Predicting Security Vulnerabilities in Software Components
Many predictive models have been constructed to estimate the reliability of software systems and even individual software components, but the extension of modeling/prediction techniques into software security is not nearly as advanced. In large systems, it is often impractical to conduct full threat modeling, code security inspection, penetration testing, etc., but these security assurance activities must be done for portions of the systems (components) that are found to be, or suspected to be, highly security-vulnerable. Therefore, a predictive method is needed to allow developers to target security-focused practices for the most vulnerable portions of the code.
Our current reliability predictive work mostly relies on linear and nonlinear regression models (followed by discriminant analysis and ranking), but we see no reason to restrict this work to only these regression options. Furthermore, there is some internal evidence that neural networks or Bayesian networks may be more useful modeling approaches for this type of investigation.
For the predictive models, it is more desirable to incorporate independent variables that have what are believed to be strong physical relationships to security vulnerability, and not variables that are more generic in nature. For example, it is more desirable for a model to use static analysis security warnings and code security inspection data as independent variables, rather than complexity, unit test data, etc. We believe that we will find stronger correlations between security-focused variables and the dependent variables of interest, such as security advisories, alerts, and security release notes. These independent variables can also serve as early in-process indicators of problems, and can more easily point to specific practice steps or changes to improve downstream results. Also, we believe that tighter physical links between in-process and downstream data will help us in motivating the developers to invest the time needed to adequately analyze and then remedy individual problematic components. We may need to incorporate several generic independent variables, but will include these only if the physically-linked variables prove to be inadequate.
It is also desirable to characterize the vulnerabilities according to both the ease of attack and the relative or quantitative impact of the attack (i.e., the value of the targeted asset), using a DREAD-like approach. (DREAD is a method to characterize security risks - see Writing Secure Code, Microsoft Press, 2003.) The specificity of the independent and dependent variables available in our databases may not allow this, at least at the project start, but we may be able to design an ease/impact experiment, using a subset of existing data, that can later allow us to incorporate ease/impact data into the modeling exercise.
We invite modeling/prediction research that will enable us to identify the subset of Cisco software components that is believed to be most vulnerable to security problems. The earlier in the lifecycle these predictions can be made, the better, so early in-process independent variables are preferable. Internal research is currently in progress, so a collaborative approach is needed.
Constraints and other information:
This project requires Cisco and the university to enter into two legal agreements. A Cisco standard non-disclosure agreement (NDA) will apply to Cisco proprietary data, such as defect information. A Cisco standard sponsored research agreement (SRA) will apply to the project. This SRA will: allow publication of the research findings, give ownership of the new intellectual property to the university, allow Cisco and the university to retain ownership of their existing intellectual property, grant Cisco royalty-free, non-exclusive licenses, create a process for negotiating exclusive licenses, and include other terms and conditions.
Please use the link below to submit a proposal for research responding to this RFP. After a preliminary review, we may ask you to revise and resubmit your proposal.
RFPs may be withdrawn as research proposals are funded, or interest in the specific topic is satisfied. Researchers should plan to submit their proposals as soon as possible. The deadline for Submissions is the Friday of the first week of each calendar quarter (the months of January, April, July, October). Funding decisions and communication will occur within 90 days from the quarterly submission deadline. The usage of funding is expected within 12 months of funding decision. Please plan your requests accordingly.
Questions? Contact: email@example.com