Many Roads: Cybersecurity Architecture Process Overview

The last area that we’ll cover before we actually dig into the meat of creating an architecture is a brief overview of the process that we use throughout our book. There are as many ways to practice architecture as there are architects — and anyone telling you there is only one way to do it is limiting themselves. Just like there are multiple approaches to writing software, system administration, or decorating your house, there are different techniques and strategies that can be adapted and employed by the architect.

We set out one path that you can follow to design, test, field, and maintain a security architecture. This isn’t the only way. It may not even be (for you) the best way. But our belief is that the best way to learn something is by doing it. Following the process that we describe will result in a functional security architecture. As the architect becomes more conversant with the steps and methods, they can incorporate other techniques, resources, strategies, and possibilities into their approach.

The process that we will walk through throughout the rest of this book is fairly straightforward. It includes the following high-level steps:

Set scope and requirements: Determining the scope and direction for your architectural planning. This phase includes the validation of what will be included in the design you create and also the determination of the requirements that will guide the solution development.

Prepare your “toolbox”: Preparing the tools (including documentation) that you will need to undertake subsequent phases and actually get started on your design.

Build enterprise blueprints: Designing the security plans and developing implementation plans for the organization.

Execute the blueprints: Putting your plan into practice.

Maintain: Making sure that the goals of the design stay relevant over time by collecting relevant metrics and telemetry.

You’ll notice these steps are very high level. There are, as you would imagine, a number of sub-steps that fall under each high-level step that we will go through in depth when we reach them. This approach is by design. From our point of view, it is more important that you understand the why behind each step than it is that you master any specific individual technique comprising a given step. Meaning, there will be situations when you will not be able to follow exactly the approach we’ve laid out.

For example, there might be situations where there are process, cultural, or technical limitations that prevent you from being able to follow the approach. However, if you understand the why behind the step, you can create your own path around those roadblocks and ultimately wind up ready to begin the next phase anyway.

An analogy for this approach is that it’s like following GPS directions to get to a given destination. If something unexpected happens along the route — for example, there is an extended detour due to construction, it is much easier to stay on track if you know the general direction of the destination and why the GPS was routing you the way it was in the first place. If, on the other hand, you have literally no clue where you are or why the GPS was taking you down a given road, the impact of an unexpected hurdle like this is much greater.

This post is part of a series excerpted from our book: Practical Cybersecurity Architecture: A guide to creating and implementing robust designs for cybersecurity architects, ISBN-13 : 978–1838989927 available at Amazon and published by Packt.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store