"Security is a process, not a product" -Bruce Schneier, Cybersecurity expert

As mentioned in a previous blog, according to statistical studies led by Dr. Gary McGraw at Cigital, half of all security vulnerabilities in systems are due to coding errors – bugs, but the other half are design flaws which can only be proactively discovered and prevented through the threat modeling (or architecture risk analysis) process. The alternative is embodied by several high-profile vulnerabilities announced recently – POODLE and Shellshock.

Both of these vulnerabilities were due to features added to base functionality to either simplify use for backwards compatibility (POODLE) or to extend capability for administrators (Shellshock) – without considering the security consequences of these features, especially as the feature aged and attack vectors changed.

A secure software development lifecycle (SSDLC) process includes threat modeling or architecture risk analysis as part of the design review stage of the development lifecycle – preferably before any code is written.

There are two primary threat modeling approaches – adversarial and defensive. The adversarial approach involves after-the-fact analysis, such as security code review or penetration testing. While this approach may provide impetus to jump-start a secure software development lifecycle program, by exposing vulnerabilities which exist in the application, it is a purely reactive (and hence expensive) approach. It often results in the rewriting of code and in “bolted on security” rather than security by design.

You cannot build secure systems until you understand your threats.” -Michael Howard, Microsoft SDLC co-developer

More mature approaches call for defining the attack surface of the application or system, then looking for possible threats against that surface. Alternately, one can list and classify the assets that the application or system will have access to, and thus needs to protect, then look for threats against those assets.

For each threat identified, one then needs to come up with a mitigation to the threat from the commonly used toolkit of security functions – authentication, authorization, encryption, integrity validation, auditing, and reliability. Here is where the all-important threat question “What can an attacker do with this?” is answered by “Doing this is how we prevent the attacker from doing that.”

A good threat modeling approach must not just look at threats and their mitigation, but also must quantify the risk that the threat could be realized. This risk-based approach looks at both the value of the asset and the probability of a successful attack to prioritize mitigating the threats which have the highest risk first.

Experience has shown that often a mitigation applied for one threat will also mitigate a threat in a different area, or for a different asset, if the mitigation is applied centrally through the application or system. For instance, requiring all network communications to utilize a secure protocol such as TLS or SSH, will mitigate any occurrence of information leakage when data is transmitted, while requiring all data residing on disk to be encrypted will mitigate any occurrence of information leakage while data is stored. Similarly, requiring the use of OWASP, OWASP Java or Microsoft Anti-Samy libraries for sanitizing all web traffic will mitigate all occurrences of XSS (Cross-Site Scripting) vulnerabilities.

Once mitigations have been implemented, it is important to verify that they are working properly; so either the above-mentioned penetration testing or other automated functionality tests (including misuse cases) should be run. Any negative findings either need to be fixed and retested, or accepted as residual risk by the product owner or product manager, and then added into the workload for the next release.

Threat models should be revisited any time there are major changes introduced, these could include changes in the feature sets, assumptions made in the threat model, or new threats or risks are discovered.

Ensuring that the implementation of a feature or functionality is secure by design will go a long way in securing our systems and hence our customers.