N100FN100F
Published on

Security is demonstrated

‘We are secure’ is not an answer. The only useful answer to ‘how do you know?’ is evidence: which control exists, who reviews it, when it was last checked and what the result was.

Service line Cybersecurity

The uncomfortable question

Ask any organisation whether its systems are secure and it will almost always say yes. Then ask how it knows, and the answer tends to change: 'we have a firewall', 'we passed an audit last year', 'nothing has ever happened to us'.

None of those answers demonstrates anything. A badly configured firewall protects very little. An annual audit portrays a single day. And nothing having happened may simply mean nobody has seen it.

How do you know you are protected?Declared answers against four concrete pieces of evidence with a date and a result.SECURITY · EVIDENCEHow do you know you are protected?DECLARED'We have a firewall''We passed the audit''Nothing has ever happened to us'DEMONSTRATEDSecond factor on administrative accessChecked today · automaticRestorable backupsRestore tested · 12 OctQuarterly access reviewMinutes signed · 30 Sep!No public storageFailed 2 Oct · fixed 3 OctFour questions for every important risk:which control, who answers for it, when it was checked and with what result.Illustrative exampleN100F · n100f.com

Declaring versus demonstrating

Declared security describes intentions and tools. Demonstrated security answers, for each important risk, four questions:

  1. Which control covers it? Something concrete: 'all administrative access requires a second factor'.
  2. Who is responsible for it working?
  3. When was it last checked?
  4. What evidence is there of the result? A report, a log, a dated screenshot.

When those answers exist and are up to date, the conversation with an auditor, a customer or the board changes tone: you are no longer debating opinions, you are reviewing proof.

What this series covers

It starts with knowing what has to be protected (the exposed surface). It moves on to how you get from frameworks to your own controls with evidence, and how that evidence collects itself. It then goes down to the layers of protection that fail most in practice: permissions, code and dependencies, encryption and hybrid access. It ends with what happens when something fails: logging, detecting, responding, and making security help rather than hinder.

Several pieces were covered in other series and are only cited here: single identity (Governance), secrets (Platform), rules as code and baselines (IaC) and design by zones (Architecture).

The first thing, before any control, is knowing what an attacker sees.

How we apply it: Cybersecurity.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk