In the previous two articles in this series, we looked at selecting a security information and event management (SIEM) solution based on your organization’s requirements, and implementing SIEM
Requires Free Membership to View
effectively. In the third and final installment in this series we look at tips to
optimally configure and use the SIEM solution of your choice.
There are many common errors that organizations make in the SIEM realm. These include: attempting to double up the SIEM solution as a syslog server; allocating insufficient dedicated manpower or poorly trained manpower; and, absence of coordination and awareness with respect to incident response. These shortcomings result in organizations getting a less than satisfactory return on their investments for SIEM.
Here are six guidelines to spruce up the performance of your SIEM implementation:
Useful SIEM resources
- Grouping perimeter devices/critical servers for monitoring: It is a good practice to
group your perimeter devices and servers in critical zones and categories. For instance, at
Genpact, devices within the public DMZ and public-facing servers have been put in a different group
and separate windows/dashboards exist for alerts coming from that particular zone.
These groups can be created for the SIEM solution using common criteria or characteristics, while taking a risk-based approach, an asset-value-based approach or an exposure-based approach. Grouping will make monitoring and reacting to events more efficient. Grouping can also be done on the basis of applicable compliances and standards such as SOX or PCI DSS, for better monitoring and ensuring compliance.
- Baseline of events/logs: A network environment has a lot of background noise that has to
be sifted through in order to detect anomalous activity. The sources of this noise may be many,
including minor alerts/flags or diagnostic alerts, and these cannot be completely eliminated.
Creating a baseline of the number and kind of events that are reported to the SIEM system over a
period of time would give you a good idea of what is normal and what isn’t.
This will help you determine how healthy your network environment is and will help to identify any anomalies in the environment. For instance, a good criterion for determining a baseline is traffic volumes. Traffic detected above the baseline by the SIEM solution may indicate suspicious activity, while traffic below the baseline may be because certain devices stop reporting to SIEM. The baseline feature is usually available with most commercial, off-the-shelf SIEM packages today.
- Traffic into the network: The team monitoring SIEM should pay more attention to traffic
that passes through the firewall and enters the network rather than on traffic that is blocked by
the firewall at the perimeter generating deny alerts. Scrutiny of traffic that has entered the
network should take precedence when performing analysis using your SIEM solution. However, do keep
in mind that an unnatural number of deny alerts may also mean that a DoS attack is in
progress.
- Your SIEM solution is not a syslog server: Most of the support functions in an
organization -- for instance, server group or network group -- tend to view the SIEM implementation
as a syslog
server. It is often suggested that the responsibility of maintaining the logs be passed on to
the team monitoring SIEM. In reality, this will defeat the very purpose of having an SIEM
monitoring team.
The primary purpose of an SIEM solution is to perform real-time analysis of security alerts. If you instead use it as a repository and reduce it to a syslog, you may end up dumping a lot of data on the SIEM system and adversely impact its performance. In situations where log retention is required, a dedicated syslog server that is maintained separately from the SIEM solution should be acquired.
- Designate single point of contact for every department in times of emergency: For an
effective incident response mechanism, consider creating a virtual team with representations from
various technologies, verticals and locations, in addition to the core SIEM monitoring team. This
will enable quicker redress for any issues that the SIEM team identifies. For effective remediation
of issues in an emergency, a single point of contact (SPOC) in each department or vertical should
be available to the SIEM team.
- Keep the SIEM function/team separate:
As a rule of thumb, the team operating the SIEM solution should not have any operational responsibilities. For instance, if the SIEM administrator is also a system administrator, such situations could lead to a conflict of interest. The team operating SIEM should be well trained on the system. An SIEM technician need not be a master of any particular domain, but it certainly helps if he is a jack of several trades, with exposure to multiple fields.
Read more on selecting & implementing SIEM
About the author: Satish Jagu is the senior manager for corporate information security at Genpact. With more than 12 years of professional experience in IT, Jagu has expertise in security, network and system administration on UNIX/Windows platforms, security systems and Internetworking devices. He has TCP/IP network experience in design, in addition to implementation of Internet and Intranet services. Jagu has worked on ISO 27001 implementation and certification projects, as well as SAS 70 and SoX IT controls.
| (As told to Varun Haran) |
This was first published in July 2012