What are Security Invariants?
--
Security invariants are a pattern for solving problems. We know what we want to be true, with minimal subjectivity. We know how to verify its truth, with minimal interpretation. It may not be true everywhere, but we know everywhere where it isn’t true.
An example of an invariant is:
- All employee laptop disks are encrypted
For that invariant to be valid, we need to answer two questions:
- What are all the disks?
- Are they all encrypted?
If we can’t affirm either of those questions, the invariant is invalid. Why are invariants useful?
Invariants are decidable
Many goals of software owners are misunderstood as binaries:
- Performant, not slow
- Well-designed, not shoddy
- Legal, not unlawful
- Secure, not exploitable
Teams that work on these goals understand there is no finish line. There is only postponement of the next inevitable failure. There is a rough consensus of past good decisions, based on observation. We cannot solve for complete security.
While security is not a binary, invariants are. We can know that we’re progressing if we can track our pace towards a fixed goal. We can pass go, collect $200, and move to the next prioritized problem.
Invariants are observable
System security is fractal. As a security engineer, your challenge is to build a lens on this complexity. This lens should be useful for both the non-security and security teams. What problem can we bring into focus?
If we focus on one problem at a time, we can take high-quality measurements. We can chart our progress. We can observe its resolution. We can avoid regression when our focus must shift.
Invariants include context
Security “best practices” need to be re-implemented for thousands of software projects. Each software project is a unique mix of people, process, and technology. Different companies adhere to best practices in unrelated ways:
- Use 2FA
