Overview of recommendations for log reports.

*This article is a follow-up to Anton Chuvakin's blog post.

What and Why

There's been enough written on the topic of "Top Reports" for SIEM/LM solutions.  The subject comes up fairly regularly, and even SANS had released their 'Top 5 Essential Log Reports' (PDF).  It quickly becomes obvious that the amount of information we can disseminate from IT systems these days is extremely vast.

However, when it comes to suggesting "top" reports for your organization, talking about "why" is even more important than listing "what".  Asking "why" should get you to think about what the top priorities are and how to address them.  Sure, we all want visibility, but which areas are more important than others?  What did look like a big gaping hole during the last outage or security incident?

In some cases what's needed heavily depends on which solutions are already in place. For example, if you already have a well developed vulnerability assessment or anti-virus infrastructure with excellent reports across the board, there might not be a need to replicate this functionality with SIEM. The same goes for things like NetFlow and network traffic anomaly detection - some solutions out there will do a much better job than trying to piece the right content for your SIEM from scratch.

Another angle is how to slice the information you already have.  Here, the organization of your IT infrastructure should probably reflect the categories and views within your reports. Splitting any metric by a Business Unit or Application provides additional insight into your operations and can help IT management to focus the efforts on specific team if necessary.  It's also common to segregate metrics by Stage (Development, Testing, or Production), as well as by areas of responsibility (infrastructure teams manning parts of the environment and commonly designated as Unix, Windows, Network Teams, and the like).

Report Examples

But what about reports themselves? I'd like to throw my hat into the ring and talk about three distinct areas or 'use cases' for reports. There are several reasons why I picked these three:

1. Other types of reports have been covered before, elsewhere, and in depth.
2. Most of these reports rely on correlation and produce results not delivered outside of SIEM solutions.
3. These particular groups would be extremely relevant in any IT organization.

Environment Monitoring

Reports such as these help ensure that your monitoring infrastructure provides complete and consistent coverage of the monitored areas.

• Systems that stopped reporting events
• Solutions/Vendors that stopped reporting events
• Noticeable drops in event "chatter" per geographical location, zone, network or VLAN
• Critical systems availability monitoring
• Critical services availability monitoring

Security Policy Enforcement

Critical in any organization, such reports ensure compliance with your internal security policy, particularly in the areas that did not have technical means for enforcing policy statements before SIEM.

• Insecure services
• Directional traffic enforcement (DMZ to Internal, etc.)
• Unauthorized services (employees hosting IRC, FTP, etc.)
• Usage of generic IDs
• Usage of default vendor accounts
• Superuser activity, including admin group memberships
• Maintenance window enforcement (change control, system resets, service restarts, etc.)

Security Program: Trending Graphs

Reports such as these help security program managers to access the security posture over time.  They demonstrate effects of decisions related to security and availability of IT infrastructure.  These would typically be represented by stacked area charts trended over extended time frame, such as weekly measurements over several months period. Although simple, these reports may indicate trends critical to the organization.

• Malware infestations with successful versus failed clean-up/quarantine outcome
• Failed authentication/authorization activity, possibly by business unit or network segment
• External "noise" levels (external attacks against perimeter, including recon)
• Suspicious internal activity (IDS based)
• Number of known vulnerabilities averaged per system, possibly by business unit or network segment
• Traffic throughput/bandwidth utilization

Trending Example

As an example, the following Malware Remediation trend graph demonstrates that even though the number of detected malware occurrences has grown since the beginning of the year, the number of unsuccessfully remediated infestations have actually decreased, indicating growing effectiveness of the anti-malware solution in place.