“Why We Wrote 'Big Breaches' and Why Should You Care?”

In a recent podcast, our host opened with this question, “So tell me, why do we need another security book?” It was a great question and on the official release day, we want to share a few thoughts about this question and why you should consider buying copies for yourself and your teams. Although you can listen to the podcast to hear our views, Royal Hansen, VP of Security at Google, who so graciously wrote the foreword for the book effectively sums it up: “Neil and Moudy have written a book … making the subject accessible to audiences who are not usually addressed by cybersecurity books … I see in Big Breaches a category that blazes a different and challenging trail— bridging the divide between the deep technical details of attacks and the practical technical, corporate, and societal actions which would make us less vulnerable.”

When the book, The Phoenix Project came out, most readers muttered to themselves, "Wait! This book is about my company! Who told them we run things this way?" One of the primary themes from the book is Dev, Ops, and Security teams need to work better together and shift from what Adam Grant calls relationship conflict to task conflict. Grant defines relationship conflict as "personal, emotional clashes that are filled not just with friction but also with animosity.” Whereas, task conflicts are clashes about ideas and opinions, such as how to implement a better authentication approach for our public-facing APIs. We wrote the book in the spirit of shifting teams from working against each other and focusing on the “task conflict” to help their organizations close security gaps.

One of the fun aspects of co-authoring the Big Breaches book together was the ability to debate the ideas and work through different points of view. We had no relationship conflict because we shared a common goal and vision. But we had lots of debates that challenged each of us to think again about our assumptions. We believe the chapters we wrote together are better because they were pressure tested through our debates, and we had the chapters reviewed by dozens of colleagues. Better answers typically surface when teams with diverse points of view engage in constructive dialogue, and further strengthens those shared and common goals.

Which brings us to why we wrote another security book: our desire is that many audiences read and discuss the case studies in the book together. 

For example:

• Security, engineering, and operations teams discuss the breaches at Facebook, Equifax, Capital One and then debate how they would have done things differently. How can first-party and third-party software vulnerabilities be identified and remediated so that they cannot be as easily exploited, whether by amateurs or nation-state attackers?
• Board members, CEOs, technology executives, and heads of government agencies discuss the breaches at Yahoo, OPM, and Marriott, and discuss prioritization and investment in their security programs. Take, for example, the OPM breach, where extremely sensitive identity data of over 20 million government employees was stolen by suspected Chinese nation-state-funded hackers. Using that case study, teams can discuss how they would address known vulnerabilities when there is pressure on resources and funding. What would they do differently? Request more funding? Deploy alternative defenses? Our book has two specific chapters on advice to members of boards of directors, and to technology/security executives -- we encourage both audiences to read both chapters so that they know what to expect from each other.
• Professors of computer science and computer security discuss the breach case studies in their classes, similar to how Harvard business case studies are used in MBA classes. Although introductory classes in fields such as mechanical engineering study the failure of the Tacoma Narrows bridge, we probably do not do enough to educate those entering computer science about the failures of the field or the immense responsibility that bears on software developers of critical systems.

This type of "case study" method has been demonstrated to produce great results for the participants. Cybersecurity must take a place similar to safety in the fields of mechanical and electrical engineering. By placing ourselves in the middle of these case studies, we allow our cross-functional teams to shift from theory to practice, and work out task conflict in assessing the readiness of your organization against the root causes of breach.

Neil and Moudy have written a book … making the subject accessible to audiences who are not usually addressed by cybersecurity books

Royal Hansen (VP of Security @ Google)

On the official launch day of our book, we hope that many teams will use the book to have productive dialogue that leads to taking action and strengthening their organization’s defense. For us, there is no greater joy and reward than learning from you that our work has made a difference in yours! 

Written by Neil and Moudy