Practical Cybersecurity Architecture E-Book

Diana Kelley

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 855

Veröffentlichungsjahr: 2023

Beschreibung

Cybersecurity architecture is the discipline of systematically ensuring that an organization is resilient against cybersecurity threats. Cybersecurity architects work in tandem with stakeholders to create a vision for security in the organization and create designs that are implementable, goal-based, and aligned with the organization’s governance strategy.
Within this book, you'll learn the fundamentals of cybersecurity architecture as a practical discipline. These fundamentals are evergreen approaches that, once mastered, can be applied and adapted to new and emerging technologies like artificial intelligence and machine learning. You’ll learn how to address and mitigate risks, design secure solutions in a purposeful and repeatable way, communicate with others about security designs, and bring designs to fruition. This new edition outlines strategies to help you work with execution teams to make your vision a reality, along with ways of keeping designs relevant over time. As you progress, you'll also learn about well-known frameworks for building robust designs and strategies that you can adopt to create your own designs.
By the end of this book, you’ll have the foundational skills required to build infrastructure, cloud, AI, and application solutions for today and well into the future with robust security components for your organization.

Leseprobe

Practical Cybersecurity Architecture

A guide to creating and implementing robust designs for cybersecurity architects

Diana Kelley

Ed Moyle

BIRMINGHAM—MUMBAI

Practical Cybersecurity Architecture

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Pavan Ramchandani

Publishing Product Manager: Khushboo Samkaria

Book Project Manager: Ashwin Kharwa

Senior Editor: Roshan Ravi Kumar

Technical Editor: Irfa Ansari

Copy Editor: Safis Editing

Proofreader: Safis Editing

Indexer: Pratik Shirodkar

Production Designer: Ponraj Dhandapani

DevRel Marketing Coordinator: Marylou De Mello

First published: November 2020

Second edition: October 2023

Production reference: 1121023

Published by Packt Publishing Ltd.

Grosvenor House
11 St Paul’s SquareBirmingham
B3 1RB, UK

ISBN 978-1-83763-716-4

www.packtpub.com

Contributors

About the authors

Diana Kelley is CISO at Protect AI. She serves on the boards of WiCyS, the Executive Women’s Forum, InfoSec World, and TechTarget Security. She was Cybersecurity Field CTO at Microsoft, Global Executive Security Advisor at IBM Security, GM at Symantec, VP at Burton Group, Manager at KPMG, and Chief vCISO at SaltCybersecurity.

Her extensive volunteer work has included serving on the ACM Ethics & Plagiarism Committee, Cybersecurity Advisor at CompTIA, and the RSAC Program Committee. She hosts BrightTALK’s The Security Balancing Act, co-authored Practical Cybersecurity Architecture and Cryptographic Libraries for Developers, and teaches LinkedIn Learning Security in AI and ML. Her awards include EWF Executive of the Year and SCMedia Power Player.

Ed Moyle is a partner with SecurityCurve and Systems and Software Security Director for Taxwell. In his 25 years in information security, Ed has held numerous positions, including Director of Thought Leadership and Research for ISACA, Senior Security Strategist with Savvis, Senior Manager with CTG, and Vice President and Information Security Officer for Merrill Lynch Investment Managers. Ed is the co-author of Cryptographic Libraries for Developers and Practical Cybersecurity Architecture. He is a frequent contributor to the information security industry as an author, public speaker, and analyst.

About the reviewer

Eyal Estrin is a cloud and information security architect, and the author of the bookCloud Security Handbook, with more than 20 years in the IT industry.

He has worked in several different industries (in the banking, academia, and healthcare sectors).

He has attained several top security certifications – CISSP, CCSP, CDPSE, CISA, and CCSK.

He shares his knowledge through social media (LinkedIn, Twitter, Medium, and more).

Table of Contents

Preface

Part 1: Security Architecture

1

What Is Cybersecurity Architecture?

Understanding the need for cybersecurity

What is cybersecurity architecture?

Network versus application security architecture

The role of the architect

Secure network architectures

Secure application architectures

Case study – the value of architecture

Architecture, security standards, and frameworks

Architecture frameworks

Security guidance and standards

Security architecture frameworks

Architecture roles and processes

Roles

Process overview

Key tasks and milestones

Summary

2

Architecture – The Core of Solution Building

Terminology

Understanding solution building

Establishing the context for designs

Understanding goals

Identifying business goals

Dimensions of success

Structures and documents

Policies, procedures, and standards

Applying to architectural frameworks

Additional frameworks

Risk management and compliance

Risk management and appetite

Compliance

Establishing a guiding process

Understanding the business’ high-level goals

Understanding the technology goals

Drawing implied goals from existing documentation

Capturing (or defining) risk tolerances

Accounting for compliance requirements

Summary

Part 2: Building an Architecture

3

Building an Architecture – Scope and Requirements

Understanding scope

What’s in this chapter?

Setting architectural scope

Enterprise security architecture

Application security architecture

Defining scope boundaries

Scope – enterprise security

Existing capability

Risk management

Strategic planning

Case study – enterprise scoping

Scope – application security

The development and release process

Components, services, and design patterns

Team/organizational boundaries

Technology considerations

Case study – application scoping

The process for setting scope

Step 1 – consider high-level goals

Step 2 – review contextual or other constraints

Step 3 – set the initial scope

Step 4 – validate and refine initial scope

Summary

4

Building an Architecture – Your Toolbox

Introduction to the architect’s toolbox

Planning tools

Analytical tools

Informational tools

Modeling and design tools

Case study – data gathering

Building blocks of secure design

Information security policies

Organization of information security

Human resources security

Asset management

Access control

Cryptography

Physical and environmental security

Operations security

Communications security

System acquisition, development, and maintenance

Supplier relationships

Information security incident management

Information security aspects of business continuity management

Compliance

Summary

5

Building an Architecture – Developing Enterprise Blueprints

Requirements

Blueprints

Process

Why ADM?

The vision

Establishing architectural principles

Setting the scope

Getting the desired future (target) state

Case study – shared goals, vision, and engagement

Creating a program

Discovery, identification, and validation

Documenting your high-level approach

Creating the roadmap

Architecture definition

Accompanying documentation

Summary

6

Building an Architecture – Application Blueprints

Application design considerations

Life cycle models

Environment

Considerations for waterfall projects

Requirements phase

Design phase

Implementation phase

Verification phase

Maintenance phase

Case study – waterfall development

Considerations for Agile projects

Conception phase

Inception phase

Construction phase

Release phase

Production phase

Retirement phase

Case study – Agile development

Considerations for DevOps projects

Develop

Build

Unit test

Deploy (integrate)

Quality assurance

Production

Validate

Case study – DevOps/DevSecOps development

Process for application security design

Systems security engineering

Architecture definition process

Architecture definition

Documentation

Validation

Modifying the SDLC and development processes

Summary

Part 3: Execution

7

Execution –Applying Architecture Models

Process steps

Technical design

What specific provider do we use to do this?

Do we need additional infrastructure (VPN, access points, etc.)?

What client software do users require (if any)?

Creating technical implementation strategies

Assess constraints, synergies, and areas of opportunity

Validating against likely threat paths and creating a skeleton solution document

Validating implementation strategies

Finalizing the documentation

Operational integration

Changing context and evolution

Execution monitoring

Case study – Operational integration

Telemetry

Selecting strategic metrics

Selecting operational metrics

Summary

8

Execution – Future-Proofing

Overcoming obstacles in project execution

Scope and requirements

Support failure and organizational issues

Resource shortfalls

Communication failure

Technical and environmental issues

Future-proofing designs

Establishing a virtuous cycle

Monitoring our own environment for changes

Monitoring for external changes

Specifics for machine learning projects

Case study – future-proofing

Summary

9

Putting It All Together

Virtuous cycles

Adapting architectural processes

Tips and tricks

Hone your ability to listen

Cultivate empathy

Have just enough process

When in doubt, over-communicate

Be ready to walk away

Gotchas

Be aware of (but don’t play) politics

Don’t shirk the preparation

Stay engaged until the end

Leave ego at the door

Use a multi-disciplinary approach

Case study: gotchas

Summary

Index

Other Books You May Enjoy

Preface

Cybersecurity is quickly becoming a make or break topic area for most businesses. We can all cite numerous examples from the headlines that underscore the importance of security: this includes security issues at both large and small companies, breach notifications from the online services we use, and incidents in the companies we work with and for. We all know stories of vulnerable software, scammed users, accidental misconfiguration of hardware or software, and numerous other events that can and do have potentially disastrous consequences for both individuals and organizations.

All of this is happening against a backdrop where artificial intelligence (AI) and machine learning (ML) are becoming ubiquitous and changing how we do things. More and more, business processes are changing their processes to adapt and accommodate these new methods. They’re changing the services they offer, how they engage with customers and partners, how they interact with stakeholders (employees, partners, customers, and others), and numerous other changes.

To help prevent security issues while at the same time best positioning to gain benefits from new technologies such as AI and ML, organizations continue to place increasing importance on cybersecurity. They are making it a higher priority than it has historically been and investing in it accordingly. But how can an organization know whether they are investing in the right places? Resources are finite, which means that they need to be selective about what security measures they implement and where they apply those limited budgets. How can organizations know when they have enough security? How do they know that they’ve attained their security goals when the necessary steps are dependent on factors unique to them: what the organization does, how it does it, who’s involved, and why? Everything from organizational culture to business context to governing regulations to geography and even industry can play a role here.

Cybersecurity architecture is one way to systematically, holistically, and repeatably answer these questions. Much like a software architect creates a vision for how to achieve a user’s goals in software or a network engineer creates a vision for how to achieve the performance and reliability targets for network communications, the cybersecurity architect works to create a vision for cybersecurity. This can be for an application, a network, a process, a business unit, or the entire organization itself.

This book takes a practical look at the nuts and bolts of defining, documenting, validating, and, ultimately, delivering an architectural vision. It draws on existing standards and frameworks for cybersecurity architecture, outlining where (and more importantly, how) they can be applied to the architecture process in your organization. This book does this by walking through the architecture process step by step, discussing why each step provides the value it does and how to use it to maximum benefit, and provides tips, gotchas, case studies, and techniques from numerous working architects in the field to supplement our own perspective.

Who this book is for

This book is primarily for cybersecurity practitioners getting started with cybersecurity architecture or those already following a systematic architecture process who would like to build their skills. For the novice, we walk through the fundamental skills and techniques used in the architecture process and, for those with some experience already, we supplement our viewpoint with that of other architecture specialists currently in the field to help them think about challenges in a new way or adapt strategies that have been successful for others into their own toolkit.

What this book covers

Chapter 1, What Is Cybersecurity Architecture?, provides an overview of cybersecurity architecture: what it is, why it’s useful, the business value that it brings to the organization employing it, and the role of the cybersecurity architect within an organization. We highlight the history of cybersecurity architecture and important standards, frameworks, and approaches that the architect can draw upon, and lay out the fundamental requirements for the architect before they get started.

Chapter 2, Core of Solution Building, helps the architect assess the important touchstones, contextual background, and goals of the organization. Architecture doesn’t happen in a vacuum: the design must be reflective of the organization’s needs, its business, and its mission. This chapter helps the architect understand that context – the boundaries around what the organization considers important – that will allow the architect to systematically and purposefully take action.

Chapter 3, Building an Architecture – Scope and Requirements, looks at how, as with any project, the outcome must be dictated by what the organization needs. This chapter presents methods for discovering the scope within which the architect must design as well as the core information about requirements that their solution should address.

Chapter 4, Building an Architecture – Your Toolbox, explains how any project you undertake has a set of tools that will let you do the job successfully. With them, the job is easy – without them, there’s nothing harder. This chapter is all about building out the toolbox that you will need as you approach the design process. Getting your tools ready ahead of time allows you to have them when you need them.

Chapter 5, Building an Architecture – Developing Enterprise Blueprints, outlines how to gather, document, and validate the necessary information that will allow you to create a high-level architectural definition. This lets you select a solution approach that is consistent with what the organization needs and is documented in such a way as to protect the organization, streamline efforts, and ensure that technical implementation approaches are optimal.

Chapter 6, Building an Architecture – Application Blueprints, looks at how, in many ways, building a cybersecurity architecture for an application is similar to doing so for the organization in aggregate or for a network. However, because there are different audiences to whom we must present designs and approaches (and that we must of necessity work collaboratively with), there are some elements of the process that are different. To accommodate this, we provide specific guidance on application security architecture efforts within this chapter.

Chapter 7, Execution – Applying Architecture Models, walks through how to implement your design concept technically, walking you through elements of execution and realization of the implementation, as at this point, you will have created a high-level “model”: a design that meets the organization’s needs. However, the best ideas on paper don’t actually provide value until they are implemented.

Chapter 8, Execution – Future-Proofing, goes through the process of ensuring that a design (and subsequent implementation) that you’ve deployed stays meaningful over time. It discusses ways to ensure that you keep apprised of changes, that you monitor the effectiveness of your solution over time, and that you build in and adapt instrumentation (e.g., metrics) to keep things running smoothly after deployment.

Chapter 9, Putting It All Together, closes the book with strategies that you can use to improve your architecture skills, improve the processes you follow, and ensure that, with each project you take on, you optimize what you do. We present guidance about common issues that architects run into, how to avoid them, and advice for the architect drawn from the experiences of those in the field.

To get the most out of this book

To be as practical in our approach as possible, we’ve made a few assumptions about you, your skill level, and your needs. First, we assume that you will know the basics of cybersecurity (or information security), such as a working knowledge of common security controls. Second, we assume a baseline of enterprise technology knowledge.

We’ve also assumed that the organization in which you will be applying the techniques we discuss is like most: one that could benefit from increased architectural rigor but where rigor itself is not an end goal. Larger organizations that systematically follow a highly rigorous process – or service providers with contractual requirements to do so – will find that we have scaled back or streamlined some elements of the process to make it accessible and achievable to smaller teams. In general, we have stated explicitly where, how, and why we have made these changes in the sections where we do so.

Lastly, we suggest (but it is not required) that you have one or more active problems to which you can apply the techniques in this book, meaning that you can apply the process sequentially as you learn it to the real-world challenges in your job. Being able to apply the concepts directly helps ensure that the principles are retained.

Conventions used

There are several conventions used throughout this book.

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: “Select System info from the Administration panel.”

In some cases, we wish to highlight areas of importance to the reader. Tips or important notes appear as follows:

Important note

Appears like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, select your book, click on the Errata Submission Form link, and enter the details.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Practical Cybersecurity Architecture, 2nd edition, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/9781837637164

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1: Security Architecture

This section gives you an overview of what cybersecurity architecture means: what it is, what it includes (and what it doesn’t), why it’s useful, and what the role of a cybersecurity architect may encompass, depending on their focus and the organization they work in. These chapters work through the origins of security architecture, common frameworks to architecture, and the evolution of the discipline.

By understanding why cybersecurity provides value, the architect can then ensure that they are adding the most value to their organization. The first chapter in this section outlines the business value that the cybersecurity architecture process brings about, while the second chapter helps architects understand the business and, by extension, the differing needs of different organizations. Since the needs and context of organizations differ, the architect should begin with an understanding of the business and adapt their role in it to ensure that the work they do will be viewed as necessary, welcome, and valuable to the organization based on what the organization does, how it does it, and its particular set of needs.

This section comprises the following chapters:

Chapter 1, What Is Cybersecurity Architecture?Chapter 2, Architecture – The Core of Solution Building

1

What Is Cybersecurity Architecture?

Let’s face it – cybersecurity can be a scary, stress-inducing proposition. And it’s no wonder. Cybersecurity in modern business is high stakes. We’ve all seen headlines about data breaches, attacks, and even accidental exposures impacting some of the largest companies (not to mention governments) in the world. The truth is, if you do security wrong, you open yourself up to being attacked by numerous potential adversaries, such as cybercriminals, hacktivists, nation-states, or any number of other parties. Even if you do everything perfectly, circumstances can still put you at risk anyway. It’s a challenging field – and it can be difficult to get it right.

We want to be clear right from the start that this book is not about a new security architecture framework or a new set of competing architectural methods to what already exists, and it’s not a reference book. These already exist and provide plenty of value to those actively using them. In fact, one might argue that the single biggest limiting factor to the discipline itself is the fact that more people aren’t actively using, or have detailed knowledge of, that excellent source material.

Therefore, rather than contributing to that problem by muddying the waters or adding competing foundational material, we intend to demonstrate clearly how to do the work, which means we intend this book to read more like a playbook designed to build muscle memory.

Think about the difference between reading a book on ballistic physics versus working with a pitching coach. The physics book will almost certainly lead you to a deeper understanding of the mechanics, forces, and mathematics of a baseball in flight than you could ever possibly derive from working with a coach. Yet, even with the deepest understanding of the physics, you probably won’t pitch a no-hitter for the Yankees. That is, you won’t do so unless and until you also build the requisite muscle memory, put in the time to practice and hone your technique, and work with those who can help you improve. However, knowledge of the underlying physics can inform (to great effect) the value derived from working with a coach as those principles can help you hone your technique and realize even greater potential.

Therefore, our intention with this book is for it to act as a sort of training guide for those looking to build their skills in the cybersecurity architecture discipline: either because they are in a new architectural role and want to build the necessary practical skills, or because they’re an existing practitioner who wants to improve. We will do this by building on the theoretical models, drawing from them, and incorporating them to lay out specific, practical steps that can be followed by anyone willing to do the work. We will focus on one set of steps and techniques – those that have worked for us – and supplement those with techniques that we’ve gathered from practitioners throughout the industry in architectural roles (either on a large or small scale).

Note that this book also isn’t a catalog of security controls. We have purposefully refrained from listing in detail the hundreds – if not thousands – of possible controls, security techniques, technical countermeasures, and other specific technologies that you might choose to adopt as implementation strategies. Consider, by analogy, a primer on the techniques of cooking. Would such a book dedicate hundreds of pages to descriptions of every possible ingredient that a home cook or professional chef might encounter throughout their career? No. Such an exercise would make for boring reading (in fact, it would serve as a distraction from the book’s utility), would rapidly become outdated, and would serve little purpose as that material is available through numerous other avenues. Instead, we’ve chosen to focus on the techniques and principles of architecture, leaving detailed descriptions of specific technical strategies to the numerous standards and guidance that already exist.

Throughout this book, we’ll introduce you to many practitioners and provide their viewpoints, their philosophy, their advice about processes, where they’ve been successful, and where they’ve made mistakes. We’ve tried to assemble those who have different perspectives on the discipline of architecture: some from large companies, some from small companies, some heavily invested in formal architectural models and frameworks (in a few cases, those who’ve authored them), and those that espouse less formal processes. The one thing these professionals all have in common is they’ve all been successful as security architects. Through interviews with these individuals, we’ve attempted to capture their viewpoints, the nuances of their techniques, and what they feel is most important. As we do this, you may notice that some of the perspectives differ from each other – in some cases, their advice differs from our approach. This is to be expected. We hope that by presenting all these viewpoints to you, they will help you better synthesize and integrate the concepts, provide you with alternative approaches if the way we’ve done things isn’t the way that’s most comfortable for you, and provide a window into the many different strategies that you can use to achieve your security architecture goals.

Important note

As this is the second edition of this book, note that the titles provided for those we’ve interviewed reflect their titles at the point in time when we conducted the interview (or interviews) with them.

These short, pointed anecdotes from security architects in the field are intended to provide real-life data and feedback: what worked, what didn’t, what the downstream impacts were as a result of a particular course of action, and so on. It won’t always be the case that your results will exactly mirror what happened in someone else’s experience (since contexts such as industry, organizational factors, regulatory environment, and numerous other elements can play a role), but seeing the cause and effect along with some description of the circumstances can still provide value.

So, to get the most value out of this book, we suggest that you follow along with us. You will still derive value from just reading the words and learning the concepts. However, we believe you will derive even more value if you seek to apply them – as they are presented to you and while they are still fresh in your mind – to your job. If you’ve never done architecture before, try to develop and implement a plan, working side by side with us as you do so. If you’re an existing practitioner, try these techniques as a supplement to your own.

Keeping in mind this philosophy, it’s natural to be anxious to move directly into the practical steps of building a security architecture. Before we can get into the nitty-gritty, though, there are a few things we need to level set. This first chapter is intended to cover these prerequisites. We believe that understanding the why of cybersecurity architecture (that is, why do it in the first place?) is perhaps the most valuable thing you can learn in this book or any other.

This first chapter is almost entirely focused on two things. The first is making sure you understand why cybersecurity architecture exists in the first place (that is, the value it provides, and how and why it helps organizations reach their security goals). The second is teeing up some of the background information necessary for us to leap right into Chapter 2, Architecture – The Core of Solution Building. This chapter covers the following topics:

Understanding the need for cybersecurityWhat is cybersecurity architecture?Architecture, security standards, and frameworksArchitecture roles and processes

Understanding the need for cybersecurity

“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 some strategies help do so.

Cybersecurity architecture, the discipline of strategically planning out 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 optimally and efficiently.

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 with a roadmap that they can follow to be successful in their job. 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 they are architects themselves and there’s no right or wrong way to do it (the right way is the way that works for them). By pulling together experiences from an array of practitioners, we hope that some of their techniques can help spark creative new approaches in your 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.

What is cybersecurity architecture?

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

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

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

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

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

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

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

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

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

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

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

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

Identifies the goals and requirements for securityDevelops a vision for how to achieve those goalsWorks with other technical specialists to make sure that their vision is practical and feasibleWorks with those specialists to put a roadmap togetherWorks in lockstep with other technologists to make the vision a reality

Network versus application security architecture

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

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

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

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

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

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

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

The difference between architecture and secure architecture

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

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

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

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

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

Important note

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

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

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.Implementation: The process of making required investments, setting resources to tasks, writing code, implementing hardware, and taking any other actions you may need to execute.Maintenance: The continual process of maintaining the solution you’ve put in place to make sure that it continues to meet the goals over time.

Represented visually, this would look something like Figure 1.1:

Figure 1.1 – Generic execution process

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

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

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

The benefits of building secure, resilient architectures

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

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

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

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

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

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

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

The role of the architect

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

– Steve Orrin, Federal CTO at Intel Corporation

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

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

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

The approach to security within the organization is well-plannedResources are used optimallyThe goals of the organization (both security as well as business and functional goals) are met throughoutThere are measures in place that allow future growth and expansion

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

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

Secure network architectures

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

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

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

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

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

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

CIA

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

Figure 1.2 – The CIA triad

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

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

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

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

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

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

Designing for resilience

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

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

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

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

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

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

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