Modelling Security Concepts with Archimate

In this post I will be using Archimate to model some fundamental information security concepts. If you're a solution or enterprise architect and you need to get an understanding of information security and how security concerns can be modelled, I hope you'll find this to be a useful starting point.

So let's get straight to it and start modelling some basic information security concepts, starting with threat agents. Unlike some areas, there is a straightforward mapping for us in Archimate with the Business Actor entity.

A business actor is an active entity defined in Archimate as an "organizational entity that is capable of performing behavior" and may exist outside of our own organisation. Whereas in our normal business layer models we are typically concerned with actors such as customers, sales and back-office staff, in security we need to think in terms of the malicious entities that wish to cause harm to our organisation and its systems. Unlike normal actors, these hostile actors have no interest in using our systems in the way we want, expect or intend them to be used; they are almost an "anti-actor" in that sense. They will seek to interact with us in unexpected and perhaps novel ways, exploiting any vulnerabilities they can find in our systems, people and processes.

Let's take a look at how we can model the different types of threat agents:

As we can see from the diagram, the generalised threat agent entity is composed of two main sub-types: Internal and External actors. These two are in turn composed of several different sub-types. The diagram shows some common types and you will probably be able to think of more. For example, a common threat agent not shown above is the aggrieved former employee who, following dismissal, seeks to inflict damage on his previous employer. If we wanted to model this threat agent we should include him under the external bucket as he no longer works for the company.

Sometimes, however, the distinction between internal and external threat agents can become blurred. For example, a disgruntled internal staff member colluding with a skilled external attacker may present a very high level of risk to the organisation. Similarly, internal staff may be tricked by external or even other internal attackers into becoming 'proxy attackers' to facilitate attacks that the original attacker is not able to execute directly, or to provide information which will allow a direct attack; for example, disclosing a password through a social engineering attack.

We can model this as follows:

In this scenario, the benign internal staff member unwittingly assumes the role of proxy attacker on behalf of the real attacker. We can model this using the Archimate Business Role stereotype as shown above. I have modelled the relationship between the internal actor and their new role using a flow connector to indicate the change in state of the entity. You may prefer to represent the relationship differently.

So let's now think about the threats that these threat agents represent to our business and consider how we can model them. In Archimate, and according to the advice provided by the Open Group, security threats closely map most closely to the Business Event stereotype. While this does not perhaps stand up to very close scrutiny, it serves well enough for us to begin expanding our models.

For both internal and external actors, threats fall into two main categories: Technical and non-technical. Technical threats are threats against our systems, our business partners systems and our supply-chain. Threat agents will seek to locate and exploit vulnerabilities in every layer of our infrastructure, from end-user devices through to networking infrastructure and servers. Non-Technical threats include, for example, physical entry to restricted areas, theft of physical documents, storage devices, laptops, mobile devices and social engineering attacks.

Attacks in the real world may also be blended; for example, one of our software suppliers may fall victim to a social engineering attack which in turn allows an attacker to install malware on an end-user laptop at the supplier. This may allow the attacker to steal SSH keys the supplier uses to log into our system to do development work. This then facilitates attacks on our own enterprise that would not otherwise have been possible.

We can model this as follows:

Here we see that there is a relationship between threat agents and both technical and non-technical threats. Technical threats are related to our network computing assets while non-technical threats are related to our people and our property.

Clearly then, if we took no steps at all to protect ourselves, our business would almost certainly be completely compromised by threat agents in very short order. These steps we take to protect ourselves can, at the highest level, be represented as a Business Service entity in Archimate. Again, quoting from the Open Group, "A business service should provide a unit of behavior that is meaningful from the point of view of the environment. It has a purpose, which states this utility." Moreover a business service is, "associated with a value." It is therefore clear that our security control service must include appropriate behaviours to add value to the business by reducing the exposure to risk. Let's consider how we can model this at a high-level:

In the above diagram we can see that security control services exist to detect and disrupt the threat agent's intentions. For example, our attacker may seek to send an email with a malicious attachment to a member of our Finance department. However our security control service includes an email protection component that identifies the potential malware and strips off the attachment before delivering the message to the user.  The flow of input from the attacker is thus intercepted and changed before it can do any damage. The traffic could also be dropped completely and/or result in alerts to members of the security team. 

So let's now move on from threat agents and start to think about how we can model some core enterprise security concerns at the highest level. To help us with this, let's walk through the following diagram:

As cryptography guru Bruce Schneier once famously observed, "Security is not a product; it's a process." Let us therefore consider that maintaining security in the enterprise is a process, represented in Archimate by the Business Process entity. That process is associated with the business requirement to protect the confidentiality, integrity and availability of systems and data. We can model these aspects using the Business Goal entity in the Motivation extension to Archimate, where a goal is described as representing "anything a stakeholder may desire, such as a state of affairs." 

As we have already seen, to maintain security and meet these goals we are dependent on our security control service. But what is this exactly? In reality it is an aggregation of different control types spanning technical, physical and administrative controls. These in turn will also be an aggregation of several major control types which act together to provide holistic security for the enterprise. In the absence of a specific stereotype in Archimate for controls, I have favoured representing them as components in this instance. And as we can see from the diagram, the security control service is realised by this aggregation of control components. 

When modelling your actual security architecture, you will of course wish to identify which technical components and which business processes realise and compose the various types of control. This will also be extremely useful in identifying any potential control gaps; remember that we must strive for defence-in-depth and not rely solely on one subset of controls to protect our enterprise. 

I hope this post has been useful and would love to hear from you if you have any questions or observations on this topic. I would highly recommend reading "Modelling Enterprise Risk Management and Security with the Archimate Language" available for free download from the Open Group if you wish to model your security architecture in Archimate.