This is the first in a series of articles about building a secure software engineering shop. These articles are applicable either to traditional dev shops creating software or to shops hosting software or services in the cloud.
Inevitably, there are vulnerabilities in code. To avoid confusion in the organization, vulnerabilities must be prioritized and worked just like any other issue. This is the core to building secure software.
Step One: Gather data and assign severity
This is the most important step. There is always a cone of uncertainty around every vulnerability. The team should gather the evidence and determine severity.
Enhance the issue tracking system to track vulnerabilities as a special case of defect. Assign a severity to any vulnerability tracked. Keep it simple; five severities level are enough:
- Critical - Any vulnerability that results in remote code execution or denial of service. Examples include ShellShock and Heartbleed.
- Severe - Any vulnerability that results in remote code execution or denial service, but has mitigations. Examples include POODLE (disable SSLv3) and BEAST (disable CBC ciphers).
- Important - Any vulnerability that allows an attacker to escalate his privileges. Examples include an XSS attack against management users, or an XSRF that allow a lower privileged user to escalate their privileges.
- Minor - Similar to Important, but mitigations may be in place. This could also be an information leak or other relatively minor issue.
- Not Vulnerable - This is self explanatory, but is a good way to track a vulnerability and the work that has been done to identify and research it.
Track all vulnerabilities by a unique number; CVE numbers work well. See a later article for information on fetching CVE identifiers and working with vulnerability databases.
Assign CVSS scores to all vulnerabilities. This can help clarify the response.
Step Two: Respond based on severity
Once a vulnerability severity is assigned, actions should be clear based on policy. The policy needs to written and understood by the entire organization. For example, a critical vulnerability invokes an immediate change window. A severe vulnerability invokes a mitigation change request; possibly scheduled for the next change window. An important issue must be fixed within the next month. All vulnerabilities in a software distribution should be documented externally with mitigation information and recommendations for avoiding the issue.
Step Three: Enforce the policy
Build reports so that all engineers and managers will know the importance of an issue. Priority should be assigned based on the severity. That priority should be understood by all parties.
Step Four: Gather metrics
Gather data about which vulnerabilities are deferred or incomplete. Track where in the code vulnerabilities are found. Escape analysis or root cause analysis should be performed on all severe or higher vulnerabilities. This information should feed back into the dev and test cycle.
Using these principles should greatly reduce confusion, improve communication and increase productivity when vulnerabilities arise.