Matthias Vallentin - Towards Interactive Network Forensics and Incident Response, Boundary Tech...
-
Upload
boundaryslides -
Category
Technology
-
view
4.632 -
download
0
description
Transcript of Matthias Vallentin - Towards Interactive Network Forensics and Incident Response, Boundary Tech...
Towards Interactive Network Forensics andIncident Response
Matthias VallentinUC Berkeley / ICSI
Boundary Tech TalkSan Francisco, CA
November 17, 2011
Motivation
What do the following activities have in common?I Network troubleshootingI Incident responseI Network forensics
→ Data-intensive analysis of past activity→ Interactive response times often critical
“How to build a platform that efficiently supports these activities?”
2 / 36
Motivation
What do the following activities have in common?I Network troubleshootingI Incident responseI Network forensics
→ Data-intensive analysis of past activity→ Interactive response times often critical
“How to build a platform that efficiently supports these activities?”
2 / 36
Motivation
What do the following activities have in common?I Network troubleshootingI Incident responseI Network forensics
→ Data-intensive analysis of past activity→ Interactive response times often critical
“How to build a platform that efficiently supports these activities?”
2 / 36
Outline
1. Incident Response and Network Forensics
2. Operational Network Monitoring using Bro
3. Building an Interactive Analytics Platform
3 / 36
About
I 4th-year PhD student at UC Berkeley, advised by Vern PaxsonI Working with researchers at ICSI/ICIR and the AMPlabI Interests
I Large-scale network intrusion detectionI High-performance traffic analysisI Network forensics and incident response→ with strong operational emphasis
I ProjectsI The Bro network security monitorI VAST: Visibility Across Space and TimeI HILTI: High-Level Intermediate Language for Traffic Inspection
4 / 36
Outline
1. Incident Response and Network Forensics
2. Operational Network Monitoring using Bro
3. Building an Interactive Analytics Platform
5 / 36
Use Case #1: Classic Incident Response
I Goal: fast and comprehensive analysis of security incidentsI Often begins with an external piece of intelligence
I “IP X serves malware over HTTP”I “This MD5 hash is malware”I “Connections to 128.11.5.0/27 at port 42000 are malicious”
I Analysis style: Ad-hoc, interactive, several refinements/adaptionsI Typical operations
I Filter: project, selectI Aggregate: mean, sum, quantile, min/max, histogram, top-k,
unique
⇒ Concrete starting point, then widen scope (bottom-up)
6 / 36
Use Case #2: Network Troubleshooting
I Goal: find root cause of component failureI Often no specific hint, merely symptomatic feedback
I “I can’t access my Gmail”I Typical operations
I Zoom: slice activity at different granularitiesI Time: seconds, minutes, days, . . .I Space: layer 2/3/4/7, host, subnet, port, URL, . . .
I Study time series data of activity aggregatesI Find abnormal activity
I “Today we see 20% less outbound DNS compared to yesterday”I Infer dependency graphs: use joint behavior from past to asses present
impact [KMV+09]I Judicious machine learning [SP10]
⇒ No concrete starting point, narrow scope (top-down)
7 / 36
Use Case #3: Combating Insider Abuse
I Goal: uncover policy violations of personnelI Analysis procedure: connect the dotsI Insider attack:
I Chain of authorized actions, hard to detect individuallyI E.g., data exfiltration
1. User logs in to internal machine2. Copies sensitive document to local machine3. Sends document to third party via email
I Typical operationsI Compare activity profiles
I “Jon never logs in to our backup machine at 3am”I “Seth accessed 10x more files on our servers today”
⇒ Relate temporally distant events, behavior-based detection
8 / 36
Outline
1. Incident Response and Network Forensics
2. Operational Network Monitoring using Bro
3. Building an Interactive Analytics Platform
9 / 36
Basic Network Monitoring
Internet Local NetworkTap
Monitor
I SitesI UC Berkeley (10 Gbps, 50,000 hosts)I NCSA, IL (8×10 Gbps, 10,000 hosts)I LBNL, Berkeley (10 Gbps, 12,000 hosts)I ICSI, Berkeley (100 Mbps, 250 hosts)I AirJaldi, India (10 Mbps, 500 hosts)
10 / 36
High-Performance Network Monitoring:The NIDS Cluster [VSL+07]
Internet Local NetworkTap
Frontend
Manager
PacketsLogsState
Proxy
......Worker Worker Worker
User
11 / 36
The Bro Cluster
I We run it operationally at:I UC Berkeley (26 workers)I LBNL (15 workers)I NCSA (10 4-core workers)
I Runs at numerous large sites:I IndustryI AcademiaI Government
Internet Local NetworkTap
Worker
Frontend
Worker Worker
Proxy
Worker Worker Worker
Manager
Proxy
...
Proxy
...
PacketsLogsState
12 / 36
The Bro Network Security Monitor
I Fundamentally different from other IDSI Real-time network analysis frameworkI Policy-neutral at the coreI Highly stateful
Key components1. Event engine
I TCP stream reassemblyI Protocol analysisI Policy-neutral
2. Script interpreterI “Domain-specific Python”I Generate extensive logsI Apply site policy
User Interface
Network
Event Engine
Script Interpreter
Packets
Events
Logs Notifications
13 / 36
From Packets to High-Level Descriptions of Activity
Event declaration
type connection: record { orig: addr, resp: addr, ... }
event connection_established(c: connection)event http_request(c: connection, method: string, URI: string)event http_reply(c: connection, status: string, data: string)
Event instantiation
connection_established({127.0.0.1, 128.32.244.172, ... })http_request({127.0.0.1, 128.32.244.172, ..}, "GET", "/index.html")http_reply({127.0.0.1, 128.32.244.172, ..}, "200", "<!DOCTYPE ht..")http_request({127.0.0.1, 128.32.244.172, ..}, "GET", "/favicon.ico")http_reply({127.0.0.1, 128.32.244.172, ..}, "200", "\xBE\xEF\x..")connection_established({127.0.0.1, 128.32.112.224, ... })
14 / 36
From Packets to High-Level Descriptions of Activity
Event declaration
type connection: record { orig: addr, resp: addr, ... }
event connection_established(c: connection)event http_request(c: connection, method: string, URI: string)event http_reply(c: connection, status: string, data: string)
Event instantiation
connection_established({127.0.0.1, 128.32.244.172, ... })http_request({127.0.0.1, 128.32.244.172, ..}, "GET", "/index.html")http_reply({127.0.0.1, 128.32.244.172, ..}, "200", "<!DOCTYPE ht..")http_request({127.0.0.1, 128.32.244.172, ..}, "GET", "/favicon.ico")http_reply({127.0.0.1, 128.32.244.172, ..}, "200", "\xBE\xEF\x..")connection_established({127.0.0.1, 128.32.112.224, ... })
14 / 36
Event Extraction with BroEvent and data model
I Rich-typed: first-class networking types (addr, port, subnet, . . . )I Deep: across the whole network stackI Fine-grained: detailed protocol-level informationI Expressive: nested data with container types (aka. semi-structured)
Transport
(Inter)Network
ApplicationMessages
Byte stream
Packets
LinkFrames
http_request, smtp_reply, ssl_certificate
new_connection, udp_request
new_packet, packet_contents
arp_request, arp_reply
15 / 36
After the Fact: Bro LogsI Policy-neutral by default: no notion of good or bad
I Forensic investigations highly benefit from unbiased informationI Flexible output formats: ASCII, binary, DB, custom
% more conn.log#fields ts id.orig_h id.orig_p id.resp_h id.resp_p proto service duration obytes ..1144876741.1198 192.150.186.169 53115 82.94.237.218 80 tcp http 16.14929 4351144876612.6063 192.150.186.169 53090 198.189.255.82 80 tcp http 4.437460 86611144876596.5597 192.150.186.169 53051 193.203.227.129 80 tcp http 0.372440 4611144876606.7789 192.150.186.169 53082 198.189.255.73 80 tcp http 0.597711 3371144876741.4693 192.150.186.169 53116 82.94.237.218 80 tcp http 16.02667 30271144876745.6102 192.150.186.169 53117 66.102.7.99 80 tcp http 1.004346 4221144876605.6847 192.150.186.169 53075 207.151.118.143 80 tcp http 0.029663 347
% more http.log#fields ts id.orig_h id.orig_p host uri status_code user_agent ..1144876741.6335 192.150.186.169 53116 docs.python.org /lib/lib.css 200 Mozilla/5.01144876742.1687 192.150.186.169 53116 docs.python.org /icons/previous.png 304 Mozilla/5.01144876741.2838 192.150.186.169 53115 docs.python.org /lib/lib.html 200 Mozilla/5.01144876742.3337 192.150.186.169 53116 docs.python.org /icons/up.png 304 Mozilla/5.01144876742.3337 192.150.186.169 53116 docs.python.org /icons/next.png 304 Mozilla/5.01144876742.3337 192.150.186.169 53116 docs.python.org /icons/contents.png 304 Mozilla/5.01144876742.3337 192.150.186.169 53116 docs.python.org /icons/modules.png 304 Mozilla/5.01144876742.3338 192.150.186.169 53116 docs.python.org /icons/index.png 304 Mozilla/5.01144876745.6144 192.150.186.169 53117 www.google.com / 200 Mozilla/5.0
16 / 36
After the Fact: Bro Logs
17 / 36
Log Analysis
I What do we do with Bro logs?I Process (ad-hoc analysis)I Summarize (time series data, histogram/top-k, quantile)I Correlate (machine learning, statistical tests)I Age (elevate old data into higher levels of abstraction)I Visualize
I How do we do it?I All eggs in one basket
I SIEM: Splunk, ArcSight, NarusInsight, . . . $$$I VAST
I In-situ processingI Tools of the trade (awk, sort, uniq, . . . )I MapReduce / Hadoop
18 / 36
Log Analysis
I What do we do with Bro logs?I Process (ad-hoc analysis)I Summarize (time series data, histogram/top-k, quantile)I Correlate (machine learning, statistical tests)I Age (elevate old data into higher levels of abstraction)I Visualize
I How do we do it?I All eggs in one basket
I SIEM: Splunk, ArcSight, NarusInsight, . . . $$$I VAST
I In-situ processingI Tools of the trade (awk, sort, uniq, . . . )I MapReduce / Hadoop
18 / 36
Outline
1. Incident Response and Network Forensics
2. Operational Network Monitoring using Bro
3. Building an Interactive Analytics Platform
19 / 36
From Ephemeral to Persistent Activity
I Bro eventsI Policy-neutral activityI EphemeralI Only inside the Bro process→ Can I haz access?
I BroccoliI Send/Receive Bro eventsI Written in CI Language bindings
I RubyI PythonI Perl
→ Send-them-while-they-are-hot
User Interface
Network
Event Engine
Script Interpreter
Packets
Events
Logs Notifications
3rd-party Application
BroccoliEvents
Com
m
(Broccoli = Bro client communications library)
20 / 36
From Ephemeral to Persistent Activity
Events
Events
Apache
Broccoli
OpenSSH
Broccoli
Events
User
Query
Result
Query Result
Bro
21 / 36
Today’s Open-Source Solutions for Analytics
22 / 36
Caveats in Real-Time Analytics
1. Getting poor performanceI Batch processing (MapReduce)I Architectural flaws (inflexible MQ)I Bloated runtime (Java)
2. Losing domain-specific contextI TypingI NestingI Causality
“Can we do better?”
23 / 36
Inspiration
1. DremelI Columnar storageI Nested data model
2. BigtableI Sharding: distributed tablets
3. GFSI Single master with meta dataI Locate chunks via master
4. SawzallI Aggregators: collection, sample, sum, maximum, quantile, top-k,
unique
5. FastBitI Bitmap indexes “work” for high-cardinality attributes
24 / 36
Design Philosophy Touch Stones [Lam11]Storage
I Keep data sorted → reduce seeks, easy random entryI Shard with access locality → minimize involved nodesI Store data in columns → don’t waste I/OI Use append-only disk format → avoid expensive index updates
ComputeI Use disk appropriately → large sequential readsI Trade CPU for I/O → type-specific, aggressive compressionI Use pipelined parallelism → hide latencyI Ship compute to data → aggregation serving tree
QueryI Make it user-friendly → declarative query interfaceI Provide query hooks → support complex analysis
25 / 36
Design Philosophy Touch Stones [Lam11]Storage
I Keep data sorted → reduce seeks, easy random entryI Shard with access locality → minimize involved nodesI Store data in columns → don’t waste I/OI Use append-only disk format → avoid expensive index updates
ComputeI Use disk appropriately → large sequential readsI Trade CPU for I/O → type-specific, aggressive compressionI Use pipelined parallelism → hide latencyI Ship compute to data → aggregation serving tree
QueryI Make it user-friendly → declarative query interfaceI Provide query hooks → support complex analysis
25 / 36
Design Philosophy Touch Stones [Lam11]Storage
I Keep data sorted → reduce seeks, easy random entryI Shard with access locality → minimize involved nodesI Store data in columns → don’t waste I/OI Use append-only disk format → avoid expensive index updates
ComputeI Use disk appropriately → large sequential readsI Trade CPU for I/O → type-specific, aggressive compressionI Use pipelined parallelism → hide latencyI Ship compute to data → aggregation serving tree
QueryI Make it user-friendly → declarative query interfaceI Provide query hooks → support complex analysis
25 / 36
VAST: Visibility Across Space and Time
I VisibilityI Deep understanding of the dataI Visualization: you know how to do that already. . .
I Across space:I Unify heterogeneous data formatsI One query language
I Apache logs, SSH logs, Bro events, sensor data, . . .I Across time:
1. From the ancient past (old historical data)2. To subscribing to data that may arrive in the future
26 / 36
Queries
I Two types1. Search: historical query2. Feed: live query→ use case: crawl archive first, then make query permanent
I Unify two ends of a spectrumLive Historical
Operation Push PullLatency O(|Xresult|) O(|Xdata|)Data location In-memory Disk (ideally cached)Flexibility Predefined Ad-hoc, adjustableCost Pay-As-You-Go Lumpsum
27 / 36
VAST: Architecture Overview
I Distributed architectureI Elasticity via MQ middle layerI Few component dependencies
I DFS: fault-tolerance, replicationI Archive: key-value store
I Contains serialized eventsI Index: sharded column-store
I Compressed bitmap indexesI In-memory store
I Caches tablets (LRU)I Flushes in batches
Archive
Index
DFS
Store
Ingest Query
28 / 36
VAST: Ingestion Architecture
1. Events arrive at Event Router1.1 Assign UUID x1.2 Put (x, event) in archive1.3 Forward event to Indexer
2. Indexer writes event into tabletand updates indexes
3. Tablet Manager flushes “ripe”tablets
I Capacity (space/rows)I Lifetime
Store
EventRouter
Tablets
Tablet Manager
Indexer
flush
ripe?
Index
DFS
put
Tablets
write
Archive
29 / 36
VAST: Query Architecture
1. User or NIDS issues query2. Query Manager distributes it
to relevant nodes3. Tablet Manager load tablets4. Query Proxy hits index
a Returns direct resultb Returns set of UUIDs
Store
Query Manager
Tablets
Tablet Manager
QueryProxy
flush
LRU
Index
DFS
get
Tablets
query
Archive load
30 / 36
Bitmap Indexes
I Column cardinality: # distinct valuesI One bitmap bi for each value i
I Sparse, but compressibleI WAH [WOSN01]I COMPAX [FSV10]I Consice [CDP10]
I Can operate on compressed bitmapsI No need to decompress
2
1
2
0
0
1
3
0
0
0
1
1
0
0
0
1
0
0
0
1
0
1
0
1
0
0
0
0
0
0
0
0
0
0
1
b1 b2 b3b0
Data Bitmap Index
31 / 36
Conclusion
1. Motivation: incident response, network troubleshooting, insider abuse2. The Bro network security monitor
I High-performance network monitoringI Expressive representation of activityI Publish/subscribe event model
3. Design sketch of a distributed analytics platform
32 / 36
Questions?
33 / 36
References I
A. Colantonio and R. Di Pietro.Concise: Compressed ’n’ Composable Integer Set.Information Processing Letters, 110(16):644–650, 2010.
Francesco Fusco, Marc Ph. Stoecklin, and Michail Vlachos.NET-FLi: On-the-fly Compression, Archiving and Indexing ofStreaming Network Traffic.Proceedings of the VLDB Endowment, 3:1382–1393, September 2010.
Srikanth Kandula, Ratul Mahajan, Patrick Verkaik, Sharad Agarwal,Jitendra Padhye, and Paramvir Bahl.Detailed Diagnosis in Enterprise Networks.In Proceedings of the ACM SIGCOMM 2009 Conference on DataCommunication, SIGCOMM ’09, pages 243–254, New York, NY, USA,2009. ACM.
34 / 36
References II
Andrew Lamb.Building Blocks for Large Analytic Systems.In 5th Extremely Large Databases Conference, XLDB ’11, Menlo Park,California, October 2011.
Robin Sommer and Vern Paxson.Outside the Closed World: On Using Machine Learning for NetworkIntrusion Detection.In Proceedings of the 2010 IEEE Symposium on Security and Privacy,SP ’10, pages 305–316, Washington, DC, USA, 2010. IEEE ComputerSociety.
35 / 36
References III
Matthias Vallentin, Robin Sommer, Jason Lee, Craig Leres, VernPaxson, and Brian Tierney.The NIDS Cluster: Scalably Stateful Network Intrusion Detection onCommodity Hardware.In Proceedings of the 10th International Conference on RecentAdvances in Intrusion Detection, RAID’07, pages 107–126.Springer-Verlag, September 2007.
Kesheng Wu, Ekow J. Otoo, Arie Shoshani, and Henrik Nordberg.Notes on Design and Implementation of Compressed Bit Vectors.Technical Report LBNL-3161, Lawrence Berkeley National Laboratory,Berkeley, CA, USA, 94720, 2001.
36 / 36