It is fairly common knowledge among security professionals that security information and event management (SIEM) technologies are complex systems. No matter the vendor or the system, SIEMs require hard work and dedication to ensure they are running at their maximum capabilities and providing the most benefit to the organization.
SIEM
When a SIEM is properly deployed within an environment, it can prove to be a great asset to numerous teams within an organization.
The information security team will see the greatest benefit, however, the information provided can also be used by networking, client/server, and even other groups outside of IT, like HR.
When deploying a SIEM technology there are numerous oversights that even the most seasoned security professionals make, which can unfortunately cause a SIEM to fail to produce much value for the teams that need it the most.
Complexity
As stated above, SIEMs are complex and at times can be intimidating to configure and manage. Many times, we see organizations with little to no security staff purchase a SIEM because they are told that they need it to solve some problem or gap within their environment. They take on this complex system without having an inkling as to how to manage or–more importantly–maintain it. A lot of money is spent with little to no benefit ever realized by the organization.
The primary reason for this is that it is very difficult for a SIEM to be someone’s “part time job” within the security group. Most security groups are very busy supporting the business and working on other tasks which means putting the time in to tune and configuring a SIEM takes a back seat.
Dedicated staff and time must be given to the technology if the organization wants a SIEM that is going to be beneficial. Without these dedicated resources, the security team is going to be frustrated with the technology and it will most likely sit in a poor state until it is removed.
Resource Utilization
When a SIEM is deployed within an organization, the first thing everyone wants to do is send everything to it.
If something produces a log, someone will think of a justification to send that log to the SIEM.
Careful planning and scoping should be performed before a SIEM is purchased. Many times, we see organizations purchase a SIEM for the purpose of using it for X,Y, and Z. But then, when it gets installed, they want to send A-Z to it. The problem that this causes is that, just like all other technologies, the more you send it, the more resources will be used. Furthermore, if the technology is overloaded, it can cause failures.
Failures on a security monitoring and correlation system is a really big deal, especially when so many groups depend on it for critical information. Just as other IT systems are monitored for resource utilization, it is important to monitor a SIEM’s health and resource utilization.
Scoping
Before a SIEM is purchased, it is essential to determine which systems / applications you want to send to it and figure out the estimated events per second (there are online calculators that can assist with this). This information will help you understand what size of SIEM is needed. Each vendor will have their own calculations and will assist in determining what is necessary for your needs. Need help figuring out requirements your SIEM has?
Before engaging with vendors, it is also very important to internally discuss how the SIEM should be used, meaning what is going to be sent to it for what purpose. Instead of just sending everything to it just because you think it needs to be logged, it is essential to figure out why it needs to be logged and what you are going to do with the information coming out of it. This upfront work will help later on when implementing the SIEM.
Parsing
Unlike “install it and leave it” technologies, SIEMs require constant care and feeding to ensure they are operating optimally. One area that is regularly overlooked is not ensuring source logs are parsing correctly.
SIEMs rely on information from other devices to correlate and alert. We typically see organizations with a false sense of security because they are under the impression that if the data is going into the SIEM, it will alert them when something triggers.
The problem is that if that source information is not parsing appropriately into the SIEM, rules will not be matched and alerts will not be triggered. An example of this is when firewall rules are sent to the SIEM, the SIEM is expecting, based on the type of device and log, that the IP address should be in X field location within the log. If that field location shifts based on an update or other reason, then the SIEM will not be able to alert off of it even though it is being sent to the SIEM.
Testing parsers, rules, and alarms should be done on a regularly scheduled basis to ensure an upstream log source did not change during an update.
At the end of the day, it is important to remember that SIEMs are not a set and forget technology. They require constant rule tuning, monitoring, and updating. Beyond that, these systems require careful management to verify that resources are both properly allocated and not over-taxed. Without proper knowledge and management efforts, SIEMs can end up frustrating everyone in the security chain and going underutilized if not unused altogether.
Find out more about how to make your SIEM work for your organization in a meaningful way. Contact us today.