Security Monitoring . SIEM . Failures!

From the early days of log data collection for auditing purposes, to present days of complex SIEM product, it has been a journey to reckon with. Evolution of analytic and big data and its implication on security monitoring, promises that future journey of log and associated data will continue being exciting and challenging.

But, all this evolution of technology to use log and some other related data to monitor enterprise security, has helped little, very little, in instilling the confidence in users / CISOs, that they have their monitoring and security posture covered. A close quarter conversation with any CISO or security experts will quickly reveal that their confidence in capabilities of security monitoring products and tools is low. Very low. Most of them will reflect following as major issues with adoption and operations of SIEM products.

• Initial adoption is time taking and needs quite a bit of coordination from various stakeholders within IT organization
• Time to value realization is very high. It can take up to an year or two before you can think of effective monitoring
• Correlation of events and corresponding comprehensive coverage of attack and compromise vectors is difficult to achieve
• SIEM installations need maintenance. Very high maintenance. And, sometime benefits of such a tool are offset by ops cost
• Out of the box reports from SIEM products and tools are mostly useless. It takes
  quite a bit of work to generate meaningful one

A closer look at the world of SIEM and other monitoring tools and technologies reveals following areas or reasons, which cause failures or dissatisfaction. Some of these are related to the way SIEM tools have shaped up. Some are related to mistakes made at the time of deployment of these products and some are related to operational realities/complexities of the IT infra and applications from where log data is collected and processed and stored.

In quite a many organization lack of a clear policy related to logging, result into log data bloating at various sources. It is not unusual to find debug level of logging being enabled at various applications, hosts and devices for no specific reasons. Debug levels are turned on, because, IT organization does not want to spend time on analyzing and deciding, what should be logged at various part of its IT infra and its elements.

Other than posing maintenance issues, in terms of local archival of log data and storage management, this kind of open ended logging at various points of IT setup leads to more complications and challenges, when an SIEM product or any monitoring tool based on log collection is deployed.

Collecting Too Much of Log Data…

From so many Log Sources!

Following are some of the issues when log collection is performed in such an environment.

• SIEM tool collection agents are expected to conduct all filtering of noise from the log source, which leads to more configuration and tuning
• Since selective log data is being collected from a large volume of generated logs, filtering process consumes additional computational resources
• In worst cases, or rather most cases, SIEM tool deployments do not burden themselves with fine tuning of collection, which leads to larger volumes being collected
• Larger log volumes collected from many sources in an IT setup creates operational challenges at the central aggregation and storage component of SIEM product
• And, large log/event volume collected and stored at the central aggregation and storage server also leads to slower searches, compromised reporting and in some cases low quality correlation of security events

What is needed, is, organizations need to come up with proper logging policies for all portions/aspects of their IT assets. The collection of logs within your IT setup needs to be with a purpose. It cannot be and should not be for mere accumulation of noisy data, which will end up lying in an archived store, which no one will ever look at and no one for sure use.

And, then further, a comprehensive filtering of what is being collected by your SIEM tools also needs to be done. Burdening your SIEM infra and components with unnecessary collection of large log volumes is a sure shot way of sending your security monitoring to a path of failure. The exercise to come up with right filtering in SIEM installation will take some time and effort. It should not be rushed, if you want to avoid complexities and pains, when SIEM is operational.

SIEM .. Its not supposed to be a Rule Engine…
Damn it… Parse & Map it completely…
Give me a proper solution!

Log data collection and monitoring of security based on what is found in logs is largely based on premise of conversion of data and events in various logs to a standard and common format, called CEF in SIEM parlance. This conversion is done by SIEM tools for each selective entry in the logs. Such a conversion of collected logs from so many log sources in an IT setup needs strong and comprehensive parsing and mapping abilities in their SIEM products and tools.

Given the sprawl of log sources and type of those sources, many SIEM vendors have resorted to providing a custom parsing development capability within their tools. A customer is expected to detect where parsing or mapping is not taking place properly in their collected logs, and then, write a custom parser for certain logs to ensure correct mapping of events is done. This is easier said than done. In the face of many versions, many types of logs, it becomes herculean task for for customers to ensure that all of their logs are getting mapped correctly within their SIEM setup. And, then it remains an operational nightmare. Any time an update or upgrade takes place, customers need to look at the correctness of their mapping and take actions if something is missing.

Here, I find major issues with SIEM product vendors and their technologies. Following are some of the things, which need to be taken care of by them.

• Your tech is supposed to do the parsing, don’t make your customer do it
• Don’t pass on the burden of dealing with version-hell to your customers, you are expected to get your tool ready to support correct parsing across different versions
• And, most of all, SIEM is not a rule engine, it is a solution. Parsing is at the center stage of this solution. Get a grip on your parsing technology and its eco-system!

In majority of the SIEM products, correlation of security events is a key capability. This capability is what makes this technology effective in providing deeper view of security important or security critical happenings within an IT setup.

Attack Vectors and Compromise Scenarios…
Ah…Those Complex Correlations!
Lack of Comprehensiveness!

Unfortunately, most of this correlation has been left to users aka customers defining their own rules for various correlation. The rule engine syndrome of SIEM tools has led to a situation, where out of box coverage of attack vectors and compromise scenarios is minimal in most of the products and tools available in market today.

A templatized approach to various security scenarios and corresponding correlations for a given type of IT setup, is what is needed and expected from SIEM products and technologies. Other than arcane and exotic IT setups, which may contain log sources and their combinations which are difficult to imagine, it should be fairly possible for SIEM vendors to provide comprehensive coverage of the correlation. Out of box… ready to be used… and effective right out of deployment!

Analysis of a ‘Found’ Security Occurrences…

Deeper Security Experts Needed!

Continues to be a challenge!

Even if an organization has a proper deployment of SIEM solution, and even if, it has managed to create meaningful correlation rules, on very many occasions an occurrence of a specific security event or scenarios still needs a high quality intervention and conclusion by a security expert.

In the face of a scenario identification and occurrence, ‘What to do’ and ‘What action to take’ continues to be a challenge for most of the organizations. For a proper coverage here, an organization is expected to employ security experts which goes beyond the routine knowledge of security products and general security understanding. Hiring such expertise is not an easy thing to do in today’s environment when security experts come at a steep premium.

Two things can help here…

• SIEM products and technologies vendors to include intelligence and knowledge about ‘actions’ which need to be taken on occurrence of these scenarios
• Organizations adopting SIEM solutions can take professional help or else employ SOC services from a third party security services player, who have a congregation of security experts readily available

The extent and rate of failed SIEM deployments is so high that it almost places a question to the whole world of security monitoring across the globe in enterprises. Some of the above mentioned issues need to be tackled quick enough for confidence to be restores in security monitoring, and, specifically in SIEM products and technologies.