Detecte ameaças e evite falsos positivos com o mecanismo de detecção no Elastic Security. Automatize a detecção de ameaças por meio de correlações e machine learning com exemplos do reais.

1. 1
ElasticON Security
Luiz Santos
Support Engineer
Automate Threat Detection

2. Agenda
Automated Threat Detection
Recapping the Data Dilemma1
Elastic Prebuilt Protections3
Detection Philosophy4
An Open Detection Repo5
The Detection Engine2

3. 5 1B 5
Data Domains
Practitioners analyze
hosts, cloud, network
devices, application
performance, user,
and more!
Events Per Day
Most organizations
average 1 billion
events per day
SOC Analysts
Security Operation
Centers vary in size,
but most have less
than 5 analysts
THE DATA DILEMMA

4. The Elastic Agent Of Course!

5. 5
Get Data
Protect My Org

6. Agenda
Automated Threat Detection
Recapping the Data Dilemma
Using Elastic Prebuilt Protections3
Detection Philosophy4
An Open Detection Repo5
The Detection Engine
1
2

7. Detection Engine
It’s as simple as search.
• Speed and scale of Elasticsearch to
detect known and unknown threats
• Easily automate threat detection
using queries (KQL/DSL, machine
learning, thresholds, and more!
• 200 free protections;
built in the open

8. 8
DEMO #1
Detection Engine

9. Agenda
Automated Threat Detection
Recapping the Data Dilemma
Elastic Prebuilt Protections3
Detection Philosophy4
An Open Detection Repo5
The Detection Engine
1
2

10. 200 Free Rules. Built in the Open
attack.mitre.org

11. Prebuilt Protections
By Data Domain
55%
Windows, Linux, MacOS

12. MITRE ATT&CK™ Knowledge Base
attack.mitre.org

13. Prebuilt Protections
Threat Detection and SecOps
27%
Defense Evasion

14. 14
DEMO #2
Rule Metadata

15. ...but my data is special...
<random security professional>

16. 16
DEMO #3
Rule Editing and Exceptions

17. 17
Get Data
Protect My Org

18. Agenda
Automated Threat Detection
Data Dilemma
Elastic Prebuilt Protections3
Detection Philosophy4
An Open Detection Repo5
The Detection Engine
1
2

19. Our Approach to Detection Engineering
github.com/elastic/detection-rules/.../PHILOSOPHY.md
● Shaped by our collective real-world experience
● Focus on behaviors more than custom tools
● Write logic independent from the data source
● Detect true positives while avoiding false positives

20. Behaviors vs Indicators
● Emphasize technique, not indicators
○ Forces you to write generic detections
○ Avoids the risk of overfitting
○ Similar philosophy to MITRE ATT&CK®
● Make exceptions where it makes sense
○ When a high-fidelity behavioral detection is nontrivial
https://attack.mitre.org/docs/ATTACK_Design_and_Philosophy_March_2020.pdf
github.com/elastic/detection-rules/.../PHILOSOPHY.md

21. Detect Behaviors, not the Tool
✖ Indicator ✔ Behavior
process.name:mimikatz.exe or
process.command_line:*sekurlsa*
event.module:sysmon and
event.code:10 and
winlog.event_data.TargetImage:
lsass.exe
github.com/elastic/detection-rules/.../PHILOSOPHY.md

22. Using Elastic Common Schema (ECS
github.com/elastic/ecs
● Defines a common set of field names and types
● Enumerates categorization fields and values to bin
similar events together
● Designed to be extensible and grow with our needs
● ECS is adopted throughout the Elastic Stack

23. Write Logic Independent of Data Sources
✖ Specific to each source ✔ With standard ECS field
src:10.42.42.42 or
client_ip:10.42.42.42 or
apache2.access.remote_ip:
10.42.42.42 or
context.user.ip:10.42.42.42
source.ip:10.42.42.42
github.com/elastic/detection-rules/.../PHILOSOPHY.md

24. Detect True Positives and avoid False Positives
● Create or Modify System Process: Windows Service
○ ATT&CK technique T1543 subtechnique 003
● System Services: Service Execution
○ ATT&CK technique T1569, subtechnique 002
github.com/elastic/detection-rules/.../PHILOSOPHY.md

25. ✖ Too vague ✖ Too many false
positives
process.name:sc.exe process.name:sc.exe and
process.args:(create or config)
Detect True Positives and avoid False Positives
github.com/elastic/detection-rules/.../PHILOSOPHY.md

26. ✖ Too easy to evade ✖ Too easy to evade
process.command_line:
"sc *create * binPath*"
process.name:sc.exe and
process.command_line:
"* create * binPath*"
Detect True Positives and avoid False Positives
github.com/elastic/detection-rules/.../PHILOSOPHY.md

27. ✖ Too overfitted ✔ Good FP and TP
balance
process.name:sc.exe and
process.args:(create or config)
and process.parent.name:cmd.exe
process.name:sc.exe and
process.args:(create or config)
and (process.args:* or
not user.name:SYSTEM)
https://github.com/elastic/detection-rules/issues/47
Detect True Positives and avoid False Positives
github.com/elastic/detection-rules/.../PHILOSOPHY.md

28. ✔ Good FP and TP
balance
process.name:sc.exe and
process.args:(create or config)
and (process.args:* or
not user.name:SYSTEM)
Use command line
arguments to infer
adversary intent
Lateral movement
Privilege escalation
Detect True Positives and avoid False Positives
github.com/elastic/detection-rules/.../PHILOSOPHY.md

29. Agenda
Automated Threat Detection
Data Dilemma
Elastic Prebuilt Protections3
Detection Philosophy4
An Open Detection Repo5
The Detection Engine
1
2

30. A Public Repo! github.com/elastic/detection-rules
Community & Collaboration
• A dev-first mentality for
malicious behavior detection
The Rules
• A place to engage on rules for all
users of Elastic Security
Contribution Guides
• Creating issues, submitting PRs,
our philosophy, and more!
Developer Tools
• Interactive CLI to create rules
• Syntax validation, ECS schemas,
metadata checker, etc.