If you are shopping for a SIEM, but don’t know which vendor or solution is the best fit for your organization, these criteria will help you in your search for the SIEM that works best.
- Are you aware of every security related event happening in your server and network environment?
- Do you have the time to manually review millions of logs for possible breaches?
- Can you show evidence of appropriate logging to an auditor for compliance?
Does your organization need a SIEM? Let’s review the basics of what a SIEM is and what is does to help set the stage for deciding which platform is right for you.
What is a SIEM?
It’s an impossible task to manually comb through event logs looking for security anomalies and keep easily accessible long-term records of events for incident response and compliance reasons. Instead, you’ll want to have a central repository for all security logging that is able to alert you when a security related event occurs. This platform is referred to as a Security Information and Event Management (SIEM) platform and it is a critical security tool. Regardless of the security team size, familiarity, or budget, there’s a SIEM that fits appropriately with your environment to provide peace of mind. When you start off with choosing a SIEM platform, it can be a daunting task as there are many flashy buzzwords thrown around. This basic set of parameters can help you pick an appropriate SIEM that can grow with your ever-changing security needs.
Capacity and multiple team usage
Planning for capacity requires you to look from multiple angles during the initial scoping to ensure the SIEM will handle business needs. Even though the primary use is for security, often times a SIEM is used by multiple departments. Teams other than security may request search/report access, a place to send events for dev/test, dashboards for executives etc. During the scoping process, evaluate how multiple teams will affect resource requirements of the SIEM. Things that should be taken into account such as hot and cold storage, capacity of event flow, resource use related to rulesets, and acceptable timeframes for event retrieval will help guide the scoping process. Ask the SIEM vendor how the events are stored and how that storage can be increased if capacity needs change in the future. Perhaps you have a security requirement that all events are encrypted at rest or that events must stay within the on-premise environment and cannot be sent to cloud storage. Also evaluate anticipated company growth and future sources of security events. All of these parameters play into the capacity planning of a SIEM platform.
Ease and flexibility for event intake
Feeding events into the SIEM from a variety of sources in an efficient manner is crucial. Traditional SIEMs will accept events from syslog sources in a standard RFC format. While this is the most widely-used ingestion method, it has its limits for processing speed, parsing flexibility, and event length. Ideally, you’d also incorporate alternate log gathering methods such as agentless log gathering and API. Event intake is only one part of the process though—the events still need to be organized into a readable format. Many SIEMs will come with out-of-the-box parsers for common event sources and provide a method of creating a custom parser. This can be a tricky process of trial and error. Some SIEMs allow the flexibility to create your own parsers for non-standard log formats, while others rely on the SIEM support team to build these parsers. There are pros and cons, including the cost of time spent building it on your own vs. a potential professional services charge from the SIEM provider. If you have the ability to build on your own, it is aided greatly when the SIEM fits a standard parsing language and/or includes a parsing builder. This provides the ability to visualize the output of an event and spot any potential parsing issues before an event source even flows into the SIEM. When onboarding event sources, a balance between ease, flexibility, and capability should be evaluated.
Customization of rule creation
Fundamentals of the rule building mechanism should be evaluated. Check to see if it allows for advanced boolean expression, such as contains, starts/ends with, the ability to add/remove from a list, working with internal SIEM events and more. Look for a SIEM that provides the ability to create more than simple 1:1 alerts and allows you to string together events in a correlation. Simple 1:1 alerting will only allow you to create an alarm if a single event type meets a threshold. For example, a group add to domain admins, while it is a crucial alarm, doesn’t take into account any other events occurring around the time of the addition.
Correlated alarms take a different approach by advancing to new stages as additional associated events are gathered. Using the same example as before, it would start with something suspicious such as disabled user was enabled by creating an internal medium alarm. This internal alarm may not need to create an alert to the security team because it could be normal sysadmin activity. However, alarms could be built off of that internal and then correlation logic would be applied if perhaps the enabled user is then added to domain admins, then logon events occur for the user, and so on. All of these events strung together would create a high security alert based on the actions taken. This could be expanded further by looking for anomalous network activity, exfiltration, back door creation attempts etc. The latest SIEM platforms will create a baseline of user activity and increase a risk score as deviation occurs from activity that has been observed in the past. Furthermore, additional parameters such as group permissions, department roles, and CAB approval platform data can influence this risk score. This tracking system is often referred to as behavioral analytics. It not only applies to users, but can also work off of network flow analysis, permissions changes, vulnerability data, and known threats.
Support from your provider
Expect a learning curve when onboarding a new SIEM platform. This learning curve not only covers working within the SIEM, but also what is required to keep the SIEM in healthy shape. During onboarding, there are a few options for accelerating this process, either a bootcamp style training or professional services can assist. Once the SIEM is in an operational state, regular maintenance is needed. Some SIEMs might have their infrastructure in a hosted environment, which allows for a hands-off approach when it comes to maintenance. If this is the case, be sure to stay informed of the affected components and any anticipated downtime. Other SIEMs, such as an on-prem platform, may require a dedicated database engineer. Most support needs come in the form of breakfix assistance, which is why it is crucial to get a feel for how trouble tickets are triaged by the support staff. Additionally, SIEMs are vulnerable to compromise just like any other platform, so it’s good to check on how often software updates are made available.
Once you have all of these answers gathered, along with your critical requirements, it’s a good time to reach out to multiple SIEM vendors for a Proof of Concept (POC). This gathering process will give you an advantage for a successful engagement in choosing the appropriate SIEM platform.