Architecture roles and processes

"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.