Desktop version

Home arrow Computer Science arrow Securing Systems Applied Security Architecture and Threat Models


  • 1. Swanson, M. and Guttman B. (September 1996). “Generally Accepted Principles and Practices for Securing Information Technology Systems.” National Institute of Standards and Technology, Technology Administration, US Department of Commerce (NIST 800-14, p. 17).
  • 2. Ashton, K. (22 June 2009). “hat ‘Internet of hings’ hing: In the real world things matter more than ideas.” RFID Journal. Retrieved from articles/view?4986.
  • 3. Grossman, L. K. (1995). Electronic Republic: Reshaping American Democracy for the Information Age (A Twentieth Century Fund Book), p. 3. Viking Adult.
  • 4. Swanson, M. and Guttman B. (September 1996). “Generally Accepted Principles and Practices for Securing Information Technology Systems.” National Institute of Standards and Technology, Technology Administration, US Department of Commerce (NIST 800-14, p. 17).


Often when the author is speaking at conferences about the practice of security architecture, participants repeatedly ask, “How do I get started?” At the present time, there are few holistic works devoted to the art and the practice of system security assessment.[1]

Yet despite the paucity of materials, the practice of security assessment is growing rapidly. The information security industry has gone through a transformation from reactive approaches such as Intrusion Detection to proactive practices that are embedded into the Secure Development Lifecycle (SDL). Among the practices that are typically required is a security architecture assessment. Most Fortune 500 companies are performing some sort of an assessment, at least on critical and major systems.

To meet this demand, there are plenty of consultants who will gladly offer their expensive services for assessments. But consultants are not typically teachers; they are not engaged long enough to provide sufficient longitudinal mentorship. Organizations attempting to build an assessment practice may be stymied if they are using a typical security consultant. Consultants are rarely geared to explaining what to do. They usually don’t supply the kind of close relationship that supports long-term training. Besides, this would be a conflict of interest—the stronger the internal team, the less they need consultants!

Explaining security architecture assessment has been the province of a few mentors who are scattered across the security landscape, including the author. Now, therefore, seems a like a good time to offer a book describing, in detail, how to actually perform a security assessment, from strategy to threat model, and on through producing security requirements that can and will get implemented.

Training to assess has typically been performed through the time-honored system of mentoring. The prospective security architect follows an experienced practitioner for some period, hoping to understand what is happening. The mentee observes the mentor as he or she examines in depth systems’ architectures.

The goal of the analysis is to achieve the desired security posture. How does the architect factor the architecture into components that are relevant for security analysis? And, that “desired” posture? How does the assessor know what that posture is? At the end of the analysis, through some as yet unexplained “magic”—really, the experience and technical depth of the security architect—requirements are generated that, when implemented, will bring the system up to the organization’s security requirements. The author has often been asked by mentees, “How do you know what questions to ask?” or, “How can you find the security holes so quickly?”

Securing Systems is meant to step into this breach, to fill the gap in training and mentorship. This book is more than a step-by-step process for performing an analysis. For instance, this book offers a set of prerequisite knowledge domains that is then brought into a skilled analysis. What does an assessor need to understand before she or he can perform an assessment?

Even before assembling the required global and local knowledge set, a security architect will have command of a number of domains, both within security and without. Obviously, it’s imperative to have a grasp of typical security technologies and their application to systems to build the defense. These are typically called “security controls,” which are usually applied in sets intended to build a “defense-in-depth,” that is, a multilayered set of security controls that, when put together, complement each other as well as provide some protection against the failure of each particular control. In addition, skilled security architects usually have at least some grounding in system architecture—the practice of defining the structure of large-scale systems. How can one decompose an architecture sufficiently to provide security wisdom if one cannot understand the architecture itself? Implicit in the practice of security architecture is a grasp of the process by which an architect arrives at an architecture, a firm grasp on how system structures are designed. Typically, security architects have significant experience in designing various types of computer systems.

And then there is the ongoing problem of calculating information security risk. Despite recent advances in understanding, the industry remains largely dependent upon expert opinion. Those opinions can be normalized so that they are comparable. Still, we, the security industry, are a long way from hard, mathematically repeatable calculations. How does the architect come to an understanding whereby her or his risk “calculation” is more or less consistent and, most importantly, trustworthy by decision makers?

This book covers all of these knowledge domains and more. Included will be the author’s tips and tricks. Some of these tips will, by the nature of the work, be technical. Still, complex systems are built by teams of highly skilled professionals, usually crossing numerous domain and organizational boundaries. In order to secure those systems, the skilled security architect must not alienate those who have to perform the work or who may have a “no” vote on requirements. Accumulated through the “hard dint” of experience, this book will offer tricks of the trade to cement relationships and to work with inevitable resistance, the conflict that seems to predictably arise among teams with different viewpoints and considerations who must come to definite agreements.

There is no promise that reading this book will turn the reader into a skilled security architect. However, every technique explained here has been practiced by the author and, at least in my hands, has a proven track record. Beyond that endorsement, I have personally trained dozens of architects in these techniques. These architects have then taught the same techniques and approaches down through several generations of architecture practice. And, indeed, these techniques have been used to assess the security of literally thousands of individual projects, to build living threat models, and to provide sets of security requirements that actually get implemented. A few of these systems have resisted ongoing attack through many years of exposure; their architectures have been canonized into industry standards.*

My promise to the reader is that there is enough information presented here to get one started. Those who’ve been tasked for the first time with the security assessment of systems will find hard answers about what to learn and what to do. For the practitioner, there are specific techniques that you can apply in your practice. These techniques are not solely theoretical, like, “programs should . . .” And they aren’t just “ivory tower” pronouncements. Rather, these techniques consist of real approaches that have delivered results on real systems. For assessment program managers, I’ve provided hints along the way about successful programs in which I’ve been involved, including a final chapter on building a program. And for the expert, perhaps I can, at the very least, spark constructive discussion about what we do and how we do it? If something that I’ve presented here can seed improvement to the practice of security architecture in some significant way, such an advance would be a major gift.

  • [1] here are numerous works devoted to organizational “security assessment.” But few describein any detail the practice of analyzing a system to determine what, if any, security must beadded to it before it is used.
< Prev   CONTENTS   Source   Next >