What SIEM Is And What It Shouldn’t Be
6 min read
I was having a conversation with a department manager the other day around security architecture and building common logging practices for application development. In the company there is a process to send all logs for production critical applications into the central SIEM (Security Information Event Manager or Security Information and Event Management – depending if you are referring to the product or practice). During the conversation it became clear that there was a lack of understanding to what the SIEM was and why it was so important that the logs were sent into it. As I had conversations with developers, project managers, and other non-security folks I realized that the SIEM what another mysterious acronym. As an information security geek I have always been a believer that when people don’t understand the importance of the security practice, adoption is near impossible because the tools are looked at as a security or IT department toy and not as a business enablement designed to help everyone.
Let’s break down what a SIEM is to understandable context.
A SIEM is a software solution that is designed to collect all the audit, application, system and any other logs generated in your environment. It’s a massive repository that pulls everything happening into one place. Imagine a single business critical application and all the components that make it work. You have web server(s), application server(s), proxy server(s), database(s), authentication processes, access processes, transaction processing, exports and imports, backups, patching, operating systems, off the shelf software and custom applications. That is just scratching the surface. The point being in an application to get a clear understanding of what is going on end to end in your solution there is more than one place to put it all together. This is where a SIEM comes in.
Here’s a more technical explanation of a SIEM –
A SIEM is a software solution that normalizes, filters, correlates, assembles, and centrally manages other operational events to monitor, alert on, respond to, analyze, audit, and manage security and compliance pertinent information. SIEM systems provide fundamental security operations. They provide more efficient and useful analysis capabilities for information security professionals and their organizations.
When you hear IT folks talk about a ‘single pane of glass’ they are talking about one place to see everything. From a security point of view there is a need to be able to easily see, analyze and track a system or user’s behavior and the SIEM is the only viable way to accomplish this. Without a SIEM an individual or a team needs to manually pull in logs from all the components, massage the logs to look the same, then try to read them. When you have millions of records to filter through it becomes a task that cannot be completed. The dark side of security analysis and investigations is you are against time. The ability to detect, alert and respond to security events is time sensitive. Ask anyone that has been impacted by a breach or stopped one before it got out of hand and ask them how long it took them to find it? Were they alerted to a behavior instantly or within minutes or months later through a manual analysis?
The other benefit of a SIEM is the integrity of the activity records. In an environment a SIEM gets the logs a few different ways, each with their own pros and cons. The first way is the SIEM will have a remote agent installed on a server that sends the logs near real time. Another way is the SIEM will remotely retrieve the logs from the server without an agent. The least efficient way is a daily upload of logs from a server to a location where it is loaded into the SIEM. In my opinion I always try to get the near real time solution. The reason is security and significant reduction of risk of an attacker or malicious employee attempting to erase or modify the logs on the server. Once the SIEM gets the log entry the server is no longer the source of truth.
Here’s how it could work – An attacker logs into a server. That logon event is sent to the SIEM in a far remote location that the attacker does not have access to. In the SIEM there are rules and analysis triggers configured for security events, one basic one that should be on in all SIEM solutions is to alert immediately if the source server stops sending logs. Now if you have reduced an attackers time to do damage down to minutes and the server’s logs are intact in the SIEM, even if the attacker deletes them off the server. Much harder to hide the trail.
That’s just one example in detail where a SIEM can help get that viewpoint centrally across the hundreds or thousands of servers in an environment.
Here are the top functions a SIEM can bring to your environment (more detailed breakdown in the picture below) –
- Correlation – Pull multiple sources of logs together into a single session or transaction for analysis.
- Example – Generate a report on Binary Blogger’s logon activity between 10am and 12pm on Thursday. You can see all the servers used in that time in one report. The alternative is to look at all the servers, everyone, and see if he logged in during that time. Which is more efficient?
- Alerting – Create rules to monitor and alert on specific behaviors happening in the environment.
- Examples – Alert whenever an account is locked out or password is reset, accounts are created in an area, servers or services restart, application errors occur, AD groups are changed, etc…
- Alerting is the glue to bring full security monitoring to the front and center across all servers, even the ones long forgotten.
- Security – Monitor access control efficiency, monitor acceptable use within the environment, monitor administration level access and use – some regulations require the ability to prove anytime an account access a specific server containing PII or PCI data, monitor server communications, firewall rules and traffic flows. In security you only know what you know, it’s the things you assume or think you know that turns out to not be the case. That’s what opens holes.
- Reporting – A SIEM is much more than a security monitoring solution. Analytical reports can greatly improve the business by providing SLA metrics for a help desk, AD health checks on traffic and loads, overall analytics on system status, account counts, login behaviors, training, justification for infrastructure improvements. Once you get the activity logs from all the systems centralized the reports you can view are very beneficial.
Here are the things a SIEM should not be –
- A Log Dumping Ground – If a SIEM is brought in to collect the logs for later use. A SIEM is not a place to send logs and leave them be.
- A Security Only Tool – A SIEM can benefit the entire business and can be delegated out to allow for reports or views on a need-to-know basis and protect the sensitive data.
- A Troubleshooting Tool – A SIEM does collect logs but not everything, only logs appropriate for critical security and environmental purposes. Trying to load everything and let dev teams use it to troubleshoot applications or development teams is not what a SIEM is meant for.
- A single security solution – A SIEM is a powerful tool but it should not be the final solution for environment visibility. It will be collecting high level security events but will not contain deeper diagnostic data.
- Treated as an IDS (Intrusion Detection System) – SIEMs are investigative solutions, the events it has have already happened and depending on the log ingestion are minutes or hours old. Don’t use it like an IDS or any other perimeter security solution. A SIEM will support those but not replace them.
In a simplistic explanation that’s a SIEM. I didn’t go into the next step of how to deploy it in an environment, how to operationalize it and how to scope them properly. In a normal environment there are hundreds of millions of records to billions over the course of a year. How to do filter through all that and identify what’s important or not? That’s the art of security and a discussion for another time.
End of line.
Binary Blogger has spent 20 years in the Information Security space currently providing security solutions and evangelism to clients. From early web application programming, system administration, senior management to enterprise consulting I provide practical security analysis and solutions to help companies and individuals figure out HOW to be secure every day.
Subscribe
Facebook Page
Follow Me On Twitter
contactme@binaryblogger.com
