March 24, 2017

The Security Architecture Cycle

BY :     March 24, 2017

Now that you understand where a security architecture starts, 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 the 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 artifacts: 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 has had a long and diverse career within as disparate areas as social worker and security architect. From 1995 till 1998 he worked as a social worker/IT-responsible but decided to quit the same day a client tried to stab him with a screwdriver. After attending different courses he started as an infrastructure consultant at MercatoR 1998 where he started looking more deeply into the field of security. 2001 he moved on to G2 Solutions for a year where the focus area was secure coding. In 2002 he joined Capgemini as an infrastructure engineer and soon began to build a security practice. As Jesper is a very curious person he has worked in all fields of security from pen testing to security strategy but the last eight years his primary focus has been security architecture and compliance.

More on Jesper Kråkhede.

Related Posts

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

1 + 2 =

    *Opinions expressed on this blog reflect the writer’s views and not the position of the Sogeti Group