Michael Gegick

Identifying security bug reports via text mining: An industrial case study

A bug-tracking system such as Bugzilla contains bug reports (BRs) collected from various sources such as development teams, testing teams, and end users. When bug reporters submit bug reports to a bug-tracking system, the bug reporters need to label the bug reports as security bug reports (SBRs) or not, to indicate whether the involved bugs are security problems. These SBRs generally deserve higher priority in bug fixing than not-security bug reports (NSBRs). However, in the bug-reporting process, bug reporters often mislabel SBRs as NSBRs partly due to lack of security domain knowledge. This mislabeling could cause serious damage to software-system stakeholders due to the induced delay of identifying and fixing the involved security bugs. To address this important issue, we developed a new approach that applies text mining on natural-language descriptions of BRs to train a statistical model on already manually-labeled BRs to identify SBRs that are manually-mislabeled as NSBRs. Security engineers can use the model to automate the classification of BRs from large bug databases to reduce the time that they spend on searching for SBRs. We evaluated the models predictions on a large Cisco software system with over ten million source lines of code. Among a sample of BRs that Cisco bug reporters manually labeled as NSBRs in bug reporting, our model successfully classified a high percentage (78%) of the SBRs as verified by Cisco security engineers, and predicted their classification as SBRs with a probability of at least 0.98.

Prioritizing software security fortification throughcode-level metrics

Limited resources preclude software engineers from finding and fixing all vulnerabilities in a software system. We create predictive models to identify which components are likely to have the most security risk. Software engineers can use these models to make measurement-based risk management decisions and to prioritize software security fortification efforts, such as redesign and additional inspection and testing. We mined and analyzed data from a large commercial telecommunications software system containing over one million lines of code that had been deployed to the field for two years. Using recursive partitioning, we built attack-prone prediction models with the following code-level metrics: static analysis tool alert density, code churn, and count of source lines of code. One model identified 100% of the attack-prone components (40% of the total number of components) with an 8% false positive rate. As such, the model could be used to prioritize fortification efforts in the system.

Matching attack patterns to security vulnerabilities in software-intensive system designs

Fortifying software applications from attack is often an effort that occurs late in the software development process. Applying patches to fix vulnerable applications in the field is a common approach to securing applications. Abstract representations of attacks such as attack trees and attack nets can be used for identifying potential threats before a system is released. We have constructed attack patterns that can illuminate security vulnerabilities in a software-intensive system design. Matching our attack patterns to vulnerabilities in the design phase may stimulate security efforts to start early and to become integrated with the software process. The intent is that our attack patterns can be used to effectively encode software vulnerabilities in vulnerability databases. A case study of our approach with undergraduate students in a security course indicated that our attack patterns can provide general descriptions of vulnerabilities. The students were able to accurately map the patterns to vulnerabilities in a system design.

Predicting Attack-prone Components

Limited resources preclude software engineers from finding and fixing all vulnerabilities in a software system. This limitation necessitates security risk management where security efforts are prioritized to the highest risk vulnerabilities that cause the most damage to the end user. We created a predictive model that identifies the software components that pose the highest security risk in order to prioritize security fortification efforts. The input variables to our model are available early in the software life cycle and include security-related static analysis tool warnings, code churn and size, and faults identified by manual inspections. These metrics are validated against vulnerabilities reported by testing and those found in the field. We evaluated our model on a large Cisco software system and found that 75.6% of the systems vulnerable components are in the top 18.6% of the components predicted to be vulnerable. The models false positive rate is 47.4% of this top 18.6% or 9.1% of the total system components. We quantified the goodness of fit of our model to the Cisco data set using a receiver operating characteristic curve that shows 94.4% of the area is under the curve.

On the design of more secure software-intensive systems by use of attack patterns

Retrofitting security implementations to a released software-intensive system or to a system under development may require significant architectural or coding changes. These late changes can be difficult and more costly than if performed early in the software process. We have created regular expression-based attack patterns that show the sequential events that occur during an attack. By performing a Security Analysis for Existing Threats (SAFE-T), software engineers can match the symbols of a regular expression to their system design. An architectural analysis that identifies security vulnerabilities early in the software process can prepare software engineers for which security implementations are necessary when coding starts. A case study involving students in an upper-level undergraduate security course suggests that SAFE-T can be performed by relatively inexperienced engineers who are not experts in security. Data from the case study also suggest that the attack patterns do not restrict themselves to vulnerabilities in specific environments.

Toward Non-security Failures as a Predictor of Security Faults and Failures

In the search for metrics that can predict the presence of vulnerabilities early in the software life cycle, there may be some benefit to choosing metrics from the non-security realm. We analyzed non-security and security failure data reported for the year 2007 of a Cisco software system. We used non-security failure reports as input variables into a classification and regression tree (CART) model to determine the probability that a component will have at least one vulnerability. Using CART, we ranked all of the system components in descending order of their probabilities and found that 57% of the vulnerable components were in the top nine percent of the total component ranking, but with a 48% false positive rate. The results indicate that non-security failures can be used as one of the input variables for security-related prediction models.

Toward the Use of Automated Static Analysis Alerts for Early Identification of Vulnerability- and Attack-prone Components

Extensive research has shown that software metrics can be used to identify fault- and failure-prone components. These metrics can also give early indications of overall software quality. We seek to parallel the identification and prediction of fault- and failure-prone components in the reliability context with vulnerability- and attack-prone components in the security context. Our research will correlate the quantity and severity of alerts generated by source code static analyzers to vulnerabilities discovered by manual analyses and testing. A strong correlation may indicate that automated static analyzers (ASA), a potentially early technique for vulnerability identification in the development phase, can identify high risk areas in the software system. Based on the alerts, we may be able to predict the presence of more complex and abstract vulnerabilities involved with the design and operation of the software system. An early knowledge of vulnerability can allow software engineers to make informed risk management decisions and prioritize redesign, inspection, and testing efforts. This paper presents our research objective and methodology.

Failure-prone components are also attack-prone components

Limited resources preclude software engineers from finding and fixing all security vulnerabilities in a software system. A predictive model that identifies which components are attack-prone can prioritize fortification efforts where they are needed most. We have analyzed two large commercial telecommunications systems that have been deployed to the field. We have found strong correlations (as high as 0.82) between non-security failures and security failures and that the most failure-prone components are likely to be attack-prone. Additionally, non-security failures were found to be a good metric for estimating the count of security failures for a given software

Protection Poker: Structuring Software Security Risk Assessment and Knowledge Transfer

Discovery of security vulnerabilities is on the rise. As a result, software development teams must place a higher priority on preventing the injection of vulnerabilities in software as it is developed. Because the focus on software security has increased only recently, software development teams often do not have expertise in techniques for identifying security risk, understanding the impact of a vulnerability, or knowing the best mitigation strategy. We propose the Protection Poker activity as a collaborative and informal form of misuse case development and threat modeling that plays off the diversity of knowledge and perspective of the participants. An excellent outcome of Protection Poker is that security knowledge passed around the team. Students in an advanced undergraduate software engineering course at North Carolina State University participated in a Protection Poker session conducted as a laboratory exercise. Students actively shared misuse cases, threat models, and their limited software security expertise as they discussed vulnerabilities in their course project. We observed students relating vulnerabilities to the business impacts of the system. Protection Poker lead to a more effective software security learning experience than in prior semesters. A pilot of the use of Protection Poker with an industrial partner began in October 2008. The first security discussion structured via Protection Poker caused two requirements to be revised for added security fortification; led to the immediate identification of one vulnerability in the system; initiated a meeting on the prioritization of security defects; and instigated a call for an education session on preventing cross site scripting vulnerabilities.

Ranking Attack-Prone Components with a Predictive Model

Limited resources preclude software engineers from finding and fixing all vulnerabilities in a software system. An early security risk analysis that ranks software components by probability of being attacked can provide an affordable means to prioritizing fortification efforts to the highest risk components. We created a predictive model using classification and regression trees and the following internal metrics: quantity of Klocwork static analysis warnings, file coupling, and quantity of changed and added lines of code. We validated the model against pre-release security testing failures on a large commercial telecommunications system. The model assigned a probability of attack to each file where upon ranking the probabilities in descending order we found that 72% of the attack-prone files are in the top 10% of the ranked files and 90% in the top 20% of the files.