cancel
Showing results for 
Search instead for 
Did you mean: 

5 More Ways I Can Steal Your Data - Accessing Unmonitored Servers and Services

Level 12

DataTheft.jpg

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.

Third-party Vendors

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.

People

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 not 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.

16 Comments
bturner1
Level 9

Pen testing is a really good idea, but I recommend using different vendors periodically at different times to make sure all the details are captured. One may uncover an issue the other vendor didn't detect or had rated at a lower threat level.

datachick
Level 12

Very good point. I'd say that's true for most outside service providers.

petergwilson
Level 14

These issues usually arise from staff numbers being cut to the bone, pressure from management to deliver systems yesterday without full testing and staff having no training or time (or senior staff being made redundant, junior staff being asked to do senior roles and new cheaper staff being employed).  The IT staff then get blamed when something goes wrong.  Management should take the blame as it is they who have failed.

vinay.by
Level 16

Good article

inkedgeekfreak
Level 9

Privilege bracket your vendor or one time use accounts. Like Target, so often access is given but not revoked. A thorough, continually review of accounts to undo privilege creep.

ecklerwr1
Level 19

Just great when the offsite monitoring team keeps telling you something is really bad going on and you do NOTHING!!!

rschroeder
Level 21

Thank you so much for bringing up the Target case again, and commenting on their flaws!  It's great information, and a pertinent and timely warning to anyone with a network or an IoT device.

datachick
Level 12

Yes, staffing and other budgetary issues are heavy contributors to these incidents.  At least in this case, C-level employees had to leave. 

datachick
Level 12

In almost all my engagements I have to beg people to completely shut down all access for me when I leave.

datachick
Level 12

I'm trying to find more facts about this part. It's my understanding that the onsite team had alert overload, so were used to having slow responses to alerts.

michael.kent
Level 13

I would say, always use an independent pen tester. Not one linked to any company selling any of the solutions you use.

d09h
Level 16

Someone should have configured dependencies in their monitoring system, assuming it had that functionality.

tinmann0715
Level 16

You say, "Don't let DevOps performance get in the way of threat management"

I would posit that one shouldn't let DevOps get ahead of your threat management policies. DevOps is preached as the fast and furious and roadblocks be durned. Security needs to be reinforced every step of the way.

datachick
Level 12

I’d say hire all kinds. 

datachick
Level 12

Ahead is in the way, right?

Same goes for Agile, Lean, MVP.  All of it.  You can’t leave infosec to phase 2.  Or 22.

mtgilmore1
Level 13

Good point

About the Author
Data Evangelist Sr. Project Manager and Architect at InfoAdvisors. I'm a consultant, frequent speaker, trainer, blogger. I love all things data. I'm an Microsoft MVP. I work with all kinds of databases in the relational and post-relational world. I'm a NASA 2016 Datanaut! I want you to love your data, too.