Self Service Secure Software Design

Application security is typically equated with security testing and performed at the end of the development process, which often proves to be both inefficient and costly. 

But not all security issues are simple bugs that can be identified through Application Security Testing (AST) tools. More complex flaws affecting the business logic or design of an application, for example, bypass of an approver process in a funds transfer operation, cannot be found through scanning alone. They require an analysis of the overall process. By starting security activities to the left of the development process, right at the design phase, security flaws can be found as early as possible, avoiding costly remediation.

Threat Modeling has emerged as a useful activity to help identify these more complex security design flaws.  There are several threat modeling techniques, though one of the most succinct and accessible to engineering teams is Adam Shostack’s four questions:

Collaborating on these four questions at design time, with input from developers, architects and security engineers, can help identify security and privacy issues and establish a plan to address them.  These questions not only serve the tactical goal of identifying security flaws but also helps engage the engineering team in a culture of thinking about security at the same time that they are designing the core features of their software.

A common pitfall within engineering teams occurs when questions like “what could go wrong” fall outside of the engineering domain, which then requires someone with a security background to provide an answer. Application security engineers are ideally placed to participate in threat modeling for this reason, but they are increasingly in short supply. The latest BSIMM 11 study found that the median ratio of full time software security group members to developers was 1 to 159. The question then becomes:  how do you scale the security knowledge of “what could go wrong” with a particular feature, to the wider engineering community?

Enter Threat Patterns
Threat patterns are documented security threats and countermeasures grouped together based on the feature to which they apply.  For example, single-factor login as a feature has a well-known set of threats and countermeasures, such as:

Threat 1: Attackers use brute-force and dictionary-based techniques to find the password for a given username.

Countermeasure 1: Enforce the use of strong passwords

Countermeasure 2: Implement anti-automation techniques to prevent rapid and repeated requests for the same function from the same source.

Threat 2: Attackers enumerate usernames

Countermeasure 3: Ensure that login responses never identify whether the username or the password was incorrect.

Countermeasure 4: Ensure that the time taken to respond to the request can’t be used to deduce whether the username or password are incorrect.

With a catalogue of patterns like this linked to the corresponding features and published to the engineering team, engineers just need to identify the features they’re building. The corresponding threats and countermeasures can simply be looked up in the threat pattern library. This avoids them having to spend valuable engineering time inventing solutions to already solved security patterns. More importantly it helps them to plan for, and build, the appropriate security controls right from the start.

This has a number of benefits:

Building a library of threat patterns opens the door to further automation of the secure design process through tooling that would not be possible with purely manual or traditional documentation-based techniques.  Tooling, even if it starts as a set of scripts, can dramatically reduce the cognitive load on engineering teams to avoid wading through reams of security standards and policy in order to answer the seemingly simple question of what can go wrong with what I’m building,  Helping engineers answer this question without having to constantly engage the security team brings us all closer to the goal of security becoming a seamless and integrated part of the normal development process for building high quality, robust software.

About the Author: Stephen de Vries, Cofounder & CEO, IriusRisk

Stephen is the co-founder and CEO of IriusRisk, the industry leading self service threat modeling platform that helps engineering teams design secure software. He has published numerous original research papers and presented at conferences such as Blackhat USA/Europe, DevOps Connect, O’Reilly Security and OWASP. He is a founding leader of the OWASP Java Project and contributor to OWASP ASVS and testing projects. In previous roles as an application security consultant he was responsible for leading security assessments, code reviews and delivering training courses for FTSE 100 clients.