Catching an attack with an evaluation SIEM product

Some of the coolest things happen during evaluation / proof of concept installs. Case in point, I was out at a client site all day yesterday doing an evaluation install of a security information and event management (SIEM) product. We got a few firewalls, IPS's, and IDS's (yes, they have both IPS and IDS) throwing their logs at the collector appliance, and while that was catching logs, the manufacturer SE started explaining some of the fine points of the product. As we were looking through the alerts that were popping up, we saw a high severity alert come from their IPS (attempted trojan install from a malicious website). We confirmed with the client that the alert was actually telling us that the attack had been blocked (just like an IDS, an IPS can alert without blocking), so we weren't too concerned with the attack. But since it was a good example to show some correlation features of the product, we decided to focus on the alert.

We drilled down to look at the attack, looking for source IP, destination IP, port, etc. As we looked closer, we noticed that there was ping traffic starting to come from the destination of the attack (a host on my client's network). We kinda looked puzzled since we had confirmed that the attack had been blocked. Why would the host start showing weird behaviour if the attack had been blocked? When we looked closer at the traffic, we found that both the source IP of the attack and the destination IP of the pings coming from the internal host were in China. Not a huge coincedence since China is a huge hacking playground, but it still smacked of something out of the norm since we had seen a blocked attack and a host acting weird within seconds of each other.

The security analyst finally determined that the host had been compromised (it may sound obvious that the host was compromised, but the client is an educational institution, so they are very open and see a lot of strange traffic). What we finally figured was that the blocked attack was either masking the real attack, or the real compromoise came ono the heels of the blocked attack.

The analyst started doing some more data gathering on the attack as we were leaving for the day. I am hoping to get some more data today when I go back out. But the point is not just the attack. It was really neat to see the correlation happen with the product we were installing. It obviously still takes a human to make the final judgements needed to track down the problems, and I don't think that will change in the next few years. But drilling down into the data and getting a good look at the attack from a few angles with just a few clicks was a confidence booster for the client. And the timing was good for the manufacturer and myself as well, since that might be the memory in the head of the client when he starts making a decision on what to buy!