 SIEM

Security Information and Event

Management (SIEM) – A
Detailed Explanation
By
 BALAJI N
 -
 December 24, 2018 
6

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.
Also Read:  Indicator Of Attack(IoA’s) And Activities – SOC/SIEM – A
Detailed Explanation
 

                                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.

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.

The Path to SIEM Success

The path to SIEM success looks something like this:

 Collect logs from standard security sources.

 Enrich logs with supplemental data.
 Global Threat Intelligence (Black Lists).
 Human Resource / Internet Download Management.
 Correlate — finding the proverbial needles in the log haystacks.
 Investigate — follow up and fix.
 The document — Standard Operating Procedures, Service Level
Agreements, Trouble Tickets.
 Incorporate — Build white lists, new content.

Top 10 Use Cases for SIEM

With the growing use of SIEM solutions, business houses are keen on solving
a number security and business use cases seen during their day-to-day
operations. In this post, we will go through the top 10 use cases with an
overview of how you can use  to detect any such behavior in your
infrastructure

The following are the top 10 use cases:

1. Authentication Activities

Abnormal authentication attempts, off hour authentication attempts etc,

using data from Windows, Unix and any other authentication application.

2. Shared Accounts

Multiple sources(internal/external) making session requests for a particular

user account during a given time frame, using login data from sources like
Windows, Unix etc.
3. Session Activities

Session duration, inactive sessions etc, using login session related data
specifically from Windows server.

4. Connections Details

Connections can be genuine or bogus. Suspicious behavior may include

connection attempts on closed ports, blocked internal connections,
connection made to bad destinations etc, using data from firewalls, network
devices or flow data. External sources can further be enriched to discover
the domain name, country and geographical details.
5. Abnormal Administrative Behavior

Monitoring inactive accounts, accounts with unchanged passwords, abnormal

account management activities etc, using data from AD account
management related activities.

6. Information Theft

Data exfiltration attempts, information leakage through emails etc, using

data from mail servers, file sharing applications etc.
7. Vulnerability Scanning and Correlation

Identification and correlation of security vulnerabilities detected by

applications like Qualys against other suspicious events.

8. Statistical Analysis
Statistical analysis can be done to study the nature of data. Functions like
average, median, quantile, quartile etc can be used for the purpose.
Numerical data from all kind of sources can be used to monitor relations like
ratio of inbound to outbound bandwidth usage, data usage per application,
response time comparison etc.

9. Intrusion Detection and Infections

This can be done by using data from IDS/IPS, antivirus, anti-malware

applications etc.
10. System Change Activities

This can be done by using data for changes in configurations, audit

configuration changes, policy changes, policy violations etc.

Critical Controls and SIEM

Critical Control 1: Inventory of Authorized and Unauthorized Devices

SIEM can correlate user activity with user rights and roles to detect
violations of least
privilege enforcement, which is required by this control.

Critical Control 2: Inventory of Authorized and Unauthorized

Software

SIEM should be used as the inventory database of authorized software

products for correlation with network and application activity.
Critical Control 3: Secure Conjurations for Hardware and Software on
Laptops, Workstations, and Servers

Known vulnerabilities are still a leading avenue for successful exploits. If an

automated
device scanning tool discovers a mis configured network system during a
Common
Configuration Enumeration (CCE) scan, that misconfiguration should be
reported to the
SIEM as a central source for these alerts. This helps with troubleshooting
incidents as
well as improving overall security posture.

Critical Control 4: Secure Configurations for Network Devices such as

Firewalls, Routers,and Switches

Any misconfiguration on network devices should also be reported to the

SIEM for consolidated analysis

Critical Control 5: Boundary Defense

Network rule violations, like CCE discoveries, should also be reported to one
central
source (a SIEM) for correlation with authorized inventory data stored in the
SIEM
solution

Critical Control 6: Maintenance, Monitoring, and Analysis of Audit

Logs

Control 6 is basically a control about SIEMs, which are a leading means for
collecting
and centralizing critical log data; in fact, there is even a subcontrol for
analysis that
studies SIEM specifically. SIEMs are the core analysis engine that can
analyze log events
as they occur.

Critical Control 7: Application Software Security

Like CCE scan results, vulnerabilities that are discovered in software

applications should
also be reported to a central source where these vulnerabilities can be
correlated with
other events concerning a particular system. SIEMs are a good place to store
these scan
results and correlate the information with network data, captured through
logs, to
determine whether vulnerabilities are being exploited in real time.

Critical Control 8: Controlled Use of Administrative Privileges

When the principles of this control are not met (such as an administrator
running a
web browser or unnecessary use of administrator accounts), SIEM can
correlate access
logs to detect the violation and generate an alert.

Critical Control 9: Controlled Access Based on Need to Know

SIEM can correlate user activity with user rights and roles to detect
violations of least
privilege enforcement, which is required by this control.

Critical Control 10: Continuous Critical Control

SIEM can correlate vulnerability context with actual system activity to
determine
whether vulnerabilities are being exploited.

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.