Threat Modeling Project

signatureAt the OMG Technical Meeting in Santa Clara, CA today I presented some thoughts on creating a comprehensive model for describing information security threats. My session was hosted by the System Assurance Task Force as part of their charter to improve overall systems security and reliance. Prior to this meeting, I had a large number of discussions with various stakeholders in the emerging (really: maturing) field of threat information sharing.


Given that there are already a number of specifications for threat information sharing, the question arises why we should bother looking at creating a complex project that would result in a threat model. There are – in my mind – a number of reasons why this not only makes sense, but in fact is  a necessity for furthering security on the internet. Some of these reasons include:

  1. Existing working specifications (such as STIX, OpenIOC, IODef, etc.) do work for their respective use cases, but are somewhat siloed and do not allow for cross-platform information sharing. In homogenous environments this is not a concern, but most systems – especially in large organizations or in a cloud-centric world – are quite heterogenous and will require interoperability between different stacks of threat sharing ecosystems. Without a consistent model that fosters semantic interoperability, we may see occasional convergence, but certainly no ability to federate at a multi-lateral level.
  2. Specific solutions are optimized for the original use-cases, but have a hard time extending cleanly beyond the original intended use. While it will always be possible to expand the scope and potential use cases for an existing ecosystem, it commonly either (i) takes increasingly complex extension mechanisms to support new areas, or (ii) starts off from a under-profiled specification that can be used for anything, but leaves enough room for interpretation in implementing it so that interoperability is effectively non-existent. Having a high-level conceptual model addresses both problems by (i) allowing a semantically consistent federation of best-of bread standards, or (ii) guides the development of profiles for enabling interoperability.
  3. Extension to new domains (such as supply chain threats or traditional law enforcement threats) or interfacing with adjacent problem areas (such as threat and risk management) is uncanny at best, if not outright impossible. Having a platform independent model or even a threat meta-model would make this connection significantly easier.

The core idea is to enable system engineers and architects to actually build systems-of-systems that implement and leverage the capabilities we have been building up to. Attached to this article are the presentation and the paper that I prepared for the SysA TF meeting – feel free to use and share as you see fit.

Approach and Goals

To address these issues, I propose a multi-phase approach that is intended to leverage existing work that has already been proposed in various communities. The goal is to understand the problems that will inevitably arise in identifying a shared ontology for threat sharing in a limited initial phase, and then broaden the scope to develop a comprehensive meta-model that can be leveraged in various ways. Specifically, for the phase 1 we can learn a lot by leveraging the UML Profile for NIEM  to generate a “Cyber Domain PIM” and a STIX Platform Specific Model (PSM) that is – effectively – a rendering of the Cyber Domain PIM in STIX compliant XML. Using the existing UML profile for NIEM is effective since it provides the necessary language to express the SITX model in a platform independent way. As an interesting side-note: completing this step will align two complex models that were originally defined in XML Schema and establish a semantic interoperability layer through a conceptual model.

In a second phase, the Cyber Domain PIM can then be broadened in multiple ways: Firstly, additional PSMs (such as for OpenIOC, IODef, Snort Rules, SI*, NIEM JSON, etc.) can be derived from the PIM in a consistent fashion, enabling the creation of meaningful mappings between these different languages. As a result, a properly profiled STIX Course of Action could then be automatically translated into a corresponding Snort rule that effectively implements a meaningful countermeasure against a specific threat. Secondly, the PIM can be extended by the capabilities supported by the new PSMs: for example, a Secure I* PSM could provide guidance on extending the PIM with advanced actor-based social and behavioral modeling.

Finally, the second phase should include a pathway towards a threat meta-model that (i) captures the domain-independent aspects of the threat model, and (ii) aligns the project with adjacent work such as the emerging risk management meta-model. In a (yet to be concretized) third phase, the cross-domain capabilities of the meta-model can effectively be used to integrate existing non-cyber domains (e.g. in the context of the Common Alerting Protocol – CAP), or guide the development or emerging non-cyber specifications in aligned specification stacks (such as the Supply Chain Observable eXpression project – SCOX – in STIX).

Road Ahead

Based on the positive feedback from the Santa Clara meeting, I am looking into starting work on phase 1 as soon as possible. There is currently great momentum within OMG and its member organizations as well as some of the affected communities, so I think that we can get a RFC for phase 1 ready in the March or June timeframe. To facilitate this, we will be starting a working group early January that will focus on creating the Cyber Domain PIM and the STIX PSM. If interested in observing or actively participating, please send me a note.

Leave a Reply

Your email address will not be published. Required fields are marked *