The Web Application Vulnerability Management Framework

Web Application Vulnerability Management continuously conducts security assessments against live, Internet facing web applications, identfying security bugs and remediating the risk. This framework introduces a methodology, processes, and activities to achieve that goal.

The web application vulnerability management framework has three domains: governance, verification, and construction. Each of these has a number of related practices, defined below.

Web Application Vulnerability Management Framework

Governance

Governance focuses on the processes and activities related to how an organization manages software development and application security. 

Policy

Security policy communicates the intentions of management for managing risk and enforcing security in the organization. It is the document that empowers the security team and gives them responsibility to perform application security.  

It outlines secure coding practices developers use to create software and the security requirements for commercial off the shelf (COTS) applications. These are the standards to be assessed against. When we find a vulnerability, the documented secure coding practices are referenced to give guidance to teams that need to fix the issue. 

Policy should contain remediation timelines. This tells various teams how long they have to get security vulnerabilities fixed. 

Inventory

Asset management is a prerequisite for vulnerability management. Before you can secure stuff, you need to know what stuff you have. It is helpful to know how many applications there are, where they are located both physically and logically on the network, who manages them, and what their value is.

Discovery is one of the first steps of the vulnerability management process, and is done through a combination of automated and manual processes. Discovery needs be recurring, so an updated inventory is maintained. 

Metrics

To know how effective the vulnerability management program is and determine if it is having an impact on software security, it needs to be measured. Metrics allow an organization to understand the performance of their security organization and weigh the costs of security safeguards against their effectiveness.

Metrics can inform policy. Data visualization, trending, and the high level view achieved through metrics allows management to make better decisions and shows us where our application security policy can be improved.

Verification

Verification is focused on the processes and activities related to how an organization checks and tests software. This is where our security assessments take place.

Enrollment

Enrollment has two activities. This is where we configure our dynamic application security testing (DAST) tool to assess an application. If the required information is not in our inventory, we may need to work with application owners to get it. 

Enrollment also includes notification and approval for security testing from stakeholders. Leverage your companies change management process if there is one already established.

Assessment

Continuous assessment is the core of the web application vulnerability management framework. This is where our DAST tool tests each web application on a continuous or frequently recurring basis as part of normal, business-as-usual operations. 

Reporting

Reporting consists of two parts: a report detailing the vulnerability, and leveraging the development teams defect tracking system for assignment of responsibility and tracking.

The vulnerability report should have general verbiage describing the vulnerability, include steps required to recreate the issue, screenshots of the affected functionality of the application, HTML or code snippets, and programming language specific remediation advice. If applicable, the report should link to applicable corporate secure coding standings and web based training. Providing this level of detail allows a developer to zero in on the problem, and review the related material if necessary.

Frame the vulnerability as a software defect, log it into the application’s defect tracking system, and assign it to a team or developer.

Construction

Remediation of an application vulnerability requires software development. While this is mostly done outside of the security organization, it is important to realize that each remediation effort can be seen as its own software development project. Construction concerns the processes and activities related to how an organization creates software.

Defect Tracking

Once reporting logs the vulnerability in the application team’s defect tracking system, both the application team and security team can use it for updates, tracking, and reporting on progress. Depending how many application teams the security organization has to interface with, it is possible to need to keep track of several disparate defect tracking system. The security team may need to maintain its own vulnerability tracking database that links to each teams defect tracking system.

Remediation

The hands on coding portion is done  by the application team. Depending on that team’s level of security knowledge, they need advice or training. After the security fix has been completed, the security team verifies that it properly addresses the vulnerability finding. This step often requires retesting with the DAST tool, along with additional manual testing. In the event that it is not completely fixed, go back to the analysis step of the remediation process to assess the best way to go forward. Only after this verification should the vulnerability be considered remediated and closed out in the appropriate defect tracking tools.