Challenge of the Month:
A well-structured Threat Library can help teams identify, assess, and mitigate risks more effectively. But what key components should it include? What attributes or data models are essential for making it useful across different teams and use cases?
This month, we challenge you to define the core elements of an internal Threat Library in a way that’s clear and actionable. Share your experience and insights with the community. Bonus points if you have examples to show.
How to participate:
Reply to this post with your response.
When to enter:
Now through April 30, 2025
Recognition:
Everyone who completes this challenge will earn an ‘Insightful’ badge. Members who collect seven ‘Insightful’ badges will receive a special award!
We have a very concrete proposal for such a library (knowledge base). It includes the following element types(your “components”):
component types - an enumeration of component types used by the organisation, in various levels of abstractions (from general descriptions like “internally developed application” to CPE entries)
vulnerabilities - vulnerabilities that the organisations identifies as relevant to its designs, including classes of vulnerabilities / weaknesses
controls - a list of security controls approved for use by the organisation
security design rules - specifying relations between the above
How can you systematically use such a “library” to analyse and design systems? This is detailed in this open access publication, including an example.
We maintain a Normalized taxonomy of security threat (NTST) mostly for STRIDE MODEL.
This is an internal library where we maintain threats and their definition and apply to each security design document. The library contains, threat event , mitre attack, mitre attack technique, mitre capec and mitre cwe.
When this is applied to the security design each of these is mapped to the specific controls that is prescribed for the design. In the end residual risk is calculated using all the threats that have not been mapped to a control.
Intentionally provocative answer: maintaining a private library of threats almost never proves to be worthwhile in the long run, which is why there’s so few of them that are even discussed.
It might be worth doing as a product (eg, Trustoncloud), community effort (eg, Cornucopia) a book (mine or Brett Crawley’s).
In theory, it’s great for end-users. But what I find in practice is that, as what Abhay may say, one can have a taxonomy of security threats. But that’s what you can get out of CWE and MITRE CAPEC.
But I do wonder if such a library is sustainable in the long-run.
It depends on the requirement for the level of detailing in the library.
You could just have a common Primary threat and Secondary threat with controls for each
" Primary Threat - Unauthorised Access -
Secondary Threat - Lateral Movement
Controls - Implementation of IDAM control xyz etc and robust firewall rules or gateway in place…"
Or
You could have a bespoke entry that covers threats to a particular system or application. So this is where you’d attribute a threat specifically to system and you can look up that system or application to see what has been highlighted before.
This can help update a model and also give it that granularity in detail.
I agree the use of a library makes life easier but the management of a library can become unwieldy if not consistently worked upon.
Well we should include in terms of Security by Design principles and Design Security flaws mapped to different control libraries from STRIDE, MITRE variations, OWASP top 10 variations like API, CNAPP, K8s, CI/CD, LLM, OWASP ASVS, CIS controls, LINDDUN GO, Plot4.ai, and few inputs from Threat Intelligence sources
For Example: We have tried this method for the Hackathon 2024, which won the 1st place last year. This methodology helped us achieve defence in depth.
Furthermore based on the architecture, as and when the attack surface exposure to critical data, assets and use cases with increase of potential exposure.
I would like to share some thoughts on a possible structure for a Threat Library, building on a lot of the great ideas already shared here. I think combining threats, weaknesses, and controls with a mix of both generic and system-specific threats can really help teams get up to speed quickly and start applying threat modeling more effectively. Perhaps with the right level of automation, it might also be possible to minimize maintenance challenges over time.
Seems like there’s different perspectives on what a threat library is.
Here is mine: Somebody threat modeled a more abstract / generic version of a building block that may be part of your system. We are invited to ask ourselves if that applies to our system: Similar scope? Similar threats? Want to follow suggested mitigations?
If we build the same things again and again, we should create and reuse a (generic) threat model. In my opinion threat library is not totally different from threat modeling in general.
This methodology helped us achieve defence in depth.
and invites us to think about those threats
(
In my opinion threat library is not totally different from threat modeling in general.