InfoSecurity.be 2011

36
All Your Security Events are Belong to ...You! InfoSecurity 2011 - Xavier Mertens

description

These are the slides of the talk given during InfoSecurity.be 2011.

Transcript of InfoSecurity.be 2011

Page 1: InfoSecurity.be 2011

All Your Security Events are Belong to ... You!

InfoSecurity 2011 - Xavier Mertens

Page 2: InfoSecurity.be 2011

$ whoami

• Xavier Mertens

• Senior Security Consultant

• CISSP, CISA, CeH

• Security Blogger

• Volunteer for security projects like:

Page 3: InfoSecurity.be 2011

$ cat disclaimer.txt

“The opinions expressed in this presentation are those of the speaker and do not reflect those of past, present or future employers, partners or customers”

Page 4: InfoSecurity.be 2011

Today’s Situation

Page 5: InfoSecurity.be 2011

Are You Ready?

• Most organizations are NOT prepared to deal with security incidents

• If anything can go wrong, it will!(Murphy’s law)

• Assigned internal resources?

Page 6: InfoSecurity.be 2011

Technical Issues

• Networks are complex

• Some components/knowledge are outsourced

• Millions of daily events

• Lot of console/tools

• Lot of protocols/applications

Page 7: InfoSecurity.be 2011

Find the Differences

Aug 27 14:33:01 macosx ipfw: 12190 Deny TCP 192.168.13.1:2060 192.168.13.104:5000 in via en1

%PIX-3-313001: Denied ICMP type=11, code=0 from 192.168.30.2 on interface 2

Page 8: InfoSecurity.be 2011

Economic Issues

• “Time is money”

• Real-time operations

• Downtime has a huge financial impact

• Reduced staff & budget

• Happy shareholders

Page 9: InfoSecurity.be 2011

Legal Issues

• Compliance requirements

• Big names

• Initiated by the group or business

• Local laws

• Due diligence & due care

Page 10: InfoSecurity.be 2011

Belgian Example: CBFAFrom a document published in April 2009:

“Tout établ i ssement qui connecte son infrastructure sur Internet dispose d’une politique de sécurité qui tient compte de:...la création, l’archivage de fichier “historique d’évènements” techniques adaptés à leur analyse, leur suivi et leur reporting.”

Page 11: InfoSecurity.be 2011

Challenges

• Creation & archiving of log files

• Analyze (Normalization)

• Follow-up

• Reporting

Page 12: InfoSecurity.be 2011

Layer Approach

Log Collection

Normalization

Storage

Search

Reporting

Correlation

Page 13: InfoSecurity.be 2011

Raw Material

• Your logs are belong to you

• If not stored internally (cloud, outsourcing), claim access to them

• All applications/devices generate events

• Developers, you MUST generate GOOD events

Page 14: InfoSecurity.be 2011

3rd Party Sources

• Vulnerabilities Databases

• Blacklists (IP addresses, ASNs)

• “Physical” Data

• Geolocalization

• Badge readers

Page 15: InfoSecurity.be 2011

The Recipe

Page 16: InfoSecurity.be 2011

Collection

• Push or pull methods

• Use a supported protocols

• Ensure integrity

• As close as the source

Page 17: InfoSecurity.be 2011

Normalization

• Parse events

• Fill in common fields

• Date, Src, Dst, User, Device, Type, Port, ...

Page 18: InfoSecurity.be 2011

Storage

• Index

• Store

• Archive

• Ensure integrity (again)

Page 19: InfoSecurity.be 2011

Search

• You know Google?

• Investigations / Forensic

• Looking for “smoke signals”

Page 20: InfoSecurity.be 2011

Reporting

• Automated / On-demand

• Reliable only if first steps are successfull

Page 21: InfoSecurity.be 2011

Correlation

• Generation of new events based on the way other events occurred (based on their logic, their time or recurrence)

• Correlation will be successful only of the other layers are properly working

• Is a step to incident management

Page 22: InfoSecurity.be 2011

Build Your Toolbox

Page 23: InfoSecurity.be 2011

<warning>Please keep v€ndor$

away from the next slide ;-)</warning>

Page 24: InfoSecurity.be 2011

Let’s Kill Some Myths

• Big players do not always provide the best solutions. A Formula-1 is touchy to drive!

• Why pay $$$ and use <10% of the features? (the “Microsoft Office” effect)

• But even free softwares have costs!

• False sense of security

Page 25: InfoSecurity.be 2011

LM vs. SIEM

• A LM (“Log Management”) addresses the lowest layers from the collection to reporting.

• A SIEM (“Security Information & Event Management”) adds the correlation layer (and incidents management tools)

Page 26: InfoSecurity.be 2011

Grocery Shopping

• Compliance

• Suspicious activity

• Web applications monitoring

• Correlation

• Supported devices

• Buying a SIEM is a very specific project

Page 27: InfoSecurity.be 2011

Free Tools to the Rescue

Page 28: InfoSecurity.be 2011

Syslog Daemons

• Syslog is well implemented

• Lot of forked implementations

• syslogd, rsyslogd, syslog-ng

• Multiple sources

• Supports TLS, TCP

• Several tools exists to export to Syslog (ex: SNARE)

Page 29: InfoSecurity.be 2011

SEC

• “Simple Event Correlation”

• Performs correlation of logs based on Perl regex

• Produces new events, triggers scripts, writes to files

Page 30: InfoSecurity.be 2011

OSSEC• HIDS

• Log collection & parsing

• Active-Response

• Rootkit detection

• File integrity checking

• Agents (UNIX, Windows)

• Log archiving

Page 31: InfoSecurity.be 2011

Miscellaneous

• MySQL

• iptables / ulogd

• GoogleMaps API

• Some Perl code

• Cloud Services (don’t be afraid)

Page 32: InfoSecurity.be 2011

Personal Researches

• Examples based on OSSEC!

• MySQL integrity audit

• USB stick detection in Windows environments

• Detecting rogue access

• Mapping data on Google Maps

Page 33: InfoSecurity.be 2011

Visibility!

• LaaS (Loggly)

• Splunk

• Secviz.org

Page 34: InfoSecurity.be 2011

Example of Visualization

Page 35: InfoSecurity.be 2011

Conclusions• The raw material is already yours!

• The amount of data cannot be reviewed manually.

• Suspicious activity occurs below the radar.

• Stick to your requirements!

• It costs $$$ and HH:MM

• Make your logs more valuable via external sources

Page 36: InfoSecurity.be 2011

Thank You!Q&A?

http://blog.rootshell.behttp://twitter.com/xme