Please review chapter-13 from the textbook attached What does a peer review process look like? When does an assessment requi

Securing Systems

Applied Security Architecture and Threat Models

Securing Systems

Applied Security Architecture and Threat Models

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

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

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

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

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

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

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

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

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

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

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

v

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

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

Dedication

vii

Contents

Dedication v

Contents vii

Foreword by John N. Stewart xiii

Foreword by Dr. James F. Ransome xv

Preface xix

Acknowledgments xxv

About the Author xxvii

Part I Introduction 3

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

Chapter 1: Introduction 9

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

Chapter 2: The Art of Security Assessment 27

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

viii Securing Systems

2.3 Necessary Ingredients 33 2.4 The Threat Landscape 35

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

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

Chapter 3: Security Architecture of Systems 53

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

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

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

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

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

Summary 98 References 98

Chapter 4: Information Security Risk 101

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

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

4.7 Business Impact 122 4.7.1 Data Sensitivity Scales 125

Contents ix

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

4.9 Summary 129 References 130

Chapter 5: Prepare for Assessment 133

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

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

of the System 138 5.2.2 Understand Every Communication Flow and Any

Valuable Data Wherever Stored 140 5.3 Threat Enumeration 145

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

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

Using Their Attack Methods 151 5.4 Attack Surfaces 153

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

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

5.4.3 List All Existing Security Controls for Each Attack Surface 160

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

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

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

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

Part I Summary 173

x Securing Systems

Part II Introduction 179

Practicing with Sample Assessments 179 Start with Architecture 180

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

Getting Back to Basics 185 References 189

Chapter 6: eCommerce Website 191

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

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

Chapter 7: Enterprise Architecture 213

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

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

Chapter 8: Business Analytics 235

8.1 Architecture 235 8.2 Threats 239 8.3 Attack Surfaces 242

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

8.5.1 Enterprise Identity Systems (Authentication and Authorization) 261

8.6 Requirements 262 References 266

Contents xi

Chapter 9: Endpoint Anti-malware 267

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

Chapter 10: Mobile Security Software with Cloud Management 285

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

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

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

Cloud Architecture 298

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

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

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

11.3 Additional Requirements for the SaaS Reputation Service 319

References 320

Part II Summary 321

Part III Introduction 327

Chapter 12: Patterns and Governance Deliver Economies of Scale 329

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

xii Securing Systems

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

12.2 Some Thoughts on Governance 348 Summary 351 References 351

Chapter 13: Building an Assessment Program 353

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

13.2 Building a Team 364 13.2.1 Training 366

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

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

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

13.8 Summary 380 References 382

Part III Summary and Afterword 383

Summary 383 Afterword 385

Index 387

xiii

Foreword

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

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

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

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

xiv Securing Systems

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

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

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

Cisco Systems, Inc.

About John N. Stewart:

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

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

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

xv

Foreword

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

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

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

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

xvi Securing Systems

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

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

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

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

* Ibid.

Foreword xvii

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

– Dr. James F. Ransome, CISSP, CISM

About Dr. James F. Ransome:

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

* Ibid.

xix

Preface

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

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

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

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

xx Securing Systems

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

Who May Benefi t from This Book?

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

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

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

and executives

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

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

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

Preface xxi

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

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