Safeguard
Incident Analysis•

Target breach checklist: would your organisation have caught it?

A checklist drawn from the 2013 Target breach: vendor access, segmentation, alert response and exfiltration monitoring. Use it to test your own controls.

Safeguard Security Team
4 min read

The 2013 Target breach is a useful test for any organisation: attackers entered through a vendor's stolen credentials, moved to systems that handled payment data, and generated alerts that were reportedly not acted on. Ask whether your vendor access, segmentation and alert handling would have stopped the same chain.

This is a review of controls, not a judgement of the people involved. Much of what is public comes from investigations and press reporting rather than a full forensic report.

What is publicly known?

Security journalist Brian Krebs reported that attackers used network credentials stolen from Fazio Mechanical Services, a refrigeration and HVAC provider. Fazio said its connection with Target was exclusively for electronic billing, contract submission and project management, and denied remotely monitoring Target's HVAC systems. Krebs gives 15 November 2013 as the date attackers first entered the network, followed by malware testing on a small number of registers and a wider spread in late November. Target said about 40 million debit and credit card accounts were exposed.

A March 2014 staff report from the US Senate Commerce Committee, which used public information and the intrusion kill chain model, concluded that Target missed opportunities to stop the attackers. It said Target failed to respond to multiple automated warnings from its anti-intrusion software, including about malware installation and data movement, gave network access to a third-party vendor that did not appear to follow accepted security practices, and did not isolate its most sensitive assets. The staff noted that the full story might not be known until Target's forensic review was complete.

The checklist

Answer each as yes, partly or no, and write an owner next to every partly and no.

1. Vendor access. Do you list every third party with network or system access, and what for? Is access limited to the system the vendor needs, not a broad internal network? Is multi-factor authentication required for vendor accounts? Are vendor accounts reviewed and removed when contracts end?

2. Segmentation. If an attacker holds a vendor's credentials, what can they reach? Can a billing or project portal reach payment systems or sensitive data? Is the path between zones restricted to named flows and monitored?

3. Alert response. When an endpoint or network tool raises a high severity alert, who sees it, how fast and what do they do? Is there a measured time from alert to action? Do you sample alerts to see if real detections get lost among noise?

4. Exfiltration. Would you notice large or unusual outbound transfers from systems that hold sensitive data? Is outbound traffic from those systems restricted to expected destinations?

5. Endpoint hardening on high value systems. Do systems that handle payments or sensitive data run only approved software, with changes controlled and logged?

6. Detection testing. Have you run an exercise that simulates stolen vendor credentials and checked whether anyone noticed?

7. Response readiness. Is there a defined path from a suspected compromise to isolation, evidence preservation and notification, rehearsed within the last year?

Why this applies to software too

Replace the HVAC portal with a build tool, a package registry account or a managed service connection. The pattern is identical: a trusted outside party holds access, a stolen credential opens it, and the question is how far it reaches and how fast you notice. The Codecov incident of 2021 showed the same logic in a CI setting.

What to do

  1. Build the vendor access list and remove anything unjustified.
  2. Draw the paths from vendor systems to your most sensitive systems and cut the unneeded ones.
  3. Measure alert to action time for high severity alerts this month.
  4. Add monitoring for unusual outbound transfers from sensitive systems.
  5. Run a stolen vendor credential exercise and record what was detected.
  6. Fix the weakest checklist rows first and re-score in a quarter.

Quick check

Would this checklist have prevented the breach?

No one can say. It tests the controls that the public reports identify as weak points. Passing it lowers your exposure to the same chain.

Is a vendor risk questionnaire enough?

Not alone. Technical limits on what a vendor account can reach matter more than answers on a form.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.