Feature

SIEM analytics: Process matters more than products

Ezine

This article can also be found in the Premium Editorial Download "Information Security magazine: Security Readers' Choice Awards 2013."

Download it now to read this article plus other related content.

Security information and event management (SIEM) projects—still in the early stages for some organizations—have a long and somewhat tortuous history. After two decades, many of the remaining challenges concern SIEM-related processes and practices rather than the tools themselves. Organizations can procure next-generation SIEM products from numerous vendors, but buying the security monitoring capability is impossible.

Research indicates 75% of chief information security officers who experience publicly disclosed security breaches and lack documented, tested response plans will be fired.

Gartner Research

 

SIEM tools collect, correlate and analyze a wide variety of security-related data. This information can include logs, alerts and flows as well as vulnerability, asset and user contexts.

Security monitoring refers to the set of operational processes that are built around the tool. SIEM processes, which can apply to multiple security monitoring and data analysis technologies, depend on the usage of the product. Is it for security or compliance-driven monitoring? If there's no process whatsoever, the IT budget that's spent on SIEM technology is likely wasted.

Use-case-independent processes

Many processes and practices are mandatory for getting any value out of a SIEM. A few procedures are compulsory for utilizing advanced functionality, and only become necessary at high maturity stages.

Use-case-independent processes are mandatory for all SIEM deployments. The core set of processes includes the following:

  • Collector and log source configuration process
  • SIEM program checkpoint process
  • Content tuning and customization processes

The collector and log source configuration process enables the SIEM team to get to log sources to send data into the SIEM product. Together with collection and parsing, the monitoring process enables the team to know when log sources stop reporting data or stop reporting the correct data, which enables the SIEM to actually function. This process should include steps aimed at planning, configuring, testing and tracking the changes of log source configurations.

The SIEM program checkpoint process (biannual or annual) is a health-monitoring indicator for an entire SIEM program, not just the tool. This process allows an organization to track its successes with SIEM and plan deployment expansion. 

Content tuning and customization are critically important for SIEM success. If an organization does not have some sort of tuning process (initial and ongoing) to adapt a SIEM product to a changing environment, the chances of getting security value that's equivalent to the software purchase price are minuscule. "Off the shelf" SIEM content, while somewhat useful, needs to be customized and adjusted to solve the tougher problems for which modern SIEM tools are built.

Today's SIEM products come with reports, dashboards and correlation rules, which are created to address regulatory compliance (such as PCI DSS, HIPAA and many others) as well as common scenarios for security (such as reduction of false positives and user authentication analysis). Some vendors claim that such content is useful "out of the box" with no customization. Customer experience has shown that most content is useful only when it is applied to specific systems (thus customized by adding filters) or tweaked to better match the environment.

As SIEM deployments move up on the maturity scale, however, the process for customizing content, and eventually creating content, essentially becomes mandatory. For example, an organization that just purchased its first SIEM tool might only customize the reports for PCI DSS compliance so that they only run on systems in scope for PCI (a task of minimum difficulty). More mature organizations can modify the parameters (such as counts or timings) of vendor-provided correlation rules to increase their applicability for specific segments of the environment. Mature organizations that seek to extract maximum value from their SIEM tools will ultimately grow to create their own content based on defined use cases, thus making the SIEM tools deliver the value they were designed to provide.

Apex of maturity: Data exploration or ‘hunting'

As organizations evolve to security maturity, IT teams often move from incident detection to incident discovery. They do so by establishing a data exploration process, known as "hunting," using their SIEM, network forensics and other visibility-focused tools.

Data exploration such as visual discovery or data mining allows SIEM users to look for traces of advanced threats. Such processes naturally appear in more advanced SIEM deployments, in which relying on content—even constantly defined content—proves insufficient, and active data exploration needs to be performed. These advanced and unique use cases come with significantly elevated skill requirements and call for people with rare—and thus more expensive—skillsets, such as statisticians or data scientists paired with traditional security analysts.

Visual discovery or data mining is a "third" type of security process (tied neither to real-time monitoring nor to incident investigations). It allows organizations to actively sift through data to look for signs of compromise, and other significant events, that were missed by real-time monitoring components and didn't result in any declared incidents. This type of activity gives organizations the best shot at dealing with advanced persistent threats; any threats that are already present and operating on their networks; deeply entrenched insider fraud and internal sabotage.

Organizations that wish to build a data exploration process will have to learn most of it on their own because there are only a few examples in the industry to learn from. A data exploration process will most likely involve steps, such as creating statistical data models, or "what if" scenarios; testing the usefulness of the models on historical data; refining the conditions of the model; and running various summarization and profiling algorithms on the data in order to build the initial model.

Content tuning and customization processes need to be built during the deployment stage or shortly thereafter, before routine SIEM operation commences.

Regulations and compliance

Compliance adds little to a core SIEM process set:

  • Report review process
  • Compliance issue remediation process

Report review presents the core of the periodic workflow dedicated to compliance. PCI DSS (see Requirement 10.6) prescribes daily log reviews; other regulations also call for activity audits and reviews. For example, HIPAA calls for "procedures for monitoring log-in attempts and reporting discrepancies" and for covered organizations to "implement procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports."

Compliance control weakness remediation enables the organization to close the loop on discovered compliance weaknesses, and thus, act on the results of monitoring. This is an equivalent to security incident response processes, but applied to compliance incidents. Admittedly, the process does not reside inside the SIEM tool, but it is closely tied to SIEM-generated reports and alerts.

Real-time monitoring and investigations

Security processes are split into two distinct kinds: real-time monitoring and investigations. Some SIEM products excel at both, a few derive their lineage from investigative tools, and others retain their focus on real-time monitoring.

However, one process reigns supreme and presents a foundational element for any SIEM security use: the security incident response process.

If an organization does not have an incident response process that outlines what will happen if there is a security incident, procuring a SIEM tool is likely a mistake. In fact, "75% of chief information security officers (CISOs) who experience publicly disclosed security breaches and lack documented, tested response plans will be fired," according to Gartner research. Thus, organizations should put an incident response process in place before putting a SIEM tool into operation.

Monitoring processes include the following:

  • Alert triage process
  • Activity baselining process

The alert triage process happens between the moment when an alert is triggered and the time when an incident response process is initiated. Not every alert generated by a SIEM product triggers an incident, some might prompt refinements of SIEM content or changes in security policy. This process should include steps that allow security personnel to unambiguously determine whether the alert is an indicator of an incident, needs to be suppressed in the future, or requires further investigation or escalation.

The activity baselining process is inherently followed by most analysts that use a SIEM tool to review logs. This means that somebody learns what "normal" is for a particular network or system, and then tracks when some activity deviates from it. A dedicated process to profile users and system behaviors, and build a baseline is recommended for mature deployments.

Investigative processes include the following:

  • Indicator analysis process
  • Remediation process

The indicator analysis process is triggered when a security monitoring team receives an indication from outside a SIEM tool that something is amiss. Such a process will involve search results and report review in order to understand whether an indicator calls for activating an incident response process.

The remediation process is most commonly triggered outside of a SIEM tool, but based on investigation or alert triage. This process actually causes changes in an environment, either on monitored systems or in a SIEM itself. Many successful SIEM projects treat this as a closed loop from detection to issue resolution. Remediation is unlikely to be fully automated and may never fully reside inside the SIEM tool.

Many other processes can be built and should evolve in more mature environments. However, this base set of processes presents a reliable indicator of SIEM program success.

About the author:
Anton Chuvakin, Ph.D., is a research director at Gartner in the Gartner for Technical Professionals' Security and Risk Management Strategies 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 Warrior, Log Management and PCI Compliance.For more, check out his Gartner blog, personal blog or follow him on Twitter @anton_chuvakin.


This was first published in October 2013

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: