A vendor's stolen login opened a retailer's network (2013) and what it shows about vendor remote access

In late 2013, attackers broke into the network of a national retail chain and took card and personal data. A Senate Commerce Committee majority staff report dated March 26, 2014, says they reportedly first got in with a login stolen from one of the retailer’s vendors, a building-services contractor. The case is more than 10 years old. The path it describes, a vendor’s login stolen on the vendor’s own computer, still applies to any company that gives outside firms remote access.

The staff report was written from media reports and expert analysis before the retailer’s forensic exam was finished. So several of its points are marked as reported or unconfirmed.

What happened

According to the staff report, the attack ran in November and December 2013. The attackers took financial and personal data on up to 110 million customers and moved it to a server in Eastern Europe. A May 23, 2017, release from the District of Columbia’s attorney general gives the figures used in the later settlement. The breach reached more than 41 million payment card accounts and the contact details of more than 60 million customers.

The vendor was a building-services contractor. It could reach the retailer’s network remotely to send bills, submit contracts and manage projects. Citing outside reports, the staff report says that at least two months before the breach began, attackers used “emails infected with malware” to steal the vendor’s login for that access. The attorney general’s release, describing the states’ own investigation, says that on or about November 12, 2013, attackers reached the retailer’s gateway server “through credentials stolen from a third-party vendor.”

The report adds a detail that it calls unconfirmed. The malware on the vendor’s systems “may have recorded passwords” and given the attackers their way into an external billing system. From there, the report says, it isn’t clear how the attackers reached the store checkout systems. It cites a former security team member who thought the outside portal was likely not fully isolated from the rest of the network.

The cause the record states

The report names a gap on each side. On the vendor’s side, the attack began with phishing emails. The report says training staff to spot them could have disrupted that step, and anti-malware software could potentially have detected the infected files. On the retailer’s side, the report says requiring two-factor authentication for vendors might have disrupted the attack at this step. Two-factor authentication adds a second step to the password, such as a code sent to the vendor’s phone. According to a former vendor manager quoted in the report, the retailer “rarely required two-factor authentication from its low-level contractors.” Where no second step was required, whoever held the vendor’s password could sign in, whether that was the vendor or an attacker who had stolen it.

Corrective steps

In May 2017, the retailer settled with the attorneys general of 46 states and the District of Columbia for $18.5 million. The attorney general’s release lists the security terms. The retailer must “develop, implement and maintain a comprehensive information security program” and employ an executive or officer responsible for it. It must control access to its network, “including implementing password rotation policies and two-factor authentication for certain accounts.” It must separate its cardholder data from the rest of its network and hire an independent third party to assess its security.

Controls usually expected after incidents like this

A password typed on a vendor’s computer is only as safe as that computer. If malware records it there, the client’s own controls decide whether the recorded password is enough to get in. That is why the controls for this type sit with the client.

The FTC Safeguards Rule, which applies to covered financial institutions, states them plainly. It requires multi-factor authentication (MFA) “for any individual accessing any information system” (16 CFR 314.4(c)(5)). That covers a vendor’s staff as much as your own. The one exception is an equivalent or stronger control approved in writing by your Qualified Individual, the person the rule puts in charge of your security program. The rule also requires you to oversee service providers (314.4(f)). You choose vendors that can keep appropriate safeguards and require those safeguards by contract. Then you assess the vendors periodically, based on the risk they present.

NIST’s authentication guideline, SP 800-63B-4, adds a rule for after the fact. Section 3.1.1.2 says a system must force a password change when there is evidence it has been compromised. A vendor reporting malware on a computer used for your work would be such evidence. What a second sign-in step is and how it works is covered in What is multi-factor authentication (MFA)?. What oversight of a vendor involves is in What is vendor oversight?.

Questions to ask about your own setup