+1(978)310-4246 credencewriters@gmail.com
  

I’m working on a cyber security question and need guidance to help me learn.

Why do good requirements go bad?  What can be done to prevent things from going bad?

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 storage or retrieval system, without written permission from the publishers.
For permission to photocopy or use material electronically from this work, please access www.copyright.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 provides licenses and registration for a variety of users. For organizations that have been granted a photocopy 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
Dedication
To the many teachers who’ve pointed me down the path; the managers who have supported 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.
v
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
The Lay of Information Security Land
The Structure of the Book
References
Chapter 1: Introduction
1.1 Breach! Fix It!
1.2 Information Security, as Applied to Systems
1.3 Applying Security to Any System
References
Chapter 2: The Art of Security Assessment
2.1
2.2
Why Art and Not Engineering?
Introducing “The Process”
3
3
7
8
9
11
14
21
25
27
28
29
vii
viii Securing Systems
2.3
2.4
Necessary Ingredients
The Threat Landscape
2.4.1 Who Are These Attackers? Why Do They Want
to Attack My System?
2.5 How Much Risk to Tolerate?
2.6 Getting Started
References
Chapter 3: Security Architecture of Systems
3.1
3.2
3.3
3.4
3.5
Why Is Enterprise Architecture Important?
The “Security” in “Architecture”
Diagramming For Security Analysis
Seeing and Applying Patterns
System Architecture Diagrams and Protocol Interchange
Flows (Data Flow Diagrams)
3.5.1 Security Touches All Domains
3.5.2 Component Views
3.6 What’s Important?
3.6.1 What Is “Architecturally Interesting”?
3.7 Understanding the Architecture of a System
3.7.1 Size Really Does Matter
3.8 Applying Principles and Patterns to Specific Designs
3.8.1 Principles, But Not Solely Principles
Summary
References
Chapter 4: Information Security Risk
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Rating with Incomplete Information
Gut Feeling and Mental Arithmetic
Real-World Calculation
Personal Security Posture
Just Because It Might Be Bad, Is It?
The Components of Risk
4.6.1 Threat
4.6.2 Exposure
4.6.3 Vulnerability
4.6.4 Impact
Business Impact
4.7.1 Data Sensitivity Scales
33
35
36
44
51
52
53
54
57
59
70
73
77
78
79
79
81
81
84
96
98
98
101
101
102
105
106
107
108
110
112
117
121
122
125
Contents ix
4.8
Risk Audiences
4.8.1 The Risk Owner
4.8.2 Desired Security Posture
4.9 Summary
References
Chapter 5: Prepare for Assessment
5.1
Process Review
5.1.1 Credible Attack Vectors
5.1.2 Applying ATASM
5.2 Architecture and Artifacts
5.2.1 Understand the Logical and Component Architecture
of the System
5.2.2 Understand Every Communication Flow and Any
Valuable Data Wherever Stored
5.3 Threat Enumeration
5.3.1 List All the Possible Threat Agents for This Type
of System
5.3.2 List the Typical Attack Methods of the Threat Agents
5.3.3 List the System-Level Objectives of Threat Agents
Using Their Attack Methods
5.4 Attack Surfaces
5.4.1 Decompose (factor) the Architecture to a Level That
Exposes Every Possible Attack Surface
5.4.2 Filter Out Threat Agents Who Have No Attack
Surfaces Exposed to Their Typical Methods
5.4.3 List All Existing Security Controls for Each Attack
Surface
5.4.4 Filter Out All Attack Surfaces for Which There Is
Sufficient Existing Protection
5.5 Data Sensitivity
5.6 A Few Additional Thoughts on Risk
5.7 Possible Controls
5.7.1 Apply New Security Controls to the Set of Attack
Services for Which There Isn’t Sufficient Mitigation
5.7.2 Build a Defense-in-Depth
5.8 Summary
References
Part I
Summary
126
127
129
129
130
133
133
134
135
137
138
140
145
146
150
151
153
154
159
160
161
163
164
165
166
168
170
171
173
x
Securing Systems
Part II
Introduction
Practicing with Sample Assessments
Start with Architecture
A Few Comments about Playing Well with Others
Understand the Big Picture and the Context
Getting Back to Basics
References
Chapter 6: eCommerce Website
6.1
6.2
6.3
Decompose the System
6.1.1 The Right Level of Decomposition
Finding Attack Surfaces to Build the Threat Model
Requirements
Chapter 7: Enterprise Architecture
7.1
7.2
7.3
7.4
Enterprise Architecture Pre-work: Digital Diskus
Digital Diskus’ Threat Landscape
Conceptual Security Architecture
Enterprise Security Architecture Imperatives
and Requirements
7.5 Digital Diskus’ Component Architecture
7.6 Enterprise Architecture Requirements
References
Chapter 8: Business Analytics
8.1
8.2
8.3
Architecture
Threats
Attack Surfaces
8.3.1 Attack Surface Enumeration
8.4 Mitigations
8.5 Administrative Controls
8.5.1 Enterprise Identity Systems (Authentication
and Authorization)
8.6 Requirements
References
179
179
180
181
183
185
189
191
191
193
194
209
213
217
218
221
222
227
232
233
235
235
239
242
254
254
260
261
262
266
Contents xi
Chapter 9: Endpoint Anti-malware
9.1 A Deployment Model Lens
9.2 Analysis
9.3 More on Deployment Model
9.4 Endpoint AV Software Security Requirements
References
267
268
269
277
282
283
Chapter 10: Mobile Security Software with Cloud Management
285
10.1 Basic Mobile Security Architecture
10.2 Mobility Often Implies Client/Cloud
10.3 Introducing Clouds
10.3.1 Authentication Is Not a Panacea
10.3.2 The Entire Message Stack Is Important
10.4 Just Good Enough Security
10.5 Additional Security Requirements for a Mobile and
Cloud Architecture
285
286
290
292
294
295
Chapter 11: Cloud Software as a Service (SaaS)
11.1 What’s So Special about Clouds?
11.2 Analysis: Peel the Onion
11.2.1 Freemium Demographics
11.2.2 Protecting Cloud Secrets
11.2.3 The Application Is a Defense
11.2.4 “Globality”
11.3 Additional Requirements for the SaaS Reputation Service
References
298
301
301
302
306
308
309
311
319
320
Part II
Summary
321
Part III
Introduction
327
Chapter 12: Patterns and Governance Deliver Economies of Scale
329
12.1 Expressing Security Requirements
12.1.1 Expressing Security Requirements to Enable
12.1.2 Who Consumes Requirements?
337
338
339
xii
Securing Systems
12.1.3 Getting Security Requirements Implemented
12.1.4 Why Do Good Requirements Go Bad?
12.2 Some Thoughts on Governance
Summary
References
Chapter 13: Building an Assessment Program
13.1 Building a Program
13.1.1 Senior Management’s Job
13.1.2 Bottom Up?
13.1.3 Use Peer Networks
13.2 Building a Team
13.2.1 Training
13.3 Documentation and Artifacts
13.4 Peer Review
13.5 Workload
13.6 Mistakes and Missteps
13.6.1 Not Everyone Should Become an Architect
13.6.2 Standards Can’t Be Applied Rigidly
13.6.3 One Size Does Not Fit All, Redux
13.6.4 Don’t Issue Edicts Unless Certain of Compliance
13.7 Measuring Success
13.7.1 Invitations Are Good!
13.7.2 Establish Baselines
13.8 Summary
References
Part III
Summary and Afterword
Summary
Afterword
Index
344
347
348
351
351
353
356
356
357
359
364
366
369
372
373
374
374
375
376
377
377
378
378
380
382
383
383
385
387
Foreword
As you read this, it is important to note that despite hundreds to thousands of peopleyears 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 software 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 architecture 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 possible 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, engenders 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 systems 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
xiii
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 security 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, underscoring 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.
Foreword
Cyberspace has become the 21st century’s greatest engine of change. And it’s everywhere. 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 challenge 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 cyberwar, 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 protect 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 solutions 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.
xv
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 applications. 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 regulatory 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 technical 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 assessment. 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 software 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 community, 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 information security book Core Software Security: Security at the Source.*
*
Ibid.
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 security architecture methods and mindset form a frame for evaluating the security of digital 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 computers, 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 purpose 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
xix
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 Benefit 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 specification, 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 practice. 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 software, 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 performed 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 decisions 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 riskdriven 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 functional 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 grounding for delivery teams that must include security architecture in their work.
I hope that all of those who must build and then sustain a security architecture practice will find useful tidbits that foster high-functioning technical delivery teams that
must include security people and security architecture—namely, project and program
managers, line managers, middle management, or senior and executive management.
Beyond the chapter specifically devoted to building a program, I’ve also included a considerable explanation of the business and organizational context in which architecture
and risk assessment programs exist. The nontechnical factors must comprise the basis
from which security architecture gets applied. Without the required business acumen
and understanding, security architecture can easily devolve to ivory tower, isolated, and
unrealistic pronouncements. Nobody actually reads those detailed, 250-page architecture documents that are gathering dust on the shelf. My sincere desire is that this body
of work remains demonstratively grounded in real-world situations.
All readers of this book may gain some understanding of how the risk of system
compromise and its impacts can be generated. Although risk remains a touted cornerstone of computer security, it is poorly understood. Even the term, “risk,” is thrown
about with little precision, and with multiple and highly overloaded meanings. Readers
will be provided with a risk definition and some specificity about its use, as well as given
a proven methodology, which itself is based upon an open standard. We can all benefit
from just a tad more precision when discussing this emotionally loaded topic, “risk.”
The approach explained in Chapter 4 underlies the analysis in the six example (though
fictitious) architectures. If you need to rank risks in your job, this book will hopefully
provide some insight and approaches.
xxii
Securing Systems
Background and Origins
I was thrown into the practice of securing systems largely because none of the other
security architects wanted to attend the Architecture Technical Review (ATR) meetings. During those meetings, every IT project would have 10 minutes to explain what
they were intending to accomplish. The goal of the review was to uncover the IT services required for project success. Security was one of those IT services.
Security had no more than 5 minutes of that precious time slot to decide whether
the project needed to be reviewed more thoroughly. That was a hard task! Mistakes and
misses occurred from time to time, but especially as I began to assess the architectures
of the projects.
When I first attended ATR meetings, I felt entirely unqualified to make the engagement decisions; in fact, I felt pretty incompetent to be assessing IT projects, at all. I
had been hired to provide long-term vision and research for future intrusion detection systems and what are now called “security incident event management systems.”
Management then asked me to become “Infosec’s” first application security architect. I
was the newest hire and was just trying to survive a staff reduction. It seemed a precarious time to refuse job duties.
A result that I didn’t expect from attending the ATR meetings was how the wide
exposure would dramatically increase my ability to spot architecture patterns. I saw
hundreds of different architectures in those couple of years. I absorbed IT standards
and learned, importantly, to quickly cull exceptional and unique situations. Later, when
new architects took ATR duty, I was forced to figure out how to explain what I was
doing to them. And interacting with all those projects fostered relationships with teams
across IT development. When inevitable conflicts arose, those relationships helped us
to cooperate across our differences.
Because my ATR role was pivotal to the workload for all the security architects
performing reviews, I became a connecting point for the team. After all, I saw almost
all the projects first. And that connecting role afforded me a view of how each of these
smart, highly skilled individuals approached the problems that they encountered as
they went through their process of securing IT’s systems and infrastructures.
Security architecture was very much a formative practice in those days. Systems
architecture was maturing; enterprise architecture was coalescing into a distinct body
of knowledge and practice. The people performing system architecture weren’t sure that
the title “architect” could be applied to security people. We were held somewhat at arm’s
length, not treated entirely as peers, not really allowed into the architects’ “club,” if you
will? Still, it turns out that it’s really difficult to secure a system if the person trying does
not have architectural skills and does not examine the system holistically, including
having the broader context for which the system is intended. A powerful lesson.
At that time, there were few people with a software design background who also
knew anything about computer security. That circumstance made someone like me
a bit of a rarity. When I got started, I had very little security knowledge, just enough
knowledge to barely get by. But, I had a rich software design background from which
Preface
xxiii
to draw. I could “do” architecture. I just didn’t know much about security beyond having written simple network access control lists and having responded to network attack
logs. (Well, maybe a little more than that?)
Consequently, people like Steve Acheson, who was already a security guru and had,
in those early days, a great feel for design, were willing to forgive me for my inexperience. I suspect that Steve tolerated my naiveté because there simply weren’t that
many people who had enough design background with whom he could kick around
the larger issues encountered in building a rigorous practice of security architecture. At
any rate, my conversations with Steve and, slightly later, Catherine Blackader Nelson,
Laura Lindsey, Gavin Reid, and somewhat later, Michele Guel, comprise the seeds out
of which this book was born. Essentially, perhaps literally, we were trying to define the
very nature of security architecture and to establish a body of craft for architecture risk
assessment and threat models.
A formative enterprise identity research team was instigated by Michele Guel in
early 2001. Along with Michele, Steve Acheson and I, (then) IT architect Steve Wright,
and (now) enterprise architect, Sergei Roussakov, probed and prodded, from diverse
angles, the problems of identity as a security service, as an infrastructure, and as an
enterprise necessity. That experience profoundly affects not only the way that I practice
security architecture but also my understanding of how security fits into an enterprise
architecture. Furthermore, as a team encompassing a fairly wide range of different perspectives and personalities, we proved that diverse individuals can come together to
produce seminal work, and relatively easily, at that. Many of the lessons culled from
that experience are included in this volume.
For not quite 15 years, I have continued to explore, investigate, and refine these
early experiments in security architecture and system assessment in concert with those
named above, as well as many other practitioners. The ideas and approaches set out
herein are this moment’s summation of not only of my experience but also that of many
of the architects with whom I’ve worked and interacted. Still, it’s useful to remember
that a book is merely a point in time, a reflection of what is understood at that moment.
No doubt my ideas will change, as will the practice of security architecture.
My sincere desire is that I’m offering both an approach and a practicum that will
make the art of securing systems a little more accessible. Indeed, ultimately, I’d like
this book to unpack, at least a little bit, the craft of applied security architecture for the
many people who are tasked with providing security oversight and due diligence for
their digital systems.
Brook S.E. Schoenfield
Camp Connell, California, USA, December 2014
Acknowledgments
There are so many people who have contributed to the content of this book—from
early technical mentors on through my current collaborators and those people who were
willing to wade through my tortured drivel as it has come off of the keyboard. I direct
the reader to my blog site, brookschoenfield.com, if you’re curious about my technical
history and the many who’ve contributed mightily to whatever skills I’ve gained. Let it
suffice to say, “Far too many to be named here.” I’ll, therefore, try to name those who
contributed directly to the development of this body of work.
Special thanks are due to Laura Lindsey, who coached my very first security review
and, afterwards, reminded me that, “We’re not the cops, Brook.” Hopefully, I continue
to pass on your wisdom?
Michelle Koblas and John Stewart not only “got” my early ideas but, more importantly, encouraged me, supporting me through the innumerable and inevitable mistakes and missteps. Special thanks are offered to you, John, for always treating me as a
respected partner in the work, and to both of you for offering me your ongoing personal
friendship. Nasrin Rezai, I continue to carry your charge to “teach junior people,” so
that security architecture actually has a future.
A debt of gratitude is owed to every past member of Cisco’s “WebArch” team during
the period when I was involved. Special thanks go to Steve Acheson for his early faith
in me (and friendship).
Everyone who was involved with WebArch let me prove that techniques gleaned
from consensus, facilitation, mediation, and emotional intelligence really do provide
a basis for high-functioning technical teams. We collectively proved it again with the
“PAT” security architecture virtual team, under the astute program management of
Ferris Jabri, of “We’re just going to do it, Brook,” fame. Ferris helped to manifest some
of the formative ideas that eventually became the chapter I wrote (Chapter 9) in Core
Software Security: Security at the Source,* by James Ransome and Anmol Misra, as well.
*
Schoenfield, B. (2014). “Applying the SDL Framework to the Real World” (Ch. 9). In Core
Software Security: Security at the Source, pp. 255–324. Boca Raton (FL): CRC Press.
xxv
xxvi
Securing Systems
A special note is reserved for Ove Hansen who, as an architect on the WebArch team,
challenged my opinions on a regular basis and in the best way. Without that countervail, Ove, that first collaborative team experiment would never have fully succeeded.
The industry continues to need your depth and breadth.
Aaron Sierra, we proved the whole concept yet again at WebEx under the direction
and support of Dr. James Ransome. Then, we got it to work with most of Cisco’s burgeoning SaaS products. A hearty thanks for your willingness to take that journey with
me and, of course, for your friendship.
Vinay Bansal and Michele Guel remain great partners in the shaping of a security
architecture practice. I’m indebted to Vinay and to Ferris for helping me to generate
a first outline for a book on security architecture. This isn’t that book, which remains
unwritten.
Thank you to Alan Paller for opportunities to put my ideas in front of wider audiences, which, of course, has provided an invaluable feedback loop.
Many thanks to the readers of the book as it progressed: Dr. James Ransome, Jack
Jones, Eoin Carroll, Izar Tarandach, and Per-Olof Perrson. Please know that your comments and suggestions have improved this work immeasurably. You also validated that
this has been a worthy pursuit.
Catherine Blackader Nelson and Dr. James Ransome continue to help me refine this
work, always challenging me to think deeper and more thoroughly. I treasure not only
your professional support but also the friendship that each of you offers to me.
Thanks to Dr. Neal Daswani for pointing out that XSS may also be mitigated
through output validation (almost an “oops” on my part).
This book simply would not exist without the tireless logistical support of Theron
Shreve and the copyediting and typesetting skills of Marje Pollack at DerryField
Publishing Services. Thanks also go to John Wyzalek for his confidence that this body
of work could have an audience and a place within the CRC Press catalog. And many
thanks to Webb Mealy for help with graphics and for building the Index.
Finally, but certainly not the least, thanks are owed to my daughter, Allison, who
unfailingly encourages me in whatever creative efforts I pursue. I hope that I return that
spirit of support to you. And to my sweetheart, Cynthia Mealy, you have my heartfelt
gratitude. It is you who must put up with me when I’m in one of my creative binges,
which tend to render me, I’m sure, absolutely impossible to deal with. Frankly, I have
no idea how you manage.
Brook S.E. Schoenfield
Camp Connell, California, USA, October 2014
About the Author
Brook S.E. Schoenfield is a Master Principal Product Security Architect at a global
technology enterprise. He is the senior technical leader for software security across a
division’s broad product portfolio. He has held leadership security architecture positions at high-tech enterprises for many years.
Brook has presented at conferences such as RSA, BSIMM, and SANS What Works
Summits on subjects within security architecture, including SaaS security, information
security risk, architecture risk assessment and threat models, and Agile security. He has
been published by CRC Press, SANS, Cisco, and the IEEE.
Brook lives in the Sierra Mountains of California. When he’s not thinking about,
writing about, and speaking on, as well as practicing, security architecture, he can be
found telemark skiing, hiking, and fly fishing in his beloved mountains, or playing
various genres of guitar—from jazz to percussive fingerstyle.
xxvii
Part I
1
Part I
Introduction
The Lay of Information Security Land
[S]ecurity requirements should be developed at the same time system planners define
the requirements of the system. These requirements can be expressed as technical features
(e.g., access controls), assurances (e.g., background checks for system developers), or
operational practices (e.g., awareness and training).1
How have we come to this pass? What series of events have led to the necessity for pervasive security in systems big and small, on corporate networks, on home networks, and
in cafes and trains in order for computers to safely and securely provide their benefits?
How did we ever come to this? Isn’t “security” something that banks implement? Isn’t
security an attribute of government intelligence agencies? Not anymore.
In a world of pervasive and ubiquitous network interconnection, our very lives are
intertwined with the successful completion of millions of transactions initiated on our
behalf on a rather constant basis. At the risk of stating the obvious, global commerce
has become highly dependent upon the “Internet of Things.”2 Beyond commerce, so
has our ability to solve large, complex problems, such as feeding the hungry, understanding the changes occurring to the ecosystems on our planet, and finding and
exploiting resources while, at the same time, preserving our natural heritage for future
generations. Indeed, war, peace, and regime change are all dependent upon the global
commons that we call “The Public Internet.” Each of these problems, as well as all of us
connected humans, have come to rely upon near-instant connection and seamless data
exchange, just as each of us who use small, general-purpose computation devices—that
is, your “smart phone,”—expect snappy responses to our queries and interchanges. A
significant proportion of the world’s 7 billion humans* have become interconnected.
*
As of this writing, the population of the world is just over 7 billion. About 3 billion of these
people are connected to the Internet.
3
4
Securing Systems
And we expect our data to arrive safely and our systems and software to provide a
modicum of safety. We’d like whatever wealth we may have to be held securely. That’s
not too much to expect, is it?
We require a modicum of security: the same protection that our ancestors expected
from the bank and solicitor. Or rather, going further back, these are the protections that
feudal villages expected from their Lord. Even further back, the village or clan warriors
supposedly provided safety from a dangerous “outside” or “other.”
Like other human experiments in sharing a commons,* the Internet seems to suffer
from the same forces that have plagued common areas throughout history: bandits,
pirates, and other groups taking advantage of the lack of barriers and control.
Early Internet pundits declared that the Internet would prove tremendously
democratizing:
As we approach the twenty-first century, America is turning into an electronic republic,
a democratic system that is vastly increasing the people’s day-to-day influence on the
decisions of state . . . transforming the nature of the political process . . .3
Somehow, I doubt that these pundits quite envisioned the “democracy” of the
modern Internet, where salacious rumors can become worldwide “facts” in hours, where
news about companies’ mistakes and misdeeds cannot be “spun” by corporate press
corps, and where products live or die through open comment and review by consumers.
Governments are not immune to the power of instant interconnectedness. Regimes
have been shaken, even toppled it would seem, by the power of the instant message.
Nation-state nuclear programs have been stymied through “cyber offensives.” Corporate
and national secrets have been stolen. Is nothing on the Internet safe?
Indeed, it is a truism in the Age of the Public Internet (if I may title it so?), “You
can’t believe anything on the Internet.” And yet, Wikipedia has widely replaced the
traditional, commercial encyclopedia as a reference source. Wikipedia articles, which
are written by its millions of participants—“crowd-sourced”—rather than being written by a hand-selected collection of experts, have proven to be quite reliable, if not
always perfectly accurate. “Just Good Enough Reference”? Is this the power of Internet
democracy?
Realizing the power of unfettered interconnection, some governments have gone to
great lengths to control connection and content access. For every censure, clever technicians have devised methods of circumventing those governmental controls. Apparently,
people all over the world prefer to experience the content that they desire and to communicate with whom they please, even in the face of arrest, detention, or other sanction.
Alongside the growth of digital interconnection have grown those wishing to take
advantage of the open structure of our collective, global commons. Individuals seeking
*
A commons is an asset held in common by a community—for example, pasture land that
every person with livestock might use to pasture personal animals. The Public Internet is a
network and a set of protocols held in common for everyone with access to it.
Part I-Introduction 5
advantage of just about every sort, criminal gangs large and small, pseudo-governmental
bodies, cyber armies, nation-states, and activists of every political persuasion have all
used and misused the openness built into the Internet.
Internet attack is pervasive. It can take anywhere from less than a minute to as
much as eight hours for an unprotected machine connected to the Internet to be completely compromised. The speed of attack entirely depends upon at what point in the
address space any of the hundreds of concurrent sweeps happen to be at the moment.
Compromise is certain; the risk of compromise is 100%. There is no doubt. An unprotected machine that is directly reachable (i.e., has a routable and visible address) from
the Internet will be controlled by an attacker given a sufficient exposure period. The
exposure period has been consistently shortening, from weeks, to days, then to hours,
down to minutes, and finally, some percentage of systems have been compromised
within seconds of connection.
In 1998, I was asked to take over the security of the single Internet router at the
small software house for which I worked. Alongside my duties as Senior Designer and
Technical Lead, I was asked, “Would you please keep the Access Control Lists (ACL)
updated?”* Why was I chosen for these duties? I wrote the TCP/IP stack for our realtime operating system. Since supposedly I knew something about computer networking, we thought I could add few minor maintenance duties. I knew very little about
digital security at the time. I learned.
As I began to study the problem, I realized that I didn’t have a view into potential
attacks, so I set up the experimental, early Intrusion Detection System (IDS), Shadow,
and began monitoring traffic. After a few days of monitoring, I had a big shock. We, a
small, relatively unknown (outside our industry) software house with a single Internet
connection, were being actively attacked! Thus began my journey (some might call it
descent?) into cyber security.
Attack and the subsequent “compromise,” that is, complete control of a system on
the Internet, is utterly pervasive: constant and continual. And this has been true for
quite a long time. Many attackers are intelligent and adaptive. If defenses improve,
attackers will change their tactics to meet the new challenge. At the same time, once
complex and technically challenging attack methods are routinely “weaponized,”
turned into point-and-click tools that the relatively technically unsophisticated can
easily use. This development has exponentially expanded the number of attackers. The
result is a broad range of attackers, some highly ingenious alongside the many who can
and will exploit well-known vulnerabilities if left unpatched. It is a plain fact that as of
this writing, we are engaged in a cyber arms race of extraordinary size, composition,
complexity, and velocity.
Who’s on the defending side of this cyber arms race? The emerging and burgeoning
information security industry.
As the attacks and attackers have matured, so have the defenders. It is information
security’s job to do our best to prevent successful compromise of data, communications,
*
Subsequently, the company’s Virtual Private Network (VPN) was added to my security duties.
6
Securing Systems
the misuse of the “Internet of Things.” “Infosec”* does this with technical tools that aid
human analysis. These tools are the popularly familiar firewalls, intrusion detection
systems (IDS), network (and other) ACLs, anti-virus and anti-malware protections,
Security Information and Event Managers (SIEM), the whole panoply of software tools
associated with information security. Alongside these are tools that find issues in software, such as vulnerability scanners and “static” analysis tools. These scanners are used
as software is written.†
Parallel to the growth in security software, there has been an emerging trend to
codify the techniques and craft used by security professionals. These disciplines have
been called “security engineering,” “security analysis,” “security monitoring,” “security
response,” “security forensics,” and most importantly for this work, “security architecture.” It is security architecture with which we are primarily concerned. Security
architecture is the discipline charged with integrating into computer systems the
security features and controls that will provide the protection expected of the system
when it is deployed for use. Security architects typically achieve a sufficient breadth of
knowledge and depth of understanding to apply a gamut of security technologies and
processes to protect systems, system interconnections, and the data in use and storage:
Securing Systems.
In fact, nearly twenty years after the publication of NIST-14 (quoted above), organizations large and small—governmental, commercial, and non-profit—prefer that some
sort of a “security review” be conducted upon proposed and/or preproduction systems.
Indeed, many organizations require a security review of systems. Review of systems to
assess and improve system security posture has become a mandate.
Standards such as the NIST 800-53 and ISO 27002, as well as measures of existing
practice, such as the BSIMM-V, all require or measure the maturity of an organization’s “architecture risk assessment” (ARA). When taken together, it seems clear that
a security review of one sort or another has become a security “best practice.” That is,
organizations that maintain a cyber-security defense posture typically require some sort
of assessment or analysis of the systems to be used by the organization, whether those
systems are homegrown, purchased, or composite. Ergo, these organizations believe it is
in their best interest to have a security expert, typically called the “security architect.”‡
However “security review” often remains locally defined. Ask one practitioner and
she will tell you that her review consists of post-build vulnerability scanning. Another
answer might be, “We perform a comprehensive attack and penetration on systems
before deployment.” But neither of these responses captures the essence and timing
of, “[S]ecurity requirements should be developed at the same time system planners define
*
“Infosec” is a common nickname for an information security department.
Static analyzers are the security equivalent of the compiler and linker that turn software
source code written in programming languages into executable programs.
‡ Though these may be called a “security engineer,” or a “security analyst,” or any number of
similar local variations.
†
Part I-Introduction 7
the requirements of the system.”4 That is, the “review,” the discovery of “requirements”
is supposed to take place proactively, before a system is completely built! And, in my
experience, for many systems, it is best to gather security requirements at various points
during system development, and at increasing levels of specificity, as the architecture
and design are thought through. The security of a system is best considered just as
all the other attributes and qualities of the system are pulled together. It remains an
ongoing mistake to leave security to the end of the development cycle.
By the time a large and complex system is ready for deployment, the possibility of
structural change becomes exponentially smaller. If a vulnerability (hole) is found in
the systems logic or that its security controls are incomplete, there is little likelihood
that the issue can or will be repaired before the system begins its useful life. Too much
effort and resources have already been expended. The owners of the system are typically
stuck with what’s been implemented. They owners will most likely bear the residual
risk, at least until some subsequent development cycle, perhaps for the life of the system.
Beyond the lack of definition among practitioners, there is a dearth of skilled security architects. The United States Department of Labor estimated in 2013 that there
would be zero unemployment of information security professionals for the foreseeable
future. Demand is high. But there are few programs devoted to the art and practice
of assessing systems. Even calculating the risk of any particular successful attack has
proven a difficult problem, as we shall explore. But risk calculation is only one part of
an assessment. A skilled security architect must bring a wealth of knowledge and understanding—global and local, technical, human, organizational, and even geopolitical—
to an assessment. How does a person get from here to there, from engineer to a security
architect who is capable of a skilled security assessment?
Addressing the skill deficit on performing security “reviews,” or more properly, security assessment and analysis, is the object of this work. The analysis must occur while
there is still time to make any required changes. The analyst must have enough information and skill to provide requirements and guidance sufficient to meet the security
goals of the owners of the system. That is the goal of this book and these methods, to
deliver the right security at the right time in the implementation lifecycle. In essence,
this book is about addressing pervasive attacks through securing systems.
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
8
Securing Systems
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.
References
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). “That ‘Internet of Things’ Thing: In the real world things
matter more than ideas.” RFID Journal. Retrieved from http://www.rfidjournal.com/
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).
Chapter 1
Introduction
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.*
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.
*
There are numerous works devoted to organizational “security assessment.” But few describe
in any detail the practice of analyzing a system to determine what, if any, security must be
added to it before it is used.
9
10 Securing Systems
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
Introduction
11
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.1 Breach! Fix It!
Advances in information security have been repeatedly driven by spectacular attacks
and by the evolutionary advances of the attackers. In fact, many organizations don’t
really empower and support their security programs until there’s been an incident. It is
a truism among security practitioners to consider a compromise or breach as an “opportunity.” Suddenly, decision makers are paying attention. The wise practitioner makes
use of this momentary attention to address the weaker areas in the extant program.
For example, for years, the web application security team on which I worked, though
reasonably staffed, endured a climate in which mid-level management “accepted” risks,
that is, vulnerabilities in the software, rather than fix them. In fact, a portfolio of
*
Most notably, the Cisco SAFE eCommerce architecture closely models Cisco’s external web
architecture, to which descendant architects and I contributed.
12
Securing Systems
thousands of applications had been largely untested for vulnerabilities. A vulnerability
scanning pilot revealed that every application tested had issues. The security “debt,”
that is, an unaddressed set of issues, grew to be much greater than the state of the art
could address. The period for detailed assessment grew to be estimated in multiple
years. The application portfolio became a tower of vulnerable cards, an incident waiting
to happen. The security team understood this full well.
This sad state of affairs came through a habit of accepting risk rather than treating
it. The team charged with the security of the portfolio was dispirited and demoralized.
They lost many negotiations about security requirements. It was difficult to achieve
security success against the juggernaut of management unwilling to address the mounting problem.
Then, a major public hack occurred.
The password file for millions of customers was stolen through the front end of a
web site pulling in 90% of a multi-billion dollar revenue stream. The attack was successful through a vector that had been identified years before by the security team. The
risk had been accepted by corporate IT due to operational and legacy demands. IT
didn’t want to upset the management who owned the applications in the environments.
Immediately, that security team received more attention, first negative, then constructive. The improved program that is still running successfully 10 years later was
built out on top of all this senior management attention. So far as I know, that company
has not endured another issue of that magnitude through its web systems. The loss of
the password file turned into a powerful imperative for improvement.
Brad Arkin, CSO for Adobe Systems, has said, “Never waste a crisis.”1 Savvy security folk leverage significant incidents for revolutionary changes. For this reason, it
seems that these sea changes are a direct result, even driven out of, successful attacks.
Basically, security leaders are told, “There’s been a breach. Fix it!” Once into a “fix it”
cycle, a program is much more likely to receive the resource expansions, programmatic
changes, and tool purchases that may be required.
In parallel, security technology makers are continually responding to new attack
methods. Antivirus, anti-malware, next-generation firewall, and similar vendors continually update the “signatures,” the identifying attributes, of malicious software, and usually very rapidly, as close to “real-time” as they are able. However, it is my understanding
that new variations run in the hundreds every single day; there are hundreds of millions
of unique, malicious software samples in existence as of this writing. Volumes of this
magnitude are a maintenance nightmare requiring significant investment in automation
in order to simply to keep track, much less build new defenses. Any system that handles
file movements is going to be handling malicious pieces of software at some point, perhaps constantly exposed to malicious files, depending upon the purpose of the system.
Beyond sheer volume, attackers have become ever more sophisticated. It is not
unusual for an Advanced Persistent Attack (APT) to take months or even years to plan,
build, disseminate, and then to execute. One well-known attack described to the author
involved site visits six months before the actual attack, two diversionary probes in parallel
Introduction
13
to the actual data theft, the actual theft being carried out over a period of days and perhaps involving an attack team staying in a hotel near the physical attack site. Clever
name-resolution schemes such as fast-flux switching allow attackers to efficiently hide
their identities without cost. It’s a dangerous cyber world out there on the Internet today.
The chance of an attempted attack of one kind or another is certain. The probability
of a web attack is 100%; systems are being attacked and will be attacked regularly and
continually. Most of those attacks will be “door rattling,” reconnaissance probes and wellknown, easily defended exploit methods. But out of the fifty million attacks each week
that most major web sites must endure, something like one or two within the mountain
of attack events will likely be highly sophisticated and tightly targeted at that particular
set of systems. And the probability of a targeted attack goes up exponentially when the
web systems employ well-known operating systems and execution environments.
Even though calculating an actual risk in dollars lost per year is fairly difficult, we
do know that Internet system designers can count on being attacked, period. And these
attacks may begin fairly rapidly upon deployment.
There’s an information security saying, “the defender must plug all the holes. The
attacker only needs to exploit a single vulnerability to be successful.” This is an oversimplification, as most successful data thefts employ two or more vulnerabilities strung
together, often across multiple systems or components.
Indeed, system complexity leads to increasing the difficulty of defense and, inversely,
decreasing the difficulty of successful exploitation. The number of flows between systems can turn into what architects call, “spaghetti,” a seeming lack of order and regularity in the design. Every component within the system calls every other component,
perhaps through multiple flows, in a disorderly matrix of calls. I have seen complex
systems from major vendors that do exactly this. In a system composed of only six
components, that gives 62=36 separate flows (or more!). Missing appropriate security
on just one of these flows might allow an attacker a significant possibility to gain a
foothold within the trust boundaries of the entire system. If each component blindly
trusts every other component, let’s say, because the system designers assumed that the
surrounding network would provide enough protection, then that foothold can easily
allow the attacker to own the entire system. And, trusted systems make excellent beach
heads from which to launch attacks at other systems on a complex enterprise network.
Game over. Defenders 0, attacker everything.
Hence, standard upon standard require organizations to meet the challenge through
building security into systems from the very start of the architecture and then on through
design. It is this practice that we will address.
• When should the architect begin the analysis?
• At what points can a security architect add the most value?
• What are the activities the architect must execute?
• How are these activities delivered?
• What is the set of knowledge domains applied to the analysis?
14
Securing Systems
• What are the outputs?
• What are the tips and tricks that make security architecture risk assessment easier?
If a breach or significant compromise and loss creates an opportunity, then that
opportunity quite often is to build a security architecture practice. A major part or focus
of that maturing security architecture practice will be the assessment of systems for the
purpose of assuring that when deployed, the assessed systems contain appropriate security qualities and controls.
• Sensitive data will be protected in storage, transmission, and processing.
• Sensitive access will be controlled (need-to-know, authentication, and
authorization).
• Defenses will be appropriately redundant and layered to account for failure.
• There will be no single point of failure in the controls.
• Systems are maintained in such a way that they remain available for use.
• Activity will be monitored for attack patterns and failures.
1.2 Information Security, as Applied to Systems
One definition of security architecture might be, “applied information security.” Or
perhaps, more to the point of this work, security architecture applies the principles of
security to system architectures. It should be noted that there are (at least) two uses of
the term, “security architecture.” One of these is, as defined above, to ensure that the
correct security features, controls, and properties are included into an organization’s
digital systems and to help implement these through the practice of system architecture.
The other branch, or common usage, of “security architecture” is the architecture of
the security systems of an organization. In the absence of the order provided through
architecture, organizations tend to implement various security technologies “helterskelter,” that is, ad hoc. Without security architecture, the intrusion system (IDS) might
be distinct and independent from the firewalls (perimeter). Firewalls and IDS would
then be unconnected and independent from anti-virus and anti-malware on the endpoint systems and entirely independent of server protections. The security architect first
uncovers the intentions and security needs of the organization: open and trusting or
tightly controlled, the data sensitivities, and so forth. Then, the desired security posture
(as it’s called) is applied through a collection of coordinated security technologies. This
can be accomplished very intentionally when the architect has sufficient time to strategize before architecting, then to architect to feed a design, and to have a sound design
to support implementation and deployment.*
*
Of course, most security architects inherit an existing set of technologies. If these have grown
up piecemeal over a significant period of time, there will be considerable legacy that hasn’t
been architected with which to contend. This is the far more common case.
Introduction
15
[I]nformation security solutions are often designed, acquired and installed on a tactical
basis. . . . [T]here is no strategy that can be identifiably said to support the goals of
the business. An approach that avoids these piecemeal problems is the development
of an enterprise security architecture which is business-driven and which describes a
structured inter-relationship between the technical and procedural solutions to support
the long-term needs of the business.2
Going a step further, the security architect who is primarily concerned with deploying security technologies will look for synergies between technologies such that the sum
of the controls is greater than any single control or technology. And, there are products
whose purpose is to enhance synergies. The purpose of the security information and
event management (SIEM) products is precisely this kind of synergy between the event
and alert flows of disparate security products. Depending upon needs, this is exactly the
sort of synergistic view of security activity that a security architect will try to enhance
through a security architecture (this second branch of the practice). The basic question
the security architect implementing security systems asks is, “How can I achieve the
security posture desired by the organization through a security infrastructure, given
time, money, and technology restraints.”
Contrast the foregoing with the security architect whose task it is to build security
into systems whose function has nothing to do with information security. The security
architecture of any system depends upon and consumes whatever security systems have
been put into place by the organization. Oftentimes, the security architecture of nonsecurity systems assumes the capabilities of those security systems that have been put into
place. The systems that implement security systems are among the tools that the system
security architect will employ, the “palette” from which she or he draws, as systems are
analyzed and security requirements are uncovered through the analysis. You may think
of the security architect concerned with security systems, the designer of security systems,
as responsible for the coherence of the security infrastructure. The architect concerned
with non-security systems will be utilizing the security infrastructure in order to add
security into or underneath the other systems that will get deployed by the organization.
In smaller organizations, there may be no actual distinction between these two roles:
the security architect will design security systems and will analyze the organization’s
other systems in light of the security infrastructure. The two, systems and security systems, are intimately linked and, typically, tightly coupled. Indeed, as stated previously,
at least a portion of the security infrastructure will usually provide security services
such as authentication and event monitoring for the other systems. And, firewalls and
the like will provide protections that surround the non-security systems.
Ultimately, the available security infrastructure gives rise to an organization’s technical standards. Although an organization might attempt to create standards and then
build an infrastructure to those standards, the dictates of resources, technology, skill,
and other constraints will limit “ivory tower” standards; very probably, the ensuing
infrastructure will diverge significantly from standards that presume a perfect world
and unlimited resources.
16
Securing Systems
When standards do not match what can actually be achieved, the standards become
empty ideals. In such a case, engineers’ confidence will be shaken; system project teams
are quite likely to ignore standards, or make up their own. Security personnel will lose
considerable influence. Therefore, as we shall see, it’s important that standards match
capabilities closely, even when the capabilities are limited. In this way, all participants
in the system security process will have more confidence in analysis and requirements.
Delivering ivory tower, unrealistic requirements is a serious error that must be avoided.
Decision makers need to understand precisely what protections can be put into place
and have a good understanding of any residual, unprotected risks that remain.
From the foregoing, it should be obvious that the two concentrations within security
architecture work closely together when these are not the same person. When the roles
are separate disciplines, the architect concerned with the infrastructure must understand what other systems will require, the desired security posture, perimeter protections, and security services. The architect who assesses the non-security systems must
have a very deep and thorough understanding of the security infrastructure such that
these services can be applied appropriately. I don’t want to over specify. If an infrastructure provides strong perimeter controls (firewalls), there is no need to duplicate those
controls locally. However, the firewalls may have to be updated for new system boundaries and inter-trust zone communications.
In other words, these two branches of security architecture work very closely together
and may even be fulfilled by the same individual.
No matter how the roles are divided or consolidated, the art of security analysis of a
system architecture is the art of applying the principles of information security to that
system architecture. A set of background knowledge domains is applied to an architecture for the purpose of discovery. The idea is to uncover points of likely attack: “attack
surfaces.” The attack surfaces are analyzed with respect to active threats that have the
capabilities to exercise the attack surfaces. Further, these threats must have access in
order to apply their capabilities to the attack surfaces. And the attack surfaces must
present a weakness that can be exploited by the attacker, which is known as a “vulnerability.” This weakness will have some kind of impact, either to the organization or to
the system. The impact may be anywhere from high to low.
We will delve into each of these components later in the book. When all the requisite
components of an attack come together, a “credible attack vector” has been discovered.
It is possible in the architecture that there are security controls that protect against the
exercise of a credible attack vector. The combination of attack vector and mitigation
indicates the risk of exploitation of the attack vector. Each attack vector is paired to
existing (or proposed) security controls. If the risk is low enough after application of the
mitigation, then that credible attack vector will receive a low risk. Those attack vectors
with a significant impact are then prioritized.
The enumeration of the credible attack vectors, their impacts, and their mitigations
can be said to be a “threat model,” which is simply the set of credible attack vectors and
their prioritized risk rating.
Introduction
17
Since there is no such thing as perfect security, nor are there typically unlimited
resources for security, the risk rating of credible attack vectors allows the security architect to focus on meaningful and significant risks.
Securing systems is the art and craft of applying information security principles,
design imperatives, and available controls in order to achieve a particular security
posture. The analyst must have a firm grasp of basic computer security objectives for
confidentiality, integrity, and availability, commonly referred to as “CIA.” Computer
security has been described in terms of CIA. These are the attributes that will result
from appropriate security “controls.” “Controls” are those functions that help to provide
some assurance that data will only be seen or handled by those allowed access, that data
will remain or arrive intact as saved or sent, and that a particular system will continue
to deliver its functionality. Some examples of security controls would be authentication,
authorization, and network restrictions. A system-monitoring function may provide
some security functionality, allowing the monitoring staff to react to apparent attacks.
Even validation of user inputs into a program may be one of the key controls in a system, preventing misuse of data handling procedures for the attacker’s purposes.
The first necessity for secure software is specifications that define secure behavior
exhibiting the security properties required. The specifications must define functionality
and be free of vulnerabilities that can be exploited by intruders. The second necessity
for secure software is correct implementation meeting specifications. Software is correct
if it exhibits only the behavior defined by its specification – not, as today is often the
case, exploitable behavior not specified, or even known to its developers and testers.3
The process that we are describing is the first “necessity” quoted above, from the
work of Redwine and Davis* (2004)3: “specifications that define secure behavior exhibiting the security properties required.” Architecture risk assessment (ARA) and threat
modeling is intended to deliver these specifications such that the system architecture
and design includes properties that describe the system’s security. We will explore the
architectural component of this in Chapter 3.
The assurance that the implementation is correct—that the security properties have
been built as specified and actually protect the system and that vulnerabilities have
not been introduced—is a function of many factors. That is, this is the second “necessity” given above by Redwine and David (2004).3 These factors must be embedded
into processes, into behaviors of the system implementers, and for which the system
is tested. Indeed, a fair description of my current thinking on a secure development
lifecycle (SDL) can be found in Core Software Security: Security at the Source, Chapter 9
(of which I’m the contributing author), and is greatly expanded within the entire book,
written by Dr. James Ransome and Anmol Misra.4 Architecture analysis for security fits
within a mature SDL. Security assessment will be far less effective standing alone, with*
With whom I’ve had the privilege to work.
18
Securing Systems
out all the other activities of a mature and holistic SDL or secure project development
lifecycle. However, a broad discussion of the practices that lead to assurance of implementation is not within the scope of this work. Together, we will limit our exploration
to ARA and threat modeling, solely, rather than attempting cover an entire SDL.
A suite of controls implemented for a system becomes that system’s defense. If well
designed, these become a “defense-in-depth,” a set of overlapping and somewhat redundant controls. Because, of course, things fail. One security “principle” is that no single
control can be counted upon to be inviolable. Everything may fail. Single points of
failure are potentially vulnerable.
I drafted the following security principles for the enterprise architecture practice of
Cisco Systems, Inc. We architected our systems to these guidelines.
1. Risk Management: We strive to manage our risk to acceptable business levels.
2. Defense-in-Depth: No one solution alone will provide sufficient risk mitigation.
Always assume that every security control will fail.
3. No Safe Environment: We do not assume that the internal network or that any
environment is “secure” or “safe.” Wherever risk is too great, security must be
addressed.
4. CIA: Security controls work to provide some acceptable amount of Confidentiality, Integrity, and/or Availability of data (CIA).
5. Ease Security Burden: Security controls should be designed so that doing the
secure thing is the path of least resistance. Make it easy to be secure, make it easy
to do the right thing.
6. Industry Standard: Whenever possible, follow industry standard security
practices.
7. Secure the Infrastructure: Provide security controls for developers not by them.
As much as possible, put security controls into the infrastructure. Developers
should develop business logic, not security, wherever possible.
The foregoing principles were used* as intentions and directions for architecting
and design. As we examined systems falling within Cisco’s IT development process, we
applied specific security requirements in order to achieve the goals outlined through
these principles. Requirements were not only technical; gaps in technology might
be filled through processes, and staffing might be required in order to carry out the
processes and build the needed technology. We drove toward our security principles
through the application of “people, process, and technology.” It is difficult to architect
without knowing what goals, even ideals, one is attempting to achieve. Principles help
*
These principles are still in use by Enterprise Architecture at Cisco Systems, Inc., though they
have gone through several revisions. National Cyber Security Award winner Michele Guel
and Security Architect Steve Acheson are coauthors of these principles.
Introduction
19
to consider goals as one analyzes a system for its security: The principles are the properties that the security is supposed to deliver.
These principles (or any similar very high level guidance) may seem like they are
too general to help? But experience taught me that once we had these principles firmly
communicated and agreed upon by most, if not all, of the architecture community,
discussions about security requirements were much more fruitful. The other architects had a firmer grasp on precisely why security architects had placed particular
requirements on a system. And, the principles helped security architects remember to
analyze more holistically, more thoroughly, for all the intentions encapsulated within
the principles.
ARAs are a security, “rubber meets the road” activity. The following is a generic statement about what the practice of information security is about, a definition, if you will.
Information assurance is achieved when information and information systems are
protected against attacks through the application of security services such as availability,
integrity, authentication, confidentiality, and nonrepudiation. The application of these
services should be based on the protect, detect, and react paradigm. This means that in
addition to incorporating protection mechanisms, organizations need to expect attacks
and include attack detection tools and procedures that allow them to react to and
recover from these unexpected attacks.5
This book is not a primer in information security. It is assumed that the reader
has at least a glancing familiarity with CIA and the paradigm, “protect, detect, react,”
as described in the quote above. If not, then perhaps it might be of some use to take
a look at an introduction to computer security before proceeding? It is precisely this
paradigm whereby:
• Security controls are in-built to protect a system.
• Monitoring systems are created to detect attacks.
• Teams are empowered to react to attacks.
The Open Web Application Security Project (OWASP) provides a distillation of
several of the most well known sets of computer security principles:
Apply defense-in-depth (complete mediation).
Use a positive security model (fail-safe defaults, minimize attack surface).
ο Fail securely.
ο Run with least privilege.
ο Avoid security by obscurity (open design).
ο Keep security simple (verifiable, economy of mechanism).
ο Detect intrusions (compromise recording).
ο Don’t trust infrastructure.
ο
ο
20 Securing Systems
ο
ο
Don’t trust services.
Establish secure defaults6
Some of these principles imply a set of controls (e.g., access controls and privilege
sets). Many of these controls, such as “Avoid security by obscurity” and “Keep security simple,” are guides to be applied during design, approaches rather than specific
demands to be applied to a system. When assessing a system, the assessor examines for
attack surfaces, then applies specific controls (technologies, processes, etc.) to realize
these principles.
These principles (and those like the ones quoted) are the tools of computer security
architecture. Principles comprise the palette of techniques that will be applied to systems in order to achieve the desired security posture. The prescribed requirements fill
in the three steps enumerated above:
• Protect a system through purpose-built security controls.
• Attempt to detect attacks with security-specific monitors.
• React to any attacks that are detected.
In other words, securing systems is the application of the processes, technologies,
and people that “protect, detect, and react” to systems. Securing systems is essentially
applied information security. Combining computer security with information security
risk comprises the core of the work.
The output of this “application of security to a system” is typically security “requirements.” There may also be “nice-to-have” guidance statements that may or may not
be implemented. However, there is a strong reason to use the word “requirement.”
Failure to implement appropriate security measures may very well put the survival of
the organization at risk.
Typically, security professionals are assigned a “due diligence” responsibility to
prevent disastrous events. There’s a “buck stops here” part of the practice: Untreated
risk must never be ignored. That doesn’t mean that security’s solution will be adopted.
What it does mean is that the security architect must either mitigate information
security risks to an acceptable, known level or make the appropriate decision maker
aware that there is residual risk that either cannot be mitigated or has not been mitigated sufficiently.
Just as a responsible doctor must follow a protocol that examines the whole health
of the patient, rather than only treating the presenting problem, so too must the security architect thoroughly examine the “patient,” any system under analysis, for “vital
signs”—that is, security health.
The requirements output from the analysis are the collection of additions to the system that will keep the system healthy as it endures whatever level of attack is predicted
for its deployment and use. Requirements must be implemented or there is residual risk.
Residual risk must be recognized because of due diligence responsibility. Hence, if the
Introduction
21
analysis uncovers untreated risk, the output of that analysis is the necessity to bring the
security posture up and risk down to acceptable levels. Thus, risk practice and architecture analysis must go hand-in-hand.
So, hopefully, it is clear that a system is risk analyzed in order to determine how
to apply security to the system appropriately. We then can define Architecture Risk
Analysis (ARA) as the process of uncovering system security risks and applying information security techniques to the system to mitigate the risks that have been discovered.
1.3 Applying Security to Any System
This book describes a process whereby a security architect analyzes a system for its
security needs, a process that is designed to uncover the security needs for the system.
Some of those security needs will be provided by an existing security infrastructure.
Some of the features that have been specified through the analysis will be services
consumed from the security infrastructure. And there may be features that need to be
built solely for the system at hand. There may be controls that are specific to the system
that has been analyzed. These will have to be built into the system itself or added to
the security architecture, depending upon whether these features, controls, or services
will be used only by this system, or whether future systems will also make use of these.
A typical progression of security maturity is to start by building one-off security
features into systems during system implementation. During the early periods, there
may be only one critical system that has any security requirements! It will be easier
and cheaper to simply build the required security services as a part of the system as it’s
being implemented. As time goes on, perhaps as business expands into new territories
or d…
Purchase answer to see full
attachment

  
error: Content is protected !!