What do you think?
Rate this book
A Data-Driven Computer Defense: A Way to Improve Any Computer Defense
Most organizations are using inefficient computer security defenses which allow hackers to break in at will. It's so bad that most companies have to assume that it is already or can easily be breached. It doesn't have to be this way! A data-driven defense will help any entity better focus on the right threats and defenses. It will create an environment which will help you recognize emerging threats sooner, communicate those threats faster, and defend far more efficiently. What is taught in this book...better aligning defenses to the very threats they are supposed to defend against, will seem commonsense after you read them, but for reasons explained in the book, aren't applied by most companies. The lessons learned come from a 30-year computer security veteran who consulted with hundreds of companies, large and small, who figured out what did and didn't work when defending against hackers and malware. Roger A. Grimes is the author of nine previous books and over 1000 national magazine articles on computer security. Reading A Data-Driven Computer Defense will change the way you look at and use computer security for now on. This is the revised 2nd Edition, which contains new, expanded chapters, operational advice, and many more examples you can use to craft your own data-driven defense.
266 pages, Paperback
Published April 2, 2019
14 people are currently reading
37 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 of 1 review
February 3, 2023
This is the 2nd edition of a book that was apparently first published in 2017.
The basic thesis is this: In security, design your priority list of what needs fixing based first on successful attacks in your own company. Why do companies not do this? Because they have entrenched systems that are "too hard to fix" or where operational downtime would jeopardize the business. Because they won't fix those core things, they fix things that don't matter and wonder why their security profiles are not becoming stronger. According to Grimes, the two areas that are going to dominate your list are: (1) Unpatched systems (and those systems are: browser add-ons, networked, services/daemons, OSs, and productivity applications [p. 136]); and (2) social engineering (for example, p. 62). But the identification of these two specific threat areas is not the point: You have to gather your own data based on your own situation, and figure it out yourself, especially by identifying root causes. And get those threats into priority order! (Grimes notes frequently CISOs who have a list of identified threats from external audits, but because they're in no particular order, they don't know where to start.) Additionally, Grimes repeatedly reminds us that if we fix root causes, we will eliminate whole categories of risk. For example, in a company I know quite well, Chrome add-ons cause of a lot of problems: The answer? Whitelist the add-ons you allow. This is a decision that takes courage, but if you really care, and you can get buy-in from the business, it's going to remove most of the threats from the complex world of add-ons.
Grimes is quite negative on following the security press and common wisdom. For instance, he goes back to Meltdown and Spectre, which were attacks on chip/firmware flaws (pp. 137-139). At the time, Grimes argued, unpopularly, that there were no attacks in the wild; so why fix them, especially given the expense of re-flashing firmware. Two years later, there were few if any attacks exploiting Meltdown and Spectre; and the fixes that did come out were almost harder to manage than the initial problem. Thus, Grimes would have advised: Why are you wasting cycles trying to fix an essentially hypothetical exposure instead of working on the attacks that have been successful in your own world?
What else? Let's talk about the scope of this book. Grimes notes the now classic NIST CSF breakdown of the components of a good security program, namely: Identify, Protect, Detect, Respond, and Recover (p. 185). This book is about only the first three: Identify, Protect, and Detect. In other words, this book does not replace what you're already doing: It refines what's on the "front end" of your program.
The book contains illuminating case studies. For example, remember Conficker? This was a nasty attack that took over key aspects of Windows and then aggressively spread to other machines. Microsoft's first attempt to fix this was to focus on patching. That helped. But it didn't help enough. They took a data-driven approach, and discovered that the key attack vector was the auto-run feature on USB drives. So Microsoft changed the default to not auto-run. This change drastically reduced the number of systems infected. They wouldn't have found this without counting up the number of computers attacked by various means.
I would say that this book has two flaws. The first is that it talks perhaps too much about Fortune 50 companies that have spent tons of money on fixes that haven't worked -- and when they turned to a data-driven approach as described here, they were more successful. That is, they shifted the emphasis of their big spends. But what about smaller companies that don't have that much money? Grimes would say that they should still follow his methodology, but I'm not so sure if that is quite the place to start: I think such companies might first prioritize the new generation of malware hunting tools such as Carbon Black, CrowdStrike, and SentinelOne. You would come to this decision following a data-driven approach, but I think nowadays there's more certainly around the needed suite.
The second flaw is that many of the issues here describe problems with the Windows operating system and Microsoft products such as ActiveDirectory and Office. Grimes is right that in the last two decades, Microsoft has radically upped its game with regard to security. Still, I'm not so sure that's enough because of the complexity of such an all-in-one solution. In our search for root causes, maybe it's time to acknowledge the fact that Microsoft products are enumerated over and over on lists of software with the most CVEs. To Microsoft, I might add Atlassian (built on Java) and parts of the Java ecosystem. Increasingly, I would advise companies to just give up on the whole lot of that stuff, or at least run them in virtualized containers. People who argue I'm wrong have entrenched staffs with expertise in those systems. It's time to move to decoupled SaaS products that can be swapped out (and re-train your staff that is administering AD in the colo).
With regard to the book, I think that means that you look at your top threats and ask the further question: Is there something wrong in the overarching system that results in these threats being the key threats? You might even apply this argument to social engineering. We fear phishing attacks. Why, I wonder, do we even allow links to be clicked in email in the general case? Isn't it time to whitelist those, and turn off the phishing channel altogether? Grimes's answer is more training and awareness (and I agree with that) but I'm kind of dumbfounded that we have live links in email from outside the company in the first place. Let's turn those off or migrate them to more controlled environments (e.g., DMs in Slack).
The basic thesis is this: In security, design your priority list of what needs fixing based first on successful attacks in your own company. Why do companies not do this? Because they have entrenched systems that are "too hard to fix" or where operational downtime would jeopardize the business. Because they won't fix those core things, they fix things that don't matter and wonder why their security profiles are not becoming stronger. According to Grimes, the two areas that are going to dominate your list are: (1) Unpatched systems (and those systems are: browser add-ons, networked, services/daemons, OSs, and productivity applications [p. 136]); and (2) social engineering (for example, p. 62). But the identification of these two specific threat areas is not the point: You have to gather your own data based on your own situation, and figure it out yourself, especially by identifying root causes. And get those threats into priority order! (Grimes notes frequently CISOs who have a list of identified threats from external audits, but because they're in no particular order, they don't know where to start.) Additionally, Grimes repeatedly reminds us that if we fix root causes, we will eliminate whole categories of risk. For example, in a company I know quite well, Chrome add-ons cause of a lot of problems: The answer? Whitelist the add-ons you allow. This is a decision that takes courage, but if you really care, and you can get buy-in from the business, it's going to remove most of the threats from the complex world of add-ons.
Grimes is quite negative on following the security press and common wisdom. For instance, he goes back to Meltdown and Spectre, which were attacks on chip/firmware flaws (pp. 137-139). At the time, Grimes argued, unpopularly, that there were no attacks in the wild; so why fix them, especially given the expense of re-flashing firmware. Two years later, there were few if any attacks exploiting Meltdown and Spectre; and the fixes that did come out were almost harder to manage than the initial problem. Thus, Grimes would have advised: Why are you wasting cycles trying to fix an essentially hypothetical exposure instead of working on the attacks that have been successful in your own world?
What else? Let's talk about the scope of this book. Grimes notes the now classic NIST CSF breakdown of the components of a good security program, namely: Identify, Protect, Detect, Respond, and Recover (p. 185). This book is about only the first three: Identify, Protect, and Detect. In other words, this book does not replace what you're already doing: It refines what's on the "front end" of your program.
The book contains illuminating case studies. For example, remember Conficker? This was a nasty attack that took over key aspects of Windows and then aggressively spread to other machines. Microsoft's first attempt to fix this was to focus on patching. That helped. But it didn't help enough. They took a data-driven approach, and discovered that the key attack vector was the auto-run feature on USB drives. So Microsoft changed the default to not auto-run. This change drastically reduced the number of systems infected. They wouldn't have found this without counting up the number of computers attacked by various means.
I would say that this book has two flaws. The first is that it talks perhaps too much about Fortune 50 companies that have spent tons of money on fixes that haven't worked -- and when they turned to a data-driven approach as described here, they were more successful. That is, they shifted the emphasis of their big spends. But what about smaller companies that don't have that much money? Grimes would say that they should still follow his methodology, but I'm not so sure if that is quite the place to start: I think such companies might first prioritize the new generation of malware hunting tools such as Carbon Black, CrowdStrike, and SentinelOne. You would come to this decision following a data-driven approach, but I think nowadays there's more certainly around the needed suite.
The second flaw is that many of the issues here describe problems with the Windows operating system and Microsoft products such as ActiveDirectory and Office. Grimes is right that in the last two decades, Microsoft has radically upped its game with regard to security. Still, I'm not so sure that's enough because of the complexity of such an all-in-one solution. In our search for root causes, maybe it's time to acknowledge the fact that Microsoft products are enumerated over and over on lists of software with the most CVEs. To Microsoft, I might add Atlassian (built on Java) and parts of the Java ecosystem. Increasingly, I would advise companies to just give up on the whole lot of that stuff, or at least run them in virtualized containers. People who argue I'm wrong have entrenched staffs with expertise in those systems. It's time to move to decoupled SaaS products that can be swapped out (and re-train your staff that is administering AD in the colo).
With regard to the book, I think that means that you look at your top threats and ask the further question: Is there something wrong in the overarching system that results in these threats being the key threats? You might even apply this argument to social engineering. We fear phishing attacks. Why, I wonder, do we even allow links to be clicked in email in the general case? Isn't it time to whitelist those, and turn off the phishing channel altogether? Grimes's answer is more training and awareness (and I agree with that) but I'm kind of dumbfounded that we have live links in email from outside the company in the first place. Let's turn those off or migrate them to more controlled environments (e.g., DMs in Slack).
Displaying 1 of 1 review