Now that we’ve established why cybersecurity architecture matters and what the key roles and responsibilities are, let’s spend some time talking about the process that architects use. It’s important to recognize that much of the process will be unique and adapted to the organization employing it. The goals of the security architect, what they’re responsible for, and the role that they play within a given organization can vary depending on a few different factors: the organization itself, the scope and focus of the architect’s role, and so on. These same factors will play a role in the process that the architect will follow to realize the results the organization needs.
Secondly, we’ve purposefully refrained from discussing much about the mechanics of how the architect approaches these tasks. We do get there later in our book (and this blog series!) – but for now, we want to make sure that the aspiring architect understands the purpose and overall process of the discipline – before beginning the practical work.
One element useful to tee up early though, is the use of architectural standards and frameworks that guide the work that the cybersecurity architect does. Interestingly, there aren’t many that directly address security architecture specifically – at least compared to the large volume of documentation that addresses IT system and infrastructure architectural planning more generally.
Note that this is not to imply that there aren’t any that do so; there are in fact some very solid and helpful frameworks that can provide quite a bit of value to the security architect that we will introduce in this section and discuss how to use in this and subsequent chapters. However, since the cybersecurity architect is likely to encounter concepts, documents, reference architectures, and other artifacts from a variety of sources, it’s useful to establish a baseline familiarity with architecture frameworks and models more generally before delving into security guidance specifically.
With that in mind, let’s start with architecture frameworks generally. These are formalized approaches to the planning of technology, systems, networks, and related components. It is not hyperbole to say that there are thousands – perhaps even hundreds of thousands – of pages of documentation related to enterprise architecture planning, supporting reference architectures, standards, and guidance that exist for the enterprise system architect.
To name just a few, these include the following:
- AGATE (Atelier de Gestion de l’Architecture des Systèmes d’Information et de Communication) in Le manuel de référence AGATE V3
- Department of Defense Architecture Framework (DoDAF), which in turn superseded Technical Architecture Framework for Information Management (TAFIM) in The DoD Architecture Framework (DoDAF)
- Federal Enterprise Architecture Framework (FEAF) in FEA Consolidated Reference Model Document Version 2.3
- Generalised Enterprise Reference Architecture and Methodology (GERAM)
- ISO/IEC 10746: Information technology – Open distributed processing – Reference model: Architecture
- ISO/IEC/IEEE 42010: Systems and software engineering – Architecture description
- MODAF (British Ministry of Defense Architecture Framework) – see https:// www.gov.uk/guidance/mod-architecture-framework
- NAFv4 (NATO Architecture Framework Version 4)
- NIST SP 500-292: NIST Cloud Computing Reference Architecture
- The Open Group Architecture Framework (TOGAF)
- Purdue Enterprise Reference Architecture (PERA)
- The Zachman Framework
Note that these represent only a small subset of what’s out there. For example, we’ve deliberately refrained from listing legacy models and frameworks that are no longer in current or active use, models that have an architecture component but that are not specifically architecturally focused, smaller or more limited-scope models, and commercial models behind a paywall.
This is obviously a lot of documentation. Therefore, the architect incorporating these approaches into their processes needs to be selective: they need to factor in things such as context, applicability, organizational needs, culture, and so forth in determining which of the many that exist might be appropriate for them.
The complexity of today’s distributed computing environments didn’t develop overnight. With the advent and proliferation of distributed computing, mobile devices and IoT, complexity increased exponentially. With the increase in the computing footprint, interconnections between devices increased non-linearly. This is hard to manage and causes emergent behavior to occur: that is, behavior that occurs at scale in a way that is difficult to foresee based on the behavior of individual systems in isolation.
Architectural frameworks represent efforts to bring order to the chaos. They emerged as a strategy to help ensure the following:
- Business goals are supported in an optimal way by the technology in use.
- Technology is purchased, leased, and/or maintained in support of business goals.
- Resources (personnel, budget, time, and so on) are used optimally and efficiently.
The challenge with so many different architectural frameworks though is that you may find enterprises favoring one or another (or in some cases multiple in parallel) depending on the country you’re located in, the business context, the industry segment, practitioner familiarity, and other factors. This is why we recommend security architectures become familiar with approaches that unify concepts from the enterprise architecture world with security. There are multiple models (some more well known and some less), but the ones we’ve found to be most useful in practice are:
- Sherwood Applied Business Security Architecture (SABSA)
- Open Enterprise Security Architecture (O-ESA) from the Open Group
- Open Security Architecture (OSA)
In our next posts we’ll provide an overview and outline for each of these three approaches.