In my eBook, 10 Ways We Can Steal Your Data, I reveal ways that people can steal or destroy the data in your systems. In this blog post, I’m focusing on un-monitored and poorly monitored systems.
The most notorious case of this type is the 2013 Target data theft incident in which 40 million credit and debit cards were stolen from Target’s systems. This data breach is a case study on the role of monitoring and alerting. It led to fines and costs in the hundreds of millions of dollars for the retailer. Target had security systems in place, but the company wasn’t monitoring the security of their third-party supplier. And, among other issues, Target did not respond to their monitoring reports.
The third-party vendor, an HVAC services provider, had a public-facing portal for logging in to monitor their systems. Access to this system was breached via an email phishing attack. This information, together with a detailed security case study and architecture published by another Target vendor, gave the attackers the information they needed to successfully install malware on Target Point-of-Sale (POS) servers and systems.
Target listed their vendors on their website. This list provided a funnel for attackers to find and exploit vendor systems. The attackers found the right vulnerability to exploit with one of the vendors, then leveraged the details from the other vendor to do their work.
Misconfigured, Unprotected, and Unsecured Resources
The attackers used vulnerabilities (backdoors, default credentials, and misconfigured domain controllers) to work their way through the systems. These are easy things to scan for and monitor. So much so that “script kiddies” can do this without even knowing how their scripts work. Why didn’t IT know about these misconfigurations? Why were default credentials left in enterprise data center applications? Why was information about ports and other configurations published publicly? No one of these issues may have led to the same outcome, but as I’ll cover below, these together formed the perfect storm of mismanaged resources to make the data breach possible.
When all this was happening, Target’s offsite monitoring team was alerted that unexpected activities were happening on a large scale. They notified Target, but there was no response.
Some of the reasons given were that there were too many false positives, so security staff had grown slow to respond to all reports. Alert tuning would have helped this issue. Other issues included having too few and undertrained security staff.
Pulling it All Together
There were monitoring controls in place at Target, as well as security staff, third-party monitoring services, and up-to-date compliance auditing. But the system as a whole failed due to having an integrated, system-wide approach to security and threat management.
How can we mitigate these types of events?
- Don’t use many, separate monitoring and alerting systems
- Follow data flows through the whole system, not just one system at a time
- Tune alerts so that humans respond
- Test responders to see if the alerts are working
- Read the SANS case study on this breach
- Don’t let DevOps performance get in the way of threat management
- Monitor for misconfigured resources
- Monitor for unpatched resources
- Monitor for rogue software installs
- Monitor for default credentials
- Monitor for open ports
- Educate staff on over-sharing about systems
- Monitor the press for reports about technical resources
- Perform regular pen testing
- Treat security as a daily operational practice for everyone, not just an annual review
- Think like a hacker
I could just keep adding to this list. Do you have items to add? List them below and I’ll update.
Source: solarwinds GEEK SPEAK