Hey All, Trying a new LEM idea courtesy byrona - a LEM/SIEM topic of the week. I'll try to post a topic related to security and log data once a week, you toss in your two cents based on your experience of what would/wouldn't work. If you have suggestions for future topics, toss them my way. I thought we'd start this week with something topical...
The Target Breach! Over the last couple of weeks, more details have come forward about what actually happened. Check out this article from Brian Krebs with the details: Target Hackers Broke in Via HVAC Company — Krebs on Security (check out his previous articles for the full unravel). We know from sources like the Verizon Data Breach Investigation Report (DBIR) that a lot of people aren't detecting breaches with log data, they are instead getting reports from third party sources, sometimes months later, and sometimes using the log data after the investigation is called in (other times just ending up in "we don't know, we're sorry, we'll do better, we promise"). Even when they HAVE log data being stored, it's just not being used, or being used much too late. So, what could we practically have detected?
- The HVAC vendor breach: the creds to get to Target's system were stolen from the HVAC vendor. Not enough info to go on here to see if we could have detected this one.
- Remote use of the HVAC credentials: now we're talking some basic bread and butter! (Not to mention PCI rules about monitoring remote access....)
- Sometimes we have to rely on vendors to do remote work. Granted, maybe we shouldn't have an always-open tunnel if it's occasional maintenance, maybe those passwords should expire, and maybe we shouldn't allow it from just anywhere, but let's pretend it's a pretty regular occurrence (and it's possible since the vendor was breached they could have used normal business hours and an internal IP to get to Target).
- Audit successful and failed usage of those accounts, PERIOD. Is this alert-worthy? Yes, if you have vendors that are logging in infrequently. If not, this is what reports are for!
- Spot check (using reports/historical analysis or sometimes alerting if you can narrow it) logon patterns that fall outside the norm. Are they logging in at a weird time when that business isn't even working? Are they logging in when your IT team didn't even solicit their help? Are those credentials being used by some IP other than the HVAC vendor's normal IP range? Are they logging in way more frequently than usual? Are they logging on to different machines/systems than usual?
- If you're using a pattern for account naming (like svc_* or ven_* or adm_*), set up a safety net alert/report/whatever (as long as you look at it) for those accounts being used.
- Malware on the POS systems: could we pick this up somehow? Maybe some unusual ports being used, unusual processes being launched on those servers? Unusual traffic data on the inside or outside of the network? Unlikely we'd pick up the infection itself, assuming it was sophisticated and undetected by traditional tools.
- Data being offloaded to external systems: here, we might have another chance.
- We could monitor for unexpected data exfiltration behavior - if you've got a good idea of the IPs or sites that a server should be communicating with and you're egress filtering (or even just auditing egress traffic, or looking at flow data), you should be able to catch the unexpected access. For example, a WSUS server shouldn't phone home to Brazil, the MS update servers are pretty well known. Either using historical analysis or alerting that filters out the "known good" you could pick out the gray/unknown. This takes some time to figure out, just like those egress filters, though, which can make it frustrating at first.
- Monitoring out of band network communication if you use a proxy or other web filter - someone not using your proxy/filter for FTP or web traffic might be attempting to bypass to surf some questionable sites, but they might also be trying to push data or bypass policy. Probably easier to do on servers, too, because the chances they are misconfigured is lower.
- Spot checking (similar to that authentication traffic) download/upload patterns on servers outside of the norm, even using your proxy/webfilter. A server probably isn't going to be pushing much data up with FTP (or even HTTP) to the internet, so why's it happening?
It's unfortunately clear at this point that some of Target's failures are evidence of PCI non-compliance, so that's kind of a step zero. Verizon just released a PCI Report that has some interesting statistics on that, we're hoping to talk about the interesting stuff in that here on Geek Speak sometime soon (maybe next week's topic? "PCI sucks, but here's how to not ****" ).
What do you think? Is some of this stuff "DUH" level stuff, or is it just too far out of reach given the day to day task of just getting stuff done? Did I miss anything you could have detected? Anyone have interesting stories or thoughts on related topics (vendor access, evil hackers, how chip and PIN won't save the day when you're not PCI compliant in the first place)?