Book Image

Practical Cybersecurity Architecture

By : Ed Moyle, Diana Kelley
Book Image

Practical Cybersecurity Architecture

By: Ed Moyle, Diana Kelley

Overview of this book

Cybersecurity architects work with others to develop a comprehensive understanding of the business' requirements. They work with stakeholders to plan designs that are implementable, goal-based, and in keeping with the governance strategy of the organization. With this book, you'll explore the fundamentals of cybersecurity architecture: addressing and mitigating risks, designing secure solutions, and communicating with others about security designs. The book outlines strategies that will help you work with execution teams to make your vision a concrete reality, along with covering ways to keep designs relevant over time through ongoing monitoring, maintenance, and continuous improvement. As you progress, you'll also learn about recognized frameworks for building robust designs as well as strategies that you can adopt to create your own designs. By the end of this book, you will have the skills you need to be able to architect solutions with robust security components for your organization, whether they are infrastructure solutions, application solutions, or others.
Table of Contents (14 chapters)
1
Section 1:Security Architecture
4
Section 2: Building an Architecture
9
Section 3:Execution

Building blocks of secure design

Any discussion about the requisite tools in your design toolbox wouldn't be complete without some discussion of the actual security mechanisms that you'll employ as part of your design. These represent specific measures you might use—and specific objectives that you might target—as part of a broader, overarching security design.

It's important to understand what these controls are and are not. They are not implementations. Any given control can be implemented in a myriad of different ways. For example, you might have a control specifying that any administrative access to production systems (and system components) must be logged and recorded. However, this control doesn't outline how you'd do that; instead, context, circumstances, and the organization itself will dictate how. For example, if access to the production system happens via a terminal (that is, a user at the keyboard), you might use the native logging...