Applied Security Architecture and Threat Models
Applied Security Architecture and Threat Models
Brook S.E. Schoenfield Forewords by John N. Stewart and James F. Ransome
CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742
© 2015 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business
No claim to original U.S. Government works Version Date: 20150417
International Standard Book Number-13: 978-1-4822-3398-8 (eBook – PDF)
This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint.
Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information stor- age or retrieval system, without written permission from the publishers.
For permission to photocopy or use material electronically from this work, please access www.copy- right.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that pro- vides licenses and registration for a variety of users. For organizations that have been granted a photo- copy license by the CCC, a separate system of payment has been arranged.
Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe.
Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com
and the CRC Press Web site at http://www.crcpress.com
To the many teachers who’ve pointed me down the path; the managers who have sup- ported my explorations; the many architects and delivery teams who’ve helped to refine the work; to my first design mentors—John Caron, Roddy Erickson, and Dr. Andrew Kerne—without whom I would still have no clue; and, lastly, to Hans Kolbe, who once upon a time was our human fuzzer.
Each of you deserves credit for whatever value may lie herein. The errors are all mine.
Foreword by John N. Stewart xiii
Foreword by Dr. James F. Ransome xv
About the Author xxvii
Part I Introduction 3
The Lay of Information Security Land 3 The Structure of the Book 7 References 8
Chapter 1: Introduction 9
1.1 Breach! Fix It! 11 1.2 Information Security, as Applied to Systems 14 1.3 Applying Security to Any System 21 References 25
Chapter 2: The Art of Security Assessment 27
2.1 Why Art and Not Engineering? 28 2.2 Introducing “The Process” 29
viii Securing Systems
2.3 Necessary Ingredients 33 2.4 The Threat Landscape 35
2.4.1 Who Are These Attackers? Why Do They Want to Attack My System? 36
2.5 How Much Risk to Tolerate? 44 2.6 Getting Started 51 References 52
Chapter 3: Security Architecture of Systems 53
3.1 Why Is Enterprise Architecture Important? 54 3.2 The “Security” in “Architecture” 57 3.3 Diagramming For Security Analysis 59 3.4 Seeing and Applying Patterns 70 3.5 System Architecture Diagrams and Protocol Interchange
Flows (Data Flow Diagrams) 73 3.5.1 Security Touches All Domains 77 3.5.2 Component Views 78
3.6 What’s Important? 79 3.6.1 What Is “Architecturally Interesting”? 79
3.7 Understanding the Architecture of a System 81 3.7.1 Size Really Does Matter 81
3.8 Applying Principles and Patterns to Specific Designs 84 3.8.1 Principles, But Not Solely Principles 96
Summary 98 References 98
Chapter 4: Information Security Risk 101
4.1 Rating with Incomplete Information 101 4.2 Gut Feeling and Mental Arithmetic 102 4.3 Real-World Calculation 105 4.4 Personal Security Posture 106 4.5 Just Because It Might Be Bad, Is It? 107 4.6 The Components of Risk 108
4.6.1 Threat 110 4.6.2 Exposure 112 4.6.3 Vulnerability 117 4.6.4 Impact 121
4.7 Business Impact 122 4.7.1 Data Sensitivity Scales 125
4.8 Risk Audiences 126 4.8.1 The Risk Owner 127 4.8.2 Desired Security Posture 129
4.9 Summary 129 References 130
Chapter 5: Prepare for Assessment 133
5.1 Process Review 133 5.1.1 Credible Attack Vectors 134 5.1.2 Applying ATASM 135
5.2 Architecture and Artifacts 137 5.2.1 Understand the Logical and Component Architecture
of the System 138 5.2.2 Understand Every Communication Flow and Any
Valuable Data Wherever Stored 140 5.3 Threat Enumeration 145
5.3.1 List All the Possible Threat Agents for This Type of System 146
5.3.2 List the Typical Attack Methods of the Threat Agents 150 5.3.3 List the System-Level Objectives of Threat Agents
Using Their Attack Methods 151 5.4 Attack Surfaces 153
5.4.1 Decompose (factor) the Architecture to a Level That Exposes Every Possible Attack Surface 154
5.4.2 Filter Out Threat Agents Who Have No Attack Surfaces Exposed to Their Typical Methods 159
5.4.3 List All Existing Security Controls for Each Attack Surface 160
5.4.4 Filter Out All Attack Surfaces for Which There Is Sufficient Existing Protection 161
5.5 Data Sensitivity 163 5.6 A Few Additional Thoughts on Risk 164 5.7 Possible Controls 165
5.7.1 Apply New Security Controls to the Set of Attack Services for Which There Isn’t Sufficient Mitigation 166
5.7.2 Build a Defense-in-Depth 168 5.8 Summary 170 References 171
Part I Summary 173
x Securing Systems
Part II Introduction 179
Practicing with Sample Assessments 179 Start with Architecture 180
A Few Comments about Playing Well with Others 181 Understand the Big Picture and the Context 183
Getting Back to Basics 185 References 189
Chapter 6: eCommerce Website 191
6.1 Decompose the System 191 6.1.1 The Right Level of Decomposition 193
6.2 Finding Attack Surfaces to Build the Threat Model 194 6.3 Requirements 209
Chapter 7: Enterprise Architecture 213
7.1 Enterprise Architecture Pre-work: Digital Diskus 217 7.2 Digital Diskus’ Threat Landscape 218 7.3 Conceptual Security Architecture 221 7.4 Enterprise Security Architecture Imperatives
and Requirements 222 7.5 Digital Diskus’ Component Architecture 227 7.6 Enterprise Architecture Requirements 232 References 233
Chapter 8: Business Analytics 235
8.1 Architecture 235 8.2 Threats 239 8.3 Attack Surfaces 242
8.3.1 Attack Surface Enumeration 254 8.4 Mitigations 254 8.5 Administrative Controls 260
8.5.1 Enterprise Identity Systems (Authentication and Authorization) 261
8.6 Requirements 262 References 266
Chapter 9: Endpoint Anti-malware 267
9.1 A Deployment Model Lens 268 9.2 Analysis 269 9.3 More on Deployment Model 277 9.4 Endpoint AV Software Security Requirements 282 References 283
Chapter 10: Mobile Security Software with Cloud Management 285
10.1 Basic Mobile Security Architecture 285 10.2 Mobility Often Implies Client/Cloud 286 10.3 Introducing Clouds 290
10.3.1 Authentication Is Not a Panacea 292 10.3.2 The Entire Message Stack Is Important 294
10.4 Just Good Enough Security 295 10.5 Additional Security Requirements for a Mobile and
Cloud Architecture 298
Chapter 11: Cloud Software as a Service (SaaS) 301
11.1 What’s So Special about Clouds? 301 11.2 Analysis: Peel the Onion 302
11.2.1 Freemium Demographics 306 11.2.2 Protecting Cloud Secrets 308 11.2.3 The Application Is a Defense 309 11.2.4 “Globality” 311
11.3 Additional Requirements for the SaaS Reputation Service 319
Part II Summary 321
Part III Introduction 327
Chapter 12: Patterns and Governance Deliver Economies of Scale 329
12.1 Expressing Security Requirements 337 12.1.1 Expressing Security Requirements to Enable 338 12.1.2 Who Consumes Requirements? 339
xii Securing Systems
12.1.3 Getting Security Requirements Implemented 344 12.1.4 Why Do Good Requirements Go Bad? 347
12.2 Some Thoughts on Governance 348 Summary 351 References 351
Chapter 13: Building an Assessment Program 353
13.1 Building a Program 356 13.1.1 Senior Management’s Job 356 13.1.2 Bottom Up? 357 13.1.3 Use Peer Networks 359
13.2 Building a Team 364 13.2.1 Training 366
13.3 Documentation and Artifacts 369 13.4 Peer Review 372 13.5 Workload 373 13.6 Mistakes and Missteps 374
13.6.1 Not Everyone Should Become an Architect 374 13.6.2 Standards Can’t Be Applied Rigidly 375 13.6.3 One Size Does Not Fit All, Redux 376 13.6.4 Don’t Issue Edicts Unless Certain of Compliance 377
13.7 Measuring Success 377 13.7.1 Invitations Are Good! 378 13.7.2 Establish Baselines 378
13.8 Summary 380 References 382
Part III Summary and Afterword 383
Summary 383 Afterword 385
As you read this, it is important to note that despite hundreds to thousands of people- years spent to date, we are still struggling mightily to take the complex, de-compose into the simple, and create the elegant when it comes to information systems. Our world is hurtling towards an always on, pervasive, interconnected mode in which soft- ware and life quality are co-dependent, productivity enhancements each year require systems, devices and systems grow to 50 billion connected, and the quantifiable and definable risks all of this creates are difficult to gauge, yet intuitively unsettling, and are slowly emerging before our eyes.
“Arkhitekton”—a Greek word preceding what we speak to as architecture today, is an underserved idea for information systems, and not unsurprisingly, security architec- ture is even further underserved. The very notion that through process and product, systems filling entire data centers, information by the pedabyte, transaction volumes at sub-millisecond speed, and compute systems doubling capability every few years, is likely seen as impossible—even if needed. I imagine the Golden Gate bridge seemed impossible at one point, a space station also, and buildings such as the Burj Khalifa, and yet here we are admiring each as a wonder unto themselves. None of this would be pos- sible without formal learning, training architects in methods that work, updating our training as we learn, and continuing to require a demonstration for proficiency. Each element plays that key role.
The same is true for the current, and future, safety in information systems. Architecture may well be the savior that normalizes our current inconsistencies, engen- ders a provable model that demonstrates efficacy that is quantifiably improved, and tames the temperamental beast known as risk. It is a sobering thought that when sys- tems are connected for the first time, they are better understood than at any other time. From that moment on, changes made—documented and undocumented—alter our understanding, and without understanding comes risk. Information systems must be understood for both operational and risk-based reasons, which means tight definitions must be at the core—and that is what architecture is all about.
For security teams, both design and protect, it is our time to build the tallest, and safest, “building.” Effective standards, structural definition, deep understanding with
xiv Securing Systems
validation, a job classification that has formal methods training, and every improving and learning system that takes knowledge from today to strengthen systems installed yesterday, assessments and inspection that look for weaknesses (which happen over time), all surrounded by a well-built security program that encourages if not demands security architecture, is the only path to success. If breaches, so oftentimes seen as avoidable ex post facto, don’t convince you of this, then the risks should.
We are struggling as a security industry now, and the need to be successful is higher than it has ever been in my twenty-five years in it. It is not good enough just to build something and try and secure it, it must be architected from the bottom up with secu- rity in it, by professionally trained and skilled security architects, checked and validated by regular assessments for weakness, and through a learning system that learns from today to inform tomorrow. We must succeed.
– John N. Stewart SVP, Chief Security & Trust Officer
Cisco Systems, Inc.
About John N. Stewart:
John N. Stewart formed and leads Cisco’s Security and Trust Organization, underscor- ing Cisco’s commitment to address two key issues in boardrooms and on the minds of top leaders around the globe. Under John’s leadership, the team’s core missions are to protect Cisco’s public and private customers, enable and ensure the Cisco Secure Development Lifecycle and Trustworthy Systems efforts across Cisco’s entire mature and emerging solution portfolio, and to protect Cisco itself from the never-ending, and always evolving, cyber threats.
Throughout his 25-year career, Stewart has led or participated in security initiatives ranging from elementary school IT design to national security programs. In addition to his role at Cisco, he sits on technical advisory boards for Area 1 Security, BlackStratus, Inc., RedSeal Networks, and Nok Nok Labs. He is a member of the Board of Directors for Shape Security, Shadow Networks, Inc., and the National Cyber-Forensics Training Alliance (NCFTA). Additionally, Stewart serves on the Cybersecurity Think Tank at University of Maryland University College, and on the Cyber Security Review to Prime Minister & Cabinet for Australia. Prior, Stewart served on the CSIS Commission on Cybersecurity for the 44th Presidency of the United States, the Council of Experts for the Global Cyber Security Center, and on advisory boards for successful companies such as Akonix, Cloudshield, Finjan, Fixmo, Ingrian Networks, Koolspan, Riverhead, and TripWire. John is a highly sought public and closed-door speaker and most recently was awarded the global Golden Bridge Award and CSO 40 Silver Award for the 2014 Chief Security Officer of the Year.
Stewart holds a Master of Science degree in computer and information science from Syracuse University, Syracuse, New York.
Cyberspace has become the 21st century’s greatest engine of change. And it’s every- where. Virtually every aspect of global civilization now depends on interconnected cyber systems to operate. A good portion of the money that was spent on offensive and defensive capabilities during the Cold War is now being spent on cyber offense and defense. Unlike the Cold War, where only governments were involved, this cyber chal- lenge requires defensive measures for commercial enterprises, small businesses, NGOs, and individuals. As we move into the Internet of Things, cybersecurity and the issues associated with it will affect everyone on the planet in some way, whether it is cyber- war, cyber-crime, or cyber-fraud.
Although there is much publicity regarding network security, the real cyber Achilles’ heel is insecure software and the architecture that structures it. Millions of software vulnerabilities create a cyber house of cards in which we conduct our digital lives. In response, security people build ever more elaborate cyber fortresses to protect this vulnerable software. Despite their efforts, cyber fortifications consistently fail to pro- tect our digital treasures. Why? The security industry has failed to engage fully with the creative, innovative people who write software and secure the systems these solu- tions are connected to. The challenges to keep an eye on all potential weaknesses are skyrocketing. Many companies and vendors are trying to stay ahead of the game by developing methods and products to detect threats and vulnerabilities, as well as highly efficient approaches to analysis, mitigation, and remediation. A comprehensive approach has become necessary to counter a growing number of attacks against networks, servers, and endpoints in every organization.
Threats would not be harmful if there were no vulnerabilities that could be exploited. The security industry continues to approach this issue in a backwards fashion by trying to fix the symptoms rather than to address the source of the problem itself. As discussed in our book Core Software Security: Security at the Source,* the stark reality is that the
* Ransome, J. and Misra, A. (2014). Core Software Security: Security at the Source. Boca Raton (FL): CRC Press.
xvi Securing Systems
vulnerabilities that we were seeing 15 years or so ago in the OWASP and SANS Top Ten and CVE Top 20 are almost the same today as they were then; only the pole positions have changed. We cannot afford to ignore the threat of insecure software any longer because software has become the infrastructure and lifeblood of the modern world.
Increasingly, the liabilities of ignoring or failing to secure software and provide the proper privacy controls are coming back to the companies that develop it. This is and will be in the form of lawsuits, regulatory fines, loss of business, or all of the above. First and foremost, you must build security into the software development process. It is clear from the statistics used in industry that there are substantial cost savings to fixing security flaws early in the development process rather than fixing them after software is fielded. The cost associated with addressing software problems increases as the lifecycle of a project matures. For vendors, the cost is magnified by the expense of developing and patching vulnerable software after release, which is a costly way of securing appli- cations. The bottom line is that it costs little to avoid potential security defects early in development, especially compared to costing 10, 20, 50, or even 100 times that amount much later in development. Of course, this doesn’t include the potential costs of regula- tory fines, lawsuits, and or loss of business due to security and privacy protection flaws discovered in your software after release.
Having filled seven Chief Security Officer (CSO) and Chief Information Security Officer (CISO) roles, and having had both software security and security architecture reporting to me in many of these positions, it is clear to me that the approach for both areas needs to be rethought. In my last book, Brook helped delineate our approach to solving the software security problem while also addressing how to build in security within new agile development methodologies such as Scrum. In the same book, Brook noted that the software security problem is bigger than just addressing the code but also the systems it is connected to.
As long as software and architecture is developed by humans, it requires the human element to fix it. There have been a lot of bright people coming up with various techni- cal solutions and models to fix this, but we are still failing to do so as an industry. We have consistently focused on the wrong things: vulnerability and command and control. But producing software and designing architecture is a creative and innovative process. In permaculture, it is said that “the problem is the solution.” Indeed, it is that very creativity that must be enhanced and empowered in order to generate security as an attribute of a creative process. A solution to this problem requires the application of a holistic, cost-effective, and collaborative approach to securing systems. This book is a perfect follow-on to the message developed in Core Software Security: Security at the Source* in that it addresses a second critical challenge in developing software: security architecture methods and the mindset that form a frame for evaluating the security of digital systems that can be used to prescribe security treatments for those systems. Specifically, it addresses an applied approach to security architecture and threat models.
It should be noted that systems security, for the most part, is still an art not a science. A skilled security architect must bring a wealth of knowledge and understanding— global and local, technical, human, organizational, and even geopolitical—to an assess- ment. In this sense, Brook is a master of his craft, and that is why I am very excited about the opportunity to provide a Foreword to this book. He and I have worked together on a daily basis for over five years and I know of no one better with regard to his experience, technical aptitude, industry knowledge, ability to think out of the box, organizational collaboration skills, thoroughness, and holistic approach to systems architecture—specifically, security as it relates to both software and systems design and architecture. I highly recommend this book to security architects and all architects who interact with security or to those that manage them. If you have a reasonable feel for what the security architect is doing, you will be able to accommodate the results from the process within your architectures, something that he and I have been able to do successfully for a number of years now. Brook’s approach to securing systems addresses the entire enterprise, not only its digital systems, as well as the processes and people who will interact, design, and build the systems. This book fills a significant gap in the literature and is appropriate for use as a resource for both aspiring and seasoned security architects alike.
– Dr. James F. Ransome, CISSP, CISM
About Dr. James F. Ransome:
Dr. James Ransome, CISSP, CISM, is the Senior Director of Product Security at McAfee—part of Intel Security—and is responsible for all aspects of McAfee’s Product Security Program, a corporate-wide initiative that supports the delivery of secure soft- ware products to customers. His career is marked by leadership positions in private and public industries, having served in three chief information officer (CISO) and four chief security officer (CSO) roles. Prior to the corporate world, Ransome had 23 years of government service in various roles supporting the United States intelligence com- munity, federal law enforcement, and the Department of Defense. He holds a Ph.D. specializing in Information Security from a NSA/DHS Center of Academic Excellence in Information Assurance Education program. Ransome is a member of Upsilon Pi Epsilon, the International Honor Society for Computing and Information Disciplines and a Ponemon Institute Distinguished Fellow. He recently completed his 10th infor- mation security book Core Software Security: Security at the Source.*
This book replies to a question that I once posed to myself. I know from my conversations with many of my brother and sister practitioners that, early in your security careers, you have also posed that very same question. When handed a diagram containing three rectangles and two double-headed arrows connecting each box to one of the others, each of us has wondered, “How do I respond to this?”
This is a book about security architecture. The focus of the book is upon how secu- rity architecture methods and mindset form a frame for evaluating the security of digi- tal systems in order to prescribe security treatments for those systems. The treatments are meant to bring the system to a particular and verifiable risk posture.
“System” should be taken to encompass a gamut running from individual com- puters, to networks of computers, to collections of applications (however that may be defined) and including complex system integrations of all the above, and more. “System” is a generic term meant to encompass rather than exclude. Presumably, a glance through the examples in Part II of this book should indicate the breadth of reach that has been attempted?
I will endeavor along the way, to provide situationally appropriate definitions for “security architecture,” “risk,” “architecture risk assessment,” “threat model,” and “applied.” These definitions should be taken as working definitions, fit only for the pur- pose of “applied security architecture” and not as proposals for general models in any of these fields. I have purposely kept a tight rein on scope in the hope that the book retains enough focus to be useful. In my very humble experience, applied security architecture
xx Securing Systems
will make use of whatever skills—technical, interpersonal, creative, adaptive, and so forth—that you have or can learn. This one area, applied security architecture, seems big enough.
Who May Benefi t from This Book?
Any organization that places into service computer systems that have some chance of being exposed to digital attack will encounter at least some of the problems addressed within Securing Systems. Digital systems can be quite complex, involving various and sometimes divergent stakeholders, and they are delivered through the collaboration of multidisciplinary teams. The range of roles performed by those individuals who will benefit from familiarity with applied security architecture, therefore, turns out to be quite broad. The following list comprises nearly everyone who is involved in the specifi- cation, implementation, delivery, and decision making for and about computer systems.
• Security architects, assessors, analysts, and engineers • System, solution, infrastructure, and enterprise architects • Developers, infrastructure engineers, system integrators, and implementation
teams • Managers, technical leaders, program and project managers, middle management,
Security architecture is and will remain, for some time, an experience-based prac- tice. The security architect encounters far too many situations where the “right” answer will be “it depends.” Those dependencies are, in part, what this book is about.
Certainly, engineering practice will be brought to bear on secure systems. Exploit techniques tend to be particular. A firm grasp of the engineering aspects of soft- ware, networks, operating systems, and the like is essential. Applied cryptography is not really an art. Cryptographic techniques do a thing, a particular thing, exactly. Cryptography is not magic, though application is subtle and algorithms are often mathematically and algorithmically complex. Security architecture cannot be per- formed without a firm grounding in many aspects of computer science. And, at a grosser granularity, there are consistent patterns whose solutions tend to be amenable to clear-cut engineering resolution.
Still, in order to recognize the patterns, one must often apply deep and broad experience. This book aims to seed precisely that kind of experience for practitioners. Hopefully, alongside the (fictitious but commonly occurring) examples, I will have explained the reasoning and described the experience behind my analysis and the deci- sions depicted herein such that even experts may gain new insight from reading these and considering my approaches. My conclusions aren’t necessarily “right.” (Being a risk- driven practice, there often is no “right” answer.)
Beyond security architects, all architects who interact with security can benefit from this work. If you have a reasonable feel for what the security architect is doing, you will be able to accommodate the results from the process within your architectures. Over the years, many partner architects and I have grown so attuned, that we could finish each other’s sentences, speak for each other’s perspectives, and even include each other’s likely requirements within our analysis of an architecture. When you have achieved this level of understanding and collaboration, security is far more easily incorporated from the very inception of a new idea. Security becomes yet another emerging attribute of the architecture and design, just like performance or usability. That, in my humble opinion, is an ideal to strive for.
Developers and, particularly, development and technical leaders will have to translate the threat model and requirements into things that can be built and coded. That’s not an easy transformation. I believe that this translation from requirement through to func- tional test is significantly eased through a clear understanding of the threat model. In fact, at my current position, I have offered many participatory coaching sessions in the ATASM process described in this book to entire engineering teams. These sessions have had a profound effect, causing everyone involved—from architect to quality engineer— to have a much clearer understanding of why the threat model is key and how to work with security requirements. I hope that reading this book will provide a similar ground- ing for delivery teams that must include security architecture in their work.
I hope that all of those who must build and then sustain a security architecture prac- tice 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 con- siderable 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 architec- ture 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 corner- stone 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) meet- ings. 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 ser- vices 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 engage- ment 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 detec- tion 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 precari- ous 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
to draw. I could “do” architecture. I just didn’t know much about security beyond hav- ing 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 inex- perience. 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 per- spectives 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
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 impor- tantly, encouraged me, supporting me through the innumerable and inevitable mis- takes 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.
* Schoenfi eld, 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.
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 counter- vail, 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 bur- geoning 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 audi- ences, 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 com- ments 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 posi- tions 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.
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 per- vasive 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, under- standing 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.
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 writ- ten 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 techni- cians have devised methods of circumventing those governmental controls. Apparently, people all over the world prefer to experience the content that they desire and to com- municate 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. Th e 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 com- pletely 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 unpro- tected 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 real- time operating system. Since supposedly I knew something about computer network- ing, 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 soft- ware, 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 archi- tecture.” 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), organi- zations 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 organiza- tion’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. ‡ Th ough 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 on going 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 secu- rity 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 under- standing—global and local, technical, human, organizational, and even geo political— 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, secu- rity 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 infor- mation 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 encompass- ing 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 com- puter 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 archi- tecture 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.
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). “Th at ‘Internet of Th ings’ Th ing: In the real world things matter more than ideas.” RFID Journal. Retrieved from http://www.rfi djournal.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).
Often when the author is speaking at conferences about the practice of security archi- tecture, 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 embed- ded into the Secure Development Lifecycle (SDL). Among the practices that are typi- cally 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 typi- cal 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.
* Th ere 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.
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 men- torship. 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 archi- tect 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 con- trols,” 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 cross- ing numerous domain and organizational boundaries. In order to secure those systems, the skilled security architect must not alienate those who have to perform the work or
who may have a “no” vote on requirements. Accumulated through the “hard dint” of experience, this book will offer tricks of the trade to cement relationships and to work with inevitable resistance, the conflict that seems to predictably arise among teams with different viewpoints and considerations who must come to definite agreements.
There is no promise that reading this book will turn the reader into a skilled security architect. However, every technique explained here has been practiced by the author and, at least in my hands, has a proven track record. Beyond that endorsement, I have personally trained dozens of architects in these techniques. These architects have then taught the same techniques and approaches down through several generations of archi- tecture 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 assess- ment 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 “oppor- tunity.” 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 manage ment unwilling to address the mount- ing 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 suc- cessful 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 con- structive. 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 secu- rity 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 contin- ually update the “signatures,” the identifying attributes, of malicious software, and usu- ally 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, per- haps 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
to the actual data theft, the actual theft being carried out over a period of days and per- haps 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 well- known, 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 over- simplification, 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 sys- tems can turn into what architects call, “spaghetti,” a seeming lack of order and regu- larity 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 secu- rity 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 “helter- skelter,” 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 end- point 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 strate- gize 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 signifi cant period of time, there will be considerable legacy that hasn’t been architected with which to contend. Th is is the far more common case.
[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 deploy- ing 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 non- security 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 sys- tems, 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 tech- nical 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 under- stand what other systems will require, the desired security posture, perimeter protec- tions, 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 infrastruc- ture 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 bound- aries 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 architec- ture 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 “vulner- ability.” 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.
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 archi- tect 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 sys- tem, 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 exhibit- ing 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 “neces- sity” 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 imple- mentation is not within the scope of this work. Together, we will limit our explora tion 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 redun- dant 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 Confidential- ity, 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
* Th ese 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.
to consider goals as one analyzes a system for its security: The principles are the proper- ties 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 archi- tects 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 state- ment 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 secu- rity 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 sys- tems 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 “require- ments.” 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 organi zation 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 miti- gated 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 secu- rity 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 sys- tem 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
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 architec- ture 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 infor- mation 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 different products, there will be a need for common architectures, if for no other reason than maintainability and shared cost. It is typically at this point that a security infrastructure comes into being that supports at least some of the common security needs for many systems to consume. It is characteristically a virtue to keep complexity to a minimum and to reap scales of economy.
Besides, it’s easier to build and run a single security service than to maintain many different ones whose function is more or less the same. Consider storage of credentials (passwords and similar).
Maintaining multiple disparate stores of credentials requires each of these to be held at stringent levels of security control. Local variations of one of the stores may lower the overall security posture protecting all credentials, perhaps enabling a loss of these sensitive tokens through attack, whereas maintaining a single repository at a very high level, through a select set of highly trained and skilled administrators (with carefully controlled boundaries and flows) will be far easier and cheaper. Security can be held at a consistently high level that can be monitored more easily; the security events will be consistent, allowing automation rules to be implemented for raising any alarms. And so forth.
22 Securing Systems
An additional value from a single authentication and credential storing service is likely to be that users may be much happier in that they have only a single password to remember! Of course, once all the passwords are kept in a single repository, there may be a single point of failure. This will have to be carefully considered. Such considera- tions are precisely what security architects are supposed to provide to the organization.
It is the application of security principles and capabilities that is the province and domain of security architecture as applied to systems.
The first problem that must be overcome is one of discovery.
• What risks are the organization’s decision makers willing to undertake? • What security capabilities exist? • Who will attack these types of systems, why, and to attain what goals?
Without the answers to these formative questions, any analysis must either treat every possible attack as equally dangerous, or miss accounting for something impor- tant. In a world of unlimited resources, perhaps locking everything down completely may be possible. But I haven’t yet worked at that organization; I don’t practice in that world. Ultimately, the goal of a security analysis isn’t perfection. The goal is to imple- ment just enough security to achieve the surety desired and to allow the organization to take those risks for which the organization is prepared. It must always be remembered that there is no usable perfect security.
A long-time joke among information security practitioners remains that all that’s required to secure a system is to disconnect the system, turn the system off, lock it into a closet, and throw away the key. But of course, this approach disallows all purposeful use of the system. A connected, running system in purposeful use is already exposed to a certain amount of risk. One cannot dodge taking risks, especially in the realm of computer security. The point is to take those risks that can be borne and avoid those which cannot. This is why the first task is to find out how much security is “enough.” Only with this information in hand can any assessment and prescription take place.
Erring on the side of too much security may seem safer, more reasonable. But, secu- rity is expensive. Taken among the many things to which any organi zation must attend, security is important but typically must compete with a host of other organizational priorities. Of course, some organizations will choose to give their computer security primacy. That is what this investigation is intended to uncover.
Beyond the security posture that will further organizational goals, an inventory of what security has been implemented, what weaknesses and limitations exist, and what security costs must be borne by each system is critical.
Years ago, when I was just learning system assessment, I was told that every applica- tion in the application server farm creating a Secure Sockets Layer (SSL)* tunnel was required to implement bi directional, SSL certificate authentication. Such a connection
* Th is was before the standard became Transport Layer Security (TLS).
presumes that at the point at which the SSL is terminated on the answering (server) end, the SSL “stack,” implementing software, will be tightly coupled, usually even con- trolled by the application that is providing functionality over the SSL tunnel. In the SSL authentication exchange, first, the server (listener) certificate is authenticated by the client (caller). Then, the client must respond with its certificate to be authenticated by the server. Where many different and disparate, logically separated applications coexist on the same servers, each application would then have to be listening for its own SSL connections. You typically shouldn’t share a single authenticator across all of the applications. Each application must have its own certificate. In this way, each authen- tication will be tied to the relevant application. Coupling authenticator to application then provides robust, multi-tenant application authentication.
I dutifully provided a requirement to the first three applications that I analyzed to use bidirectional, SSL authentication. I was told to require this. I simply passed the requirement to project teams when encountering a need for SSL. Case closed? Unfortunately not.
I didn’t bother to investigate how SSL was terminated for our application server farms. SSL was not terminated at the application, at the application server software, or even
at the operating system upon which each server was running. SSL was terminated on a huge, specialized SSL adjunct to the bank of network switches that routed network traffic to the server farm. The receiving switch passed all SSL to the adjunct, which terminated the connection and then passed the normal (not encrypted SSL) connection request onwards to the application servers.
The key here is that this architecture separated the network details from the applica- tion details. And further and most importantly, SSL termination was quite a distance (in an application sense) from any notion of application. There was no coupling whatso- ever between application and SSL termination. That is, SSL termination was entirely independent from the server-side entities (applications), which must offer the connect- ing client an authentication certificate. The point being that the infrastructure had designed “out” and had not accounted for a need for application entities to have indivi- dual SSL certificate authenticators. The three applications couldn’t “get there from here”; there was no capability to implement bidirectional SSL authentication. I had given each of these project teams a requirement that couldn’t be accomplished without an entire redesign of a multi-million dollar infrastructure. Oops!
Before rushing full steam ahead into the analysis of any system, the security architect must be sure of what can be implemented and what cannot, what has been designed into the security infrastructure, and what has been designed out of it. There are usually at least a few different ways to “skin” a security problem, a few different approaches that can be applied. Some of the approaches will be possible and some difficult or even impossible, just as my directive to implement bidirectional SSL authentication was impossible given the existing infrastructure for those particular server farms and networks. No matter how good a security idea may seem on the face of it, it is illusory if it cannot be made real, given the limits of what exists or accounting for what can be put
24 Securing Systems
into place. I prefer never to assume; time spent understanding existing security infra- structure is always time well spent. This will save a lot of time for everyone involved. Some security problems cannot be solved without a thorough understanding of the existing infrastructure.
Almost every type and size of a system will have some security needs. Although it may be argued that a throw-away utility, written to solve a singular problem, might not have any security needs, if that utility finds a useful place beyond its original problem scope, the utility is likely to develop security needs at some point. Think about how many of the UNIX command line programs gather a password from the user. Perhaps many of these utilities were written without the need to prompt for the user’s creden- tials and subsequently to perform an authentication on the user’s behalf? Still, many of these utilities do so today. And authentication is just one security aspect out of many that UNIX system utilities perform. In other words, over time, many applications will eventually grapple with one or more security issues.
Complex business systems typically have security requirements up front. In addi- tion, either the implementing organization or the users of the system or both will have security expectations of the system. But complexity is not the determiner of security. Consider a small program whose sole purpose is to catch central processing unit (CPU) memory faults. If this software is used for debugging, it will probably have to, at the very least, build in access controls, especially if the software allows more than one user at a time (multiuser). Alternatively, if the software catches the memory faults as a part of a security system preventing misuse of the system through promulgation of memory faults, preventing say, a privilege escalation through an executing program via a mem- ory fault, then this small program will have to be self-protective such that attackers cannot turn it off, remove it, or subvert its function. Such a security program must not, under any circumstances, open a new vector of attack. Such a program will be targeted by sophisticated attackers if the program achieves any kind of broad distribution.
Thus, the answer as to whether a system requires an ARA and threat model is tied to the answers to a number of key questions:
• What is the expected deployment model? • What will be the distribution? • What language and execution environment will run the code? • On what operating system(s) will the executables run?
These questions are placed against probable attackers, attack methods, network exposures, and so on. And, of course, as stated above, the security needs of the organi- zation and users must be factored against these.
The answer to whether a system will benefit from an ARA/Threat model is a func- tion of the dimensions outlined above, and perhaps others, depending upon consider- ation of those domains on which analysis is dependent. The assessment preprocess or triage will be outlined in a subsequent chapter. The simple answer to “which systems?”
is any size, shape, complexity, but certainly not all systems. A part of the art of the secu- rity architecture assessment is deciding which systems must be analyzed, which will benefit, and which may pass. That is, unless in your practice you have unlimited time and resources. I’ve never had this luxury. Most importantly, even the smallest applica- tion may open a vulnerability, an attack vector, into a shared environment.
Unless every application and its side effects are safely isolated from every other appli- cation, each set of code can have effects upon the security posture of the whole. This is particularly true in shared environments. Even an application destined for an endpoint (a Microsoft Windows™ application, for instance) can contain a buffer overflow that allows an attacker an opportunity, perhaps, to execute code of the attacker’s choosing. In other words, an application doesn’t have to be destined for a large, shared server farm in order to affect the security of its environment. Hence, a significant step that we will explore is the security triage assessment of the need for analysis.
Size, business criticality, expenses, and complexity, among others, are dimensions that may have a bearing, but are not solely deterministic. I have seen many Enterprise IT efforts fail, simply because there was an attempt to reduce this early decision to a two-dimensional space, yes/no questions. These simplifications invariably attempted to achieve efficiencies at scale. Unfortunately, in practice today, the decision to analyze the architecture of a system for security is a complex, multivariate problem. That is why this decision will have its own section in this book. It takes experience (and usually more than a few mistakes) to ask appropriate determining questions that are relevant to the system under discussion.
The answer to “Systems? Which systems?” cannot be overly simplified. Depending upon use cases and intentions, analyzing almost any system may produce significant security return on time invested. And, concomitantly, in a world of limited resources, some systems and, certainly, certain types of system changes may be passed without review. The organization may be willing to accept a certain amount of unknown risk as a result of not conducting a review.
1. Arkin, B. (2012). “Never Waste a Crisis – Necessity Drives Software Security.” RSA Conference 2012, San Francisco, CA, February 29, 2012. Retrieved from http://www.rsaconference. com/events/us12/agenda/sessions/794/never-waste-a-crisis-necessity-drives-software.
2. Sherwood, J., Clark, A., and Lynas, D. “Enterprise Security Architecture.” SABSA White Paper, SABSA Limited, 1995–2009. Retrieved from http://www.sabsa-institute.com/ members/sites/default/inline-fi les/SABSA_White_Paper.pdf.
3. Redwine, S. T., Jr., and Davis, N., eds. (2004). “Processes to Produce Secure Software: Towards more Secure Software.” Software Process Subgroup, Task Force on Security across the Software Development Lifecycle, National Cyber Security Summit, March 2004.
4. Ransome, J. and Misra, A. (2014). Core Software Security: Security at the Source. Boca Raton (FL): CRC Press.
26 Securing Systems
5. NSA. “Defense in Depth: A practical strategy for achieving Information Assurance in today’s highly networked environments.” National Security Agency, Information Assurance Solutions Group – STE 6737. Available from: https://www.nsa.gov/ia/_fi les/ support/defenseindepth.pdf.
6. Open Web Application Security Project (OWASP) (2013). Some Proven Application Security Principles. Retrieved from https://www.owasp.org/index.php/Category:Principle.
The Art of Security Assessment
Despite the fact that general computer engineering is taught as a “science,” there is a gap between what can be engineered in computer security and what remains, as of this writ- ing, as “art.” Certainly, it can be argued that configuring Access Control Lists (ACL) is an engineering activity. Cold hard logic is employed to generate linear steps that must flow precisely and correctly to form a network router’s ACL. Each ACL rule must lie in precisely the correct place so as not to disturb the functioning of the other rules. There is a definite and repeatable order in the rule set. What is known as the “default deny” rule must be at the very end of the list of rules. For some of the rules’ ordering, there is very little slippage room, and sometimes absolutely no wiggle room as to where the rule must be placed within the set. Certain rules must absolutely follow other rules in order for the entire list to function as designed.
Definition of “engineering”:
The branch of science and technology concerned with the design, building, and use of engines, machines, and structures.1
Like an ACL list, the configuration of alerts in a security monitoring system, the use of a cryptographic function to protect credentials, and the handling of the crypto- graphic keying material are all engineering tasks. There are specific demands that must be met in design and implementation. This is engineering. Certainly, a great deal in computer security can be described as engineering.
There is no doubt that the study of engineering requires a significant investment in time and effort. I do not mean to suggest otherwise. In order to construct an effective
28 Securing Systems
ACL, a security engineer must understand network routing, TCP/IP, the assignment and use of network ports for application functions, and perhaps even some aspects and details of the network protocols that will be allowed or blocked. Alongside this general knowledge of networking, a strong understanding of basic network security is essential. And, a thorough knowledge of the configuration language that controls options for the router or firewall on which the rule set will be applied is also essential. This is a con- siderable and specific knowledge set. In large and/or security-conscious organizations, typically only experts in all of these domains are allowed to set up and maintain the ACL lists on the organization’s networking equipment.
Each of these domains follows very specific rules. These rules are deterministic; most if not all of the behaviors can be described with Boolean logic. Commands must be entered precisely; command-line interpreters are notoriously unforgiving. Hence, hopefully, few will disagree that writing ACLs is an engineering function.
2.1 Why Art and Not Engineering?
In contrast, a security architect must use her or his understanding of the currently active threat agents in order to apply these appropriately to a particular system. Whether a particular threat agent will aim at a particular system is as much a matter of under- standing, knowledge, and experience as it is cold hard fact.* Applying threat agents and their capabilities to any particular system is an essential activity within the art of threat modeling. Hence, a security assessment of an architecture is an act of craft.
Craftsmen know the ways of the substances they use. They watch. Perception and systematic thinking combine to formulate understanding.2
Generally, effective security architects have a strong computer engineering back- ground. Without the knowledge of how systems are configured and deployed, and without a broad understanding of attack methods—maybe even a vast array of attack methods and their application to particular scenarios—the threat model will be incom- plete. Or the modeler will not be able to prioritize attacks. All attacks will, therefore, have to be considered as equally probable. In security assessment, art meets science; craft meets engineering; and experience meets standard, policy, and rule. Hence, the methodology presented here is a combination of art and science, craft and engineering.
It would be prohibitively expensive and impractical to defend every possible vulnerability.3
* Th ough we do know with absolute certainty that any system directly addressable on the Public Internet will be attacked, and that the attacks will be constant and unremitting.
The Art of Security Assessment 29
Perhaps someday, security architecture risk assessment (ARA) and threat model- ing will become a rigorous and repeatable engineering activity? As of the writing of this book, however, this is far from the case. Good assessors bring a number of key knowledge domains to each assessment. It is with these domains that we will start. Just as an assessment begins before the system is examined, so in this chapter we will explore the knowledge and understanding that feeds into and underpins an analysis of a system for security purposes.
You may care to think of these pre-assessment knowledge domains as the homework or pre-work of an assessment. When the analyst does not have this information, she or he will normally research appropriately before entering into the system assessment. Of course, if during an assessment you find that you’ve missed something, you can always stop the analysis and do the necessary research. While I do set this out in a linear fash- ion, the linearity is a matter of convenience and pedagogy. There have been many times when I have had to stop an assessment in order to research a technology or a threat agent capability about which I was unsure.
It is key to understand that jumping over or missing any of the prerequisite knowledge sets is likely to cause the analysis to be incomplete, important facets to be missed. The idea here is to help you to be holistic and thorough. Some of the biggest mistakes I’ve made have been because I did not look at the system as a whole but rather focused on a particular problem to the detriment of the resulting analysis. Or I didn’t do thorough research. I assumed that what I knew was complete when it wasn’t. My assessment mis- takes could likely fill an entire volume by themselves. Wherever relevant, I will try to highlight explanations with both my successes and my failures.
Because we are dealing with experience supporting well-educated estimates, the underpinning knowledge sets are part of the assessor’s craft. It is in the application of controls for risk mitigation that we will step into areas of hard engineering, once again.
2.2 Introducing “The Process”
It certainly may appear that an experienced security architect can do a system assess- ment, even the assessment of something fairly complex, without seeming to have any structure to the process at all. Most practitioners whom I’ve met most certainly do have a system and an approach. Because we security architects have methodologies, or I should say, I have a map in my mind while I assess, I can allow myself to run down threads into details without losing the whole of both the architecture and the methodology. But, unfortunately, that’s very hard to teach. Without structure, the whole assessment may appear aimless and unordered? I’ve had many people follow me around through many, many reviews. Those who are good at following and learning through osmosis “get it.” But many people require a bit more structure in order to fit the various elements that must be covered into a whole and a set of steps.
30 Securing Systems
Because most experienced architects actually have a structure that they’re following, that structure gives the architect the opportunity to allow discussion to flow where it needs to rather than imposing a strict agenda. This approach is useful, of course, in helping everyone involved feel like they’re part of a dialogue rather than an inter- rogation. Still, anyone who doesn’t understand the map may believe that there is no structure at all. In fact, there is a very particular process that proceeds from threat and attack methods, through attack surfaces, and ultimately resulting in requirements. Practitioners will express these steps in different ways, and there are certainly many dif- ferent means to express the process, all of them valid. The process that will be explained in this book is simply one expression and certainly not absolute in any sense of the word.
Further, there is certain information, such as threat analysis, that most practitioners bring to the investigation. But the architect may not take the time to describe this pre- assessment information to other participants. It was only when I started to teach the process to others that I realized I had to find a way to explain what I was doing and what I knew to be essential to the analysis.
Because this book explains how to perform an assessment, I will try to make plain all that is necessary. Please remember when you’re watching an expert that she or he will apply existing knowledge to an analysis but may not explain all the pre-work that she or he has already expended. The security architect will have already thought through the appropriate list of threat agents for the type of system under consideration. If this type of system is analyzed every day, architects live and breathe the appropriate infor- mation. Hence, they may not even realize the amount of background that they bring to the analysis.
I’m going to outline with broad strokes a series of steps that can take one from pre- requisite know ledge through a system assessment. This series of steps assumes that the analyst has sufficient understanding of system architecture and security architecture going into the analysis. It also assumes that the analyst is comfortable uncovering risk, rating that risk, and expressing it appropriately for different audiences. Since each of these, architecture and risk, are significant bodies of knowledge, before proceeding into the chapters on analysis, we will take time exploring each domain in a separate section. As you read the following list, please remember that there are significant prerequisite understandings and knowledge domains that contribute to a successful ARA.
○ Enumerate inputs and connections ○ Enumerate threats for this type of system and its intended deployment – Consider threats’ usual attack methods – Consider threats’ usual goals ○ Intersect threat’s attack methods against the inputs and connections. These are the
set of attack surfaces ○ Collect the set of credible attack surfaces ○ Factor in each existing security control (mitigations) ○ Risk assess each attack surface. Risk rating will help to prioritize attack surfaces
The Art of Security Assessment 31
Each of the foregoing steps hides a number of intermediate steps through which an assessment must iterate. The above list is obviously a simplification. A more complete list follows. However, these intermediate steps are perceived as a consequence of the investigation. At this point, it may be more useful to understand that relevant threats are applied to the attack surfaces of a system to understand how much additional secu- rity needs to be added.
The analysis is attempting to enumerate the set of “credible attack surfaces.” I use the word “credi ble” in order to underline the fact that every attack method is not appli- cable to every input. In fact, not every threat agent is interested in every system. As we consider different threat agents, their typical methods, and most importantly, the goals of their attacks, I hope that you’ll see that some attacks are irrelevant against some systems: These attacks are simply not worth consideration. The idea is to filter out the noise such that the truly relevant, the importantly dangerous, get more attention than anything else.
Credible attack vector: A credible threat exercising an exploit on an exposed vulnerability.
I have defined the term “credible attack vector.” This is the term that I use to indi- cate a composite of factors that all must be true before an attack can proceed. I use the term “true” in the Boolean sense: there is an implicit “if” statement (for the pro- gramming language minded) in the term “credible”: if the threat can exercise one of the threat’s exploit techniques (attack method) upon a vulnerability that is sufficiently exposed such that the exploit may proceed successfully.
There are a number of factors that must each be true before a particular attack sur- face becomes relevant. There has to be a known threat agent who has the capability to attack that attack surface. The threat agent has to have a reason for attacking. And most importantly, the attack surface needs to be exposed in some way such that the threat agent can exploit it. Without each of these factors being true, that is, if any one of them is false, then the attack cannot be promulgated. As such, that particular attack is not worth considering. A lack of exposure might be due to an existing set of controls. Or, there might be architectural reasons why the attack surface is not exposed. Either way, the discussion will be entirely theoretical without exposure.
Consider the following pseudo code:
Credible attack vector = (active threat agent & exploit & exposure & vulnerability)
The term “credible attack vector” may only be true if each of the dependent conditions is true. Hence, an attack vector is only interesting if its component terms all return a “true” value. The operator combining each terms is Boolean And. Understanding the combinatory quality of these terms is key in order to filter out hypothetical attacks in favor of attacks that have some chance of succeeding if these attacks are not well defended.
32 Securing Systems
Also important: If the attacker cannot meet his or her goals by exploiting a par- ticular attack surface, the discussion is also moot. As an example, consider an overflow condition that can only be exploited with elevated, super-user privileges. At the point at which attackers have gained superuser privileges, they can run any code they want on most operating systems. There is no advantage to exploiting an additional overflow. It has no attack value. Therefore, any vulnerability such as the one outlined here is theoretical. In a world of limited resources, concentrating on such an overflow wastes energy that is better spent elsewhere.
In this same vein, a credible attack vector has little value if there’s no reward for the attacker. Risk, then, must include a further term: the impact or loss. We’ll take a deeper dive into risk, subsequently.
An analysis must first uncover all the credible attack vectors of the system. This simple statement hides significant detail. At this point in this work, it may be suffi- cient to outline the following mnemonic, “ATASM.” Figure 2.1 graphically shows an ATASM flow:
Figure 2.1 Architecture, threats, attack surfaces, and mitigations.
Threats are applied to the attack surfaces that are uncovered through decomposing an architecture. The architecture is “factored” into its logical components—the inputs to the logical components and communication flows between components. Existing mitigations are applied to the credible attack surfaces. New (unimplemented) mitiga- tions become the “security requirements” for the system. These four steps are sketched in the list given above. If we break these down into their constituent parts, we might have a list something like the following, more detailed list:
• Diagram (and understand) the logical architecture of the system. • List all the possible threat agents for this type of system. • List the goals of each of these threat agents. • List the typical attack methods of the threat agents. • List the technical objectives of threat agents applying their attack methods. • Decompose (factor) the architecture to a level that exposes every possible attack
surface. • Apply attack methods for expected goals to the attack surfaces. • Filter out threat agents who have no attack surfaces exposed to their typical
The Art of Security Assessment 33
• Deprioritize attack surfaces that do not provide access to threat agent goals. • List all existing security controls for each attack surface. • Filter out all attack surfaces for which there is sufficient existing protection. • Apply new security controls to the set of attack services for which there isn’t
sufficient mitigation. Remember to build a defense-in-depth. • The security controls that are not yet implemented become the set of security
requirements for the system.
Even this seemingly comprehensive set of steps hides significant detail. The details that are not specified in the list given above comprise the simplistic purpose of this book. Essentially, this work explains a complex process that is usually treated atomically, as though the entire art of security architecture assessment can be reduced to a few easily repeated steps. However, if the process of ARA and threat modeling really were this simple, then there might be no reason for a lengthy explication. There would be no need for the six months to three years of training, coaching, and mentoring that is typi- cally undertaken. In my experience, the process cannot be so reduced. Analyzing the security of complex systems is itself a complex process.
2.3 Necessary Ingredients
Just as a good cook pulls out all the ingredients from the cupboards and arranges them for ready access, so the experienced assessor has at her fingertips information that must feed into the assessment. In Figure 2.2, you will see the set of knowledge domains that
Figure 2.2 Knowledge sets that feed a security analysis.
34 Securing Systems
feed into an architecture analysis. Underlying the analysis set are two other domains that are discussed, separately, in subsequent chapters: system architecture and specifi- cally security architecture, and information security risk. Each of these requires its own explanation and examples. Hence, we take these up below.
The first two domains from the left in Figure 2.2 are strategic: threats and risk pos- ture (or tolerance). These not only feed the analysis, they help to set the direction and high-level requirements very early in the development lifecycle. For a fuller discussion on early engagement, please see my chapter, “The SDL in the Real World,” in Core Software Security.4 The next two domains, moving clockwise—possible controls and existing limitations—refer to any existing security infrastructure and its capabilities: what is possible and what is difficult or excluded. The last three domains—data sensi- tivity, runtime/execution environment, and expected deployment model—refer to the system under discussion. These will be discussed in a later chapter.
Figure 2.3 places each contributing knowledge domain within the area for which it is most useful. If it helps you to remember, these are the “3 S’s.” Strategy, infrastructure and security structures, and specifications about the system help determine what is important: “Strategy, Structures, Specification.” Indeed, very early in the lifecycle, per- haps as early as possible, the strategic understandings are critically important in order to deliver high-level requirements. Once the analysis begins, accuracy, relevance, and deliverability of the security requirements may be hampered if one does not know what security is possible, what exists, and what the limitations are. As I did in my first couple of reviews, it is easy to specify what cannot actually be accomplished. As an architecture begins to coalesce and become more solid, details such as data sensitivity, the runtime and/or execution environment, and under what deployment models the system will run become clearer. Each of these strongly influences what is necessary, which threats and attack methods become relevant, and which can be filtered out from consideration.
Figure 2.3 Strategy knowledge, structure information, and system specifi cs.
The Art of Security Assessment 35
It should be noted that the process is not nearly as linear as I’m presenting it. The deployment model, for instance, may be known very early, even though it’s a fairly specific piece of knowledge. The deployment model can highly influence whether secu- rity is inherited or must be placed into the hands of those who will deploy the system. As soon as this is known, the deployment model will engender some design imperatives and perhaps a set of specific controls. Without these specifics, the analyst is more or less shooting in the dark.
2.4 The Threat Landscape
Differing groups target and attack different types of systems in different ways for dif- ferent reasons. Each unique type of attacker is called a “threat agent.” The threat agent is simply an individual, organi zation, or group that is capable and motivated to pro- mulgate an attack of one sort or another. Threat agents are not created equal. They have different goals. They have different methods. They have different capabilities and access. They have different risk profiles and will go to quite different lengths to be suc- cessful. One type of attacker may move quickly from one system to another searching for an easy target, whereas another type of attacker or threat agent may expend con- siderable time and resources to carefully target a single system and goal. This is why it is important to understand who your attackers are and why they might attack you. Indeed, it helps when calculating the probability of attack to know if there are large numbers or very few of each sort of attackers. How active is each threat agent? How might a successful attack serve a particular threat agent’s goals?
You may note that I use the word “threat” to denote a human actor who promul- gates attacks against computer systems. There are also inanimate threats. Natural disasters, such as earthquakes and tornadoes, are most certainly threats to computer systems. Preparing for these types of events may fall onto the security architect. On the other hand, in many organizations, responding to natural disasters is the responsibility of the business continuity function rather than the security function. Responding to natural disaster events and noncomputer human events, such as riots, social disruption, or military conflict, do require forethought and planning. But, it is availability that is mostly affected by this class of events. And for this reason generally, the business con- tinuity function takes the lead rather than security. We acknowledge the seriousness of disastrous events, but for the study of architecture analysis for security, we focus on human attackers.
It should be noted that there are research laboratories who specialize in understand- ing threat agents and attack methods. Some of these, even commercial research, are regularly published for the benefit of all. A security architect can consume these public reports rather than trying to become an expert in threat research. What is important is to stay abreast of current trends and emerging patterns. Part of the art of security
36 Securing Systems
assessment is planning for the future. As of this writing, two very useful reports are produced by Verizon and by McAfee Labs.*
Although a complete examination of every known computer attacker is far beyond the scope of this work, we can take a look at a few examples to outline the kind of knowledge about threats that is necessary to bring to an assessment.
There are three key attributes of human attackers, as follows:
• Intelligence • Adaptivity • Creativity
This means that whatever security is put into place can and will be probed, tested, and reverse engineered. I always assume that the attacker is as skilled as I am, if not more so. Furthermore, there is a truism in computer security: “The defender must close every hole. The attacker only needs one hole in order to be successful.” Thus, the onus is on the defender to understand his adversaries as well as possible. And, as has been noted several times previously, the analysis has to be thorough and holistic. The attackers are clever; they only need one opportunity for success. One weak link will break the chain of defense. A vulnerability that is unprotected and exposed can lead to a successful attack.
2.4.1 Who Are These Attackers? Why Do They Want to Attack My System?
Let’s explore a couple of typical threat agents in order to understand what it is we need to know about threats in order to proceed with an analysis.† Much media attention has been given to cyber criminals and organized cyber crime. We will contrast cyber crimi- nals with industrial espionage threats (who may or may not be related to nation-state espionage). Then we’ll take a look at how cyber activists work, since their goals and methods differ pretty markedly from cyber crime. These three threat agents might be the only relevant ones to a particular system. But these are certainly not the only threat agents who are active as of this writing. It behooves you, the reader, to take advantage of public research in order to know your attackers, to understand your adversaries.
* Full disclosure: At the time of this writing, the author works for McAfee Inc. However, citing these two reports from among several currently being published is not intended as an endorsement of either company or their products. Verizon and McAfee Labs are given as example reports. Th ere are others.
† Th e threat analysis presented in this work is similar in intention and spirit to Intel’s Th reat Agent Risk Assessment (TARA). However, my analysis technique was developed independently, without knowledge of TARA. Any resemblance is purely coincidental.
The Art of Security Assessment 37
Currently, organized cyber criminals are pulling in billions and sometimes tens of billions of dollars each year. Email spam vastly outweighs in volume the amount of legitimate email being exchanged on any given day. Scams abound; confidence games are ubiquitous. Users identities are stolen every day; credit card numbers are a dime a dozen on the thriving black market. Who are these criminals and what do they want?
The simple answer is money. There is money to be made in cyber crime. There are thriving black markets in compromised computers. People discover (or automate exist- ing) and then sell attack exploits; the exploit methods are then used to attack systems. Fake drugs are sold. New computer viruses get written. Some people still do, appar- ently, really believe that a Nigerian Prince is going to give them a large sum of money if they only supply a bank account number to which the money will supposedly be wired.
Each of these activities generates revenue for someone. That is why people do these things, for income. In some instances, lots of income. The goal of all of this activity is really pretty simple, as I understand it. The goal of cyber criminals can be summed up with financial reward. It’s all about the money.
But, interestingly, cyber criminals are not interested in computer problems, per se. These are a means to an end. Little hard exploit research actually occurs in the cyber crime community. Instead, these actors tend to prefer to make use of the work of others, if possible. Since the goal is income, like any business, there’s more profit when cost of goods, that is, when the cost of research can be minimized.
This is not to imply that cyber criminals are never sophisticated. One only has to investigate fast flux DNS switching to realize the level of technical skill that can be brought to bear. Still, the goal is not to be clever, but to generate revenue.
Cyber crime can be an organized criminal’s “dream come true.” Attacks can be largely anonymous. Plenty of attack scenarios are invisible to the target until after suc- cess: Bank accounts can be drained in seconds. There’s typically no need for heavy handed thuggery, no guns, no physical interaction whatsoever. These activities can be conducted with far less risk than physical violence. “Clean crime?”
Hence, cyber criminals have a rather low risk tolerance, in general. Attacks tend to be poorly targeted. Send out millions of spams; one of them will hit somewhere to someone. If you wonder why you get so many spams, it’s because these continue to hit pay dirt; people actually do click those links, they do order those fake drugs, and they do believe that they can make $5000 per week working from home. These email scams are successful or they would stop. The point here is that if I don’t order a fake drug, that doesn’t matter; the criminal moves on to someone who will.
If a machine can’t easily be compromised, no matter. Cyber criminals simply move on to one that can fall to some well-known vulnerability. If one web site doesn’t offer any cross-site scripting (XSS) opportunities from which to attack users, a hundred thou- sand other web sites do offer this vulnerability. Cyber criminals are after the gullible, the poorly defended, the poorly coded. They don’t exhibit a lot of patience. “There’s a sucker born every day,” as T.E. Barnum famously noted.
38 Securing Systems
From the foregoing, you may also notice that cyber criminals prefer to put in as little work as possible. I call this a low “work factor.” The pattern then is low risk, low work factor. The cyber criminal preference is for existing exploits against existing vulnerabili- ties. Cyber criminals aren’t likely to carefully target a system or a particular individual, as a generalization. (Of course, there may be exceptions to any broad characterization.)
There are documented cases of criminals carefully targeting a particular organi- zation. But even in this case, the attacks have gone after the weak links of the system, such as poorly constructed user passwords and unpatched systems with well-known vulnerabilities, rather than highly sophisticated attack scenarios making use of unknown vulnerabilities.
Further, there’s little incentive to carefully map out a particular person’s digital life. That’s too much trouble when there are so many (unfortunately) who don’t patch their systems and who use the same, easily guessed password for many systems. It’s a simple matter of time and effort. When not successful, move on to the next mark.
This Report [2012 Attorney General Breach Report*], and other studies, have repeatedly shown that cybercrime is largely opportunistic.† In other words, the organizations and individuals who engage in hacking, malware, and data breach crimes are mostly looking for “low-hanging fruit” — today’s equivalent of someone who forgets to lock her car door.5
If you’ve been following along, I hope that you have a fair grasp of the methods, goals, and profile of the cyber criminal? Low work factor, easy targets, as little risk as possible.
Let’s contrast cyber crime to some of the well-known industrial espionage cases. Advanced persistent threats (APTs) are well named because these attack efforts can be multi-year, multidimensional, and are often highly targeted. The goals are informa- tion and disruption. The actors may be professionals (inter-company espionage), quasi- state sponsored (or, at least, state tolerated), and nation-states themselves. Many of the threat agents have significant numbers of people with which to work as well as being well funded. Hence, unlike organized cyber criminals, no challenge is too difficult. Attackers will spend the time and resources necessary to accomplish the job.
I am convinced that every company in every conceivable industry with significant size and valuable intellectual property and trade secrets has been compromised (or will be shortly) . . . In fact, I divide the entire set of Fortune Global 2,000 firms into two categories: those that know they’ve been compromised and those that don’t yet know.6
* Harris, K. D. (2013). 2012 Attorney General Breach Report. Retrieved from http://oag. ca.gov/news/press-releases/attorney-general-kamala-d-harris-releases-report-data-breaches- 25-million> (as of Jan. 8, 2014).
† VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT, 2014. Retrieved from http://www.verizonenterprise.com/DBIR/2014/reports/rp_Verizon-DBIR-2014_en_xg.pdf.
The Art of Security Assessment 39
We have collected logs that reveal the full extent of the victim population since mid- 2006 when the log collection began.7
That is, Operation “Shady RAT” likely began in 2006, whereas the McAfee research was published in 2011. That is an operation of at least five years. There were at least 70 organizations that were targeted. In fact, as the author suggests, all of the Fortune 2000 companies were likely successfully breached. These are astounding numbers.
More astounding then the sheer breadth of Shady RAT is the length, sophistication, and persistence of this single set of attacks, perhaps promulgated by a single group or under a single command structure (even if multiple groups). APT attacks are multi- month, often multi-year efforts. Sometimes a single set of data is targeted, and some- times the attacks seem to be after whatever may be available. Multiple diversionary attacks may be exercised to hide the data theft. Note the level of sophistication here:
• Carefully planned and coordinated • Highly secretive • Combination of techniques (sometimes highly sophisticated)
The direct goal is rarely money (though commercial success or a nation-state advan- tage may ultimately be the goal). The direct goal of the attack is usually data, informa- tion, or disruption. Like cyber criminals, APT is a risk averse strategy, attempting to hide the intrusion and any compromise. Persistence is an attribute. This is very unlike the pattern of cyber criminals, who prefer to find an easier or more exposed target. For industrial spies, breaking through a defense-in-depth is an important part of the approach. Spies will take the time necessary to study and then to target indivi duals. New software attacks are built. Nation-states may even use “zero day” (previously unknown) vulnerabilities and exploits. The United States’ STUXNET attack utilized an exploit never before seen.
Although both cyber criminals and industrial spies are fairly risk averse, their methods differ somewhat—that is, both threats make use of anonymizing services, but spies will attempt to cover their tracks completely. They don’t want the breach to be discovered, ever, if possible. In contrast, criminals tend to focus on hiding only their identity. Once the theft has occurred, they don’t want to be caught and punished; their goal is to hang on to their illegitimate gains. The fact that a crime has occurred will eventually be obvious to the victim.
These two approaches cause different technical details to emerge through the attacks. And, defenses need to be different.
Since the cyber criminal will move on in the event of resistance, an industry stan- dard defense is generally sufficient. As long as the attack work-factor is kept fairly high, the attackers will go somewhere else that offers easier pickings. The house with the dog and burglar alarm remains safe. Next door, the house with poor locks that is regularly unoccupied is burglarized repeatedly.
40 Securing Systems
The industrial spy spends weeks, months, years researching the target organization’s technology and defenses. The interests and social relations of potentially targetable users are carefully studied. In one famous attack, the attacker knew that on a particu- lar day, a certain file was distributed to a given set of individuals with an expected file name. By spoofing the document and the sender, several of the recipients were fooled into opening the document, which contained the attack.
It is difficult to resist a targeted “spear phishing” attack: An email or URL that appears to be sent such that the email masquerades as something expected, of particular interest, from someone trusted. To resist an APT effort, defenses must be thorough and in depth. No single defense can be a single point of failure. Each defense is assumed to fail. As the principles previously outlined state, each defense must “fail securely.” The entire defense cannot count on any single security control surviving; controls are layered, with spheres of control overlapping significantly. The concept being that one has built sufficient barriers for the attackers to surmount such that an attack will be identified before it can fully succeed.* It is assumed that some protections will fail to the technical excellence of the attackers. But the attacks will be slower than the reacti on to them.
Figure 2.4 attempts to provide a visual mapping of the relationships between various attributes that we might associate with threat agents. This figure includes inanimate threats, with which we are not concerned here. Attributes include capabilities, activity level, risk tolerance, strength of the motivation, and reward goals.
If we superimpose attributes from Table 2.1’s cyber-crime attributes onto Figure 2.4, we can render Figure 2.5. Figure 2.5 gives us a visual representation of cyber criminal threat agent attributes and their relationships in a mind map format.
[I]f malicious actors are interested in a company in the aerospace sector, they may try to compromise the website of one of the company’s vendors or the website of an aerospace industry-related conference. That website can become a vector to exploit and infect employees who visit it in order to gain a foothold in the intended target company.8
We will not cover every active threat here. Table 2.1 summarizes the attributes that characterize each of the threat agents that we’re examining. In order to illustrate the differences in methods, goals, effort, and risk tolerance of differing threat agents, let’s now briefly examine the well-known “hacktivist” group, Anonymous.
Unlike either cyber criminals or spies, activists typically want the world to know about a breach. In the case of the HP Gary Federal hack (2011), the email, user credentials, and other compromised data were posted publicly after the successful breach. Before the advent of severe penalties for computer breaches, computer activists sometimes did
* Astute readers may note that I did not say, “attack prevented.” Th e level of focus, eff ort, and sophistication that nation-state cyber spies can muster implies that most protections can be breached, if the attackers are suffi ciently motivated.
The Art of Security Assessment 41
not hide their attack at all.* As of this writing, activists do try to hide their identities because current US law provides serious penalties for any breach, whether politically motivated or not: All breaches are treated as criminal acts. Still, hacktivists go to no great pains to hide the compromise. Quite the opposite. The goal is to uncover wrong- doing, perhaps even illegal actions. The goal is an open flow of information and more transparency. So there is no point in hiding an attack. This is completely opposite to how spies operate.
Figure 2.4 Threat agent attribute relationships.
Table 2.1 Summarized Threat Attributes
Threat Agent Goals Risk Tolerance Work Factor Methods
Cyber criminals Financial Low Low to medium Known proven
Industrial spies Information and disruption
Low High to extreme Sophisticated and unique
Hacktivists Information, disruption, and media attention
Medium to high Low to medium System administration errors and social engineering
* Under the current US laws, an activist (Aaron Schwartz) who merely used a publicly available system (MIT library) faced terrorism charges for downloading readily available scientifi c papers without explicit permission from the library and each author. Th is shift in US law has proven incredibly chilling to transparent cyber activism.
42 Securing Systems
The technical methods that were used by Anonymous were not particularly sophisti- cated.* At HP Gary Federal, a very poorly constructed and obvious password was used for high-privilege capabilities on a key system. The password was easily guessed or oth- erwise forced. From then on, the attackers employed social engineering, not technical acumen. Certainly, the attackers were familiar with the use of email systems and the manipulation of servers and their operating systems. Any typical system administrator would have the skills necessary. This attack did not require sophisticated reverse engi- neering skills, understanding of operating system kernels, system drivers, or wire-level network communications. Anonymous didn’t have to break any industrial-strength cryptography in order to breach HB Gary Federal.
Computer activists are volunteers. They do not get paid (despite any propaganda you may have read). If they do have paying jobs, their hacktivism has to be performed during
Figure 2.5 Cyber criminal attributes.
* I drew these conclusions after reading a technically detailed account of the HB Gary attack in Unmasked, by Peter Bright, Nate Anderson, and Jacqui Cheng (Amazon Kindle, 2011).9 Th e conclusions that I’ve drawn about Anonymous were further bolstered by an in-depth analysis appearing in Rolling Stone Magazine, “Th e Rise and Fall of Jeremy Hammond: Enemy of the State,” by Janet Reitman, appearing in the December 7, 2012, issue.10 It can be retrieved from: http://www.rollingstone.com/culture/news/ the-rise-and-fall-of-jeremy-hammond-enemy-of-the-state-20121207.
The Art of Security Assessment 43
their non-job hours. Although there is some evidence that Anonymous did coordinate between the various actors, group affiliation is loose. There are no leaders who give the orders and coordinate the work of the many to a single goal. This is quite unlike the organization of cyber criminals or cyber spies.
In our short and incomplete survey, I hope you now have a feel for the differences between at least some of the currently active threat agents.
• Cyber crimes: The goal is financial. Risk tolerance is low. Effort tends to be low to medium; cyber criminals are after the low hanging fruit. Their methods tend to be proven.
• Industrial espionage: The goal is information and disruption. Risk tolerance is low. Effort can be quite high, perhaps even extreme. Difficult targets are not a barrier. Methods are very sophisticated.
• Computer activists: The goal is information, disruption, and media attention. Risk tolerance is medium to high (they are willing to go to jail for their beliefs). Their methods are computer savvy but not necessarily sophisticated. They are willing to put in the time necessary to achieve their goal.
These differences are summarized in Table 2.1, above. Each of these threat agents operates in a different way, for different motivations, and
with different methods. Although many of the controls that would be put into place to protect against any of them are the same, a defense-in-depth has to be far more rigor- ous and deep against industrial espionage or nation-state spying versus cyber criminals or activists.
If a system does not need to resist industrial espionage, it may rely on a less rigorous defense. Instead, shoring up significant barriers to attack at the entrances to systems should be the focus. On the other hand, preparing to resist a nation-state attack will likely also discourage cyber criminals. Attending to basics appropriately should deter many external activists.*
Hopefully, at this point you can see that knowing who your attackers are and some- thing about them influences the way you build your defenses. An organization will need to decide which of the various threat agents pose the most likely attack scenarios and which, if any, can be ignored. Depending upon the use of the system, its exposure, the data it handles, and the organizations that will deploy and use the system, certain threat agents are likely to be far more important and dangerous to the mission of the organization than others. An organization without much controversy may very well not have to worry about computer activism. An organization that offers little financial reward may not have to worry about cyber crime (other than the pervasive cyber crime
* Edward Snowden, the NSA whistleblower, was given almost free rein to access systems as a trusted insider. In his case, he required no technical acumen in order to retrieve much of the information that he has made public. He was given access rights.
44 Securing Systems
that’s aimed at every individual who uses a computer). And likewise, an organization that handles a lot of liquid funds may choose to focus on cyber crime.
I do not mean to suggest that there’s only one threat that any particular system must resist. Rather, the intersection of organization, organizational mission, and systems can help focus on those threats that are of concern while, at the same time, allowing some threat agents and their attack methods to be de-prioritized.
2.5 How Much Risk to Tolerate?
As we have seen, different threat agents have different risk tolerances. Some attempt near perfect secrecy, some need anonymity, and some require immediate attention for success. In the same way, different organizations have different organizational risk pos- tures. Some businesses are inherently risky; the rewards need to be commensurate with the risk. Some organizations need to minimize risk as much as possible. And, some organizations have sophisticated risk management processes. One only needs to con- sider an insurance business or any loan-making enterprise. Each of these makes a profit through the sophisticated calculation of risk. An insurance company’s management of its risk will, necessarily, be a key activity for a successful business. On the other hand, an entrepreneurial start-up run by previously successful businesspeople may be able to tolerate a great deal of risk. That, in fact, may be a joy for the entrepreneur.
Since there is no perfect security, and there are no guarantees that a successful attack will always be prevented, especially in computer security, risk is always inherent in the application of security to a system. And, since there are no guarantees, how much security is enough? This is ultimately the question that must be answered before the appropriate set of security controls can be applied to any system.
I remind the reader of a definition from the Introduction:
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.
I have emphasized “a particular security posture.” Some security postures will be too little to resist the attacks that are most likely to come. On the other hand, deep, rigorous, pervasive information security is expensive and time consuming. The classic example is the situation where the security controls cost more than the expected return on investment for the system. It should be obvious that such an expensive security posture would then be too much? Security is typically only one of many attributes that contribute to the success of a particular system, which then contributes to the success of the organi zation. When resources are limited (and aren’t they always?), difficult choices need to be made.
In my experience, it’s a great deal easier to make these difficult choices when one has a firm grasp on what is needed. A system that I had to assess was subject to a number of the organization’s standards. The system was to be run by a third party, which brought
The Art of Security Assessment 45
it under the “Application Service Provider Policy.” That policy and standard was very clear: All third parties handling the organization’s data were required to go through an extensive assessment of their security practices. Since the proposed system was to be exposed to the Internet, it also fell under standards and policies related to protection of applications and equipment exposed to the Public Internet. Typically, application service provider reviews took two or three months to complete, sometimes considerably longer. If the third party didn’t see the value in participating or was resistive for any other reason, the review would languish waiting for their responses. And, oftentimes the responses would be incomplete or indicate a misunderstanding of one or more of the review questions. Though unusual, a review could take as long as a year to complete.
The Web standards called for the use of network restrictions and firewalls between the various components, as they change function from Web to application to data (multi-tier protections). This is common in web architectures. Further, since the organi- zation putting forth the standards deployed huge, revenue-producing server farms, its standards were geared to large implementations, extensive staff, and very mature pro- cesses. These standards would be overwhelming for a small, nimble, poorly capitalized company to implement.
When the project manager driving the project was told about all the requirements that would be necessary and the likely time delays that meeting the requirements would entail, she was shocked. She worked in a division that had little contact with the web security team and, thus, had not encountered these policies and standards previously. She then explained that the company was willing to lose all the money to be expended on this project: The effort was an experiment in a new business model. That’s why they were using a third party. They wanted to be able to cut loose from the effort and the application on a moment’s notice. The company’s brand name was not going to be asso- ciated with this effort. So there was little danger of a brand impact should the system be successfully breached. Further, there was no sensitive data: All the data was eminently discardable. This application was to be a tentative experiment. The goal was simply to see if there was interest for this type of application. In today’s lexicon, the company for which I worked was searching for the “right product,” rather than trying to build the product “right.”
Any system connected to the Internet, of course, must have some self-protection against the omnipresent level of attack it must face. But the kind of protections that we would normally have put on a web system were simply too much for this particular project. The required risk posture was quite low. In this case, we granted exceptions to the policies so that the project could go forward quickly and easily. The controls that we actually implemented were just sufficient to stave off typical, omnipresent web attack. It was a business decision to forgo a more protective security posture.
The primary business requirements for information security are business-specific. They will usually be expressed in terms of protecting the availability, integrity, authenticity and confidentiality of business information, and providing accountability and auditability in information systems.11
46 Securing Systems
There are two risk tolerances that need to be understood before going into a system security assessment.
• What is the general risk tolerance of the owners of the system? • What is the risk tolerance for this particular system?
Systems critical to the functioning of an organization will necessarily have far less risk tolerance and a far higher security posture than systems that are peripheral. If a business can continue despite the loss of a system or its data, then that system is not nearly as important as a system whose functioning is key. It should be noted that in a shared environment, even the least critical application within the shared environment may open a hole that degrades the posture of the entire environment. If the environ- ment is critical, then the security of each component, no matter how peripheral, must meet the standards of the entire environment. In the example above, the system under assessment was both peripheral and entirely separate. Therefore, that system’s loss could not have significant impact on the whole. On the other hand, an application on that organization’s shared web infrastructure with a vulnerability that breached the tiered protections could open a disastrous hole, even if completely insignificant. (I did prevent an application from doing exactly that in another, unrelated, review.)
It should be apparent that organizations willing to take a great deal of risk as a general part of their approach will necessarily be willing to lose systems. A security architect providing security controls for systems being deployed by such an organiza- tion needs to understand what risks the organization is willing to take. I offer as an example a business model that typically interacts with its customers exactly one single time. In such a model, the business may not care if customers are harmed through their business systems. Cross-site scripting (XSS) is typically an attack through a web system against the users of the system. In this business model, the owners of the system may not care that some percentage of their customers get attacked, since the organization won’t interact with these customers again; they have no need for customer loyalty.*
On the other hand, if the business model requires the retention, loyalty, and good- will of as many customers as possible, then having one’s customers get attacked because of flaws in one’s commerce systems is probably not a risk worth taking. I use these two polar examples to illustrate how the organization’s operational model influences its risk stance. And, the risk tolerance of the organization significantly influences how much security is required to protect its systems.
How does one uncover the risk tolerance of an organization? The obvious answer is to simply ask. In organizations that have sophisticated and/or mature risk management
* I do not mean to suggest that ignoring your customers’ safety is a particularly moral stance. My own code entreats me to “do no harm.” However, I can readily imagine types of businesses that don’t require the continuing goodwill of their customers.
The Art of Security Assessment 47
practices, it may be a matter of simply asking the right team or group. However, for any organization that doesn’t have this information readily available, some investigation is required. As in the case with the project manager whose project was purely experimen- tal and easily lost, simply asking, “What is the net effect of losing the data in the sys- tem?” may be sufficient. But in situations where the development team hasn’t thought about this issue, the most likely people to understand the question in the broader orga- nizational sense will be those who are responsible and accountable. In a commercial organization, this may be senior management, for instance, a general manager for a division, and others in similar positions. In organizations with less hierarchy, this may be a discussion among all the leaders—technical, management, whoever’s responsible, or whoever takes responsibility for the success of the organization.
Although organizational risk assessment is beyond the scope of this book, one can get a good feel simply by asking pointed questions:
• How much are we willing to lose? • What loss would mean the end of the organization? • What losses can this organization sustain? And for how long? • What data and systems are key to delivering the organizational mission? • Could we make up for the loss of key systems through alternate means? For how
long can we exist using alternate means?
These and similar questions are likely to seed informative conversations that will give the analyst a better sense of just how much risk and of what sort the organization is willing to tolerate.
As an example, for a long time, an organization at which I worked was willing to tolerate accumulating risk through its thousands of web applications. For most of these applications, loss of any particular one of them would not degrade the overall enterprise significantly. While the aggregate risk continued to increase, each risk owner, usually a director or vice president, was willing to tolerate this isolated risk for their particular function. No one in senior management was willing to think about the aggregate risk that was being accumulated. Then, a nasty compromise and breach occurred. This highlighted the pile of unmitigated risk that had accumulated. At this point, executive management decided that the accumulated risk pile needed to be addressed; we were carrying too much technology debt above and beyond the risk tolerance of the organi- zation. Sometimes, it takes a crisis in order to fully understand the implications for the organization. As quoted earlier, in Chapter 1, “Never waste a crisis.”12 The short of it is, it’s hard to build the right security if you don’t know what “secure enough” is. Time spent fact finding can be very enlightening.
With security posture and risk tolerance of the overall organization in hand, spe- cific questions about specific systems can be placed within that overall tolerance. The questions are more or less the same as listed above. One can simply change the word “organization” to “system under discussion.”
48 Securing Systems
There is one additional question that should be added to our list: “What is the high- est sensitivity of the data handled by the system?” Most organizations with any security maturity at all will have developed a data-sensitivity classification policy and scale. These usually run from public (available to the world) to secret (need-to-know basis only). There are many variations on these policies and systems, from only two classifications to as many as six or seven. An important element for protecting the organi zation’s data is to understand how restricted the access to particular data within a particular system needs to be. It is useful to ask for the highest sensitivity of data since controls will have to be fit for that, irrespective of other, lower classification data that is processed or stored.
Different systems require different levels of security. A “one-size-fits-all” approach is likely to lead to over specifying some systems. Or it may lead to under specifying most systems, especially key, critical systems. Understanding the system risk tolerance and the sensitivity of the data being held are key to building the correct security.
For large information technology (IT) organizations, economies of scale are typi- cally achieved by treating as many systems as possible in the same way, with the same processes, with the same infrastructure, with as few barriers between information flow as possible. In the “good old days” of information security, when network restrictions ruled all, this approach may have made some sense. Many of the attacks of the time were at the network and the endpoint. Sophisticated application attacks, combination attacks, persistent attacks, and the like were extremely rare. The castle walls and the perimeter controls were strong enough. Security could be served by enclosing and iso- lating the entire network. Information within the “castle” could flow freely. There were only a few tightly controlled ingress and egress points.
Those days are long gone. Most organizations are so highly cross-connected that we live in an age of information ecosystems rather than isolated castles and digital city- states. I don’t mean to suggest that perimeter controls are useless or passé. They are one part of a defense-in-depth. But in large organizations, certainly, there are likely to be several, if not many, connections to third parties, some of whom maintain radically different security postures. And, on any particular day, there are quite likely to be any number of people whose interests are not the same as the organization’s but who’ve been given internal access of one kind or another.
Added to highly cross-connected organizations, many people own many connecting devices. The “consumerization” of IT has opened the trusted network to devices that are owned and not at all controlled by the IT security department. Hence, we don’t know what applications are running on what devices that may be connecting (through open exchanges like HTTP/HTML) to what applications. We can authen ticate and autho- rize the user. But from how safe a device is the user connecting? Generally, today, it is safer to assume that some number of the devices accessing the organization’s network and resources are already compromised. That is a very different picture from the highly restricted networks of the past.
National Cyber Security Award winner Michelle Guel has been touting “islands of security” for years now. Place the security around that which needs it rather than
The Art of Security Assessment 49
trusting the entire castle. As I wrote above, it’s pretty simple: Different systems require different security postures. Remember, always, that one system’s security posture affects all the other systems’ security posture in any shared environment.
What is a security posture?
Security posture is the overall capability of the security organization to assess its unique risk areas and to implement security measures that would protect against exploitation.13
If we replace “organization” with “system,” we are close to a definition of a system’s security posture. According to Michael Fey’s definition, quoted above, an architecture analysis for security is a part of the security posture of the system (replacing “organi- zation” with “system”). But is the analysis to determine system posture a part of that posture? I would argue, “No.” At least within the context of this book, the analysis is outside the posture. If the analysis is to be taken as a part of the posture, then sim- ply performing the analysis will change the posture of the system. And our working approach is that the point of the analysis is to determine the current posture of the system and then to bring the system’s posture to a desired, intended state. If we then rework the definition, we have something like the following:
System security posture: The unique risk areas of a system against which to implement security measures that will protect against exploitation of the system.
Notice that our working definition includes both risk areas and security measures. It is the sum total of these that constitute a “security posture.” A posture includes both risk and protection. Once again, “no risk” doesn’t exist. Neither does “no protection,” as most modern operating environments have some protections in-built. Thus, posture must include the risks, the risk mitigations, and any residual risk that remains unpro- tected. The point of an ARA—the point of securing systems—is to bring a system to an intended security posture, the security posture that matches the risk tolerance of the organization and protects against those threats that are relevant to that system and its data.
Hence, one must ascertain what’s needed for the system that’s under analysis. The answers that you will collect to the risk questions posed above point in the right direc- tion. An analysis aims to discover the existing security posture of a system and to cal- culate through some risk-based method, the likely threats and attack scenarios. It then requires those controls that will bring the system to the intended security posture.
The business model (or similar mission of system owners) is deeply tied into the desired risk posture. Let’s explore some more real-life examples. We’ve already examined a system that was meant to be temporary and experimental. Let’s find a polar opposite, a system that handles financial data for a business that must retain customer loyalty.
In the world of banking, there are many offerings, and competition for customers is fierce. With the growth of online banking services, customers need significant reasons
50 Securing Systems
to bank with the local institution, even if there is only a single bank in town. A friend of mine is a bank manager in a small town of four thousand people, in central California. Even in that town, there are several brick and mortar banks. She vies for the loyalty of her customers with personal services and through paying close attention to individual needs and the town’s overall economic concerns.
Obviously, a front-end banking system available to the Internet may not be able to offer the human touch that my friend can tender to her customers. Hopefully, you still agree that loyalty is won, not guaranteed? Part of that loyalty will be the demonstration, over time, that deposits are safely held, that each customer’s information is secure.
Beyond the customer-retention imperative, in most countries, banks are subject to a host of regulations, some of which require and specify security. The regulatory picture will influence the business’ risk posture, alongside its business imperatives. Any system deployed by the bank for its customers will have to have a security posture sufficient for customer confidence and that meets jurisdictional regulations, as well.*
As we have noted, any system connected to the Public Internet is guaranteed to be attacked, to be severely tested continuously. Financial institutions, as we have already examined, will be targeted by cyber criminals. This gives us our first posture clue: The system will have to have sufficient defense to resist this constant level of attack, some of which will be targeted and perhaps sophisticated.
But we also know that our customers are targets and their deposits are targeted. These are two separate goals: to gain, through our system, the customers’ equipment and data (on their endpoint). And, at the same time, some attackers will be targeting the funds held in trust. Hence, this system must do all that it can to prevent its use to attack our customers. And, we must protect the customers’ funds and data; an ideal would be to protect “like a safety deposit box.”
Security requirements for an online bank might include demilitarized zone (DMZ) hardening, administration restrictions, protective firewall tiers between HTTP termi- nations, application code and the databases to support the application, robust authen- tication and authorization systems (which mustn’t be exposed to the Internet, but only to the systems that need to authenticate), input validation (to prevent input validation errors), stored procedures (to prevent SQL injection errors), and so forth. As you can see, the list is quite extensive. And I have not listed everything that I would expect for this system, only the most obvious.
If the bank chose to outsource the system and its operations, then the chosen vendor would have to demonstrate all of the above and more, not just once, but repeatedly through time.
Given these different types of systems, perhaps you are beginning to comprehend why the analysis can only move forward successfully with both the organization posture
* I don’t mean to reduce banking to two imperatives. I’m not a banking security expert. And, online banking is beyond our scope. I’ve reduced the complexity, as an example.
The Art of Security Assessment 51
and the system posture understood? The bank’s internal company portal through which employees get the current company news and access various employee services, would, however, have a different security posture. The human resources (HR) system may have significant security needs, but the press release feed may have signi ficantly less. Certainly, the company will prefer not to have fake news posted. Fake company news postings may have a much less significant impact on the bank than losing the account holdings of 30% of the banks customers?
Before analysis, one needs to have a good understanding of the shared services that are available, and how a security posture may be shared across systems in any particular environment. With the required system risk posture and risk tolerance in hand, one may proceed with the next steps of the syste m analysis.
2.6 Getting Started
Before I can begin to effectively analyze systems for an organization, I read the security policy and standards. This gives me a reasonable feel for how the organization approaches security. Then, I speak with leaders about the risks they are willing to take, and those that they cannot—business risks that seem to have nothing to do with computers may still be quite enlightening. I further query technical leaders about the security that they think systems have and that systems require.
I then spend time learning the infrastructure—how it’s implemented, who admin- isters it, the processes in place to grant access, the organization’s approach to security layers, monitoring, and event analysis. Who performs these tasks, with what technol- ogy help, and under what response timing (“SLA”). In other words, what security is already in place and how does a system inherit that security?
My investigations help me understand the difference between past organization expectations and current ones. These help me to separate my sense of appropriate secu- rity from that of the organization. Although I may be paid to be an expert, I’m also paid to execute the organization’s mission, not my own. As we shall see, a big part of risk is separating my risk tolerance from the desired risk tolerance.
Once I have a feel for the background knowledge sets listed in this introduction, then I’m ready to start looking at systems. I try to remember that I’ll learn more as I analyze. Many assessments are like peeling an onion: I test my understandings with the stakeholders. If I’m off base or I’ve missed something substantive, the stakeholders will correct me. I may check each “fact” as I believe that I’ve come to understand something about the system. There are a lot of questions. I need to be absolutely cer- tain of every relevant thing that can be known at the time of the assessment. I reach for absolute technical certainty. Through the process, my understanding will mature about each system under consideration and about the surrounding and supporting environment. As always, I will make mistakes; for these, I prepare myself and I prepare the organization.
52 Securing Systems
1. Oxford Dictionary of English. (2010). 3rd ed. UK: Oxford University Press. 2. Buschmann, F., Henney, K., and Schmidt, D. C. (2007). “Foreword.” In Pattern-Oriented
Software Architecture: On Patterns and Pattern Languages. Vol. 5. John Wiley & Sons. 3. Rosenquist, M. (2009). “Prioritizing Information Security Risks with Th reat Agent
Risk Assessment.” IT@Intel White Paper, Intel Information Technology. Retrieved from http://media10.connectedsocialmedia.com/intel/10/5725/Intel_IT_Business_Value_ Prioritizing_Info_Security_Risks_with_TARA.pdf.
4. Schoenfi eld, 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.
5. Harris, K. D. (2014). “Cybersecurity in the Golden State.” California Department of Justice.
6. Alperovitch, D. (2011-08-02). “Revealed: Operation Shady RAT.” McAfee, Inc. White Paper.
7. Ibid. 8. Global Th reat Report 2013 YEAR IN REVIEW, Crowdstrike, 2013. Available at:
9. Bright, P., Anderson, N., and Cheng, J. (2011). Unmasked. Amazon Kindle. Retrieved from http://www.amazon.com/Unmasked-Peter-Bright.
10. Reitman, J. (Dec. 7, 2012). “Th e Rise and Fall of Jeremy Hammond: Enemy of the State.” Rolling Stone Magazine. Retrieved from http://www.rollingstone.com/culture/news/ the-rise-and-fall-of-jeremy-hammond-enemy-of-the-state-20121207.
11. Sherwood, J., Clark, A., and Lynas, D. “Enterprise Security Architecture.” SABSA White Paper, SABSA Limited, 1995–2009. Retrieved from http://www.sabsa-institute.com/ members/sites/default/inline-fi les/SABSA_White_Paper.pdf.
12. Arkin, B. (2012). “Never Waste a Crisis – Necessity Drives Software Security.” RSA Conference 2012, San Francisco, CA, February 29, 2012. Retrieved from http://www.rsaconference. com/events/us12/agenda/sessions/794/never-waste-a-crisis-necessity-drives-software.
13. Fey, M., Kenyon, B., Reardon, K. T., Rogers, B., and Ross, C. (2012). “Assessing Mission Readiness” (Ch. 2). In Security Battleground: An Executive Field Manual. Intel Press.
Security Architecture of Systems
A survey of 7,000 years of history of human kind would conclude that the only known strategy for accommodating extreme complexity and high rates of change is architecture. If you can’t describe something, you can’t create it, whether it is an airplane, a hundred storey building, a computer, an automobile . . . or an enterprise. Once you get a complex product created and you want to change it, the basis for change is its descriptive representations.1
If the only viable strategy for handling complex things is the art of architecture, then surely the practice of architecture is key to the practice of security for computers. This is John Zachman’s position in the quote introducing this chapter. The implication found in this quote is that the art of representing a complex system via an abstraction helps us cope with the complexity because it allows us to understand the structure of a thing— for our purposes, computer systems.
Along with a coping strategy for complexity, the practice of architecture gives us a tool for experimenting with change before we actually build the system. This is a pro- found concept that bears some thinking. By creating an abstraction that represents a structure, we can then play with that structure, abstractly. In this way, when encounter- ing change, we can try before we build, in a representative sense.
For a fairly common but perhaps trivial example, what happens when we place the authentication system in our demilitarized zone (DMZ)—that is, in the layer closest to the Internet? What do we have to do to protect the authentication system? Does this placement facilitate authentication in some way? How about if we move the authentica tion system to a tier behind the DMZ, thus, a more trusted zone? What are
54 Securing Systems
the implications of doing so for authentication performance? For security? I’ve had pre- cisely these discussions, more than once, when architecting a web platform. These are discussions about structures; these are architecture discussions.
Computer security is a multivariate, multidimensional field. Hence, by its very nature, computer security meets a test for complexity. Architecture then becomes a tool to apply to that complexity.
Computer security is dynamic; the attackers are adaptive and unpredictable. This dynamism guarantees change alongside the inherent complexity. The complexity of the problem space is mirrored within the complexity of the systems under discussion and the security mechanisms that must be built in order to protect the systems. And as John Zachman suggests in the quote introducing this chapter, complex systems that are going to change require some kind of descriptive map so as to manage the change in an orderly fashion: “the basis for change is its descriptive representations.”2
3.1 Why Is Enterprise Architecture Important?
The field of enterprise architecture supplies a mapping to generate order for a modern, cross-connected digital organization.* I think Pallab Saha sums up the discipline of Enterprise architecture in the following quote. Let this be our working definition for enterprise—that is, an enterprise of “systems”—architecture.
Enterprise architecture (EA) is the discipline of designing enterprises guided with principles, frameworks, methodologies, requirements, tools, reference models, and standards.3
Enterprise architecture is focused on the entire enterprise, not only its digital sys- tems, including the processes and people who will interact, design, and build the sys- tems. An often-quoted adage, “people, process, and technology,” is used to include human, non-digital technology, and digital domains in the enterprise architecture. Enterprise architects are not just concerned with technology. Any process, manual or digital, that contributes to the overall goals of the enterprise, of the entire system taken as a whole, is then, necessarily, a part of the “enterprise architecture.” Thus, a manu- ally executed process will, by definition, include the people who execute that process: “People, process, and technology.”
I’ve thrown around the term “enterprise” since the very beginning of this book. But, I haven’t yet defined it. I’ve found most definitions of “enterprise,” in the sense that it is used here and in enterprise architecture, rather lacking. There’s often some demarcation below which an organization doesn’t meet the test. Yet, the organizations who fail to meet the criteria would still benefit from architecture, perhaps enterprise architecture, certainly enterprise security architecture. Consider the following criteria:
* Large business organizations are often called “enterprises.”
Security Architecture of Systems 55
• Greater than 5000 employees (10,000? 50,000? 100,000?) • Greater than $1 billion in sales ($2 billion? $5 billion? $10 billion?) • Fortune 1000 company (Fortune 500? Fortune 100? Fortune 50?)
Each of these measures presumes a for-profit goal. That leaves out non- governmental organizations (NGOs) and perhaps governments.
A dictionary definition also doesn’t seem sufficient to our purpose:
[A] unit of economic organization or activity; especially : a business organization4
For the purposes of this book, I will offer a working definition not meant for any purposes but my own:
Enterprise: An organization whose breadth and depth of activities cannot easily be held simultaneously in one’s conscious mind.
That is, for our purposes only, if a person (you? I?) can’t keep the relationships and processes of an organization in mind, it’s probably complex enough to meet our, not very stringent, requirement and, thus, can be called an “enterprise.”
The emphasis here is on complexity. At the risk of forming a tautology, if the orga- nization needs an architecture practice in order to transcend ad hoc and disparate solu- tions to create some semblance of order, then it’s big enough to benefit from enterprise architecture. Our sole concern in this discussion concerns whether or not an organiza- tion may benefit from enterprise architecture as a methodology to provide order and to reap synergies between the organization’s activities. If benefit may be derived from an architectural approach, then we can apply enterprise architecture to the organization, and specifically, a security architecture.
If enterprise architecture is concerned with the structure of the enterprise as a func- tioning system, then enterprise security architecture will be concerned with the secu- rity of the enterprise architecture as a functioning system. We emphasize the subset of enterprise security architecture that focuses on the security of digital systems that are to be used within the enterprise architecture. Often, this more granular architecture prac- tice is known as “solutions” architectu re although, as of this writing, I have not seen the following term applied to security: “solutions security architecture.” The general term, “security architecture,” will need to suffice (though, as has been previously noted, the term “security architecture” is overloaded).
Generally, if there is an enterprise architecture practice in an organization, the enter- prise architecture is a good place from which to start. Systems intended to function within an enterprise architecture should be placed within that overall enterprise struc- ture and will contribute to the working and the goals of the organization. The enterprise architecture then is an abstract, and hopefully ordered, representation of those systems and their interactions. Because the security architecture of the organization is one part of the overarching architecture (or should be!), it is useful for the security architect to
56 Securing Systems
understand and become conversant in architectures at this gross, organizational level of granularity. Hence, I introduce some enterprise architecture concepts in order to place system security assessments within the larger framework in which they may exist.
Still, it’s important to note that most system assessments—that is, architecture risk assessment (ARA) and threat modeling—will take place at the systems or solutions level, not at the enterprise view. Although understanding the enterprise architecture helps to find the correct security posture for systems, the system-oriented pieces of the enterprise security architecture emerge from the individual systems that make up the total enterprise architecture. The caveat to this statement is the security infrastructure into which systems are placed and which those systems consume for security services. The security infrastructure must be one key component of an enterprise architecture. This is why enterprise security architects normally work closely with, and are peers of, the enterprise architects in an organization. Nevertheless, security people charged with the architectural assessment of systems will typically be working at the system or solu- tion level, placing those systems within the enterprise architecture and, thus, within an enterprise security architecture.
Being a successful security architect means thinking in business terms at all times, even when you get down to the real detail and the nuts and bolts of the construction. You always need to have in mind the questions: Why are you doing this? What are you trying to achieve in business terms here?5
In this book, we will take a cursory tour through some enterprise architecture con- cepts as a grounding and path into the practice of security architecture. In our security architecture journey, we can borrow the ordering and semantics of enterprise architecture concepts for our security purposes. Enterprise architecture as a practice has been develop- ing somewhat longer than security architecture.* Its framework is reasonably mature.
An added benefit of adopting enterprise security architecture terminology will then be that the security architect can gently and easily insert him or herself in an organi- zation’s architecture practice without perturbing already in-flight projects and pro- cesses. A security architect who is comfortable interacting within existing and accepted architecture practices will likely be more successful in adding security requirements to an architecture. By using typical enterprise architecture language, it is much easier for non-security architects to accept what may seem like strange concepts—attack vectors and misuse cases, threat analysis and information security risk rating, and so forth. Security concepts can run counter to the goals of the other architects. The bridge
* Th e Open Group off ers a certifi cation for Enterprise Architects. In 2008, I asked several principals of the Open Group about security architecture as a practice. Th ey replied that they weren’t sure such an architecture practice actually existed. Since then, the Open Group has initiated an enterprise security architect certifi cation. So, apparently we’ve now been recognized.
Security Architecture of Systems 57
between security and solution is to understand enterprise and solutions architecture first, and then to build the security picture from those practices.
I would suggest that architecture is the total set of descriptive representations relevant for describing something, anything complex you want to create, which serves as the baseline for change if you ever want to change the thing you have created.6
I think that Zachman’s architecture definition at the beginning of the chapter applies very well to the needs of securing systems. In order to apply information security prin- ciples to a system, that system needs to be describable through a representation—that is, it needs to have an architecture. As Izar Taarandach told me, “if you can’t describe it—it is not time to do security architecture yet.” A security assessment doesn’t have to wait for a completely finished system architecture. Assessment can’t wait for perfec- tion because high-level security requirements need to be discovered early enough to get into the architecture. But Izar is right in that without a system architecture, how does the security architect know what to do? Not to mention that introducing even more change by attempting to build security before sufficient system architecture exists is only going to add more complexity before the structure of the system is understood well enough. Furthermore, given one or more descriptive representations of the system, the person who assesses the system for security will have to understand the representation as intended by the creators of the representation (i.e., the “architects” of the system).
3.2 The “Security” in “Architecture”
The assessor cannot stop at an architectural understanding of the system. This is where security architecture and enterprise, solutions, or systems architects part company. In order to assess for security, the representation must be viewed both as its functioning is intended and, just as importantly, as it may be misused. The system designers are inter- ested in “use cases.” Use cases must be understood by the security architect in the context of the intentions of the system. And, the security architect must generate the “misuse cases” for the system, how the system may be abused for purposes that were not intended and may even run counter to the goals of the organization sponsoring the system.
An assessor (usually a security architect) must then be proficient in architecture in order to understand and manipulate system architectures. In addition, the security architect also brings substantial specialized knowledge to the practice of security assess- ment. Hence, we start with solutions or systems architectures and their representations and then apply security to them.
This set of descriptive representations thereby becomes the basis for describing the security needs of the system. If the security needs are not yet built, they will cause a “change” to the system, as explained in Zachman’s definition describing architecture as providing a “baseline for change” (see above).7
58 Securing Systems
Let me suggest a working definition for our purposes that might be something simi- lar to the following:
System architecture is the descriptive representation of the system’s component functions and the communication* flows between those components.
My definition immediately raises some important questions.
• What are “components”? • Which functions are relevant? • What is a communication flow?
It is precisely these questions that the security architect must answer in order to understand a system architecture well enough to enumerate the system’s attack sur- faces. Ultimately, we are interested in attack surfaces and the risk treatments that will protect them. However, the discovery of attack surfaces is not quite as straightforward a problem as we might like. Deployment models, runtime environments, user expecta- tions, and the like greatly influence the level of detail at which a system architecture will need to be examined. Like computer security itself, the architectural representation is the product of a multivariate, complex problem. We will examine this problem in some detail.
Mario Godinez et al. (2010)8 categorize architectures into several different layers, as follows:
• Conceptual Level—This level is closest to business definitions, business processes, and enterprise standards.
• Logical Level—This level of the Reference Architecture translates conceptual design into logical design.
• Physical Level—This level of the Reference Architecture translates the logical design into physical structures and often products.
The Logical Level is broken down by Godinez et al. (2010) into two interlocking and contributing sub-models:
ο Logical Architecture—The Logical Architecture shows the relationships of the different data domains and functionalities required to manage each type of information.
* I use “communication fl ow” because, sometimes, people forget those communications between systems that aren’t considered “data” connections. In order to communicate, digital entities need to exchange data. So, essentially, all communication fl ows are data fl ows. In this context we don’t want to constrain ourselves to common conceptions of data fl ows, but rather, all exchange of bits between one function and another.
Security Architecture of Systems 59
ο Component Model—Technical capabilities and the architecture building blocks that execute them are used to delineate the Component Model.9
For complex systems, and particularly at the enterprise architecture level, a single repre sentation will never be sufficient. Any attempt at a complete representation is likely to be far too “noisy” to be useful to any particular audience: There are too many possible representations, too many details, and too many audiences. Each “audience”—that is, each stakeholder group—has unique needs that must be reflected in a representation of the system. Organizational leaders (senior management, typically) need to understand how the organization’s goals will be carried out through the system. This view is very different from what is required by network architects building a network infrastructure to support the system. As we shall see, what the security architect needs is also different, though hopefully not entirely unique. Due to these factors, the practice of enterprise architecture creates different views representing the same architecture.
For the purposes of security evaluation, we are concerned primarily with the Logical Level—both the logical architecture and component model. Often, the logical archi- tecture, the different domains and functionalities, as well as the component model, are superimposed upon the same system architecture diagram. For simplicity, we will call this the “logical system architecture.” The most useful system architecture diagram will contain sufficient logical separation to represent the workings of the system and the differing domains. And the diagram should explain the component model sufficiently such that the logical functions can be tied to technical components.
Security controls tend to be “point”—that is, they implement a single function that will then be paired to one or more attack vectors. The mapping is not one-to-one, vec- tor to control or control to attack method. The associations are much looser (we will examine this in greater detail later). Due to the lack of absolute coherence between the controls that can be implemented and the attack vectors, the technical components are essential for understanding just precisely which controls can be implemented and which will contribute towards the intended defense-in-depth.
Eventually, any security services that a system consumes or implements will, of course, have to be designed at the physical level. Physical servers, routers, firewalls, and monitoring systems will have to be built. But these are usually dealt with logically, first, leaving the physical implementation until the logical and component architectures are thoroughly worked out. The details of firewall physical implementation often aren’t important during the logical security analysis of a system, so long as the logical controls produce the tiers and restrictions, as required. Eventually, the details will have to be decided upon, as well, of course.
3.3 Diagramming For Security Analysis
Circles and arrows leave one free to describe the interrelationships between things in a way that tables, for example, do not.10
60 Securing Systems
It may be of help to step back from our problem (assessing systems for security) to examine different ways in which computer systems are described visually. The archi- tecture diagram is a critical prerequisite for most architects to conduct an assessment. What does an architecture diagram look like?
In Figure 3.1, I have presented a diagram of an “architecture” that strongly resem- bles a diagram that I once received from a team.* The diagram does show something of the system: There is some sort of interaction between a user’s computer and a server. The server interacts with another set of servers in some manner. So there are obviously at least three different components involved. The brick wall is a standard representation of a firewall. Apparently, there’s some kind of security control between the user and the middle server. Because the arrows are double headed, we don’t know which component calls the others. It is just as likely that the servers on the far right call the middle server as the other way around. The diagram doesn’t show us enough specificity to begin to think about trust boundaries. And, are the two servers on the right in the same trust area? The same network? Or are they separated in some manner? We don’t know from this diagram. How are these servers managed? Are they managed by a professional, security-conscious team? Or are they under someone’s desk, a pilot project that has gone live without any sort of administrative security practice? We don’t know if these are web and database protocols or something else. We also do not know anything about the firewall. Is it stateful? Deep packet inspection? A web application firewall (WAF)? Or merely a router with an Access Control List (ACL) applied?
An astute architect might simply make queries about each of these facets (and more). Or the architect might request more details in order to help the team create a diagram with just a little bit more specificity.
I include Figure 3.2 because although this diagram may enhance the sales of a product, it doesn’t tell us very much about those things with which we must deal. This diagram is loosely based upon the “architecture” diagram that I received from a busi- ness data processing product† that I was reviewing. What is being communicated by the diagram, and what is needed for an assessment?
Figure 3.1 A simplistic Web architecture diagram.
* Figure 3.1 includes no references that might endanger or otherwise identify a running system at any of my former or current employers.
† Although based upon similar concepts, this diagram is entirely original. Any resemblance to an existing product is purely coincidental.
Security Architecture of Systems 61
From Figure 3.2, we know that, somehow, a “warehouse” (whatever that is) commu- nicates with data sources. And presumably, the application foundation supports various higher-level functions? This may be very interesting for someone buying the product. However, this diagram does not give us sufficient information about any of the compo- nents for us to begin to identify attack surfaces, which is the point of a security analysis. The diagram is too high level, and the components displayed are not tied to things that we can protect, such as applications, platforms, databases, applications, and so forth.
Even though we understand, by studying Figure 3.2, that there’s some sort of “appli- cation platform”—an operating environment that might call various modules that are being considered as “applications”—we do not know what that execution entails, whether “application” in this diagram should be considered as atomic, with attack sur- faces exposed, or whether this is simply a functional nomenclature to express func- tionality about which customers will have some interest. Operating systems provide application execution. But so do “application servers.” Each of these presents rather dif- ferent attack possibilities. An analysis of this “architecture” could not proceed without more specificity about program execution.
In this case, the real product’s platform was actually a Java web application server (a well-known version), with proprietary code running within the application server’s usual web application runtime. The actual applications were packaged as J2EE serve- lets. That means that custom code was running within a well-defined and publicly available specification. The diagram that the vendor had given to me did not give me much useful information; one could not even tell how “sources” were accessed, for what
Figure 3.2 Marketing architecture for a business intelligence product.
62 Securing Systems
operations (Read only? Write? Execute?). And which side, warehouse or source, initiated the connection? From the diagram, it was impossible to know. Do the source commu- nications require credentials? How might credentials be stored and protected? We don’t have a clue from the diagram that authentication by each source is even supported.
[T]he System Context Diagram . . . is a methodological approach to assist in the detailing of the conceptual architecture all the way down to the Operational Model step by step and phase by phase.11
As may be seen from the foregoing explanation, the diagram in Figure 3.2 was quite insufficient for the purposes of a security assessment. In fact, neither of these diagrams (Figures 3.1 or 3.2) meets Zachman’s definition, “the total set of descriptive representa- tions relevant for describing something.”12 Nor would either of these diagrams suitably describe “all the way down to the Operational Model step by step.”13 Each of these diagrams describes some of the system in an incomplete way, not only for the purposes of security assessment, but incomplete in a more general architectural sense, as well. Figures 3.1 and 3.2 may very well be sufficient for other purposes beyond general sys- tem architecture or security architecture. My point is that these representations were
Figure 3.3 Sample external web architecture.14 (Courtesy of the SANS Institute.)
Security Architecture of Systems 63
insufficient for the kind of analysis about which this book is written. Since systems vary so tremendously, it is difficult to provide a template for a system architecture that is relevant across the extant variety and complexity. Still, a couple of examples may help?
Figure 3.3 is reproduced from an ISA Smart Guide that I wrote to explain how to securely allow HTTP traffic to be processed by internal resources that were not originally designed to be exposed to the constant attack levels of the Internet. The diagram was not intended for architecture analysis. However, unlike Figure 3.1, several trust-level boundaries are clearly delineated. Internet traffic must pass a firewall before HTTP/S traffic is terminated at a web server. The web server is separated by a second firewall from the application server. Finally, there is a third firewall between the entire DMZ network and the internal networks (the cloud in the lower right-hand corner of the diagram).
Further, in Figure 3.3, it is clear that only Structured Query Language (SQL) traf- fic will be allowed from the application server to internal databases. The SQL traffic originates at the application server and terminates at the internal databases. No other traffic from the DMZ is allowed onto internal networks. The other resources within the internal cloud do not receive traffic from the DMZ.
Figure 3.3 is still too high level for analyzing the infrastructure and runtime of the components. We don’t know what kind of web server, application server, or database may be implemented. Still, we have a far better idea about the general layout of the architecture than from, say, Figure 3.1. We certainly know that HTTP and some vari- ant of SQL protocols are being used. The system supports HTTPS (encrypted HTTP) up to the first firewall. But communications are not encrypted from that firewall to the web server. From Figure 3.3, we can tell that the SSL/TLS tunnel is terminated at the first firewall. The diagram clearly demonstrates that it is HTTP past the firewall into the DMZ.
We know where the protocols originate and terminate. We can surmise boundaries of trust* from highly exposed to internally protected. We know that there are functional tiers. We also know that external users will be involved. Since it’s HTTP, we know that those users will employ some sort of browser or browser-like functionality. Finally, we know that the infrastructure demarks a formal DMZ, which is generally restricted from the internal network.
The security architect needs to understand bits of functionality that can be treated relatively independently. Unity of any particular piece of the architecture we’ll call “atomic.” The term “atomic” has a fairly specific meaning in some computer contexts. It is the third Oxford Dictionary definition of atomic that applies to the art of secur- ing systems:
* “Boundaries” in this context is about levels of exposure of networks and systems to hostile networks, from exposed to protected. Th ese are usually called “trust boundaries.” It is gener- ally assumed that as a segment moves closer to the Internet the less it is trusted. Well protected from external traffi c has higher trust. We will examine boundaries in greater detail, later.
64 Securing Systems
[O]f or forming a single irreducible unit or component in a larger system15
“Irreducible” in our context is almost never true, until one gets down to the indivi- dual line of code. Even then, is the irreducible unit a single binary computer instruc- tion? Probably. But we don’t have to answer this question,* as we work toward the “right” level of “single unit.” In the context of security assessments of systems, “atomic” may be taken as treat as irreducible or regard as a “unit or component in a larger system.”16
In this way, the security architect has a requirement for abstraction that is different from most of the other architects working on a system. As we shall see further along, we reduce to a unit that presents the relevant attack surfaces. The reduction is dependent on other factors in an assessment, which were enumerated earlier:
• Active threat agents that attack similar systems • Infrastructure security capabilities • Expected deployment model • Distribution of executables or other deployable units • The computer programming languages that have been used • Relevant operating system(s) and runtime or execution environment(s)
This list is essentially synonymous with the assessment “background” knowledge, or pre-assessment “homework” that has already been detailed. Unfortunately, there is no single architecture view that can be applied to every component of every system. “Logical” and “Component” are the most typical.
Depending upon on the security architect role that is described, one of two likely situations prevail: 1. The security architect must integrate into existing architecture practices, making
use of whatever architecture views other architects are creating. 2 The security architect is expected to produce a “security view” of each architec-
ture that is assessed.†
In the first case, where the organization expects integration, essentially, the assessor is going to “get what’s on offer” and make do. One can attempt to drive artifacts to some useful level of detail, as necessary. When in this situation, I take a lot of notes about the architecture because the diagrams offered are often incomplete for my purposes.
The second case is perhaps the luxury case? Given sufficient time, producing both an adequate logical and component architecture, and then overlaying a threat model onto them, delivers a working document that the entire team may consider as they
* I cannot remember a single instance of needing to go down to the assembly or binary code level during a review.
† Th e author has personally worked under each of these assumptions.
Security Architecture of Systems 65
architect, design, code, and test. Such an artifact (diagram, or better, layered diagram) can “seed” creative security involvement of the entire team.
Eoin Carroll, when he worked as a Senior Quality Engineer at McAfee, Inc., inno- vated exactly this practice. Security became embedded into Agile team consideration to the benefit of everyone involved with these teams and to the benefit of “building security in from the start.” As new features were designed,* teams were able to consider the security implications of the feature and the intended design before coding, or while iterating through possible algorithmic solutions.
If the security architect is highly shared across many teams, he or she will likely not have sufficient time to spend on any extensive diagramming. In this situation, because diagramming takes considerable time to do well, diagramming a security architecture view may be precluded.
And, there is the danger that the effort expended to render a security architecture may be wasted, if a heavyweight document is only used by the security architect dur- ing the assessment. Although it may be useful to archive a record of what has been considered during the assessment, those building programs will want to consider cost versus benefit carefully before mandating that there be a diagrammatic record of every assessment. I have seen drawings on a white board, and thus, entirely ephemeral, suffice for highly complex system analysis. Ultimately, the basic need is to uncover the security needs of the system—the “security requirements.”
The decision about exactly which artifacts are required and for whose consumption is necessarily an organizational choice. Suffice it to note that, in some manner, the secu- rity architect who is performing a system analysis will require enough detail to uncover all the attack surfaces, but no more detail than that. We will explore “decomposing” and “factoring” architectures at some length, below. After our exploration, I will offer a few guidelines to the art of decomposing an architecture for security analysis.
Let’s turn our attention for a moment to the “mental” game involved in understand- ing an architecture in order to assess the architecture for security.
It has also been said that architecture is a practice of applying patterns. Security pat- terns are unique problems that can be described as arising within disparate systems and whose solutions can be described architecturally (as a representation).
Patterns provide us with a vocabulary to express architectural visions, as well as examples of representative designs and detailed implementations that are clear and to the point. Presenting pieces of software in terms of their constituent patterns also allows us to communicate more effectively, with fewer words and less ambiguity.17
For instance, the need for authentication occurs not just between users, but wherever in a software architecture a trust boundary occurs. This can be between eCommerce
* In SCRUM Agile, that point in the process when user stories are pulled from the backlog for implementation during a Sprint.
66 Securing Systems
tiers (say, web to application server) or between privilege boundaries among executables running on top of an operating system on a computer. The pattern named here is the requirement of proof that the calling entity is not a rogue system, perhaps under control of an attacker (say, authentication before allowing automated interactions). At a very gross level, ensuring some level of trust on either side of a boundary is an authentication pattern. However, we can move downwards in specificity by one level and say that all tiers within a web stack are trust boundaries that should be authenticated. The usual authentication is either bidirectional or the less trusted system authenticates to those of higher trust. Similarly, any code that might allow attacker access to code running at a higher privilege level, especially across executable boundaries, presents this same authentication pattern.
That is, entities at higher trust levels should authenticate communication flows from entities of lower trust. Doing so prevents an attacker from pretending to be, that is, “spoofing,” the lower trust entity. “Entity” in this discussion is both a web tier and an exe- cutable process. The same pattern expresses itself in two seemingly disparate archite ctures.
Figure 3.4 represents the logical Web architecture for the Java application develop- ment environment called “AppMaker.”* AppMaker produces dynamic web applications without custom coding by a web developer. The AppMaker application provides a plat-
Figure 3.4 AppMaker Web architecture.
* AppMaker is not an existing product. Th ere are many off erings for producing web applica- tions with little or no coding. Th is example demonstrates a typical application server and database architecture.
Security Architecture of Systems 67
form for creating dynamic web applications drawing data from a database, as needed, to respond to HTTP requests from a user’s browser. For our purposes, this architecture represents a classic pattern for a static content plus dynamic content web application. Through this example, we can explore the various logical components and tiers of a typical web application that also includes a database.
The AppMaker architecture shows a series of arrows representing how a typical HTTP request will be handled by the system. Because there are two different flows, one to return static content, and an alternate path for dynamic content built up out of the data- base, the return HTTP response flow is shown (“5” from database server to AppMaker, and then from AppMaker through the webserver). Because there are two possible flows in this logical architecture, there is an arrow for each of the two response flows.
Quite often, an HTTP response will be assumed; an architecture diagram would only show the incoming request. If the system is functioning normally, it will generate a response; an HTTP response can be assumed. HTTP is a request/response protocol.
But in this case, the program designers want potential implementers to understand that there are two possible avenues for delivering a response: a static path and a dynamic path. Hence, you can see “2a” being retrieved from the disk available to the Web server (marked “Static Content”). That’s the static repository.
Dynamic requests (or portions of requests) are delivered to the AppMaker web application, which is incoming arrow “2b” going from the Web server to the applica- tion server in the diagram. After generating the dynamic response through interactions with custom code, forms, and a database server (arrows 3 and 4), the response is sent back in the outgoing arrows, “5.”
Digging a little further into Figure 3.4, you may note that there are four logical tiers. Obviously, the browser is the user space in the system. You will often hear secu- rity architects exclude the browser when naming application tiers, whereas the browser application designers will consider the browser to be an additional web application tier, for their purposes. Inclusion of the browser as a tier of the web application is especially common when there is scripting or other application-specific code that is downloaded to the browser, and, thus, a portion of the system is running in the context of the user’s browser. In any case, whether considering the browser as a tier in the architecture or not, the user’s browser initiates a request to the web application, regardless of whether there is server-supplied code running in the browser.
This opposing viewpoint is a function of what can be trusted and what can be pro- tected in a typical Web application. The browser must always be considered “untrusted.” There is no way for a web application to know whether the browser has been compro- mised or not. There is no way for a web application to confirm that the data sent as HTTP requests is not under the control of an attacker.* By the way, authentication of the user only reduces the attack surface. There is still no way to guarantee that an
* Likewise, a server may be compromised, thus sending attacks to the user’s browser. From the user’s perspective, the web application might be considered untrusted.
68 Securing Systems
attacker hasn’t previously taken over the user’s session or is otherwise misusing a user’s login credentials.
Manipulating the variables in the URL is simple. But attackers can also manipulate almost all information going from the client to the server like form fields, hidden fields, content-length, session-id and http methods.18
Due to the essential distrust of everything coming into any Web application, security architects are likely to discount the browser as a valid tier of the application. Basically, there is very little that a web application designer can do to enhance the protection of the web browsers. That is not to say that there aren’t applications and security controls that can’t be applied to web browser; there most certainly are. Numerous security ven- dors offer just such protections. However, for a web application that must serve content to a broad population, there can be no guarantees of browser protection; there are no guarantees that the browser hasn’t already been compromised or controlled by an attacker. Therefore, from a security perspective, the browser is often considered outside the defensible perimeter of a web application or web system. While in this explanation we will follow that customary usage, it must be noted that there certainly are applica- tions where the browser would be considered to lie within the perimeter of the web application. In this case, the browser would then be considered as the user tier of the system.
Returning then to Figure 3.4, from a defensible perimeter standpoint, and from the standpoint of a typical security architect, we have a three-tier application:
1. Web server 2. Application server 3. Database
For this architecture, the Web server tier includes disk storage. Static content to be served by the system resides in this forward most layer. Next, further back in the sys- tem, where it is not directly exposed to HTTP-based attacks (which presumably will be aimed at the Web server?), there is an application server that runs dynamic code. We don’t know from this diagram what protocol is used between the Web server and the application server. We do know that messages bound for the application server originate at the Web server. The arrow pointing from the Web server to the application server clearly demonstrates this. Finally, as requests are processed, the application server inter- acts with the database server to construct responses. Figure 3.4 does not specify what protocol is used to interact with the database. However, database storage is shown as a separate component from the database server. This probably means that storage can be separated from the actual database application code, which could indicate an additional tier, if so desired.
What security information can be harvested from Figure 3.4? Where are the obvious attack surfaces? Which is the least-trusted tier? Where would you surmise that the
Security Architecture of Systems 69
greatest trust resides? Where would you put security controls? You will note that no security boundaries are depicted in the AppMaker logical architecture.
In Chapter 6, we will apply our architecture assessment and threat modeling methodology to this architecture in an attempt to answer these questions.
Figure 3.5 represents a completely different type of architecture compared to a web application. In this case, there are only two components (I’ve purposely simplified the architecture): a user interface (UI) and a kernel driver. The entire application resides on some sort of independent computing device (often called an “endpoint”). Although a standard desktop computer is shown, this type of architecture shows up on laptops, mobile devices, and all sorts of different endpoint types that can be generalized to most operating systems. The separation of the UI from a higher privileged system function is a classic architecture pattern that crops up again and again.
Under most operating systems where there is some user-accessible component that then opens and perhaps controls a system level piece of code, such as a kernel driver, the kernel portion of the application will run at a higher privilege level than the user inter- face. The user interface will run at whatever privilege level the logged-in user’s account runs. Generally, pieces of code that run as part of the kernel have to have access to all system resources and must run at a much higher privilege level, usually the highest privilege level available under the operating system. The bus, kernel drivers, and the like are valuable targets for attackers. Once an attacker can insert him or herself into the kernel: “game over.” The attacker has the run of the system to perform whatever actions and achieve whatever goals are intended by the attack. For system takeover, the kernel is the target.
For system takeover, the component presents a valuable and interesting attack sur- face. If the attacker can get at the kernel driver through the user interface (UI) in some
Figure 3.5 Two-component endpoint application and driver.
70 Securing Systems
fashion, then his or her goals will have been achieved. Whatever inputs the UI portion of our architecture presents (represented in Figure 3.5) become critical attack surfaces and must be defended. If Figure 3.5 is a complete architecture, it may describe enough of a logical architecture to begin a threat model. Certainly, the key trust boundary is obvious as the interface between user and system code (kernel driver). We will explore this type of application in somewhat more depth in a subsequent chapter.
3.4 Seeing and Applying Patterns
A pattern is a common and repeating idiom of solution design and architecture. A pattern is defined as a solution to a problem in the context of an application.19
Through patterns, unique solutions convert to common patterns that make the task of applying information security to systems much easier. There are common patterns at a gross level (trust/distrust), and there are recurring patterns with more specificity. Learning and then recognizing these patterns as they occur in systems under assess- ment is a large part of assessing systems for security.
Identifying patterns is a key to understanding system architectures. Understanding an architecture is a prerequisite to assessing that architecture. Remediating the security of an architecture is a practice of applying security architecture patterns to the system patterns found within an architecture. Unique problems generating unique solutions do crop up; one is constantly learning, growing, and maturing one’s security architecture practice. But after a security architect has assessed a few systems, she or he will start to apply security patterns as solutions to architectural patterns.
There are architectural patterns that may be abstracted from specific architectures:
• Standard e-commerce Web tiers • Creating a portal to backend application services • Database as the point of integration between disparate functions • Message bus as the point of integration between disparate functions • Integration through proprietary protocol • Web services for third-party integration • Service-oriented architecture (SOA) • Federated authentication [usually Security Assertion Markup Language (SAML)] • Web authentication validation using a session token • Employing a kernel driver to capture or alter system traffic • Model–view–controller (MVC) • Separation of presentation from business logic • JavaBeans for reusable components • Automated process orchestration • And more
Security Architecture of Systems 71
There are literally hundreds of patterns that repeat, architecture to architecture. The above list should be considered as only a small sample.
As one becomes familiar with various patterns, they begin to “pop out,” become obvious. An experienced architect builds solutions from these well-known patterns. Exactly which patterns will become usable is dependent upon available technologies and infrastructure. Typically, if a task may be accomplished through a known or even implemented pattern, it will be more cost-effective than having to build an entirely new technology. Generally, there has to be a strong business and technological motivation to ignore existing capabilities in favor of building new ones.
Like architectural patterns, security solution patterns also repeat at some level of abstraction. The repeatable security solutions are the security architecture “patterns.” For each of the architectural patterns listed above, there are a series of security controls that are often applied to build a defense-in-depth. A security architect may fairly rapidly recognize a typical architecture pattern for which the security solution is understood. To the uninitiated, this may seem mysterious. In actuality, there’s nothing mysterious about it at all. Typical architectural patterns can be generalized such that the security solution set also becomes typical.
As an example, let’s examine a couple of patterns from the list above.
• Web services for third-party integration: ο Bidirectional, mutual authentication of each party ο Encryption of the authentication exchange ο Encryption of message traffic ο Mutual distrust: Each party should carefully inspect data that are received for
anomalous and out-of-range values (input validation) ο Network restrictions disallowing all but intended parties
• Message bus as a point of integration: ο Authentication of each automated process to the message bus before allowing
further message traffic ο Constraint on message destination such that messages may only flow to
intended destinations (ACL) ο Encryption of message traffic over untrusted networks ο In situations where the message bus crosses the network trust boundaries, access
to the message bus from less-trusted networks should require some form of access grant process
Hopefully, as may be seen, each of the foregoing patterns (listed) has a fairly well- defined security solution set.* When a system architecture is entirely new, of course, the
* Th e security solutions don’t include specifi c technology; the implementation is undefi ned— lack of specifi city is purposive at this level of abstraction. In order to be implemented, these requirements will have to be designed with specifi c technologies and particular semantics.
72 Securing Systems
security assessor will need to understand the architecture in a fairly detailed manner (as we will explain in a later chapter). However, architectural patterns repeat over and over again. The assessment process is more efficient and can be done rapidly when repeating architectural patterns are readily recognized. As you assess systems, hopefully, you will begin to notice the patterns that keep recurring?
As you build your catalog of architectural patterns, so you will build your catalog of security solution patterns. In many organizations, the typical security solution sets become the organization’s standards.
I have seen organizations that have sufficient standards (and sufficient infrastructure to support those standards in an organized and efficient manner) to allow designs that strictly follow the standards to bypass security architecture assessment entirely. Even when those standard systems were highly complex, if projects employed the standard architectural patterns to which the appropriate security patterns were applied, then the organization had fairly strong assurance that there was little residual risk inherent in the new or updated system. Hence, the ARA could be skipped. Such behavior is typi- cally a sign of architectural and security maturity. Often (but not always), organizations begin with few or no patterns and little security infrastructure. As time and complex- ity increase, there is an incentive to be more efficient; every system can’t be deployed as a single, one-off case. Treating every system as unique is inefficient. As complexity increases, so does the need to recognize patterns, to apply known solutions, and to make those known solutions standards that can then be followed.
I caution organizations to avoid attempting to build too many standards before the actual system and security patterns have emerged. As has been noted above, there are clas- sic patterns that certainly can be applied right from the start of any program. However, there is a danger of specifying capabilities that will never be in place and may not even be needed to protect the organization. Any hints of “ivory tower,” or other idealized but unrealistic pronouncements, are likely to be seen as incompetence or, at the very least, misunderstandings. Since the practice of architecture is still craft and relatively relation- ship based, trust and respect are integral to getting anything accomplished.
When standards reflect reality, they will be observed. But just as importantly, when the standards make architectural and security sense, participants will implicitly under- stand that a need for an exception to standards will need to be proved, not assumed. Hence, blindly applying industry “standards” or practices without first understanding the complexities of the situation at hand is generally a mistake and will have costly repercussions.
Even in the face of reduced capabilities or constrained resources, if one understands the normal solution to an architectural pattern, a standard solution, or an industry- recognized solution, one can creatively work from that standard. It’s much easier to start with something well understood and work towards an implementable solution, given the capabilities at hand. This is where a sensible risk practice is employed. The architect must do as much as possible and then assess any remaining residual risk.
As we shall see, residual risk must be brought to decision makers so that it can either be accepted or treated. Sometimes, a security architect has to do what he or she can
Security Architecture of Systems 73
within the limits and constraints given, while making plain the impact that those limits are likely to generate. Even with many standard patterns at hand, in the real world, applying patterns must work hand-in-hand with a risk practice. It has been said that information security is “all about risk.”
In order to recognize patterns—whether architectural or security—one has to have a representation of the architecture. There are many forms of architectural representa- tion. Certainly, an architecture can be described in a specification document through descriptive paragraphs. Even with a well-drawn set of diagrams, the components and flows will typically need to be documented in prose as well as diagramed. That is, details will be described in words, as well. It is possible, with sufficient diagrams and a written explanation, that a security assessment can be performed with little or no interaction. In the author’s experience, however, this is quite rare. Inevitably, the dia- gram is missing something or the descriptions are misleading or incomplete. As you begin assessing systems, prepare yourself for a fair amount of communication and dia- logue. For most of the architects with whom I’ve worked and who I’ve had the privilege to train and mentor, the architectural diagram becomes the representation of choice. Hence, we will spend some time looking at a series of diagrams that are more or less typical. Like Figure 3.3, let’s try to understand what the diagram tells us, as well as from a security perspective, what may be missing.
3.5 System Architecture Diagrams and Protocol Interchange Flows (Data Flow Diagrams)
Let’s begin by defining what we mean by a representation. In its simplest form, the representation of a system is a graphical representation, a diagram. Unfortunately, there are “logical” diagrams that contain almost no useful information. Or, a diagram can contain so much information that the relevant and important areas are obscured.
A classic example of an overly simplified view would be a diagram containing a laptop, a double-headed arrow from the laptop to the server icon with, perhaps, a brick wall in between representing a firewall (actual, real-world “diagrams”). Figure 3.1 is more less this simple (with the addition of some sort of backend server component). Although it is quite possible that the system architecture is really this simple (there are systems that only contain the user’s browser and the Web server), we still don’t know a key piece of information without asking, namely, which side, laptop or server, opens the connection and begins the interaction. Merely for the sake of understanding authenti- cation, we have to understand that one key piece of the communication flow.* And for most modestly complex systems, it’s quite likely that there are many more components
* Given the ubiquity of HTTP interactions, if the protocol is HTTP and the content is some form of browser interaction (HTML+dynamic content), then origination can safely be assumed from the user, from the user’s browser, or from an automated process, for example, a “web service client.”
74 Securing Systems
involved than just a laptop and a server (unless the protocol is telnet and the laptop is logging directly into the server).
Figure 3.6 represents a conceptual sample enterprise architecture. Working from the abovementioned definition given by Godinez et al. (2010)20 of a conceptual architec- ture, Figure 3.6 then represents the enterprise architect’s view of the business relation- ships of th e architecture. What the conceptual architecture intends to represent are the business functions and their interrelationships; technologies are typically unimportant,
We start with an enterprise view for two reasons:
1. Enterprise architecture practice is better described than system architecture. 2. Each system under review must fit into its enterprise architecture.
Hence, because the systems you will review have a place within and deliver some part of the intent of the enterprise architecture, we begin at this very gross level. When one possesses some understanding of enterprise architectures, this understanding provides a basis for the practice of architecture and, specifically, security architecture. Enterprise architecture, being a fairly well-described and mature area, may help unlock that which is key to describing and then analyzing all architectures. We, therefore, begin at the enterprise level.
Figure 3.6 Conceptual enterprise architecture.
Security Architecture of Systems 75
In a conceptual enterprise architecture, a very gross level of granularity is displayed so that viewers can understand what business functions are at play. For instance, in Figure 3.6, we can understand that there are integrating services that connect func- tions. These have been collapsed into a single conceptual function: “Integrations.” Anyone who has worked with SOA knows that, at the very least, there will be clients and servers, perhaps SOA managing software, and so on. These are all collapsed, along with an enterprise message bus, into a single block. “Functions get connected through integrations” becomes the architecture message portrayed in Figure 3.6.
Likewise, all data has been collapsed into a single disk. In an enterprise, it is highly unlikely that terrabytes of data could be delivered on a single disk icon. Hence, we know that this representation is conceptual: There is data that must be delivered to applica- tions and presentations. The architecture will make use of “integrations” in order to access the data. Business functions all are integrated with identity, data, and metadata, whereas the presentations of the data for human consumption have been separated out from the business functions for a “Model, View, Controller” or MVC separation. It is highly unlikely that an enterprise would use a single presentation layer for each of the business functions. For one thing, external customers’ presentations probably shouldn’t be allowed to mix with internal business presentations.
In Figure 3.6, we get some sense that there are technological infrastructures that are key to the business flows and processes. For instance, “Integrations” implies some sort of messaging bus technology. Details like a message bus and other infrastructures might be shown in the conceptual architecture only if the technologies were “stan- dards” within the organization. Details like a message bus might also be depicted if these details will in some manner enhance the understanding of what the architecture is trying to accomplish at a business level. Mostly, technologies will be represented at a very gross level; details are unimportant within the conceptual architecture. There are some important details, however, that the security architect can glean from a concep- tual architecture.
Why might the security architect want to see the conceptual architecture? As I wrote in Chapter 9 of Core Software Security,21 early engagement of security into the Secure Development Lifecycle (SDL) allows for security strategy to become embedded in the architecture. “Strategy” in this context means a consideration of the underlying secu- rity back story that has already been outlined, namely, the organization’s risk tolerance and how that will be implemented in the enterprise architecture or any specific portion of that architecture. Security strategy will also consider the evolving threat landscape and its relation to systems of the sort being contemplated. Such early engagement will enhance the conceptual architecture’s ability to account for security. And just as impor- tantly, it will make analysis and inclusion of security components within the logical architecture much easier, as architectures move to greater specificity.
From Figure 3.6 we can surmise that there are “clients,” “line of business systems,” “presentations,” and so on who must connect through some sort of messaging or other exchange semantic [perhaps file transfer protocol (FTP)] with core business services. In this diagram, two end-to-end, matrix domains are conceptualized as unitary:
76 Securing Systems
• Process Orchestrations • Security and privacy services
This is a classic enterprise architect concept of security; security is a box of ser- vices rather than some distinct services (the security infrastructure) and some security
Figure 3.7 Component enterprise architecture.
Security Architecture of Systems 77
capabilities built within each component. It’s quite convenient for an enterprise archi- tect to imagine security (or orchestrations, for that matter) as unitary. Enterprise archi- tects are generally not domain experts. It’s handy to unify into a “black box,” opaque, singular function that one needn’t understand, so one can focus on the other services. (I won’t argue that some security controls are, indeed, services. But just as many are not.)
Figure 3.6 also tells us something about the integration of the systems: “service- oriented.” This generally means service-oriented architecture (SOA). At an enterprise level, these are typically implemented through the use of Simple Object Access protocol (SOAP) services or Web services. The use of Web services implies loose coupling to any particular technology stack. SOAP implementation libraries are nearly ubiquitous across operating systems. And, the SOAP clients and servers don’t require program- ming knowledge of each other’s implementation in order to work: loosely coupled. If mature, SOA may contain management components, and even orchestration of services to achieve appropriate process stepping and process control.
You might take a moment at this point to see what questions come up about this diagram (see Figure 3.6). What do you think is missing? What do you want to know more of? Is it clear from the diagram what is external to the organization and what lies within possible network or other trust boundaries?
Figure 3.7 represents the same enterprise architecture that was depicted in Figure 3.6. Figure 3.6 represents a conceptual view, whereas Figure 3.7 represents the compo- nent view.
3.5.1 Security Touches All Domains
For a moment, ignore the box second from the left titled “Infrastructure Security Component” found in the conceptual diagram (Figure 3.6). For enterprise architects, it’s quite normal to try and treat security as a black box through which communications and data flow. Somehow the data are “magically” made secure. If you work with enough systems, you will see these “security” boxes placed into diagrams over and over again.
Like any practice, the enterprise architect can only understand so many factors and so many technologies. Usually, anyone operating at the enterprise level will be an expert in many domains. The reason they depend upon security architects is because the enterprise architects are typically not security experts. Security is a matrix function across every other domain. Some security controls are reasonably separate and distinct, and thus, can be placed in their own component space, whereas other controls must be embedded within the functionality of each component. It is our task as security architects to help our sister and brother architects understand the nature of security a s a matrix domain.*
* Annoying as the treatment of security as a kind of unitary, magical transformation might be, I don’t expect the architects with whom I work to be security experts. Th at’s my job.
78 Securing Systems
In Figure 3.7, the security functions have been broken down into four distinct components:
1. Internet facing access controls and validation 2. External to internal access controls and validation 3. Security monitoring 4. A data store of security alerts and events that is tightly coupled to the security
This component breakout still hides much technological detail. Still, we can see where entrance and exit points are, where the major trust boundaries exist. Across the obvious trust boundary between exposed networks (at the top of the diagram) and the internal networks, there is some sort of security infrastructure component. This com- ponent is still largely undefined. Still, placing “access controls and validation” between the two trust zones allows us to get some feel for where there are security-related com- ponents and how these might be separated from the other components represented in Figure 3.7. The security controls that must be integrated into other components would create too much visual noise in an already crowded representation. Another security- specific view might be necessary for this enterprise architecture.
3.5.2 Component Views
Moving beyond the security functions, how is the component view different from the conceptual view?
Most obviously, there’s a lot more “stuff” depicted. In Figure 3.7, there are now two very distinct areas—“external” and “internal.” Functions have been placed such that we can now understand where within these two areas the function will be placed. That single change engenders the necessity to split up data so that co-located data will be represented separately. In fact, the entire internal data layer has been sited (and thus associated to) the business applications and processing. Regarding those components for which there are multiple instances, we can see these represented.
“Presentations” have been split from “external integrations” as the integrations are sited in a special area: “Extranet.” That is typical at an enterprise, where organizations are cross-connected with special, leased lines and other point-to-point solutions, such as virtual private networks (VPN). Access is granted based upon business contracts and relationships. Allowing data exchange after contracts are confirmed is a different rela- tionship than encouraging interested parties to be customers through a “presentation” of customer services and online shopping (“eCommerce”). Because these two modes of interaction are fundamentally different, they are often segmented into different zones: web site zone (for the public and customers) and Extranet (for business partners). Typically, both of these will be implemented through multiple applications, which are
Security Architecture of Systems 79
usually deployed on a unitary set of shared infrastructure services that are sited in the externally accessible environment (a formal “DMZ”).
In Figure 3.7 you see a single box labeled, “External Infrastructures,” which cuts across both segments, eCommerce and Extranet. This is to indicate that for economies of scale, there is only one set of external infrastructures, not two. That doesn’t mean that the segments are not isolated from each other! And enterprise architects know full well that infrastructures are complex, which is why the label is plural. Still, at this granularity, there is no need to be more specific than noting that “infrastructures” are separated from applications.
Take a few moments to study Figures 3.6 and 3.7, their similarities and their dif- ferences. What functions have been broken into several components and which can be considered unitary, even in the component enterprise architecture view?
3.6 What’s Important?
The amount of granularity within any particular architecture diagram is akin to the story of Goldilocks and the Three Bears. “This bed is too soft! This bed is too hard! This bed is just right.” Like Goldilocks, we may be presented with a diagram that’s “too soft.” The diagram, like Figure 3.1, doesn’t describe enough, isn’t enough of a detailed representation to uncover the attack surfaces.
On the other hand, a diagram that breaks down the components that, for the pur- poses of analysis, could have been considered as atomic (can be treated as a unit) into too many subcomponents will obscure the attack surfaces with too much detail: “This diagram is too hard!”
As we shall see in the following section, what’s “architecturally interesting” is depen- dent upon a number of factors. Unfortunately, there is no simple answer to this problem. When assessing, if you’re left with a lot of questions, or the diagram only answers one or two, it’s probably “too soft.” On the other hand, if your eyes glaze over from all the detail, you probably need to come up one or two levels of granularity, at least to get started. That detailed diagram is “too hard.” There are a couple of patterns that can help.
3.6.1 What Is “Architecturally Interesting”?
This is why I wrote “component functions.” If the interesting function is the operat- ing system of a server, then one may think of the operating system in an atomic man- ner. However, even a command-line remote access method such as telnet or secure Shell (SSH) gives access to any number of secondary logical functions. In the same way, unless a Web server is only sharing static HTML pages, there is likely to be an application, some sort of processing, and some sort of data involved beyond an atomic web server. In this case, our logical system architecture will probably need a few more
80 Securing Systems
components and the methods of communication between those components: Web server, application, data store. There has to be a way for the Web server to instantiate the application processing and then return the HTTP response from that processing. And the application will need to fetch data from the data store and perhaps update the data based on whatever processing is taking place. We have now gone from two compo- nents to five. We’ve gone from one communication flow to three. Typical web systems are considerably more complex than this, by the way.
On the other hand, let’s consider the web tier of a large, commercial server. If we know with some certainty that web servers are only administered by security savvy, highly trained and highly trusted web masters, then we can assume a certain amount of restriction to any attacker-attractive functionality. Perhaps we already know and have approved a rigorous web server and operating environment hardening standard. Storage areas are highly restricted to only allow updates from trusted sources and to only allow read operations from the web servers. The network on which these web servers exist is highly restricted such that only HTTP/S is allowed into the network from untrusted sources, only responses from the web servers can flow back to untrusted sources, and administrative traffic comes only from a trusted source that has consider- able access restrictions and robust authorization before grant of access. That adminis- trative network is run by security savvy, highly trusted individuals handpicked for the role through a formal approval process, and so forth.*
In the website case outlined above, we may choose to treat web servers as atomic without digging into their subcomponents and their details. The web servers inherit a great deal of security control from the underlying infrastructure and the established formal processes. Having answered our security questions once to satisfaction, we don’t need to ask each web project going into the environment, so long as the project uses the environment in the intended and accepted manner, that is, the project adheres to the existing standards. In a security assessment, we would be freed to consider other factors, given reasonably certain knowledge and understanding of the security controls already in place. Each individual server can be considered “atomic.” In fact, we may even be able to consider an entire large block of servers hosting precisely the same function as atomic, for the purposes of analysis.
Besides, quite often in these types of highly controlled environments, the application programmer is not given any control over the supporting factors. Asking the application team about the network or server administration will likely engender a good deal of frustration. Also, since the team members actually don’t have the answers, they may be encouraged to guess. In matters relating to security due diligence, guessing is not good enough. An assessor must have near absolute certainty about everything about which certainty can be attained. All unknowns must be treated as potential risks.
Linked libraries and all the different objects or other modular interfaces inside an executable program usually don’t present any trust boundaries that are interesting. A
* We will revisit web sites more thoroughly in later chapters.
Security Architecture of Systems 81
single process (in whatever manner the execution environment defines “process”) can usually be considered atomic. There is generally no advantage to digging through the internal software architecture, the internal call graph of an executable process space.
The obvious exception to the guideline to treat executable packages as atomic are dynamically linked executable forms,* such as DLLs under the Microsoft operating sys- tems or dynamic link libraries under UNIX. Depending upon the rest of the architec- ture and the deployment model, these communications might prove interesting, since certain attack methods substitute a DLL of the attacker’s choosing.
The architecture diagram needs to represent the appropriate logical components. But, unfortunately, what constitutes “logical components” is dependent upon three factors:
1. Deployment model 2. Infrastructure (and execution environment) 3. Attack methods
In the previous chapter, infrastructure was mentioned with respect to security capa- bilities and limitations. Alongside the security capabilities that are inherited from the infrastructure and runtime stack, the very type of infrastructure upon which the system will run influences the level at which components may be considered atomic. This aspect is worth exploring at some length.
3.7 Understanding the Architecture of a System
The question that needs answering in order to factor the architecture properly for attack surfaces is at what level of specificity can components be treated as atomic? In other words, how deep should the analysis decompose an architecture? What constitutes meaningless detail that confuses the picture?
3.7.1 Size Really Does Matter
As mentioned above, any executable package that is joined to a running process after it’s been launched is a point of attack to the executable, perhaps to the operating system. This is particularly true where the attack target is the machine or virtual machine itself. Remember that some cyber criminals make their living by renting “botnets,” networks of attacker-controlled machines. For this attack goal, the compromise of a machine has attacker value in and of itself (without promulgating some further attack, like key- stroke logging or capturing a user session). In the world of Advanced Persistent Threats (APT), the attacker may wish to control internal servers as a beachhead, an internal
* We will examine another exception below: Critical pieces of code, especially code that handles secrets, will be attacked if the secret protects a target suffi ciently attractive.
82 Securing Systems
machine from which to launch further attacks. Depending upon the architecture of intrusion detection services (IDS), if attacks come from an internal machine, these internally originating attacks may be ignored. Like botnet compromise, APT attackers are interested in gaining the underlying computer operating environment and subvert- ing the OS to their purposes.
Probing a typical computer operating system’s privilege levels can help us delve into the factoring problem. When protecting an operating environment, such as a user’s lap- top or mobile phone, we must decompose down to executable and/or process boundaries. The presence of a vulnerability, particularly an overflow or boundary condition vulner- ability that allows the attacker to execute code of her or his choosing, means that one process may be used against all the others, especially if that process is implicitly trusted.
As an example, imagine the user interface (UI) to an anti-virus engine (AV). Figure 3.4 could represent an architecture that an AV engine might employ. We could add an additional process running in user space, the AV engine. Figure 3.8 depicts this change to the architecture that we examined in Figure 3.4. Many AV engines employ system drivers in order to capture file and network traffic transparently. In Figure 3.8, we have a generalized anti-virus or anti-malware endpoint architecture.
The AV runs in a separate process space; it receives commands from the UI, which also runs in a separate process. Despite what you may believe, quite often, AV engines do not run at high privilege. This is purposive. But, AV engines typically communicate or receive communications from higher privilege components, such as system drivers and the like. The UI will be running at the privilege level of the user (unless the security architect has made a big mistake!).
Figure 3.8 Anti-virus endpoint architecture.
Security Architecture of Systems 83
In this situation, a takeover of the UI process would allow the attacker to send com- mands to the AV engine. This could result in a simple denial of service (DOS) through overloading the engine with commands. But perhaps the UI can turn off the engine? Perhaps the UI can tell the engine to ignore malicious code of the attacker’s choosing? These scenarios suggest that the communication channel from UI to AV needs some protection. Generally, the AV engine should be reasonably suspicious of all communica- tions, even from the UI.
Still, if the AV engine does not confirm that the UI is, indeed, the one true UI component shipped with the product, the AV engine presents a much bigger and more dangerous attack surface. In this case, with no authentication and validation of the UI process, an attacker no longer needs to compromise the UI! Why go to all the trouble of reverse-engineering the UI, hunting for possible overflow conditions, and then building an exploit for the vulnerability? That’s quite a bit of work compared to simply supplying the attacker’s very own UI. By studying the calls and communications between the UI and the AV engine, the attacker can craft her or his own UI component that has the same level of control as the product’s UI component. This is a lot less work than reverse engineering the product’s UI component. This attack is made possible when the AV engine assumes the validity of the UI without verification. If you will, there is a trust relationship between the AV engine and the UI process. The AV process must establish trust of the UI. Failure to do so allows the attacker to send commands to the AV engine, possibly including, “Stop checking for malware.”
The foregoing details why most anti-virus and malware programs employ digital sig- natures rendered over executable binary files. The digital signature can be validated by each process before communications commence. Each process will verify that, indeed, the process attempting to communicate is the intended process. Although not entirely foolproof,* binary signature validation can provide a significant barrier to an attack to a more trusted process from a less than trusted source.
Abstracting the decomposition problem from the anti-virus engine example, one must factor an independently running endpoint architecture (or subcomponent) down to the granularity of each process space in order to establish trust boundaries, attack surfaces, and defensible perimeters. As we have seen, such granular depth may be unnecessary in other scenarios. If you recall, we were able to generally treat the user’s browser atomically simply because the whole endpoint is untrusted. I’ll stress again: It is the context of the architecture that determines whether or not a particular component will need to be factored further.
* It is beyond the scope of this book to delve into the intricacies of signature validations. Th ese are generally performed by the operating system in favor of a process before load and execu- tion. However, since system software has to remain backward compatible, there are numerous very subtle validation holes that have become diffi cult to close without compromising the ability of users to run all of the user’s software.
84 Securing Systems
For the general case of an operating system without the presence of significant, addi- tional, exterior protections, the system under analysis can be broken down into execut- able processes and dynamically loaded libraries. A useful guideline is to decompose the architecture to the level of executable binary packages. Obviously, a loadable “pro- gram,” which when executed by the operating system will be placed into whatever runtime space is normally given to an executable binary package, can be considered an atomic unit. Communications with the operating system and with other executable processes can then be examined as likely attack vectors.
3.8 Applying Principles and Patterns to Specifi c Designs
How does Figure 3.9 differ from Figure 3.8? Do you notice a pattern similarity that exists within both architectures? I have purposely named items in the drawing using typical mobile nomenclature, rather than generalizing, in the hope that you will translate these details into general structures as you study the diagram. Before we explore this typical mobile anti-virus or anti-malware application architecture, take a few moments to look at Figure 3.8, then Figure 3.9. Please ponder the similarities as well as differences. See if you can abstract the basic underlying pattern or patterns between the two architectures.
Obviously, I’ve included a “communicate” component within the mobile architec- ture. Actually, there would be a similar function within almost any modern endpoint
Figure 3.9 Mobile security application endpoint architecture.
Security Architecture of Systems 85
security application, whether the software was intended for consumers, any size orga- nization, or enterprise consumption. People expect their malware identifications to get updated almost in real time, let’s say, “rapidly.” These updates* are often sent from a central threat “intelligence” team, a threat evaluation service via centralized, highly controlled Web services to the endpoint.†
In addition, the communicator will likely send information about the state of the endpoint to a centralized location for analysis: Is the endpoint compromised? Does it store malware? What versions of the software are currently running? How many evil samples have been seen and stopped? All kinds of telemetry about the state of the end- point are typically collected. This means that communications are usually both ways: downwards to the endpoint and upwards to a centralized server.
In fact, in today’s mobile application market, most applications will embed some sort of communications. Only the simplest application, say a “flashlight” that turns on the camera’s light, or a localized measuring tool or similar discreet application, will not require its own server component and the necessary communications flows. An embed- ded mobile communications function is not unique to security software; mobile server communications are ubiquitous.
In order to keep things simple, I kept the communications out of the discussion of Figure 3.8. For completeness and to represent a more typical mobile architecture, I have introduced the communicator into Figure 3.9. As you may now see, the inclusion of the communicator opens up all kinds of new security challenges. Go ahead and consider these as you may. We will take up the security challenges within a mobile application in the analyses in Part II. For the moment, let’s restrict the discussion to the mobile endpoint. Our task at this point in the journey is to understand architectures. And, furthermore, we need to understand how to extract security-related information from an architecture diagram so that we have the skills to proceed with an architecture risk assessment and threat model.
The art of architecture involves the skill of recognizing and then applying abstract patterns while, at the same time, understanding any local details that will be ignored through the application of patterns. Any unique local circumstances are also important and will have to be attended to properly.
It is not that locally specific details should be completely ignored. Rather, in the interest of achieving an “architectural” view, these implementation details are over- looked until a broader view can be established. That broader view is the architecture. As the architecture proceeds to specific design, the implementation details, things like specific operating system services that are or are not available, once again come to the fore and must receive attention.
* Th ese updates are called “DAT” fi les or updates. Every endpoint security service of which the author knows operates in this manner.
† For enterprises, the updated DAT will be sent to an administrative console from which admin- istrators can then roll out to large numbers of endpoints at the administrator’s discretion
86 Securing Systems
I return to the concept of different architecture views. We will stress again and again how important the different views are during an assessment. We don’t eliminate the details; we abstract the patterns in order to apply solutions. Architecture solutions in hand, we then dive into the detail of the specifics.
In Figure 3.8, the trust boundary is between “user” space and “kernel” execution area. Those are typical nomenclature for these execution areas in UNIX and UNIX- like and Windows™ operating systems. In both the Android™ and iOS™ mobile plat- forms, the names are somewhat different because the functions are not entirely same: the system area and the application environment. Abstracting just what we need from this boundary, I think it is safe to declare that there is an essential similarity between kernel and system, even though, on a mobile platform, there is a kernel beneath the sys- tem level (as I understand it). Nevertheless, the system execution space has high privi- leges. System processes have access to almost everything,* just as a kernel does. These are analogous for security purposes. Kernel and system are “high” privilege execution spaces. User and application are restricted execution environments, purposely so.
A security architect will likely become quite conversant in the details of an operat- ing system with which he or she works on a regular basis. Still, in order to assess any architecture, one needn’t be a “guru.” As we shall see, the details change, but the basic problems are entirely similar. There are patterns that we may abstract and with which we can work.
Table 3.1 is an approximation to illuminate similarities and, thus, must not be taken as a definitive statement. The makers of each of these operating systems may very well violently disagree. For instance, much discussion has been had, often quite spirited, about whether the Linux system is a UNIX operating system or not. As a security architect, I purposely dodge the argument; a position one way or the other (yes or no) is irrelevant to the architecture pattern. Most UNIX utilities can be compiled to run on Linux, and do. The configuration of the system greatly mirrors other UNIX systems, that is, load order, process spaces, threading, and memory can all be treated as similar to other UNIX variants. For our purposes, Linux may be considered a UNIX variant without reaching a definitive answer to the question, “Is Linux a UNIX operating sys- tem?” For our purposes, we don’t need to know.
Hence, we can take the same stance on all the variants listed in Table 3.1—that is, we don’t care whether it is or is not; we are searching for common patterns. I offer the following table as a “cheat sheet,” if you will, of some common operating systems as of this writing. I have grossly oversimplified in order to reveal similarities while obscur- ing differences and exceptions. The list is not a complete list, by any means. Experts in each of these operating systems will likely take exception to my cavalier treatment of the details.
* System processes can access processes and services in the system and user spaces. System pro- cesses will have only restricted access to kernel services through a formal API of some sort, usually a driver model and services.
Security Architecture of Systems 87
Table 3.1 Common Operating Systems and Their Security Treatment
Name Family Highest Privilege
Higher Privilege? User Space
BSD UNIX UNIX1 Kernel2 User3
Posix UNIX UNIX Kernel User
System V UNIX Kernel User
Mac OS™ UNIX (BSD) Kernel Administrator4 User
iOS™ Mac OS Kernel System Application
Linux5 UNIX-like Kernel User
Android™ Linux Kernel System Application8
Windows™6 Windows NT Kernel System User
Windows Mobile™ (variants)
Windows7 Kernel System Application
1. There are far more UNIX variants and subvariants than listed here. For our purposes, these variations are essentially the same architecture.
2. The superuser or root, by design, has ultimate privileges to change anything in every UNIX and UNIX-like operating system. Superuser has god-like powers. The superuser should be considered essentially the same as kernel, even though the kernel is an operating environ- ment and the superuser is a highly privileged user of the system. These have the same privileges: everything.
3. In all UNIX and UNIX descendant systems, users can be configured with granular read/ write/execute privileges up to and including superuser equivalence. We ignore this for the moment, as there is a definite boundary between user and kernel processes. If the super- user has chosen to equate user with superuser, the boundary has been made irrelevant from the attacker’s point of view.
4. Mac OS introduced a preconfigured boundary between the superuser and an administra- tor. These do not have equivalent powers. The superuser, or “root” as it is designated in Mac OS documentation, has powers reserved to it, thus protecting the environment from mistakes that are typical of inexperienced administrators. Administrator is highly privileged but not god-like in the Mac OS.
5. There are also many variants and subvariants of Linux. For our purposes, these may be treated as essentially the same operating system.
6. I do not include the Windows-branded operating systems before the kernel was ported to the NT kernel base. These had an entirely different internal architecture and are completely obsolete and deprecated. There are many variants of the Windows OS, too numerous for our purposes. There have been many improvements in design over the years. These varia- tions and improvements are all descendants of the Windows NT kernel, so far as I know. I don’t believe that the essential driver model has changed since I wrote drivers for the sys- tem in the 1990s.
7. I’m not conversant with the details of the various Windows mobile operating systems. I’m making a broad assumption here. Please research as necessary.
8. Android employs OS users as application strategy. It creates a new user for each application so that applications can be effectively isolated, called a “sandbox.” It is assumed that there is only a single human user of the operating system since Android is meant for personal computing devices, such as phones and tablets.
88 Securing Systems
It should be readily apparent, glancing through the operating system cheat sheet given in Table 3.1, that one can draw some reasonable comparisons between operat- ing systems as different as Windows Server™ and Android™. The details are certainly radically different, as are implementation environments, compilers, linkers, testing, deployment—that is, the whole panoply of development tooling. However, an essential pattern emerges. There are higher privileged execution spaces and spaces that can have their privileges restricted (but don’t necessarily, depending upon configuration by the superuser or system administrator).
On mobile platforms especially, the application area will be restricted on the deliv- ered device. Removing the restrictions is usually called “jail breaking.” It is quite pos- sible to give applications the same privileges as the system or, rather, give the running user or application administrative or system privileges. The user (or malware) usually has to take an additional step*: jail breaking. We can assume the usual separation of privileges rather than the exception in our analysis. It might be a function of a mobile security application to ascertain whether or not the device has been jail broken and, based upon a positive result, take some form of protective action against the jail break.