“Moving to The Left”: Getting Ahead of Vulnerabilities by Focusing on Weaknesses
No ratings
Presented at FirstConferenceKualaLumpur 2018 by
If I have learned anything from nearly thirty years of CSIRT experience, it is that the number and complexity of vulnerabilities continue to grow as fast as (or faster than) our plans to deal with them. We continue to develop and improve tools for vulnerability management, classification, analysis, communication and so on, but these are all merely coping strategies. There will always be water in the basement, no matter how fast we run the pump (nor how many pumps we put into service). Just as health professionals move beyond epidemics and infected individuals to improvement of environments and lifestyles that lead to less disease and improved quality of life, so do we need to shift our focus away from vulnerabilities and onto the conditions that allow them to exist. All vulnerabilities depend on the existence of one or more weaknesses, usually in coding or design. The inverse is not true; not all weaknesses result in vulnerabilities. However, because of the former relationship, if we remove or reduce weaknesses, we get vulnerability elimination for free as a side effect. In this one-hour presentation, I will explain this concept and walk the attendees through the structure of the Common Weakness Enumeration. I will give concrete examples of improvements that come with weakness identification and analysis. Shortly after changing jobs from the Juniper SIRT to the Juniper Secure Development Lifecycle program nearly five years ago, I instigated modifications to Juniper’s problem reporting system, GNATS, so that weaknesses could be identified as as part of PR management and CWE labels could be assigned to individual flaws. The grouping of individual weaknesses into larger groups enables trending and analysis. It has become a fundamental part of our penetration testing reports and the results allow us to target certain failures in coding and design. In particular, managers and directors are empowered by the results to implement changes in training requirements and shift focus on bug resolution, for two examples. Separately, without regard to specific products, by studying large numbers of CWE labels attached to a variety of problem reports from across our entire development organization, I have produced a “Top Ten Weaknesses Report” for all but 2017. By comparing to industry trends, we can quickly identify where we are consistent with our vendor peers and take advantage of already-available resources for improvement. We can also see where we diverge from our peers and take action on our own to implement improvements. Next, I will help attendees with tips and tricks for mapping specific findings to a range of CWE labels, help identify which may be the “best” label with regard to grouping and trending analysis, and also show the interplay between CWE, CVE and CAPEC labels. Lastly, I will offer some prognostications on the future of the CWE project and weakness study and processing in general. For any PSIRT with a nascent SDL function, this is a matter of survival. By “moving to the left” – getting ahead of software development coding and into the earlier design phases – a focus on weakness pays real dividends in reducing the overall incidence of vulnerabilities. And that, as we well know, keeps costs down by “vulnerability containment”, keeping flaws from escaping into customers’ networks.