"I think it's useful to recognize that different stakeholders have different viewpoints. As an example, imagine you are standing on a hill: in front of you there is a valley and mountains to the east and west. Multiple people in that same setting will have a different viewpoint depending on where they are standing and the direction they look. This is similar to enterprise architecture: different disciplines, users, and stakeholders have a different view depending on their focus. The security architect needs to be able to see all these views at the same time. This is because security is a cross-cutting architectural concept that can't be singled out and put into its own, separate box. Instead, it needs to cut across the whole organization and take these different viewpoints into account."

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

There are numerous unknowns involved in putting the right plan in place for security in a given organization. Creating the right plan involves answering tough questions such as the following:

• What will attackers do next?
• How will their techniques evolve in ways we haven't planned for?
• How will new technologies impact our organization's security model?
• How will new business opportunities impact our security?
• How can we know that we're secure – that we've secured the organization appropriately?
• How do we use our limited resources in the best way possible?

There's no magic bullet, panacea, or sure-fire way to answer all these questions. But there are strategies that help do so.

Cybersecurity architecture, the discipline of planning out strategically the security measures of the organization, is one of those strategies. As cybersecurity architects, we will work to create a blueprint for security measures in our organizations. We'll plan out what the security profile should look like – and subsequently work with stakeholders in the organization to make the plan a reality.

Security architecture provides us with a systematic way to guide our organizations to the most effective security measures; to identify where they will provide the most benefit, who they'll provide the most value to, when they should be implemented, and why the organization should select one over another. It can help us know whether the measures we put in place perform effectively and do what we need them to do. It can help us know that the resources we have are being used in an optimal and efficient way.

All this doesn't happen magically. Cybersecurity architecture takes work. It involves creating the long term "vision" for security, "selling" that vision to stakeholders throughout the organization, charting a realistic roadmap to move from the current state to the proposed future state, working with subject matter experts and others in the organization to execute the roadmap, reacting to unexpected developments and unforeseen challenges, and ultimately working over the long term to implement improvements.

The reality is that architecture is a craft. And like any craft, it involves a combination of artistry, creativity, planning, and knowledge. Also, like any craft, becoming a master takes time, persistence, and discipline – though it's accessible to anyone willing to put in the time and persistence to learn.

We've written this book for two reasons. First, we hope to provide someone new to a security architecture role a roadmap that they can follow to be successful in their jobs. To do that, we've tried to outline the methods and techniques that have worked for us and distill down guidance from successful architects in the field about what's worked for them. For someone completely new, this allows them to get started quickly and get a jump on the learning curve.

Second, for more experienced professionals, we've tried to provide insights and tips that will help them improve. There are as many ways to be a cybersecurity architect as there are architects themselves and there's no right or wrong way to do it (the right way is the way that works). By pulling together experiences from an array of practitioners, our hope is that some of their techniques can help spark creative new approaches in your own practice that lead you to a higher level of proficiency.

Understanding the need for cybersecurity is only the first step in this book. To develop the best, most robust cybersecurity, you need to plan the architecture of your systems. In the next section, we'll gain a fundamental understanding of 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 a 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 fiftieth 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 fitness of purpose. Meaning, ensuring that the structure meets the various requirements that drive the reason why the structure is being built in the first place. This can include the following:

• Financial and budget requirements
• Aesthetic requirements
• Functional requirements (that is, that the occupants of a skyscraper can get where they need to go with minimal hassle)
• Timing requirements

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. In fact, 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 and input with 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. The parallel is so apt in fact 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 for the technological systems in their area. They construct a design based on the needs of the organization and the goals that 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

Actually, 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 architect. This can be confusing, because sometimes it is not clear from a person's title what a practitioner's scope, focus, and purview is.

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 architects' 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 with 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 (that is, a "virtualization security architect") might leverage tools and techniques predominantly 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. Meaning, understanding why organizations have a specific earmarked position for a 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 is 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 a 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. Let's for the moment imagine a technology project as having three fundamental phases. This is obviously a vast oversimplification for most projects, but bear with me:

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: 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 "delay" that is gating the organization from getting to a solution, implementing a fix, or addressing the need. The point being, 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, 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 it. 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 uses road patterns that 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.

There are likewise benefits from a planned, structured approach in 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.

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 the 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 of course true about 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 there 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, for a network or set of networks, or for 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 an intrusion detection system (IDS), 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. Yet another organization might have both sets of security architects, each focusing on their particular area. 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, 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 too: the substrate upon which internal business applications were deployed. Meaning, 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.

The astute reader might wonder the rationale for the repeated use of the word historically in laying out the preceding. This is due to the fact that, 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, some 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 therefore 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" here 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 at 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 that might be unfamiliar with these concepts and then will talk about resiliency and depth of coverage. We won't get into the "how to" (yet) of building a secure design, but instead 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) will likely generally align with the tenets of the "CIA triad," pictured here:

Figure 1.2 – The "CIA" triad

For those that 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. Meaning, 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 away to do so. There are numerous strategies for accomplishing this: the use of 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), the tunneling of insecure ports over secure protocols, as well as dozens of other strategies.

Likewise, integrity – the capability to ensure data quality from deliberate tampering or accidental degradation – can also be facilitated at the network level. There are protocols that can help enforce integrity during transmission, applications and hardware that can enforce it during storage, and strategies such as blockchain that 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 results in correspondingly fewer people who can manipulate them in undesired or unauthorized ways.

Lastly, availability. Availability just means that the 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 refers to anything and everything employees or the business needs 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 actually done must, out of necessity, change somewhat depending on specifically 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 therefore 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 in" to 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 to 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. Meaning, 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 layers):

Figure 1.4 – The TCP/IP model

As you can see, each layer of the stack comprises 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 together individual bits into more complex structures (frames and packets, for example) occur higher up in the stack, and protocols responsible for delivery of those packets to destinations outside the current local network are higher up still.

The point? 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 each and every time they need to accomplish a particular task. Meaning, 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 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 though 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 the transmission of the username and password. Obviously, 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. The architect then, 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 then 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 to enable application delivery, they instead 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 be applicable 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 the architect during each of these phases. In addition, just like cloud adoption and externalization has "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, 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 with 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 for the architect an optimal time for 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, that the farther along in the development life cycle a flaw is discovered, the more expensive it becomes to fix. In fact, 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. For example, 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.

What happens though if they do not find that bug until much later in the process; say, for example, 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 – but now, they also need to integration test the change against the rest of the product, slot it for a release, rebuild, release a patch, notify users of the issue and get them to patch, and then support the patch application for the host of users it will invariably fail for. This of course assumes that they are able to notify all 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, they must work extra hard to ensure that they have thought through how the application will be used, how it might be attacked, any budgetary or resourcing constraints that would be imposed by their design, and they must socialize and gain acceptance for their design (and the changes that design requires) from the engineers actually 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 undertakes fielding 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 obviously 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 can also include deploying new hardware or software security products, the reconfiguration of existing hardware or software, user training and education, the execution of scripts, or really 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 problem-solver, troubleshooter, and even active participant in development.

Support

Once the application is released, the focus of the architect shifts once again. In fact, 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 in time for a scheduled deployment, because they are dependent on application functionality that itself is scheduled for a subsequent future release, or any other reason. In fact, 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 a rare application that has one release and doesn't ever get updated subsequently. Meaning, 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 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 notice that in looking through the lens of these phases, the specific goals and tasks of the architect are clear at each phase when laid out in this way. You can likewise 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; 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 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 in nature 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 CI/CD (continuous integration and continuous development) 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 really change even when the development models don't have clearly defined phases. We describe them as done precedingly for the purposes of illustrating 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. Meaning, 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 clearly inter-related. Aldous Huxley, in Ends and Means: An Inquiry into the Nature of Ideals, Routledge, once famously said that "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 end result is secure requires an effort to "build security in" to 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.

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.

"If your only tool is a hammer, every problem looks like a nail. Meaning, if you talk to a developer or someone who is a product security manager about security architecture, they are going to focus on the software life cycle or how to build controls at various application trust boundaries. If you talk to IT operations, they are going to tell you about segmenting the network and hardening the perimeter. To me, security architecture is more holistic: it's the overall set of processes, policy, people, technology, and controls that ensure security goals are aligned with business goals."

– Ted Ipsen, President and COO at Positroniq, LLC

In this chapter, we've discussed what security architecture is conceptually, describing and providing an introduction to some of the standards and frameworks that are involved in effecting it in an organization. The last topic that we will cover before we get into the "meat" of actually performing the work of the architect is that of the roles intersecting the architect's work as well as an overview of the architecture processes that we will describe in depth and explain how to perform throughout the rest of this book.

First, we'll walk through adjacent roles that the architect will need to work closely with – and that it's helpful for them to have an intimate understanding of – in the course of doing their work. These areas, while not exactly a prerequisite to being an effective security architect, can provide quite a bit of value because they intersect so closely with the work that the architect must do. This means that the more understanding of these related disciplines the architect can develop, the more effective they are likely to be and the more productive the conversations they have with the professionals in the roles that they may need to work with directly in the course of realizing their vision will be.

After that, we will walk through the process (at a high level) that we will explain throughout the course of the rest of the book. While there is no "right way" to perform the work of a security architect (the "right way" is the way that works for you), we will describe one approach that has worked successfully for us in doing so. Our intent in providing it is to give those new to the discipline a starting point that they can follow to actually do the work successfully and to share our experiences (and, more importantly, the experiences of others in the profession) with more veteran practitioners who may wish to incorporate new or different techniques into their approach.

Lastly, we'll walk through (at a high level) the key milestones and tasks involved in the high-level process that we describe. Note that we won't go into much detail yet – at least in this first introduction – however, it is useful to make sure that those looking to adopt or adapt this approach into their toolbox understand the purpose and relative timing of the stages before they undertake it.

Roles

As mentioned, there are a few related disciplines that, while not architecture exactly, are nevertheless important for the architect to know about as the work that they do is so closely tied to that of the architect. In fact, throughout this book, we will draw heavily upon elements of each of these disciplines, so it is helpful to understand what each is and why it exists in the first place. The three that we will discuss in more detail are the following:

• Security engineering
• Risk management
• Security operations

Without a doubt, there are more roles than this in many organizations that intersect the role of the architect. However, we've chosen to cover these three specifically for a few reasons. First, most organizations of mid-market size or larger will have these roles either as a named individual who is assigned to them full-time or as a function that is subsumed into another role. Second, they are synergistic and symbiotic with the security architect. There are numerous other roles that might set requirements (for example, compliance officer, executive management, individual business teams) or that derive benefit from the design put in place by the architect (business teams, technology organizations, and so on), however, the roles we're drilling into here have a particularly collaborative role to play with the security architect: a "back and forth" and synergy that is different from other roles the organization might have. Lastly, we've picked these roles because, depending on the scope of a particular effort or the organizational makeup, the architect may need to step in to help directly with these other roles.

With that in mind, let's step through what these roles are, what they entail, and how the security architect may be called upon to work collaboratively with them.

Security engineering

Security engineering, strictly speaking, is the discipline of building systems that are resilient to purposeful misuse or sabotage, accident, natural disaster, or other unexpected events. Ross Anderson, in Security Engineering: A Guide to Building Dependable Distributed Systems, Wiley, describes security engineering as "...building systems to remain dependable in the face of malice, error, or mischance. As a discipline, it focuses on the tools, processes, and methods needed to design, implement, and test complete systems, and to adapt existing systems as their environment evolves." The astute reader will notice that this description and definition is similar to the one that we provided earlier in this chapter in reference to security architecture. In truth, there is a significant overlap in focus, goals, and purview/scope. And, as a consequence, you can probably intuit from the definition alone how closely the two would need to work together in organizations where they both exist (and hence the reason that we're covering it here).

As a practical matter, there is a difference in the execution of both roles – though, frankly, depending on the organization, there can be wide areas of overlap. Just like a system architect is focused on big-picture design and the vision of the system being developed, the security architect is focused on high-level design and the vision of security within their scope of operation. And just like a systems engineer is focused on the implementation mechanics within that system to make sure all individual components perform appropriately in isolation and together, so too does the system security engineer focus on the components within the system that provide security, their implementation, and their inter-operation.

Given the alignment in interests and goals between the security architect and the security engineer, they will need to work together closely. The security engineer can provide important information to the architect such as the feasibility of implementing a particular type of control in a particular location, strategies and designs to allow security controls to interoperate with each other, implementation guidance, and other important information. Likewise, the architect can provide value to the engineer as well; the architect can help provide input and support to the engineer on control implementation, help champion and whip up support for tools or technologies that the engineer needs, and otherwise work collaboratively with them to the betterment of both.

In situations where there is a defined system security engineering role, security architects should be prepared to work closely with them on a day-to-day basis. Where there is not a defined role – or where the function is spread over multiple other departments – the architect will find that they will need to take on some of this role themselves.

(IT) risk management

"I think the most important part of the architecture process is risk, informed by data. Nowadays, it's all about the data. We've moved beyond building strategies to protect a given server, or service. In reality, what you really need are strategies to protect the data."

– Steve Orrin, Federal CTO at Intel Corporation

Risk management is a key part of most (if not all) of the numerous security frameworks, regulatory requirements, security architectural frameworks, guidance, and other practical security advice you will come across. Meaning, it is understood to be of such importance that it is near-universally prescribed as a key principle and tenet of generally accepted security practice. Some organizations, particularly larger organizations, will have either a high-level risk management function that cascades in focus to the technology environment or an IT-focused risk management function. Other times, mostly in large and highly regulated organizations, they'll have both.

The function of the risk management team is to ensure that any given risk is identified, assessed for impact and likelihood, mitigated to the extent practical, and tracked over time. What's a risk in this context? It's defined formally by the International Organization for Standardization, Risk management – Vocabulary, as the "effect of uncertainty on objectives" (see https://www.iso.org/obp/ui/#iso:std:iso:guide:73:ed-1:v1:en)or, perhaps more concretely, in COBIT 5: for Risk, ISACA, (indirectly referencing the ISO guide) as "...the combination of the probability of an event and its consequence...".

In plain language, it's the combination of the likelihood and impact of something unexpected arising. Risk management seeks to account for these risks systematically. Therefore, risk managers are the folks that oversee and implement that effort.

Risk management can be general in nature, applying to the entirety of the business and all risk sources (for example, business risks, financial risks, operational risks, and so on) or it can be narrowly scoped (for example, IT and/or technology risks).

Risk management is absolutely critical to the security architect for a few reasons. First, in keeping with the principle that the security architecture is there to ensure that the business can meet its goals and to enable the mission of the organization, risks to the business are obviously an important part of making that happen.

Second, an understanding of what risks exist is key to the goal of resilience: specifically, knowing what could happen, how likely it is to do so, and what the impact might be as a result is an important part of ensuring that the overall system, network, and applications are resilient to those unexpected events. In fact, risk management is so critical to the process that you will notice that we have included a section on it as part of the process that we've laid out in this book.

In organizations that have a defined risk management function, security architects will find that they are one of the main stakeholders in the work that the architect performs. They will, for example, help the architect to prioritize controls, security mechanisms, countermeasures, and other artifacts of their security vision and strategy.

They will help translate underlying business requirements into security goals, they will track residual risks that may exist after countermeasures are put in place, they can help provide and track important metrics to the architect about the function of security solutions post implementation, and they will in turn be a primary consumer of metrics and telemetry gathered by the architect.

Because information about risk is so important to the work of the security architect, if the function does not formally exist within the organization, architects will find that they will need to perform some elements of the risk management process themselves.

Security operations

The last area that we will cover here is that of security operations, that is, the folks that directly use, maintain, interface with, and otherwise administer and support the security controls and tools that the architect fields into production. Security operations can be its own team, it can be part of another team (for example, network operations), or it can be distributed functionally based on the tool/control in scope (for example, firewall administration in network operations, application controls with business teams, monitoring tools in the security operations center, and so on).

Operations teams work closely with the architect in a few different ways. First, given their role as the primary interface point for the controls that the architect will deploy as part of their strategy, they can provide valuable input to requirements; they can help ensure that architecture designs are feasible and maintainable. Second, they can provide requirements directly into the architectural process; for example, there may be gaps in the visibility they have into the organization, areas where operations can be streamlined, or other criteria that can become requirements of the security architecture design.

This means that, just like the other roles outlined previously, security architects and security operations teams will need to work together very closely for maximum effect. Likewise, it is not unheard of for architects to take a more active role in the operational side of the designs they put together. This is often the case in smaller companies where security operations may not be a fully realized function, it can happen in situations where security operations are distributed and there is no clear home for an operational element in the design, or it can happen for certain areas of operation that are needed by the architect but that the operations team is unable to support (for example, the gathering of metrics from controls).

Process overview

"Because security architecture is by nature a "bridge" or translation, the aspects of the architecture process that are most important are going to change from organization to organization. It might be a culture change that is most important for one organization, just getting things written down in the first place for another, or the recognition that decisions should be driven by business instead of technology for yet another. Therefore, be ready to adapt and adjust the process you follow in light of what's most important to you."

– Mark Simos, Lead Cybersecurity Architect, Microsoft

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

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

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

1. Set scope and requirements: Determining the scope and direction for your architectural planning. This phase includes the validation of what will be included in the design you create and also the determination of the requirements that will guide the solution development.
2. Prepare your "toolbox": Preparing the tools (including documentation) that you will need to undertake subsequent phases and actually get started on your design.
3. Build enterprise blueprints: Designing the security plans and developing implementation plans for the organization.
4. Execute the blueprints: Putting your plan into practice.
5. Maintain: Making sure that the goals of the design stay relevant over time by collecting relevant metrics and telemetry.

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

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

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

Key tasks and milestones

"What you need to understand first is why you are doing architecture at all. This will inform you as to how much process makes sense. Meaning, if you understand the business drivers for architecture, the value it's providing to you, and why you need it, the answer for how much process to employ and where to apply it becomes self-evident. In some senses, extra process (adopting a process-heavy standard) is the "lazy person's way out." It takes more discipline to figure out the actual business needs and apply the creative energy to adapt a model to you versus just adopting something without understanding why you need it or what the value will be."

– Ted Ipsen, President and COO at Positroniq, LLC

Within each of these high-level phases, there are a few important milestones that we'll hit. It's useful to lay out what those are. There are a number of them, but the most important ones to know about for now are as follows:

• Establishing context

  What is the scope?

  What is included and what is excluded?

• Determining requirements

  What are the business goals?

  What risks should the design mitigate?

  What threats should the end result be resilient against?

• Assembling the "raw materials" for planning

  What documentation will you need to create?

  What architectural tools will you use to communicate your design?

  What exists already in the organization that you can incorporate into your plans and otherwise draw from?

  What resources are available to you and when?

• Building your plan

  What controls will you select and how will they be implemented?

  What areas can you not directly address?

  What is the timeline for implementation?

  How will resources be used?

• Execution/implementation

  How will you put your plan into practice?

  How will you overcome challenges and hurdles you will face along the way?

• Monitoring

  How can you gather information about the performance of your design?

  What data can you gather to make refinements?

  How can you gather additional information to make updates to the implementation in response to external events?

• Improving

  How can you adjust or adapt your design to optimize performance or improve outcomes?

Note that the execution steps in some areas will depend on the scope. For example, the design documentation that you choose to employ might vary depending on whether you are creating a design for a network, for a system, for an entire organization or business unit, or for an application. With that in mind, when there are differences, we will spell out what they are so that you can ensure the maximum likelihood that the process will be workable for the situation you are applying it to.

Throughout this chapter, we've attempted to provide you with information about why architecture exists, the value that it provides, and how it is (at a high level) normally practiced throughout enterprises. We've also tried to lay out some of the useful background information about what goes into being a cybersecurity architect.

Looking ahead, we will build on this to unpack the specific processes that architects use to actually do their work and walk through one approach and steps with you that you can use to do so yourself.

In the next chapter, we'll explore governance and why it matters to the security architect; governance structures and their purpose; and learn to cascade from enterprise/mission goals to technology and security goals.