The logs collected need to be analyzed for events. We use a class of tools called SIEM for that. SIEM stands for Security Information and Events Management. These are basically software that collects events and use data correlation techniques to process huge volumes of data to find connections between events. The biggest benefit of using data correlation software is that 90% of the event logs are dismissed as false positives. This frees up the security team to look at only the suspicious events. SIEM majorly assists in achieve the following: Collects and store logs from network devices, security devices, and host operating systems, correlates logs from variety of security related systems and devices and generates alerts regarding important security issues, provides reporting mechanism for compliance, auditing, and security monitoring. It's a single source for investigation.

Detection of incidents, it can detect and respond efficiently to any kind of anomalies or suspicious activities identified from the logs, and it serves as an early warning for risk mitigation. It detects anomalies in user behavior, traffic pattern, and system configurations. It gives us information on log retention, that is due diligence towards investigation and forensic analysis. Compliance, regulation, information towards information security standards such as ISO 27001 and regulatory requirements such as SOX.

Real time alerting helps in upholding the SLA with instant correlation alerts on security incidents, allowing immediate investigation and corrective actions to prevent breaches. And operational accountability, who did what, where and when? Formally speaking, the various tasks or steps that are carried out by an SIEM is as follows: Collection. This is where the logs from the various asset classes referred to in the previous slide are collected, namely network devices, application devices, etcetera. Setting up the architecture for the collection of these logs and planning the network capacity is a topic in itself. But the most important point to note is that any SIEM devices, uses devices called collectors to collect the logs, and these are pretty costly. It is important to plan the location of these collectors wisely.

Secondly, in the case of centralized log management systems, network bandwidth to transport these logs to the central location needs to be planned in advance. This should come under the capacity planning discussed in an earlier domain. Aggregation and normalization: Once all the logs have flowed into the centralized SIEM system, the logs are aggregated and normalized, that is they are converted to a format that makes it easy for the central correlation engine to compare them with other events. Correlation. This is the heavy lifting portion of the SIEM system. Intense statistical algorithms are carried out to find out whether there are any connections between these events and which look likely to be actual incidents. Real time alerting and reporting: Once the SIEM system believes it has detected an actual incident, it will send out an alert to the security operations team monitoring the SIEM. This now becomes part of the incident management process. Retention storage and maintenance.

One last point to note about monitoring. Compliance might require that the logs be stored for a certain duration of time. This is called log retention policy. The legal department in conjunction with a privacy group usually draws this up. The security group needs to insure that capacity planning for storage has been appropriately planned. Frequently, due to ineffective capacity planning, the SIEM system starts to run out of storage, both temporary, as well as permanent. The impact of this is that the SIEM starts to react very slowly, and pretty much becomes ineffective when we are combating an actual attack.