2. INDEX
Threat Detection with Zero-cost
01 Abstract
03 Detection Strategy
02Detection Architecture
04Demo
05 Q&A
3. NUMBERS TELL STORIES:
GLOBAL DWELL TIME
It takes so long to detect
badguys inside your
organization.
FireEye Mandiant M-Trends 2019 Special Report
4. 1. Too many tools, too many solutions
2. Implement everything without a roadmap
3. Collect everything and forgetting about
analysis
4. Forgetting about people
5. Forgetting about security fundamentals
SECURITY COMMON PITFALLS
5. Threat Detection with “Zero-cost”
Will be powerful
Will enable hunters
Will help to spot badguys ASAP
6. Threat Detection with “Zero-cost”
Will not be easy
Will not be a silver bullet
Will not be really Zero-cost
11. Data-gathering
strategies
Input-Driven Strategy Output-Driven Strategy
DEFINITION
• Collecting everything allows for
analysis
PROs
• You have everything
CONs
• Hard for searching, hunting…etc
• Slow and expensive
DEFINITION
• Collecting only what you need
makes deployment and
analysis easier
PROs
• Least expensive approach
• Easier rollout and improved
search performance
CONs
• Likely to miss something you
did not know you needed
Different types of event sources
seem limitless and growing. We
need to know what to collect
and what to analyze.
12. Data Enrichment
Proper log enrichment saves
analysts time and adds detection
capabilities.
• We need data come with context
• Applying log enrichment help to maximize log value:
1. GeoIP lookups
2. DNS lookups
3. Top 1 million websites tagging
4. Threat intelligence feeds
6. Base64 decoding
Ordinary Extraordinary
query: fireoscaptiveportal.com query: fireoscaptiveportal.com
length: 23
reputation: Good
top1m_rank: 5994
domain_freq: 9.0176
country: United States
creation_date: 2017-06-16
destination_ASN: Amazon.com, Inc. (14618)
13. Data Broker
Act as a buffer to handle bursts
in log traffic or outages on
another backend systems.
BEFORE BROKER
This design will FALL
1. Too much EPS
2. Heavy parsing or enrichment crashes the Processor
3. Storage overload cause dropping of inbound log
14. Data Broker
Go broke or go home…
AFTER BROKER
This design will WIN
1. The Collector can handle tons of logs
2. The Processor will only fetch logs from the broker when it is
ready.
3. Whenever the Storage starts to get overloaded, Processor will
hold off all the log until Storage is back to normal state.
15. LOG STORAGE
Storage must be designed to handle:
• Handle large amounts of logs
• Log retention
• Fast search response times.
Ideally is lower then 30 seconds
• Proper classification of log data
17. Sysmon
Free download tools from Windows Sysinternals kit
Run as Windows system service
Having capabilities to monitors so many things:
• Processes
• Registry
• Network connections
• Driver & DLL loading
• Modifications of file
• DNS Query
https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
18. Elastalert
Framework for alerting on anomalies, spikes, or other patterns of interest
from data in Elasticsearch.
Reliable, highly modular, and easy to set up and configure
Several rule types with common monitoring paradigms:
Built-in support for the following alert types:
1. Email
2. JIRA
3. OpsGenie
4. Commands
5. HipChat
6. MS Teams
7. AWS SNS
8. VictorOps
9. PagerDuty
10. PagerTree
11. Exotel
12. Twilio
14. Zabbix
15. Slack
16. Telegram
17. GoogleChat
18. Gitter
19. Line Notify
https://github.com/Yelp/elastalert