Arguably, one of the faster rising segments within Cybersecurity has been the adoption of Security Information Event Management (SIEM) platforms. Although there has been a myriad of vendors in this space for over a decade, it is only in the last 4-5 years that drivers such compliance and a need for a consolidated view of security threats, that propelled SIEM projects to top of IT and cybersecurity project priorities. It’s easy to see why. A SIEM program, properly deployed and executed, can provide comprehensive visibility to events affecting enterprise networks, thereby increasing an organization’s security posture, while adhering to ever-increasing compliance demands.
However, having participated in numerous SIEM deployments, of all shapes and sizes, we would like to discuss the most common pitfalls of SIEM projects and the main reasons behind organizations not maximizing ROI (Return-on-Investment) and TTV (Time-to-Value) behind such important initiatives.
1) Not Understanding Currency
Before embarking on a SIEM project (even if simply re-visiting an existing deployment), organizations needs to self-examine and understand its’ current security posture. After all, how would an executive be able to justify and rationalize the financial spend after 6 months (longer? Shorter?) if they don’t know their starting point? How will they know they made a sound investment? Chose the right service provider?
This entails performing comprehensive gap analysis and introspection about an organization’s existing controls, people, and processes. Once complete, a roadmap can be created which articulates what the future state looks like, while taking into context security demands, business demands, and compliance requirements. After all, there’s no sense in a state of the art home security system if your windows are broken and your door is unlocked.
Action: Work with your service provider or trusted advisor to provide you with a comprehensive security assessment and/or gap assessment to identify how far your organization deviates from the ‘norm’ of best practices. Such assessment will take into account the tools your organization has as well as the maturity level of its people and processes. This exercise needs to be re-visited some time after completion of SIEM deployment to ensure that a positive outcome has indeed been achieved.
2) Choosing a Logging Solution Rather Than SIEM Platform
A very basic pitfall of projects lays in the intent behind the project itself. Network tools, security tools, applications, operating systems, all create logs. It is a fallacy to believe that simply congregating all logs into one central ‘platform’ makes a SIEM. The opposite is actually true. The collection and subsequent storage of logs is simply the first step in any SIEM project. Real value comes in the ability to correlate and draw analysis from various logs in order to make observations that can be ‘actioned’ by IT teams.
Without appropriate correlation and analysis, organizations end up with large amounts of logs that either do not make sense on their own, paint only part of the picture, or seem innocent, but if appropriately analysed, will be much more telling than they seemingly are.
A proper SIEM platform (note the use of the word platform, and not just a product) will provide the appropriate correlational data, analysis, and draw possible conclusions from logs that would otherwise be of lesser value, if evaluated independently.
Action: Organizations should be asking vendors about their ability to provide both out-of-the-box analytical and correlational capability as well as the ability to create use-cases that pertain to their specific requirements, industry, network, and compliance drivers.
3) Having Incomplete Visibility
SIEMs function best when given a lot of information to digest. In fact, it would stand to reason that the more data (i.e more logs) are sent to a SIEM for analysis, the better the results are going to be (yes, I recognize the need for tuning and noise reduction….more on that later).
Many organizations start by sending logs from firewalls and possibly IDS/IPS to a SIEM. Great place to start. But unfortunately, it’s also where they end. Such logs will (hopefully) yield some alerts and point to items to investigate, however they only tell a partial story (if at all).
To truly maximize on SIEM deployments, organizations ought to analyze all aspects of their security tools and examine any security related log source, especially at endpoint level. Only then, can a better picture of the security posture of the network begin to form (albeit still an incomplete one).
Action: Organizations need to outline all security controls, tools, products, and applications, and undergo a systematic, yet comprehensive, strategic to forward all such logs to their SIEM. After all security log sources relay their logs into the SIEM, organizations can turn to networking tools (routers, switches, …) to forward logs as well.
4) Set It & Forget It
IT and Security professionals today are forced to contend with competing projects, priorities, and distractions. One of the more egregious abuses (yes, I said it) of a SIEM project, is the notion that after implementation, no matter how comprehensive and ‘successful’, the deployment of a SIEM translates into a more secure environment. In fact, the opposite may be true. Without constant, vigilant monitoring, companies fall into a false sense of security and assume that simply having a SIEM means a more secure environment.
Once deployed, a SIEM platforms need to be constantly monitored and triggered events need to be investigated for potential breaches. Unfortunately, organizations rely on staff that is already stretched thin with workload and various demands to only ‘partially’ monitor the SIEM and only do so on a best effort basis. Action: Organizations need to plan for post implementation monitoring and be vigilant on doing so on a 24/7 basis. This may mean contracting with a managed service provider to provide either a full managed service, or at the very least a co-managed service, where trained eyes are monitoring alerts and performing initial investigations and triage. Bad guys (both external and internal) don’t keep 9-5 hours and neither should you. Shameless plug, IntelliGO Networks offers 24/7 managed services that’s designed to fit your organizations’ processes, budgets, and requirements. We’ve been doing it for more than a decade.
5) No Fine-Tuning
A natural extension to the ‘set-it-and-forget-it’ mistake is not re-visiting the SIEM, the established rules, triggers, log sources, and processes in order to fine tune them. Organizations’ needs change over time. Networks are dynamic, the threat landscape is ever evolving, and new compliance requirements spring up constantly. It is necessary to re-visit (and often) the rule sets, alerting hierarchy, and other controls in order to ensure that the program is running in an efficient, effective matter. After all, SIEM deployments are part of security programs. That means that the ‘people’ and ‘process’ aspect of the program are as important (arguably more) than the ‘tool’ aspect of the program. Action: Create a feedback system where all aspects of the SIEM program are examined. This may involve performing a quarterly or semi-annual health check to ensure maximal optimization. In fact, this is one of the best ways to continually extract more value from your SIEM investment. Moreover, if your organization enlists a managed service provider, fine-tuning and re-visiting rules and policies needs to be mandated in the service contracts.
Action: Create a feedback system where all aspects of the SIEM program are examined. This may involve performing a quarterly or semi-annual health check to ensure maximal optimization. In fact, this is one of the best ways to continually extract more value from your SIEM investment. Moreover, if your organization enlists a managed service provider, fine-tuning and re-visiting rules and policies needs to be mandated in the service contracts.
6) Process Ownership
All too often organizations deploy a SIEM platform and maintain vigilant monitoring of the SIEM (either internally or through a managed SIEM provider), however they fail to establish and enforce the process through which investigations and remediation will follow. This results in the SIEM doing its job perfectly well, and triggering the appropriate alerts on potential breaches but the sounding alarm is either ignored or stalled because of broken processes. This is even more evident with larger enterprises where there are multiple teams that could be called in (end-user services, networking, security, management….) but are not. In fact, it has been documented that in some of the more notable security breaches, the SIEM actually performed its job and the alerts were triggered, but there was no one listening or broken processes impeded investigation. Action: During the SIEM implementation and onboarding period, ensure that there is a documented (and rehearsed) plan of action to follow for investigating various types of alerts, and follow through to remediation. This is a critical area where your trusted advisor (ahem,
7) No Contextual Awareness
The relationship between users, devices, and applications is dynamic and complex. Having information about just one of these leads to ambiguity and lost time/money in chasing investigations for either innocent alerts or false-positive ones. Having complete visibility into ALL aspects of your network means that your decision making ability will be based on more complete information and thus will be more timely and accurate. Having the appropriate level of context is a function of proper implementation and onboarding where an organization can draw on its (or its service provider) encyclopedic volumes of rules and policies to ascertain which rules need to be enforced and when, and from which log sources and under what circumstances.
Action: Plan your implementation and deployment to provide as much context to the SIEM about log sources and the information relayed to the SIEM. This means user information (from active directly and other identity stores); types of traffic (internal? External? VPN?); manners of authentication (wired? Wireless?), application information, and other controls.
While many organizations are deploying SIEM platforms for the first time, numerous others are re-visiting their deployments as technologies mature, evolve, and refresh cycles approach. The above discussion is by no-means a complete list of pitfalls nor is it a checklist to follow. In fact, each of the subjects above can be expanded into a much broader discussion. They are called out here because many organizations either don’t think through all the components of a SIEM program or they undergo one for the wrong reasons. I fully recognize that this is a partial list and a discussion is welcome in the comments section.