You said “SIEM”?

In my previous post, I talked about a “SIEM” environment. What’s behing this new accronym?

SIEM stands for:

• Security
• Information
• and Event
• Management

Today, IT platforms are very complex (exponential expansion, integration of mixed environments, worldwide deployed) and, in the same time, they must be reliable on a 24×7 basis: Events must be captured in no time and corrective actions applied. The business requires to be compliant with one of more norms such as SoX (Sarbanes-Oxley), HIPAA, Basel II, etc.

The administrators must face with major technical problems:

• A fast growing amount of logs to be archived and analyzed.
• Logs are generated in multiple formats by multiple devices.
• Analyzes must be performed as real time (alerting) as in batch (reporting)

The goal of a SIEM platform is to try to solve all those issues by performing the following operations on the logs:

• Collecting the logs from many sources
• Normalizing the logs
• Storing in a proprietary DB system (optimized to store them in the best way)
• Alerting when triggers are detected
• Performing scheduled reports (daily, weekly, monthly)
• Performing forensics search

The application looks like: (click to enlarge)

What about “exotic” devices or self-developed applications? Well, all SIEM environments have the capacity to “learn” messages from devices they don’t support natively (don’t care, they provide support for almost all big players on the market). Anyway from time to time, it can be very usefull to integrate your own devices. In this case some investigation is required to collect sample logs, analyze them and extract the useful information (warning, this can be very time consuming in a project!).

What useful information can be extracted from the collected logs? It depends on the business requirements! But the most powerful feature provided by a SIEM is “alert correlation”! The problem with a high number of monitored devices is to avoid flood of alarms or worst false alarms! With alert correlation, administrators can write complex sets of rules and generate only ONE alarm or event! Exemple:

• If the firewall drops packets for IP a.b.c.d on ports x, y and z in less than t seconds, we can generate a “port scanning” alert.
• If we detect a rejected password for user john on all UNIX servers in a short interval of time, we can generate a “intrusion probe” alert.

Of course, the SIEM is “open” to other systems to export alarms to a third party application (ex: if the company has already deployed its own ticketing system).