Cybersecurity Architecture: Some matters of opinion

We recently held an internal webcast and panel session on what security architecture means to us as individuals as part of our Global Cybersecurity Architecture community. One of the benefits of working at Capgemini is that we are encouraged to have our own, occasionally divergent, opinions. “Career-limiting” conversations are few and far-between in this organization (I hope I am not tempting fate!). So, what are the three personal opinions that I shared during this session?

Improved and active communications are the real value in security architecture

The real value in security architecture rests in improved and active communications across a wide range of stakeholders rather than in the production of overly complex documentation which will often just sit on a lonely Teams site gathering electronic dust. If you do security architecture properly – by which I obviously mean in the way that I believe it should be done – then you end up with an agreed common view on what security means in the context of the project, program,  or organization you are working in. You bring the business stakeholders and the technical stakeholders together on a journey towards a common goal. There are a lot of prerequisites that an architect must fulfill to deliver such a common perspective, one being that your stakeholders are willing to play nicely with both their peers and the architect. Another assumption is that there is a common view on the threats, risks, and business goals associated with the project, program, or organization in scope. This latter view is something that is in the remit of the architect to facilitate and so architects need a well-populated toolset of techniques to ease these conversations. It’s not always easy – the analogy of herding cats can be an apt one.

There’s a difference between design and architecture

There’s a difference between design and architecture.  The former will tend to focus on the “How” whereas I believe architects should focus much more on the “Why.” If you have ever looked after kids, then you have quite likely suffered through the “but, why?” phase of toddlerhood, where everything you ask a child to do is met with “why?” Followed by a “but, why?”  And on and on and on, potentially without break or end.

Childcare is a pretty good preparation for stakeholders about to encounter a competent security architect. Security architects should have a really good idea of why any particular security control is needed and should not stop asking “why?” until they get a reasonable answer. What threat actor does it confound? What vulnerability does it help to mitigate? What risk does it reduce? Do we actually need to expend time and energy on putting in place a particular control? I would advise caution whenever dealing with a security architect who offers up solutions without having gone through a lot of “whys” beforehand.

It’s the contextual level of the Capgemini Integrated Architecture Framework (IAF) model that is most important. We need to understand the context that we are working within. What is the strategy of the business? What is the regulatory regime? Who are the key decision-makers? Who are the likely threat sources and what are their aims? What are the organization’s crown jewels from an information and information systems perspective? Is there an existing architecture that your own project needs to fit within? A fun question that doesn’t always get asked enough – what’s the real priority of each individual element of the confidentiality, integrity, and availability triad? Too many security professionals focus heavily on the confidentiality aspect to the detriment of the others.

Architects need to bottom out the contextual layer so that we have a solid reality to which we can anchor the conceptual, logical, and physical architectures that follow.

I finished off my part of the session with a discussion of a security reference model that I’ve used over the years and how we can use such models to help scope conversations with our various stakeholders and how such architecture models and processes can be effective in the more agile, fast-paced environments within which we now work.

To conclude, good architecture is not purely theoretical. Good architecture is not shelfware. Good architecture does not “get in the way” or needlessly hold up project delivery. Good architecture does however help to align the systems we build and operate to the underlying needs of the business and so to deliver defensible outcomes. If your security architecture exists only in Powerpoint, perhaps it’s time to break out one of those “whys?”

To find out more about how we can help you visit our cybersecurity services page.

Follow Lee Newcombe on LinkedIn.

Lee Newcombe

Expert in Cloud security, Security Architecture

I advise my clients on how to identify and manage cyber risk in an ever-changing and increasingly digital world.
I have assisted central government, a regulatory authority, global insurers, major banks, transport providers, utilities providers, consumer goods producers and others with their adoption of cloud services through provision of pragmatic, forward-looking and practical guidance relating to the organizational, process and technical change needed to securely deliver the benefits offered by the cloud model.