application_security/vulnerability_management

17 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Virtual Patching Definition

A virtual patch is a security policy enforcement layer which prevents and reports the exploitation attempt of a known vulnerability. It works by analyzing transactions and intercepting attacks in transit so malicious traffic never reaches the web application. While the actual source code of the application has not been modified, the exploitation attempt does not succeed.

Virtual Patching Goals

The two main goals of Virtual Patching are: (1) Minimize Time-to-Fix - implementing a mitigation for identified vulnerabilities as soon as possible before source code fixes are available; (2) Attack Surface Reduction - minimizing the attack vector by focusing on the specific vulnerability. A 50% reduction in 10 minutes is better than 100% reduction in 48 hours.

Virtual Patching Tools and Deployment Options

Virtual patches can be implemented using various tools: intermediary devices such as a WAF or IPS appliance; web server plugins such as ModSecurity; or application layer filters such as ESAPI WAF. Tools should be deployed in advance during the preparation phase so they are ready to be enabled if needed, rather than waiting until a live incident occurs.

Virtual Patching Workflow Phases

Virtual patching should follow a consistent, repeatable process consisting of six phases: (1) Preparation; (2) Identification; (3) Analysis; (4) Virtual Patch Creation; (5) Implementation/Testing; (6) Recovery/Follow Up. This workflow mimics industry accepted practice for conducting IT Incident Response.

Preparation Phase: Vulnerability Monitoring

During the preparation phase, organizations should be signed up for all vendor alert mail-lists for commercial software in use. This ensures notification when vendors release vulnerability information and patching data.

Preparation Phase: Virtual Patch Pre-Authorization

Virtual patches need to be implemented quickly, so normal governance processes and authorization steps for standard software patches should be expedited. Since virtual patches do not modify source code, they do not require the same amount of regression testing as normal software patches. Categorizing virtual patches in the same group as Anti-Virus updates or Network IDS signatures helps speed up authorization and minimize extended testing phases.

Identification Phase: Proactive Vulnerability Identification

Proactive identification occurs when an organization assesses its web security posture by conducting: (1) Dynamic Application Assessments - ethical attackers conduct penetration tests or automated web assessment tools are run against the live web application; (2) Source code reviews - ethical attackers use manual or automated means to analyze source code. These proactive tasks are extremely important for custom coded applications since third-party vulnerability notifications cannot be relied upon.

Identification Phase: Reactive Vulnerability Identification

There are three main reactive methods for identifying vulnerabilities: (1) Vendor contact (e.g. pre-warning) - vendor discloses vulnerability for commercial web application software in use, such as Microsoft's Active Protections Program (MAPP); (2) Public disclosure - public vulnerability disclosure for commercial or open source web application software, with increased threat level as more people know about the vulnerability; (3) Security incident - most urgent situation where attack is active and remediation must be immediate.

Analysis Phase: Virtual Patching Applicability Assessment

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.

Analysis Phase: Vulnerability Information Collection

The analysis phase should collect: (1) Public vulnerability identifier (CVE name/number) or assign unique identifier if identified proactively; (2) Impact level - criticality level of the vulnerability; (3) Affected software versions - identify what versions are impacted; (4) Required configuration to trigger the problem - some vulnerabilities manifest only under certain settings; (5) Proof of Concept (PoC) exploit code or payloads - download accompanying exploit code for analysis, useful for developing and testing virtual patches.

Virtual Patch Creation: Core Tenants

Creating an accurate virtual patch is bound by two main tenants: (1) No false positives - do not ever block legitimate traffic under any circumstances; (2) No false negatives - do not ever miss attacks, even when the attacker intentionally tries to evade detection. Virtual patching is about Risk Reduction, and it may not be possible to adhere 100% to each goal.

Automated Virtual Patch Creation Tools

Automated means may become necessary as the number of vulnerabilities grow. If vulnerabilities were identified using automated tools and XML reports are available, it is possible to auto-convert vulnerability data into virtual patches. Three examples include: (1) OWASP ModSecurity Core Rule Set (CRS) Scripts - includes scripts to auto-convert XML output from tools such as ZAP into ModSecurity Virtual Patches; (2) ThreadFix Virtual Patching - includes automated processes to convert imported vulnerability XML data into virtual patches for security tools such as ModSecurity; (3) Direct Importing to WAF Device - many commercial WAF products have capability to import DAST tool XML report data and automatically adjust their protection profiles.

Implementation/Testing Phase: Testing Tools

To accurately test newly created virtual patches, useful tools include: (1) Web browser; (2) Command-line web clients such as Curl and Wget; (3) Local Proxy Servers such as ZAP; (4) ModSecurity AuditViewer - allows loading a ModSecurity audit log file, manipulating it and re-injecting the data back into any web server.

Implementation/Testing Phase: Testing Steps

Testing steps for virtual patches: (1) Implement virtual patches initially in a 'Log Only' configuration to ensure no normal user traffic is blocked (false positives); (2) If the vulnerability was identified by a specific tool or assessment team, request a retest; (3) If retesting fails due to evasions, go back to the Analysis phase to identify how to better fix the issue.

Recovery/Follow-Up Phase: Tracking and Documentation

During recovery/follow-up phase: (1) Update Data in Ticket System - although virtual patches may need expedited implementation, they should still be tracked in normal Patch Management processes with proper change request tickets documenting their existence and functionality; (2) Properly log the virtual patch rule ID values in the ticket system to help identify 'time-to-fix' metrics for different vulnerability types.

Recovery/Follow-Up Phase: Virtual Patch Removal and Reassessment

Periodic re-assessments should verify if and when virtual patches can be removed once the web application code has been updated with real source code fixes. However, many organizations opt to keep virtual patches in place due to better identification and logging capabilities compared to application or database capabilities.

Code Fixes and Virtual Patching are Not Mutually Exclusive

Code level fixes and Virtual Patching are not mutually exclusive processes. They are executed by different teams (OWASP Builders/Devs vs. OWASP Defenders/OpSec) and can be run in tandem, allowing for immediate protection via virtual patches while longer-term source code fixes are being developed.

Give your agent this brain