Control Services are a mechanism we can use to implement security control measures. I wrote this blog to demonstrate that controls are real things, which we should carefully consider; not just line items on a spreadsheet.
The Common Understanding Of Controls
I’ve seen very varied levels of understanding on control measures.
The most crude level of control implementation I have seen is where a project just runs through an excel with a list of questions. For example, they will simply ask the question “is the web server traffic authenticated?” and a technical person says “yes”.
That’s not really a control so much as it is a check of the current state. Some people argue that the exercise of running through the checklist and answering those questions is a control – and to a limited extent I can except that; This basic checking is better than no checking. However, There are varying levels of control, I tend to think about controls in terms of continuous control.
Its important to note there is a balance to be had; In designing any solution you need to think about your requirements, and you need to think about effort, vs return. Its just as easy to over engineer things as it is to under engineer them. Every now and then when I am designing something I stand back and ask myself – is this too much?
The subject of fully modelling security will take a few blogs, and wont try to cover everything here. A lot can be said around FAIR / SABSA way of doing things. There’s a whole bunch of related concepts and elements that I am not covering here.
The Control Measure
There are many frameworks out there that have security controls – for example the Cloud Security Alliance has the Cloud Controls Matrix. When representing a control it can be modeled in standard ArchiMate as a Goal element. Those of us using BiZZdesign’s Enterprise Studio (BES) have a set of elements especially for risk management – so we can represent them directly. In our example we are going to use a fairly simple control – Authentication – a standard control that exists in any number of frameworks. Figure 1 – shows how a control service realizes a control. In BES security controls can be modeled in figure 1.
For those using BES, Control Services can be created in a risk and security view. Although that view type only has a few elements in the create window, its possible to paste architecture from other views into a risk and security view. Enterprise studio will also allow you to assign a control strength to a control and has a number of features relating to modelling risk and security. Control services in BES – have a padlock next to them.
Showing a control service within your architecture
Representing a control service as part of an architecture model is easy. so as an example if I created my Authentication Control Service you could see it represented on a diagram like this:
In this case I have associated my service with some application components. Already this beats the approach of just saying “yes, we have authentication”. Its showing how our controls are implemented; we can see exactly where in our architecture our control is enforced.
Designing a Control Service
The authentication control is a simple example, but right from the beginning I can ask some simple questions:
- How do I ensure that control is being continually achieved?
- What do I want to happen if things fail?
- How much of this control can I automate?
I was talking to a colleague about implementing this kind of a control in a conversation in the office and I came up with something like this:
Figure 3 was a quick view drawn to support a conversation, during a conversation. Its not a complete architecture but it does show some elements we can use to control authentication at an application layer. This control would be fairly easy to scale because it doesn’t rely on any person to check it. It leverages policies in active directory, and in this simple example I was demonstrating that we need a mechanism that shows continuous control.
You can see I was showing that we do not just need an authentication mechanism but we also need a mechanism to ensure its applied – you can have the best burglar alarm in the world, but if you don’t switch it on, its useless.
The view doesn’t cover all the IT Aspects; In itself it raises other questions we would need to answer in other views; for example:
- Where would we run the different application components?
- Who supports this architecture?
- How would it be deployed?
- How are these things supporting business needs?
- What are the motivations for this?
- What are the Key Performance Indicators & How Would I Implement Them?
In my example I am showing an application level control service – I can also have business or technology layer control services. There’s also nothing to stop me realizing a security control with a number of different control services or a combination of them.
So Why Bring All This Up?
Controls are important. The point of this blog wasn’t so much to show how to properly design a control service, as it was to show that there are varying levels of control you can apply in architecture, and hopefully to get people to think more seriously about what applying a control actually means.
I have spoken about requirements realization before – I tend to think of controls in a similar way – it is not enough to say we have controls in place – we need to understand how we have controls in place.
Controls need to be considered as an integral part of architecture design, and should not be an afterthought. If you design controls into architecture audits become significantly cheaper, because you do not need to burn so much time hunting for answers to auditor questions – you are continuously ensuring a well designed solution which does not only satisfy the needs of the auditors but is also built to actually protect the Information running through our systems.