Fluent Essays

Topic: Security Architecture and Design Question: 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 authentication system to a tier behind the DMZ, thus, a more trusted zone? What are the implications of doing so for authentication performance? For security? Instructions: Minimum 400 words. Need 2 APA References Textbook attached. Single space and single page No Plagiarism please. ransome__james_f.__schoenfield__brook_s._e.__stewart__john_n___securing_systems___applied_security_architecture_and_threat_models__2015__crc_press_.pdf Unformatted Attachment Preview Securing Systems Applied Security Architecture and Threat Models Securing Systems Applied Security Architecture and Threat Models Brook S.E. Schoenfield Forewords by John N. Stewart and James F. Ransome CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2015 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works Version Date: 20150417 International Standard Book Number-13: 978-1-4822-3398-8 (eBook - PDF) This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint. Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www.copyright.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and registration for a variety of users. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe. Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the CRC Press Web site at http://www.crcpress.com Dedication To the many teachers who’ve pointed me down the path; the managers who have supported my explorations; the many architects and delivery teams who’ve helped to refine the work; to my first design mentors—John Caron, Roddy Erickson, and Dr. Andrew Kerne—without whom I would still have no clue; and, lastly, to Hans Kolbe, who once upon a time was our human fuzzer. Each of you deserves credit for whatever value may lie herein. The errors are all mine. v Contents Dedication v Contents vii Foreword by John N. Stewart xiii Foreword by Dr. James F. Ransome xv Preface xix Acknowledgments xxv About the Author xxvii Part I Introduction The Lay of Information Security Land The Structure of the Book References Chapter 1: Introduction 1.1 Breach! Fix It! 1.2 Information Security, as Applied to Systems 1.3 Applying Security to Any System References Chapter 2: The Art of Security Assessment 2.1 2.2 Why Art and Not Engineering? Introducing “The Process” 3 3 7 8 9 11 14 21 25 27 28 29 vii viii Securing Systems 2.3 2.4 Necessary Ingredients The Threat Landscape 2.4.1 Who Are These Attackers? Why Do They Want to Attack My System? 2.5 How Much Risk to Tolerate? 2.6 Getting Started References Chapter 3: Security Architecture of Systems 3.1 3.2 3.3 3.4 3.5 Why Is Enterprise Architecture Important? The “Security” in “Architecture” Diagramming For Security Analysis Seeing and Applying Patterns System Architecture Diagrams and Protocol Interchange Flows (Data Flow Diagrams) 3.5.1 Security Touches All Domains 3.5.2 Component Views 3.6 What’s Important? 3.6.1 What Is “Architecturally Interesting”? 3.7 Understanding the Architecture of a System 3.7.1 Size Really Does Matter 3.8 Applying Principles and Patterns to Specific Designs 3.8.1 Principles, But Not Solely Principles Summary References Chapter 4: Information Security Risk 4.1 4.2 4.3 4.4 4.5 4.6 4.7 Rating with Incomplete Information Gut Feeling and Mental Arithmetic Real-World Calculation Personal Security Posture Just Because It Might Be Bad, Is It? The Components of Risk 4.6.1 Threat 4.6.2 Exposure 4.6.3 Vulnerability 4.6.4 Impact Business Impact 4.7.1 Data Sensitivity Scales 33 35 36 44 51 52 53 54 57 59 70 73 77 78 79 79 81 81 84 96 98 98 101 101 102 105 106 107 108 110 112 117 121 122 125 Contents ix 4.8 Risk Audiences 4.8.1 The Risk Owner 4.8.2 Desired Security Posture 4.9 Summary References Chapter 5: Prepare for Assessment 5.1 Process Review 5.1.1 Credible Attack Vectors 5.1.2 Applying ATASM 5.2 Architecture and Artifacts 5.2.1 Understand the Logical and Component Architecture of the System 5.2.2 Understand Every Communication Flow and Any Valuable Data Wherever Stored 5.3 Threat Enumeration 5.3.1 List All the Possible Threat Agents for This Type of System 5.3.2 List the Typical Attack Methods of the Threat Agents 5.3.3 List the System-Level Objectives of Threat Agents Using Their Attack Methods 5.4 Attack Surfaces 5.4.1 Decompose (factor) the Architecture to a Level That Exposes Every Possible Attack Surface 5.4.2 Filter Out Threat Agents Who Have No Attack Surfaces Exposed to Their Typical Methods 5.4.3 List All Existing Security Controls for Each Attack Surface 5.4.4 Filter Out All Attack Surfaces for Which There Is Sufficient Existing Protection 5.5 Data Sensitivity 5.6 A Few Additional Thoughts on Risk 5.7 Possible Controls 5.7.1 Apply New Security Controls to the Set of Attack Services for Which There Isn’t Sufficient Mitigation 5.7.2 Build a Defense-in-Depth 5.8 Summary References Part I Summary 126 127 129 129 130 133 133 134 135 137 138 140 145 146 150 151 153 154 159 160 161 163 164 165 166 168 170 171 173 x Securing Systems Part II Introduction Practicing with Sample Assessments Start with Architecture A Few Comments about Playing Well with Others Understand the Big Picture and the Context Getting Back to Basics References Chapter 6: eCommerce Website 6.1 6.2 6.3 Decompose the System 6.1.1 The Right Level of Decomposition Finding Attack Surfaces to Build the Threat Model Requirements Chapter 7: Enterprise Architecture 7.1 7.2 7.3 7.4 Enterprise Architecture Pre-work: Digital Diskus Digital Diskus’ Threat Landscape Conceptual Security Architecture Enterprise Security Architecture Imperatives and Requirements 7.5 Digital Diskus’ Component Architecture 7.6 Enterprise Architecture Requirements References Chapter 8: Business Analytics 8.1 8.2 8.3 Architecture Threats Attack Surfaces 8.3.1 Attack Surface Enumeration 8.4 Mitigations 8.5 Administrative Controls 8.5.1 Enterprise Identity Systems (Authentication and Authorization) 8.6 Requirements References 179 179 180 181 183 185 189 191 191 193 194 209 213 217 218 221 222 227 232 233 235 235 239 242 254 254 260 261 262 266 Contents xi Chapter 9: Endpoint Anti-malware 9.1 A Deployment Model Lens 9.2 Analysis 9.3 More on Deployment Model 9.4 Endpoint AV Software Security Requirements References Chapter 10: Mobile Security Software with Cloud Management 10.1 Basic Mobile Security Architecture 10.2 Mobility Often Implies Client/Cloud 10.3 Introducing Clouds 10.3.1 Authentication Is Not a Panacea 10.3.2 The Entire Message Stack Is Important 10.4 Just Good Enough Security 10.5 Additional Security Requirements for a Mobile and Cloud Architecture Chapter 11: Cloud Software as a Service (SaaS) 11.1 What’s So Special about Clouds? 11.2 Analysis: Peel the Onion 11.2.1 Freemium Demographics 11.2.2 Protecting Cloud Secrets 11.2.3 The Application Is a Defense 11.2.4 “Globality” 11.3 Additional Requirements for the SaaS Reputation Service References 267 268 269 277 282 283 285 285 286 290 292 294 295 298 301 301 302 306 308 309 311 319 320 Part II Summary 321 Part III Introduction 327 Chapter 12: Patterns and Governance Deliver Economies of Scale 329 12.1 Expressing Security Requirements 12.1.1 Expressing Security Requirements to Enable 12.1.2 Who Consumes Requirements? 337 338 339 xii Securing Systems 12.1.3 Getting Security Requirements Implemented 12.1.4 Why Do Good Requirements Go Bad? 12.2 Some Thoughts on Governance Summary References Chapter 13: Building an Assessment Program 13.1 Building a Program 13.1.1 Senior Management’s Job 13.1.2 Bottom Up? 13.1.3 Use Peer Networks 13.2 Building a Team 13.2.1 Training 13.3 Documentation and Artifacts 13.4 Peer Review 13.5 Workload 13.6 Mistakes and Missteps 13.6.1 Not Everyone Should Become an Architect 13.6.2 Standards Can’t Be Applied Rigidly 13.6.3 One Size Does Not Fit All, Redux 13.6.4 Don’t Issue Edicts Unless Certain of Compliance 13.7 Measuring Success 13.7.1 Invitations Are Good! 13.7.2 Establish Baselines 13.8 Summary References Part III Summary and Afterword Summary Afterword Index 344 347 348 351 351 353 356 356 357 359 364 366 369 372 373 374 374 375 376 377 377 378 378 380 382 383 383 385 387 Foreword As you read this, it is important to note that despite hundreds to thousands of peopleyears spent to date, we are still struggling mightily to take the complex, de-compose into the simple, and create the elegant when it comes to information systems. Our world is hurtling towards an always on, pervasive, interconnected mode in which software and life quality are co-dependent, productivity enhancements each year require systems, devices and systems grow to 50 billion connected, and the quantifiable and definable risks all of this creates are difficult to gauge, yet intuitively unsettling, and are slowly emerging before our eyes. “Arkhitekton”—a Greek word preceding what we speak to as architecture today, is an underserved idea for information systems, and not unsurprisingly, security architecture is even further underserved. The very notion that through process and product, systems filling entire data centers, information by the pedabyte, transaction volumes at sub-millisecond speed, and compute systems doubling capability every few years, is likely seen as impossible—even if needed. I imagine the Golden Gate bridge seemed impossible at one point, a space station also, and buildings such as the Burj Khalifa, and yet here we are admiring each as a wonder unto themselves. None of this would be possible without formal learning, training architects in methods that work, updating our training as we learn, and continuing to require a demonstration for proficiency. Each element plays that key role. The same is true for the current, and future, safety in information systems. Architecture may well be the savior that normalizes our current inconsistencies, engenders a provable model that demonstrates efficacy that is quantifiably improved, and tames the temperamental beast known as risk. It is a sobering thought that when systems are connected for the first time, they are better understood than at any other time. From that moment on, changes made—documented and undocumented—alter our understanding, and without understanding comes risk. Information systems must be understood for both operational and risk-based reasons, which means tight definitions must be at the core—and that is what architecture is all about. For security teams, both design and protect, it is our time to build the tallest, and safest, “building.” Effective standards, structural definition, deep understanding with xiii xiv Securing Systems validation, a job classification that has formal methods training, and every improving and learning system that takes knowledge from today to strengthen systems installed yesterday, assessments and inspection that look for weaknesses (which happen over time), all surrounded by a well-built security program that encourages if not demands security architecture, is the only path to success. If breaches, so oftentimes seen as avoidable ex post facto, don’t convince you of this, then the risks should. We are struggling as a security industry now, and the need to be successful is higher than it has ever been in my twenty-five years in it. It is not good enough just to build something and try and secure it, it must be architected from the bottom up with security in it, by professionally trained and skilled security architects, checked and validated by regular assessments for weakness, and through a learning system that learns from today to inform tomorrow. We must succeed. – John N. Stewart SVP, Chief Security & Trust Officer Cisco Systems, Inc. About John N. Stewart: John N. Stewart formed and leads Cisco’s Security and Trust Organization, underscoring Cisco’s commitment to address two key issues in boardrooms and on the minds of top leaders around the globe. Under John’s leadership, the team’s core missions are to protect Cisco’s public and private customers, enable and ensure the Cisco Secure Development Lifecycle and Trustworthy Systems efforts across Cisco’s entire mature and emerging solution portfolio, and to protect Cisco itself from the never-ending, and always evolving, cyber threats. Throughout his 25-year career, Stewart has led or participated in security initiatives ranging from elementary school IT design to national security programs. In addition to his role at Cisco, he sits on technical advisory boards for Area 1 Security, BlackStratus, Inc., RedSeal Networks, and Nok Nok Labs. He is a member of the Board of Directors for Shape Security, Shadow Networks, Inc., and the National Cyber-Forensics Training Alliance (NCFTA). Additionally, Stewart serves on the Cybersecurity Think Tank at University of Maryland University College, and on the Cyber Security Review to Prime Minister & Cabinet for Australia. Prior, Stewart served on the CSIS Commission on Cybersecurity for the 44th Presidency of the United States, the Council of Experts for the Global Cyber Security Center, and on advisory boards for successful companies such as Akonix, Cloudshield, Finjan, Fixmo, Ingrian Networks, Koolspan, Riverhead, and TripWire. John is a highly sought public and closed-door speaker and most recently was awarded the global Golden Bridge Award and CSO 40 Silver Award for the 2014 Chief Security Officer of the Year. Stewart holds a Master of Science degree in computer and information science from Syracuse University, Syracuse, New York. Foreword Cyberspace has become the 21st century’s greatest engine of change. And it’s everywhere. Virtually every aspect of global civilization now depends on interconnected cyber systems to operate. A good portion of the money that was spent on offensive and defensive capabilities during the Cold War is now being spent on cyber offense and defense. Unlike the Cold War, where only governments were involved, this cyber challenge requires defensive measures for commercial enterprises, small businesses, NGOs, and individuals. As we move into the Internet of Things, cybersecurity and the issues associated with it will affect everyone on the planet in some way, whether it is cyberwar, cyber-crime, or cyber-fraud. Although there is much publicity regarding network security, the real cyber Achilles’ heel is insecure software and the architecture that structures it. Millions of software vulnerabilities create a cyber house of cards in which we conduct our digital lives. In response, security people build ever more elaborate cyber fortresses to protect this vulnerable software. Despite their efforts, cyber fortifications consistently fail to protect our digital treasures. Why? The security industry has failed to engage fully with the creative, innovative people who write software and secure the systems these solutions are connected to. The challenges to keep an eye on all potential weaknesses are skyrocketing. Many companies and vendors are trying to stay ahead of the game by developing methods and products to detect threats and vulnerabilities, as well as highly efficient approaches to analysis, mitigation, and remediation. A comprehensive approach has become necessary to counter a growing number of attacks against networks, servers, and endpoints in every organization. Threats would not be harmful if there were no vulnerabilities that could be exploited. The security industry continues to approach this issue in a backwards fashion by trying to fix the symptoms rather than to address the source of the problem itself. As discussed in our book Core Software Security: Security at the Source,* the stark reality is that the * Ransome, J. and Misra, A. (2014). Core Software Security: Security at the Source. Boca Raton (FL): CRC Press. xv xvi Securing Systems vulnerabilities that we were seeing 15 years or so ago in the OWASP and SANS Top Ten and CVE Top 20 are almost the same today as they were then; only the pole positions have changed. We cannot afford to ignore the threat of insecure software any longer because software has become the infrastructure and lifeblood of the modern world. Increasingly, the liabilities of ignoring or failing to secure software and provide the proper privacy controls are coming back to the companies that develop it. This is and will be in the form of lawsuits, regulatory fines, loss of business, or all of the above. First and foremost, you must build security into the software development process. It is clear from the statistics used in industry that there are substantial cost savings to fixing security flaws early in the development process rather than fixing them after software is fielded. The cost associated with addressing software problems increases as the lifecycle of a project matures. For vendors, the cost is magnified by the expense of developing and patching vulnerable software after release, which is a costly way of securing applications. The bottom line is that it costs little to avoid potential security defects early in development, especially compared to costing 10, 20, 50, or even 100 times that amount much later in development. Of course, this doesn’t include the potential costs of regulatory fines, lawsuits, and or loss of business due to security and privacy protection flaws discovered in your software after release. Having filled seven Chief Security Officer (CSO) and Chief Information Security Officer (CISO) roles, and having had both software security and security architecture reporting to me in many of these positions, it is clear to me that the approach for both areas needs to be rethought. In my last book, Brook helped delineate our approach to solving the software security problem while also addressing how to build in security within new agile development methodologies such as Scrum. In the same book, Brook noted that the software security problem is bigger than just addressing the code but also the systems it is connected to. As long as software and architecture is developed by humans, it requires the human element to fix it. There have been a lot of bright people coming up with various technical solutions and models to fix this, but we are still failing to do so as an industry. We have consistently focused on the wrong things: vulnerability and command and control. But producing software and designing architecture is a creative and innovative process. In permaculture, it is said that “the problem is the solution.” Indeed, it is that very creativity that must be enhanced and empowered in order to generate security as an attribute of a creative process. A solution to this problem requires the application of a holistic, cost-effective, and collaborative approach to securing systems. This book is a perfect follow-on to the message developed in Core Software Security: Security at the Source * in that it addresses a second critical challenge in developing software: security ... Purchase answer to see full attachment