What to do when you get a security alert

Hacker's handbook • 3 min read

An alert saying your site is at risk is unwelcome, and it's also the system working. You've been told about a problem while there's still time to act. What you do in the next hour matters more than how the problem got there. This is a plan you can follow without being a security specialist.

1. Read it properly

Before you change anything, make sure you understand three things:

What is affected: which domain, server, or page.
What an attacker could do: read data, sign in, take the site over, or only learn something about it.
How easy it is: can anyone on the internet do it, or does it need an account or special conditions?

Something anyone can reach that exposes data or control is urgent. Something that needs unusual conditions can wait until morning.

2. Confirm it's real

Automated findings are sometimes wrong. Check the finding yourself if it's quick to do: request the page, look at the version, read the file. But don't let checking become a reason to wait. If you can't rule it out in a few minutes, treat it as real.

3. Contain it first

Containing a problem and fixing it are different jobs. Containment is whatever stops the exposure right now, even if it's crude:

Block access to the affected page or port at the firewall or proxy.
Take the affected service offline if it isn't essential.
Turn off the vulnerable feature until it can be updated.
Remove the exposed file.

A feature being unavailable for an afternoon is a far smaller problem than a breach.

4. Fix the cause

Now do the proper repair: apply the update, correct the setting, or change the code. Then ask how it happened. An exposed file usually points to a deploy process that copies too much. An unpatched server points to nobody owning its updates. Fixing the cause is what stops the same alert arriving next month.

5. Check whether it was already used

This step is the one people skip. If the weakness was reachable, someone may have found it before you did.

Search your logs for requests to the affected path or service, going back as far as it was exposed.
Look for what doesn't belong: new admin accounts, unfamiliar files, scheduled tasks you didn't create, or outbound connections to unknown addresses.
Change any secrets that were within reach: passwords, API keys, and tokens. If a configuration file was exposed, change everything in it.
End active sessions if accounts may have been affected.

If you find signs that someone got in, stop and get help from someone with incident-response experience before you clean up. Well-meant tidying can destroy the evidence of what was taken.

6. Make sure it's closed

Test again from the outside, the same way the problem was found. Changes don't always reach the live site: a deploy fails, a cache keeps serving the old response, or a second server was missed. The problem is closed when a fresh test says so.

7. Tell the people who need to know

Your team: what happened, what was done, and what to watch for.
Your customers: if their data may have been accessed, they need to hear it from you, plainly and soon.
Regulators: many countries require you to report a breach of personal data, often within a few days. Check the rules that apply to you, or ask a lawyer, before you assume you're exempt.

Be ready before it happens

Decide who gets the alerts and who covers when they're away.
Keep logs long enough to look back over weeks, not hours.
Know how to roll back a deploy and how to rotate each of your secrets.
Keep backups you've actually restored from, stored somewhere the live site can't reach.

Conclusion

An alert is a head start. Understand it, contain it, fix the cause, check whether anyone got there first, and test again before you call it done. Handled this way, most alerts end as a short afternoon's work, and nothing more.