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.
Jeff - Great article. Even though this seems very straight-forward and common-sense, it's something I see companies struggle with every day. "I know I need to do something, but where do i start....?"
ReplyDeleteSomething I'd like to add, that I've seen many times, is complete support by 'the business' and upper management must exist. Without it, this type of effort most likely will 'die on the vine'. As you're well aware, developers are already heavily taxed as it is, so throwing the expectation of secure development must come from above, usually in the form of policies, etc.
One other requirement that makes the component you outlined successful is the commitment by the organization to address or remediate the vulnerabilities identified. Without that commitment, the organization is likely just uncovering and understanding risk to the organization without managing it...a failure of risk-management 101 and potentially opening themselves up to being pwned or even worse, legal action with something bad ultimately does happen. As your brother used to comment to me over and over, "It's about finding and fixing...".
Keep up the great work and be well.
Happy New Year!
Thank you for the kind words.
DeleteIndeed, convincing upper management of the importance of vulnerabilities can be a challenge.
I have found that the vulnerability severity categorization eliminates many arguments about actions.
The triage team needs to be aware of the "calling wolf" effect. If every issue is critical, then you will likely start to encounter resistance.
Make informal predictions about how many severe and critical vulnerabilities will be seen in a year. Later check those predictions. If you are seeing more criticals and severes then you desire, then start to reduce your threat surface or isolate or eliminate problematic components.
I just made a placeholder for myself for an article on managing management.
I have about 4-5 articles in the queue before that one though.