Threat Modeling is Table Stakes for Security

Table-stakes security often means a checklist to get the security team off the back of the web team. This approach is weak from every perspective: a frustrating web and security collaboration process, vulnerability to excessive spending with security vendors and loose credential hygiene. A holistic threat modeling approach — centering collaboration and effectiveness — can redefine table stakes to everyone’s benefit.

Here are four common approaches followed by tips to center threat modeling.

Checklists often approach security through discrete tasks. Use a VPN. Enable the firewall. Update your software. These steps can be valuable, but overreliance mitigates unrealistic threats while ignoring tangible ones. Inflexible checklists frustrate development teams with irrelevant or misguided requirements, creating friction between security and implementation teams.

Tip 1: Limit the proliferation of checklist items and retain openness to alternatives. For handling alternatives, consider how PCI DSS approaches compensating controls.

Vendors can also exploit checklist approaches. When a requirement looks like “have a WAF with rate limiting,” two bad things happen. First, it’s unclear what the WAF is supposed to be mitigating, allowing slapdash rulesets that check the “WAF with rate limits” box but may not evolve to meet relevant threats. Second, it creates regulatory capture (even in private organizations) by creating “needs” that are satisfiable by a narrow range of products — products which companies position themselves to sell. Some checklists are so sales-influenced that it’s possible to tell which vendors wrote the requirements.

Tip 2: Be skeptical of vendors insisting they have solutions you need. Instead, press them for the threats they think you face. Incorporate plausible threats into a broader exercise that balances threats against one another by likelihood and impact. Adapt threats into abstract requirements like “address OWASP Top 10 vulnerabilities and denial-of-service attacks” alongside suggested mitigations. Rather than merely mitigating the chance of success, also reduce the impacts of a successful compromise with approaches like restricting which systems handle personally identifiable information (PII).

Attacks today often rely on weak or leaked credentials and social engineering, and checklists aren’t good at preventing these, either. Pantheon reduces the risk for its customers by integrating with SSO providers and simplifying (and centralizing) access control changes that might otherwise be forgotten. It’s always easy to identify when necessary access is missing; it’s much harder to clean up stale SSH keys and other authorizations.

Tip 3: Start by mapping who has access to what data and resources, considering the worst that could be done with that access. For sensitive systems, implement the least access to reduce the harm a malicious or tricked human can cause. Finally, adopt a well-defined, sustainable user lifecycle management process — even if it’s managed on paper or a spreadsheet.

The worst impact of checklist-oriented solutions is poor outcomes. Today’s supply chain attacks and complex stacks make the combined system vulnerable in ways invisible to discrete controls. For example, the way two HTTP layers integrate can create risk even when either system alone is safe. Privileged systems can get tricked almost like humans. Supply chain attacks leverage access to a less-secure, early system to plant a compromise that will propagate to later, deployed systems.

Tip 4: Identify the ultimate value of each compromise. Office Wi-Fi may not be that valuable attacking your infrastructure (making WPA3-Enterprise a misplaced investment). A highly privileged continuous integration (CI) system might be missing multifactor authentication, creating a large and risky backdoor. In general, review the assumptions individual systems make about the behavior of adjacent infrastructure. Security that seems redundant (e.g. two different layers that both homogenize inbound HTTP requests) can even interact pathologically and introduce vulnerabilities.

When shaping your organization’s table-stakes security, there’s a limited budget for time and cost. Threat modeling may seem like a distraction unsuitable for an organization’s first security efforts, but it’s really a method for focusing limited resources. Understanding risks and impacts — and using the results to shape security strategy — can make the difference between checks on an attacker’s ability to compromise key systems versus checks on a spreadsheet.