Term of the Week: Threat Modeling

Why does a business professional need to know this?

Threat modeling assesses, architects, and designs security into software, avoiding many vulnerabilities and reducing the severity of others. Techniques used in threat modeling, such as attack surface analysis and reducing unnecessary elevation of privilege, can avoid thousands of vulnerabilities at once, without having to find and fix them individually.

Business professionals should know about threat modeling because it is the single secure software design practice used by all SAFECode members. The Software Assurance Forum (SAFECode) is a non-profit organization exclusively dedicated to increasing trust in information and communications technology products and services through advancement of effective software assurance methods(Simpson 2008).

Developers who do not use threat analysis often fail to create secure-by-design software, leading to poor security quality. Architectural threat analysis and modeling significantly increase robustness and resilience, dramatically reducing the number and severity of vulnerabilities(Diamant 2011).

A threat analysis of Linux software avoided more than 100 vulnerabilities, which required security patches or updates to be developed, tested, released, and installed, all at a significant cost to the developer and software users(Diamant 2011). Despite the cost, this was the best-case scenario. The worst case would have been a serious data breach, such as the Equifax breach, which exposed Social Security numbers and other sensitive information for more than half of the U.S. adult population, rendering Social Security numbers obsolete as a security measure, costing the CEO his job, and enabling countless identity thefts.

Threat analysis and modeling should be preceded by a security requirements gap analysis to identify missing or incompletely addressed security requirements and controls. This ensures that those conducting the threat analysis understand the security requirements and controls required to enable appropriate security properties(Diamant 2017).

We need to apply the lessons from past decades that tell us that quality (and thus security) must be designed in, and we can’t expect to simply test it out. Although software developers sometimes do threat modeling without specific, or only brief, training, this practice is analogous to do-it-yourself surgery. To avoid a false sense of security, have independent experts perform risk analysis and threat modeling.