DEV Community

Sedat SALMAN for AWS Community Builders

Posted on • Updated on

AWS Security Stories #01: Virtual Patching

When we learn of the existence of a new vulnerability affecting our systems, the first thing we do is immediately follow the manufacturer’s knowledge base instructions and patch the system. In cybersecurity, a vulnerability refers to a gap that allows cyber attackers to damage a system. Vulnerabilities must be fixed as soon as they are detected before they are exploited by a cybercriminal.

But the situation may not always be this easy. Sometimes the systems that have these vulnerabilities may be outside of your direct interaction.

For example, the criticality level of the Log4j vulnerability with the code CVE-2021-44228 is 10/10 according to the NVD. So we need to patch this vulnerability immediately.

However, the Log4j library may be part of another software so you cannot patch it directly since it is just a library for your software. Here comes the concept of virtual patching to save your life.

What makes patching difficult for businesses?

Some of the difficulties that businesses experience while implementing a vulnerability and patch management policy are as follows:

Limited Visibility: Sometimes the vulnerability occurs because of a library, not the software itself so you may have not enough visibility on your asset register.
Legacy Systems: Embedded systems, such as POS terminals, IoT devices, and industrial control systems, frequently contain software or components that cannot be patched.
Operational Continuity: Patching can be disruptive and expensive so you may choose to delay the patching process to minimize operational cutdowns.
Outsourced Code:

What is a Virtual Patch?

A patch is a repair task to repair the part of code or program that causes the vulnerability patching a vulnerable system might take too much time even months, especially if there is an issue that patching may interfere with the app’s basic functionality.

Virtual Patching is started with IPS (Intrusion Prevention System) Vendors. it is a way to limit the risks of exploitation of an existing vulnerability. The main goal is to prevent malicious payloads to access the vulnerable system.

Image description
One of the main primary goals of virtual patching is to quickly implement security controls and reduce the risk level.

The tools that may be used for virtual patching are as follows:

  • intermediary devices like waf or ips
  • modsecurity
  • hardening on the application side

For the AWS systems, we can use the following tools for Virtual Patching

AWS WAF: AWS WAF lets you create rules to filter web traffic based on conditions that include IP addresses, HTTP headers, and body, or custom URIs. This gives you an additional layer of protection from web attacks that attempt to exploit vulnerabilities in custom or third-party web applications. In addition, AWS WAF makes it easy to create rules that block common web exploits like SQL injection and cross-site scripting. Bu using AWS Waf you can either create rules or you can use ready-use managed rules that are provided by third-party vendors like

  • Cyber Security Cloud Managed Rules for AWS WAF
  • F5 Managed Rules for AWS WAF
  • Fortinet Managed Rules for AWS WAF
  • Imperva Managed Rules for AWS WAF
  • Trend Micro Managed Rules for AWS WAF
  • Trustwave Managed Rules for AWS WAF

all can provides virtual patches using their predefined rules. You can select the vendor according to your needs and requirements (e.g. you can select TrendMicro to protect Wordpress systems)

AWS IPS: As we stated earlier you can use a IPS to protect your system proactive by applying the virtual patch rules to you cloud network but AWS does not provide IPS product directly instead you can use the following cloud native products of the Vendors.

  • Trend Micro Deep Security
  • McAfee Virtual Network Security Platform
  • Alert Logic Professional

Top comments (0)