Skip to content

Hangout with Evan: July 2018

EvanBradMichaelShelleyJames Williams

Engineers explore architecture and security mechanisms for Hangout with Evan: July 2018.

Summary

## Overview

"Hangout with Evan: July 2018" is an informal webinar-style discussion hosted by Evan (a book author) and Brad (consulting services lead at F-Secure), examining Chapter 5 of Evan's forthcoming book titled "The Information Security Industry is Broken." The chapter focuses on the blame game—the human tendency to assign fault to others rather than accept responsibility when security incidents occur. The conversation emphasizes that while breaches are inevitable, the response to them and how blame is distributed often makes situations worse.

## Key Topics

**What is Blame?** Blame is presented as a human defense mechanism and natural response when things go wrong. It is easier to blame others than to accept personal responsibility, even when multiple factors and people contribute to a failure. The hosts note this extends beyond security into everyday life (road rage, personal relationships, work environments).

**Problems Enabling the Blame Game** Evan identifies five key problems: (1) No shortage of scapegoats—multiple people and systems can be blamed; (2) Living in glass houses—the proverb that those in glass houses should not throw stones, yet security practitioners often do; (3) Fear and reprimand—users reluctant to report security incidents because they fear punishment; (4) Poor attribution—organizations struggle to determine who or what caused a breach and lack proper systems to support attribution; (5) Faulty products and services—IoT devices, cars, and medical devices with security flaws but no recourse for users.

**The Equifax Breach Case Study** Evan walks through the Equifax breach as a detailed example. The breach resulted from an unpatched Apache Struts vulnerability that was months old. Equifax had a formal patching policy requiring patches within 48 hours, followed by a two-stage process including vulnerability scanning. Multiple parties could be blamed: the vendor, employees, the organization's vetting process, executive management's failure to fund security, the security operations team's failure to detect the attack, and the incident response team's failure to test procedures. Blame ultimately fell on three parties: an unnamed individual (blamed by CEO Richard Smith for not patching), Smith himself (who retired with a golden parachute), and CISO Susan Mouldin (who was blamed for having a music composition degree rather than a cybersecurity degree, eventually forcing her to hide her identity).

**Attribution Challenges** Brad shares firsthand experience that attribution is expensive, often impossible, and even when successful, may not lead to action. Law enforcement involvement often requires subpoena power, and local law enforcement and FBI are frequently overloaded and unwilling to pursue cases. As a result, attribution efforts often stall or are abandoned despite significant financial impact.

**Foundational Controls and Systems** The discussion emphasizes that proper attribution requires foundational security controls including asset management, access control, configuration control, and change management. Without these basics, dwell time (time between breach occurrence and detection) remains very long—averaging 170–200 days according to studies mentioned.

## Technical Details

**Policy and Compliance** The hosts note that many security policies are incomprehensible to users. If users are expected to comply with policies, the policies must be understandable—similar to rules of a board game that users must follow, even if they don't read every word. User responsibilities should be simplified to compliance, not understanding complex technical jargon.

**Logging and Evidence Preservation** Proper incident response requires preserved log files and secure configuration of logging on firewalls and systems. Many organizations either do not configure logging or configure it poorly, making it impossible to reconstruct events months later.

**Accountability vs. Blame** A key distinction emerges: holding someone accountable (coaching, improvement) differs from blaming them (isolation, shame). A culture of blame and reprimand defeats the purpose of information security by preventing employees from reporting incidents and learning from mistakes.

## Takeaways

1. **Breaches will happen.** No organization can prevent all breaches, regardless of budget or effort. The focus should shift from prevention-only to incident response and learning.

2. **Define roles and responsibilities clearly.** From the Board of Directors to the CISO to users, everyone should understand their security responsibilities to avoid ambiguity and scapegoating.

3. **Build transparency and encouragement over fear.** A culture of encouragement and transparency is more effective than fear and reprimand for achieving security goals.

4. **Invest in foundational controls.** Asset management, access control, configuration control, and change management are unglamorous but essential for any mature security program.

5. **Recognize the industry's egotism problem.** The security industry has a tendency toward superiority and egotism that hinders communication with non-technical stakeholders and colleagues.

6. **Humility and communication matter.** CISOs and security leaders who fail to communicate well and show humility often lose organizational standing. Those reporting directly to the CEO may be demoted if they don't approach information security correctly.

7. **Recourse for faulty products is limited.** Connected devices (IoT, vehicles, medical equipment) often have no recourse for privacy violations or security failures, creating a systemic problem.

Related talks