Cheap and cheerful approach to front up with for your next infrastructure security office hours:

  • Get a diagram (every, damn, time).
  • Break the diagram into trust zones.
  • Draw the data flows (all of them).
  • Draw the management and deployment flows too.
  • Label everything: asset, threat, control.

Obviously, there’s more to it, but I find this checklist makes me seem relatively prepared most of the time, even when I haven’t had a chance to do my homework.

What goes on the diagram?

Enough detail to follow a request from the user to the thing they came for. Then follow an administrator doing the same thing. Those are often very different paths.

For a small web service, that might be a load balancer, two application servers and a database. But who deploys the application? Where does the database password come from? Can the build runner read it? Can someone with access to the backup account restore the database somewhere else?

That’s why I want the management flows on there. A database can be beautifully isolated from the Internet while the deployment account has access to everything.

Pick a boundary and follow it

Take one arrow at a time. Say the application server connects to the database:

  • Which identity is making that connection?
  • What can it read or change?
  • Where is the credential stored, and who else can retrieve it?
  • Which machines can reach the database port?
  • What would we see if that identity started exporting every table?

Now assume the application server is compromised. Does the attacker get just this application’s data, or the other applications sharing the database too? Can they delete the backups? Can they modify the logs we’d use to figure out what happened?

These questions give the controls something specific to do. “Database is encrypted” doesn’t answer any of them on its own.

Leave with something someone can fix

An observation like “logging needs improvement” isn’t much use after the meeting. Something like this is:

The application identity can export customer data, but database audit events aren’t being sent anywhere. The database team will enable the relevant events and the detection team will check that a test export is visible.

Keep the owner, the evidence and the next action beside the finding. If nobody knows whether a control exists, write that down as an unanswered question. It’s much easier to follow up on that than to reverse-engineer what “probably fine” meant two weeks later.