IT has always given importance to security and compliance. As infrastructure becomes more and more complex, IT needs to evolve toward more mature ways of monitoring applications and infrastructure. This means letting go of strategies, models, and products such as SIEM that used to work a decade ago, but are unable to serve the needs of today’s cloud-based microservice applications.
Security information and event management (SIEM) is one such model that needs to be reconsidered. In the age of the cloud, traditional SIEM strategies no longer work. Here’s what you need to do differently.
Key features of SIEM
SIEM is the combination of two older IT monitoring processes—SIM (security information management) and SEM (security event management). SIM gathers system data that can be used for compliance and reporting purposes, and SEM centralizes log data for near real-time analysis. SIEM combines both these methods in an attempt to be the single source of truth for all information related to security and compliance. It includes all events and logs that are churned out from every layer of the stack. SIEM gathers data through collectorsdeployed at various parts of the system. This includes end user devices, hardware and virtual servers, and network switches and ports.
IT teams have relied on SIEM tools to make sense of the events generated by their security tools. These tools are great at collecting events and consolidating them into a single view to help manage and monitor the entire system from a single point. They allow teams to manage incidents and respond to them faster as compared to manually sifting through the events and logs.
SIEM worked great for fixed capacity monolithic applications where each layer of the stack was clearly segregated, and there were fewer moving parts. A lot of good things came from SIEM, like the collection of data from every point of the system to create a consolidated view of security. It made the job of IT security simpler and more manageable in some ways. The ability to correlate event and log data to help analyze security incidents was new, and provided better context when troubleshooting issues. On the other hand, the amount of incident data generated could lead to false positive and alert fatigue if not managed properly.
Despite its strengths, SIEM has some inherent weaknesses that make it incompatible with the new breed of cloud-native applications.
Why SIEM won’t work for the cloud
With the cloud, a couple of things have changed, and this calls for a change in security analysis as well.
1. Microservices
The biggest change is that applications have shifted from being monoliths to being a collection of microservices. In this model, each request passes through multiple services, and each service communicates with multiple other services frequently. Each service needs to be secured with its own version of a firewall, creating policy-based security. Multiple containers power each microservice, and every container needs to be hardened at the kernel level, registries with third-party container images, and the orchestration layer.
In addition, collecting logs and events from containers is difficult because containers by default do not store log data persistently, and depending on how your container environment and logging tools are configured, they may not be able to aggregate container logs and events. For example, a syslog service can’t collect logs from Docker containers unless you configure your Docker environment to use syslog logging, and have a syslog logging tool that is designed to work in a containerized environment. (Sumo Logic is able to do this, as well as collect container logs in several other ways, depending on your preferences or needs.)
2. Rules-based
SIEM depends on a collection of parsing rules to glean insight out of the log and event data generated by the system it monitors. The problem with this is that in a dynamic cloud environment these rules become outdated as soon as they’re created. You can’t monitor zero-day attacks with a fixed, rules-based systems. With new services and resources being started up and retired all the time, SIEM is outpaced by the stack it monitors.
3. SIEM requires upfront planning
SIEM requires a great deal of planning and provisioning. They must start by creating a profile of the system under normal conditions. Assuming the definition of “normal” will stay the same over time is one of the weaknesses of SIEM. In cloud-native applications, there are many moving pieces and lots more complexity. The lifespan of a container is typically a few hours long, and organizations spin up new containers in the thousands per day. SIEM’s upfront planning cannot take into account such frantic rates of change.
The need for a high level of provisioning makes it difficult to build lean, agile SIEM-based defenses that are also reliable. Unless you are very careful (and lucky), you end up either over-provisioning (which leads to wasted resources and money) or under-provisioning (which leaves you at risk of not being able to accommodate your load).
4. SIEM stalls action
SIEM’s rigid architecture results in many gaps in information. With only a partial version of what’s really happening, security teams are unable to take action as quickly and decisively as they need to. The cloud needs more than just monitoring information—It needs the ability to go from analysis to action. Doing this requires the ability to distinguish noise from alerts easily. Otherwise, your team will suffer from alert fatigue and stop paying attention to critical notifications because it receives too many alerts that appear serious, even though not all are.
What the cloud needs
The cloud needs a new breed of information management tools.
1. Scalable elastic architecture
Cloud security tools need to be able to scale out effortlessly. Elasticity is one of the key differentiating factors between traditional and cloud-based apps, and monitoring tools should reflect this reality. Scalability doesn’t just mean adding more nodes to copy. With the additional data storage needs, it also means being able to enjoy the same level of monitoring, whether you’re running ten containers, or tens of thousands of them.
2. Diverse sources: ingest without parsing
With the advent of containerization, the application stack is becoming more complex. There are many APIs, plugins, third-party services, and underlying platforms that all require plumbing. Each of these sources needs monitoring and needs to be secured. You can’t write parsers for all of them. What you need is flexible, no-parse storage on ingested data.
3. Quicker time to action
Most organizations invest lots of money in protection and very little in incident response and detection. Organizations require a plan when a breach happens, and tool flexibility to address it. Cloud security tools need to prioritize incident response and hunting capabilities. Beyond collecting data, security teams in the cloud need to leverage machine learning to glean predictive insight from the data, automate incident response wherever possible, and be able to act in real time.
Security in the cloud is essentially the same as security for a traditional on-premises environment. What you do does not fundamentally change—Your goal is still to secure your environment. However, it’s how you implement those security control changes that is different. SIEM tools fall short in this respect. They were built for on-premises applications, and are unable to cater to the needs of cloud-based and containerized apps that are a collection of microservices. Today’s apps need a cloud-native monitoring tool that doesn’t just ingest data, but also gets teams to take action on it faster than ever.
