What is cybersecurity architecture?

“Cybersecurity architecture is a fusion of architecture and cybersecurity. ‘Cybersecurity’ is a combination of ‘cyber’ (from the Greek word κυβερνήτης, meaning ‘helmsman’) and security (‘the freedom from risk or danger’). Putting these all together, it’s a model to produce an intended outcome related to freedom from technology-related danger.”

– Dan Blum, Cybersecurity Strategist, Security Architect, and author of the book Rational Cybersecurity for Business

The easiest way to understand cybersecurity architecture is through a comparison with the role of an architect in the physical world, such as one who is working on a large structure such as a bridge, tunnel, skyscraper, museum, or new house.

In the physical world, it’s easy to understand what an architect does. We all know that you can’t just forego planning and wing it when it comes to building a safe, durable, and functional structure. Would you, for example, feel comfortable riding the elevator to the 50th floor of a building where they decided to forego planning and just build it and see if it works? I wouldn’t.

But there’s more to it than just safety. There’s also ensuring the fitness of purpose – that is, ensuring that the structure meets the various requirements that drive the reason why the structure is being built in the first place. This could include the following for an example skyscraper building project:

• Financial and budget requirements: Can we build a structure that meets the intended requirements given the resources available?
• Aesthetic requirements: Will the finished edifice meet aesthetic expectations?
• Functional requirements: Is the building fit for purpose? For example, can the occupants of the skyscraper get where they need to go with minimal hassle?
• Timing requirements: Can we build the structure within the time allotted?

Again, this comes down to planning. In the preceding skyscraper example, can you imagine if someone built it but didn’t include elevators? An oversight like that would outrage occupants: no residential tenant would want to walk 50 flights of stairs and no business would hold on to customers who were required to do so. Such a structure would be illegal in many parts of the world for exactly this reason. In this case, the fitness of purpose for the building isn’t realized – and to remediate it after the fact would lead to tremendous expense, wasted time, and needless impact on the building’s occupants.

No – in the physical world, the value the architect brings to the table is obvious: they’re the keeper of the vision for the structure being built. It is their job to come up with a design based on the requirements of what the structure will do and what it’s for, to ensure the fitness of that design for the intended purpose, to make sure the result is realistic in light of the resources available, to work with the many specialists required to implement the vision (for example, to ensure the design is feasible and practical), to ultimately shepherd the project through execution as the final result is brought to life, and to do all the previous things safely.

This, as you might imagine, is easier said than done. It’s not a job that exists in isolation. Depending on the type of project, there can be numerous people – or even teams of people – involved: from specialized professionals such as geologists or hydrologists to tradespeople such as electricians and plumbers, to waste engineers and soil specialists, and it even requires in-depth discussions with and input from those for whom the structure is being developed (the ultimate users or inhabitants of the structure).

In the enterprise computing world, the role of the architect is directly analogous to the one we discussed previously. The parallel is so apt that there are often multiple different kinds of architects that can play a role in any technology system. There are system architects, network architects, software architects, cloud architects, data architects, and numerous others. What they all have in common is that, just like in the physical world, they are all the keepers of the vision for their particular area of specialization.

Just like the physical architect ensuring that their structure fits the purpose for which it is being built, the technology architect ensures the fitness for purpose of the technological systems in their area. They construct a design based on the needs of the organization and the goals that the organization is trying to achieve, they work with others to vet it and ensure it is feasible, and they craft a plan (in conjunction with other stakeholders and technical specialists) to make the vision a reality.

The cybersecurity architect then is the specific type of technology architect responsible for cybersecurity within an organization. Just like a network or software architect, the cybersecurity architect does the following:

• Identifies the goals and requirements for security
• Develops a vision for how to achieve those goals
• Works with other technical specialists to make sure that their vision is practical and feasible
• Works with those specialists to put a roadmap together
• Works in lockstep with other technologists to make the vision a reality

Network versus application security architecture

“There is a difference between network and application security. They work together, but they are very different: using different techniques and tools. One is not a substitute for the other.”

– John Sherwood, Chief Architect, thought leader, and co-Founder of The SABSA Institute

Just like there are different sub-types of technology architects generally (for example, data architect versus software architect versus network architect), there can also be different types of cybersecurity architects. This can be confusing because sometimes, it is not clear from a person’s title what a practitioner’s scope, focus, and purview are.

A cybersecurity architect within one company might be focused almost entirely on network infrastructure, while another with the same title and similar job description at another firm might focus almost exclusively on application design. Different types of cybersecurity architects have different scopes and different tools/methods that they use to help them achieve their goals.

In this book, we’ve chosen to focus on two different personas of cybersecurity architect: the application security architect and the network security architect. There are, of course, other specializations beyond this (data security architects, cloud security architects, and so on), and, usually in smaller or mid-market organizations, you can find those with a focus and goals that span both roles. However, we’ve chosen these two specializations for a few reasons:

• They are the most common. While there are potentially as many security architect specializations as there are technologies themselves, most cybersecurity security architect’s scope will fall into one of these two groups or (like a cloud security architect) potentially span both.
• They represent most tools/techniques that you will encounter. Other specialized sub-disciplines within cybersecurity architecture will likely adapt tools and methods from one of these specializations. For example, a security architect whose focus is on hypervisor deployment in a data center might predominantly leverage tools and techniques from the network security architecture world. Those working on securing a container-driven service mesh architecture might primarily use tools from the application security world.

Ultimately, context will dictate which of the tools and techniques we cover will be most useful to you and germane to your role. However, the versatile architect will have a working familiarity with approaches that address both the application and network side of the technology landscape.

The difference between architecture and secure architecture

“Everything has an architecture – whether you plan it or not. The more actively you engage with building and shaping that architecture, the more predictable your system is going to be. By ‘system’ here I mean it in the broadest possible sense: your system of getting things done.”

– Andrew S. Townley, Chief Executive Officer at Archistry Incorporated

Earlier, we learned what a cybersecurity architect does at a very high level. We looked at a very quick skeleton of what tasks are in the security architect’s role. Naturally, at this point, you may be anxious to move directly into the nitty-gritty of the day-to-day life of a cybersecurity architect. This temptation to start digging into the weeds is natural, but it’s better to begin with understanding the why instead of the how. This means understanding why organizations have a specific earmarked position of Cybersecurity Architect in the first place.

The fact of the matter is that any organization (including yours) will have a cybersecurity architecture. This is true no matter what you do. Even if you do nothing and completely ignore all principles of sound network design, sound application development, and all requirements and principles, you’ll still have a cybersecurity architecture – just not a planned, thought-out, and efficient one. Instead, it’ll be whatever architecture happens to evolve organically in an ad hoc fashion over time.

Having an architect at the helm of security design means having someone who is ultimately accountable for ensuring that the overall design and vision are efficient and effective. This is particularly important as human nature tends to favor entropy in design (that is, less mature, considered, and planned out).

Important note

This is generally true, regardless of context; for example, whether you’re talking about writing new software, deploying new commercial-off-the-shelf (COTS) applications, building networks, or adopting new technology (for example, the cloud).

Why does human nature tend to remove focus from planning phases? The reasons why this happens aren’t tremendously hard to understand. For the moment, let’s imagine a technology project as having three fundamental phases. This is a vast oversimplification for most projects, but bear with us:

1. Planning: The process of assessing requirements, marshaling resources to do the work, assigning work to resources, setting key milestones, setting a budget, and so on.
2. Implementation: The process of making required investments, setting resources to tasks, writing code, implementing hardware, and taking any other actions you may need to execute.
3. Maintenance: The continual process of maintaining the solution you’ve put in place to make sure that it continues to meet the goals over time.

Represented visually, this would look something like Figure 1.1:

Figure 1.1 – Generic execution process

Now, of these three phases, into which bucket does the attention of those doing the work tend to go? Stage 2 (implementation), right? Any new project represents an area of need for the organization. After all, if there’s no need to do a project, why would they undertake it in the first place? When there’s a need, there is pressure to address it. Often, stakeholders will apply pressure to actually make progress and sometimes view planning phases as delays that gate the organization from getting to a solution, implementing a fix, or addressing the need. The point is that there is often pressure within organizations to minimize the time spent planning.

On the other side, something similar happens with the maintenance and support aspects of the project. Here, there’s a similar tendency to de-emphasize maintenance implications and considerations relative to implementation. There can often be a “we’ll cross that bridge when we come to it” mentality where the focus is on getting the solution to work in the first place (closing the area of need) while leaving the work of sorting out the support and maintenance details until after the immediate pressure to address the need is met.

The point of all this is that most people (and most organizations) naturally feel pressure to move directly to the implementation of a project. This doesn’t mean that nobody ever plans – just that there can be pressure to minimize or de-emphasize non-implementation steps relative to implementation-focused ones. Additionally, as time constraints and real-world business needs drive planning cycles to be more modular, it can become harder and harder to see the big picture.

The benefits of building secure, resilient architectures

“For me, I always look at architecture first from an information asset perspective. What are the information assets in the scope and how will it be used functionally? I think of technical architectures as being comprised of the various components and subcomponents that enable the system functionally. This means that the security architecture needs to be aligned with the functional architecture to be successful.”

– John Tannahill, a Canadian management consultant specializing in information security

All of this highlights why, in a given project, human nature and business pressure work against some of the planning elements of the design. But who cares? Will an implementation that has evolved ad hoc, piecemeal, and organically be substantively worse in every case? No. It does mean though that it can be more difficult to optimize over the long term than a more planned, systematic approach.

To illustrate why this is the case, let’s consider another analogy: city planning. Most of us know that there are planned and unplanned cities. Planned cities are those where traffic, zoning, roads, and other aspects are based on human design. Unplanned cities are those that developed organically over time based in large part on the actions of the people living in them. Consider then the experience of driving (and navigating) through a planned city (for example, the Manhattan borough of New York City, Chandigarh, or Dubai) compared to an unplanned one (for example, Boston, London, or Chennai). The planned city might use a grid or ring approach, while the unplanned city might use road patterns that have evolved over time. For most non-native inhabitants, the planned city is easier to navigate: while they won’t know exactly what’s on a given road, they will know what direction the road leads in (and likely what other roads it intersects with) based on the planned design.

Likewise, there are benefits from a planned, structured approach to technology projects. Technology projects that are developed and fielded in a systematic way – where detailed attention is paid to the goals of the project, and where future-proofing and subsequent improvements that might be made down the road are accounted for – can have direct performance, operational, or maintenance (supportability) benefits right from the get-go. Likewise, future adjustments to the design or the incorporation of new components/technologies into the mix can be, in many cases, more effectively deployed when existing elements are laid out in a structured, organized way.

What is the point? The technology architect is responsible for coming up with the organizing principles that will be used for the project in scope to achieve this organized, planned result. In the case of a network architect, this means coming up with a design for the network that enables reliable, fast, and secure communications today and that can be most easily extended and upgraded tomorrow. In the case of the application architect, it is the same: they’re responsible for coming up with application designs that meet the requirements of users today but that can also easily be updated with new features should the need arise.

In the context of the cybersecurity architect, the same principles apply. The goal in this case though is to create a model and design for security that fulfills today’s security needs but that can also be easily extended when new features are needed, when the business context changes, or in any situation where adjustments need to be made to accommodate future activity.

The role of the architect

“When I hear security architecture, two things come to mind. First, there’s enterprise architecture: architecture for the whole of enterprise, where you attempt to create one set of documents that cover every possible security scenario. Then, there’s the more practical approach where you pick one area to focus on – a narrow set of services or capabilities – and create a well-defined architecture to support just that. One of the reasons you have these different camps is everyone wants to go straight to the technology. Instead, architecture needs to start with understanding the risk profile: risk should drive the architecture.”

– Steve Orrin, Federal CTO at Intel Corporation

The architect then is there to help make sure that technology projects fit into an integrated strategy. An architect comes up with a vision for the solution that guides the entire life cycle. Just like an architect working in the physical world on a building or bridge, the technology architect evaluates goals and constraints – things such as the goals and envisioned purpose, support and maintenance requirements, integration with existing technology, the strategic direction of the organization, and budget and resource requirements – to come up with an overarching design that makes the most sense for the organization. Once the architect has a vision in mind, they come up with a blueprint for how to execute that vision.

This is true for any architecture discipline within technology. Application architects, for example, develop and maintain a master vision of one or more applications; they make sure that new software (components, extensions, new features) fit well within the existing ecosystem and are consistent with the direction that the organization is looking to go in with their application portfolio. Likewise, network architects have a vision for connectivity. They create and maintain a master vision of the overall network, ensuring that new devices, new services, and so on fit efficiently and optimally within the larger framework so that service is maximized, and things keep running as smoothly as possible.

Cybersecurity architecture is no different. In a nutshell, security architecture is the process of ensuring the following:

• The approach to security within the organization is well-planned
• Resources are used optimally
• The goals of the organization (both security as well as business and functional goals) are met throughout
• There are measures in place that allow future growth and expansion

A security architect generally develops and maintains a vision of security for the technology elements and components within their scope. The more specialized network security architect is responsible for ensuring the design and execution of the security elements that apply to the network while application security architects do so for the security of applications that may be under development. For each, their role is to ensure that new work in security is performed optimally, that security goals are met, that deployment is efficient, and that the design of new security services advances rather than impedes the overall direction that the organization is trying to go toward.

The scope of the security architect can be narrow or specific. They might be responsible for one or more applications, a network or a set of networks, or the security controls and services within a business unit or the entire organization. A cybersecurity architect in one organization might be responsible for infrastructure controls such as firewalls, anti-malware, and intrusion detection systems (IDSs), whereas the cybersecurity architect at another firm might work hand in hand with developers to ensure that the security needs of a given product or application are met. Formal models and larger organizations might keep architects at a “big picture” level (where implementation and operations are handled by separate folks entirely), while smaller organizations or nimble teams might require architects to be involved in day-to-day operations. Other organizations might have multiple sets of security architects, each focusing on their particular area of specialization. The specific context within which the security architect operates will govern their areas of focus.

Secure network architectures

The role of the cybersecurity architect is, as we’ve discussed, the chief planner and vision-keeper for security within the organization. As mentioned, though, there are different types of security architects. One of the primary areas where cybersecurity architects will play a role is in the creation, design, execution, and operation of the secure networking and communications infrastructure of the organization.

Historically, most organizations (from the largest to the smallest) of necessity were directly responsible for maintaining their own robust network. The network served as the primary communications medium for employee collaboration (through services such as email, file sharing, collaboration tools, intranet portals, and numerous other avenues of communication) but they also had another role: the substrate upon which internal business applications were deployed. So, in addition to providing internal communication services (a valuable end in and of itself), the internal network also historically played a significant role in enabling business applications that make the organization run.

You might be wondering about the rationale for the repeated use of the word historically in laying out the preceding example. This is because, for many organizations, the functional role of the network itself is in a period of transition. Specifically, while the network is still very much the primary conduit for employee communication, much of the use of the network as the launchpad for internal services has migrated off the internal network to the cloud. This isn’t to say that all internal business applications are now cloud-based; after all, there will always be specialized applications (industrial control networks, biomedical applications, and other specialized hardware/software) that either can’t go to the cloud or, for security or functional purposes, it would be foolhardy to relocate there. But for many organizations that don’t have these specific requirements, much of what would have been fielded to an on-premises data center, to communicate over internal network channels, has been relocated to cloud environments.

Despite this, the network is critical to the way that business gets done in modern organizations. Not only are there still (despite the cloud migration we alluded to) internal applications that employees need access to, but there are also communication and collaboration tools that they need to use and that require network connectivity for them to reach. There is also an increasing array of mobile and cloud services that require internet access to reach them. Employees, business partners, guests, and others rely on the network for everything from checking their email, sharing documents and files, accessing cloud services and internal applications, conducting telephone calls (for example, via VOIP), and the numerous other activities involved in doing their jobs.

The role of the security architect in a networking context is to ensure three primary goals: confidentiality, integrity, and availability (CIA). Those familiar with security will likely recognize these fundamental concepts, given how critical they are to the discipline of security. However, applying these concepts from a network architecture point of view also means accounting for three other factors across multiple dimensions: effectiveness, resiliency, and depth. Effectiveness is very straightforward: are the security measures effective at doing what they need to do in enforcing the CIA goals? The last two require a little bit more explanation. Specifically, by resiliency, we mean not that the network itself is resilient (this falls under the existing pillar of availability in the CIA triad) but instead that the mechanisms that enforce those goals are resilient against disruption. Likewise, by depth, we mean that the mechanisms need to apply to multiple levels of the network stack.

Throughout this subsection, we’ll walk through each of these areas in detail. We’ll talk about CIA in general for those who might be unfamiliar with these concepts and then talk about resiliency and depth of coverage. We won’t get into the how-to (yet) of building a secure design as we just want to outline the specific requirements of what a secure design would entail in the first place.

CIA

The most critical underlying principle to secure network design is to ensure that the network facilitates the security goals of the organization more generally. These will likely be organization-specific to a large degree, but when examined from the highest altitude (that is, at their most abstract), they will likely generally align with the tenets of the CIA triad, as shown here:

Figure 1.2 – The CIA triad

For those who have some familiarity with the principles of cybersecurity under their belt, they will almost certainly recognize this acronym. For those that do not, it refers to the three core tenets of security:

• Confidentiality: The property that information is only disclosed to those that are authorized. This means that data is confidential to all those without a legitimate business need to know.
• Integrity: The property that information is reliable: it cannot be changed or modified unless performed by someone who is authorized to make that change.
• Availability: The property that resources and information can be accessed when needed.

Each of these elements is important from a network design perspective. Confidentiality is important because the design of the network should mean that conversations between parties who may need to exchange data that needs to be kept confidential should have a way to do so. There are numerous strategies for accomplishing this: using encrypted network protocols (SSH, TLS, IPsec, S-MAIL, and so on), network segmentation (that is, creating sequestered network zones where those not on the same VLAN, segment, and so on can eavesdrop on cleartext traffic), tunneling insecure ports over secure protocols, as well as dozens of other strategies.

Integrity is the capability to ensure data quality is not affected by deliberate tampering or accidental degradation. This can also be facilitated at the network level. Some protocols can help enforce integrity during transmission, applications and hardware can enforce it during storage, and strategies such as blockchain can enforce it against deliberate attack. Once again, even internal segmentation can help drive integrity goals as fewer individuals with access to data, files, or other artifacts result in fewer people who can manipulate them in undesired or unauthorized ways.

Availability refers to the property where services that people need to use are available for use when needed. As a practical matter, natural and man-made disasters can impact availability – for example, when data links are down – as can human agents (for example, denial of service attacks against the network). Just as there are both design strategies and countermeasures that foster confidentiality and integrity, so too can both strategies help with availability. Tools such as DDoS prevention can help mitigate certain types of attacks, whereas high availability, redundancy, and load-balancing strategies can be incorporated into the design to help with natural or man-made disasters.

The point of all this is that it is the job of the network security architect to create designs that account for and preserve each of these properties. More specifically, it is the job of the security architect to understand which of these tenets apply in a given situation based on the business needs and what the relative priority of a given tenet is based on context and requirements, and to craft solutions that address them appropriately given that information.

Designing for resilience

“There are businesses that seem to be able to continue to get their job done and function without disruption. This is the primary goal of cybersecurity architecture: to be able to function and continue to perform work functions despite what’s going on around you. In general, organizations want to be resilient – to execute their mission with a minimum of disruption; if you can show a track record of value in an organization or point to organizations with a track record of resilience and explain how a robust architecture can get you there, you gain credibility and help pave the way for architecture efforts.”

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

One of the primary considerations for the network security architect is designing the network to be resilient. We’re referring to the ability of resources to remain available and protected despite unexpected events, natural and man-made disasters, attacker activity, and any other unforeseen situation. Resources in this context refer to anything and everything employees or the business need to accomplish the organization’s mission: everything from the ability to conduct conference or voice calls, to remote working and telepresence, to email and other messaging tools, to internal or external business applications. Even something simple such as access to files or the ability to call a coworker can be a resource in this context.

It is an important property of availability that the network is designed such that it continues to operate and provide the right access to the right people, even in adverse situations (such as a pandemic, flood, earthquake, or communications disruption). The way that this is done must, out of necessity, change somewhat depending on what might impact the network and how. For example, ensuring access to services during a natural disaster (something such as a flood or inclement weather) is a very different proposition – using different tools and technical strategies – compared to a situation instigated by human action (such as a human attacker).

However, there is more to the resilience design aspect than just these availability concerns (important though they are). Specifically, it is also important that the mechanisms that enforce CIA are themselves resilient against disruption. For example, should a major catastrophe happen, confidential data is kept confidential, data remains trustworthy, and services remain available. By analogy, think of a bank. Would it make sense to design a vault that would unlock itself and open the door if the fire alarm is pulled? No, right? Even if there is a fire (or threat of fire), we still want to keep the assets protected.

With this in mind, there are a few different individual goals when it comes to the overall design of both the network as well as the security mechanisms used by the network:

• High availability: Ensuring network-based services and tools remain available during natural and/or man-made disasters such as earthquakes, floods, fires, or pandemics
• Resistance to attack: The degree to which network countermeasures mitigate or thwart attacks by human or software threat agents

A secure network design will enable both goals. In the case that the architect has direct input into the design of a new network, the security architect will work directly with the engineers and other network architects to make sure that these properties are baked into the overall network design; in situations where the network already exists (in many cases, designed and built without these goals in mind or with minimal focus on security), they will work with other stakeholders to build out a portfolio of countermeasures and improvements that help increase resiliency after the fact.

“Depth” of coverage – securing the stack

The last dimension for the network security architect is the need to address security at all layers of the network stack. Security shouldn’t just apply to a subset of the network, but instead to all levels.

One of the most powerful conceptual tools in the IT world is the networking stack. Most technology practitioners have some familiarity with either the OSI or TCP/IP stacks. OSI (Figure 1.3) divides networking communications into seven layers (application, presentation, session, transport, network, data link, and physical):

Figure 1.3 – The OSI model

The TCP/IP model (Figure 1.4) divides it into four layers (application, transport, internet, and link):

Figure 1.4 – The TCP/IP model

As you can see, each layer of the stack is comprised of specific technologies, protocols, software bindings, and other artifacts that accomplish a particular aspect of delivering data between nodes on a network. For example, protocols that encode individual bits as electrical signals on a wire or as individual pulses of light on an optical fiber are defined in layer 1 of both models (the physical and network access layer in the OSI and TCP/IP model respectively). Protocols that group individual bits into more complex structures (frames and packets, for example) occur higher up in the stack, and protocols responsible for delivering those packets to destinations outside the current local network are higher up still.

This network stack concept is powerful because it allows a technology professional to deliberately limit or compartmentalize their scope to only a subset of the network rather than needing to weed through tremendous complexity every time they need to accomplish a particular task. This means that engineers can focus only on one particular layer of the stack at a time; by doing so, they can compartmentalize complexities associated with other levels of the stack that aren’t relevant to the question they are trying to answer. For example, consider a network administrator looking to understand why traffic is not being read by a given application. They might start by looking to ensure that the network is routing traffic correctly to the destination – looking at the IP protocol at layer 3 of the OSI stack. From there, they can either diagnose and debug the problem or, if they are unable to solve the problem by looking at layer 3 in isolation, expand their analysis to include other layers and consider them each in isolation until they do.

The fact that the network stack is organized in this way adds both complexity as well as opportunity for the network cybersecurity architect. It adds complexity because the architect is responsible for all the levels of the stack and therefore needs to account for all of them in their vision. This means that they need to factor all levels of the stack and how they are implemented in the organization into their planning; it also means that they need to select and apply appropriate security countermeasures in that plan. This adds complexity because, as anyone who’s looked at traffic on the network can tell you, there’s a lot of surface area when considering all layers of the stack. The fact that the architect’s role is so all-encompassing also means that countermeasures they put in can either span multiple levels of the stack or target a different area of the stack other than where the problem occurs. For example, a network security architect seeking to address an application issue (layer 7 of the OSI stack) might target another level of the stack to resolve the problem.

As an example of this, consider an application that might not have a facility for strong authentication of users: maybe it requires a username and password but doesn’t use a secure channel such as TLS for transmitting that username and password. The ideal strategy is to address this – a layer 7 problem – at layer 7 itself. But what if that’s not feasible? Say, for example, that the application is supplied by an external vendor and they are unwilling or unable to close that particular issue. So, the architect, knowing that there might not be an optimal layer 7 solution to the issue at hand, might decide to implement a solution at a lower level of the stack. For example, they might consider tunneling the traffic, using filtering rules to ensure that only users from inside a trusted zone can access the service, and so on.

The job of the network cybersecurity architect is to ensure that the solutions that they create, the network design that they work with other stakeholders to build and hone, and the countermeasures that they deploy protect the network fully and comprehensively – that is, at each level of the stack.

Secure application architectures

“There is another value in architecture in that it adds speed to a release process. Just like writing testing software in code slows down the first few releases but speeds up all the rest of them, so too does architecture make the first design iteration maybe take a little longer – but all future design work that leverages it will go more smoothly and more quickly.”

– Adam Shostack, President, Shostack & Associates

From the standpoint of end goals, the remit of the application security architect is like that of the network security architect: ensure the security of the entities in their scope. In this case, though, instead of focusing on the infrastructure that helps enable application delivery, they focus on the applications themselves: ensuring that they are built with security in mind, that the process of building them satisfies security goals, that they have appropriate and strong security features built into them to achieve those goals, and so on.

For the application security architect, the specific responsibilities, actions, and – most importantly – goals depend to a large degree on the phase of the development effort that the organization is undertaking. For example, there are different goals and approaches for projects in the following areas:

• Requirements: Outlining and documenting what the scope and purpose of the application are.
• Development: While the software is under active development – namely, the period from ideation to release, either for new software or updates to existing software. Note that this includes any interim, pre-release phases such as unit testing, integration, functional and performance testing, building, and any other phases of the life cycle that may apply to a given organization.
• Release: The process of deploying the software to production. This includes the release process itself, followed by immediate pre and post-release actions such as shakeout and production deployment.
• Support: Post-release updates, support, and maintenance.

This section outlines some of the main concerns and goals of an architect during each of these phases. In addition, just like cloud adoption and externalization have muddied the waters in the networking space, so too have evolutions in the software development process added complexity to the application space. As organizations and software development methodologies have evolved, the pace of code release has increased.

Important note

The pace of release has accelerated to the point that now, in many organizations, software release is continuous or nearly so. We’ve seen new continuous development models emerge along with DevOps (and DevSecOps) alongside breakneck release timelines; Amazon, for example, has reported that they deploy new production code every second (https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html) while Google reports that they conduct over 4 million builds on the average day (https://thenewstack.io/google-reveals-the-secrets-of-devops/).

While the goals of application-focused security architects are the same in models where the delineation between phases is blurred, it may be a little harder to see clearly; additionally, since some of the tools and techniques associated with the architecture process must, out of necessity, be different in this context, we’ve elected to include a separate discussion in this section about these models specifically.

Requirements and design

“The most important ingredient to the security architecture process is understanding what the business (or technology peers) are trying to do. Understanding what a system is for – the broader context and why it exists in the first place – is absolutely essential to ensuring the right security design.”

– John Kallil, Chief Information Security Officer

During the earliest stages of planning, the architect is involved in making sure that security requirements are captured and that key features reflect not only important elements of security (for example, authentication, protection of data, data integrity, availability, and so on) but also that misuse cases (for example, how the application might be attacked or features subverted) are considered along with the use cases or user stories that are used as input in the application design process.

Development

During the period when software is being actively developed, the life of the cybersecurity architect is very busy. At this stage, the architect must create a plan for the application and an overall design that addresses a few different considerations:

• Security functionality: Strategies to ensure that any functional security requirements are addressed securely. This includes features such as user account management, administrator and user authentication, logging and monitoring features, secrets management (for passwords, API tokens, cryptographic keys, and so on), availability considerations, and others.
• Threat mitigation: Strategies to ensure that the application is resilient against attack or accidental misuse. This includes input tampering or over-run, insecure business logic, race conditions, or any other flaw in the software that could allow or facilitate unauthorized activity.

As you might imagine, each of these areas of focus has its own tools and techniques to achieve the optimal effect; we will discuss some of these tools and techniques in more detail in subsequent chapters as we explore the ins and outs of how to create a cybersecurity architecture for an application. For now, though, the important point is that the design phase of an application provides the architect with an optimal time to make large, sweeping changes to the security profile of an application.

Software engineer and professor Barry Boehm famously pointed out in Software Engineering Economics, Prentice Hall PTR, that the cost of fixing a software flaw increases non-linearly over time; in other words, the farther along in the development life cycle a flaw is discovered, the more expensive it becomes to fix. Graphs such as the following one, representing the cost of a software defect over time, are still often informally referred to as Boehm’s Curve in honor of this insight (Figure 1.5):

Figure 1.5 – Boehm’s Curve (or Boehm’s Law)

Just like fixing a defect, changes made to the security model of an application are much more easily and cost-effectively addressed earlier in the life cycle than they are later. Consider a security defect, for example: a security vulnerability that could undermine a key portion of the application or that could allow an attacker a method to subvert the application. Should a developer find a bug like this immediately after authoring the code that contains it, fixing it is relatively simple: they just modify the offending code, test it, and call it a day.

But what happens if they do not find that bug until much later in the process? Say, for example, they discover it after they have shipped a million units of that software across the globe. At that point, the complexity – and cost – of applying the fix is comparatively astronomical: the developer still has to update the source code and unit test it the way they always would. However, there are other things they also now need to do: integration test the change against the rest of the product, slot it into a release, rebuild the software, release a patch, notify users of the issue and encourage them to patch, and then support the patch (knowing that it will invariably fail for a subset of users). This of course assumes that they can notify users in the first place. As we all know quite well, many times they will not, leaving potentially hundreds or thousands of users vulnerable to the issue.

Therefore, not only must the architect design a vision for the overall security of the application during the design and development phases, but they must work extra hard to ensure that they have thought through how the application will be used, how it might be attacked, and any budgetary or resourcing constraints that would be imposed by their design, and they must also socialize and gain acceptance for their design (and the changes that design requires) from the engineers authoring and developing the software. Just like other features, not every security goal, feature, and countermeasure will ultimately make it into the initial release of the application.

Release

During the release process, security is also an important consideration and goal for the architect. At this point, because of their efforts during the development phase, the architect will ideally have a solid design for the application that is implemented (to a greater or lesser degree) within the application as the organization fields it to production. As you might expect, there will likely be some aspects of the security model, vision, and design that will require orchestration during the release process to work and perform optimally.

As an example, consider the situation where the architecture calls for the use of cryptography as part of the application security model and overall design. During the development process, the security architect would work with the development team to create the logic behind this, but reasonable security hygiene would preclude using the same secrets (keys) during development as what will ultimately be fielded into production. Therefore, the process of actually creating those production keys – and storing them in a location where they are themselves appropriately protected – needs to happen during the release process itself.

There are often quite a few tasks like this that will be required when an application enters production. These can include secrets, as in the preceding example, but they can also include deploying new hardware or software security products, reconfiguring existing hardware or software, user training and education, executing scripts, or any other release-related task that the application might require.

The upshot? While during the development phase, the architect will be heavily involved in the planning and design decisions, they may take a more active role as a problem-solver, troubleshooter, and even active participant in development.

Support

Once the application is released, the focus of the architect shifts once again. This is where the work gets the most interesting for the architect as there are multiple areas of focus that they must maintain simultaneously. These are as follows:

• Execute the long-term vision
• Respond to unanticipated behaviors of the application in the field
• Participate in the design of future iterations of the application

As we mentioned during the preceding discussion, it is highly likely that some of the security features, along with countermeasures required to keep the application secure, may not make it into the first release. This can be because those features would require slowing down the release to implement fully and in time for a scheduled deployment. For example, they might be dependent on application functionality which is scheduled for a subsequent future release. It is almost certain that there will be something that will need to be addressed in future iterations. Working with other stakeholders, the security architect will need to continue to work to get these deployed over the long term.

In addition, just like there are hiccups in new applications, so too can there be unexpected events that arise in security features and security controls. As part of the support process, the architect will need to be involved in ironing those out. These can be bugs in security features that are intrinsic to the application, they can be emergent behavior that can only be seen once the application usage reaches a certain scale, or they can be bugs or unexpected behavior in security products, tools, or countermeasures that were deployed to support the application.

Lastly, don’t forget that it’s rare for an application to have one release and never get updated subsequently. It’s almost certain that as an application enters the support phase for a given release, the next release will almost certainly be entering (or will have already entered) the design and development stages for new features. So, just like the architect needed to plan security features and protections around the initial release, so too will subsequent releases bring with them modifications and necessary changes that the architect will need to be involved in.

Building security in

Now, you may have noticed that in looking through the lens of these phases, the specific goals and tasks of the architect are clear at each phase when they’re laid out in this way. Likewise, you can probably realize how and why the architect changes their approach and focus somewhat on the portion of the cycle that they are in. But the truth is that it is more complex than it seems based on just looking at these discrete, monolithic phases. This is because most new software being built in enterprises today no longer uses such clearly defined phases. Instead, the lines between phases have blurred – or in some cases, they’ve disappeared entirely.

In other words, under legacy models such as waterfall, development phases were closer to clearly defined, boundary-aligned steps with clear gates between stages, ultimately leading to a developed project. It was never perfect even under waterfall as some phases (for example, testing) were always iterative and not a one-shot, monolithic process. However, newer models have less clear differentiation than even that. For example, DevOps blurs the lines between “development, release, and support” and approaches such as continuous integration/continuous development (CI/CD) mean that each portion of the cycle may be so compressed as to be almost meaningless.

What’s important to note about this is that the goals of the architect – and the scope of what they are called upon to do – don’t change substantively even when the development models don’t have clearly defined phases. We’ve described them above through the lens of having discrete phases to illustrate the focus and key aspects of the architectural role in each area, but ultimately, the architect is still focused on developing a clear vision (of the application’s security profile, security features, use and misuse cases, and how it might be attacked) for the application, regardless of the underlying model used to author and deploy it.

One additional substantive part of the architect’s job that models such as DevOps and CI/CD can help illustrate is the role of architecture in the development methodology and release process itself. Architects often have a stake in how software gets developed in the first place. This means that they can have a role in ensuring a process that fosters reliable, consistent, and secure outcomes. Under a waterfall model, this might mean that they incorporate security design reviews, manual or automated software security testing, code review, or other checkpoints or gates into the release process. Under agile, it might mean that sprint reviews include time to specifically discuss and evaluate security topics and features. Under DevOps, it might mean an automated security testing capability integrated into the pipeline. In all cases, it also likely means a culture built around security: by training developers on security coding techniques, by supplying components (for example, cryptographic modules, authentication components, services, or other software) to encapsulate and provide security functionality, or numerous other techniques.

The distinction between what is built and how it’s built is subtle, but the outcomes of each are interrelated. Aldous Huxley, in Ends and Means: An Inquiry into the Nature of Ideals, Routledge, once famously said the following:

“The end cannot justify the means, for the simple and obvious reason that the means employed determine the nature of the ends produced.”

By this, he meant that the way that you derive something ultimately dictates what the result will be. In the context of software development, this means that if you follow a slapdash, disorganized process, then you will tend to wind up with a slapdash, disorganized result – a result that is more likely to have vulnerabilities, security flaws, weaknesses, and other undesirable security properties.

If instead, you follow a process that engenders security – where security is accounted for and actively espoused during the development process – the resulting software will tend to be more resilient than would otherwise be the case. Therefore, ensuring that the result is secure requires an effort to build security into the software development life cycle. The tools, techniques, and processes to do this will vary from organization to organization, depending on their culture and context; this means that, for organizations where this is a goal, it is often the remit of the security architect to create a vision for those mechanisms to the same degree that they are responsible for ensuring the security of the software itself.

Case study – the value of architecture

“To me, security architecture is a function of building a strong understanding of the resources you have in play and the way that they communicate with each other. This is so that you can properly identify, analyze, and mitigate risk. Remember the ‘operators’ in The Matrix? They looked at the console and the matrix code and were able to interpret what was actually going on from that. This is what architects do: they read the signals and translate signals from the technology side of the organization to what is really going on – from there, they figure out what will best support the mission and keep everything running smoothly and safely.”

– Pete Lindstrom, Security Architect and Analyst, Spire Security

When asked in an interview about the value of security architecture and what it brings to the table, security architect and analyst Pete Lindstrom offered the following perspective. He explained that one of the main sources of value in having a defined and systematically created architecture is that it can highlight unforeseen (or difficult to foresee) risk areas. He went on to describe three related instances to highlight this relationship between risk and systematic planning. Each of the scenarios he described is different, but the through line is the impact associated with a lack of planning and the risks that can arise as a result.

First, he outlined an experience early in his career:

“I always used to downplay physical access until one day my desktop computer at work was stolen. In fact, not just my desktop but over a dozen desktops throughout the building. In this case, there wasn’t any requirement to physically secure equipment (for example by bolting it to furniture or to the floor). In this particular location, we’d had a few ‘smash and grab’ thefts in the past – but in general, we were much more concerned about the data center instead of the equipment left on people’s desks.”

The second example was in a large, publicly traded, highly decentralized, pharmaceutical firm. One day, a new temp (short-term, temporary employee) started working there. Everything seemed normal at first: they were told to expect a temp, and sure enough, a temp showed up. There was, however, more to it than what initially met the eye:

“There was a mixup along the way. The actual temp never arrived – but a patient from the mental health facility down the street did. This person left the facility, came into the office, and started working. He also started living there: sleeping in the conference room, eating food left in the kitchen, etc. Due to some unanticipated process challenges, he was accepted right in with no one being the wiser.”

The last situation he told us about was a situation where the pipes burst over a data center:

“Another organization I worked with built a new data center but didn’t account for the fact that higher floors had water pipes running the length of the building. One day, the pipes burst, bringing about catastrophic damage to the equipment located on the lower floor in the data center. This led to a ‘rapid fire’ remediation – however, much of the improvements were of the ‘lessons learned for next time’ variety because of the fact that moving the data center or changing the location would have been so cost-prohibitive.”

There are two things to note about these examples. The first is that you’ll notice that you don’t need to be super technical to understand the challenges here. There’s no fancy technology involved to appreciate the risks (this is one of the reasons that we’ve chosen to highlight these examples now before we start talking about the technology side of the game).

The second thing to note is how these situations all arose – specifically, through missteps in the security vision. In the first instance, something as simple as failing to account for physical security challenges led to the loss of some very critical and sensitive information. In the second example, failure to account for possible breakdowns in the authorization and temp employee onboarding process led to a (very) unexpected threat scenario. And, in the last case, unintended consequences led to water damage to critical equipment.

Would a robust architectural approach have prevented all these problems? Since nobody can foresee every eventuality ahead of time, maybe yes and maybe no. However, the chances of preventing a situation like this ahead of time are improved through systematic planning and security architecture.

Architecture, security standards, and frameworks

Knowing 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. At the beginning of 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 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:

• Atelier de Gestion de l’Architecture des Systèmes d’Information et de Commun vication (AGATE) 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
• British Ministry of Defense Architecture Framework (MODAF); see https://www.gov.uk/guidance/mod-architecture-framework
• NATO Architecture Framework Version 4 (NAFv4)
• 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 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 while 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 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 co-location 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 – that are 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 increased. With this increase in computing footprint, interconnections between devices increased non-linearly. This is both hard to manage and 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 optimally 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

However, the challenge with so many different architectural frameworks 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 several 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 and 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 (PCI DSS), 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 may also, particularly in the case of regulatory requirements, 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

There are also approaches that attempt to unify concepts from both the enterprise architecture world with security, which are likely to be more directly useful for the security architect. 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 serious security architects, 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 at 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. So, 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 six 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. 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 everyone (some being available only commercially). As such, we will attempt to refer to SABSA where appropriate, but where we can, we will 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.

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 follows:

“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 will 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 add 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 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 lifecycle), 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.

However, the most directly useful element of the OSA effort, at least from the point of view of the practically-minded security architect, is its library of community-authored design patterns. Those with a background in software development (or those who 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. Describing these strategies this way 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, which 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 PCI-DSS cardholder data environment (SP-026). These are only a small sample of the many design patterns that are made available through the OSA.