The Structure of the Book
There are three parts to this book: Parts I, II, and III. Part I presents and then attempts to explain the practices, knowledge domains, and methods that must be brought to bear when performing assessments and threat models.
Part II is a series of linked assessments. The assessments are intended to build upon each other; I have avoided repeating the same analysis and solution set over and over again. In the real world, unique circumstances and individual treatments exist within a universe of fairly well known and repeating architecture patterns. Alongside the need for a certain amount of brevity, I also hope that each assessment may be read by itself, especially for experienced security architects who are already familiar with the typical, repeating patterns of their practice. Each assessment adds at least one new architecture and its corresponding security solutions.
Part III is an abbreviated exploration into building the larger practice encompassing multiple security architects and engineers, multiple stakeholders and teams, and the need for standards and repeating practices. This section is short; I’ve tried to avoid repeating the many great books that already explain in great detail a security program. These usually touch upon an assessment program within the context of a larger computer security practice. Instead, I’ve tried to stay focused on those facets that apply directly to an applied security architecture practice. There is no doubt that I have left out many important areas in favor of keeping a tight focus.
I assume that many readers will use the book as a reference for their security architecture and system risk-assessment practice. I hope that by clearly separating tools and preparation from analysis, and these from program, it will be easier for readers to find what they need quickly, whether through the index or by browsing a particular part or chapter.
In my (very humble) experience, when performing assessments, nothing is as neat as the organization of any methodology or book. I have to jump from architecture to attack surface, explain my risk reasoning, only to jump to some previously unexplored technical detail. Real-world systems can get pretty messy, which is why we impose the ordering that architecture and, specifically, security architecture provides.