This article “What to Threat Model -- For CISOs” is part of the What to Threat Model series.
Author: John Steven
When organizations consider adding threat modeling activity to their software security initiative, a common worry is, "Do I have to cover every application? All the infrastructure?" The number one concern heard over the years is, "I'm not sure I have the staff, let alone qualified staff, to take this on… " Organizations address this concern by prioritizing their portfolios and threat model that which is perceived most valuable. How should organizations think about what to threat model?
Model the Full Stack
Organizations should threat model those essential applications and infrastructure alike, it's not sufficient to do only one or the other. Each provides its respective piece of the total model: modeling the application is vital because that’s where business logic and assets are. And, increasingly, infrastructure views help define a model's surfaces, security properties, and controls rather than developer logic. From a risk-management perspective, application and infrastructure modeling are inseparable: application business logic relies on platform and infrastructure for security posture and platform and infrastructure rely on application modeling for business context and impact assessment.
Which comes first: Infrastructure or Application?
If an organization is moving several key business applications to a new delivery platform, prioritize threat modeling that platform so that its properties can be well-understood for application-level modeling. Focus on diagramming and documenting that platform infrastructure's attack surfaces, security guarantees (compartmentalization, least-privilege, data confidentiality or integrity, etc.), as well as security controls. Is the platform "next gen" app delivery for the organization? If so, compare those properties proposed by the ng-platform to the previous generation's offerings. Communicate and track what undue challenges infrastructure leaves for application development/delivery.
When documenting infrastructure security properties, save risk management activities for the application-specific models built on that infrastructure. When modeling applications, take the infrastructure model as input and context and add to it view of assets, adversaries, and key risks to be avoided. Communicate and track risks and mitigations to the appropriate responsible party, be it application and infrastructure, and always within the context of the application's business value.
What does 'Portfolio Coverage' Look Like?
When CISOs commit to threat modeling as an organizational control, the question is always "What constitutes 'the whole portfolio [of apps and infrastructure]?' The way organizations count applications differs wildly, but organizations to fall into buckets:
- Single-SaaS Providers: 3-10 applications
- SMB: 30-50 applications
- Mid-market: 300-400 applications
- Fortune 500 and conglomerate: Up to 3000 applications
Maturing organizations consistently set a 36-month target for "All Apps", but it's probably more realistic to say that those organizations will staff and update threat models for about 50% of their portfolio in that time frame. More often than not, the remaining 50% are left uncovered because they're deemed too 'low risk' to be a valuable exercise, rather than due to a lack of bandwidth.
The apparent lack of 'total coverage' is mitigated when low-risk applications benefit and act on findings from high-risk applications, and from more threat modeling of common underlying infrastructure. Organizations believe, "If low-risk applications remediate flaws they share with high-risk applications and the infrastructure is least privilege and compartmentalized then penetrate and pivot for low-to-high risk applications is less viable."
Regardless of maturity level, organizations set a 12-month target for 10% of their portfolio. Whether that represents one application or hundreds, this percentage is a proxy for "those applications on the critical path to business/revenue-generating transactions." Organizations find their first sets of threat models the hardest to conduct. Each completed threat model pays dividends to subsequent modeling: infrastructure and platforms are increasingly understood and serve as reusable assets.
How Much is Enough?
Whether couched as "what does a 'complete' threat model look like?" or "How much is enough threat modeling for a particular app or infrastructure?" the question informally is "what does 'secure enough' look like when conducting a threat model?" We'll cover this topic in-depth in subsequent material, but a good rule of thumb is: for each major release of software or system, make sure the threat model prioritizes and considers, then explicitly accepts or addresses the risk of about 10-12 potential flaws. Whereas the heuristics above contend with measuring the amount of apps, or infrastructure (organizational assets), this metric is tuned to "the amount of risk discovered and considered" by IT asset.