Security Information and Event Management (SIEM) systems create a lot of controversy with security folks; they are one of the cornerstones on which the security program are built upon within every enterprise. Yet, simultaneously SIEM generates the most complaints and general angst. Two years ago Mike and I completed a research project on “SIEM 2.0: Time to Replace your SIEM?” based upon a series of conversations with organizations who wanted more from their investment. Specifically they wanted more scalability, easier deployment, and the ability to ‘monitor up the stack’ in context of business applications and better integration with enterprise systems (like identity).

Over the past two years the pace of customer demands and platform evolution to meet those demands has accelerated. What we thought was the tail end of a trend with second-generation SIEMs improving scalability using purpose-built data stores turned out to be the tip of the iceberg. As enterprises wanted to analyze more types of data, from more sources, with more – re: better – analysis capabilities to derive better information to keep pace with advanced attackers. Despite solid platform upgrades from a number of SIEM vendors, these requirements have blossomed faster than their vendor could respond. And sadly, some security vendors marketed “advanced capabilities” when it was really the same old pig in a new suit, causing further chagrin and disappointment amongst their customers.

Whatever the reason, here we are two years later, listening to the same tale from customers looking to replace their SIEM (again) given these new requirements. You may feel like Bill Murray in Groundhog Day, reliving the past over and over again, but this time is different. The requirements have changed! Actually they have. The original architects of the early SIEM platforms could not have envisioned the kind of analysis required to detect attacks designed to evade SIEM tools. The attackers are thinking differently, and that means the defenders that want to keep pace need to rip up their old playbook and very likely critically evaluate their old tools as well.

Malware is now the major driver, but since you can’t really detect advanced attacks anymore based on a file signature, you have to mine data for security information in a whole new way. Cloud computing and mobile devices are disrupting the technology infrastructure. And the collection and analysis of these and many other data streams (like network packet capture) are bursting the seams of SIEM. It doesn’t just stop at security alerting either. Other organizations, from IT operations to risk to business analytics, also want to mine the security information collected looking for new ways to streamline operations, maintain availability, and optimize the environment. Moving forward, you’ll need to heavily leverage your investments in security monitoring and analysis technologies. If that resource can’t be leveraged, enterprises will move on and find something more in line with their requirements.

Given the rapid evolution we’ve seen in SIEM/Log Management over the past 4-5 years, product obsolescence is a genuine issue. The negative impact of a product that has not kept pace with technical evolution and customer requirements cannot be trivialized. This pain becomes more acute in the event of a missed security incident because the SIEM did not collect the requisite information, or worse, could not detect the threat. Customers spend significant resources (both time and money) on the care and feeding of their SIEM. If they don’t feel the value is in alignment with the investment, again they’ll move on and search for better, easier, and faster products. It’s realistic, if not expected, that these customers start questioning whether the incumbent offering makes sense for their organization moving forward.

Additionally, firms are increasingly considering managed services and 3rd party security operations providers to address skills and resource shortages within internal groups. Firms simply don’t have the internal expertise to look for advanced threats. This skills gap also promises to reshape the landscape of security management, so we’ll kick off the series discussing these factors, setting the stage to update our guide to selecting a SIEM.

Specifically, we will cover the following topics:

1. The Changing Needs of Security Management: As firms branch into cloud environments and offer mobile applications to their employees and customers, the definition of ‘system’ now encompasses use cases outside what’s long been considered the corporate perimeter, changing the view of “infrastructure” that needs to be monitored. Simultaneously, advanced malware attacks now requires more types of data, threat intelligence and polices to adequately detect these attacks. Additionally, firms are increasingly considering managed services and 3rd party security operations to address skills and resource shortages within internal groups. All of these factors are once again reshaping the landscape of security management, so we’ll kick off the series discussing these factors to set the stage for re-evaluating the security management platform.
2. Evolution of SIEM Platform (and Technology): Next we’ll discuss the evolutionary changes in SIEM – from the standpoint of platform capabilities. It’s still all about more data and more data. We’ll cover architectural evolution, integration and ongoing care and feeding of the environment to meet the scaling requirements. We will also discuss how SIEM is increasingly leveraging other data sources, such as virtual servers, mobile events, big data analytics, threat feeds, as well as human and machine generated data. But all of this data does nothing if you don’t have the capabilities to do something with it, so we will discuss new analysis techniques and updates to older approaches that yield better results faster. To do more with more means, under the covers, scale and performance are being achieved via virtualizing lower cost commodity hardware, leveraging new data storage and data management architectures. SIEM remains the aggregation point for operations and security data, but the demands on the platform to ‘do more with more data’ is pushing the technical definition of SIEM forward and spawning necessary hybrid models to meet the requirements.
3. Revisiting Your Requirements: Given the evolution of both the technology and the attacks, it’s time to revisit your specific requirements and use cases, both current and evolving. We will look at how customers can utilize advanced analytics to make better decisions via new data sources and managing data in new ways. Then we will examine the need to get results faster to keep pace with the velocity of attacks. This step is critical because you need to take a fresh look at the environment to understand what you NEED for tomorrow, not being constrained by what you HAVE today.
4. Evaluating Your Platform: Now you need to evaluate your current environment for effectiveness and capabilities, given your fresh view of the requirements and use cases. This is where reality sets in as you consider what you have today, and assess objectively what makes you unhappy about your current situation. You must be brutally candid about what works and what doesn’t, and what’s involved to get it to work, if that’s even possible. You’ll also need to consider what portion of your old investment will be lost, if you migrate to something else. Finally you need to carefully consider replacement and be very clear on success criteria to factor in the good and the bad, since you don’t want to trade one set of limitations and compromises for another.
5. Decision Process: We’ll lay out a decision process to remove the biases in the selection process. This is not the time to let the ego get in the way of doing what’s right, and organizations must look at the decision differently to ensure previous mistakes are not repeated, ending up with the organization in the same place three years from now to the degree that can be avoided.
6. Selection Criteria: Part of the decision process will be assembling the critical evaluation criteria for any new security management platform. SIEM and emerging security big data marketing data sheets all sound the same, making it tough to distinguish innovative technologies from pigs with a fresh shade of lipstick. We’ll define a set of questions and evaluation criteria to help tell the difference.
7. Negotiation: Dealing with an incumbent (who doesn’t want to lose business) adds a layer of complexity to the decision, so customers will also need to factor in the reality that incumbent vendors will try to save the business, and there are means to leverage that fact as the decision process comes to a conclusion. Customers also need to consider that maybe staying is the best option for their organization, so knowing how to consider both sides of the decision determines your ability to make the “right” choice.
8. Migration Planning: Now that you are moving to something else, how do you get there? It may involve supporting two systems for a short while. Or in a hybrid architecture using two systems indefinitely. Either way, when a customer puts his/her head on the block to select a new platform, the migration needs to go smoothly. Here we map out a migration plan for to move to the new security management platform, including data collection, migrating/revisiting policies, reports, and deployment architectures.

Next up, the changing needs of security management and new uses cases for SIEM.