You have signed the contract, installed the cabling, and configured your network devices. Syslogs are streaming into your new SIEM and alerting is operational. Finally, you can stop reviewing thousands of logs each day and move on to something a bit more interesting.
(mic drop)
But if it were that simple, I would not be writing this. There is still more work to be done.
Security is not a set-it-and-forget-it endeavor. It is an ongoing process and culture.
In the case of your new SIEM, it requires a continuous awareness of what constitutes right and wrong within your environment. When a SIEM is first turned up, the proud new owner is not simply getting alerts, they are getting a lot of them. And the number of events being collected in just a few minutes can be blinding.
Now it is time to tune your SIEM.
Your SIEM Optimization Strategy for Success
Tuning a SIEM is the process of eliminating the false positives, reducing the noise, and making the adjustments necessary to alert on the important things that happen in your environment. It is what makes the SIEM valuable to you for cybersecurity as opposed to just another logging system that sits in the corner gathering dust.
Tuning a SIEM can be separated into three parts:
- Too many alerts (Alarms)
- Reducing the noise (Events)
- Alerting on the important things (Rules)
In this blog post, we will be looking at the first of these.
Dealing with Too Many Alerts (Alarms)
We will begin to answer the question,
"Now that I am getting all these alerts, what do I do?"
As I look at the alerts on a new SIEM dashboard in front of me, I see numerous alarms, most of which (if not all of them) are not real security events.
They are false positives.
These false positives fall into three buckets:
- Indicators of operational issues
- Policy concerns
- Nonactionable information
Eliminating False Positives
Glancing at the dashboard of a newly installed SIEM, some typical alerts that will be displayed are:
- Port scan Alert - 12 minutes ago
- Successful logon to default account - 54 minutes ago
- Dropbox in use - 1 hour ago
- Brute force logon attempts - 1 hour ago
- Critical IPS Event - 3 hours ago
Knowing and being able to decide if these are false positives or not requires a knowledge of the contextual environment. Depending on the company's information architecture, policies, and applications, any of these could be a false positive or it could represent a matter of grave concern. Let's take a look.
1) Operational Issues
On day one of your SIEM's operation, some of the alerts you see, rather than being indicators that a hacker is rampant on your network, are instead simply indicators that something is misconfigured.
For example, you might see:
- services running as 'administrator' being flagged as default account logons
- services trying to use old passwords causing brute force alarms
- network management system telnet sessions being flagged for unencrypted transport of logon credentials
While these alerts are not "house fires," they do need resolution if your end goal is a secure network and infrastructure.
Having these alerts popping up red every couple of minutes, hours, or days not only obscures the real house fires but are likely indications of a needed security improvement.
For this category of alert, I recommend the following three steps:
a. Suppress the alert.
Clearly document the reason for suppression within the SIEM itself either within the rule name or as a comment.
b. Create a ticket or task, however you track work to be done.
This activity identifies the operational issue that has been revealed so it can be resolved in an orderly manner.
c. Post resolution, undo the alert suppression.
Once the operational issue is resolved, delete the suppression rule so it will alert once again should the same configuration problem creep back into the environment.
Issues being suppressed and not resolved should be resolved as part of your periodic risk management review.
2) Policy Concerns
Related to the operation issues mentioned above are policy concerns.
These types of alerts are typically warning about:
- people connecting to personal email from work (potential path for data loss)
- Dropbox in use (another data loss path or malware entry point)
- internal servers running over HTTP (data exposure and man-in-the-middle implications)
Good, bad, or indifferent, the validity of these alerts is largely dependent on your company's policy.
- If there is a policy against the alerted event such as: "Employee will not use VPNs to bypass web filtering mechanisms," then the alert is real and the root cause needs to be resolved.
- If the flagged event is within policy (maybe Dropbox is the approved way to transfer advertising documents to a print shop), then you should tune the SIEM by suppressing the alarms in the future.
3) Unworkable Alerts
We have one more bucketful of false positives to deal with. This bucket contains alerts that are either the course of a normal business day or are not actionable.
Alerts Due to Normal Business Activities
An example of an alert that is part of the normal business day is:
Indication that an account has had an escalation of privileges, that account is used for backups, and the escalation occurs every day at 3:00 PM.
In this example, since you likely don't have the ability to change the way a particular software package works, and the package is likely filling an important business need, the root cause of the alert cannot be eliminated. Instead the alert should be suppressed. Again, clearly identify why the suppression rule exists, and review the rule periodically.
Not Actionable Alerts
A typical event I would say is non-actionable is a port scan of a web server's IP address. Port scans are seen all the time on internet facing IP addresses and there is not much that can be done to stop them. (Hopefully the alert is coming from your firewall and not the server itself.)
Before you declare any alarm non-actionable, you should ask yourself if there is ever something you need to do as a result of such an alert.
If your answer is that, in every case, you will yawn, sit back, and say "just another scan," then the alert is a candidate to be suppressed. If you do act on such an alert, maybe by extracting its source IP address and adding it to a blacklist, even if only occasionally, then the alert is workable and should not be suppressed. Here you should have a documented Incident Response plan in place that specifies the action you will take.
A Final Caution Regarding Alert Suppression
One final comment regarding alert suppression before I wrap up.
Whenever an alert or event is suppressed within a SIEM, there is an inherent risk being accepted.
You are saying that the suppressed alert costs more to look at than to not look at; you are making a declaration regarding your confidence level that the event is what you believe it to be and will always be that.
To reduce the risk being introduced by the creation of suppression rules, care should be taken to limit their scope and focus them as tightly as possible using specific machine, IP address, or time period parameters within them that will allow for the exact same alert on some other device or some other time of day to be flagged and investigated.
Conclusion
Reducing the number of alarms that are emanating from your SIEM allows your security team to be more efficient in the use of their time and more effective in focusing on and resolving important issues quickly when they arise.
There are only so many hours in a day and your security personnel's time is valuable. The faster you can get them looking at the right things the better.
>> Learn more about Corserva's managed SIEM service. <<
If there are more alerts in one day than your security personnel can review, then some level of suppression must be implemented that will bring the most important items to their attention the fastest.
Stay tuned for part 2 in this series on SIEM optimization which describes steps you should take to reduce the noise, or events, when tuning your SIEM.
About Corserva's Managed SIEM Service
With Corserva’s Managed SIEM, you gain enterprise level cybersecurity for a fixed monthly cost, with no hefty licensing fees and no additional staffing requirements. The solution provides predefined reports you can provide to auditors to show compliance with PCI DSS, HIPAA, NIST 800-53, and NIST 800-171.
Collecting log files and analyzing them is at the heart of the solution. We can accurately identify, contain, and remediate threats in your network. The built-in security intelligence combined with our expertise in correlating the applicable log data enables us to identify policy violations and respond appropriately.
Corserva’s staff have key security certifications including CISSP, CISM, CGE IT, CRISC, CEH, and CompTIA Security+. We provide 24x7x365 support for our clients from our US based security operations centers.
Request a quote for Corserva's managed SIEM service.
