Getting Started with Application Risk Management

Getting Started Guide

Veracode is the only on-demand provider in the marketplace to offer its customers a full application risk management solution, including application inventory definition and an application security policy that includes multiple analysis methods and standard security ratings.

Application Risk Management

Risk management is the process that allows IT managers to balance the operational and economic costs of protective measures and achieve gains in mission capability by protecting the IT systems and data that support their organizations' missions. Overall risk management encompasses three processes: risk assessment, risk mitigation, and evaluation and assessment. The following steps detail best practices for implementing a successful software risk management program.

Step 1 - Application Risk Assessment: Assess Business Criticality across Portfolio

While it may seem obvious that as part of a risk assessment organizations need to create a portfolio of their applications that are being developed, purchased, or maintained by an outsourcing provider, in practice it is a challenging exercise. With the advent of low-cost offshore development, open source and low-cost commercial software it is common to see application "sprawl" as individual groups or business units may have contracted work that previously would have required higher capital costs and formal approvals. When conducting an application inventory, involve business units, procurement and vendor management to ensure all software that was or is entering the organization has been identified.

Once applications have been identified, organizations need to understand the risk that the application poses to the business. This can be achieved through the assignment of a business criticality for each application based on business risk factors such as: reputation damage, financial loss, operational risk, sensitive information disclosure, personal safety, and legal violations. Business Criticality is used to determine the extent of testing methods (e.g. more business critical applications may be tested using multiple techniques) and the overall acceptance criteria (e.g. lower criticality applications may be accepted with lower security scores as they do not pose a significant risk to the business).

Step 2 - Define Application Security Policies

The business criticality selected for an application determines the application security policy required for the application. Defining an application security policy consists of the following steps:

  1. Select Appropriate Analysis Methods and Scanning Frequency
  2. Use Industry Standard Security Scores
  3. Define Appropriate Remediation Periods
Selecting Appropriate Analysis Methods

Higher assurance applications require more comprehensive analysis to accurately score their security quality. Because each analysis technique (automated static, automated dynamic, manual penetration testing or manual review) has differing false negative (FN) rates for different types of security flaws, any single analysis technique or combination of techniques will produce a certain level of false negatives. Some false negatives are acceptable for lower business criticality applications, so a less expensive analysis using only one or two analysis techniques is acceptable. At higher business criticality the FN rate should be close to zero, so multiple analysis techniques are recommended.

As shown below, higher assurance applications require multiple testing techniques in order to provide an acceptable level of risk to the organization.

As the business criticality of an application increases, multiple analysis techniques should be used to assess its security quality.

Using Industry Standard Security Scores

Until recently, each security solution provider assessed the severity of vulnerabilities according to their own, proprietary system. This led to discrepancies between products and services, and limited the value of security assessments. In 2005, a coalition of security experts created the Common Vulnerability Scoring System (CVSS), a vendor-agnostic standard for communicating the severity of vulnerabilities to help businesses prioritize decisions about which flaws to fix.

Veracode combines the CVSS for severity and ease of exploitability with other industry standards, including MITRE's Common Weakness Enumeration (CWE) for classification of software weaknesses to provide an overall application security rating. Veracode is the only organization to combine these standards into a meaningful and practical way to assess software security across internally and externally developed applications.

To determine a Security Quality Score (SQS) the severities of all security flaws are aggregated and normalized to a scale of 0 to 100, where 100 is a perfect score. The score generated by a particular type of testing (automated static, automated dynamic, or manual) and the application's assurance requirements are then used to compute the application's Veracode Level for each testing technique.

Set Policies for Acceptable Thresholds

Veracode provides an overall Veracode Level based on the Security Quality Score (SQS), severity of flaws found, and scans performed, in the form of a simple to understand level from Veracode Level 1 to Veracode Level 5. This provides businesses with the ability to set policies for acceptable thresholds based not only the number and severity of vulnerabilities in the software, but the risk that application poses to the business.

The Veracode Level (VL) achieved by an application is determined by type of testing performed on the application, and the severity and types of flaws detected. A minimum security score is also required for each level.

Select an appropriate application for scan

When deciding which applications to scan, consider Veracode's supported languages and platforms for static scans and the guidelines for DynamicDS scans.