The Most Difficult Security Architecture Question Out There

Drumroll…. I think it is this one:

What is Security Architecture?

Uhm, Esther, are you sure? Seems pretty basic to me.

When me and my team were creating our new Security Architecture brochure at Deloitte, we got a lot of feedback on a certain slide. Our definition slide. “Why do you need to explain what it is, isn’t it clear?” and “We never put in definition slides in our brochures.” And this is fair as for most security capabilities the answer is very intuitive. E.g. our incident response team helps you respond to cybersecurity incidents. They come in, assess the situation, take actions to limit the damage and get you back on your feet. But what do security architects do? They help you architect your enterprise’s security? But what does that actually mean?

When one meets a security architect one has not met before, it is like meeting a new animal species. What kind of architect are they? Business-oriented? Deep into the technology? Somebody who loves to model and document everything? Or rather evangelises a set of max 10 principles? Are they concerned with only network architecture or solution architecture? There are as many types of security architects as there are birds in the sky.

Why is this question worth answering?

You might just think — Esther, can’t we just get on with doing it? Yes, yes, of course that matters a lot. But if we don’t know ourselves what we mean, how are others supposed to? What if I would like to explain to my other colleagues in 1 or 2 sentences what security architecture is? What if a client asks me what security architecture is? Do you have a clear cut answer ready? It is very important to be clear what we mean when we talk about security architecture, otherwise we could get into all kinds of misunderstandings, misconceptions and misgivings. Hence my personal need to figure out a good definition. I found most definitions to only cover part of our understanding of the concept. And so me and my team set out on a journey amongst definitions to find our answer.

Tell me, what is it then?

First, we looked at the definition of OpenSecurityArchitecture.org. This is an open-source volunteer platform focussed on creating architecture patterns. They say:

“The design artifacts that describe how the security controls are positioned, and how they relate to the overall IT Architecture. These controls serve the purpose to maintain the system’s quality attributes, among them confidentiality, integrity, availability, accountability and assurance.”

This is a great definition because of the explicit link towards IT architecture. I believe security architecture should never exist in isolation from the enterprise or IT architecture. From the definition it is also clear that we use controls to achieve a certain set of attributes related to security. But the definition equals architecture to the ‘design artefacts’ it produces, its output. The process of ‘doing architecture’ is not explained? Just artefacts that magically fall from the sky.

The second definition comes from the SABSA framework. SABSA is a business-driven, risk- and opportunity-focussed security architecture framework. They say:

“Security architecture is the art and science of designing and supervising the construction of business systems , usually business information systems, which are: free from danger, damage, fear and care; in safe custody, not likely to fail, able to be relied upon and safe from attack.”

This definition speaks of security architecture as a ‘discipline’. It aims to protect against all kinds of risks, rather than the traditional CIA attributes. But this definition remains quite unspecific about how we reach those goals.

The third definition we appreciated was that of Gartner, the well-known research institute:

“The discipline and associated process of planning and designing organizational, conceptual, logical, and physical components that interact in a coherent fashion, aligned with business requirements, in order to achieve and maintain a state of managed security related risk.”

This definition is nice as it pulls out the specific components of an architecture. It is not very specific about what the aim is of those components though! That they are on different architectural layers is not interesting to the layman.

So here’s our suggested definition that we feel comprises the best of the three above:

“Security architecture is a discipline (methodologies, reference frameworks, processes, technologies, organization and communication) that produces and maintains architectural artefacts providing structured direction and control to coherent decisions about security in (complex) business and IT landscapes.”

Let’s break this down:

1. What? We recognize that term ‘security architecture’ is both the discipline and resulting artefacts. It comprises creating architectural strategy, designing and implementing architecture, and maintenance of artefacts.
2. Why? The aim of ‘architecting’ is to direct and control coherent security decisions. As Gartner says these are often focused on managing risks. But we also account for costs, the organizational future and enterprise architecture.
3. How? We use methodologies, reference frameworks, processes, technologies, organization and communication to deliver.
4. Whom, where and when? We do (enterprise) security architecture in complex business and IT landscapes. This entails the organization is either quite large or there are a lot of moving security parts and changes. Security architecture is overkill for overseeable organizations like the bakery around the corner (IT architecture and solution architecture have lower ‘usability’ threshold though).

So isn’t it just everything within cybersecurity?

This is a comment I get often, e.g. from colleagues who are trying to place it in relation to their own specialty. For instance, a colleague who specialises in risk assessments might feel that I have just absorbed their expertise along with 40 other specializations. I cannot stress the following two points enough:

• Security Architecture is about providing insight and oversight for the organization in its security risks and controls. Many of the other security disciplines deliver a part of that objective (e.g. a risk assessment). But the critical issue is that many fail organizations fail to tie the results for that discipline to other disciplines (e.g. the implementation of controls or evaluating the impact on their business strategy). So you need an architect to make sure that everything from the business strategy to the technical implementation is aligned.
• Being an architect does not mean I do everything that my architecture needs. I might well rely on experts in the other disciplines to get me that risk assessment or help me craft a network design. Unless you’ve been in the game for 50 years and have been in the fortunate position of constantly being able to develop yourself, I am going to come out and say it is very rare for an architect to be able to do everything from the super-strategic to the super-technical. There is not enough time in the world to become a superhero like that. Most architects were something else before to they turned to architecture. I used to specialise in strategy, risk assessments and maturity assessments and therefore as an architect I excel in the strategy, business logic and logical architecture layers. I am continuously develop myself technically, especially in the field of Cloud (various certificates coming up), but I might never be as comfortable with the technical nitty-gritty as an architect who used to be a sysadmin or a network specialist would be. And vice versa. In the beginning this made me quite insecure, but more on this in another article to come “Help?! I want to be a great Security Architect”.

So what?

A clear definition of what we are talking about is fundamental for good discussions. Think I am wrong about this being the most difficult question to answer? Have you got a better answer? GOOD! Let’s have it then! As far as I can tell nobody has written a similarly extensive argumentation around what it is we actually do. Leave your comments below!