Podcast

Dr. Anton Chuvakin leads a panel podcast on SIEM for enterprises and small organizations. He is joined by A. N. Ananth (Prism Microsystems), Nick Briers (IBM Tivoli) and Brian Singer (Novell).

Anton Chuvakin: What, in your opinion, are the defining features of a SIEM? Is it correlation, reporting, normalization or a combination of these?

A. N. Ananth: It’s best to think about use cases rather than defining it by what the term means. We find that people think of this technology first and foremost for compliance reporting, secondly for security management, and then sometimes for operational requirements. For me, the defining aspect of SIEM would be looking at security information from across the enterprise, not just log data, because while that’s important it’s certainly not all of it. It’s also to do with things like change audit, security config base line assessment and so on. From a feature perspective; reporting is necessary, search is necessary, the correlation rules are necessary, and that’s our view of what SIEM really means. 

Nick Briers: I believe it to be a combination. I see a lot of clients looking at SIEM and how that fits into their security framework, so we see SIEM as being a cornerstone of that security framework for our clients. SIEM is a combination of log management, external threat, internal threat, forensics, audit, compliance management, operations management—and the list goes on. But it’s about bringing all of those capabilities together and it shouldn’t be looked at as a standalone. SIEM is a cornerstone and a framework, and it has to integrate with the rest of your enterprise. You should look at how it’s integrating with your change management systems, your database, your workflow and so on. SIEM fits in with the rest of the way your security framework is implemented. I like to think of it as the video camera of a surveillance system. It’s responsible for detecting and telling. Yes reporting is key in that; yes forensics is key; the ability to investigate is key; the event management is key; and the ability to detect external/internal threats is key. Just the basic acts of collecting logs and storing them is also key. I’m not saying that you can’t do one without the other, but I think they’re all important parts of the overall definition. 

Brian Singer: I agree with a lot of what the panel has said, but I also think you have to consider the reason we use SIEM. When you look at what you’re actually trying to get out of a SIEM, you’re basically trying to understand when there’s a problem with security in your environment. The reason SIEM exists is because we have so many different systems and layers of security that it’s hard to get that enterprise-wide view. I actually don’t view a single feature as the defining feature of SIEM. I think correlation is an imperfect way that we’ve devised to get to that end goal of understanding when there are anomalies in our environment. We haven’t yet devised the perfect way to do it. With correlation, you have to define a rule and you have to know what you’re looking for ahead of time in a lot of cases. You start at a use case for the business problem you’re trying to solve and work back from there. You can get there from correlation or you can get there from reporting if your use case is compliance. But these aren’t necessarily the defining features.