Featured image of post Revisiting the Manifesto for Modern Cybersecurity

Revisiting the Manifesto for Modern Cybersecurity

How to adapt a cybersecurity program to a modern tech organisation

The Manifesto

The Manifesto for Modern Cybersecurity is a brilliant bit of text.

We believe modern cybersecurity, especially for digital companies with cloud-native operations, requires a different mindset and operating model such that:

  • Assume compromise, but expose no single point of compromise.
  • Track everything since you cannot protect what you can’t see.
  • Engage everyone for there is power in the crowd; two is stronger than one.
  • Automation is key because people don’t scale and changes are constant.
  • Build products that are secure by design and secure by default.
  • Favor transparency over obscurity, practicality over process, and usability over complexity.

We must keep security simple, open, collaborative, enabling and rewarding.

It was originally written by Erkang Zheng & Zane Lackey in 2017, and I believe it is still as relevant today as it was then. Let’s take the time to explore and possibly challenge these ideas.

The Critique

First off, it’s important to note that the following principles are set in no particular order.

Assume compromise, but expose no single point of compromise

Yes, absolutely. Always assume compromise.

While a compromise may result from the failure of the security mechanisms your org employs, it is not necessarily a failure of the security team. If your business leaders do not recognize that, chances are you’re in a toxic environment, and arguably need to get out.

However, exposing 0 points of compromise may be easier said than done. It could potentially require inordinate amounts of resources to achieve. But that does not mean you should not try.

Assess your risk, identify your points of compromise, and do try to eliminate them. To do that, learn about resilience engineering, and set up your system components to work in a way where even if one of them is compromised or failing, the rest of the system is resilient enough to carry on.

Track everything since you cannot protect what you can’t see

Putting security cameras everywhere is a great idea! For real! But, in the real world, tracking everything poses quantity and quality problems.

Let’s imagine a common scenario: you want to ingest 2 terabytes of data monthly, with 12 month retention. That will cost you multiple thousands of dollars every month, on any cloud provider. As your team & services grow, that spend will increase too. Unfortunately life catches up with us very quickly there.

So we need to be smart about it:

  • log everything important to the SIEM
    • I’ll let you define what’s important to you
  • anything that can be, shoud be offloaded to long term storage, and ingested on demand for investigation purposes.

Speaking of investigations, having properly parsable and meaningful logs is going to be crucial. AppSecEngineer’s The Importance of Security Logging in Protecting Your Web Apps blog post is a very useful resource to explore if you’re wondering how to go about that.

Engage everyone for there is power in the crowd; two is stronger than one

The security team can’t singlehandedly prevent all issues. So, yes, harnessing “the crowd”, aka your coworkers, is a smart move.

I’ve already spoken at length about the importance of running good security awareness trainings, see this previous post to learn more. But you can go even further by telling your coworkers exactly what is expected from them, security wise.

I like to establish a Shared Security Responsibility Model in the organisations I work for. Use AWS’ Shared Responsibility Model for inspiration to establish yours. It doesn’t have to be as complex. Something like this 👇 works very well!

Teams are responsible for:

  • Following security policies
  • Alerting in case of a security incident
  • etc.

Security team is responsible for:

  • Establishing and maintaining security policies
  • Managing security incidents
  • etc.

Automation is key because people don’t scale and changes are constant

You may have heard of the Law of Large Numbers. Let’s apply it to security in a tech organisation: a 100 people organisation can be very security minded; a 1000 people organisation can be above average in terms of security; a 10000 people organisation will always be decidedly average.

Do you see where I’m going here? Engage as many crowds as you want, if you don’t automate the important stuff, you’ll inevitably expose a single point of compromise somewhere.

Build products that are secure by design and secure by default

This one is obvious, hopefully. Spend time with your product team to figure out how to integrate threat modelling into their workflows.

Favor transparency over obscurity, practicality over process, and usability over complexity

This one will upset many a compliance specialist.

Surely, you can’t reconcile the principle of least privilege with radical transparency? Surely, you can’t eliminate human security checks from the release cycle? Surely, you can’t axe the TOTP 2FA challenge at login?

Well, yes, you can and arguably should do exactly all of that.


Radical transparency allows for more serendipity as well as autonomy and mastery (learn more about the importance of autonomy and mastery within Dan Pink’s intrinsic motivation framework). That doesn’t mean you should leak all your sensitive data to all your coworkers. It means that any information that does not have good reason to be restricted, shouldn’t be.


Continuous delivery should kill your release cycle, and human security checks with it. Favour automated security checks to speed up your delivery, and run non-blocking security checks.


And last, but not least, yes, you should be abandoning TOTP wherever you can, and favouring U2F instead. See this blog post for why.

The vision

To me, security is the discipline of placing obstacles on your attackers path, withtout impeding workflows. The more obstacles you place, the more likely your attackers will fail.

The Manifesto for Modern Cybersecurity provides some pointers as to how to implement this vision efficiently, even if implementations will greatly vary depending on the socio-technical system you’re considering.