Virtual Patching Cheat Sheet / 虚拟补丁速查表¶

Introduction / 介绍¶

The goal with this cheat Sheet is to present a concise virtual patching framework that organizations can follow to maximize the timely implementation of mitigation protections.

本速查表的目的是提供一个简洁的虚拟补丁框架，组织可以遵循此框架以最大化及时实施缓解保护措施。

Definition: Virtual Patching / 定义：虚拟补丁¶

A security policy enforcement layer that detects and blocks matching exploitation attempts against a known vulnerability without changing the vulnerable code.

一种安全策略执行层，它可以检测并阻止针对已知漏洞的匹配利用尝试，而不更改易受攻击的代码。

A virtual patch reduces exposure only for traffic the enforcement layer inspects and attack variants its rules recognize. It does not remove the underlying vulnerability. Test for bypasses and continue the code or vendor fix; rule matching and transformations can miss attacks.

虚拟补丁仅减少执行层检查的流量和其规则识别的攻击变体的暴露。它不会移除底层漏洞。测试绕过并继续代码或供应商修复；规则匹配和转换可能会错过攻击。

Why Not Just Fix the Code / 为什么不直接修复代码¶

From a purely technical perspective, the number one remediation strategy would be for an organization to correct the identified vulnerability within the source code of the web application. This concept is universally agreed upon by both web application security experts and system owners. Unfortunately, in real world business situations, there arise many scenarios where updating the source code of a web application is not easy such as:

从纯粹的技术角度来看，组织修复应用程序源代码中识别到的漏洞应该是排名第一的修复策略。这一概念得到了网络应用程序安全专家和系统所有者的普遍认同。不幸的是，在现实世界的商业情况下，有许多场景中更新网络应用程序的源代码并不容易，例如：

Lack of resources - Devs are already allocated to other projects.
中文：资源不足 - 开发人员已经被分配到其他项目。
Third-party Software - Code can not be modified by the user.
中文：第三方软件 - 代码不能被用户修改。
Outsourced App Dev - Changes would require a new project.
中文：外包应用开发 - 修改需要新的项目。

The important point is this - Code level fixes and Virtual Patching are NOT mutually exclusive. They are processes that are executed by different team (OWASP Builders/Devs vs. OWASP Defenders/OpSec) and can be run in tandem.

重要的是这一点 - 代码级别的修复和虚拟补丁不是相互排斥的。它们是由不同的团队执行的过程（OWASP 构建者/开发者 vs. OWASP 防御者/安全运营），并且可以并行运行。

Value of Virtual Patching / 虚拟补丁的价值¶

The two main goals of Virtual Patching are:

虚拟补丁的两个主要目标是：

Minimize Time-to-Fix - Fixing application source code takes time. The main purpose of a virtual patch is to implement a mitigation for the identified vulnerability as soon as possible. The urgency of this response may be different: for example if the vulnerability was identified in-house through code reviews or penetration testing vs. finding a vulnerability as part of live incident response.
中文：最小化修复时间 - 修复应用程序源代码需要时间。虚拟补丁的主要目的是尽快实施对已识别漏洞的缓解措施。这种响应的紧迫性可能不同：例如，如果漏洞是通过代码审查或渗透测试在内部发现的，与在实时事件响应中发现漏洞相比。
Attack Surface Reduction - Block the known exploitation path while a permanent fix is prepared. Test alternate encodings, affected endpoints, and paths that bypass the enforcement layer before claiming coverage. A passing test for one payload does not establish complete protection; Core Rule Set (CRS) rule-writing guidance illustrates how small payload changes can evade a rule.

Virtual Patching Tools / 虚拟补丁工具¶

Notice that the definition above did not list any specific tool as there are a number of different options that may be used for virtual patching efforts such as:

注意，上述定义中没有列出任何特定工具，因为有许多不同的选项可以用于虚拟补丁工作，例如：

Intermediary devices such as a WAF or IPS appliance
中文：中介设备，例如 WAF 或 IPS 设备
Web server plugin such as ModSecurity
中文：Web 服务器插件，例如 ModSecurity
Application layer filter such as ESAPI WAF
中文：应用层过滤器，例如 ESAPI WAF

For example purposes, we will show virtual patching examples using the open source ModSecurity WAF tool.

例如，我们将展示使用开源 ModSecurity WAF 工具的虚拟补丁示例。

A Virtual Patching Methodology / 虚拟补丁方法¶

Virtual Patching, like most other security processes, is not something that should be approached haphazardly. Instead, a consistent, repeatable process should be followed that will provide the best chances of success. The following virtual patching workflow mimics the industry accepted practice for conducting IT Incident Response and consists of the following phases:

虚拟补丁，就像大多数其他安全流程一样，不应随意对待。相反，应遵循一致、可重复的过程，以提高成功的最佳机会。以下虚拟补丁工作流程模仿了行业接受的 IT 事件响应实践，包括以下阶段：

Preparation.
中文：准备阶段。
Identification.
中文：识别阶段。
Analysis.
中文：分析。
Virtual Patch Creation.
中文：虚拟补丁创建。
Implementation/Testing.
Recovery/Follow Up.

Example Public Vulnerability / 示例公开漏洞¶

Let's take the following SQL Injection vulnerability as our example for the remainder of this article:

以下我们将以下SQL注入漏洞作为本文剩余部分的示例：

WordPress Shopping Cart Plugin for WordPress
/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php
reqID Parameter prone to SQL Injection.

Description:

描述：

WordPress Shopping Cart Plugin for WordPress contains a flaw that may allow an attacker to carry out an SQL injection attack.

WordPress购物车插件包含一个漏洞，可能允许攻击者执行SQL注入攻击。

The issue is due to the /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php script not properly sanitizing user-supplied input to the reqID parameter.

问题出在/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php脚本没有正确清理用户提供的reqID参数的输入。

This may allow an attacker to inject or manipulate SQL queries in the back-end database, allowing for the manipulation or disclosure of arbitrary data.

这可能导致攻击者在后端数据库中注入或操纵SQL查询，从而允许操纵或泄露任意数据。

Preparation Phase / 准备阶段¶

The importance of properly utilizing the preparation phase with regards to virtual patching cannot be overstated. You need to do a number of things to setup the virtual patching processes and framework prior to actually having to deal with an identified vulnerability, or worse yet, react to a live web application intrusion. The point is that during a live compromise is not the ideal time to be proposing installation of a web application firewall and the concept of a virtual patch. Tension is high during real incidents and time is of the essence, so lay the foundation of virtual patching when the waters are calm and get everything in place and ready to go when an incident does occur.

在虚拟补丁方面，充分利用准备阶段的重要性不容忽视。在必须处理已识别的漏洞，或者更糟糕的是，对实际的网络应用程序入侵做出反应之前，您需要做许多事情来设置虚拟补丁流程和框架。关键是，在实时妥协期间不是提出安装Web应用程序防火墙和虚拟补丁概念的理想时间。在真实事件中，紧张程度很高，时间至关重要，因此当情况平静时，为虚拟补丁打下基础，并在事件发生时一切就绪，随时可以启动。

Here are a few critical items that should be addressed during the preparation phase:

以下是一些在准备阶段应解决的几个关键事项：

Public/Vendor Vulnerability Monitoring - Ensure that you are signed up for all vendor alert mail-lists for commercial software that you are using. This will ensure that you will be notified in the event that the vendor releases vulnerability information and patching data.

Virtual Patching Pre-Authorization – Establish an expedited review and rollout process before an incident. Test both exploit attempts and legitimate application workflows: false positives can block valid transactions even though application code is unchanged. Define monitoring and rollback criteria before enabling blocking.

Deploy Virtual Patching Tool In Advance - As time is critical during incident response, it would be a poor time to have to get approvals to install new software. For instance, you can install ModSecurity WAF in embedded mode on your Apache servers, or an Apache reverse proxy server. The advantage with this deployment is that you can create fixes for non-Apache back-end servers. Even if you do not use ModSecurity under normal circumstances, it is best to have it "on deck" ready to be enabled if need be.
中文：提前部署虚拟补丁工具 - 在事件响应期间，时间是关键，此时不是安装新软件获得批准的好时机。例如，您可以在Apache服务器上以嵌入式模式安装ModSecurity WAF，或者安装Apache反向代理服务器。这种部署的优势在于，您可以创建针对非Apache后端服务器的修复程序。即使您在正常情况下不使用ModSecurity，最好让它“待命”，以便在需要时启用。
Configure HTTP Audit Logging – Record the rule ID, timestamp, affected endpoint, enforcement outcome, and a correlation identifier for investigation. Avoid indiscriminate capture of query strings, headers, cookies, and request or response bodies: WAF alerts can expose passwords and payment data. Exclude or redact sensitive fields before logging, following the Logging Cheat Sheet.

Identification Phase / 识别阶段¶

The Identification Phase occurs when an organization becomes aware of a vulnerability within their web application. There are generally two different methods of identifying vulnerabilities: Proactive and Reactive.

当组织意识到其Web应用程序中存在漏洞时，就进入了识别阶段。通常有两种不同的方法来识别漏洞：主动和被动。

Proactive Identification / 主动识别¶

This occurs when an organization takes it upon themselves to assess their web security posture and conducts the following tasks:

这发生在组织承担起评估其Web安全态势并执行以下任务时：

Dynamic Application Assessments - Ethical attackers conduct penetration tests or automated web assessment tools are run against the live web application to identify flaws.
中文：动态应用评估 - 道德黑客进行渗透测试或运行自动化网络评估工具针对实时网络应用以识别漏洞。
Source code reviews - Ethical attackers use manual/automated means to analyze the source code of the web application to identify flaws.

Due to the fact that custom coded web applications are unique, these proactive identification tasks are extremely important as you are not able to rely upon third-party vulnerability notifications.

由于自定义编码的网络应用是独特的，因此这些主动识别任务非常重要，因为您不能依赖于第三方漏洞通知。

Reactive Identification / 被动识别¶

There are three main reactive methods for identifying vulnerabilities:

识别漏洞主要有三种被动方法：

Vendor contact (e.g. pre-warning) - Occurs when a vendor discloses a vulnerability for commercial web application software that you are using. Example is Microsoft's Active Protections Program (MAPP)
中文：供应商联系（例如，预先警告） - 当供应商披露您所使用的商业Web应用程序软件中的漏洞时发生。例如，微软的主动保护计划（MAPP）
Public disclosure - Public vulnerability disclosure for commercial/open source web application software that you are using. The threat level for public disclosure is increased as more people know about the vulnerability.
中文：公开披露 - 对您所使用的商业/开源Web应用程序软件的公开漏洞披露。随着越来越多的人了解漏洞，公开披露的威胁级别会增加。
Security incident – This is the most urgent situation as the attack is active. In these situations, remediation must be immediate.
中文：安全事件 - 这是最紧急的情况，因为攻击正在进行。在这种情况下，必须立即进行修复。

Analysis Phase / 分析阶段¶

Here are the recommended steps to start the analysis phase:

以下是开始分析阶段的推荐步骤：

Determine Virtual Patching Applicability - Virtual patching is ideally suited for injection-type flaws but may not provide an adequate level of attack surface reduction for other attack types or categories. Thorough analysis of the underlying flaw should be conducted to determine if the virtual patching tool has adequate detection logic capabilities.
中文：确定虚拟补丁适用性 - 虚拟补丁非常适合注入型漏洞，但可能无法为其他攻击类型或类别提供足够的攻击面减少。应彻底分析潜在漏洞，以确定虚拟补丁工具是否具有足够的检测逻辑能力。
Utilize Bug Tracking/Ticketing System - Enter the vulnerability information into a bug tracking system for tracking purposes and metrics. Recommend you use ticketing systems you already use such as Jira or you may use a specialized tool such as ThreadFix.
中文：利用缺陷跟踪/工单系统 - 将漏洞信息输入到缺陷跟踪系统中进行跟踪和度量。建议您使用您已经使用的工单系统，如Jira，或者您可以使用专门的工具，如ThreadFix。
Verify the name of the vulnerability - This means that you need to have the proper public vulnerability identifier (such as CVE name/number) specified by the vulnerability announcement, vulnerability scan, etc. If the vulnerability is identified proactively rather than through public announcements, then you should assign your own unique identifier to each vulnerability.
中文：验证漏洞名称 - 这意味着您需要根据漏洞公告、漏洞扫描等指定的适当公共漏洞标识符（例如CVE名称/编号）。如果漏洞是通过主动识别而不是通过公开公告来识别的，那么您应该为每个漏洞分配您自己的唯一标识符。
Designate the impact level - It is always important to understand the level of criticality involved with a web vulnerability. Information leakages may not be treated in the same manner as an SQL Injection issue.
中文：指定影响级别 - 总是了解与网络漏洞相关的严重性级别非常重要。信息泄露可能不会像SQL注入问题那样被对待。
Specify which versions of software are impacted - You need to identify what versions of software are listed so that you can determine if the version(s) you have installed are affected.
中文：指定受影响的软件版本 - 您需要确定哪些软件版本被列出，以便您可以确定您安装的版本是否受到影响。
List what configuration is required to trigger the problem - Some vulnerabilities may only manifest themselves under certain configuration settings.
中文：列出触发问题的配置要求 - 一些漏洞可能仅在特定的配置设置下才会表现出来。
List Proof of Concept (PoC) exploit code or payloads used during attacks/testing - Many vulnerability announcements have accompanying exploit code that shows how to demonstrate the vulnerability. If this data is available, make sure to download it for analysis. This will be useful later on when both developing and testing the virtual patch.
中文：列出攻击/测试期间使用的概念验证（PoC）利用代码或有效载荷 - 许多漏洞公告都附带了演示漏洞的利用代码。如果这些数据可用，请确保下载它进行分析。这将在开发虚拟补丁和测试虚拟补丁时非常有用。

Virtual Patch Creation Phase / 虚拟补丁创建阶段¶

The process of creating an accurate virtual patch is bound by two main tenants:

创建准确虚拟补丁的过程受以下两个主要原则的约束：

No false positives - Do not ever block legitimate traffic under any circumstances.
中文：无误报 - 在任何情况下都不要阻止合法流量。
No false negatives - Do not ever miss attacks, even when the attacker intentionally tries to evade detection.
中文：无漏报 - 即使攻击者故意试图规避检测，也不要错过攻击。

Care should be taken to attempt to minimize either of these two rules. It may not be possible to adhere 100% to each of these goals but remember that virtual patching is about Risk Reduction. It should be understood by business owners that while you are gaining the advantage of shortening the Time-to-Fix metric, you may not be implementing a complete fix for the flaw.

应尽力最小化这两条规则之一。可能无法100%遵守这些目标，但请记住，虚拟补丁是关于风险降低的。业务负责人应理解，虽然您正在缩短修复时间指标，但您可能没有实施对漏洞的完整修复。

Manual Virtual Patch Creation / 手动虚拟补丁创建¶

Positive Security (Allow List) Virtual Patches (Recommended Solution) / 积极安全（允许列表）虚拟补丁（推荐解决方案）¶

Positive security model (allowlist) is a comprehensive security mechanism that provides an independent input validation envelope to an application. The model specifies the characteristics of valid input (character set, length, etc…) and denies anything that does not conform. By defining rules for every parameter in every page in the application the application is protected by an additional security envelop independent from its code.

积极安全模型（允许列表）是一种全面的安全机制，为应用程序提供一个独立输入验证的外壳。该模型指定了有效输入的特性（字符集、长度等...）并拒绝任何不符合规定的输入。通过定义应用程序中每个页面每个参数的规则，应用程序通过一个额外的安全外壳得到保护，这个外壳独立于其代码。

Example Allow List ModSecurity Virtual Patch / 示例允许列表ModSecurity虚拟补丁¶

In order to create an allow-list virtual patch, you must be able to verify what the normal, expected input values are. If you have implemented proper audit logging as part of the Preparation Phase, then you should be able to review audit logs to identify the format of expected input types. In this case, the reqID parameter is supposed to only hold integer characters so we can use this virtual patch:

为了创建允许列表虚拟补丁，您必须能够验证正常、预期的输入值。如果您在准备阶段实现了适当的审计日志记录，那么您应该能够审查审计日志以识别预期输入类型的格式。在这种情况下，reqID参数应该只包含整数字符，因此我们可以使用这个虚拟补丁：

##
## Verify we only receive 1 parameter called "reqID"
##
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter - Duplicate Parameters Names Seen.',logdata:'%{matched_var}'"
  SecRule &ARGS:/reqID/ "!@eq 1"

##
## Verify reqID's payload only contains integers
##
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:2,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
  SecRule ARGS:/reqID/ "!@rx ^[0-9]+$"

This virtual patch will inspect the reqID parameter value on the specified page and prevent any characters other than integers as input.

这个虚拟补丁将检查指定页面的reqID参数值，并防止任何非整数字符作为输入。

Note - You should make sure to assign rule IDs properly and track them in the bug tracking system.
中文：注意 - 您应该确保正确分配规则ID并在缺陷跟踪系统中跟踪它们。
Caution: There are numerous evasion vectors when creating virtual patches. Please consult the OWASP Best Practices: Virtual Patching document for a more thorough discussion on countering evasion methods.
中文：注意：创建虚拟补丁时存在许多规避向量。请参阅OWASP最佳实践：虚拟补丁文档，以了解更多关于对抗规避方法的内容。

Negative Security (Block List) Virtual Patches / 消极安全（阻止列表）虚拟补丁¶

A negative security model (denylist) is based on a set of rules that detect specific known attacks rather than allow only valid traffic.

基于一组规则的安全模型（拒绝列表）是检测特定已知攻击，而不是仅允许有效流量的一种方式。

Example Block List ModSecurity Virtual Patch / ModSecurity 虚拟补丁示例阻止列表¶

Here is the example PoC code that was supplied by the public advisory:

以下是由公共安全通告提供的示例 PoC 代码：

http://localhost/wordpress/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php?reqID=1' or 1='1

Looking at the payload, we can see that the attacker is inserting a single quote character and then adding additional SQL query logic to the end. Based on this data, we could disallow the single quote character like this:

观察有效载荷，我们可以看到攻击者正在插入一个单引号字符，然后在末尾添加额外的 SQL 查询逻辑。基于这些数据，我们可以像这样禁止单引号字符：

SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
  SecRule ARGS:/reqID/ "@pm '"

Which Method is Better for Virtual Patching – Positive or Negative Security / 虚拟补丁哪种方法更好 - 正面还是负面安全？¶

A virtual patch may employ either a positive or negative security model. Which one you decide to use depends on the situation and a few different considerations. For example, negative security rules can usually be implemented more quickly, however the possible evasions are more likely.

虚拟补丁可能采用正面或负面安全模型。您决定使用哪种取决于具体情况和几个不同的考虑因素。例如，负面安全规则通常可以更快地实现，然而可能的规避可能性更大。

Positive security rules, only the other hand, provides better protection however it is often a manual process and thus is not scalable and difficult to maintain for large/dynamic sites. While manual positive security rules for an entire site may not be feasible, a positive security model can be selectively employed when a vulnerability alert identifies a specific location with a problem.

另一方面，正面安全规则提供了更好的保护，但它通常是一个手动过程，因此不适用于大型/动态站点。虽然为整个站点手动设置正面安全规则可能不可行，但在漏洞警报识别出特定位置存在问题的情况下，可以选择性地采用正面安全模型。

Beware of Exploit-Specific Virtual Patches / 小心针对特定漏洞的虚拟补丁¶

You want to resist the urge to take the easy road and quickly create an exploit-specific virtual patch.

您应该抵制走捷径并快速创建一个特定漏洞的虚拟补丁的诱惑。

For instance, if an authorized penetration test identified an XSS vulnerability on a page and used the following attack payload in the report:

例如，如果一次授权的渗透测试在某个页面上发现了一个XSS漏洞，并在报告中使用了以下攻击载荷：

<script>
  alert('XSS Test')
</script>

It would not be wise to implement a virtual patch that simply blocks that exact payload. While it may provide some immediate protection, its long term value is significantly decreased.

简单地阻止该特定载荷的虚拟补丁并不是明智之举。虽然这可能会提供一些即时的保护，但其长期价值显著降低。

Automated Virtual Patch Creation / 自动化虚拟补丁创建¶

Manual patch creation may become unfeasible as the number of vulnerabilities grow and automated means may become necessary. If the vulnerabilities were identified using automated tools and an XML report is available, it is possible to leverage automated processes to auto-convert this vulnerability data into virtual patches for protection systems.

随着漏洞数量的增加，手动创建补丁可能变得不可行，而自动化手段可能变得必要。如果使用自动化工具识别漏洞且提供了XML报告，则可以利用自动化流程将此漏洞数据自动转换为保护系统的虚拟补丁。

Three examples include:

以下有三个例子：

OWASP ModSecurity Core Rule Set (CRS) Scripts - The OWASP CRS includes scripts to auto-convert XML output from tools such as [ZAP into ModSecurity Virtual Patches]. Reference here.
中文：OWASP ModSecurity核心规则集（CRS）脚本 - OWASP CRS包括将来自ZAP等工具的XML输出自动转换为ModSecurity虚拟补丁的脚本。参考此处。
ThreadFix Virtual Patching - ThreadFix also includes automated processes of converting imported vulnerability XML data into virtual patches for security tools such as ModSecurity. Reference here.
中文：ThreadFix虚拟补丁 - ThreadFix还包括将导入的漏洞XML数据自动转换为ModSecurity等安全工具的虚拟补丁的自动化过程。参考此处。
Direct Importing to WAF Device - Many commercial WAF products have the capability to import DAST tool XML report data and automatically adjust their protection profiles.
中文：直接导入到WAF设备 - 许多商业WAF产品具有导入DAST工具XML报告数据并自动调整其保护配置文件的能力。

Implementation/Testing Phase¶

In order to accurately test out the newly created virtual patches, it may be necessary to use an application other than a web browser. Some useful tools are:

为了准确测试新创建的虚拟补丁，可能需要使用除网页浏览器以外的应用程序。一些有用的工具包括：

Web browser.
中文：网页浏览器.
Command-line web clients such as Curl and Wget.
中文：命令行网页客户端，如Curl和Wget.
Local Proxy Servers such as ZAP.
中文：本地代理服务器，例如 ZAP.
ModSecurity AuditViewer) （ModSecurity审计查看器） – which allows you to load a ModSecurity audit log file, manipulate it and then re-inject the data back into any web server.

Testing Steps / 测试步骤¶

Implement virtual patches initially in a "Log Only" configuration to ensure that you do not block any normal user traffic (false positives).
中文：最初在“仅记录”配置中实施虚拟补丁，以确保您不会阻止任何正常用户流量（误报）。
If the vulnerability was identified by a specific tool or assessment team - request a retest.
中文：如果漏洞是由特定工具或评估团队识别的，则请求重新测试。
If retesting fails due to evasions, then you must go back to the Analysis phase to identify how to better fix the issue.
中文：如果由于规避而重新测试失败，那么您必须回到分析阶段，以确定如何更好地修复问题。

Recovery/Follow-Up Phase¶

Update Data in Ticket System - Although you may need to expedite the implementation of virtual patches, you should still track them in your normal Patch Management processes. This means that you should create proper change request tickets, etc… so that their existence and functionality is documented. Updating the ticket system also helps to identify "time-to-fix" metrics for different vulnerability types. Make sure to properly log the virtual patch rule ID values.
中文：更新票务系统中的数据 - 虽然您可能需要加快虚拟补丁的实施，但您仍应在正常的补丁管理流程中跟踪它们。这意味着您应该创建适当的变化请求票据等，以便记录它们的存续和功能。更新票务系统还有助于识别不同漏洞类型的“修复时间”指标。请确保正确记录虚拟补丁规则ID值。
Periodic Re-assessments - You should also have periodic re-assessments to verify if/when you can remove previous virtual patches if the web application code has been updated with the real source code fix. I have found that many people opt to keep virtual patches in place due to better identification/logging vs. application or db capabilities.
中文：定期再评估 - 您还应进行定期再评估，以验证是否可以在应用程序代码更新为真实源代码修复后移除之前的虚拟补丁。我发现许多人选择保留虚拟补丁，因为它们在识别/记录方面优于应用程序或数据库功能。
Running Virtual Patch Alert Reports - Run reports to identify if/when any of your virtual patches have triggered. This will show value for virtual patching in relation to windows of exposure for source code time-to-fix.
中文：运行虚拟补丁警报报告 - 运行报告以确定是否任何虚拟补丁已触发。这将显示虚拟补丁在源代码修复时间窗口内的价值。

References / 参考¶

OWASP Virtual Patching Best Practices) （OWASP虚拟打补丁最佳实践）
OWASP CRS: Making Rules) （OWASP CRS：制定规则）