SIEM software products and services combine security information management (SIM) and security event management (SEM). They provide real-time analysis of security alerts generated by network hardware and applications.
Vendors sell SIEM as software, as appliances or as managed services; these products are also used to log security data and generate reports for compliance purposes.
Although the industry has settled on the term ‘SIEM’ as the catch-all term for this type of security software, it evolved from several different (but complementary) technologies that came before it.
Also Read : How to build and run a Security Operations Center
• LMS“Log Management System” – a system that collects and stores log files (from Operating Systems, Applications, etc) from multiple hosts and systems into a single location, allowing centralized access to logs instead of accessing them from each system individually.
• SLM /SEM “Security Log/Event Management” – an LMS, but marketed towards security analysts instead of system administrators. SEM is about highlighting log entries as more significant to security than others.
• SIM “Security Information Management” – an Asset Management system, but with features to join security information too. Hosts may have vulnerability reports listed in their summaries, Intrusion Detection and AntiVirus alerts may be shown mapped to the systems involved.
• SEC “Security Event Correlation” – To a particular piece of software, three failed login attempts to the same user account from three different clients, are just three lines in their logfile. To an analyst, that is a particular sequence of events worthy of investigation, and Log Correlation (looking for patterns in log files) is a way to raise alerts when these things happen.
• SIEM “Security Information and Event Management” – SIEM is the “All of the Above” option, and as the above technologies become merged into single products, became the generalized term for managing information generated from security controls and infrastructure. We’ll use the term SIEM for the rest of this presentation.
Capabilities
- Data aggregation: Log management aggregates data from many sources, including network, security, servers, databases, applications, providing the ability to consolidate monitored data to help avoid missing crucial events.
- Correlation: looks for common attributes and links events together into meaningful bundles. This technology provides the ability to do a variety of correlation techniques to integrate different sources, to turn data into useful information. Correlation is typically a function of the Security Event Management part of a full SIEM solution
- Alerting: the automated analysis of correlated events and production of alerts, to tell recipients of immediate issues. Alerting can be to a dashboard or sent via third-party channels such as email.
- Dashboards: Tools can take event data and turn it into informational charts to aid in seeing patterns, or identifying activity that is not forming a standard pattern.
- Compliance: Applications can be employed to automate the gathering of compliance data, producing reports that adapt to existing security, governance and auditing processes.
- Retention: employing long-term storage of historical data to facilitate correlation of data over time, and to provide the retention necessary for compliance requirements. Long-term log data retention is critical in forensic investigations as it is unlikely that discovery of a network breach will be at the time of the breach occurring.
- Forensic analysis: The ability to search across logs on different nodes and time periods based on specific criteria. This mitigates having to aggregate log information in your head or having to search through thousands and thousands of logs.
How do SIEM works?
You may have noticed the word “Co-Relation” Yes, for the question How the SIEM works, the one stop answer is a co-relation. But not that alone of course.
Basically, a SIEM tool collects logs from devices present in the Organization’s infrastructure. Some solutions also collect NetFlow and even raw packets. With the collected data(mainly logs, packets), the tool provides an insight into the happenings of the network.
It provides data for each event occurring in the network and thus acts as a complete centralized security monitoring system.
In addition to this, the SIEM tool can be configured to detect specific incident. For example, a user is trying to log in to an AD server. For first 3 times the authentication failed and the 4th time it succeeded. Now this is an incident to look up on.
There are many possibilities. Maybe a person is trying to guess the password of another user and got it right, which is a breach. Or maybe if the user forgot his password but got it right at the end and so on. This is where co-relation comes in.
For such a case, a co-relation rule can be made in such a way that, If an authentication failure event is happening 3 times consecutively followed by a success in a specific time period, then alert pops up.
Also read: Better Visibility for an Analyst to Handle an Incident with Event ID
This can be further investigated further by analyzing the logs from respective machines. So my definition of co-relation is: “ It is the rule which aggregates events into an incident which is defined by specific application or scenario.”
SIEM Recipes – A list of ingredients you’ll need for a good SIEM Deployment
Logs and Alerts:
Security Controls Infrastructure
• Intrusion Detection Routers
• Endpoint Security (Antivirus, etc) Switches
• Data Loss Prevention Domain Controllers
• VPN Concentrators Wireless Access Points
• Web Filters Application Servers
• Honeypots Databases
• Firewalls Intranet Applications
Infrastructure Information Business Information
• Configuration • Business Process Mappings
• Locations • Points of Contact
• Owners • Partner Information
• Network Maps
• Vulnerability Reports
• Software Inventory
Security Information/Events Logs
• Log Collection is the heart and soul of a SIEM – the more log sources that
send logs to the SIEM, the more that can be accomplished with the SIEM.
• Logs on their own rarely contain the information needed to understand their
contents within the context of your business.
• Security Analysts have limited bandwidth to be familiar with every last system
that your IT operation depends on.
• With only the logs, all an analyst sees is “Connection from Host A to Host B”
• Yet, to the administrator of that system, this becomes “Daily Activity Transfer
from Point of Sales to Accounts Receivable”.
• The Analyst needs this information to make reasoned assessment of any
security alert involving this connection.
• The true value of logs is in correlation to getting actionable information.
Log records cover:
- Normal activity
- Error conditions
- Configuration changes
- Policy changes
- User access to assets
- Incident alerts
- Unauthorized use of resources
- Non-privileged access to files
- User behavior patterns
- Clearing of sensitive data
- Access to audit trails
Logs provide feedback on the status of IT resources and all activity going through them.
How logs reach the SIEM?
Logs are fetched to the SIEM in two different ways. Agent-based & Non-Agent based. In agent-based approach, a log pushing agent in installed in the client machine from which the logs are collected.
Then this agent is configured to forward logs into the solution. In the later type, the client system sends logs on it’s own using a service like Syslog or Windows Event Collector service etc.
There are also specific applications & devices which can be integrated through a series of vendor specific procedures.
How exactly would the SIEM raise an alert?
Well, now you know that the logs from different devices are being forwarded into the SIEM. Take an example: A port scan is initiated against a specific machine. In such a case, the machine would generate a lot of unusual logs.
Analyzing the logs, it will be clear that a number of connection failures are occurring to different ports in regular intervals.
Seeing packet information if possible, we can detect the SYN requests being sent from the same IP to the same IP but to different ports in regular intervals. That concludes that somebody initiated an SYN scan against our asset.
The SIEM automates this process and raises alerts. Different solutions do this in different ways but produce same results.
Critical Control 11: Account Monitoring and Control
Abnormal account activity can only be detected when compared to a baseline of
known good activity. The baseline to meet this control should be recorded by the
SIEM; and, as future snapshots or baselines are recorded, they can be compared to the
approved baseline in the SIEM.
Critical Control 12: Malware Defenses
Malware that is discovered should be recorded according to this control. Centralized
anti-malware tools should report their findings to a SIEM, which correlates against
system and vulnerability data to determine which systems pose a greater risk due to the
malware discovered on that system
Critical Control 13: Limitation and Control of Network Ports, Protocols, and Services
if a system has a running port, protocol, or service that has not been authorized, it should also be reported to a central source where these vulnerabilities can be correlated with other events concerning a particular system. SIEMs can monitor log data to detect traffic over restricted ports, protocols, and services. Organizations can use these controls to decide which ports and services are useful for business, which are not, and which types of traffic and ports to limit
Critical Control 14: Wireless Device Control
Device misconfigurations and wireless intrusions should be reported to a central
database for incident handling purposes. A SIEM is a perfect candidate to consolidate
this information and use it for correlation or detection of threats to wireless
infrastructure
Critical Control 15: Data Loss Prevention
data loss rule violations, like CCE discoveries, should also be reported to one central source such as a SIEM, which can correlate data loss events with inventory or asset information as well as other system and user activity to detect complex breaches of sensitive data.
Critical Control 15: Data Loss Prevention
data loss rule violations, like CCE discoveries, should also be reported to one central source such as a SIEM, which can correlate data loss events with inventory or asset information as well as other system and user activity to detect complex breaches of sensitive data.
