CyberKsen Blog

Threat model steps Every entry in the following data will have an ID that can be referenced in the TM itself or by the tools processing the TM data. It is advisable to use unique identifiers in the breaded scope (company/product/component). For example, an ID would then have a structure similar to PPP.SSS.NNN where PPP is the project or product name, SSS is the section and NNN is the sequential inside the analysis. This is just a basic idea of an identifier that should help also to compose different TM into one by avoiding collision of IDs and to reference the same architectural components. Scope definition High-level security requirements/compliance level This will consist of a list of descriptive requirements. High-level security requirements are those that would exist before designing the software itself and are often business-related. Compliance like PCI-DSS, ISO-XXX, FEDRAMP, are examples of high-level security requirements that are better to capture at the beginning of the TM. ID

Introduction I've been recently asked this question. And it still bugs me because given my experience, even if I do have a fairly good idea of what a good threat model should look like it has not only one 'good' final representation. A threat model is more than its outcomes (for simplifications: vulnerabilities and their mitigations). In this sense I'll use an analogy with software development itself, hoping it will help the audience, especially those in the software development. When creating software, the final result is typically an executable file. But this is far from enough, having only an executable, as good as it can be, it is too short-lived and it is not very useful over a long, or even a medium period. An executable software, unless in rare cases of extra simple firmware running on an electronic singing postcard, or driving the lights of your Christmas tree, is part of a wider ecosystem made up of evolving software, hardware, infrastructure, changing business