Architecture, security standards, and frameworks

Knowing then what the purpose of the architect is and where/how they might be involved, it's important to spend some time talking about the process that they employ to get there. In beginning this discussion, it's important to recognize that much of that process will be unique and adapted to the organization employing it. We've seen that 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'll get there – but for now, we want to make sure that the aspiring architect understands the purpose of the discipline first, before getting into the details of doing it (it's similar to fully understanding the requirements of an IT project – why do it in the first place? – before beginning the implementation work).

One element that does border on execution, but that is useful to tee up early anyway, 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.

Architecture frameworks

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 contained in the literally hundreds of enterprise architecture frameworks, 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 again 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 – more than any one person could be expected to read and digest in any reasonable amount of time. 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.

One question that can also provide some insight into the architectural process is the reason why there is so much guidance on the topic in the first place. The reason for it is largely historical, but thinking it through illustrates the value that architecture provides. Specifically, the breadth of coverage isn't hard to understand in considering the role that they've played in the evolution of enterprise computing.

Consider for a moment the early days of information processing – before distributed computing and ubiquitous networking. In that world, organizations were either not using computing at all, or if they were, they had a relatively simple computing footprint. For example, they might have one or two large mainframe systems connected to terminals that didn't have much, if any, computing capability of their own. Under this model, an engineer, analyst, or system administrator can very easily hold the entirety of the computing footprint in their mind or, for a particularly large deployment, with the aid of a few pieces of paper.

As we all know, this is not the situation we're in today. Today, any medium- or large-size enterprise might have thousands or tens of thousands of endpoints, each more powerful than the room-occupying mainframes of the early days. There are server systems in on-premises data centers, at colocation providers, and in the cloud. There are hypervisors running virtual – and sometimes ephemeral – operating system images in addition to application containers such as Docker that further subdivide the landscape. There are mobile devices – some belonging to the organization and some belonging to employees personally – used to conduct business and a host of applications hosted all over the world used on a routine basis. It's a world of unimaginable complexity. Anyone saying that they can keep track of even a small enterprise's computing footprint in their head is either lying or fooling themselves.

This isn't a situation that developed overnight. Plenty of smart folks noticed early on that, with the advent and proliferation of distributed computing, complexity was increasing. As scale increased over time, the sheer number of computing devices obviously increased. With the increase in the computing footprint, interconnections between devices increased non-linearly. This is both hard to manage but also 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.

These architectural frameworks then represent efforts attempting 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.

Security guidance and standards

At the same time as there are multiple architecture frameworks, there are also a number of different security frameworks, standards, and regulations that, while not often containing architectural elements in and of themselves, are nevertheless important for the architect to understand. These include the following:

• Security standards: Formal standards that govern elements either of security for an entire program or organization or for specific elements of a larger program (for example, risk management, technical standards). Examples include ISO/IEC 27001 (Information Security Program Management), KMIP for cryptographic key management, TLS/IPsec for transport layer security, the Payment Card Industry Data Security Standard, and numerous others.
• Security management frameworks: Documents that, while not official standards, nevertheless provide guidance about how to implement and manage security within an organization. Examples include COBIT, the NIST Cybersecurity Framework (CSF), HITRUST, and the CIS Controls.
• Regulatory requirements: Governing legislation that contains elements applicable to information security. Examples include national laws such as HIPAA in the United States, the Cyber Security Law of the People's Republic of China, and local or regional laws such as US state breach notification laws.

Don't worry if you're not immediately familiar with all these. We'll spend more time discussing some of them later in this book. For now, just understand that they are important because they provide a backdrop for the general approach to security taken by the organization. They can also influence how and what technical controls are in the organization's security "toolbox," how they analyze and address risk, processes for the implementation and execution of security measures, goals such as measurement and metrics, as well as numerous other decision points. They also, particularly in the case of regulatory requirements, may dictate what specific security controls are mandatory and which are discretionary.

Security architecture frameworks

"In the early days, cybersecurity architecture was almost a "dark art": you had to understand a lot of different things all at once: the technology, the organization, the people employing the technology, regulations/standards, and the threat landscape. As we've gained in maturity, the discipline has been moving toward formalization since these early days; for example, there's been a push in the industry to formalize and merge the required skills as well as to introduce processes. These processes are important because, while we still need a number of different skills to ensure a quality job, standardization brings maturity which lets us ensure consistent, reproducible outcomes from architectural efforts."

– Dr. Char Sample, Chief Research Scientist – Cybercore Division at Idaho National Laboratory

More directly useful to the security architect relative to the preceding, there are also approaches that attempt to unify concepts from both the enterprise architecture world with security. There are multiple models (some more well known and some less), but the primary ones that we will investigate for our purposes are as follows:

• Sherwood Applied Business Security Architecture (SABSA)
• Open Enterprise Security Architecture (O-ESA) from the Open Group
• Open Security Architecture (OSA)

Given their importance to the serious security architect, we will briefly outline each of these approaches.

Sherwood Applied Business Security Architecture (SABSA)

"The value proposition of security architecture is simple. If you have a security architecture and you're able to understand how that architecture enables and supports achieving the objectives that you want, it gives you, as the owner of those objectives, confidence that you're really going to get them. If you do it with a methodology like SABSA, where you have traceability and measuring your security capabilities versus the risk exposure, then you can show with confidence that you are likely to obtain the result."

– Andrew S. Townley, Chief Executive Officer Archistry Incorporated

The SABSA framework provides a generic framework for security architecture efforts. As with many enterprise architecture frameworks, the philosophy of the approach stems from the belief that security architectures, like enterprise architecture generally, should map efforts back to underlying business goals and harmonize (that is, be aware of and synthesize) views and viewpoints from different stakeholders in the organization.

It's founded on the recognition that security in an enterprise – and thereby the security architectures that support the security function of that enterprise – do not exist as an end goal in and of themselves. Instead, they exist solely in service of – and to enable – the business. This means that any security effort should map directly and concretely to some business driver, goal, or end state desired by the business.

Originally discussed at the COMPSEC 96 conference in London (called SALSA at the time), the model has been subsequently expanded in more detail over time (see SALSA: A method for developing the enterprise security architecture and strategy in Computer & Security vol 15, Issue 6, John Sherwood). For those familiar with the Zachman Framework of enterprise architecture, there can sometimes be confusion about the relationship between SABSA and the Zachman Framework. Similar to SABSA, the Zachman Framework is also a matrix-based ontology with an X axis that uses interrogatives (who, what, when, where, why, and how) and a Y axis that uses architectural layers. Despite these superficial similarities though, the two models evolved independently. The confusion that arises is unfortunate because it distracts from a thorough and utility-based understanding of the models. Meaning, despite a superficial similarity in the ontology, the approach and philosophy of each extend well beyond just the visualized ontology.

The ontology is constructed as a matrix, with intersection points between a Y axis describing the layers of abstraction (from the most general to the most specific). These layers, from the most general to the most specific under SABSA, are as follows:

• Contextual Security Architecture
• Conceptual Security Architecture
• Logical Security Architecture
• Physical Security Architecture
• Component Security Architecture

Running throughout and in parallel to each layer is the "Security Service Management Architecture" view. This layer is different in that it applies to all layers rather than applying to only one.

The X axis contains the 6 basic interrogatives:

• What (Assets)
• Why (Motivation)
• How (Process)
• Who (People)
• Where (Location)
• When (Time)

Laid out as a grid, each cell of the grid contains a unique point that the architecture process must address to be complete. For example, at the intersection of the Y-axis "Logical Security Architecture" abstraction layer and the X-axis interrogative "What," you find considerations unique to that intersection point (in this case, "Information Assets") and supporting artifacts (in this case, "Inventory of Information Assets"). Page 16 of the SABSA whitepaper entitled "SABSA: Enterprise Security Architecture" by John Sherwood, Andy Clark, and David Lynas spells each out in thorough detail. You can find it at https://sabsa.org/white-paper-requests/.

Note that this book adheres quite closely to the SABSA model in the philosophy and approach that we take to security architecture. In fact, we've provided viewpoints and perspectives from many of the luminary voices from the SABSA community (for example, SABSA co-founders, authors, and "power users") to provide perspective on the topics we'll cover (you've seen a few of these already). The reason that we've done so is that the model is lightweight, easily understandable by all with the addition of a minimal time investment, and for the curious is accompanied by detailed supporting materials to supplement the excellent source material. From a process standpoint though, while we attempt to maintain compatibility with SABSA, we recognize that all SABSA source materials may not be readily available to all readers (some being available only commercially). As such, we will attempt to refer to SABSA where appropriate, but where we can, we draw primarily on materials freely available.

Open Enterprise Security Architecture (O-ESA)

One of the areas where many more formal security architecture models struggle is in the capacity to handle change within the organization. Recognizing that change in the technology ecosystem is a complicating factor and needs to be specifically accounted for in enterprise architecture efforts, the now-defunct Network Application Consortium (NAC) created a model for security architecture that specifically accounts for (in fact, presupposes and in some senses relies upon) the fact that change is both inevitable and a natural part of enterprise security efforts (see Comparing Security Architectures: defining and testing a model for evaluating and categorizing security architecture frameworks, Rob Van Os, master's thesis, Luleå University of Technology, Department of Computer Science, Electrical and Space Engineering, Luleå, Sweden, available at http://www.diva-portal.org/smash/get/diva2:1031560/FULLTEXT02.pdf).

This model, the Enterprise Security Architecture (ESA) model, was absorbed by The Open Group – an industry consortium consisting of over 700 enterprise stakeholders (https://www.opengroup.org/about-us) including IBM, Oracle, Philips, Microsoft, Boeing, and numerous others – who took over as steward when the NAC concluded its charter in 2007 (https://blog.opengroup.org/2011/05/16/the-open-group-updates-enterprise-security-architecture-guidance-and-reference-architecture-for-information-security/). Today, subsequently renamed as the Open Enterprise Security Architecture (O-ESA): A framework and template for Policy-Driven Security, it continues to provide value to security architects by embracing automation as the primary method to account for continued security in the face of near-constant technology change.

The model stems from a similar premise as SABSA; namely, that business drivers are the fundamental nexus from which all security efforts stem. O-ESA uses "governance" as the starting point and strategy for defining the principles, policies, guidelines, and standards of the organization as input into the architectural decision-making process.

Formally, governance in this context refers to the process of ensuring that IT efforts are in alignment with stakeholder and organizational goals. COBIT 5: A Business Framework for the Governance and Management of Enterprise IT, ISACA, an IT governance framework, defines Governance of Enterprise IT (GEIT) as "A governance view that ensures that information and related technology support and enable the enterprise strategy and the achievement of enterprise objectives. It also includes the functional governance of IT, that is, ensuring that IT capabilities are provided efficiently and effectively."

It should be noted that, throughout this book, we try to attempt to avoid using the word governance where possible. This is for the simple reason that the term is used often informally in a way that is contrary to the formal definition and the way that O-ESA intends. This creates confusion and can detract from, rather than adding to, the understanding of those confronting the material for the first time. Therefore, while governance (at least in its formal sense) is important conceptually to the architecture process (as its use within O-ESA highlights), we've tried to use specific language in describing what we mean.

O-ESA then describes an approach to creating policy, drawing heavily on ISO/IEC 27001 and ISO/IEC 27002 to do so. The model goes on to describe elements of "automated policy enforcement" – specifically, automated measures to ensure that policy is enforced throughout the organization; these elements include the following:

• Policy Management Authority (PMA) – the central authority responsible for setting policy.
• Policy repository/registry – a location where policy artifacts are stored.
• Policy Decision Points (PDPs) – locations (for example, software or hardware) where decisions are made about whether requests or actions are allowed or disallowed based on the governing policy.
• Policy Enforcement Points (PEPs) – locations (for example, software or hardware) where decisions about policy are enforced.

Open Security Architecture (OSA)

The last framework that we will look at is that of Open Security Architecture (OSA). OSA is a community-driven effort to develop a model for security architecture. By community-driven, we mean that it is a set of individual elements contributed by whoever has the willingness and acumen to do so, with subsequent peer review by others in the broader community. One way to think about this is along the lines of an open source software project. In an open source project, interested parties contribute to the development of the final work, such as a server (for example, Apache), tool (for example, Wireshark), operating system (for example, Linux), or any other software that might be of interest to the broader world at large. The model for OSA is similar; in this case, interested parties contribute to a repository of information about security architecture "design patterns" for enterprise security measures.

At the highest level of abstraction, OSA provides the contextual backdrop ("landscape" in their parlance) that allows meaningful contributions to take place. This includes a common set of terminology (to ensure that everyone contributing refers to the same concept the same way), actors (personas or roles of stakeholders in the security life cycle), a controls catalog (based on those outlined by NIST in their special publication 800-53), and a taxonomy – a map of relationships between elements of a security system.

The most directly useful element of the OSA effort though, at least from the point of view of the practically minded security architect, is the library of community-authored design patterns. Those with a background in software development (or those that have worked closely with developers) will likely be familiar with the term "design pattern." It essentially refers to a strategy for accomplishing a certain goal that can be used and reused when faced with a given situation.

Design patterns are essentially strategies for accomplishing a certain goal. In a software development context, they are strategies that can be described in a way that is agnostic of implementation and language. By describing these strategies this way, it allows developers to easily discuss and share those strategies when they are faced with a given problem that they may have never seen before. For example, a developer of an object-oriented program might wish to create an instance of a software object and interact with it via a defined interface; in so doing though, they might wish to leave the actual mechanics of implementing the functionality to someone else: either another piece of code they didn't write or in a way where the implementation can be dynamically changed at runtime.

To put more specificity on this example, a developer working in Java might wish to create and use a TLS-enabled socket (that is, a "secure socket") to send data but do so in such a way that the actual implementation of the socket (that is, the version of the TLS protocol supported, the cipher suite, and so on) is decided upon at runtime based on the defined policy of the system. There is a design pattern that accomplishes exactly this: in this example, the factory design pattern. In Java, this pattern is implemented (among other places) via the SSLSocketFactory class that follows and implements this pattern: it allows a developer to create and use a TLS-enabled socket without knowing the underlying implementation.

These design patterns are very powerful because they provide a concise, standardized way to describe the solution to a problem that others might encounter and describe those solutions in a concise, highly precise way. The landscape and high-level artifacts of OSA allow the creation of security design patterns that do this in a way comparable to the way that software design patterns perform. For example, an OSA contributor can create a design pattern to address any given situation that includes information about the solution (for example, a diagram or schematic), a list of the relevant controls or security measures that implement the pattern, as well as other information such as challenges and threats that the pattern is designed to defend against.

For example, OSA provides design patterns for securing everything from public web servers (pattern SP-008) to public Wi-Fi hotspots (pattern SP-007), to cloud computing (SP-011), to even a pattern that describes the entirety of a Payment Card Industry Data Security Standard (PCI-DSS) cardholder data environment (SP-026). These are only a small sample of the many design patterns that are made available through OSA.