So you have a SIEM or have been asked to evaluate one, what now? For those of you that are unfamiliar with this acronym SIEM or SEIM stands for Security Instrumentation/Event and Event/ Instrumentation Monitoring. In the world of security, this is one of the more important platforms for organizations big or small. This platform allows you to aggregate all your logs from all IT/ IS systems into one consolidated view saving time by having a single pane of glass for all your events, logs and instrumentation. Let’s dive into the core components that are required to make this happen.
"SIEM allows you to aggregate all your logs from all IT/IS systems into one consolidated view saving time by having a single pane of glass for all your events, logs and instrumentation"
First, in order for a SIEM/SEIM to work, you must have complete buy-in from the organization and all its business lines. If you collect all your windows logs but are missing the network logs the ease of pivoting from one event to the other is all for naught for example. Collecting events and normalizing, aggregating, correlating and reporting/alarming off of them requires that the organization buy into this single pane of glass concept. The outcome of this also allows all the logs to be centrally managed and comply with any guidelines that the business must follow whether PCI, GLBA or HIPAA for retention and investigations in the event of an incident.
SIEM/SEIM will also be enhanced by the security tooling you invest so much time and effort in. By integrating all security tools events, they become your own internal threat intelligence source. By leveraging network logs, OS logs and security tools events and correlating them, you are better equipped to investigate incidents quickly and efficiently. This also allows for scripting and automation to be done by integrating actions in more mature SIEM implementations to remediate either automatically or via a manual process without the need for the analyst or incident responder to log into the remediation tool whether a firewall or endpoint detection and response platform.
You can also trigger events to alert off a combination of events that you can either build yourself off of IOC’s and KRI’s you have or build off of ones that come pre-built in most of the SIEM’s out there on the market. Some even come with AI/ ML (Artificial Intelligence/Machine Learning) built into those correlation rules. An example of this would be a detection of an IDS (Intrusion Detection System) seeing a user account attempt a login and fail from China, and the same user account also fails the logins from New York on the Domain Controller logs. Once that event is correlated most SIEM’s will allow an action to be taken like an email alert, auto-remediation by locking the user account and creating a ticket in your ITSM platform of choice.
Another point to make is the log retention for compliance as well as compliance-based reporting and alerting. This is important as organizations can struggle to quickly search historical logs or even roll out logs properly. For example, there may be a requirement from a framework or guideline the business must follow to retain 6 months’ worth of historical logs yet the organization either does not have the capacity or just stores more than needed. Within the SIEM retention policies can be set granularly per each data point to not only hash, encrypt and compress the raw logs but they are also quickly retrievable and searchable via keywords and dates. With this we also have the ability to build reporting, alerting and auditing of what violations of policy, frameworks or guidelines may have transpired. Dashboards are quickly and easily created and filtered to display this information as well.
So with all of this why is this notion of a SIEM not something that every organization buys into? The overhead is the answer to this. You must have FTE’s dedicated to setting this platform up properly and professional services. A SIEM also requires constant tuning, with all the events, dashboards, alarms, correlation and reporting that gets put into it the SIEM can be easily overwhelmed and become shelfware. Carefully testing correlation rules is another piece of advice I would give to anyone wanting to implement them, a rogue correlation rule can literally bring down the entire platform by sucking up all the IO on the appliance.
So there we have it now why do we want a SIEM with all the above? It’s simple really, consolidating all of your events into this single pane of glass saves time. The main return on investment is when you are detecting more events quicker and remediating issues faster. But of all the benefits it is giving you back your IT/ IS staff to properly engineer solutions. The last point to make is that a SIEM is a collaborative tool meaning every business line of the organization should be able to put their own stamp into what they can use it for. Simply put, the organization will have a force multiplier by just having a SIEM to be able to monitor, alert, report and correlate what is happening whether for their responsibilities or for the entirety of the organization.