Book Image

Practical Cybersecurity Architecture - Second Edition

By : Diana Kelley, Ed Moyle
Book Image

Practical Cybersecurity Architecture - Second Edition

By: Diana Kelley, Ed Moyle

Overview of this book

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.
Table of Contents (15 chapters)
Part 1: Security Architecture
Part 2: Building an Architecture
Part 3: Execution

Risk management and compliance

If you limit yourself only to looking at what is already explicitly documented in the organization in the form of policies, procedures, supporting documentation, and other existing documentation (for example, management artifacts), you’ll find that you have a good picture but not a complete one. At this stage, the picture can be potentially incomplete in two very important ways. First, there can often be other security objectives that are important to the organization but that are unrealized by the authors of policy and procedure documentation. To see this in action, recall the earlier example where we posited a developer who had spent years working inside a particular technology stack (for example working within the Java ecosystem) to the exclusion of all others. They may potentially take that technology stack so much for granted that the idea of stepping outside of it is a place their thought process just won’t naturally go.

The second...