Securing
Systems

Applied Security
Architecture and
Threat Models

Securing
Systems

Applied Security
Architecture and
Threat Models

Brook S.E. Schoenfield
Forewords by John N. Stewart and James F. Ransome

CRC Press
Taylor & Francis Group
6000 Broken Sound Parkway NW, Suite 300
Boca Raton, FL 33487-2742

© 2015 by Taylor & Francis Group, LLC
CRC Press is an imprint of Taylor & Francis Group, an Informa business

No claim to original U.S. Government works
Version Date: 20150417

International Standard Book Number-13: 978-1-4822-3398-8 (eBook – PDF)

This book contains information obtained from authentic and highly regarded sources. Reasonable
efforts have been made to publish reliable data and information, but the author and publisher cannot
assume responsibility for the validity of all materials or the consequences of their use. The authors and
publishers have attempted to trace the copyright holders of all material reproduced in this publication
and apologize to copyright holders if permission to publish in this form has not been obtained. If any
copyright material has not been acknowledged please write and let us know so we may rectify in any
future reprint.

Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced,
transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or
hereafter invented, including photocopying, microfilming, and recording, or in any information stor-
age or retrieval system, without written permission from the publishers.

For permission to photocopy or use material electronically from this work, please access www.copy-
right.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222
Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that pro-
vides licenses and registration for a variety of users. For organizations that have been granted a photo-
copy license by the CCC, a separate system of payment has been arranged.

Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are
used only for identification and explanation without intent to infringe.

Visit the Taylor & Francis Web site at
http://www.taylorandfrancis.com

and the CRC Press Web site at
http://www.crcpress.com

v

To the many teachers who’ve pointed me down the path; the managers who have sup-
ported my explorations; the many architects and delivery teams who’ve helped to refine
the work; to my first design mentors—John Caron, Roddy Erickson, and Dr. Andrew
Kerne—without whom I would still have no clue; and, lastly, to Hans Kolbe, who once
upon a time was our human fuzzer.

Each of you deserves credit for whatever value may lie herein.
The errors are all mine.

Dedication

vii

Contents

Dedication v

Contents vii

Foreword by John N. Stewart xiii

Foreword by Dr. James F. Ransome xv

Preface xix

Acknowledgments xxv

About the Author xxvii

Part I
Introduction 3

The Lay of Information Security Land 3
The Structure of the Book 7
References 8

Chapter 1: Introduction 9

1.1 Breach! Fix It! 11
1.2 Information Security, as Applied to Systems 14
1.3 Applying Security to Any System 21
References 25

Chapter 2: The Art of Security Assessment 27

2.1 Why Art and Not Engineering? 28
2.2 Introducing “The Process” 29

viii Securing Systems

2.3 Necessary Ingredients 33
2.4 The Threat Landscape 35

2.4.1 Who Are These Attackers? Why Do They Want
to Attack My System? 36

2.5 How Much Risk to Tolerate? 44
2.6 Getting Started 51
References 52

Chapter 3: Security Architecture of Systems 53

3.1 Why Is Enterprise Architecture Important? 54
3.2 The “Security” in “Architecture” 57
3.3 Diagramming For Security Analysis 59
3.4 Seeing and Applying Patterns 70
3.5 System Architecture Diagrams and Protocol Interchange

Flows (Data Flow Diagrams) 73
3.5.1 Security Touches All Domains 77
3.5.2 Component Views 78

3.6 What’s Important? 79
3.6.1 What Is “Architecturally Interesting”? 79

3.7 Understanding the Architecture of a System 81
3.7.1 Size Really Does Matter 81

3.8 Applying Principles and Patterns to Specific Designs 84
3.8.1 Principles, But Not Solely Principles 96

Summary 98
References 98

Chapter 4: Information Security Risk 101

4.1 Rating with Incomplete Information 101
4.2 Gut Feeling and Mental Arithmetic 102
4.3 Real-World Calculation 105
4.4 Personal Security Posture 106
4.5 Just Because It Might Be Bad, Is It? 107
4.6 The Components of Risk 108

4.6.1 Threat 110
4.6.2 Exposure 112
4.6.3 Vulnerability 117
4.6.4 Impact 121

4.7 Business Impact 122
4.7.1 Data Sensitivity Scales 125

Contents ix

4.8 Risk Audiences 126
4.8.1 The Risk Owner 127
4.8.2 Desired Security Posture 129

4.9 Summary 129
References 130

Chapter 5: Prepare for Assessment 133

5.1 Process Review 133
5.1.1 Credible Attack Vectors 134
5.1.2 Applying ATASM 135

5.2 Architecture and Artifacts 137
5.2.1 Understand the Logical and Component Architecture

of the System 138
5.2.2 Understand Every Communication Flow and Any

Valuable Data Wherever Stored 140
5.3 Threat Enumeration 145

5.3.1 List All the Possible Threat Agents for This Type
of System 146

5.3.2 List the Typical Attack Methods of the Threat Agents 150
5.3.3 List the System-Level Objectives of Threat Agents

Using Their Attack Methods 151
5.4 Attack Surfaces 153

5.4.1 Decompose (factor) the Architecture to a Level That
Exposes Every Possible Attack Surface 154

5.4.2 Filter Out Threat Agents Who Have No Attack
Surfaces Exposed to Their Typical Methods 159

5.4.3 List All Existing Security Controls for Each Attack
Surface 160

5.4.4 Filter Out All Attack Surfaces for Which There Is
Sufficient Existing Protection 161

5.5 Data Sensitivity 163
5.6 A Few Additional Thoughts on Risk 164
5.7 Possible Controls 165

5.7.1 Apply New Security Controls to the Set of Attack
Services for Which There Isn’t Sufficient Mitigation 166

5.7.2 Build a Defense-in-Depth 168
5.8 Summary 170
References 171

Part I
Summary 173

x Securing Systems

Part II
Introduction 179

Practicing with Sample Assessments 179
Start with Architecture 180

A Few Comments about Playing Well with Others 181
Understand the Big Picture and the Context 183

Getting Back to Basics 185
References 189

Chapter 6: eCommerce Website 191

6.1 Decompose the System 191
6.1.1 The Right Level of Decomposition 193

6.2 Finding Attack Surfaces to Build the Threat Model 194
6.3 Requirements 209

Chapter 7: Enterprise Architecture 213

7.1 Enterprise Architecture Pre-work: Digital Diskus 217
7.2 Digital Diskus’ Threat Landscape 218
7.3 Conceptual Security Architecture 221
7.4 Enterprise Security Architecture Imperatives

and Requirements 222
7.5 Digital Diskus’ Component Architecture 227
7.6 Enterprise Architecture Requirements 232
References 233

Chapter 8: Business Analytics 235

8.1 Architecture 235
8.2 Threats 239
8.3 Attack Surfaces 242

8.3.1 Attack Surface Enumeration 254
8.4 Mitigations 254
8.5 Administrative Controls 260

8.5.1 Enterprise Identity Systems (Authentication
and Authorization) 261

8.6 Requirements 262
References 266

Contents xi

Chapter 9: Endpoint Anti-malware 267

9.1 A Deployment Model Lens 268
9.2 Analysis 269
9.3 More on Deployment Model 277
9.4 Endpoint AV Software Security Requirements 282
References 283

Chapter 10: Mobile Security Software with Cloud Management 285

10.1 Basic Mobile Security Architecture 285
10.2 Mobility Often Implies Client/Cloud 286
10.3 Introducing Clouds 290

10.3.1 Authentication Is Not a Panacea 292
10.3.2 The Entire Message Stack Is Important 294

10.4 Just Good Enough Security 295
10.5 Additional Security Requirements for a Mobile and

Cloud Architecture 298

Chapter 11: Cloud Software as a Service (SaaS) 301

11.1 What’s So Special about Clouds? 301
11.2 Analysis: Peel the Onion 302

11.2.1 Freemium Demographics 306
11.2.2 Protecting Cloud Secrets 308
11.2.3 The Application Is a Defense 309
11.2.4 “Globality” 311

11.3 Additional Requirements for the SaaS Reputation Service 319

References 320

Part II
Summary 321

Part III
Introduction 327

Chapter 12: Patterns and Governance Deliver Economies of Scale 329

12.1 Expressing Security Requirements 337
12.1.1 Expressing Security Requirements to Enable 338
12.1.2 Who Consumes Requirements? 339

xii Securing Systems

12.1.3 Getting Security Requirements Implemented 344
12.1.4 Why Do Good Requirements Go Bad? 347

12.2 Some Thoughts on Governance 348
Summary 351
References 351

Chapter 13: Building an Assessment Program 353

13.1 Building a Program 356
13.1.1 Senior Management’s Job 356
13.1.2 Bottom Up? 357
13.1.3 Use Peer Networks 359

13.2 Building a Team 364
13.2.1 Training 366

13.3 Documentation and Artifacts 369
13.4 Peer Review 372
13.5 Workload 373
13.6 Mistakes and Missteps 374

13.6.1 Not Everyone Should Become an Architect 374
13.6.2 Standards Can’t Be Applied Rigidly 375
13.6.3 One Size Does Not Fit All, Redux 376
13.6.4 Don’t Issue Edicts Unless Certain of Compliance 377

13.7 Measuring Success 377
13.7.1 Invitations Are Good! 378
13.7.2 Establish Baselines 378

13.8 Summary 380
References 382

Part III
Summary and Afterword 383

Summary 383
Afterword 385

Index 387

xiii

Foreword

As you read this, it is important to note that despite hundreds to thousands of people-
years spent to date, we are still struggling mightily to take the complex, de-compose
into the simple, and create the elegant when it comes to information systems. Our
world is hurtling towards an always on, pervasive, interconnected mode in which soft-
ware and life quality are co-dependent, productivity enhancements each year require
systems, devices and systems grow to 50 billion connected, and the quantifiable and
definable risks all of this creates are difficult to gauge, yet intuitively unsettling, and are
slowly emerging before our eyes.

“Arkhitekton”—a Greek word preceding what we speak to as architecture today, is
an underserved idea for information systems, and not unsurprisingly, security architec-
ture is even further underserved. The very notion that through process and product,
systems filling entire data centers, information by the pedabyte, transaction volumes
at sub-millisecond speed, and compute systems doubling capability every few years, is
likely seen as impossible—even if needed. I imagine the Golden Gate bridge seemed
impossible at one point, a space station also, and buildings such as the Burj Khalifa, and
yet here we are admiring each as a wonder unto themselves. None of this would be pos-
sible without formal learning, training architects in methods that work, updating our
training as we learn, and continuing to require a demonstration for proficiency. Each
element plays that key role.

The same is true for the current, and future, safety in information systems.
Architecture may well be the savior that normalizes our current inconsistencies, engen-
ders a provable model that demonstrates efficacy that is quantifiably improved, and
tames the temperamental beast known as risk. It is a sobering thought that when sys-
tems are connected for the first time, they are better understood than at any other time.
From that moment on, changes made—documented and undocumented—alter our
understanding, and without understanding comes risk. Information systems must be
understood for both operational and risk-based reasons, which means tight definitions
must be at the core—and that is what architecture is all about.

For security teams, both design and protect, it is our time to build the tallest, and
safest, “building.” Effective standards, structural definition, deep understanding with

xiv Securing Systems

validation, a job classification that has formal methods training, and every improving
and learning system that takes knowledge from today to strengthen systems installed
yesterday, assessments and inspection that look for weaknesses (which happen over
time), all surrounded by a well-built security program that encourages if not demands
security architecture, is the only path to success. If breaches, so oftentimes seen as
avoidable ex post facto, don’t convince you of this, then the risks should.

We are struggling as a security industry now, and the need to be successful is higher
than it has ever been in my twenty-five years in it. It is not good enough just to build
something and try and secure it, it must be architected from the bottom up with secu-
rity in it, by professionally trained and skilled security architects, checked and validated
by regular assessments for weakness, and through a learning system that learns from
today to inform tomorrow. We must succeed.

– John N. Stewart
SVP, Chief Security & Trust Officer

Cisco Systems, Inc.

About John N. Stewart:

John N. Stewart formed and leads Cisco’s Security and Trust Organization, underscor-
ing Cisco’s commitment to address two key issues in boardrooms and on the minds
of top leaders around the globe. Under John’s leadership, the team’s core missions are
to protect Cisco’s public and private customers, enable and ensure the Cisco Secure
Development Lifecycle and Trustworthy Systems efforts across Cisco’s entire mature
and emerging solution portfolio, and to protect Cisco itself from the never-ending, and
always evolving, cyber threats.

Throughout his 25-year career, Stewart has led or participated in security initiatives
ranging from elementary school IT design to national security programs. In addition to
his role at Cisco, he sits on technical advisory boards for Area 1 Security, BlackStratus,
Inc., RedSeal Networks, and Nok Nok Labs. He is a member of the Board of Directors
for Shape Security, Shadow Networks, Inc., and the National Cyber-Forensics Training
Alliance (NCFTA). Additionally, Stewart serves on the Cybersecurity Think Tank at
University of Maryland University College, and on the Cyber Security Review to Prime
Minister & Cabinet for Australia. Prior, Stewart served on the CSIS Commission on
Cybersecurity for the 44th Presidency of the United States, the Council of Experts for
the Global Cyber Security Center, and on advisory boards for successful companies
such as Akonix, Cloudshield, Finjan, Fixmo, Ingrian Networks, Koolspan, Riverhead,
and TripWire. John is a highly sought public and closed-door speaker and most recently
was awarded the global Golden Bridge Award and CSO 40 Silver Award for the 2014
Chief Security Officer of the Year.

Stewart holds a Master of Science degree in computer and information science from
Syracuse University, Syracuse, New York.

xv

Foreword

Cyberspace has become the 21st century’s greatest engine of change. And it’s every-
where. Virtually every aspect of global civilization now depends on interconnected
cyber systems to operate. A good portion of the money that was spent on offensive and
defensive capabilities during the Cold War is now being spent on cyber offense and
defense. Unlike the Cold War, where only governments were involved, this cyber chal-
lenge requires defensive measures for commercial enterprises, small businesses, NGOs,
and individuals. As we move into the Internet of Things, cybersecurity and the issues
associated with it will affect everyone on the planet in some way, whether it is cyber-
war, cyber-crime, or cyber-fraud.

Although there is much publicity regarding network security, the real cyber Achilles’
heel is insecure software and the architecture that structures it. Millions of software
vulnerabilities create a cyber house of cards in which we conduct our digital lives.
In response, security people build ever more elaborate cyber fortresses to protect this
vulnerable software. Despite their efforts, cyber fortifications consistently fail to pro-
tect our digital treasures. Why? The security industry has failed to engage fully with
the creative, innovative people who write software and secure the systems these solu-
tions are connected to. The challenges to keep an eye on all potential weaknesses are
skyrocketing. Many companies and vendors are trying to stay ahead of the game by
developing methods and products to detect threats and vulnerabilities, as well as highly
efficient approaches to analysis, mitigation, and remediation. A comprehensive approach
has become necessary to counter a growing number of attacks against networks, servers,
and endpoints in every organization.

Threats would not be harmful if there were no vulnerabilities that could be exploited.
The security industry continues to approach this issue in a backwards fashion by trying
to fix the symptoms rather than to address the source of the problem itself. As discussed
in our book Core Software Security: Security at the Source,* the stark reality is that the

* Ransome, J. and Misra, A. (2014). Core Software Security: Security at the Source. Boca Raton
(FL): CRC Press.

xvi Securing Systems

vulnerabilities that we were seeing 15 years or so ago in the OWASP and SANS Top Ten
and CVE Top 20 are almost the same today as they were then; only the pole positions
have changed. We cannot afford to ignore the threat of insecure software any longer
because software has become the infrastructure and lifeblood of the modern world.

Increasingly, the liabilities of ignoring or failing to secure software and provide the
proper privacy controls are coming back to the companies that develop it. This is and
will be in the form of lawsuits, regulatory fines, loss of business, or all of the above.
First and foremost, you must build security into the software development process. It is
clear from the statistics used in industry that there are substantial cost savings to fixing
security flaws early in the development process rather than fixing them after software is
fielded. The cost associated with addressing software problems increases as the lifecycle
of a project matures. For vendors, the cost is magnified by the expense of developing
and patching vulnerable software after release, which is a costly way of securing appli-
cations. The bottom line is that it costs little to avoid potential security defects early in
development, especially compared to costing 10, 20, 50, or even 100 times that amount
much later in development. Of course, this doesn’t include the potential costs of regula-
tory fines, lawsuits, and or loss of business due to security and privacy protection flaws
discovered in your software after release.

Having filled seven Chief Security Officer (CSO) and Chief Information Security
Officer (CISO) roles, and having had both software security and security architecture
reporting to me in many of these positions, it is clear to me that the approach for both
areas needs to be rethought. In my last book, Brook helped delineate our approach to
solving the software security problem while also addressing how to build in security
within new agile development methodologies such as Scrum. In the same book, Brook
noted that the software security problem is bigger than just addressing the code but also
the systems it is connected to.

As long as software and architecture is developed by humans, it requires the human
element to fix it. There have been a lot of bright people coming up with various techni-
cal solutions and models to fix this, but we are still failing to do so as an industry.
We have consistently focused on the wrong things: vulnerability and command and
control. But producing software and designing architecture is a creative and innovative
process. In permaculture, it is said that “the problem is the solution.” Indeed, it is that
very creativity that must be enhanced and empowered in order to generate security as
an attribute of a creative process. A solution to this problem requires the application of
a holistic, cost-effective, and collaborative approach to securing systems. This book is
a perfect follow-on to the message developed in Core Software Security: Security at the
Source* in that it addresses a second critical challenge in developing software: security
architecture methods and the mindset that form a frame for evaluating the security
of digital systems that can be used to prescribe security treatments for those systems.
Specifically, it addresses an applied approach to security architecture and threat models.

* Ibid.

Foreword xvii

It should be noted that systems security, for the most part, is still an art not a science.
A skilled security architect must bring a wealth of knowledge and understanding—
global and local, technical, human, organizational, and even geopolitical—to an assess-
ment. In this sense, Brook is a master of his craft, and that is why I am very excited
about the opportunity to provide a Foreword to this book. He and I have worked
together on a daily basis for over five years and I know of no one better with regard
to his experience, technical aptitude, industry knowledge, ability to think out of the
box, organizational collaboration skills, thoroughness, and holistic approach to systems
architecture—specifically, security as it relates to both software and systems design and
architecture. I highly recommend this book to security architects and all architects who
interact with security or to those that manage them. If you have a reasonable feel for
what the security architect is doing, you will be able to accommodate the results from
the process within your architectures, something that he and I have been able to do
successfully for a number of years now. Brook’s approach to securing systems addresses
the entire enterprise, not only its digital systems, as well as the processes and people
who will interact, design, and build the systems. This book fills a significant gap in the
literature and is appropriate for use as a resource for both aspiring and seasoned security
architects alike.

– Dr. James F. Ransome, CISSP, CISM

About Dr. James F. Ransome:

Dr. James Ransome, CISSP, CISM, is the Senior Director of Product Security at
McAfee—part of Intel Security—and is responsible for all aspects of McAfee’s Product
Security Program, a corporate-wide initiative that supports the delivery of secure soft-
ware products to customers. His career is marked by leadership positions in private and
public industries, having served in three chief information officer (CISO) and four
chief security officer (CSO) roles. Prior to the corporate world, Ransome had 23 years
of government service in various roles supporting the United States intelligence com-
munity, federal law enforcement, and the Department of Defense. He holds a Ph.D.
specializing in Information Security from a NSA/DHS Center of Academic Excellence
in Information Assurance Education program. Ransome is a member of Upsilon Pi
Epsilon, the International Honor Society for Computing and Information Disciplines
and a Ponemon Institute Distinguished Fellow. He recently completed his 10th infor-
mation security book Core Software Security: Security at the Source.*

* Ibid.

xix

Preface

This book replies to a question that I once posed to myself. I know from my conversations
with many of my brother and sister practitioners that, early in your security careers, you have
also posed that very same question. When handed a diagram containing three rectangles and
two double-headed arrows connecting each box to one of the others, each of us has wondered,
“How do I respond to this?”

This is a book about security architecture. The focus of the book is upon how secu-
rity architecture methods and mindset form a frame for evaluating the security of digi-
tal systems in order to prescribe security treatments for those systems. The treatments
are meant to bring the system to a particular and verifiable risk posture.

“System” should be taken to encompass a gamut running from individual com-
puters, to networks of computers, to collections of applications (however that may
be defined) and including complex system integrations of all the above, and more.
“System” is a generic term meant to encompass rather than exclude. Presumably, a
glance through the examples in Part II of this book should indicate the breadth of reach
that has been attempted?

I will endeavor along the way, to provide situationally appropriate definitions for
“security architecture,” “risk,” “architecture risk assessment,” “threat model,” and
“applied.” These definitions should be taken as working definitions, fit only for the pur-
pose of “applied security architecture” and not as proposals for general models in any of
these fields. I have purposely kept a tight rein on scope in the hope that the book retains
enough focus to be useful. In my very humble experience, applied security architecture

xx Securing Systems

will make use of whatever skills—technical, interpersonal, creative, adaptive, and so
forth—that you have or can learn. This one area, applied security architecture, seems
big enough.

Who May Benefi t from This Book?

Any organization that places into service computer systems that have some chance of
being exposed to digital attack will encounter at least some of the problems addressed
within Securing Systems. Digital systems can be quite complex, involving various and
sometimes divergent stakeholders, and they are delivered through the collaboration of
multidisciplinary teams. The range of roles performed by those individuals who will
benefit from familiarity with applied security architecture, therefore, turns out to be
quite broad. The following list comprises nearly everyone who is involved in the specifi-
cation, implementation, delivery, and decision making for and about computer systems.

• Security architects, assessors, analysts, and engineers
• System, solution, infrastructure, and enterprise architects
• Developers, infrastructure engineers, system integrators, and implementation

teams
• Managers, technical leaders, program and project managers, middle management,

and executives

Security architecture is and will remain, for some time, an experience-based prac-
tice. The security architect encounters far too many situations where the “right” answer
will be “it depends.” Those dependencies are, in part, what this book is about.

Certainly, engineering practice will be brought to bear on secure systems. Exploit
techniques tend to be particular. A firm grasp of the engineering aspects of soft-
ware, networks, operating systems, and the like is essential. Applied cryptography is
not really an art. Cryptographic techniques do a thing, a particular thing, exactly.
Cryptography is not magic, though application is subtle and algorithms are often
mathematically and algorithmically complex. Security architecture cannot be per-
formed without a firm grounding in many aspects of computer science. And, at a
grosser granularity, there are consistent patterns whose solutions tend to be amenable
to clear-cut engineering resolution.

Still, in order to recognize the patterns, one must often apply deep and broad
experience. This book aims to seed precisely that kind of experience for practitioners.
Hopefully, alongside the (fictitious but commonly occurring) examples, I will have
explained the reasoning and described the experience behind my analysis and the deci-
sions depicted herein such that even experts may gain new insight from reading these
and considering my approaches. My conclusions aren’t necessarily “right.” (Being a risk-
driven practice, there often is no “right” answer.)

Preface xxi

Beyond security architects, all architects who interact with security can benefit from
this work. If you have a reasonable feel for what the security architect is doing, you will
be able to accommodate the results from the process within your architectures. Over
the years, many partner architects and I have grown so attuned, that we could finish
each other’s sentences, speak for each other’s perspectives, and even include each other’s
likely requirements within our analysis of an architecture. When you have achieved
this level of understanding and collaboration, security is far more easily incorporated
from the very inception of a new idea. Security becomes yet another emerging attribute
of the architecture and design, just like performance or usability. That, in my humble
opinion, is an ideal to strive for.

Developers and, particularly, development and technical leaders will have to translate
the threat model and requirements into things that can be built and coded. That’s not an
easy transformation. I believe that this translation from requirement through to func-
tional test is significantly eased through a clear understanding of the threat model. In
fact, at my current position, I have offered many participatory coaching sessions in the
ATASM process described in this book to entire engineering teams. These sessions have
had a profound effect, causing everyone involved—from architect to quality engineer—
to have a much clearer understanding of why the threat model is key and how to work
with security requirements. I hope that reading this book will provide a similar ground-
ing for delivery teams that …