Security intelligence updates for Microsoft Defender Antivirus and other Microsoft antimalware

Microsoft continually updates security intelligence in antimalware products to cover the latest threats and to constantly tweak detection logic, enhancing the ability of Microsoft Defender Antivirus and other Microsoft antimalware solutions to accurately identify threats. This security intelligence works directly with cloud-based protection to deliver fast and powerful AI-enhanced, next-generation protection.

Microsoft security intelligence updates include software that incorporates material from third parties. Third-party notices and information

Automatic updates

To help ensure your antimalware solution detects the latest threats, get updates automatically as part of Windows Update. If you are having problems with Windows Update, use the troubleshooter.

If you don’t already use Microsoft Defender Antivirus, learn how to turn it on.

Trigger an update

A manually triggered update immediately downloads and applies the latest security intelligence. This process might also address problems with automatic updates. Microsoft Defender Antivirus and other Microsoft antimalware solutions provide a way to manually trigger an update.

In Windows 10, select Check for updates in the Windows Security Virus & threat protection screen to check for the latest updates.

Enterprise administrators can also push updates to devices in their network. To clear the current cache and trigger an update, use a batch script that runs the following commands as an administrator:

Manually download the update

You can manually download the latest update.

Latest security intelligence update

The latest security intelligence update is:

• Version: 1.335.1079.0
• Engine Version: 1.1.18000.5
• Platform Version: 4.18.2103.7
• Released: 4/17/2021 6:41:46 PM
• Documentation: Release notes

You need to download different security intelligence files for different products and platforms. Select the version that matches your Windows operating system or the environment where you will apply the update.

Note: Starting on Monday October 21, 2019, the Security intelligence update packages will be SHA2 signed.
Please make sure you have the necessary update installed to support SHA2 signing, see 2019 SHA-2 Code Signing Support requirement for Windows and WSUS.

Antimalware solution	Definition version
Microsoft Defender Antivirus for Windows 10 and Windows 8.1	32-bit | 64-bit | ARM
Microsoft Security Essentials	32-bit | 64-bit
Windows Defender in Windows 7 and Windows Vista	32-bit | 64-bit
Microsoft Diagnostics and Recovery Toolset (DaRT)	32-bit | 64-bit
System Center 2012 Configuration Manager	32-bit | 64-bit
System Center 2012 Endpoint Protection	32-bit | 64-bit
Windows Intune	32-bit | 64-bit

The links point to an executable file named mpam-fe.exe , mpam-feX64.exe , or mpas-fe.exe (used by older antispyware solutions). Simply launch the file to manually install the latest security intelligence.

End of life for Microsoft Forefront Client Security was on July 14, 2015. Customers are encouraged to migrate to System Center Endpoint Protection. For more information, visit the Microsoft support lifecycle website.

Network Inspection System updates

The following products leverage Network Inspection System (NIS) updates:

• Microsoft Security Essentials
• Forefront Endpoint Protection
• System Center 2012 Endpoint Protection

These updates are designed to protect you from network threats, including exploits as they are transmitted. Check the version of the Antimalware Client component on your security software and download the right version of the NIS updates for your platform.

Secure the Network Controller

Applies to: Windows Server 2019, Windows Server 2016

In this topic, you learn how to configure security for all communication between Network Controller and other software and devices.

The communication paths that you can secure include Northbound communication on the management plane, cluster communication between Network Controller virtual machines (VMs) in a cluster, and Southbound communication on the data plane.

Northbound Communication. Network Controller communicates on the management plane with SDN-capable management software like Windows PowerShell and System Center Virtual Machine Manager (SCVMM). These management tools provide you with the ability to define network policy and to create a goal state for the network, against which you can compare the actual network configuration to bring the actual configuration into parity with the goal state.

Network Controller Cluster Communication. When you configure three or more VMs as Network Controller cluster nodes, these nodes communicate with each other. This communication might be related to synchronizing and replication of data across nodes, or specific communication between Network Controller services.

Southbound Communication. Network Controller communicates on the data plane with SDN infrastructure and other devices like software load balancers, gateways, and host machines. You can use Network Controller to configure and manage these southbound devices so that they maintain the goal state that you have configured for the network.

Northbound Communication

Network Controller supports authentication, authorization, and encryption for Northbound communication. The following sections provide information on how to configure these security settings.

Authentication

When you configure authentication for Network Controller Northbound communication, you allow Network Controller cluster nodes and management clients to verify the identity of the device with which they are communicating.

Network Controller supports the following three modes of authentication between management clients and Network Controller nodes.

If you are deploying Network Controller with System Center Virtual Machine Manager, only Kerberos mode is supported.

Kerberos. Use Kerberos authentication when joining both the management client and all Network Controller cluster nodes to an Active Directory domain. The Active Directory domain must have domain accounts used for authentication.

X509. Use X509 for certificate-based authentication for management clients not joined to an Active Directory domain. You must enroll certificates to all Network Controller cluster nodes and management clients. Also, all nodes and management clients must trust each others’ certificates.

None. Use None for testing purposes in a test environment and, therefore, not recommended for use in a production environment. When you choose this mode, there is no authentication performed between nodes and management clients.

You can configure the Authentication mode for Northbound communication by using the Windows PowerShell command Install-NetworkController with the ClientAuthentication parameter.

Authorization

When you configure authorization for Network Controller Northbound communication, you allow Network Controller cluster nodes and management clients to verify that the device with which they are communicating is trusted and has permission to participate in the communication.

Use the following authorization methods for each of the authentication modes supported by Network Controller.

Kerberos. When you are using the Kerberos authentication method, you define the users and computers authorized to communicate with Network Controller by creating a security group in Active Directory, and then adding the authorized users and computers to the group. You can configure Network Controller to use the security group for authorization by using the ClientSecurityGroup parameter of the Install-NetworkController Windows PowerShell command. After installing the Network Controller, you can change the security group by using the Set-NetworkController command with the parameter -ClientSecurityGroup. If using SCVMM, you must provide the security group as a parameter during deployment.

X509. When you are using the X509 authentication method, Network Controller only accepts requests from management clients whose certificate thumbprints are known to Network Controller. You can configure these thumbprints by using the ClientCertificateThumbprint parameter of the Install-NetworkController Windows PowerShell command. You can add other client thumbprints at any time by using the Set-NetworkController command.

None. When you choose this mode, there is no authentication performed between nodes and management clients. Use None for testing purposes in a test environment and, therefore, not recommended for use in a production environment.

Encryption

Northbound communication uses Secure Sockets Layer (SSL) to create an encrypted channel between management clients and Network Controller nodes. SSL encryption for Northbound communication includes the following requirements:

All Network Controller nodes must have an identical certificate that includes the Server Authentication and Client Authentication purposes in Enhanced Key Usage (EKU) extensions.

The URI used by management clients to communicate with Network Controller must be the certificate subject name. The certificate subject name must contain either the Fully Qualified Domain Name (FQDN) or the IP address of the Network Controller REST Endpoint.

If Network Controller nodes are on different subnets, the subject name of their certificates must be the same as the value used for the RestName parameter in the Install-NetworkController Windows PowerShell command.

All of the management clients must trust the SSL certificate.

SSL Certificate Enrollment and Configuration

You must manually enroll the SSL certificate on Network Controller nodes.

After the certificate is enrolled, you can configure Network Controller to use the certificate with the -ServerCertificate parameter of the Install-NetworkController Windows PowerShell command. If you have already installed Network Controller, you can update the configuration at any time by using the Set-NetworkController command.

If you are using SCVMM, you must add the certificate as a library resource. For more information, see Set up an SDN network controller in the VMM fabric.

Network Controller Cluster Communication

Network Controller supports authentication, authorization, and encryption for communication between Network Controller nodes. The communication is over Windows Communication Foundation (WCF) and TCP.

You can configure this mode with the ClusterAuthentication parameter of the Install-NetworkControllerCluster Windows PowerShell command.

Authentication

When you configure authentication for Network Controller Cluster communication, you allow Network Controller cluster nodes to verify the identity of the other nodes with which they are communicating.

Network Controller supports the following three modes of authentication between Network Controller nodes.

If you deploy Network Controller by using SCVMM, only Kerberos mode is supported.

Kerberos. You can use Kerberos authentication when all Network Controller cluster nodes are joined to an Active Directory domain, with domain accounts used for authentication.

X509. X509 is certificate-based authentication. You can use X509 authentication when Network Controller cluster nodes are not joined to an Active Directory domain. To use X509, you must enroll certificates to all Network Controller cluster nodes, and all nodes must trust the certificates. In addition, the subject name of the certificate that is enrolled on each node must be the same as the DNS name of the node.

None. When you choose this mode, there is no authentication performed between Network Controller nodes. This mode is provided only for testing purposes, and is not recommended for use in a production environment.

Authorization

When you configure authorization for Network Controller Cluster communication, you allow Network Controller cluster nodes to verify that the nodes with which they are communicating are trusted and have permission to participate in the communication.

For each of the authentication modes supported by Network Controller, the following authorization methods are used.

Kerberos. Network Controller nodes accept communication requests only from other Network Controller machine accounts. You can configure these accounts when you deploy Network Controller by using the Name parameter of the New-NetworkControllerNodeObject Windows PowerShell command.

X509. Network Controller nodes accept communication requests only from other Network Controller machine accounts. You can configure these accounts when you deploy Network Controller by using the Name parameter of the New-NetworkControllerNodeObject Windows PowerShell command.

None. When you choose this mode, there is no authorization performed between Network Controller nodes. This mode is provided only for testing purposes, and is not recommended for use in a production environment.

Encryption

Communication between Network Controller nodes is encrypted using WCF Transport level encryption. This form of encryption is used when the authentication and authorization methods are either Kerberos or X509 certificates. For more information, see the following topics.

Southbound Communication

Network Controller interacts with different types of devices for Southbound communication. These interactions use different protocols. Because of this, there are different requirements for authentication, authorization, and encryption depending on the type of device and protocol used by Network Controller to communicate with the device.

The following table provides information about Network Controller interaction with different southbound devices.

Southbound device/service	Protocol	Authentication used
Software Load Balancer	WCF (MUX), TCP (Host)	Certificates
Firewall	OVSDB	Certificates
Gateway	WinRM	Kerberos, Certificates
Virtual Networking	OVSDB, WCF	Certificates
User defined routing	OVSDB	Certificates

For each of these protocols, the communication mechanism is described in the following section.

Authentication

For Southbound communication, the following protocols and authentication methods are used.

WCF/TCP/OVSDB. For these protocols, authentication is performed by using X509 certificates. Both Network Controller and the peer Software Load Balancing (SLB) Multiplexer (MUX)/host machines present their certificates to each other for mutual authentication. Each certificate must be trusted by the remote peer.

For southbound authentication, you can use the same SSL certificate that is configured for encrypting the communication with the Northbound clients. You must also configure a certificate on the SLB MUX and host devices. The certificate subject name must be same as the DNS name of the device.

WinRM. For this protocol, authentication is performed by using Kerberos (for domain joined machines) and by using certificates (for non-domain joined machines).

Authorization

For Southbound communication, the following protocols and authorization methods are used.

WCF/TCP. For these protocols, authorization is based on the subject name of the peer entity. Network Controller stores the peer device DNS name, and uses it for authorization. This DNS name must match the subject name of the device in the certificate. Likewise, Network Controller certificate must match the Network Controller DNS name stored on the peer device.

WinRM. If Kerberos is being used, the WinRM client account must be present in a predefined group in Active Directory or in the Local Administrators group on the server. If certificates are being used, the client presents a certificate to the server that the server authorizes using the subject name/issuer, and the server uses a mapped user account to perform authentication.

OVSDB. There is no authorization provided for this protocol.

Encryption

For Southbound communication, the following encryption methods are used for protocols.

WCF/TCP/OVSDB. For these protocols, encryption is performed using the certificate that is enrolled on the client or server.

WinRM. WinRM traffic is encrypted by default using Kerberos security support provider (SSP). You can configure Additional encryption, in the form of SSL, on the WinRM server.