SIEM Extracting Intelligence out of logs CSX 1.1

Vijay Luiz, CISSP, CISA, GCIH

SIEM: Extracting Intelligence

out of Logs

Copyright © 2016 Information Systems Audit and Control Association, Inc. All rights reserved.

• Roles delivering SIEM since 2012

• SIEM & SOC consulting and training

• Recognises security as a multifaceted problem not to be solved

just by using a product

About Me


• What is SIEM?

• Why SIEM?

• How do we deploy?

• People, Process & Technology

• Evolution of your SIEM

Outline


• Security Information and Event Management

– Collection of events from many sources

– Correlation of events for security intelligence

– Automated reporting of items of interest

– Alerting users of items of particular interest

– Keeping data for duration as per retention requirement

• Security monitoring tool

– Does not take active measures to prevent attacks

– Has capability to identify anomalous activity

– Remediation is not necessarily a part of the tool

What is SIEM? Definitions


What is SIEM? Main Players

Source: Gartner (August 2016)


• Compliance to standards (ISO, PCI DSS, MAS TRM,…)

• Audit requirements (“The auditor needs me to review logs!”)

• Panic (“I need something to take care of my security problems.”)

• Security (“I need to know what is going on to take action”)

Why SIEM? Motivations


• What are you really trying to achieve?

– Log collection

• Long term log retention

• After incident review of logs

– Minor audit compliance

• Periodic log review

• Reporting

– Security monitoring and intelligence

• Real-time high-level security view

• Incident alerting

Why SIEM? Requirements


• Product

– Appliance cost

– Licensing costs

• Events Per Second (EPS)

• Log volumes

• Man-days for initial deployment

• Training of staff

– Product training

– GCIA, GCIH, etc.

• Additional staff / splitting of staff responsibilities

– Opportunity cost as staff spends time on SIEM

• Post-deployment support

– Product updates and patches

– Maintenance

How? Budgeting


• What logs / flows do you want to collect?

• How many logs should you collect?

– You do not have to collect all.

– Know your requirements.

• For how long do you need to retain logs?

– Offline or online?

• How big should your SIEM be?

– EPS

– Log volume

• Account for growth over the years.

How? Sizing


• Do you have structured and unstructured data in the environment?

• Can the SIEM read logs held in different formats?

• Is it possible to extract meaningful data out of all collected logs?

• Are the logs safe from tampering?

• Are the logs encrypted in transit? Do they need to be?

• How real-time is the log collection?

• How long does the initial configuration take?

• Do the users need extensive training?

• Can the SIEM content be customised?

• Is it easy to extend?

How? Details


• Different logs for different purposes

– Active Directory

– Firewall

– VPN

– IDS/IPS

– Proxy

– Web server

– Database

– Email gateway

– Linux Security Logs

• You do not have collect them all

How? Logs

Authentication /

insider threat

Application security

Perimeter

monitoring


• Key phrase: “People, Process & Technology”

– All three elements must be in place for SIEM to be effective.

– Do not rely on a product by itself to solve security problems.

People, Process & Technology


• Definitively identify users

– Operators

– Analysts (Level 2 & 3)

– Administrators

– Manager

– Business User

– External consultants (incident responders, SIEM product

specialists)

• Ensure that they have adequate training

• Employees need clear career paths to aid retention

PPT: People


• SIEM administration

• Daily health check

• Daily operation

• Report generation and review

• Alert triage

• Incident response

• Escalation

• Content building / tuning

• Shift handover (for SOCs and setups involving shift work)

PPT: Process


• SIEM content

– Dashboards – high-level real-time status

– Alerts – real-time notification that something has taken place

– Reports – periodic or ad-hoc review of status or events

– Filters – narrows down log selection from millions of events

collected

– Rules – if-then statements that trigger actions such as alerts

• SIEM advanced features

– Anomaly detection

– User behaviour analytics

– Threat intelligence

PPT: Technology


• Will contain false positives

– System needs to be tuned to environment

– Exceptions and exclusions will need to be made

• Take baselines of normal behaviour

• Easy to get started by tuning OOTB content

– Authentication-related reports and rules

– Device configuration-related content

Evolution of your SIEM: Out of the box Content


Do not try to jump straight to 5. Make a realisable step-by-step plan.

Source: http://blogs.gartner.com/anton-chuvakin/2012/09/17/on-siem-maturity-scale-and-maybe-on-cmm-too/

Evolution of your SIEM: Maturity Model

Stage Maturity stage Key processes that must be in place

1 SIEM deployed and collecting some log data SIEM infrastructure monitoring process

Log collection monitoring process

2 Periodic SIEM usage, dashboard/report review Incident response process

Report review process

3 SIEM alerts and correlation rules enabled Alert triage process

4 SIEM tuned with customized filters, rules, alerts and

reports

Real-time alert triage process

Content tuning process

5 Advanced monitoring use cases, custom SIEM content Threat intelligence process

Content research and development


• What is a use case?

– Business security concern (“privileged user access”)

– Problem you need to solve (“privileged users misusing access”)

– The worry that keeps you awake at night (“loss of customer data”)

– Output includes reports, dashboards & notifications

• How should we go about it?

– Low-hanging fruits first

– Easily achievable ones by tweaking OOTB content

– Start with simple content and reports

– Go for more complex content once SIEM at appropriate maturity

Evolution of your SIEM: Use Cases


• Security use cases come from business pain points.

• Translate these pain points into SIEM components.

– Action statement

– Device logs that need to be collected in SIEM

– SIEM content that needs to be built

• Rules

• Reports

• Alerts

• Dashboards, etc.

• Final output of the SIEM

– Notification

– PDF report for management

Discussion: Use Cases


• Translate use case to SIEM content!

• Case 1: Privileged account breach

• Respond to brute forcing of privileged accounts

– Action statement:

– Collect relevant logs:

– Create:


Be alerted to brute force attacks against privileged user accounts

AD, DB audit logs, app logs, etc.

Correlation rule (x failed attempts followed by successful attempt for

same user ID). Upon triggering, rule generates alert (email, SMS, popup, etc.)



• Case 2: Critical device access

• Management needs to know the trend on SSH access to critical devices



– Create:


Report on SSH access attempts to critical devices.

Firewall logs, server audit logs, etc.

Report with statistical data.



• Case 3: Critical DB server monitoring

• Take action and report on attacks targeting DB server



– Create:


Alert and report on attacks targeting critical DB server.

DB audit logs, app logs, firewall, IPS, etc.

Correlation rule that observes attacks targeting DB.

Report that displays events classified as attacks pertinent to specified DB

server. Attacks can be categorized depending upon vector and/or type of

attack.


• Anton Chuvakin - http://blogs.gartner.com/anton-chuvakin/

• Erik Bloch -

https://www.linkedin.com/today/author/0_0UUwiVUxn4Y8XUm0

_z67Vx?trk=prof-sm

References

http://blogs.gartner.com/anton-chuvakin/

https://www.linkedin.com/today/author/0_0UUwiVUxn4Y8XUm0_z67Vx?trk=prof-sm


Questions?

• Shoot!


• Website: www.essaysonsecurity.com

• Twitter: @vijayluiz

Stay in Touch!

http://www.essaysonsecurity.com/

Thank You!

SIEM Extracting Intelligence out of logs CSX 1.1

Documents