25 Reasons Information Sharing Fails

### Overview This talk examines historical patterns of information sharing failures across major crises—including Pearl Harbor, September 11, Hurricane Katrina, the Virginia Tech shooting, Deepwater Horizon, and the cyber incident at the Oldsmar water utility. The speaker argues that these catastrophes were not failures of technology, as adequate sensors, radars, and processing tools existed, but failures of people and information architecture. As modern industrial control systems (ICS) and operational technology (OT) transition away from isolated, hierarchical architectures (such as the traditional Purdue model) toward highly connected, cloud-integrated ecosystems, addressing recurring information sharing breakdowns becomes essential to securing critical infrastructure and supply chains.

### Key Topics - **Recurring Failure Patterns**: Examples include conflation of authority or ambiguity of responsibility (e.g., lower-ranking liaisons at Pearl Harbor; overlapping jurisdictions among the FAA, FBI, and intelligence bodies during 9/11; IT vs. OT responsibility collisions regarding TeamViewer in Oldsmar). Another recurring failure is the lack of verification of critical features or decisions (e.g., misinterpreted war warnings in Hawaii, unverified detainee risks prior to 9/11, untracked FEMA requests in Katrina, and unverified TeamViewer operations in Oldsmar until chemical levels were altered). - **Shift to Collaborative Outcomes**: Sharing information purely for the sake of sharing typically triggers common failure modes. Information sharing programs must instead be anchored to predefined collaborative outcomes, which dictate necessary data fusion, communication channels, and partnership structures. - **Case Studies in Operational Collaboration**: - *Food Shield*: Developed after a salsa contamination incident was mistakenly blamed on Florida tomatoes rather than Mexican peppers. Food Shield established specific collaborative outcomes, document repositories, and a Common Organizational Registry Environment (CORE), reducing response resolution times from months to 72 hours. - *Joint Cyber Defense Collaborative (JCDC)*: An initiative focused on shifting ICS cybersecurity toward operational collaboration, referencing instances such as Microsoft sharing threat intelligence on new malware with the White House and European allies during Russia's invasion of Ukraine.

### Technical Details - **Digitization & Value Drivers in OT**: Modern systems demand shared architectures due to efficiency and economic value. In South Bend, Indiana, deployment of ~200 flow and level sensors connected to gateways and cloud analytics replaced an estimated $850 million physical overhaul with a $200 million sensor-driven solution. The implementation introduced an automated bidding mechanism for downstream wastewater capacity rather than relying solely on traditional IEC 61131-compliant controller logic. - **Four ICS Supply Chain Collaborative Outcomes**: Securing critical infrastructure requires collaboration across the entire lifecycle: 1. *Secure Products*: Incorporating secure boot, root of trust, vulnerability identification pre-commercialization, secure update mechanisms, and communication drivers that uniquely identify endpoints, sign messages for integrity, and handle encryption. 2. *Secure Deployment*: Hardening architectures through secure-by-design guidelines rather than relying on component-level security in isolation. 3. *Continuous Health and Monitoring*: Implementing telemetry and collection management frameworks across deployed environments. 4. *Incident Response*: Coordinating fast, structured defensive action across suppliers, integrators, and operators. - **Gateway Threat Modeling & Hardware Trust**: The speaker describes collaborating with a third-party gateway supplier on a joint STRIDE-style threat model (analyzing spoofing, tampering, repudiation, denial of service, and information disclosure). This collaboration surfaced new hardware entropy sources, enforced port-level authentication, and implemented an automated self-provisioning manufacturing flow using certificate signing requests (CSRs) and API keys tied to an IoT shadow configuration.

### Takeaways - Merely exchanging data or mandating compliance checklists like security questionnaires does not protect systems; questionnaires are expensive and easily bypassed. - Effective defense requires establishing shared responsibility between asset owners/operators, integrators, and component manufacturers. - Suppliers must provide greater visibility, understanding, and control, while operators must define concrete operational outcomes rather than relying on rigid, purely formal information channels.