Best Practices

Your First Security Hire Is a Prioritisation Problem Disguised as a Recruiting One

The job description lists fifteen domains and describes a person who does not exist and would not want the job if they did. The role you need is narrower and harder to write down.

The Postmortem Was Good. The Action Items Were Not Done.

Nine items with named owners. Six months later two are done, four are in a backlog, two were closed without checking, and one is the direct cause of the incident you are having now.

Sep 18, 20265 min read

Localhost Is Not as Private as It Feels

Your machine is running more servers than you think, most with no authentication because localhost feels private. Any page you visit can send requests to them, on the machine holding your cloud credentials and SSH keys.

Sep 18, 20265 min read

An Audit Log You Can Actually Answer Questions With

During an incident you get asked three questions. If answering takes a week of grepping application logs, you do not have an audit log, you have debugging output that happens to contain some of the answer.

Deciding a Security Incident's Severity While You Still Know Nothing

Outage rubrics rate impact, which you can measure while it happens. A security incident's impact is unknown at the moment you must classify it, and often stays unknown for days. Rate the observation instead.

Write the Runbook for a Tired Stranger, Not for Yourself

Most runbooks are written by the person who least needs them and read by someone who has never seen the system, at night, afraid of making it worse. That mismatch explains nearly every runbook failure.

The Asset Nobody Owns Is the One That Sits for a Year

The DNS record pointing at a dead vendor, the service account nobody can justify, the repository failing every scan. Each has a fix that takes an afternoon, and each waits a year because finding an owner has no owner either.

A Researcher Just Emailed You About a Vulnerability

What happens in the next twenty-four hours decides whether this becomes a fixed bug and a useful relationship, or a public disclosure with a thread about how badly you handled it. Most companies get it wrong in the first reply.

The Incident You Did Not Have Is the Cheapest Data You Will Get

A credential was public for nine minutes and nobody used it. No incident, no postmortem, nothing changed. Your incident history is a biased sample containing only the times luck ran out.

Writing a Security Finding an Engineer Will Actually Fix

Most findings are written for the person who found them: a vulnerability class, a CVSS score, an advisory link. Getting one fixed is a writing problem more than a detection problem.

Never Investigate a Bug by Calling the API as a Real Customer

That read is very likely a write. Progress state, audit rows, quotas, notifications and billing all record the identity you sent, permanently, under a real person's name, and it contaminates the thing you were investigating.

Your First 90 Days as the Only Security Engineer

120 engineers, no AppSec program, a compliance deadline and 4,000 unread scanner findings. A week-by-week plan for the solo security hire, and the three mistakes that define the next two years.