Logs and SIEMs

Incident Response
Logs
• Logs are key to knowing what’s happening on your network
 Even attackers will leave tracks

• Reveal critical errors/misconfigurations in systems

• Show usage of resources
 Audit logs
 Track an attacker’s activities

• Track security related information on computers

• Most every system (software, operating systems, etc.) have some sort of log capability
 Windows event logs

Incident Response
 DNS application logs
 Web server logs
 Proxy logs
 Email mailbox access logs

2
Configure logging
• Default logging levels are not always sufficient
 Sometimes no logging is default
• Be sure to check with your vendor
• Probably don’t need debug logging
• Pay attention to storage space!
 Lots of heavy logs will fill drives fast
 Lots of logs might not actually be useful

Incident Response
• Analyze the usefulness of the log

3
Analyzing Logs
• Manual log review
 Easy, no special tools required
 Impossible to do at scale

• Filtering logs
 Show a list of bad, ignore the good
 Easy to interpret the results
 Doesn’t catch everything

• Summary analysis
 Top 10 users, most connections by IP address

Incident Response
 Reduces the data, useful for reporting
 Loss of information to summarization

4
Analyzing Logs
• Visualization
 Easy to spot patterns
 Great to show off
 Not super useful for getting the details of an event

• Search analysis
 Easy to understand
 But what exactly should you search for?

• Correlation
 Rule-based algorithms
 Automated

Incident Response
 Fine tuning and writing by experts required

• Log mining
 Extract meaning from raw data
 Automated

5
 But still early in research
How logs help an IR
• Preparation
 Verify controls, collect a normal baseline, etc.

• Identification
 Detect and confirm an incident

• Containment
 Scope the incident, find what else was lost

• Eradication
 Preserve logs for the future, confirm backups are safe

• Recovery

Incident Response
 Confirm restoration

• Lessons Learned
 Logs available for training, as well as preventing a future attack

6
SANS top 6 log categories
• These can best show when suspicious activity is occurring

• Authentication and Authorization Reports

• Change Reports

• Network Activity Reports

• Resource Access Reports

• Malware Activity Reports

Incident Response
• Critical Errors and Failures Reports

7
Authentication and Authorization Reports
• What is it?
 Successful and failed attempts to access a system
 Specific privileged user activities

• Why is this important?

 Main barrier for access
 Attackers often will try to just log in, rather than bypassing the control

• Example searches (What might these be indicative of?)

 Logins after hours
 Remote access failures (VPN)

Incident Response
 Privileged account access
 Multiple login failures
 Followed by success of that same account

8
Example
• What’s wrong with this?

System Account Source IP Status Method Count

Name
Venus administrator 10.1.1.2 Failure Local 1
Pluto alex 10.11.12.13 Success Local 1
Mercury root 10.1.2.3 Failure SSH 893765

Incident Response
9
Change Reports
• What is it?
 Changes to configuration files
 Changes to accounts
 Changes to sensitive components of the system

• Why is this important?

 Unauthorized changes may indicate an incident
 Attackers may modify systems to expand or enable their access

• Example searches (What might these be indicative of?)

 New users or groups created

Incident Response
 New services installed
 Change in file permissions

10
Example
• What’s wrong with this?

Date System Account Operation Object Status

Name
1/10/11 Venus root Account anton Success
11:11AM PST Added
1/10/11 Jupiter anton Group sudoers Success
11:12AM PST Added
1/10/11 Venus root Account root1 Failure
11:15AM PST Added

Incident Response
11
Network Activity Reports
• What is it?
 Network activities that need to be tracked for regulatory compliance
 Potentially dangerous network activities
 Who is talking to who, how much bandwidth, what port/protocol, etc.

• Why is this important?

 The network is the main avenue into a computer
 Almost all attacks will traverse the network

• Example searches (What might these be indicative of?)

 Outbound connections from DMZ systems

Incident Response
 Largest file transfers, inbound or outbound
 File uploads to external sites
 VPN activity and usage

12
Example
• What’s wrong with this?

• VPN Access and usage

Date VPN User Name System Action Status Count

1/11/11 VPN1 anton antonlaptop Login Success 2
1/12/11 VPN1 anton antonlaptop Login Failure 1
1/13/11 VPN2 root Lapt19847 Login Failure 77

Incident Response
13
Resource Access Reports
• What is it?
 Access of system, application, and database resources
 Activity audit, incident detection

• Why is this important?

 Resource use can be used to track abuse
 Determine which resources the attacker accessed

• Example searches (What might these be indicative of?)

 Access to critical resources during off hours
 Privileged database user accesses

Incident Response
 DELETE queries executed on a database
 Systems sending mail, excluding known mail servers

14
 Example
• What’s wrong with this?

• File Access

Date Server User Name File Name Access Status Count

Type
1/11/11 Win1 anton Expenses.xlsx Read Success 1
1/12/11 Win2 anton Roadmap.ppt Read Success 1
1/13/11 NFS anton Blank.docx Write Failure 37

Incident Response
15
Malware Activity Reports
• What is it?
 Summarize various activities and events likely related to malicious software

• Why is this important?

 Malware is a key threat vector in all sizes of organizations
 Logs can be leveraged in addition to anti-virus products

• Example searches (What might these be indicative of?)

 Malware detection trends
 Internal connections to known malware IP addresses
 Anti-virus protection failures

Incident Response
16
Example
• What’s wrong with this?

Malware type Status Infected System

Count
VirusX Detected 1
VirusY Detected 1
Botz Quarantined 2

Incident Response
17
Critical Errors and Failures
• What is it?
 Significant system errors and failure indicators
 Often are security related events

• Why is this important?

 Can provide early indication of security threats
 Unusual errors could be indicative of a new threat to the network

• Example searches (What might these be indicative of?)

 Backup failures
 Capacity events for system resources like memory, CPU, disk, etc

Incident Response
 System crashes, shutdowns, restarts

18
Example

Server Event Type Date

Serv1 Disk Full 10/1/11
Sirius Disk Full 1/1/11
VenusX CPU Load 100% 1/2/11

Incident Response
19
So those are some examples on how
logs can be useful.

How do we go about determining if

something in the logs is malicious?

Incident Response
Two major techniques…
20
Signature Detection
• Detect known threats • Signature Examples

• Uses prior knowledge of what

an attack looks like
• Malicious File with a specific
• Alerts are high confidence hash
 Attacker can change one
• Easy to bypass character in the file, results in a
different hash

• Port 4444 being connected to

• Hashes  Commonly used in meterpreter

Incident Response
• Ports  Attacker can use a different
port
• IP Addresses

• Other Artifacts

21
Anomaly Detection
• Detect threats based on non- • Anomaly Examples
standard activities

• Uses prior knowledge of what

normal looks like, and generates
alerts based off abnormal • A login to an Admin account
at 2am
• Alerts are not always high
confidence  Typically that user only logs in
from 8-5, maybe that is a
• Slightly more difficult to bypass, but malicious use of the account?
still possible
• SSL/TLS encrypted traffic on
a port other than 443

Incident Response
• Behaviors  We expect to see encrypted
traffic on ports 443, 22, etc.
• Ports
 Seeing that traffic on, for
• Protocol Analysis example, port 80, would be
anomalous. Malicious? Maybe.
• Other Artifacts

22
So many logs
• Logs are extremely useful – essential to a good security monitoring program

• Need a way to efficiently collect, store, and analyze logs

• Log aggregation utility, SIEM

• Needs to be able to handle LOTS of logs quickly and efficiently

• Keep in mind the quantity of logs you may be dealing with!

 Tens or hundreds of thousands of events per machine (or more)
 Imagine a company with 100-1000 computers (not actually that big)
 Easily in the millions of events each day (or more)

Incident Response
23
SIM, SEM, SIEM
• All are tools that collect information used to analyze the security of the network

• SIM – Security Information Management

 Typically collecting logs
 The raw information

• SEM – Security Event Management

 Holds a collection of events
 Suspicious authentications, logon to admin account after hours, etc.
 Summarized “event” information from the raw security information

• SIEM – Security Information Event Management

Incident Response
 Combination of the above two
 Raw information from logs
 Security events

24
They are quite similar
• All really started with SIM tools
 Start collecting logs from various systems
 Often helps meet compliance requirements

• So you have a bunch of logs, now what?

• SEM systems help provide analysis and visualization capabilities

 Real-time
 Analyze alerts

• SIEM combines this – most products today should have the combined
capabilities

Incident Response
• Very few folks draw a distinction between these anymore – basically the same

25
Capabilities
• Data Aggregation • Compliance
 Consolidates logs from many sources  Produce reports from log data for
compliance requirements
• Correlation
 Uses common attributes to link events • Retention
together
 Long-term storage for forensic
 Turns raw data into more useful investigations and possible compliance
information requirements
• Alerting
• Forensic Analysis
 Automated analysis of raw data produces
actionable alerts  Ability to search across different nodes
and time periods.

Incident Response
• Dashboards
 Turns data into useful charts
 Easier to see patterns or anomalies in
data

26
Plenty of options
• Lots of vendors in the market
• Orgs should evaluate products and make selections based on their needs
 Which features from the previous slide are 100% necessary?
 Price
 Learning curve
 Quantity of data and server requirements

• As an incident responder, you may use any number of these – whatever is

available to you
• Some vendors in the market…
 IBM, Splunk, HPE, AlertLogic, Intel, LogRhythm, ManageEngine, MicroFocus, Solar

Incident Response
Winds, Trustwave…

• Even some open source options

 OSSIM, Elastic Stack, Apache Metron, SIEMonster, Prelude, Graylog

27
Graylog
• Open source log management

• Scalability
 Can bring in logs from multiple tools from multiple systems
 Terabytes of data

• Alerting capabilities

• Report generation capabilities

Incident Response
• Pre-configured appliance for testing

• Production, more scalable setups on Ubuntu, Debian, CentOS

28
Lab
• Graylog VM – just the pre-configured appliance for testing

• NXLog
 Open source log forwarder
 Used for forwarding to various aggregation solutions

• Windows machine
 Security log
 Sysmon

Incident Response
• Let’s jump in to get familiar

29