Some companies use cloud-based security information and event management (SIEM), and others use SIEM that has been installed in a local data center. These on-premises SIEMs can be run on Windows Servers, Linux Servers, and within virtual machines (VMs) or containers. While the security vulnerabilities for each of these instances will be unique and highly dependent upon setup, you can still verify your security using the same checklist, which we’ll give the acronym VIDA DUCA for the steps below:
Each item on the checklist is a reminder to address a potential source of vulnerabilities. This checklist should be used for the initial installation and for ongoing and periodic updates (quarterly, annually). Following the checklist will help focus your team on the ways in which the security of your company’s SIEM implementation could be undermined.
See our picks for the Best SIEM Solutions
Vulnerabilities
Vulnerabilities can be found within any program, application, or system. With the systems (servers, VMs, etc.) hosting your SIEM, vulnerabilities most commonly stem from errors or overlooked issues during installation. Unpatched vulnerabilities will need to be mitigated, and patches will need to be applied prior to exposing your SIEM system to external connections.
You can use penetration and vulnerability testing to locate known vulnerabilities, but there may still be zero-day vulnerabilities discovered in the future. Unfortunately, most companies do not have the resources to thoroughly test software or hardware for vulnerabilities. So, you may have to rely on researchers to discover vulnerabilities and report them. Once reported, your vendors (SIEM, OS, etc.) can issue patches and updates, which should be applied as soon as possible to eliminate these vulnerabilities.
Also read: Testing & Evaluating SIEM Systems: A Review of Rapid7 InsightIDR
Integrations
To make SIEMs valuable, they need to integrate with many different systems: endpoints, IoT, servers, networking equipment, VMs, cloud resources, and more. Each type of device needs to be able to send logs to the SIEM for analysis, and each system requires integration. While some devices might integrate directly, many others require writing one-off code to extract and ingest the log data.
This checklist item reminds us to consider each integration point as a potential point of failure for the SIEM that needs to be double checked. You need to check the security of the integration and test your code via pen testing or code review.
As a matter of practicality, you would want to prioritize the highest risk systems first. Which integration connects to the highest value assets or business processes? Which ones connect to the largest number of similar sub-systems?
Defaults
Many SIEMs come with default configurations—some of which may be blatantly wrong and insecure for use. You should carefully examine and consider any defaults that were retained for their impact on security.
Not all defaults will be obvious. You may need to dive deep into nested menus of options or check configuration files related to the software. You should make sure to discuss this topic with your SIEM provider during installation, so you know what to check later. Asking your vendor for a checklist of their default settings to follow is within the bounds of reasonable requests.
Alerts
After the initial setup, you’ll begin ingesting data, and the system will begin to produce alerts. Congratulations! Now the real work can begin. SIEMs exist to generate alerts, and you need to make these alerts valuable.
When it comes to alerts, you need to consider four primary issues in an iterative cycle.
- What alerts are you supposed to receive?
- What alerts do you actually receive?
- What alerts do you want?
- How many alerts is too many?
You should start by examining the settings on the SIEM. You know what alerts you think were set up, but do you actually receive those alerts? Do those alerts actually inform you about what you intended?
When considering alerts, you should follow the same risk-based priority used during integration. Do you receive alerts on the highest value assets? Do you receive alerts when something threatens the most valued business process? If not, you need to add what is missing.
You can also simulate events to verify it triggers the alerts you expect. If not, then why? Is it the setting or the simulation? Repeat until you receive the alerts desired on a regular basis for all required systems.
Another major factor for alerts will be cost. SIEMs often charge money by the amount of data fed into the system, so many organizations choose to pre-screen alerts prior to sending them to the SIEM. You will need to examine any of these pre-screening filters and ensure that the data and alerts being withheld are truly benign and not something you should train your artificial intelligence (AI) algorithms on.
After you start to receive the desired alerts, now you should check the volume of alerts for your security analysts to monitor and address. Are you generating so many alerts that some are ignored? Are there non-critical alerts that simply add noise? To avoid generating too many alerts, consider alternative potential alerts that might be more useful to monitor.
Once you have the SIEM dialed in correctly, you can test the SIEM with a purple team. With this type of test, part of the team plays the traditional red team role and attempts to trigger alerts. Afterwards, the part of the team that played the blue team role sits down with the red team and they examine the results. Did the alerts trigger as desired? Did the SIEM or the security team interpret the data and the alerts as they should have? Any discrepancies should be addressed and resolved.
Data Sources
Our SIEM uses the data it receives to make decisions. Bad data can lead to bad decisions or missed alerts. When you start the SIEM, you cannot assume that your endpoints are in good condition. Some SIEM alerts may only be triggered by a change in the condition of an endpoint, and if the endpoints start off and then stay corrupted, no alert will be generated.
Interestingly, smart contracts for blockchain systems have a similar issue. They call it the “Oracle” issue. If your data source, your “Oracle,” is corrupt, incorrect, or contaminated, you simply can’t trust your smart contracts to execute correctly.
You can gain confidence in the quality of data coming into the SIEM through verification audits of the endpoints. Initially, this might require you to audit every system, but those pressed for time or performing a subsequent annual update might pursue verification of a random sampling of systems instead.
Data corruption isn’t the only way to generate bad results. If the wrong log files are picked up or incomplete log files are generated from your endpoints, then your SIEM may come to misleading conclusions. Most SIEMs use AI or machine learning (ML) algorithms to learn from data. When these algorithms are fed the wrong type of data it may create biases that will be difficult to counter.
IT and security team members typically are not data scientists and may not understand how settings on log files might skew SIEM algorithms. To manage this issue, you will need to incorporate data scientists into your team or communicate with your SIEM provider. This communication should happen early in the setup phases.
Users
The number of users for your SIEM should be limited, and admin users should be even more limited. When determining your users, consider the number, the type of access, and the training.
You may need many users to help integrate and implement all systems during the initial installation, but many of those users will not need access on an ongoing basis. The ongoing number of users should be limited to internal and external experts that need to modify, verify, or manage the SIEM.
Some users may only need to verify proper data feeds and may only need a basic level of read-only access on an ongoing basis. Others may need to adjust alerts or modify algorithms within the SIEM and require a higher level of access (see Access below). As with the number of users, specific-access users should be evaluated carefully at the beginning and verified on a periodic basis (quarterly, annually, etc.).
Users should also be carefully trained for the level at which they will be expected to operate. Heavy training should be done initially to ensure a proper setup of the SIEM, but should be refreshed periodically to learn about new features of the SIEM or to understand the types of alerts being generated by AI/ML algorithms.
Configurations
SIEMs can be established in three ways:
- Installed on servers, VMs, or containers in the local data center
- Installed on cloud servers, VMs, or containers
- Contracted with a SIEM service provider (to whom you send data)
Regardless of the choice, misconfigurations can wreck the SIEM capabilities and security. With outsourcing, the configuration headaches can sometimes be transferred to the service provider, but in your own data centers, the responsibilities fall on your team.
You need to lock down the environment hosting the SIEM software as you would any other critical corporate function such as Active Directory or Domain Name Service (DNS). If a malicious actor can gain access to your local machines, they can likely affect the flow of data into and alerts out from the SIEM, which would disrupt security processes.
You also need to check the configurations on your SIEM program. Just as you checked the default settings, you should also double-check the settings you intentionally changed. Did you change them correctly to meet your needs? You need to verify these settings before going live.
You also need to continue to check settings. Do those installation settings still suit the business during your checkup two years later? Your business won’t be static, so your SIEM may also need settings adjusted to keep up.
Access Levels
When establishing a SIEM, or any sophisticated software, there will be different possible levels of access. From the basic user account to the highest level of administrator access, each account offers a spectrum of control and access to security settings.
When considering the access for the SIEM, you should pursue the principle of least privilege, zero trust. In order to implement it, you also need to know what levels of access are available with your software.
Once you establish what is available, you need to create a comparison of levels of access: What settings and configurations can be modified at each level of access, and what level of access is appropriate for each type of user? Once determined, the access levels should be periodically reviewed to verify that software updates have not changed any understanding of the underlying software and its permissions.
Also read: Best Privileged Access Management (PAM) Software
Getting SIEM Right
SIEM’s are amazingly useful tools. They are flexible, powerful, and can offer critical insight into the status of an organization’s infrastructure. However, inadequate implementation can mislead security teams, waste their time chasing false alarms, and miss significant security threats. Using this checklist can be a handy way to systematically review a SIEM’s implementation and settings and avoid trouble later.
Further reading: An Investment Firm Built Its Own SIEM. Here’s How.
