Microsoft October 2020 Patch Tuesday Fixes & How Cognitive Trust Can Help

Last week, Microsoft released its monthly batch of security updates, which has come to be known as Patch Tuesday, and patched 87 vulnerabilities across a wide range of Microsoft products. The fixes address critical RCE (Remote Code Execution) bugs in windows TCP/IP stack (CVE-2020-16898) and Outlook (CVE-2020-16947).

Just today (October 20), Microsoft had to rush out two additional fixes for RCE vulnerabilities affecting Microsoft Windows Codecs Library ( CVE-2020-17022) and Visual Studio Code (CVE-2020-17023). This presented a major threat, as the updated RCE bugs can allow an attacker to takeover entire Windows systems by targeting these unpatched applications.

Anyone who has ever managed a network knows that patch management can be a painful process. It becomes especially challenging when fixes to critical vulnerabilities cannot be easily applied due to various reasons, including:

• Production systems that can’t be taken offline
• Legacy systems with dependencies that will break if a patch is applied
• Patching itself introduces additional vulnerabilities which require the IT team to roll back the patch level

In addition, compliance issues tend to arise when it comes to patching systems. No matter the reason, when organizations do not patch known vulnerabilities, they’re accepting risks – implicitly or explicitly.

With the recent influx of remote work across the globe, these risks are even greater (this is especially true for CVE’s affecting Windows 10 devices). As more employees access corporate resources and sensitive data from home and other mobile or remote locations, network-based security by itself can’t hold up to these new risks and vulnerabilities.

One way to help IT and security teams tackle a patch management strategy is by implementing a zero-trust network with Elisity Cognitive Trust.

Elisity Cognitive Trust

Elisity Cognitive Trust (ECT) flips the traditional way of managing security on its head. Instead of the traditional “trust but verify” method of managing access to and on a corporate network, ECT works a bit differently, requiring that all traffic, users, applications, hosts, devices, can be authorized only if they have an explicit policy.

Additionally, when an app/device/user/etc. is verified, the trust granted only applies to that one connection. So every time a communication is initiated on a cognitive trust network, the “what” trying to connect must be verified again to ensure that a threat actor hasn’t intercepted the communication, isn’t hiding inside approved controls, or hasn’t dropped malware onto the system.

So what does this have to do with patch management? In a cognitive trust secure network, all systems— servers, applications, databases, hosts, etc.—run on the principle of least privilege. This means that only systems/apps/etc. that require access to another system/app/etc. are configured to send and receive communication to and from other network connections.

In contrast, in a traditional network, there are a lot of un-managed communication pathways. This means that both legitimate applications/services and malicious traffic can communicate over these pathways. With cognitive trust, anything unused or unnecessary is automatically blocked, therefore reducing the scope of what can communicate, or act maliciously. As a result, the probability of an exploit of an un-patched system is also reduced, as fewer resources are talking to it.

Further, an asset profile created for a cognitive trust secure network includes product or device names, versions, CVE information, and patch levels. Meaning that system administrators can be alerted on any patch management issues and make the best decision for the organization. For example, security teams could implement a policy that says, “If a remote user using windows 10 device has CVE-2020-16898 and is not running an appropriate patched version alert on a connection.” With that information in hand, the security team can make the decision to either segment the application until it’s fixed, or accept the risk of not applying the patch.

There’s a strong chance we’ll have another patch Tuesday and another set of RCE bug fixes. While patch management tools can help operationalize patch fixes in the broadly distributed enterprise, these tools cannot keep software from communicating, especially if it is already compromised by malware before patching. Also critical is that patch management is only relevant when a patch exists.  How does an organization know and prevent RCE issues before discovery and patching? Cognitive Trust provides combined Zero-Trust Network Architecture (ZTNA) and Software-Defined Perimeter (SDP) capabilities to provide fine-grained access control. This gives security teams a fighting chance at stopping unnecessary risks.

To learn more about adopting Cognitive Trust in your organization, read our how-to blog, 5 Stages to Adopt a “Zero Trust” Networking Model, or see our White Paper: Making Identity the New Perimeter.