{"id":535,"date":"2025-07-29T08:10:52","date_gmt":"2025-07-29T08:10:52","guid":{"rendered":"https:\/\/donavan.sg\/blog\/?p=535"},"modified":"2025-09-03T07:35:33","modified_gmt":"2025-09-03T07:35:33","slug":"and-what-part-of-threat-models-should-we-publish","status":"publish","type":"post","link":"https:\/\/donavan.sg\/blog\/index.php\/2025\/07\/29\/and-what-part-of-threat-models-should-we-publish\/","title":{"rendered":"And What Part of Threat Models Should We Publish?"},"content":{"rendered":"\n

Recently, I read both the works “Publish Your Threat Models!<\/a>” (written by Loren Kohnfelder and Adam Shostack) as well as “Should We Publish Threat Models?<\/a>” (written by Matin Mavaddat) with great interest. These are important conversations that the industry should have, and also one of the numerous motivations for setting up a Singapore “Threat Modeling Connect<\/a>” chapter.<\/p>\n\n\n\n

Transitivity: Is the Threat Model Useful?<\/h2>\n\n\n\n

Let us start with Matin’s point on whether or not security is transitive<\/em>. A layperson view of transitivity<\/em> means the extent to which a certain point can be applied to another scenario. In threat modeling, we want to know if an artefact<\/strong> in a threat model can be applied to another scenario. Here, we distinguish between artefact<\/strong> and framework<\/strong>; there are many frameworks that exist, such as STRIDE, LINDDUN and other hybrid frameworks. Frameworks enable threat modelers to enumerate threats to produce artefacts<\/strong>, which are the more pertinent points of discussion.<\/p>\n\n\n\n

Let us break down this point further, by referencing both articles in context.<\/p>\n\n\n\n

Loren and Adam take a view that published threat models (PTMs) is at least transitive enough for threat models to be of use to providers, customers, end users and others. The transitive<\/em> property exists due to some artefact that is of value to some audience members. For instance, Loren and Adam opine that one such benefit of a PTM to a customer (here the customer is a consumer of a threat model for their direct use, such as system integration) is a quick understanding of the risk profile of a system. In the same sub-section, it is also interesting to note the following:<\/p>\n\n\n\n

“To the extent that it (i.e. the PTM) doesn’t match their needs, they can assess if ‘compensating controls’ can be ‘bolted on’ (often this is a risky move contrary to Secure by Design, but full knowledge of the threat model should help considerably).”<\/p>\n\n\n\n

In theory, this is true. Given a good enough PTM, it is possible for a customer be able to answer questions along the line of the extent of rigour (and hence a ballpark estimate on security investment) and usefulness (whether or not the artefacts from said PTM can, in fact, be contextualized to the customer’s environment and use case).<\/p>\n\n\n\n

But the practical reality, as what Matin articulates, is not exactly true.<\/p>\n\n\n\n

To Assess Transitivity, We Need Context<\/h2>\n\n\n\n

Recently, I had the privilege of speaking to several Singapore-based threat modeling practitioners. Some of them have to build threat modeling programs in their organizations. One of them is also trying to build threat modeling software that is useful for the organization. One common insight across these diverse range of practitioners is the context<\/em> in which the threat model is used for.<\/p>\n\n\n\n

But the context<\/em> in which threat models are written for differs considerably across organizations. As Matin points out, threat modeling and risk posture are fundamentally intertwined. At least in Singapore, a threat model often begins more as a risk<\/em> activity than a security<\/em> activity first. In some cases, it may even be a compliance activity. But risk<\/em> is inherently a business concept. Different businesses view their risks<\/em> differently and write up context-specific enterprise risk management frameworks to systemize the risk treatment process.<\/p>\n\n\n\n

Too Fatalistic?<\/h2>\n\n\n\n

A naive interpretation suggests we should simply stop with this idea and not move on. Many things can go wrong. Would the PTM expose our cutting edge? Would the PTM unwittingly give our attackers know-how over our cybersecurity team’s capability (or lack of)?<\/p>\n\n\n\n

But perhaps such a view is too fatalistic. There have been examples where the security community has managed to come together before to publish usable artefacts<\/strong> that have saved countless man-hours for security professionals in different disciplines. Examples of these (some of which, in fact, we incorporate into threat modeling exercises) are the MITRE ATT&CK<\/a> and CAPEC<\/a> frameworks, as well as design patterns<\/a> that incorporate security into their design.<\/p>\n\n\n\n

Rethinking Threat Modeling: User Security Stories?<\/h2>\n\n\n\n

Performing security from scratch is time-consuming, and at times, utterly unnecessary. Brought to the wrong extreme, threat modeling risks becoming a bespoke service that sucks up too much resources for too little return on investment. Thus, contemporary threat modeling discussions revolve around breaking down artefacts in threat models into standard components which can then be shared as best practices. OWASP’s “User Security Stories”<\/a> are a good example. By now, it is clear that there are standard security practices that users demand. These are straightforward. For instance:<\/p>\n\n\n\n

\n

As a Software company Customer, if an application component is vulnerable, I want the malicious activity against it to have minimal or no impact on the rest of the application<\/em>. (as quoted from OWASP)<\/p>\n<\/blockquote>\n\n\n\n

Such a security story can arise from a threat model. For example, one way to lead to such a security story is by highlighting a lateral movement threat (LM) when performing a threat model using STRIDE-LM: the application could involve various custom-built drivers, and the risk is that the malformed input that does not get sanitized in some application then gets passed to another part of the system (perhaps a kernel driver) and that can result in a BSOD.<\/p>\n\n\n\n

With a standard user story, we can then have standard mitigation measures. Different levels of context<\/em> could potentially result in different rigor of security stories that would imply different means of fulfilling the intent of said user security story. For example, a security story that often results in context-dependent<\/em> mitigations is:<\/p>\n\n\n\n

\n

As a Software company Customer, I want my account credentials to be created, stored and transported securely so that they can\u2019t be guessed, intercepted or reused by an attacker.<\/em> (as quoted from OWASP)<\/p>\n\n\n\n

Depending on whether the solution is an on-premise solution or a solution with Internet connectivity, there exists different mitigation methods. For a solution that can access the Internet, a common way to mitigate such a risk is to use existing authentication methods such as leveraging Google authentication, but an on-premise solution has to consider a different form of mitigation. <\/p>\n<\/blockquote>\n\n\n\n

Agreeing on an Ontology<\/h2>\n\n\n\n

Let us come back to the core dilemma. In my own words, the core dilemma revolves around what we can share that is useful for the security community, and what we cannot share because it distracts the reader, or is a liability.<\/p>\n\n\n\n

Standardization of differing security contexts of different environments is difficult. But the differing security contexts can be broken down into more atomic security stories that explain why these security contexts might different. These atomic security stories can form the basis of a more common ontology like how data flow diagrams are an atomic representation of a system. Such a standard set of stories can be useful not just from the perspective of a threat model, but are useful enough to write up as part of a PTM to illustrate the types of security stories the organization deems relevant.<\/p>\n\n\n\n

This goes back to Loren’s and Adam’s point on how PTMs can be made more widespread and function as effective communication tools, given a more standard ontology which is atomic enough such that the PTMs do not reveal commercially sensitive information, yet are useful enough to provide a standard basis in which the security stories can be discussed on topics of relevance, rigor of mitigation and perhaps, even culminate into design patterns or security best practices — all of which to help establish broadly accepted practices.<\/p>\n","protected":false},"excerpt":{"rendered":"

Recently, I read both the works “Publish Your Threat Models!” (written by Loren Kohnfelder and Adam Shostack) as well as “Should We Publish Threat Models?” (written by Matin Mavaddat) with great interest. These are important conversations that the industry should have, and also one of the numerous motivations for setting up a Singapore “Threat Modeling…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[8,5],"tags":[],"class_list":["post-535","post","type-post","status-publish","format-standard","hentry","category-cybersecurity","category-digital-world"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/donavan.sg\/blog\/index.php\/wp-json\/wp\/v2\/posts\/535","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/donavan.sg\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/donavan.sg\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/donavan.sg\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/donavan.sg\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=535"}],"version-history":[{"count":2,"href":"https:\/\/donavan.sg\/blog\/index.php\/wp-json\/wp\/v2\/posts\/535\/revisions"}],"predecessor-version":[{"id":538,"href":"https:\/\/donavan.sg\/blog\/index.php\/wp-json\/wp\/v2\/posts\/535\/revisions\/538"}],"wp:attachment":[{"href":"https:\/\/donavan.sg\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=535"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/donavan.sg\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=535"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/donavan.sg\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=535"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}