Every day, organizations rely on security information and event management (SIEM) solutions to protect, control and monitor their technology infrastructures. These platforms serve as early detection tools for security threats. But how can security professionals validate that their SIEM systems are properly configured and aligned with the organization’s security requirements? Is there any kind of evaluation system — in other words, a maturity model — to check these solutions against security best practices?

The SIEM Maturity Model

There’s no need to reinvent the wheel to create this model of measurement, but analysts must be able to catalog and group the characteristics they aim to measure to determine what level of SIEM implementation is appropriate for the organization.

Below is an example of how analysts can use various features, requirements and usage schemata to create a basic measurement model for SIEM tools.

Level 1 : Clean Up/Start Up

If you have an SIEM installed and configured in your infrastructure, the first step is to ensure that the log sources list is correctly identified and grouped. Next, verify that the SIEM is parsing events properly so that no event is classified as unknown. The information about the properties involved in the rules and initial use cases must be correctly configured and parsed as well.

Next, make sure that the rules activated in the current configuration make sense and are correctly parameterized by the managers of each area. Also verify that the reports generated by the SIEM are valid and the dashboard is configured according to the platform manager’s needs. It’s worth noting that during the early stages of this procedure, these processes may or may not be documented.

Level 2: Documentation and Formal Process

If Level 1 processes are not documented, they should be documented at this level. Create formal documentation of the following critical technical aspects in relation to the SIEM platform:

• Current network diagram and network hierarchy;
• Log sources (quantity, ID, type of events to send, criticality, etc.);
• Base lists of information contained in building blocks and reference sets;
• Type and structure of the dashboards;
• Licensing;
• Backups;
• Storage;
• Routing rules; and
• Retention period.

It is also very important to have a monitoring and control scheme in which the SIEM figures heavily into internal security policies and procedures. To take your SIEM maturity model to the next level, you must document processes related to:

• Monitoring and controlling infrastructure and security;
• Management of monitoring platforms;
• Incident control and reporting; and
• SIEM tasks such as inclusion of new log sources, rule creation and reporting.

You should also have documentation about the reports generated by the SIEM. This should include information related to the reason for the report, expected or required data, scheduling, internal structure and access privileges.

Finally, it is critical to document searches to streamline both the normal use of the platform and the creation of new rules and reports. It is useful and efficient to have preconfigured searches, but the list can become unmanageable if it is too long. For this reason, documentation about why a search was conducted and by whom is key.

Level 3: Improvements and New Usages

Now that we’ve covered the technical, configuration and management aspects of the maturity model, we can start to create use cases to generate new security alerts on the SIEM platform. As in the previous level, it is important to document the creation of these new monitoring schemes.

When creating these new improvements, we must consider the security requirements and monitor internal host access to malicious sites categorized by a threat intelligence feed. We must also validate that log sources and events correspond to the logic of the new rule. Finally, we should document other details such as severity levels, rule indices and the creation of specific events each time a rule is run.

Level 4: Integration and External Services

While the previous levels take advantage of the SIEM platform, this level is characterized by the inclusion of new services such as plugins, external feeds and custom parameters. By this process, we can integrate services and external incidents from areas such as ticket management and the service desk with security management tools. You should wait until the final stage to perform these integrations. That way, the platform will be in good condition and contain relevant information that is controlled by the proper owners. This also ensures that the SIEM fits correctly with other processes and systems with high levels of ripeness.

The final step is to conduct a gap analysis to determine ways to improve the current process. We should then create a road map based on this assessment to summarize the efforts required to improve the current level. This road map can serve as a monitoring and control process to be presented to management.

SIEM Maturity Is Not One-Size-Fits-All

Remember that this is only a basic scheme that, depending on the organization and its current maturity level, may vary. It should also be noted that many companies are regulated by robust measurement models and may have better control mechanisms for their security management tools. For organizations that lack a process of measurement, however, this model can help security analysts begin the process of maturing their SIEM deployments.