This brings with it several issues that I am sure many of you have dealt with if you have performed a threat model.
1. You deal with inconsistent threat modeling. This is due to the skill issue. You can have a situation where a team may be producing great, deep threat models because they are
skilled at identifying threats and in other situations, you might have terribly generic and dare I say, useless threat models that are of no good to anyone.
2. This could be worse. You might be dealing with a wildly incomplete Threat Model masquerading as a complete one. It might be missing entire categories of risks based on components, data flows and more. This is dangerous because it creates a false sense of security and coverage.
3. This inherently comes with a scaling problem. This creates an issue where Threat Models NEED to be executed by the Security Team or Security Architecture Team. They are likely to be a small team that is inundated with Threat Modeling requests from hundreds of teams.
Its not as if there are no techniques to help you solve this. There are a few well known techniques like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation Privilege) and the privacy-oriented Threat Modeling technique, LINDDUN (Linking, Identifying, Non-repudiation, Detecting, Data Disclosure, Unawareness and Non-compliance)
These help. For sure. In fact, earlier on in my career, I used to really spend a good deal of time using STRIDE as the primary technique to coax my mind to think about threat scenarios by category of STRIDE. This helped me greatly mature as a security professional. But as time passed and systems got more complex. I started to feel that this became inadequate. I felt that STRIDE addressed the “categories” of threats by classifying them into certain categories. But, I felt that there was really not a good way to help me “find them” in the first place. And by “finding them” I mean, allow me to enumerate them by domain or by examining and breaking down a given system.
This is when I came up with PWNISMS. It’s been around 3 years now since I came up with this and I have used this for over 700+ Threat Models to great effect. In fact, I have seen that this methodology helps me perform better Threat Models using AI and Large Language Models (LLMs). The reason I came up with this, over many other threat enumeration libraries is that it fits with the following parameters:
1. Its full-stack. It considers threats across all layers of an application or system stack.
2. It provides a great deal of domain coverage across multiple typically under-represented threat domains like Monitoring and Supply-Chain, which we as humans are typically bad at thinking about.
3. It fits well with STRIDE and can be used without STRIDE.
4. It works really well for AI-generated Threat Modeling.
PWNISMS is a technique that helps you identify threats based on the system that you’re dealing with. I especially find it useful to work with PWNISMS because it helps me identify threats in complex, massive systems in a structured and sequential manner. It also helps you with the “best of both worlds” effect. You can use this in conjunction with or as a substitute for STRIDE. Basically, PWNISMS is a technique that you can use to identify Threat scenarios by domain/system. This is how the mnemonic breaks down:
P is for Product – Specifically denotes Product related Threats – Things like Business Logic Flaws, Access Control issues with the core application(s), other AppSec Issues relating to “Product Functionality” per sé. You can use STRIDE to identify product specific threats.
W is for Workload – Specifically denotes threats that relate to the workloads you’re running your system on or that your system relies on. Could be Kubernetes, Functions-as-a-Service, Cloud VPS, Databases, Queue Systems, etc.
N is for Network – Denotes threats against the network for the system you’re threat modeling. This could relate to encryption threat scenarios on the network or internal network threats or configuration issues related to network security and more. Again, use STRIDE to help you dive into this category.
I is for IAM – Every system today is exceedingly reliant on complex IAM systems. It could be cloud, on-prem or hybrid, but IAM itself is a pretty massive category of threat scenarios that you could identify across all the systems that you’re dealing with. This is one of those “composite” categories that might see some overlap across other categories but I see a good deal of value in calling this out in its own category.
S is for Secrets – Today’s systems are ridden with secrets and secret sprawl. You’re dealing with a plethora of API Tokens, OAuth Tokens, Encryption Keys, Service Account Credentials, Certificates and more. Secrets are not only an important consideration to look at across the system but forms an important aspect of identifying threats to the system. Secrets are stepping stones to the rest of the system and its essential to consider them as a key piece of your threat modeling methodology.
M is for Monitoring – This is one of the most forgotten and ignored aspects of any Threat Model. But the ROI on modeling threats here is incredible. Threats that either stem from monitoring or lack thereof are very important to be considered especially while formulating a threat model. These become keystone architecture and design considerations that you must get right at the earliest, or risk dealing with a lot of potential issues downstream right from lack of security telemetry for threat hunting and so on, to exposure of sensitive information through monitoring systems.
S is for Supply-Chain – Supply-Chain threats have ballooned over time in importance. It seems to be Issue number 1 for several teams. With AI, this is only going to get worse. This category serves as a way to gather your supply-chain inventory and identify threats against that inventory. A wildly useful category when you’re identifying threats.
I suggest that you give PWNISMS a shot the next time you’re threat modeling. It has helped me immensely. I am sure it will help you solve one of the biggest issues with Threat Modeling. Finding Security Threats.
