AGIX Discussion All HowTo's CISM & CRISC

A SIEM as a Process

This article explores the concept of a SIEM as part of a process, and without a process, you don’t have a SIEM.

A SIEM is a security information and event management system. In it’s full capacity, it accepts logs from a variety of sources and via a variety of protocols, assesses those logs for threats based on threat feeds and rules, and forwards any findings onto the responsible role or team for remediation. If this isn’t how a SIEM is being used, then it’s not a SIEM.

The goal of a SIEM is to enable remediation of identified incidents. This works only if there’s a process.

Before we get to the process, the following clarifies the three phases of a SIEM in the opening paragraph are:

  1. To accept logs from a variety of sources and via a variety of protocols. Logs will be shipped using Syslog/CEF, EventLog, JSON, GELF and more. They can be over UDP or TCP, and they can be encrypted or clear-text.
  2. To assess [those] logs for threats based on threat feeds and rules. Threat feeds should be a combination of opensource feeds, commercial feeds and (in some cases) government feeds. They should be updated regularly. Allowing for manual rules enables custom requirements for identification of anything the organisation would find interesting – such as information exfiltration by custom document tags.
  3. Forwards any findings onto the responsible role or team for remediation. This is the output of a SIEM. An identified incident is made known to the responsible people. This could be the system owner or whoever is responsible for the system day-to-day. This person takes on the ownership of remediation.

So far we’ve discussed what a SIEM is, and now we can talk about what a SIEM process looks like. The following diagram illustrates the process. While the process may vary between organisations, this article focuses on a sensible balance of complexity and manageability.

The following details each phase of the above diagram.

  1. Source System. This system sends logs. It is the log origin. Some examples are: Firewalls, Web servers, Web Applications, and Domain Controllers. The logs will vary in type and shipment method.
  2. Aggregator. This is a system often placed before the SIEM. It allows for log filtering, enrichment, tagging and more. Other benefits are: Cost savings due to SIEM charges (often) by ingestion volume, and feature rich log receiving capabilities.
  3. SIEM. This was defined in great detail above. For now, it’s accepting logs, assessing them for incidents, and forwarding the alert on.
  4. Incident Management. This could be a ticket-management system with defined responsible people/roles/teams that tickets are automatically assigned to.

The 4th phase loops back to the 3rd phase. This is because the SIEM would typically have a means to track the progress of remediation of an identified incident. The incident status needs to be updated to match the progress of remediation. Much like a ticket-management system. However, it is important to use an external ticket-management system rather than the SIEM’s in-built ticket-management system because there are other non-SIEM related incidents to track, factoring in the wider organisation. Additionally, you want to be able to swap-out the SIEM at a future date in order to replace it with a more suitable SIEM, and losing ticket history is undesirable.

Phase 3 loops back to the originating system at phase 1. This is to ensure that the incident has been remediated. Of course, the incident may stem further than the original system. Consider the original system may have been the opening for a advanced threat actor. But regardless, the originating incident still needs to be remediated so that such an event will not reoccur.

In a business process, the SIEM and ticket-management system still need to be updated with the final status. This could happen (depending on the organisational process) only once the original state has been confirmed resolved, or possibly immediately with the knowledge that the responsible person is satisfied with the remediation efforts.

These phases ensure the lifecycle of an incident is managed, effective, and auditable.

Leave a Reply

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