Is your security information and event management stuck in the past? Is it mature? Some organizations procure and deploy a SIEM tool only to wonder whether it is collecting dust, instead of improving their security posture, with all that unmonitored log data.
SIEM is used by organizations for collecting, normalizing and correlating security events based on log data from an array of systems and devices. Today, many SIEM tools also support threat intelligence feeds and other data from external sources. The best path for a SIEM deployment is from one successful security incident response to another, with constant refinement of the technology's configuration and processes. There is nothing more motivating than value realized with a sequence of "quick wins" and security problems solved.
A number of SIEM deployments are stuck in nonproductive stages, however. Ask yourself: Is your SIEM evolving? Is it solving just one problem or addressing multiple security monitoring and analysis issues?
If your SIEM architecture is still solving the original security problem -- monitoring user access to servers or reducing IDS/IPS "false positives" -- there is absolutely nothing wrong with your implementation. As long as you are not paying hundreds of thousands of dollars every year for legacy network intrusion detection systems' (NIDS) "false positive" reduction, then a static SIEM deployment or one that is in maintenance mode is not inherently worse than a dynamic deployment.
SIEM evolution offers advantages for many enterprises that should not be overlooked given the cost of these tools. It helps retain security personnel, unlock budgets, refine processes, improve collaboration and integration–and ultimately creates a self-fulfilling prophesy of a successful security monitoring program.
What are some of the common mistakes that organizations make with SIEM? And, how can you go from deployment to steady-state operation to successful SIEM expansion?
Mired in Data Collection
One reason your SIEM deployment may be failing to evolve is that it is stuck in the collection phase. This deployment scenario often happens when IT security teams plan a SIEM project in a horizontal manner–all collection first, all analysis later—rather than on a use-case by use-case basis. The end result is a good log collection system at ten times the price.
The way to resolve this issue is to use "output-driven SIEM." An output-driven approach simply means deploying a SIEM tool in such a way that no data comes into the system until there is a clear knowledge of how that information will be used and presented. Here, only existing/planned reports, visuals, alerts, dashboards, profiling algorithms, context fusion and so on can make a SIEM team "open the floodgates" and admit a particular log or context type into the tool.
With this model of SIEM, the "what if we need it someday?" argument does not work. Log entries can be collected by a log management tool (commercial or open source) with a much lower per-log cost. The use-case-driven collection facilitates just the right amount of analysis because the SIEM tool stays at its optimum performance level without incurring excessive hardware costs.
Focused on Compliance Checklists
Another reason a SIEM deployment may remain stuck is compliance. This happens when organizations buy a SIEM tool "to check the box" and never start using it for anything beyond scaring away the auditors. The result is one really expensive checkbox.
Today's SIEM products come with reports, dashboards and correlation rules that are created to address regulatory compliance such as PCI DSS, Health Insurance Portability and Accountability Act (HIPAA) and Sarbanes-Oxley Act (SOX) as well as common scenarios for security. Some vendors claim that such off-the-shelf SIEM content is useful out of the box with no customization. But customer experience has shown that most off-the-shelf SIEM content is useful only when it is applied to specific systems (and thus customized by adding filters) or when it is tweaked to better match the environment.
The way to evolve out of this logjam is to explore the use cases at the edges of your compliance usage, from monitoring users that touch card data to observing all users that interact with sensitive data. Threat management and breach detection have also emerged as the primary drivers of SIEM in the past few years, but compliance is still holding strong. Today, most customers at least ask about using their SIEM tools for detecting breaches -- even if compliance is top of mind. The functionality required to satisfy the two use cases overlaps, and many customers look for SIEM product capabilities that satisfy both. Finally, even compliance requires that your SIEM be used and not just connected to the network.
One Problem Solved, 'N' to Go
Sometimes an organization builds a SIEM deployment, solves the initial problem and then something breaks. Maybe staff turns over, the security team gets downsized or the consulting budget runs out. And then the deployment focus shifts to maintaining the status quo.
Many SIEM deployments have failed to adapt to business changes as well as developments in surrounding IT environments. A SIEM project that is deployed to solve a particular problem with no specific plans to expand sometimes gets left behind when business changes make the problem irrelevant. To resolve this issue, security architects should plan to deploy SIEM tactically, achieving "quick wins" as part of a phased approach. A phased approach by use case, further divided by log source types, geography and functions (such as report before alert or review before correlation) can be used to slice this large effort into manageable chunks. The opposite of using any phased approaches -- "collect all at once" or "implement all use cases at once" -- almost never results in success and often leads to a large-scale waste of resources.
Caught Up in Incident Investigations
Finally, some organizations fail to get the most out of their SIEM deployments because the tool is tied up in incident investigations. This model of SIEM is nowhere near as harmful as the previous ones. It happens when a SIEM is primarily used to investigate, rather than detect, incidents because the organization never matures to security monitoring stage.
A common result of such deployments is that the SIEM product gets replaced with a commercial or an open source log search tool, such as an emerging ELK stack (a combination of Elastic Search, Logstash and Kibana). To resolve this issue, take a long hard look at your SIEM. Do you only plan to use it for incident investigations and not for security monitoring? Or, similarly, do you plan to evolve to monitoring but have not done so in the past 5 years? If the answer is yes in either of these scenarios, consider scrapping your SIEM and replacing it with a log analysis tool. The money that you save on SIEM can buy a lot of fast and effective log management.
Overall, the best strategy for a SIEM deployment is constant refinement and expansion. SIEM works like a bicycle -- you are happy with the technology only if you pedal and move forward.
SIEM Reality Check
What is the best way to get there? A SIEM program requires an annual or biannual check of its "health" and operations. This evaluation process allows an organization to track its achievements with SIEM and plan deployment expansion. The key question is, what security issues can we solve next?
Just as you'd check that the proper network systems and device logs of security events are flowing into the SIEM, you should also consider this: Is the value of the SIEM deployment being delivered? If no real value to the deployment is seen, what can you change, add, subtract, refine, or improve? (Hint: It is rarely the product itself.) Could changes related to data sources, speed of hardware, logging configurations, network bandwidth or load balancing improve your SIEM deployment? If no obvious next step comes to mind, ask around the organization. This process will definitely help you run your SIEM well.
On a more tactical level, organizations need to benchmark how their SIEM is performing; the challenge is that measuring SIEM health and operations is still an emerging area, and there is no set of accepted metrics.
The core SIEM team has to define success criteria at the planning stage and periodically check for progress in regard to these criteria. Measurements of SIEM impact on incident recovery time (similar to the operational mean time to repair) and on incident severity offers evidence of more strategic SIEM success. A reduced incident discovery window, if observed, can provide a great boost to a SIEM program.
Even with all of this done right, you still need a bit of luck. This is not a sentiment about SIEM; it's the same with the any large IT security project -- successful deployments depend on strategy, expansion and things falling into place.
Anton Chuvakin, Ph.D., is a research vice president at Gartner for the Technical Professionals' Security and Risk Management group. As a recognized expert in log management and PCI compliance, Dr. Chuvakin has published dozens of papers on log management, SIEM, correlation, security data analysis, PCI DSS and security management. He is an author of Security Warriorand PCI Compliance. For more, check out his Gartner blog, personal blogor follow him on Twitter @anton_chuvakin.