SIEM Product Selection Criteria in 2018
When it’s time to evaluate the best Security Information and Event Management (SIEM) product for your business, the decision on which platform best suits your needs should look beyond core functionality, such as security event log collection and correlation, rather you should evaluate its additional capabilities and integrations since the broader the functionality the more chance you’ll have of catching attackers on your network.
Looking beyond basic SIEM Functionality
Modern security operations centres (SOC) have refocused their attention from a purely network centric view to proactive cyber threat management. Technology platforms are supporting this by integrating a variety of capabilities together and relying on threat intelligence and ingestion of security events from networks, endpoints and applications to catch attackers much earlier in the kill chain.
The SIEM is the most commonly deployed technology platform in a SOC since it offers the most fundamental capability a SOC needs – continuous protective monitoring of log sources across the enterprise. The reality is that event monitoring has been at the heart of SOC services for decades, but today’s attackers are much more sophisticated and sneaky than they have ever been before, which has led to a notable reduction in detection rates where event logging and correlation are the only services provided.
Organisations continue to purchase and deploy traditional SIEMs, with a tacit understanding that they cannot do without its core functionality. Yet the additional insight the SOC requires to protect the business can only be derived from systems that incorporate threat intelligence and advanced attack profiling, automated incident response, and weave in behavioural analysis to detect unusual activity that could be missed under normal SOC monitoring circumstances. This evolved SIEM is commonly known as Security Analytics (SA), SIM 2.0 or next-generation SIM.
Proactive Threat Hunting
Atop the core capabilities of basic event monitoring and correlation, technology selection should be based on understanding the business problems you are trying to solve. For example, if you are a critical infrastructure operator, you’ll likely have an Operational Technology (OT) network, so your SOC capability should be extended to monitor that side of the business as well as traditional IT networks. You’ll have a different threat model and different attacks to respond to, since OT networks are harder to monitor (due to limited bandwidth and legacy equipment). Furthermore, the risk to OT networks is different, since most attacks affecting OT systems relate to integrity and availability rather than confidentiality.
No matter what the context, the SIEM needs to integrate with all your business technologies and collect logs from as many different log sources as possible, such as standalone SCADA systems, specialist management applications and even text files if that’s where proprietary applications store operational logs.
In many cases, attackers will use a combination of tools and techniques that allow them to remain undetected by traditional SIEM technology. Therefore user behavioural anomaly detection has become another important tool in the SOC’s toolkit. If you can profile what normal looks like on your network, or what normal user interaction with an application looks like, you can set thresholds that, if breached, raise an alert within the SOC. It might be that the system is still performing normally, but is under abnormal loading, which might be for a legitimate reason, but it also worth investigating.
The last feature we’ll consider in SIEM selection is scalability. It goes without saying that your chosen solution needs to meet your current business requirements, but it should also be able to scale to meet future growth or change. If your company has a cloud-first strategy, where new systems must be deployed in the public cloud, you will still need to be able to collect, process and correlate security event logs and monitor user behaviour.
Some SIEM providers have a flexible model that works both on premise and in the cloud, so that’s a good place to start. However, you need to look at how integrated the cloud capability is, since running in the cloud doesn’t guarantee it can see the logs below the infrastructure layer it’s deployed in. Take, for example, a SIEM system deployed into Amazon’s AWS. Amazon will provide robust security around the outside of the container they provide to you, but the security of the systems inside the containers remains each customer’s own responsibility.
If you have cloud systems today or cloud ambitions in the future, then you need to consider the following:
- Do you require multi tenancy?
- Do you need full visibility of security logs created in the cloud?
- Do you need to collect logs from IaaS, PaaS and SaaS services (each layer of the cloud model)?
- Do you need to rapidly scale up within the cloud environment?
- Do you want a pricing model that scales up and down on demand?
Each of those questions should be answered prior to selecting your vendor, since the SOC model you require can change dramatically when you factor in cloud services. It may well be more beneficial to run your SOC as a virtual SOC in the cloud, alongside the rest of your infrastructure, rather than maintaining on-premise security technology that must collect logs remotely.
SIEM in the modern world
In a landscape where security teams have to manage more information and more complexity, while at the same time remain efficient, it is clear that you and your team need more context, greater insights and automation.
When you’re next reviewing your SIEM requirements, make sure you look up to the horizon at Security Analytics… the next-generation SIM.