Chapter 1. Introduction

Security often gets simplified down to selecting security controls or countermeasures that prevent loss of confidentiality, integrity, and availability. However, the integration of the controls is just as important as selecting the controls. A series of architectural decisions, informed by the sensitivity of the data and the context of the environment around the system, guides the integration of the security controls.

There are publications providing useful guidance on the design and implementation of cybersecurity technology, the use of software architecture methods, and the application of cloud security services. However, there is a need for a repeatable and consistent way of approaching the architectural thinking for the secure design of an information system hosted on hybrid cloud.

There is a need to clearly communicate the architectural thinking practices and provide assurance that the controls deployment is effective and comprehensive. In a regulated environment this is particularly important, as there needs to be transparency, starting with the design of the security controls through to the assurance mechanisms used to demonstrate compliance.

This book will take you through a step-by-step process to architect security into a solution that resides on hybrid cloud. This first chapter will set the context for the rest of the book by describing:

The need for effective integration of the foundational security techniques
The type of architect who should use the architectural thinking described within this book
How the structure of the book uses an artifact dependency diagram as a roadmap to architectural thinking for security

Once you have read the introductory chapter, you may wish to skip to a chapter that’s relevant to the current stage of your architectural thinking. However, we encourage you to start at the beginning, as the end-to-end method helps you understand the traceability of requirements, architecture decomposition, and threat modeling leading to detection and response. Once you have read the end-to-end method, the book will be a useful reference to dip into to refresh yourself on the techniques as you work on the security for a solution architecture.

Let’s start by discussing the foundational security techniques for effective integration of security and compliance into hybrid cloud solutions.

Foundational Security Techniques

There are many different security controls used to protect data from loss of confidentiality, integrity, and availability. Foundational security techniques integrate the controls into a system. However, each of these techniques or concepts is normally discussed independently and the ones chosen tend to be the favorite of the loudest stakeholder or solution provider. None of these techniques alone is enough to design, build, and run a secure system.

In this book, we integrate four foundational security techniques into an end-to-end method:

Compliance management
Data-centric security
Secure by design with threat modeling
Zero trust architecture

Figure 1-1 shows how these techniques integrate together to form the foundation of the method we will discuss.

At the center of the diagram are the three architectural thinking techniques we will use to embed security into the architecture of a solution. This is all supported by the demonstration of compliance shown around the outside.

Compliance takes a static, unfocused approach to security, but data moving through a system is dynamic as it’s processed while in transit, at rest, and in use. Let’s start with the technique, which focuses on the transaction flows and processing of data.

Data-Centric Security

Data-centric security puts a focus on analyzing the flow of data through a system from the start of a transaction to the end. At each stage of the journey, we consider the security controls needed to protect the transaction flow in transit, at rest, and in use.

The diagram in Figure 1-2 shows the flow of data as it passes through a system:

In the diagram, the shopper initiates a transaction to order some goods. The box represents the organization, and the outer ellipse represents the boundary of the system processing the data. Within the system, there are three interconnected subsystems that process the data. The dotted line represents the transaction flows that transport the data through the subsystems and require protection.

Let’s walk through each of the transaction flows in order:

The order is first passed as a transaction flow from the shopper to the “Core app” subsystem. When the order is ready to complete, the flow continues onto the “Payments” subsystem and out to an external payment system, as shown in flow 1.
After completion of the payment, the transaction returns to the “Payments” subsystem and moves on to the “Delivery” subsystem to connect externally to arrange for delivery, as shown in flow 2.
After the arrangement of the delivery, the confirmation of the order is then returned to the “Core app” subsystem and the person who placed the order, as shown in flow 3.

At many of the steps in this transaction flow, processing and aggregation of data are taking place, increasing the value of the data and the need for increased controls. At all stages of the transaction flow, we need to consider the security controls to protect the data from loss of confidentiality, integrity, and availability.

Once we understand the transaction flows we can move on to secure by design.

Secure by Design with Threat Modeling

Secure by design uses threat modeling as a way to identify risk-based security controls directly to transactions and data that move through a technology product or system.

In their paper, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure-by-Design and -Default, CISA and other national security organizations define secure by design to mean where “technology products are built in a way that reasonably protects against malicious cyber actors successfully gaining access to devices, data, and connected infrastructure.” It means that engineers need to embed security in the design of a software or hardware component through an assessment of the risk by carrying out threat modeling.

Threat modeling identifies specific threats and builds on security policies, practices, and processes that don’t specifically address the risks to sensitive data. You can extend the practice to the examination of the application and infrastructure architecture for the identification of risk-based controls.

To ensure the identification of all sensitive data, we use a systematic architectural thinking approach for the examination of all the important data flows and transactions. Threat modeling practices need to work at scale across multiple computing platforms in a hybrid cloud environment.

We will discuss threat modeling further in Chapter 6, including recent approaches such as MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge).

Zero Trust Architecture

Cloud computing and the use of mobile devices challenged the traditional concept of a perimeter-based security model. Traditional “castle and moat” security models assumed, after data passed through the perimeter, that everything inside a system could be implicitly trusted. The change in thinking started with the Jericho Forum in 2007 releasing the Jericho Forum Commandments for a deperimiterized world where it’s assumed a network perimeter doesn’t exist.

John Kindervag, from Forrester Research, then came up with the term “zero trust” in 2010 and developed the phrase “never trust, always verify.” He identified zero trust as a model that removes implicit trust within a system boundary and continuously evaluates the risks by applying mitigations to business transactions and data flows at every step of their journey. The phrase “assume breach” is also often associated with zero trust and comes from the phrase “assume compromise” used by the US Department of Defense in the 1990s.

The approach requires a combination of technologies, processes, practices, and cultural changes to be successfully implemented. It involves a fundamental shift in the way organizations approach cybersecurity.

Zero trust basics

The zero trust model assumes that all business transactions and data flows, whether originating from inside or outside the network, are potentially malicious. Every interaction in a business transaction or data flow must be continuously validated to ensure that only authorized users and devices can access sensitive business data. In effect, it moves the perimeter from the system boundary to the point at which identification, authentication, and authorization take place, resulting in identity becoming the new perimeter. The whole concept often gets simplified down to the “never trust, always verify” principle, but it’s more than that.

Zero trust architecture requires a cultural shift that emphasizes the importance of security rather than just compliance throughout an organization. This means that implementing a zero trust architecture involves not only the deployment of specific technologies but also the development of processes and practices that promote a data security-first mindset across the organization, building on the data-centric security approach we discussed earlier.

When architecting and developing security for a system, an architect should follow a set of principles, tenets, or simply a way of thinking to apply zero trust. Zero trust isn’t an end-to-end method, and a comprehensive approach requires integration with other architectural thinking techniques.

Zero trust principles

Organizations offer guidance in publications, including the US National Institute of Standards and Technology (NIST) SP 800-207 Zero Trust Architecture document that has a set of zero trust architecture tenets and the UK National Cyber Security Centre (NCSC) Zero trust architecture design principles.

Zero Trust Network Architecture Principles

Don’t get confused by “zero trust network architecture principles” that are used by solution providers to describe their products; they are a subset of the overall zero trust principles.

Throughout the book, we show zero trust tenets and principles embedded in the method. We’ve created five higher-level guiding principles in Table 1-1 mapped to the tenets and principles. We’ve brought them back to the familiar phrases you might see in marketing.

Table 1-1. Zero trust tenets and principles mapping
Guiding principles	NIST SP 800-207 Zero Trust Architecture tenets	UK NCSC Zero Trust Architecture Design Principles
Data-centric security	All data sources and computing services are considered resources.	Know your architecture including users, devices, services, and data. Know your user, service, and device identities.
“Never trust, always verify” or Identity verification + Access control + Least privilege + Microsegmentation	Access to individual enterprise resources is granted on a per-session basis. Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes. All resource authentication and authorization are dynamic and strictly enforced before access is allowed.	Use policies to authorize requests. Authenticate and authorize everywhere.
Data protection everywhere	All communication is secured regardless of network location.	Don’t trust any network, including your own.
“Assume breach” or Continuous monitoring	The enterprise monitors and measures the integrity and security posture of all owned and associated assets. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve its security posture.	Assess user behavior, service, and device health. Focus your monitoring on users, devices, and services.
Zero trust component selection		Choose services which have been designed for zero trust.

We then come to the need to demonstrate compliance, not just against the policies, practices, and processes but against the threats we’ve identified.

Compliance Management

An organization uses compliance management processes to show it’s following a set of rules, regulations, or standards given by external organizations, such as governments and industry bodies. The process ensures that businesses follow these strict requirements for operational risk, security, privacy, and resilience.

Compliance management includes checking that an information system meets a set of policies, practices, and processes for the organization. They may only cover a subset of the security controls needed to protect sensitive information, as they often represent a minimum level of security that organizations must meet to avoid fines or legal penalties.

Often, the security team can’t keep up with changes in technology, new system vulnerabilities, emerging threats, or advanced attack techniques, resulting in slow or delayed updates to security policies and standards. In some cases, it takes a security incident to force improvements in protection to cope with new types of attacks or security vulnerabilities not previously identified or blocked.

The continuous raising of the compliance bar sometimes requires the implementation of new controls, even if the risk doesn’t justify the increased controls. There are additional costs from the increased compliance, and the protection may still be ineffective for the most sensitive data.

Compliance Is Not Security

Compliance is not security, and you won’t achieve compliance without security. We’ve seen many organizations where there is significant investment spent demonstrating “noncompliance” through compliance checking, control reviews, and audits, but little investment takes place in security. Focus on security with traceability to demonstrate compliance.

In Chapter 4, there is a discussion on compliance validation techniques, including traceability to demonstrate compliance, and in Chapter 10, a discussion on compliance assurance techniques.

Let’s continue with a discussion on the users of the foundational security techniques in the industry today.

Users of the Security Techniques

The techniques or models that we discuss in this section are often primarily used by different types of security professionals, with the result that each of the different users promotes their own favorite technique. The integration of these techniques isn’t often written about or practiced as an integrated set of techniques.

So where do we see these techniques used today?

Data-centric security: We’ve seen architects overlay colored data flows for architecturally significant data flows, but it’s not something we see regularly. Sometimes it’s used for security, and other times it’s just for showing the transaction flow.
Secure by design with threat modeling: Secure by design is mostly referenced for the development of a software product using the software development lifecycle. It discusses the use of a threat model as part of the design of a product. Since the release of Threat Modeling: Designing for Security (Wiley) by Adam Shostack in 2014, software developers (or engineers) are more likely to use threat modeling as a technique during software development. We see the technique mostly used in software development rather than used for the end-to-end design of a whole application, system, or system of systems.
Zero trust architecture: Many different organizations are adopting zero trust architecture, but solution providers dominate where they use the technique to sell products that tend to focus on one domain, such as network security, identity management, or threat management.
Compliance: Compliance is often the focus of risk and compliance organizations in many regulated industries. We suspect it’s because it’s easier for auditors, consultants, and executives to think about a series of checklists that don’t require the deep technical background necessary to use other techniques.

This book will take you through a method that will integrate each of these techniques together, but before we talk about a method, let’s consider who should be architecting security into a solution.

Architect Roles for Security

Architectural thinking is the primary role of an architect. However, it’s a skill also used by consultants and software engineers engaged in making architectural decisions. We will discuss further in Chapter 2 how architectural thinking fits with consulting and engineering.

Architectural thinking for secure design is also not only for security architects; a wide range of architect roles need to apply security to the development of an information system. Architects developing infrastructure or applications should adopt this method, not just security architects.

In Agile development, there is a need for a hybrid role called a security champion, who will have both architectural and engineering skills. They should be able to use this method to advise the developers on embedding security into DevSecOps.

A range of different architect roles should use architectural thinking for security techniques, including:

Security architect
Infrastructure and application architect
Security champion

Let’s continue by discussing each of these architect roles and how they should be using the method in this book.

Security Architect

A security architect is an architect with a specialty in security, compliance, and risk management. We’ve split the role of a security architect further into four categories: enterprise security architect, solution security architect, product security architect, and advisory or consulting security architect. Each role has a common set of security skills but a different focus with additional skills and experiences:

Enterprise security architect

A security professional who is a specialist in enterprise architecture and produces enterprise-level guidance on the application of security to an enterprise. They develop an enterprise architecture and guiding principles to align with the security strategy and guide the development of security in solution architectures.

They must have a good understanding of current threats and the direction of the industry, as well as excellent communication skills, to align the enterprise with the enterprise security strategy and architecture.

If you have this role, this book contains some overall guidance on enterprise architecture in Chapters 2 and 3. Together with the rest of the book, these chapters enable an enterprise security architect to understand the architectural thinking for secure design process so they can provide the right inputs to support architects in the solutioning of security.

Solution security architect

A security professional who is a specialist in the development of solution architectures for security in specific projects or initiatives within an organization. For example, they may develop an architecture for a specific solution, such as a privileged access management service.

They must have a deep understanding of specific threats and risks associated with the technology and a good understanding of the organization’s enterprise strategy, enterprise architecture, policies, standards, and guidelines.

In addition, they need to have all the skills of infrastructure and application architects in resilience, scalability, and operations, as they will be developing the architecture for a security application.

They will work closely with engineers, developers, testers, and project managers. They need to have excellent communication skills to explain security concerns to non-technical stakeholders.

If you have this role, the whole of this book provides the security-specific architecture activities needed for a security solution, but generic architecture techniques, available in other software and application architecture publications, will supplement the techniques discussed in this book. The end of this chapter contains references to other useful publications.

Product security architect

A security professional who is a specialist in the development of a security product or suite of products. They’re often specialists in a specific security domain, such as identity and access management or threat detection, with a deep understanding of the products’ software and hardware requirements.

They will be responsible for the development of the architecture for a security product and will work closely with the development and testing teams. For the product to be quickly adopted, they will need to understand how it fits into an enterprise environment and the benefits it delivers.

They will need great communication skills to explain the benefits of the product to the product management team, which will market and sell the solution.

If you have this role, the whole of this book provides the security-specific architecture activities needed for a software product, but generic architecture techniques, available in other software architecture publications, will supplement the techniques discussed in this book. The end of this chapter contains references to other useful publications.

Advisory or consulting security architect

A security professional who is a specialist who advises an organization on how to integrate security controls into its infrastructure and applications. They work with the lead or chief architect for the project and sometimes with architects of other disciplines to embed security into the solution developed.

They need to have a good understanding of not only industry best practices, regulatory requirements, and security technologies but also infrastructure and application architecture solutions. The architect has “T-shaped” skills with a deep security understanding and a wide range of skills related to information systems.

They need to be able to talk about security with a wide range of stakeholders, including those who aren’t technical and those who work on the specific implementation of the security controls and have deep engineering skills.

If you have this role, the whole of this book provides the security-specific architecture activities needed for an infrastructure or application architecture, and the artifacts will need to overlay the architecture developed by an infrastructure or application architect. The end of this chapter contains references to other useful publications that will enable you to better support the architects you are advising.

If you are an architect for an information system, think about what role you have in integrating security into the solution architecture. The question isn’t whether you are responsible, but to what extent.

Infrastructure and Application Architect

There are many projects or initiatives that don’t need the benefit of a specialist security architect, the infrastructure or application architect will need to integrate security into the solution. The infrastructure architect might be designing a cloud platform, while the application architect might be designing a payments platform that’s hosted on the cloud platform. In both cases, security will be the responsibility of these architects. This book will help them with the architectural thinking for secure design needed in their roles.

Security Champion

In an Agile or DevOps development environment, a security champion may take on the role of an advisory security architect. In this case, the security professional will have a mix of architectural thinking and engineering skills that enable them to get into the details of advising a developer on how to develop code securely. Further detail on this role is in Chapter 10.

Contextual Roles and Responsibilities

All the roles need to understand the end-to-end architectural thinking process and the artifacts involved. Each role’s responsibilities for leading or assisting in the development of artifacts will vary. As technical leaders, they will need to adapt their responsibilities depending on the context of the organization, product, project, or program.

Now that we’ve talked about the foundational security concepts requiring integration into a method and the architect roles, let’s move on to a discussion of the structure of the book that will enable an effective walkthrough of the method.

Book Structure

The book has a series of chapters that build a security architecture using techniques to develop artifacts throughout the book. Each chapter focuses on specific artifacts and techniques, giving you the opportunity to also use the book as a reference manual. Each chapter will highlight techniques that support zero trust. To help reinforce the learning from the book, we’ve included examples of artifacts based on the case study contained in Appendix A.

Artifact Framework

Let’s start with looking at the framework used throughout this book, followed by the detailed artifact dependency diagram.

In Figure 1-3, we show a framework for the architectural thinking that’s used to develop a security architecture. Each block on the diagram represents a grouping of related artifacts.

At the top, we have the enterprise context, which includes all the organization inputs used to architect a solution architecture, including business context and organization policies. These artifacts are normally created before the solution architecture, but sometimes they don’t exist and the project is responsible for their development. You may have to fill in these details, which will add additional effort to the project.

Below that, we have the requirements, architecture and operations sections that demonstrate the left to right development of the architecture. The requirements section includes the artifacts for gathering the functional and non-functional requirements for the solution. The architecture section includes the artifacts for the top-down decomposition of the solution architecture, starting with the architecture overview and system context. The operations section may be the last on this picture, but it’s no less important and contains artifacts developed from the requirements and architecture parts of the framework.

At the bottom left is the governance section, including the artifacts used to support the overall development of the architecture and used at all stages of architecture development.

Finally, on the bottom right is the assurance section, which includes all the activities necessary to give us confidence in the design and implementation of the security controls, and these activities continue into Day-2 operations.

This is a starting point, and now we need to elaborate the framework.

Artifact Dependency Diagram

The framework in Figure 1-4 shows an artifact dependency diagram with the documents, diagrams, and tables created using techniques contained within this book. In the following chapters, we will walk through the creation of the artifacts using this diagram as a roadmap.

The number of artifacts may look overwhelming, but the artifacts can be individual diagrams and tables rather than a big document. It also has artifacts containing code, such as a deployable architecture. Use the artifacts and techniques as tools, depending on the project’s specific requirements.

Diagram Format

The original diagrams we produced have been redrawn for consistency and to support publishing requirements. If you want to see selected original diagrams, they are hosted on the companion website for the book.

It’s likely that, as an architect, you will come across these artifacts, with varying levels of input depending on your role. As we discussed earlier, the application or infrastructure architect will own some of these artifacts, and you may add content to them. In other cases, you will own them. If someone doesn’t own them, it’s most likely that you do. When it comes to operations artifacts, you may not create the artifacts, but you are responsible for ensuring their delivery.

It’s also not necessary to use every one of the artifacts, and the time spent on each one should be just enough to convey the architecturally important features of a system. For instance, when validating the effectiveness of control mechanisms, you don’t have to consider every single transaction flow that could occur within the system. Instead, you should look for a representative collection of architecturally significant transaction flows that enable you to review all major paths through the system at least once.

Create documentation appropriate to the context of the project and the sensitivity of the data the system is processing. There will be a need to create significant documentation for an application subject to regulations to give assurance to internal risk management and external auditors. An organization that’s less tolerant of risk may require the identification of an extended list of threats and countermeasures.

Integration of Artifacts with Other Methods

We’ve used names for artifacts that may be different from the ones you use for architectural thinking. We’ve tried to align with common industry names, and where there isn’t agreement, we’ve tried to assign names that would be recognizable to most software or infrastructure architects. We’ve provided a mapping between the artifact names we used and other methods and publications in Appendix B.

You’ll often see that there is no equivalent artifact to the ones we propose. It just highlights how other methods have a focus on specific parts of the architectural thinking process. We’ve tried to create a set of artifacts and techniques that integrate practices such as design thinking and stretch into the critical operational aspects of security.

Using this generic set of artifact names, we hope you are able to overlay whatever software architecture method you may be using. We’re not trying to dictate the underlying methods used within your organization, but we hope you can find a way to integrate and enhance the methods, artifacts, and techniques you are already using today.

We have an interest in knowing if you integrate our thinking into other software architecture methods or if you have any ideas to improve the method.

Now we need to discuss how best to demonstrate the use of the techniques to create artifacts.

Case Study

We’ve found the best way to learn the techniques to create the artifacts is through a case study that defines a problem with some business context, current IT architecture, and an architecture overview diagram. We reference the case study contained in Appendix A in each chapter and use it to create example artifacts to show the use of the technique.

Figure 1-5 shows the artifacts contained within the case study. It provides an overall business context to the project, through a discussion of the need to deliver a system to charge polluting vehicles for entry into the city. It describes the current IT architecture including the organizations that will need to integrate with the system, such as Clean Air Pay that needs RabbitMQ integration. If this was a project for an organization with many existing applications, there would be many more constraints on the solution.

As the system is processing personal data, the prevailing data privacy legislation will guide the required controls. The application needs to meet the Payment Card Industry Data Security Standard (PCI DSS) as it processes payments. The case study says little about the existing security policies but does talk about using the NIST Cybersecurity Framework as a practice the project needs to apply to the system.

The case study provides an architecture overview diagram to show the overall system. Don’t expect the diagram to show all external actors for the system, and you may have to identify extra information from the description or implied systems to integrate with. This is the first diagram the project is likely to give you, or you need to create it yourself. It’s a diagram that shows an overview of the solution, but it’s not expected to be in a standard format and will be a diagram that anyone can understand from a non-technical perspective. In the case study diagram, we have components joined together by lines, but it could just be a block diagram of capabilities in groups without lines showing control or data flow. It’s also likely to evolve over time, so keep an eye on changes to this diagram from the lead architect, as the updates may change your solution.

We will use an artifact dependency diagram in each chapter, to highlight the artifacts we’re discussing. Let’s walk through each of the chapters and their contents.

Book Organization

As discussed before, the book has chapters organized broadly in the order of the development process to construct a solution architecture with security included. Figure 1-6 shows the solution lifecycle with the boxes Plan, Design, Build, and Run representing the phases.

These solution lifecycle phases all feed the security architecture at the bottom of the diagram. The Govern, Identify, Protect, Detect, Respond, and Recover blocks align with the six functions in the NIST Cybersecurity Framework, which we will discuss in Chapter 2, together with the security domains we’ve defined for an enterprise security architecture.

We’ll now take you through the different parts of the book that align to the solution lifecycle phases in Figure 1-6. Each part contains one or more chapters.

Architectural Thinking for Security Framework

Part I. Concepts

We start the book with two chapters discussing the security and architecture concepts used within the book. These chapters provide a foundation before we get into the stages of the solution lifecycle:

Introduction: Chapter 1 will give you some background to architecture, security architecture, and the approach this book uses to walk through the method.
Architecture Concepts: Chapter 2 discusses where architectural thinking fits into the design and development lifecycle, and the difference between enterprise and solution architecture.

Part II. Plan

We continue with the Plan phase in Figure 1-6, where we discuss obtaining requirements from the enterprise context and then requirements definition:

Enterprise Context: Chapter 3 discusses the information that’s external to the development of the solution architecture including business context, current IT environment, laws and regulations, policies and standards, enterprise architecture, and guiding principles.
Requirements and Constraints: Chapter 4 discusses the gathering of requirements, starting with external laws, regulations, and industry standards. It then goes on to discuss documenting the functional and non-functional requirements for a system.

Part III. Design

Now that we’ve gathered the requirements, we continue with the Design phase in Figure 1-6, where we discuss the design of the solution architecture, starting with the functional components and moving on to the deployed architecture:

System Context: Chapter 5 discusses the core architectural thinking technique for protecting sensitive assets by focusing the boundary of the system, on where the data flows, where it’s stored, and where it’s processed. An architect uses the system context diagram to define the boundaries of the system and the external actors triggering data flows through interactions with the system. The chapter continues by describing the documentation of an information asset register and the classification of the data to identify the types of controls depending on data sensitivity.
Application Security: Chapter 6 discusses the development of a functional architecture for an application or workload through documenting a component architecture diagram. It continues by starting with threat modeling at a high level for the application components.
Shared Responsibilities: Chapter 7 will discuss the deployment of application subsystems onto technology platforms and document the shared responsibilities for a set of hybrid cloud platforms.
Infrastructure Security: Chapter 8 continues elaboration of the solution by deploying the functional components onto infrastructure and ensuring data flows use zero trust principles for protection. A deployment architecture diagram or cloud architecture diagram provides the documentation for a hybrid cloud infrastructure architecture. The architecture diagrams will then have the threat modeling repeated.
Architecture Patterns and Decisions: Chapter 9 looks at how you can accelerate architectural thinking by using architecture patterns and deployable architectures. The chapter will then introduce the use of architectural decision records.

Part IV. Build

Once we’ve designed a solution architecture, we continue with the Build phase in Figure 1-6 by considering the development lifecycle:

Secure Development and Assurance: Chapter 10 looks at the development lifecycle and how architectural thinking for security integrates into it, including Agile development and the role of a security champion. We then look at the role of the risk, issue, assumption, and dependency log during the design and development lifecycle.

Part V. Run

Finally, we need the system to remain secure after it’s live, so we discuss the operational aspects of the system as shown in the Run phase in Figure 1-6:

Security Operations: Chapter 11 looks at elaborating the roles and responsibilities identified with the shared responsibility diagram into a Responsible, Accountable, Consulted, and Informed (RACI) table. The responsibilities are then documented through the processes, procedures, and work instructions needed to secure the system. We then continue with the documentation of the detection of threats and response to incidents through a threat detection use case and incident response runbook.

Part VI. Close

And the final chapter includes some closing thoughts:

Closing Thoughts: Chapter 12 concludes the book with some thoughts on best practices when architecting security into a solution architecture.

Architectural thinking is the decomposition of a solution through an iterative process into more and more detail. Let’s discuss how we will do that.

Solution Architecture Decomposition

Throughout the book, we break down the solution architecture of the information system into layers, as shown in Figure 1-7. We start at the top layer by using a system context diagram to describe the system’s boundary and how it connects to external human and system actors. In Chapter 5, we will talk more about this.

We will then look at the functional components of the application, or workload, that are inside the system boundary. We will describe how they interact with each other and start to examine the threats to the application. In Chapter 6, we will examine this in more detail.

Solution Architecture Decomposition Layers

On the bottom layer, we will examine the deployment of the functional components of the application onto the infrastructure and apply zero trust architecture practices. In Chapter 8, we will explore this layer in more detail.

Other architecture models may introduce additional layers, but we’ve tried to make it simple so you can apply the techniques to different architecture methods. However, it’s likely that you will decompose each layer from a logical to a physical (or prescriptive) perspective. We give an example of that decomposition in Chapter 5. As another example, look at the container, component, and code diagram decomposition in the C4 Model.

We continue with a discussion of the steps involved in architectural thinking and decomposition.

Method Techniques

In each of the following chapters, you will find at least one architectural thinking technique discussed.

We split the techniques into two types:

Enterprise: The techniques discussed apply to enterprise architecture and don’t use the case study.
Case study: The techniques discussed use the case study in Appendix A to demonstrate how to apply the techniques.

Table 1-2 lists the techniques and their type discussed in each chapter.

Table 1-2. Techniques by chapter
Chapter	Technique type	Technique
Chapter 2, “Architecture Concepts”	Enterprise	Enterprise security architecture
Chapter 3, “Enterprise Context”	Enterprise	All artifacts from the enterprise context group
Chapter 4, “Requirements and Constraints”	Case study	Use case Journey map User stories Swimlane diagram Separation of duties matrix Non-functional requirements Requirements traceability matrix
Chapter 5, “System Context”	Case study	System context diagram Information asset register
Chapter 6, “Application Security”	Case study	Data flow diagram Component architecture diagram Sequence diagram Collaboration diagram Threat model
Chapter 7, “Shared Responsibilities”	Case study	Shared responsibility diagram
Chapter 8, “Infrastructure Security”	Case study	Deployment architecture diagram Cloud architecture diagram
Chapter 9, “Architecture Patterns and Decisions”	Case study	Architecture patterns Deployable architecture Architectural decision record
Chapter 10, “Secure Development and Assurance”	Case study	Risks, assumptions, issues, and dependencies (RAID) log Test strategy and plan
Chapter 11, “Security Operations”	Case study	Shared responsibilities RACI Process (swimlane diagram) Statechart diagram Procedures Work instructions Separation of duties matrix Threat detection use case Incident response runbook Threat traceability matrix

Order of the Techniques

The order of the techniques throughout the book uses the same order we teach students for the MSc degree module in the UK. We designed the order to build up the architecture step by step. The documentation of the architectural decision records and RAID artifacts is something that should happen from the start of the architectural thinking process, but it makes more sense to discuss it after the completion of some architectural thinking.

In many chapters, we offer a QA checklist or extra detail on the steps you should perform to help deliver quality artifacts.

At the end of each chapter there is an Exercises section with multiple choice questions. The answers can be found in Appendix C. Further, summative questions with answers can be found on the companion website.

Let’s close this chapter with some final thoughts.

Summary

We started by discussing four foundational techniques for designing security into systems and how it’s a problem when they’re not integrated together, creating a disjointed approach to integrating security into an information system. We believe there is a need to integrate the techniques to create a robust security architecture method to overlay existing information system and software architecture methods.

We went on to discuss the different types of architects that will use the method. We believe that all types of information system architects need to be able to design the security of an information system. A security architect is there to support other architects and develop architecture for security services. Think about your role as a consultant, architect, or engineer and how architectural thinking for security will fit within your current projects.

The final section discussed the structure of the book, with the artifact dependency diagram helping frame the journey through the architectural thinking for secure design method. The chapter contained a summary of later chapters, and the techniques used to create the artifacts. You might want to create a copy of the artifact dependency diagram to pin on your wall and use as a prompt in your project.

In Chapter 2, we will take some time to reflect on where architectural thinking fits into the development lifecycle. We often see a jump from design thinking to software engineering without architectural thinking, causing problems with major architectural changes needed at a later stage. We will also talk about the difference between enterprise and solution architecture, as this can often get confused. These topics will help give context to the following chapter, where we start on the journey through the artifact dependency diagram.

Exercises

Which of the following are the foundational security techniques used in the method described in this book? Select all that apply.
1. Secure by design with threat modeling
2. Zero trust architecture
3. Confidential computing
4. Compliance management
5. Data-centric security
What are the characteristics of secure by design? Select all that apply.
1. It includes threat modeling.
2. It precedes architectural thinking.
3. It is targeted at the design of technology products.
4. It scales to design a system of systems.
What are characteristics of zero trust architecture? Select all that apply.
1. “Never trust, always verify.”
2. It’s only about network security.
3. Identity is the new perimeter.
4. It’s a product or solution.
Which one of these architect roles is specifically used in an Agile or DevOps development environment?
1. Enterprise security architect
2. Application architect
3. Security champion
4. Advisory security architect
Which of the artifact sections supports the overall development of the architecture during all stages of development?
1. Requirements
2. Architecture
3. Operations
4. Governance
5. Assurance
The artifact dependency diagram contains which of the following types of artifacts? Select all that apply.
1. Diagrams
2. Event logs
3. Automation
4. Tables
Which of the following statements is correct?
1. Solution architecture decomposition includes enterprise architecture, component architecture, and deployment architecture.
2. Solution architecture decomposition includes architecture overview, component architecture, and deployment architecture.
3. Solution architecture decomposition includes system context, component architecture, and deployment architecture.
4. Solution architecture decomposition includes system context, component architecture, and data flow diagram.

Get Security Architecture for Hybrid Cloud now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial