How do you apply security architecture?

Everyone is talking about security architecture and want to incorporate it into their daily architecture work but many fails to see what security architecture really is and how you should use it.

What is security architecture exactly? 

I had a client meeting recently where we started to discuss their view on security architecture and quite interesting I got several views of what security architecture actually is. As a result of that I created a set of slides that describes how I work with security architecture. Of course, there are many ways to do security architecture but a common consensus of the how you view the topic is quite important to define.  

As you see in the above picture I use IAF (Integrated Architecture Framework) as a model to build my architecture. IAF is part of TOGAF since TOGAF 9. An architecture consists of four large parts: Business, Information, Information System and Technical Infrastructure. Security architecture is not a specific architecture within this framework. In some cases, you model an IAM-system and call it a security architecture but that is not correct. That´s a Technical Infrastructure architecture of a security system. A security architecture is actually something completely but it ends up in changing the current architecture you have to make sure that its secure. The red dots show examples where an architecture could be changed to make it secure.

So basically, security architecture is the process of making an architecture secure. 

Where do you start your security architecture?

It´s not that easy to start creating a security architecture when it’s hard to define in the first place.  A security architecture has a few starting points. The first one is the realisation that you have something to protect. That may sound as a simple thing but without your assets defined you cannot define a security architecture.

Following that you need to start building the list of requirements you need to adhere to. 


This list consists of your risk analysis, applicable laws you need to adhere to and compliance schemes you need to follow. Of course, you could have others that are on a voluntary basis and those should be included in the list as well as long as you don´t regard them as strict mandatory.

The list you provide will be your risk register that you will start working with. 

The security architecture cycle

Now that you understand where a security architecture start it is time to look at the full cycle of security architecture.

When you have a risk register with risk for different assets you need to start working on how to mitigate those. The first task is to define the security mechanisms that are needed to solve your problems. A security mechanism is a description of a security solution to a defined security problem.

For example: Encrypted communication solves eavesdropping on network traffic and is solved by using an encryption technology to change a payload to an unreadable format except for the intended reader. 

By mapping your risks to security mechanism, you can start defining your solutions. After you have defined the possible mechanisms you need to check if they are applicable in a specific implementation scenario. One example is a requirement to encrypt information stored on a fileserver in such a way that data is encrypted when not used. A quick glance would make it possible to use Microsoft RMS or a disk-based encryption. When we look a bit further we understand that a disk-based encryption that encrypts the whole disk is not working as a fileserver is online 24/7, hence the data is always accessible.

When you know the mechanisms, you need you map out the possible patterns that you need to solve the problems. In some cases, they will contain more mechanisms or usage of mechanisms in another way than you thought of. The patterns are accelerators but not always the correct way to solve a problem. They seldom adhere to your specific business processes.

With all this information readily available you will create a few artefacts: Changes to different parts of the architecture and suggestions how to implement different security mechanisms technically or using processes.

With this you have managed to run a full circle and could update your risk analysis and the whole circle starts again. 

Jesper Kråkhede
Jesper Kråkhede
Cyber Security ansvarlig
+46 (0) 725276587
todo todo