Lessons from The Home Depot Breach
| DevOps |
Security researcher Brian Krebs published an article today that detailed how the Home Depot breach yielded up not only the usernames and passwords for their customer base, but also more than 50,000,000 email addresses.
Like the Target breach of 2013, it appears that the criminals got in through an escalation-of-privileges attack, using vendor credentials to gain illegitimate access to the company’s network, and then using that access to work their way up the food chain through a series of exploits and malware tools that were (apparently) custom-built to penetrate the Home Depot security perimeter.
Over the coming weeks, we expect to see coverage around that malware, its design and deployment, and how it was used to gain access to customer credentials and data. While the story so far is that no credit card (PCI) or personally identifiable information (PII) was gained, it may end up being the case that systems containing that kind of critically sensitive information were in fact accessed, especially if the attackers were deploying tools designed to do so.
Start at the Beginning
What’s important to note here is that the attack started with stolen credentials from a vendor. This was not a failure to manage a firewall properly, or a lack of security patches on a server — it was a compromised but valid secret (credentials) being used by someone who should not have had the authorization to do so.
This breach, like Target before it, underscores how important it is to have a security posture that is not exclusively focused on protecting against perimeter-based attack. Authz failures are often the simplest to execute: pose as a vendor or grab a username and password through social engineering, and you’re in. Unless you have a robust permissions and secrets management framework built into your infrastructure, it’s game over.
A better approach here might have been to layer in those secrets and permissions systems from day one. One model that would have worked:
- Home Depot could have established a bastion host that authenticated vendors prior to gaining network access, with inspection of IP range and more robust (MFA) identification
- Once authenticated, authorization could have been highly restricted, for example, via one-time token distribution into ephemeral storage with highly limited access rights, ideally through fully and immutably audited service broker systems that prevented any direct network access
- Those authorization tokens and the originating credentials could and should have been rotated regularly, making it impossible to gain access with old data
- All subsequent internal access should have been highly regulated, such that no escalation path existed for a vendor account under any circumstances
Build Least Privilege In From Day One
The work that would have gone into this sort of system may appear daunting, but had Home Depot dedicated the effort before they were publicly hacked, they could have saved a tremendous amount of time and expense that’s now being dedicated to a (very embarrassing) response.
More importantly, consumer data would not have been stolen, and 50 million people wouldn’t have to keep an eye on their accounts for the foreseeable future, wondering if their information was being used illicitly. There are no indications of this so far, and with luck it won’t happen — none of us at Conjur are believers in fear as a sales tactic — but we do believe passionately in the importance of getting security right when you’re the custodian of your customers’ data.
Least privilege, separation of duties, and zero-trust networking aren’t just buzzwords. Isn’t it time to make them requirements for any modern network infrastructure?