One of the core requirements of an Information Security Management System (ISMS) is to have a process for handling security incidents. Thus many organizations find themselves forced by regulation into running a SIEM (security information and event management).
While it is widely understood – and required by regulation – that the availability of accurate log data is a mandatory requirement for a working security incident management process, many organizations are still struggling to make sense out of it.
The problem starts with the technical definition of a security incident. As a single log record usually is not significant enough to trigger an alert, you will have to collect log records centrally, pipe them to your SIEM platform, define time windows, specify events and event counts in order to build rules that describe meaningful scenarios.
It is easy to see that without experience and knowledge of a real world attack pattern, an organization will end up in one of two extremes: either the rules will fire very rarely, or too frequently. In the first case, you simply will not be aware of incidents, in the latter your incident management process will be overloaded because of a huge number of false alarms. In fact, this will also lead to the same result – unnoticed incidents – as your staff is busy working on harmless artefacts.
From that perspective, it is no surprise that recent studies found that the average detection time of a security breach is more than 200 days, and that incidents often only get detected through observation from outside the organization.
To make things worse, the log volume can reach quickly terabytes, which calls for an appropriate storage – and possibly increased license fees from the SIEM vendors. SIEM is entirely mysterious; this seems to be the quintessence for many organizations, but first let’s step back and have a look at where we want to get.
SIEM Objectives
Log events need to be collected centrally and alerts need to be triggered in a timely manner with high precision. All events worth an investigation should be identified. Also, SIEM reports need to be aligned with the security policies of the organization in order to prove compliance. This implies that there can’t be a canned solution, but many organizations still seem to be searching for it. Adapting a SIEM will be quite a challenge, but it can be tackled.
For sure, setting up meaningful rules for filtering out the noise from log data is the main difficulty. The key idea is that you need to know the taxonomy of attacks. To illustrate this, let’s look at a scenario with an outside attacker. You should expect that attack is carried out in phases.
First you will notice that there is a reconnaissance phase where the attacker will use network and port scans to find potential targets. This is usually harmless looking traffic, where the most interesting information from an attacker perspective is not where traffic is blocked by a firewall, but went through because it is indistinguishable from legitimate traffic, and therefore not even get logged usually.
However at that stage it is characteristic that an attacker will not continue a connection as soon as they have got enough evidence that they have found a potential target. If you find a number of dropped and orphaned connections in your logs, originating from the same IP addresses, you will have a good indication that these might be the early stages of an attack.
So we will want to keep these IP addresses for further reference when we discover more suspicious activities which is expected to occur in the following phases and an alarm with low severity should be triggered by the SIEM.
In the second phase, an attacker will try to find vulnerabilities with the hosts and services discovered in the first phase. An IDS can help to identify and log fingerprinting activities. If we are seeing here the same IP addresses as during phase one, the SIEM can correlate these activities with the activities detected previously, and send an alarm with an increased severity level.
If the attacker performs fingerprinting to identify a specific vulnerable service, the SIEM could also make a correlation here and send an alert with severity high to initiate incident response.
If the attacker has identified a vulnerable service, there might be only one more connection necessary to get in. If you have an IDS in place, you might be able to observe this malicious traffic, the magic bullet, log it and make the SIEM correlate it again to the phase two information. An alert with highest severity should be triggered here.
To summarize: Your SIEM rules should build on each other. You need to identify and score potential attacker IP addresses and potential targets. Each suspicious traffic will add to this score. Linking threat intelligence information to the SIEM will help here also. If the score reaches a certain level, the SIEM should trigger an appropriate alarm. Properly tuned, 99.99% accuracy has been reported to be within reach.
The Whole Picture
You should follow a top down approach: start with writing the logging policy. Only log data specified should be sent to the central log server. This will help you control your log volume while concentrating on the crucial events.
Next, make sure that you have identified your critical assets - your crown jewels. At the bare minimum, for these you will want to have log correlation. Connect your assets to your SIEM platform and make sure you have processes in place to register new and deregister decommissioned assets. Verify that all registered assets are sending log records on a regular basis. Make sure your capacity management and license management are monitoring storage and license usage.
Understand what a normal network behavior is within the context of your organization. Understand the taxonomy of attacks: what happens at which phase of an attack, and how this network traffic can be distinguished from a normal traffic.
Know your weak points. How long does it take for you to install the last updates? Is it because of business reasons that you cannot install an upgrade? Do your employees attend security trainings periodically?
Put these insights into rules. Define what needs to be done within what timeframe when an incident is observed and set up an incident response team. Having identified threats, vulnerabilities and the value of your assets before enables you to run a prioritized approach based on risk, which will increase efficiency.
Start small: a few highly accurate rules are much better than a larger number of fewer accurate rules. Consider using a state machine model to track, link together and escalate events over time. Make sure that through a penetration test, your detection and incident response are indeed capable of detecting malicious activities.
Last but not least, adjust your processes based on performance observed, changes in your infrastructure and changes to the threat landscape.
Linking to an ISMS
If you are running a SIEM to a good share because of compliance reasons, your main focus has to be on the consistency to your policies and the establishment of the reports that will allow you the verification accordingly. Also, automatic ticket generation would be desirable in order to prove that your processes are really working: if you have inaccurate rules and automatic ticket generation, most likely you will not be able to show evidence that security incident tickets are handled in a timely manner.
A good metric for judging the efficiency of an SIEM is the ratio of true incidents and total incidents reported. If this ratio is 99% or worse, a low maturity level can be stated. Also, the response time is important: how long did it take from the first suspicious events to remediation? Is this time within the boundaries defined by SLAs and policies?
Conclusion
Introducing an SIEM to an organization without proper planning has the potential of becoming a real disaster. Therefore, make sure you have understood the challenges and have skilled and experienced staff to deal with this. You can’t practically run a SIEM as a one man show.
Among others, your staff need to have these skills:
- Cyber security professionals who are trained on the SIEM tool chosen and recent attack vectors
- Penetration testers to verify that real world attacks can be indeed detected
- Forensic experts to collect, preserve and analyze digital media in the aftermath of an attack
- Administrators with strong operating system, database, storage and specific SIEM platform skills
- System engineers who can integrate the logs of your servers, network and security equipment into the centralized SIEM platform