Design Points for Implementing a SIEM

Reuters had a news story on the wire this morning titled “HP Enterprise Lets Russia Scrutinize Cyberdefense System Used by Pentagon“. When I read the story, I was expecting something about some super secret defense system that was of the scale of Stuxnet and used AI to some unimaginable extent. Instead, what I saw was a story about ArcSight and how HPE, in order to sell into Russia, had to show it’s ArcSight source code to prove that the US didn’t have some sort of backdoor that could be leveraged against Russia. In essence, it was Kaspersky but in reverse.

So I thought I’d talk to day about SIEMs and design considerations for implementing them. It’s important to understand what a SIEM is and is not and to then design around those capabilities. To make ArcSight, or any other SIEM, sound like a super secret cyberdefence system is just wrong and the height of sensationalism.

So let’s start with an understanding of what a SIEM is. A SIEM, or Security Incident and Event Management system is basically an aggregation point for security logs. It takes logs in from various systems throughout an organization and, if a system isn’t sending it’s logs to a SIEM, the SIEM has no way of acting on it. So the first REALLY important point to understand about a SIEM is that it is only as good as the logs that it is fed. In short, it follows the old computer saying of “garbage in, garbage out”.

A SIEM is NOT the creator of logs. It is an ACTOR on those logs. You feed the logs of any system that has security logging turned on into the SIEM so that you don’t have to go to each individual log source manually. So Servers, Network devices, security solutions such as Anti-Virus and NIDS, Firewalls, etc, all can send their logs to the SIEM. Notice I didn’t include Applications? That’s because most applications don’t have logs that can correspond to security activities. You may be able to interpret some of their logs as the result of security activity but you can’t really call those logs as security logs.

Okay, so you’ve identified the source locations of your logs. Now you have to get logs to the SIEM itself in order to consolidate them. Typically, SIEM’s with have two methods of getting logs from the source to the main management console. The first method, and typically most common, is to put a mid-stream aggregation point in a place where the sources can send their logs. ArcSight calls these things a “Logger”. Splunk calls them a “Forwarders”. LogRhythm calls them “Appliances”. Because the full logs are sent to these devices, you want to make sure there isn’t a Firewall or some sort of device with ACLs between your aggregation point and the source. It saves on the resources associated with the ACL control.

The second method used is typically an Agent based solution. In this case, an agent is placed directly on the log source and it then will interpret the logs and only send the information that is appropriate for the SIEM. It saves on network traffic and storage capability on the SIEM. The down side is that the log source itself now has yet another agent installed on it and this can lead to a need for more local resources. Choosing between an aggregation point and an agent solution is dependent on the volume of log information and whether your solution actually has an agent available for the source. But this is a design decision.

The last component of a SIEM is the actual Management Console. Again, different solutions have different names for the management console. But the Console is where the Security Analyst will review the logs themselves. They will set up the policies for their SIEM and then the console will reach out to the agents and aggregation points to get the information that is requested by the policies. The information is then received by the Console and then alerts are applied to them. Some SIEMs have the capability of applying advanced algorithms that provide a bit of some sort of “AI” to the logs, giving the Security Analyst a heads up as to what MAY be occuring by correlating events from various systems.

The last thing to think about when putting your SIEM in place is the types of reports you are looking for. And I’m not just talking about for the screen of the Security Analyst. Sometimes (actually, most of the time), Executives are looking to understand the organization’s security posture. This could come from a report on your SIEM. Or you may want to understand things like the number of devices that actually are forwarding logs. Remember, you can’t monitor what you aren’t logging.

SIEMs are really important to a SOC. But, at the end of the day, the actual source locations of the logs are the key to the success of a SIEM. If the SIEM isn’t receiving those source logs, then the fault isn’t on the SIEM for giving poor information. Remember;

“Garbage in, Garbage out”.

Hope that helps …


Leave a Reply

Your email address will not be published. Required fields are marked *