Unit 5: HTTPS and certificates · Lesson 5 of 5 · 18 min
Case file: the monitoring that silently stopped
Check the certificates your security tools depend on, and alert when a sensor goes quiet, the lessons of the Equifax breach.
case file
Equifax breach
Equifax · 2017
Attackers exploited a publicly disclosed Apache Struts flaw in Equifax's online dispute portal and stayed for months, exposing personal data of roughly 147 million people. The intrusion was spotted only after an expired certificate on a traffic inspection device was renewed and suspicious traffic immediately showed up.
What went wrong
The Struts patch was never applied to the portal, and the device that inspected its traffic had been inactive for about 19 months because its certificate had expired.
What would have stopped it
- Keep an accurate inventory so every internet-facing copy of a vulnerable library gets patched, and verify the patch.
- Track expiry of certificates used by security tooling and alert well before it.
- Treat a monitoring device that stops producing events as an incident.
What defenders could have seen
- A heartbeat alert when an inspection sensor stops sending events.
- A scan or SBOM match showing the vulnerable version after the patch deadline.
sourcesgao.govtechtarget.com
mission
- You are
- The analyst who owns the shop's security monitoring.
- Situation
- Three sensors watch the shop's traffic. Each needs a valid certificate to decrypt and inspect what passes. A dashboard full of green does not prove they are all still looking.
- Goal
- Find any sensor with an expired certificate and any that has gone quiet.
- Hand in
- A list of sensors to fix today and an alert rule that would have caught it.
A traffic sensor with an expired badge
When does each certificate expire?
for c in cases/monitoring/*.crt; do printf '%-16s ' $(basename $c .crt); openssl x509 -in $c -noout -enddate; done
ids-core notAfter=Feb 1 00:00:00 2028 GMT
inspect-dmz notAfter=Mar 1 00:00:00 2025 GMT
proxy-out notAfter=Apr 15 00:00:00 2028 GMT
you should see inspect-dmz expired on 1 March 2025. The others run to 2028.
Check expiry the way an alert would
-checkend exits with failure if the certificate expires within that many seconds. 0 means already expired; 60 days gives you warning.
for c in cases/monitoring/*.crt; do printf '%-16s ' $(basename $c .crt); openssl x509 -in $c -noout -checkend 0 >/dev/null && echo valid || echo EXPIRED; done ids-core valid inspect-dmz EXPIRED proxy-out valid for c in cases/monitoring/*.crt; do printf '%-16s ' $(basename $c .crt); openssl x509 -in $c -noout -checkend $((60*86400)) >/dev/null && echo ok || echo 'renew now'; done ids-core ok inspect-dmz renew now proxy-out ok
you should see Only inspect-dmz fails both checks. The same loop on a schedule is a working alert.
Which sensors have gone quiet?
cat cases/monitoring/sensors.csv sensor,type,cert,last_event inspect-dmz,tls-inspection,inspect-dmz.crt,2025-03-01T00:00:00Z ids-core,ids,ids-core.crt,2026-10-14T08:59:12Z proxy-out,web-proxy,proxy-out.crt,2026-10-14T08:58:40Z awk -F, 'NR>1 && $4 < "2026-10-13"' cases/monitoring/sensors.csv inspect-dmz,tls-inspection,inspect-dmz.crt,2025-03-01T00:00:00Z
you should see inspect-dmz has sent nothing since the day its certificate expired. Nobody noticed, because silence raised no alert.
defender tip Alert on absence: every sensor should report a heartbeat, and a missing one is as urgent as a detection.
Turn it into an alert
A check that prints nothing when all is well is easy to schedule and easy to alert on.
for c in cases/monitoring/*.crt; do openssl x509 -in $c -noout -checkend $((60*86400)) >/dev/null || echo "renew $(basename $c)"; done
renew inspect-dmz.crt
you should see One line, for inspect-dmz. Run it daily and send any output to the on-call channel.
What a defender takes away
- 1Security tools fail quietly; monitor the monitors.
- 2Track certificate expiry for tooling, not just websites.
- 3Patching and visibility are both controls. Equifax lost both.
Questions
0 of 2 solved
Answer each one from what you find on your lab machine.