Is the S in SRE for “Security”?
summary
Argues that security performance tracks general engineering performance and cites three 2019 studies plus later meta-analyses: daily scanning teams close vulnerabilities in days while groups scanning 1–3×/year take months or years; the top effective controls are attack surface management and rapid patch cadence; MFA helps most at the individual level. Notes tooling convergence as SEM features merge into general observability stacks, describes building an open-source network IDS with Shadow and using Nessus for scans, and proposes Security Level Objectives to trigger maintenance.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:03Security and SRE overlap
- 2:27Safety mindset for cybersecurity
- 6:26Security vs software performance
- 9:39Software supply chain security
- 12:29Effective security controls
- 15:18SRE and security teams
- 17:46Observability as foundation
- 19:55Incident response differences
- 24:31Reliability and security testing
- 27:19Security level objectives
- 30:08Practical takeaways and closing remarks
related talks
33mSecurity and SRE: Natural Force Multipliers
28mDefending against SRE with SRE
35mRole of SRE in DevSecOps
49mSite Reliability Engineering and the Security Team They Love
35mSRE for [cyber]security
30mIntegrating cloud native security into the SRE culture
49mWhat SRE Could Be: Systems Reliability Engineering
32mHow Can SRE Help Security Governance?...
