AppSec Europe 2014

Despite many publications and presentations detailing threat modeling and, more generally - Architectural Risk Analysis (ARA) techniques, and widely accepted notion that it is so much cheaper to deal with security issues proactively and upfront, rather than reactively in already released applications, many software development teams still have not embraced ARA as a mandatory part of their SDLC. Why is it so, if the benefits are so obvious? Because establishing ARA as a regularly practiced activity is a very complicated process, and existing industry materials and methodologies do not help development teams make this transition any smoother. This presentation, based on first-hand experiences and observations from introducing ARA into SDLC, will describe the many obstacles to broad adoption of ARA in a software development company as an integral element of regular product development cycle.

The reasons for the existing situation are plenty, ranging from mindset of software engineers, to lack of security-related culture, and to shortage of sufficiently skilled security professionals. Instead of trying to tackle these challenges, many companies aim to placate customers' security assurance demands by going down the easier route of "testing security in" and contract security verification out to external vendors. These problems may be attributed to inertia and general lack of understanding of how to write secure software.

Unfortunately, there are many problems with the threat modeling and ARA methodologies themselves, which complicate their adoption as proactive defense mechanisms. There are no commonly accepted methods to calculate Return on Investment (ROI) of such programs, and senior management, with very few exceptions, remain skeptical when asked to further burden already strained development teams. In the best case, they may tolerate it, but support is far from guaranteed. The concepts and skills, required for practicing those methodologies, remain foreign to regular developers, who have difficulties transitioning from functional into attacker mode of thinking. Broad developers education is challenging because the software industry as a whole has so far failed to produce any meaningful materials on attack patterns that could be relatively easily introduced into software development process. There are efforts under way, but some of them are too academic in nature, while others are way too broad and

inconsistent, making the end result unsuitable for practical applications. This stands in sharp contrast to the reactive mechanism of vulnerability alerts practice, which relies on well established and commonly used vulnerability data sources.

As a result, despite lots of talk about great importance of ARA, and quite a few years after introduction of the concept into the applied software development discipline it remains more of an art than a trade. ARA and threat modeling are still practiced by relatively small and exquisite groups of dedicated security professionals, either within Software Security Groups (SSGs) in large companies, or by highly specialized consultancies.

This presentation will look at the key ingredients necessary for establishing a successful ARA program in a software development organization, recognizing the limitations and obstacles described earlier. The process of bridging the current knowledge gap requires close cooperation of both development and security teams, so the presentation will be particularly useful for development managers and architects involved into implementation of SDLC within software development organizations, as well as application security professionals dealing with software development teams. Finally, we will also discuss specific examples of what is lacking in the currently available public materials for threat modeling/ARA and how this situation could be improved to make those materials more applicable as part of the regular software development process.