[Excerpted from "SIEM Success: Maximizing Your Monitoring Investment," a new report posted this week in Dark Reading's Security Monitoring Tech Center.]

If we are to believe the vendors, SIEM systems help consolidate event information and sift through the enormous volume of data collected to separate the significant events from the noise and meet regulatory and security requirements -- all with a skeleton monitoring crew.

Even if we take these claims with a grain of salt, we still hope our SIEM systems will bring some sense of order to all that information. Unfortunately, companies often are disappointed with SIEM systems' effectiveness in their default configurations, yet never invest the time required to extract the value these products can provide.

The problem is one of mismanaged expectations: The truth is that SIEM systems are as valuable as the effort a company puts into understanding and using them. Their effectiveness is based largely on a company's ability to identify how events emitted from technical components relate to its particular business risks. While off-the-shelf rules and filters may help with some rudimentary event-to-business mapping, successful monitoring is mostly a matter of hard work.

SIEM monitoring is much more complex than pointing a tool at a set of logs and having a system administrator check it occasionally. Establishing an effective monitoring program requires a strategy that begins with identifying the critical systems and components that must be watched, and understanding what we need to know about them.

Your strategy should be to identify critical assets, understand what your company needs to know about them, and look for logs and events that include that information. When that data is not available, you need to instrument systems, change logging levels and/or install additional systems that will provide it.

The quality of your monitoring effort and the value of your SIEM system will be directly dependent on the caliber of the team you assign: the people who work with the business, manage the monitoring effort, configure the SIEM system, and extract useful information from systems and logs.

With a SIEM team in place, your next job is to identify the assets to monitor and choose a suitable starting point. Make a list of your most critical systems in priority order and organize them and their components by asset -- for example, your ERP, HR and payroll systems are assets.

Some companies maintain a critical asset list, so you'll save some time. This list, which will drive your monitoring prioritization decisions, is typically maintained by IT, but the priorities are based on risk, determined by the business owners' assessment of the asset's value to the company and security's assessment of potential threats. The list must be validated by senior management.

Now, choose your first asset to monitor. This requires close coordination of the business and technical people responsible for the systems to be monitored. You will need help with requirements definition, identification of system components, identification of event sources (logs, event streams), and understanding the mapping of log entries to events that are meaningful to the business.

The first group you choose will suffer through the initial pain of product configuration, rules development, and false positives as you refine your process, so it is important to have willing participants who appreciate the end goal. Try to identify an existing group that has clear compliance requirements, such as responsibility for protecting financial records, credit cards, or personally identifiable information. In the early going, stay away from pure operational systems that don't have specific monitoring requirements.

An asset's business value and regulatory requirements dictate its monitoring requirements. For example, an e-commerce application that accepts, processes, and stores credit card information must meet both PCI DSS and, perhaps, state privacy law monitoring requirements.

The same standards and regulations provide guidance to the types of behavior you should monitor. When you analyze the application and the information it captures based on compliance requirements, you will need to determine the types of events that signify noncompliance and policy breaches.

After you've selected an asset and determined the criteria of a policy breach, analyze the systems supporting the asset, and use business requirements from regulations and risk analysis to turn policy breaches into event filtering rules. This process allows for the methodical extraction of information from logs, event streams, and supporting systems, and identification of significant security events.

To learn about the steps used to maximize SIEM capabilities and find out what "red flags" to monitor, download the free report.

Have a comment on this story? Please click "Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.