Uncouth Users, Dopey Developers and Crazy Cryptographers OR... Mike Bursell & Christopher Robinson

### Overview In this talk, security architects Mike Bursell (Confidential Computing Consortium) and Christopher "Krob" Robinson (OpenSSF) deliver a humorous yet practical exploration of security architecture. Drawing on their backgrounds across systems, solutions, operational engineering, identity and access management (IAM), and governance, risk, and compliance (GRC), the speakers examine how organizations frequently struggle with security due to functional silos. They argue that the primary role of a security architect is to reduce systemic complexity, bridge the gap between low-level technical realities and high-level business risk, and address emergent security behaviors across components.

### Key Topics - **Silos and Stakeholder Perspectives**: The speakers contrast how various organizational roles approach their work. Users often fail to read documentation; software engineers specialize deeply in their stacks but often lack broader security training; security engineers and cryptographers tend to view all problems through narrow lenses (like algorithms and math) without accounting for human usability; QA testers test discrete features rather than holistic interactions; operations teams prioritize uptime and fear change; product managers focus on features and accumulate security technical debt; and C-level executives primarily evaluate risk, shareholder value, and board demands rather than pure security. - **Open Source Security Realities**: The talk addresses the open-source ecosystem, debunking the absolute claim that "all bugs are shallow." Open source exposes code and flaws transparently, but bugs are only found and remediated if experienced researchers have the time, resources, and systemic perspective to examine emergent interactions across distributed or integrated components. - **The Architect's Breadth**: The speakers emphasize that security architects provide broad perspective (a "mile wide and centimeters deep"), integrating knowledge from disaster recovery, physical security, and project management with foundational security principles such as least privilege, separation of duties, and hierarchical trust.

### Technical Details & Frameworks - **Methodologies & Standards**: The presentation references architectural and security frameworks including TOGAF, SABSA, NIST, ENISA, and certifications like CISSP. - **Non-Functional Requirements (NFRs)**: During the Q&A, the speakers detail how organizations can avoid overspending on security by establishing clear non-functional requirements around uptime, latency, regulatory compliance, and risk appetite. - **Translating Risk**: Instead of demanding binary "no" decisions or shutting down production systems, security architects must quantify risk, presenting executive leadership with clear trade-offs involving capacity, likelihood of data loss, operational impact, and mitigation costs.

### Takeaways - **Think Bigger**: Technologists must look beyond their immediate component silo to identify emergent risks that appear when multiple systems, APIs, or data flows interact. - **Speak the Audience's Language**: Tailor communications to the stakeholder—discussing defects and bugs with software developers, physical parameters with hardware engineers, and financial exposure, likelihood, and business impact with executives. - **Budget for Security Continuously**: Product management should allocate a continuous budget (e.g., ~15% per release) toward security technical debt rather than planning standalone security releases that never materialize. - **Proportional Defense**: Never spend more to secure an asset than the asset and its associated risks (such as brand reputation and regulatory exposure) are worth; the objective is to reduce risk to an acceptable, manageable threshold.