Skip to main content


Threat Model Maturity model

 Achieving a difficult goal like having a useful, always updated Threat Models requires resources and a good strategy. Requires also to divide the big challenge in smaller step, assess progress and, in the first place define the ultimate goal. To perform those activities a maturity models is the right tool. It defines the goal as the target maturity. It also defines a series to intermediate goals in the form of lower to higher maturity targets, and is fundamental to assess the advancement and the overall quality/maturity of the Threat Models. There are some great maturity models, for example OWASP SAMM, that helps assessing the maturity of different practices across secure development lifecycle (  I've personally worked on them with great results. But the granularity and details of the parameters to assess the maturity of secure design and threat model is not enough for defining a specific strategy for successfully Threat Model
Recent posts

Threat Modeling, what 'good' should look like. Part 2 Execution Steps

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

Threat Modeling, what 'good' should look like. Part 1 Introduction and examples

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

Effective Cloud Security Programme, Part 1

In the same way that happens for any IT system, the main security goals are: Assess the risk level Protect assets reducing risk through mitigation strategy ...both goals in the most cost-efficient and business enabling way. To assess a cloud-based system architecture security posture we need to identify and structure a well-defined set of dimensions (metrics) that can be measured against such cloud system. Having that risk assessment then will drive the development and risk governance strategy including refactoring efforts in a more efficient and coherent way. This is true whether we are considering a single system or, especially, a set of independent systems. This is key in larger, more structured organizations. Frameworks like OWASP SAMM (Software Assurance Maturity Models) show us a way to approach such an assessment challenge. Having cloud-specific metrics and the right incentives in the organization hierarchy is a must to successfully deploy and drive a security enhanceme

Content-Security-Policy and third party JS, a Threat Model view, PART 1

A lot has been done to defeat XSS and other potential vulnerabilities in nowadays frameworks (contextual encoding in React Angular... etc)  and development practices, still, XSS, and in general the ability for an attacker to execute arbitrary code (mostly Javascript) is still in the OWASP TOP 10 and at the root of many cybersecurity incidents. As mobile applications also became a wrap on top of a browser-based web application, the attack surface for XSS and other related malicious code injection widens even more. Given the situation leveraging browser mechanisms to restrict the Javascript code that the client can execute to only the expected one sounds like a great solution. Content-Security-Policy (some of the advanced features) has this potentiality but is mostly unused. I saw two main reasons for this: The advantage is hard to defend: 1) It needs to be fully understood, it needs clear evidence and arguments to justify it (that's why I'm writing this article). 2) It is