In-depth reviews of zero-day threats and defenses
Zero-Day Vulnerability Response: A 72-Hour Triage Checklist for Small Security Teams
Vulnerabilities

Zero-Day Vulnerability Response: A 72-Hour Triage Checklist for Small Security Teams

You get the alert at 4:40 on a Thursday afternoon: a critical remote code execution flaw in a product you run, exploit code already circulating, vendor advisory live. There is no threat intel team down the hall. There is you, a ticket queue, and a colleague who just went offline. What happens over the next 72 hours — the order you do things in, and what you deliberately skip — matters far more than how fast you push a patch.

Hours 0–4: Separate what you know from what you've read

The first block is for facts, not action. Read the vendor advisory itself, not the summary someone reposted. Then write down the answers to five questions, with timestamps, in one shared document.

  1. Do we run the affected product, at an affected version, in a reachable configuration?
  2. Is the flaw exploitable without credentials, and from where — the internet, the LAN, a VPN segment?
  3. Is exploitation confirmed in the wild, or is this proof-of-concept only?
  4. Does the vendor have a patch, a mitigation, or nothing yet?
  5. Who owns each affected system, and who can authorize a change to it today?

Be careful with severity scores. CVSS describes technical severity; it knows nothing about your architecture. A 9.8 in a service you never exposed is a lower operational priority than a 7.5 on the appliance guarding your remote access. Check whether the vendor or a national authority has flagged active exploitation, and whether the flaw has landed in a known-exploited-vulnerability catalog. Those catalogs exist precisely to give small teams a reality check on urgency.

Hours 4–12: Map the flaw onto your actual estate

Now turn a generic advisory into a list of hosts. This is the step small teams skip, and it is the step that determines whether the next 60 hours feel calm or chaotic.

Build a one-page exposure map

  • Instances: hostname, owner, environment, business function.
  • Reachability: internet-facing, partner-facing, internal only, or an isolated lab nobody remembers.
  • Version and patch level, plus the date you last confirmed it rather than assumed it.
  • Front-door controls: WAF, reverse proxy, load balancer — or nothing at all.
  • Blast radius: could a compromise here reach your identity provider, your backups, or your build pipeline?

If discovery returns "unknown," treat that as a finding in its own right. An hour spent hunting shadow instances now is cheaper than a week of incident response later. Assign one person to own the inventory and one to own the technical verification, even if those are the same two people doing everything else.

Hours 12–24: Contain with the controls you already have

If exploitation is confirmed and you cannot patch yet, buy time with compensating controls. Their job is not to be perfect. It is to raise the cost of an attack and to generate noise you can actually detect.

  • Disable the vulnerable feature, close the port, or restrict access to known IP ranges at the edge.
  • Put authentication or an allowlist in front of an interface that was previously wide open.
  • Turn the service off entirely if the business can tolerate 48 hours without it. Ask; often they can.
  • Rotate credentials and session tokens for anything touching the affected host, service accounts included.
  • Segment the host so it can no longer talk to everything on the network.
  • Snapshot before you change anything, so you have something to compare against later.

Containment breaks things. Test the change on one system, keep a rollback path ready, and name the person authorized to reverse it at 2 a.m. without a committee meeting.

Hours 24–48: Detect, hunt backward, and stage the patch

Containment without detection only means you will not know when it fails.

What useful detection looks like here

  • A rule or signature for the known exploitation pattern, even a rough one.
  • Alerting when the vulnerable process spawns unexpected children, opens outbound connections, or writes to new paths.
  • A log coverage check: do you actually retain the relevant telemetry for the past 30 days, or only for seven?

Then hunt backward. Assume the worst case: if this was exploited last week, what would you see? Search historical logs for the artifact, not just live traffic. Absence of evidence is only meaningful if you know your logs would have captured it.

In parallel, stage the patch. Name the maintenance window, define the canary ring, document the rollback, and pre-write the change ticket so the approval is a formality rather than a debate. Order deployments by exposure, not alphabetically.

Hours 48–72: Communicate on purpose

Silence is a decision with consequences. So is a vague update that tells people nothing.

Three audiences, three messages

  • Leadership: what we know, what we are doing, what we need from them, and the risk of doing nothing.
  • Technical staff and the helpdesk: what to expect from the mitigation, how to report odd behavior, who to escalate to.
  • Customers, partners, regulators: only once you have confirmed impact, or when a contractual or regulatory duty requires you to speak.
We are aware of the flaw in the affected product. It does not currently affect the services you use, and we are applying the vendor's mitigation tonight. We will confirm completion by Friday morning.

Two sentences of fact and a next-update time beat three paragraphs of reassurance. Draft the template before you need it, and let one person own the wording so the message stays consistent.

Notification duties differ by jurisdiction and sector, and some have short clocks attached. Check your obligations with counsel before you publish anything you cannot walk back.

The 72-hour rhythm

The point of this checklist is not to finish everything in three days. It is to force a sequence so that panic does not set the order: assess, map, contain, detect, patch, communicate. Some steps will overlap. Some will take longer than a day on their own, and that is fine.

Keep the exposure map, the log, and the message templates you wrote this time. Next disclosure, you will start the clock at hour four instead of hour zero — and that head start is the whole advantage.

Photo: AMORIE SAM / Pexels

Category:

Vulnerabilities

Related Posts