In order to get started developing a cybersecurity architecture, we need to gather a few raw materials first. These are the items that will set the context for all the design work that we will undertake in subsequent chapters. Specifically, we need to first obtain a baseline understanding of the organization itself; this helps ensure that the measures we will later incorporate into designs are appropriate, practicable, and in line with the context. This is, in turn, because the nuances and specifics of the organization – everything from its goals, to its culture, to its “mission” and unique needs – will ultimately drive the design. Everything about the design – the scope, security measures, implementation, operational constraints, and functional requirements – must account for the context in which it will operate. That context is an extension of the organization itself.
As an example of what we mean here, consider a situation where you decide to plan a fishing trip. There are a lot of tasks you’d need to complete to do so, and several important decisions that you’d need to make along the way. Specifically, you’d need to do the following:
- Acquire the appropriate equipment (tackle, bait, fishing rods, etc)
- Acquire any provisions that you’d need (food, beverages, hot or cold weather clothing, etc)
- Organize secure lodging and travel arrangements
- Depending on the type of fishing you want to do, you may need to secure a boat, and specialized equipment such as drills (ice fishing), depth finders or radar (deep water fishing), and lights (night fishing)
Each of the decisions you make impacts the experience. Some will impact the final experience more than others, but each individual decision will impact the outcome; and, obviously, you need to make decisions in a particular order. These and other factors govern the circumstances under which your decision making and preparation make sense – and without them, you have every likelihood of making a wrong assumption, resulting in wasted planning time, wasted money, and bringing about a sub-optimal experience for all involved.
One way to think about it is by drawing an analogy with the laws of physics that govern how our universe operates. We know that light moves at a constant speed in a vacuum (c=299,792,458 m/s). We know that the force between two bodies is governed by the product of their masses over the square of the distance between them multiplied by the gravitational constant (G=6.67384(80)×10−11 kg−1 m3 s−2).
It’d be totally different – fundamentally different. Even a small change to the underlying laws and parameters of the universe would result in a vastly different universe. If the speed of light were faster, (aside from other more pronounced effects) it would impact magnetism, perhaps leading to an earth without magnetic poles. If the gravitational constant were subtly smaller or larger, the universe as we know it couldn’t exist at all. All these values define the context of what we can perceive in the universe.
The point is, even a very small change to the underlying “context” means something totally different – and a minor change at that most basic level means outcomes that are vastly and fundamentally different from each other. Just like the structure of the universe would be vastly different with even a minute tweak to the underlying constants of gravitation and speed of light, so too will designs that are viable – even optimal – in one organization be total non-starters in others based on the fundamental assumptions and drivers upon which the business is built. A minor, subtle difference, misunderstanding, or “tweak” of the most fundamental contextual parameters means a completely different outcome and set of constraints. As architects, therefore, it is up to us to identify, understand, and abide by these fundamental assumptions that govern the world in which we will operate.
There are the “laws” that govern how your cybersecurity architecture “universe” operates that are just like this: contextual information that governs each decision that we’ll make. These represent the fundamental assumptions and constraints under which design decisions make sense and are viable. If you’ve been in an organization for a period of time, many of them are likely to be so ingrained to you as to be relatively invisible. For example, if I’ve spent my whole career as a software developer working in a shop that deals exclusively in writing Java code, it might not occur to me that it might be advantageous to write in Python.
Either way, we need to know what these things are so that we can design around them and ensure that the designs we’re proposing make sense for the organization into which they’ll be deployed.
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.