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.
