Issuu

You CAN Stop Stupid

You CAN Stop Stupid Stopping Losses from Accidental and Malicious Actions Ira Winkler Dr. Tracy Celaya Brown

You CAN Stop Stupid: Stopping Losses from Accidental and Malicious Actions Copyright © 2021 by John Wiley & Sons, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-1-119-62198-0 ISBN: 978-1-119-62206-2 (ebk) ISBN: 978-1-119-62204-8 (ebk) Manufactured in the United States of America No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or website may provide or recommendations it may make. Further, readers should be aware that Internet websites listed in this work may have changed or disappeared between when this work was written and when it is read. For general information on our other products and services please contact our Customer Care Department within the United States at (877) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com. Library of Congress Control Number: 2019956718 Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.

To my incredible wife, Adriana, who pushed me harder to write this book than I pushed myself. —Ira To my extraordinary husband, Mel, and my wonderful family, I love and appreciate you more than words can ever express. —Tracy

About the Authors Ira Winkler, CISSP, is president of Secure Mentem and author of Advanced Persistent Security. He is considered one of the world’s most influential security professionals. Ira began his career at the National Security Agency (NSA), where he served in various roles as an intelligence and computer systems analyst. He has since served in other positions supporting the cybersecurity and risk management programs in organizations of all sizes. His specialty is the human aspects of technology and loss mitigation. He has received several lifetime achievement awards, including the CSO COMPASS Award, which dubbed him “The Awareness Crusader.” Ira has written books and speaks around the world about cybersecurity, risk management, and the human aspects of security and technology. Ira can be reached through his website at www.irawinkler.com. Dr. Tracy Celaya Brown, CISSP, is a sought-after IT and business consultant and the president of Go Consulting International. Clients consider her their “secret weapon” as she helps organizations define and implement their security strategy and develop a solid organizational culture of security. Committed to making the digital world more secure and influencing the next wave of IT and security professionals, she is also a facilitator, researcher, author, innovative leader, and an awardwinning international speaker. Dr. Tracy Celaya Brown can be reached through her website at DrTre.com.

About the Technical Editors Adam Shostack is a leading expert on threat modeling, and a consultant, entrepreneur, technologist, author, and game designer. He’s a member of the BlackHat Review Board, and he helped create the CVE. He currently assists many organizations to improve their security via Shostack & Associates and advises startups, including as a Mach37 Star Mentor. While at Microsoft, he drove the Autorun fix into Windows Update, was the lead designer of the SDL Threat Modeling Tool v3, and created the Elevation of Privilege game. Adam is the author of Threat Modeling: Designing for Security and the co-author of The New School of Information Security. Dr. Lance Hayden has 30 years of experience in the information security field, a career that includes roles in industry, government, and academia. He is the chief information security strategist for Vericast, as well as a professor at the University of Texas School of Information. Dr. Hayden’s research and expertise includes understanding information security awareness and behavior, and he is the author of People-Centric Security: Transforming Your Enterprise Security Culture.

Acknowledgments

book like this represents the experiences and lessons learned throughout our entire careers. As such, we owe a debt of gratitude to many people, some of whom we’ve lost touch with. So to all of you, the best we can do is send you good karma and hope we have somehow returned the favor. There are, however, a few people to whom we need to truly express our thanks. First is Jim Minatel, who worked with us to determine the book we really wanted to write and allowed us to share our passion and experiences with you, the reader. We also owe an immense debt of gratitude to Kelly Talbot, our development editor, who kept us from sounding stupid and helped us get our points across. During the review process, we cringed every time we saw comments from Lance Hayden and Adam Shostack, our technical editors. The cringes were due to the fact that we knew that each of their comments were well thought out, would add immensely to the quality of the book, and would require us to do a lot of research and hours of more writing. They both have an incredible breadth and depth of experience in the field and truly know how to incorporate research into practice. If you find value in this book, it is as much a credit to them as it is to us. Dr. Nicklas Dahlstrom of Emirates also provided incredibly valuable guidance in forming our thoughts on the integration of safety science with mitigating userinitiated loss. We likewise owe a massive thanks to Adriana Winkler, who read everything to ensure that it made sense to laypersons as well as to the technical experts. We also want to give a special thanks to Rupin Kotecha of Digital Guru, who was the catalyst for putting us in contact with Jim Minatel to get this book started. Finally, we need to thank Britta Glade of RSA Conference, who was the instigator for our working together. —Ira Winkler and Dr. Tracy Celaya Brown

Foreword

o, here it is, in your hands. A book with a message that took the field of cybersecurity only a couple of years—decades at most— to come around to. Its premise is something that human factors professionals wish they could get through to the people they work with every day: the medical device manufacturers, the cockpit designers, the “autonomous” vehicle developers, the construction site planners, the procedure writers—if they could just get this simple message. Spoiler alert, this is the message: If your people are doing stupid things, it’s not because you have stupid people. It’s because you have a stupid system. And then to think that human factors is a field that’s been around for almost 80 years. It was at the basis of the discoveries that led to this premise. Design a cockpit that puts two toggle switches next to each other—one for the landing gear, and the other for the flaps—and you are going to get belly landings. Which the new, bigger, badder Boeing B-17 bomber was getting a lot of during WWII. The solution was not punishing the errant pilots. It wasn’t putting up posters exhorting them to try harder. It wasn’t mounting an incident counter on the wall that announced how many days had gone by without a fellow B-17 pilot planting the aircraft on its belly. As long as the toggle switches were inviting pilots to mix them up, then pilots would mix them up. In 1943, Alphonse Chapanis, a human factors pioneer, fashioned a little flap handle and a little wheel in a workshop and mounted them on the respective toggle switches of some of the B-17s. The ones that were thus equipped never belly-landed again. A gear lever that looks and feels like a wheel, and a flap handle that looks and feels like a flap, now constitute a design and certification requirement for airplane cockpits. If your people are doing stupid things, then you have a stupid system. So, go fix your system. As Ira and Tracy put it, “The simple fact is that a user can’t initiate loss unless an organization creates an environment that puts them in a position to do so.” When you suffer a loss, it is, of course, attractive to gravitate to emotionally satisfying and low-cost interventions. Blame the person who messed things up. Hold them accountable. But Ira and Tracy have a different, and more sustainable, message for you. If you want to talk

xiv Foreword about accountability, then you are actually accountable for setting your people, your users, up for success. You are accountable for avoiding safety barriers that get unreasonably in the way of work, which leads to undesired side effects. You are accountable for showing nonjudgmental curiosity in how work actually gets done, rather than how you, or your designers, imagined it to be done. You are accountable for giving your people error-resistant and error-tolerant designs to work with. You are accountable for reducing the resource constraints and goal conflicts that set your system up for drifting into failure. You are accountable for valuing your people’s native resilience and adaptive capacity over dogmatic, strict rule-following. And you are accountable for identifying and enhancing the capacities in your people that make things go well. There is so much you can do to stop “stupid.” But you need to see “stupid,” not as the root cause of your problems. If you discover “stupid” somewhere, then that is just the beginning of your inquiry, of your curiosity, of your journey toward improvement. “Stupid” comes from somewhere. It is an effect, an outcome—not a cause. When you start looking behind that label “stupid,” you will find lots of things that actually make sense: where people were looking at the time, which things they considered important to focus on, what knowledge they brought to bear, which interacting goals they were trying to achieve simultaneously, what resource constraints they were trying to make up for, what work they were trying to get done despite all the obstacles you may well have helped put in their way. If you think your people were doing “stupid” things, then muster the courage to go behind that label and face up to what you find. Stop stupid by fixing your system. Because otherwise the label “stupid” might well stop with you, and stick. Sidney Dekker Professor, Griffith University (Australia) and Delft University of Technology (Netherlands)

Contents at a Glance Forword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii

I Stopping Stupid Is Your Job. . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 Failure: The Most Common Option. . . . . . . . . . . . . . . . . . . . . 3 2 Users Are Part of the System. . . . . . . . . . . . . . . . . . . . . . . . . 11 3 What Is User-Initiated Loss?. . . . . . . . . . . . . . . . . . . . . . . . . . 17 II Foundational Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4 Risk Management.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5 The Problems with Awareness Efforts . . . . . . . . . . . . . . . . . 65 6 Protection, Detection, and Reaction. . . . . . . . . . . . . . . . . . . 79 7 Lessons from Safety Science . . . . . . . . . . . . . . . . . . . . . . . . . 89 8 Applied Behavioral Science. . . . . . . . . . . . . . . . . . . . . . . . . . 103 9 Security Culture and Behavior. . . . . . . . . . . . . . . . . . . . . . . 123 10 User Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 11 The Kill Chain.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 12 Total Quality Management Revisited . . . . . . . . . . . . . . . . . 167

xvi Contents at a Glance

III Countermeasures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 13 Governance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 14 Technical Countermeasures. . . . . . . . . . . . . . . . . . . . . . . . . 197 15 Creating Effective Awareness Programs. . . . . . . . . . . . . . .225 IV Applying Boom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 16 Start with Boom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 17 Right of Boom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 18 Preventing Boom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 19 Determining the Most Effective Countermeasures . . . . . 289 20 Implementation Considerations . . . . . . . . . . . . . . . . . . . . . 303 21 If You Have Stupid Users, You Have a Stupid System. . . . 317 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325

Contents Forword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii

I Stopping Stupid Is Your Job. . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 Failure: The Most Common Option. . . . . . . . . . . . . . . . . . . . . 3 History Is Not on the Users’ Side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Today’s Common Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Operational and Security Awareness. . . . . . . . . . . . . . . . . . . . . . . 6 Technology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Governance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 We Propose a Strategy, Not Tactics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Users Are Part of the System. . . . . . . . . . . . . . . . . . . . . . . . . 11 Understanding Users’ Role in the System . . . . . . . . . . . . . . . . . . . . . 11 Users Aren’t Perfect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 “Users” Refers to Anyone in Any Function. . . . . . . . . . . . . . . . . . . . . 13 Malice Is an Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 What You Should Expect from Users. . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 What Is User-Initiated Loss?. . . . . . . . . . . . . . . . . . . . . . . . . . 17 Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Physical Losses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Crime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 User Malice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Social Engineering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 User Error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Inadequate Training. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

xviii Contents Technology Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Design and Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 User Enablement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Shadow IT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Confusing Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 UIL Is Pervasive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

II Foundational Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4 Risk Management.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Death by 1,000 Cuts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 The Risk Equation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Threats.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Vulnerabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Risk Optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Risk and User-Initiated Loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5 The Problems with Awareness Efforts . . . . . . . . . . . . . . . . . 65 Awareness Programs Can Be Extremely Valuable . . . . . . . . . . . . . . 65 Check-the-Box Mentality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Training vs. Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 The Compliance Budget.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Shoulds vs. Musts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 When It’s Okay to Blame the User. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Awareness Programs Do Not Always Translate into Practice. . . . . 74 Structural Failings of Awareness Programs. . . . . . . . . . . . . . . . . . . . 75 Further Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6 Protection, Detection, and Reaction. . . . . . . . . . . . . . . . . . . 79 Conceptual Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Contents

xix

Detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Reaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Mitigating a Loss in Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Mitigating Future Incidents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Putting It All Together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7 Lessons from Safety Science . . . . . . . . . . . . . . . . . . . . . . . . . 89 The Limitations of Old-School Safety Science. . . . . . . . . . . . . . . . . . 91 Most UIL Prevention Programs Are Old-School . . . . . . . . . . . . . . . . 93 The New School of Safety Science. . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Putting Safety Science to Use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Safety Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 The Need to Not Remove All Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . 98 When to Blame Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 We Need to Learn from Safety Science. . . . . . . . . . . . . . . . . . . . . . . 100

8 Applied Behavioral Science. . . . . . . . . . . . . . . . . . . . . . . . . . 103 The ABCs of Behavioral Science. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Antecedents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Consequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Engineering Behavior vs. Influencing Behavior. . . . . . . . . . . . 120

9 Security Culture and Behavior. . . . . . . . . . . . . . . . . . . . . . . 123 ABCs of Culture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Types of Cultures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Subcultures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 What Is Your Culture?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Improving Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Determining a Finite Set of Behaviors to Improve. . . . . . . . . .134 Behavioral Change Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Traditional Project Management . . . . . . . . . . . . . . . . . . . . . . . . 137 Change Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

xx Contents Is Culture Your Ally?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

10 User Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 The Importance of Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 The Hidden Cost of Awareness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Types of Awareness Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Compliance Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Engagement Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Behavioral Improvement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Tangible ROI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Intangible Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Day 0 Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Deserve More . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

11 The Kill Chain.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Kill Chain Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 The Military Kill Chain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 The Cyber Kill Chain and Defense in Depth.. . . . . . . . . . . . . . . 155 Deconstructing the Cyber Kill Chain. . . . . . . . . . . . . . . . . . . . . . . . . 157 Phishing Kill Chain Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Other Models and Frameworks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Applying Kill Chains to UIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

12 Total Quality Management Revisited . . . . . . . . . . . . . . . . . 167 TQM: In Search of Excellence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Exponential Increase in Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Principles of TQM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 What Makes TQM Fail? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Other Frameworks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Product Improvement and Management. . . . . . . . . . . . . . . . . 177 Kill Chain for Process Improvement. . . . . . . . . . . . . . . . . . . . . . 178

Contents

xxi

COVID-19 Remote Workforce Process Activated. . . . . . . . . . . . . . . 178 Applying Quality Principles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

III Countermeasures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 13 Governance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Defining the Scope of Governance for Our Purposes . . . . . . . . . . 184 Operational Security or Loss Mitigation. . . . . . . . . . . . . . . . . . 185 Physical Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Personnel Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186 Traditional Governance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Policies, Procedures, and Guidelines. . . . . . . . . . . . . . . . . . . . . 188 In the Workplace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Security and the Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Analyzing Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Grandma’s House. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

14 Technical Countermeasures. . . . . . . . . . . . . . . . . . . . . . . . . 197 Personnel Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Background Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Continuous Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Employee Management Systems. . . . . . . . . . . . . . . . . . . . . . . . 201 Misuse and Abuse Detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Data Leak Prevention. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Physical Countermeasures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Access Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Surveillance and Safety Systems. . . . . . . . . . . . . . . . . . . . . . . . 204 Point-of-Sale Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Inventory Systems and Supply Chains. . . . . . . . . . . . . . . . . . . . 207 Computer Tracking Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Operational Countermeasures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Accounting Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

xxii Contents Customer Relationship Management . . . . . . . . . . . . . . . . . . . . 210 Operational Technology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Workflow Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Cybersecurity Countermeasures. . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 The 20 CIS Controls and Resources. . . . . . . . . . . . . . . . . . . . . . 212 Anti-malware Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Whitelisting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Firewalls.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Intrusion Detection/Prevention Systems . . . . . . . . . . . . . . . . . 215 Managed Security Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Backups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Secure Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Automated Patching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Vulnerability Management Tools . . . . . . . . . . . . . . . . . . . . . . . . 217 Behavioral Analytics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Data Leak Prevention. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Web Content Filters/Application Firewalls. . . . . . . . . . . . . . . . .218 Wireless and Remote Security. . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Mobile Device Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Multifactor Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Single Sign-On. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Nothing Is Perfect.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Putting It All Together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

15 Creating Effective Awareness Programs. . . . . . . . . . . . . . .225 What Is Effective Awareness?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Governance as the Focus.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Where Awareness Strategically Fits in the Organization. . . . . . . . 229 The Goal of Awareness Programs. . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Changing Culture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Defining Subcultures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Interdepartmental Cooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Contents xxiii The Core of All Awareness Efforts. . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Business Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Culture and Communication Tools. . . . . . . . . . . . . . . . . . . . . . . 238 Putting It Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Gamification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Gamification Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Structuring Gamification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Gamification Is Not for Everyone. . . . . . . . . . . . . . . . . . . . . . . . 248 Getting Management’s Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Awareness Programs for Management. . . . . . . . . . . . . . . . . . . 249 Demonstrate Clear Business Value . . . . . . . . . . . . . . . . . . . . . . 250 Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Experiment.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

IV Applying Boom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 16 Start with Boom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 What Are the Actions That Initiate UIL? . . . . . . . . . . . . . . . . . . . . . . 257 Start with a List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Order the List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Governance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 User Experience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Prevention and Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Awareness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Feeding the Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Stopping Boom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

17 Right of Boom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Repeat as Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 What Does Loss Initiation Look Like? . . . . . . . . . . . . . . . . . . . . . . . . 267

xxiv Contents What Are the Potential Losses? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Preventing the Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Compiling Protective Countermeasures. . . . . . . . . . . . . . . . . . 273 Detecting the Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Before, During, and After. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Mitigating the Loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Determining Where to Mitigate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Avoiding Analysis Paralysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Your Last Line of Defense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

18 Preventing Boom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Why Are We Here?.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Governance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Awareness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Technology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Step-by-Step.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

19 Determining the Most Effective Countermeasures . . . . . 289 Early Prevention vs. Response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Start with Governance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Understand the Business Goal. . . . . . . . . . . . . . . . . . . . . . . . . . 293 Start Left of Boom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Consider Technology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Prioritize Potential Loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Define Governance Thoroughly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Matrix Technical Countermeasures. . . . . . . . . . . . . . . . . . . . . . . . . . 299 Creating the Matrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Define Awareness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 It’s Just a Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

20 Implementation Considerations . . . . . . . . . . . . . . . . . . . . . 303 You’ve Got Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Contents

xxv

Weak Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Resources, Culture, and Implementation. . . . . . . . . . . . . . . . . 305 Lack of Ownership and Accountability . . . . . . . . . . . . . . . . . . . 307 One Effort at a Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Change Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Adopting Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Governance, Again . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 Business Case for a Human Security Officer. . . . . . . . . . . . . . . . . . 315 It Won’t Be Easy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

21 If You Have Stupid Users, You Have a Stupid System. . . . 317 A User Should Never Surprise You. . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Perform Some More Research. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Start Somewhere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Take Day Zero Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 UIL Mitigation Is a Living Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Grow from Success. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 The Users Are Your Canary in the Mine . . . . . . . . . . . . . . . . . . . . . . 322

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325

Introduction

e believe that the title of a book is perhaps its most critical characteristic. We acknowledge that the title, You Can Stop Stupid is controversial. We had considered other possible titles, such as Stopping Human Attacks, but such a title does not convey the essence of this book. Although we do intend to stop attacks that target your users, the same methodology will stop attacks by malicious insiders, as well as accidents. The underlying problem is not that users are the targets of attacks or that they accidentally or maliciously create damage, but that users have the ability to make decisions or take actions that inevitably lead to damage. That is the fundamental issue this book addresses, and it makes a critical distinction: The problem lies not necessarily in the user, but also in the environment surrounding the people performing operational functions.

What Is Stupid? Managers, security specialists, IT staff, and other professionals often complain that employees, customers, and users are stupid. But what is “stupid”? The definition of “stupid” is having or showing a great lack of intelligence or common sense. First, let’s examine the attribute of showing a great lack of intelligence. When your organization hires and reviews people, you generally assess whether they have the requisite intelligence to perform the required duties. If you did hire or retain an employee knowing that they lacked the necessary intelligence to do the job, who is actually stupid in this scenario: the employee or the employer? Regarding a person who shows a great lack of common sense, there is a critical psychological principle regarding common sense: You cannot have common sense without common knowledge. Therefore, someone who is stupid for demonstrating a great lack of common sense is likely suffering from a lack of common knowledge. Who is responsible for ensuring that the person has such common knowledge? That responsibility belongs to the people who place or retain people in positions within the organization.

xxviii Introduction In general, don’t accuse someone in your organization of being stupid. Instead, identify and adjust your own failings in bad employment or training practices, as well as the processes and technologies that enable the “stupidity.”

Do You Create Stupidity? When people talk about employee, customer, and other user stupidity, they are often thinking of the actions those users take that cause damage to your organization. In this book, we refer to that as user-initiated loss (UIL). The simple fact is that a user can’t initiate loss unless an organization creates an environment that puts them in a position to do so. While organizations do have to empower employees, customers, and other users to perform their tasks, in most environments, there is little thought paid to proactively reducing UIL. It is expected that users will make mistakes, fall for tricks, or purposefully intend to cause damage. An organization needs to consider this in its specification of business practices and technological environments to reduce the potential for user-initiated loss. Even if you reduce the likelihood for people to cause harm, you cannot eliminate all possibilities. There is no such thing as perfect security, so it is folly to rely completely on prevention. For that reason, wise organizations also embed controls to detect and reduce damage throughout their business processes.

How Smart Organizations Become Smart Consider that large retail stores, such as Target, have a great deal to lose from a physical standpoint. Goods can be physically stolen. Cashiers can potentially steal money. These are just a couple of common forms of loss in retail environments. To account for the theft of goods, extensive security controls are in place. Cameras monitor areas where goods are delivered, stored, and sold. Strict inventory control systems track everything. Store associates are rewarded for reporting potential shoplifters. Security guards, sometimes undercover, patrol the store. High-value goods are outfitted with sensors, and sensor readers are stationed at the exits.

Introduction xxix

From a cash perspective, cashiers receive and return their cash drawers in a room that is heavily monitored. They have to “count in” the cash and verify the cash under the watchful eyes of the surveillance team. The cash registers keep track of and report all transactions. Accounting teams also verify that all cash receipts are within a reasonable level of expected error. Also, as important, the use of credit cards reduces the opportunity for employees to mishandle or steal cash. Despite all of these measures, there are still losses. Some loss is due to simple errors. A cashier might accidentally give out the wrong change. There might be a simple accounting error. Employees might figure out how to game the system and embezzle cash. Someone in the self-checkout line might accidentally not scan all items. Criminals may still be able to outright steal goods despite the best controls. Regardless, the controls proactively mitigate and detect large amounts of losses. There are likely further opportunities for mitigating loss, and new studies can always be consulted to determine varying degrees to which they might be practical. An excellent example of an industry that intelligently mitigates risk is the scuba diving industry. Author Ira Winkler is certified as a Master Scuba Diving Trainer and first heard the expression “you can’t stop stupid” during his scuba instructor training. The instructor was telling all the prospective instructors that there will always be some students who do not pay attention to safety rules. It is true that scuba diving provides for an almost infinite number of ways for students to do something potentially dangerous and even deadly. Despite this, scuba diving is statistically safer than bowling. When you consider how that may be, you have to understand that most scuba instruction involves safety protocols. Reputable dive operators are affiliated with professional associations, such as the Professional Association of Diving Instructors (PADI). PADI examines how dive accidents have occurred and works with members to develop safety protocols that all members must follow. For example, when Ira would certify new divers, all students had to take course work specifying safe diving practices. They also had to go through a health screening process and demonstrate basic swimming skills and comfort in the water. They then had to demonstrate the required diving skills in a pool.

xxx Introduction When it comes to certifying people in open water, all equipment is inspected by the students and instructors prior to diving. The potential dive location is chosen based upon the calmness and clarity of the water and limited depth so that students don’t accidentally go too deep. Before the dive, there is a complete dive briefing, so students know what to expect, as well as safety precautions and instructions about what to do if a diver runs into trouble. The instructors are familiar with the location and any potential hazards. The number of students is limited, and dive master assistants accompany the group as available to ensure safety. Additionally, instructors are required to ensure there is a wellequipped first aid kit, an emergency oxygen supply, and information about the nearest hospital and hyperbaric chamber. To become an instructor, Ira went through hundreds of hours of training, especially including detailed training about how to handle likely and unlikely problems. This training includes extensive first aid training. From a risk mitigation strategy, instructors maintain personal liability insurance. Similarly, the sponsoring school maintains liability insurance while also paying for supplemental insurance to cover potential injuries to students. The dive facilities, be they pools, boats, quarries, or so on, also maintain liability insurance. Essentially, PADI and other professional associations have proactively examined where potential injuries may occur and determined how to prevent them as best as possible. Although some accidents will inevitably occur, there is extensive preparation for those incidents, and the result is that diving is a comparatively safe activity.

Not All Industries Are as Smart Retail loss prevention and dive instruction have clearly created comprehensive strategies for preventing and mitigating loss that accounts for human error and malfeasance. Unfortunately, many industries, and ironically even many practices within the same industries that are otherwise relatively secure, are not dealing with human error well. For example, Target, which generally has an outstanding loss prevention practice, failed when it came to a data breach where 110,000,000 credit records were stolen. When an organization fails to account for humor error and malfeasance, and fails to put in sufficient layers of controls, the losses can be devastating. When organizations fail to implement an effective process

Introduction xxxi

of risk mitigation to account for user-initiated loss, there is a great deal of blame to go around, but organizations tend to point to the “stupid user” who made a single error. No case is more notorious for this than the massive Equifax data breach. When Richard Smith, former CEO of Equifax, testified to Congress regarding the infamous data breach, he laid the blame for the data breach squarely on an administrator for not applying a critical patch for a vulnerability in a timely manner. Not immediately applying a patch is not uncommon for organizations the size of Equifax. However, a detailed investigation showed that there was a gross systemic failure of Equifax’s security posture. After all, not only did Equifax allow the criminal in, the criminal was able to explore the network undetected for six weeks, breach dozens of other systems, and download data for another six weeks. The attack was detected only after Equifax renewed a long-expired digital certificate that was required to run a security tool. This type of scenario is common in computer-related incidents. Whether it is the failing of an individual user or someone on the IT team, a single action, or failure to act, can initiate a major loss. However, for there to be a major loss, there has to be a variety of failures to allow an attack to be successful. Similar failures happen in all operational units of organizations. Any operational process that does not analyze where and how people can intentionally or unintentionally cause potential loss enables that loss. The goal of this book is to help the reader identify and mitigate actions where users might initiate loss, and then detect the actions initiating loss and mitigate the potential damage from the harmful acts. Just as the diving and loss prevention industries have figured out how to effectively mitigate risk arising from human failures, you can do the same within your environment. By adopting the proper sciences and strategies laid out in this book, you can effectively mitigate userinitiated loss.

Deserve More When we consult with organizations, we find that one of the biggest impediments to adequately addressing user-initiated loss is not getting the required resources to do so. The underlying reason is that all too frequently, people responsible for loss reduction fail to demonstrate a

xxxii Introduction return on investment. In short: You get the budget that you deserve, not the budget that you need. You need to deserve more. If people believe scuba diving is dangerous, the scuba industry will collapse. If accounting systems fail, public companies can suffer dire consequences. These industries recognize these dangers, and they take steps to demonstrate their value and viability. However, many other professions do not adequately address risk and prove their worth. The common strategy of dealing with user-initiated loss is to focus on awareness and letting people know how not to initiate a loss. Clearly, this fails all too frequently. Therefore, money put into preventing the loss appears wasted. There is no clear sense of deserving more resources. It is our goal that you will be able to apply our strategies and show you are deserving of the resources you need to properly mitigate the potential losses that you face.

Reader Support for This Book We appreciate your input and questions about this book. You can contact us at www.YouCanStopStupid.com.

How to Contact the Publisher If you believe you’ve found a mistake in this book, please bring it to our attention. At John Wiley & Sons, we understand how important it is to provide our customers with accurate content, but an error may occur even with our best efforts. To submit your possible errata, please email it to our Customer Service Team at wileysupport@wiley.com with the subject line “Possible Book Errata Submission.”

How to Contact the Authors Ira Winkler can be reached through his website at www.irawinkler .com. Dr. Tracy Celaya Brown can be reached through her website at DrTre.com. Additional material will be made available at the book’s website, www.youcanstopstupid.com.

Stopping Stupid Is Your Job

hile professionals bemoan how users make their job difficult, the problem is that this difficulty should be considered part of the job. No matter how well-meaning or intelligent a user may be, they will inevitably make mistakes. Alternatively, the users might have malicious intent and intend to commit acts that cause loss. Considering the act “stupid” assists a malicious party in getting away with their intent. Fundamentally, you don’t care about an individual action by a user; you care that the action may result in damage. This is where professionals need to focus. Yes, you want to have awareness so users are less likely to initiate damage. However, you have to assume that users will inevitably make a potentially harmful action, and your job is to mitigate that action in a cost-effective way. Part I lays the groundwork for being able to address the potential damage that users can initiate. The big problem that we perceive regarding the whole concept of securing the user—as some people refer to it, creating the human firewall—is that people think that the solution to stopping losses related to users is awareness. To stop the problem, you have to understand that awareness is just one tactic among many, and the underlying solution is that you need a comprehensive strategy to prevent users from needing to be aware, to create a culture where people behave appropriately through awareness or other methods, and to detect and mitigate loss before it gets out of hand. Any individual tactic will be ineffective at stopping the problem of user-initiated loss (UIL). As you read the chapters in Part I, you should come away with the holistic nature of the problem and begin to perceive the holistic solutions required to address the problem.

1 A

Failure: The Most Common Option

s security professionals, we simultaneously hear platitudes about how users are our best resource, as well as our weakest link. The people contending that users are the best resource state that aware users will not only not fall prey to the attacks, they will also respond to the attacks and stop them in their tracks. They might have an example or two as well. Those contending that the users are the weakest link will point to the plethora of devastating attacks where users failed, despite their organizations’ best efforts. The reality is that regardless of the varying strengths that some users bring to the table in specific circumstances, users generally are still the weakest link. Study after study of major data breaches and computer incidents show that users (which can include anyone with access to information or computer assets) are the primary attack vector or perpetrator in an overwhelming percentage of attacks. Starting with the lowest estimate, in 2016, a Computer Technology Industry Association (CompTIA) study found that 52 percent of all attacks begin by targeting users (www.comptia.org/about-us/newsroom/ press-releases/2016/07/21/comptia-launches-training-to-stembiggest-cause-of-data-breaches). In 2018, Kroll compiled the incidents reported to the UK Information Commissioner’s Office and determined that human error accounted for 88 percent of all data breaches (www.infosecurity-magazine.com/news/ico-breach-reportsjump-75-human/). Verizon’s 2018 Data Breach Investigations Report (DBIR) reported that 28 percent of incidents were perpetrated by malicious insiders (www.documentwereld.nl/files/2018/VerizonDBIR_2018-Main_report.pdf). Although the remaining 72 percent of incidents were not specifically classified as resulting from an insider mistake or action, their nature indicates that the majority of the attacks perpetrated by outsiders resulted from user actions or mistakes.