Virtual Patches

Virtual Patches protect web applications by targeting specific vulnerabilities and only triggering attacks aimed at those weaknesses. They operate based on rules with conditions that must be true for a violation to occur, minimizing false positives.

Grouped by software product or technology, Virtual Patches address specific vulnerabilities. The Emerging Threats group covers zero-day exploits and is enabled by default. Managing active patches is crucial to avoid latency, with patches retired after 365 days for software-specific and 730 days for Emerging Threats.

Fortra monitors exploit repositories to ensure coverage, focusing on widely used software. Virtual Patches are released weekly, with immediate updates for Emerging Threats within five hours of identifying a zero-day exploit.

Each virtual patch group has a separate policy scope, allowing for specific violation actions like blocking or logging, ensuring precise and effective security measures.

• Virtual Patches
  • Virtual patch rules
  • Virtual patch groups
  • Virtual patch coverage
  • Release cadency
  • Policy scope
  • Managing Virtual Patches

To go to the documentation for the previous section of Alert Logic Managed Web Application Firewall (WAF), see Web Applications. To go to the documentation for next section in the WAF section, see Output Filter.

Virtual patch rules

Virtual Patches play a crucial role in protecting web applications by detecting and responding to specific vulnerabilities. Each virtual patch is designed to target known vulnerabilities and only triggers on attacks aimed at those specific weaknesses. The following list outlines the essential characteristics and functions of Virtual Patches:

• Rule-based detection and attribution of attacks targeting known vulnerabilities.
• Each virtual patch is closely related to a specific vulnerability and only triggers on attacks targeting that vulnerability.
• Even with detectable exploit payloads in a request, the virtual patch must not trigger unless the specific vulnerability is targeted.
• A virtual patch rule consists of conditions that all must be true for the rule to trigger a violation—conditions are AND’ed.
• Each condition consists of one or more patterns, and any one pattern matching the condition makes it true—patterns within conditions are OR’ed.
• Conditions are either of type Discriminate or Detect.
• Discriminate conditions trigger on strings in the request specific to the vulnerability covered by the rule.
• Detect conditions trigger on the presence of exploit payloads in specific request elements.
• The combination of Discriminate and Detect conditions makes a properly crafted virtual patch very unlikely to trigger false positives.

Virtual patch groups

Virtual Patches are mainly grouped by software product or technology. In each group individual patches are specifically tailored to address exploits targeting specific vulnerabilities, which in turn are unique to each software product. Therefore, it is essential to enable the virtual patch groups that are relevant to the protected website to ensure optimal security.

One notable group of Virtual Patches is the Emerging Threats group, which provides coverage for zero-day exploits identified by the Fortra research team. This group is enabled by default to offer immediate protection against newly discovered threats.

However, it is important to manage the number of active Virtual Patches carefully. Enabling too many patches can increase latency by adding unnecessary load on the detection system when validating requests. To control this, Virtual Patches are retired once the vulnerability they cover reaches a certain age, a process known as the rolling coverage period. For software-specific Virtual Patches, this period is 365 days, while for the Emerging Threats group, it extends to 730 days.

• Virtual Patches are mainly grouped by software product or technology.
• Since Virtual Patches are specific to vulnerabilities and vulnerabilities are specific to software products, it is essential to enable only the Virtual Patches relevant to the protected website.
• The Emerging Threats group (enabled by default) provides coverage for zero-day exploits classified as Emerging Threats by the Fortra research team.
• Enabling too many Virtual Patches can increase latency by adding unnecessary load on the detection system when validating requests. Therefore, the number of active Virtual Patches should be limited.
• To control the number of patches within each group, Virtual Patches are retired when the vulnerability they cover reaches a certain age. This process is referred to as the rolling coverage period.
• The rolling coverage period for software-specific Virtual Patches is 365 days, while for the Emerging Threats group, it is 730 days.

Virtual patch coverage

Fortra actively monitors well-known exploit repositories such as Packet Storm, GitHub, and Exploit DB to identify new exploits and ensure comprehensive coverage.

The coverage provided by Virtual Patches is determined based on the popularity and usage of applications and technologies among Fortra customers. By focusing on widely used software and technologies, Fortra ensures that the most critical vulnerabilities are addressed, providing robust protection for our customers. Currently, Fortra tracks the top 100 web applications along with several other applications that are frequently used by our customers.

Release cadency

Virtual Patches are released on a weekly basis to ensure continuous protection against known vulnerabilities in standard software products. However, when it comes to Emerging Threats, Fortra takes immediate action. As soon as an exploit sample of an emerging threat is available, it typically takes less than an hour to build a virtual patch. Once these patches are released, individual Web Application Firewall (WAF) appliances are updated within four hours. This means that from the moment Fortra becomes aware of a zero-day exploit, all customers' WAF instances will typically be updated to protect against it within five hours.

Virtual patch groups are automatically updated to streamline the release process. For enabled virtual patch groups, new Virtual Patches will become active immediately upon arrival at the instance, ensuring that protection is always up to date.

Policy scope

Each individual virtual patch group operates as a separate policy scope, allowing for specific violation actions to be set. These actions can be configured to block (Protect), log only (Detect), or inherit the global violation action set for the website policy (Use Global). The virtual patch policy scope takes precedence over the website policy global setting. This means that while the Web Application Firewall (WAF) policy is still being tuned and the global violation action is set to Detect, individual virtual patch groups—due to their targeted nature and near zero false positive rate—can be set to Protect.

Additionally, violation actions can be customized for individual Virtual Patches within each virtual patch group, further overriding the violation action set for the virtual patch group scope. This flexibility ensures that security measures are both precise and effective, tailored to the specific needs of each virtual patch group.

Managing Virtual Patches

To manage Virtual Patches, navigate to Websites > Policy > Virtual Patches.

The following screenshot shows the enabled Virtual Patch Group, APACHECAMEL. Disabled Virtual Patch Groups names will appear dimmed:

To select between showing all groups or only enabled groups, click the Display drop-down menu:

To enable and manage a Virtual Patch Group, click the plus (+) icon.

Use the following settings to manage a group:

• Application status: Toggle between Active and Inactive to enable and disable the Virtual Patch Group.
• Violation action: Select from the following actions for the scope of the Virtual patch Group:
  • Use global: Inherit the violation action from global policy scope.
  • Protect: Block violations from Virtual Patches within group.
  • Detect: Log but do not block violations.
  • Pass: Allow violations.

The following screenshot shows the APACHECAMEL Virtual Patch Group was added recently and only contains the most recent vulnerability ID for the application. All six Virtual Patches reference the same vulnerability ID as there are six different exploit variations targeting the specific vulnerability.

To view a list of information regarding the vulnerability, click the magnifying glass icon:

To override a Virtual Patch Group violation action for an individual Virtual Patch, click the Action Override drop-down menu and then select one of the following actions:

• None: Use the Virtual Patch Group violation action.
• Block IP: Block violations and blacklist source IP.
• Block: Block violations.
• Log: Log but do not block violations.
• Pass: Allow violations.

  • The Pass action is typically used in cases where the exploit is difficult to differentiate from normal requests, such as Authentication or Authorization vulnerabilities. The Virtual Patch “stops the accident” but may limit normal usage. Once a patch has been applied to the vulnerable application, Action Override can be set to Pass to effectively disable the individual virtual patch.