targeted soc use cases for effective incident detection and response … · targeted soc use cases...
Post on 01-Aug-2018
223 Views
Preview:
TRANSCRIPT
Targeted SOC Use Cases for Effective Incident Detection and Response
SANS DFIR SUMMIT PRAGUE 2016
David Gray
Senior Consultant - GCIA, GCIH, GREM, GCFE
Angelo Perniola
Advisory Consultant - GCFA
RSA Advanced Cyber Defense Practice EMEA
TODAY’S TOPICS
• Framework to create a “complete” SOC[*] Use Case
• Methodology to create a custom Use Case library
[*] “SOC” is intended as “Incident Detection and Response Program”
2
WHAT IS A SOC USE CASE?
• Use Cases came from Software Development but were adopted with
the “rise of the SIEM’s” (Next Terminator Movie Title!).
• Specific condition or event (usually related to a specific threat) to be
detected or reported by the security tool” (Gartner, How to Develop and Maintain Security
Monitoring Use Cases, 2016)
• “Methodology used by the SOC team to identify and organize
technical and organizational requirements for detection and
response to specific threats”
3
THE FRAMEWORK
USE CASE FRAMEWORK AT A GLANCE
5
Objective Threat Stakeholders Data Reqs. Logic Testing Priority Output
OBJECTIVE
• Why we need the Use Case and what we want to accomplish
• “To enable ACME Industries SOC staff to detect and respond in a constant
manner to Administrator logins during unexpected times, or from
unexpected sites/workstations and login activities for accounts listed in
specific ACME watch lists including attempted logons by disabled and
decommissioned accounts.”
6
• This is the high level information that Managers require to give them an
overview of all their detection capabilities (when a complete Library is
created)
• Improves Effectiveness of SOC by targeting resources
THREAT
• What we want to Defend against
• Should identify some scenarios we are looking to detect:
• “Administrative and Privileged accounts are one of the primary targets for
internal and external attackers. The elevated permissions of these accounts
allow the attacker to perform a broad range of actions including gaining access
to sensitive information, modifying system settings, deleting log data and
gaining persistence on a network via creating new user accounts, changing
passwords and traversing the network. Suspicious logins should be monitored
to detect suspicious logons and attempted logons of privileged accounts.”
• Gives background to why the Use Case has been created
7
STAKEHOLDERS
• Stakeholders are not necessarily the owners of the
Use Case
• They are analysts involved in detecting threats and
responding to incidents
• Any external parties should be incorporated
• IT OPS, HR, Internal Security
• Law Enforcement Contacts
• MSSP’s
8
L1/L2 Analyst
SOC
Manager/
CISO
Incident
Coordinator
DATA REQUIREMENTS
• The raw Log/Packet/Flow/Endpoint Data sources that are required to
be able to detect our Threat
• High level and Low level listing of requirements
• Consultation with local Platform Engineering Team is key
• External feeds should be incorporated:
• Threat Intel (e.g. RSA Live, Open Source/Commercial …)
• Context (CMDB, VIP list, change requests, Watchlists, …)
9
LOGIC
• How we are going to detect our malicious behaviour
• This can be a high level overview (Management View)
• “UC-001-001 - Admin Credential Abuse – Suspicious Admin
logon out of working hours Threat can be detected via alerting
to the successful logon of Admin accounts outside of documented
business hours, if multiple domains exist for separate regional
users, multiple rules may be created to account for each region.”
• However that sentence is going to be a bit tricky to parse isn't
it ?????
10
LOGIC [CONT.]
• Low Level Example (technology dependant):
11
@RSAAlert(oneInSeconds=0)
SELECT * FROM Event(
(device_type ='winevent_nic' AND reference_id IN ('4624','4672', '528' ) AND (
'admin_user' = ANY(alert_id )) AND (user_dst NOT IN ('_srvXXX_AAA_PER',
'_srvXXX_MSXX')) )
AND
( (esa_time).getDayOfWeek IN (2,3,4,5,6) AND (esa_time).getHourOfDay
NOT IN (5,6,7,8,9,10,11,12,13,14,15,16)
OR
(esa_time).getDayOfWeek IN (0,1))
);
TESTING
• How we know the Logic will produce a (reliable) alert
• Key to validating the Content Rules
“Suspicious Admin logon out of working hours Logon to any account from
the admin watchlist outside of the agreed unusual working hours parameter
(ie after 6pm)”
• Should be tested first in a QA environment before being tested on a
live network (with benign traffic)
• Results should be fed back into the Logic to ensure the greatest
degree of confidence is achieved
12
PRIORITY
• Provides guidance to SOC Analysts
• “During Triage by the L1 Analysts, the Priority for Admin Account
compromises should be set to “P2”. Post Triage, the Priority should be set
according to the Priority Selection Matrix.”
• Dependent upon policies and business requirements
• Any changes to Priority as a result of asset value should be
considered
• i.e. An Incident involving an Active Directory Server would have a higher
Priority than that of a User’s workstation
13
OUTPUT
• Reports
• Dashboards
• Incident Response Procedures
• “Failure to prepare is preparing to fail” Benjamin Franklin
• Gives clear guidance to analysts as to what they are looking for and what their next steps are
• Tasks
• Data to be collected
• Escalation and Decision points
14
WORKFLOW/PROCEDURAL STEPS
15
SUMMARY – THE BIG PICTURE
16
Objective Threat Stakeholder Data Req. Logic Testing Priority Output
Purpose and
goal of the
procedure
The threat
which the logic
seeks to
identify
Those with
responsibility
relating to the
procedure
Detection Info.
sources e.g.
logs, packets,
host
configuration,
CTI, etc.
Content rules
and filters, etc.
to process data
and identify
threat
Logic validation
process to
confirm that it
addresses the
risk
Classification
category and
level for the
threat based
on impact and
urgency
Workflow when
responding to
the threat
Monitor and
alert on
unusual Admin
Account
Access
Attacker Lateral
Movement and
use of Admin
accounts
L1, L2 Analysts
Incident
Coordinator,
ITOPS
Microsoft Domain
Controller,
Windows Server
(various)
Reporting Engine;
NetWitness ESA
Rules
Conduct Test
with Admin
account out of
hours
DMZ: P2
DC: P1
Procedure to be
followed when
Unusual Admin
Account access
is detected
Use Case Elements
Element Descriptions
Example: Admin Credential Abuse
THE LIBRARY
BEFORE WE START
“A good engineering result depends on
knowing know what problem we’re
trying to solve” (Geer D.,The Problem Statement is the Problem, 2005)
BEFORE WE START
“What is the mission of our SOC and
how can this mission be accomplished
in an effective way?”
WHY A THREAT CENTRIC APPROACH
(https://memegenerator.net/)
WHY A THREAT CENTRIC APPROACH
“Adversary modeling – abstract representations of adversary
behavior and characteristics – is central to developing and
analyzing hypotheses or claims about the effects of
technologies, architectural decisions, and/or defender
actions on the cyber adversary”
(MITRE - Characterizing Effects on the Cyber Adversary, 2013)
DEFENDER'S OBJECTIVES
Possible Effects of Cyber Defender Activities and/or Investments on
Adversary Activities:
Defender Goal Definition Effect Evidence
Detect
Identify adversary activities or their effects by discovering or discerning the fact that an adversary activity is occurring, has occurred, or (based on indicators, warnings, and precursor activities) is about to occur
The adversary’s activities become susceptible to defensive responses
Adversary activities are detected, or indicators, warnings, and/or precursor activities are observed
Redirect Obviate Impede Detect Limit Expose
Deter Prevent Degrade Contain Recover Analyze
Divert Preempt Delay Curtail Expunge Publicize
Deceive
Adversary activities are detected, or indicators, warnings, and/or precursor activities are observed
(MITRE - Characterizing Effects on the Cyber Adversary, 2013)
CUSTOMERS’ PAIN POINTS
• Inherited Use Cases
• “We have always done it that way”
• Reliance on OOTB vendors’ rulesets only
• “The more the better!”
• Lack of prioritization
• “Alert fatigue? What’s alert fatigue?”
• Inefficient use of data sources
• “Sorry, no proxy logs …”
• No correlation between detection and response
• “We found them, now what?”
PROPOSED APPROACH
• Threat identification as an input
• From Stakeholders (Business Owners, Risk Mgt, Sec/Net/SW Architects, etc.)
• From SOC (Mgmt, Analysts, Threat Intel team)
• Identify attack vectors and TTPs to build Attack Scenarios
• Use Attack Scenarios to identify Threat Indicators
• Map Threat Indicators against needed data sources and identify
exploitable Detection Logic
• Map Detection Logic against IRP’s
ATTACK SCENARIOS
• Threat Actor actions (knowledge of TTP’s is required, used to
determine observables)
• Available countermeasures against the Threat Actor actions (data
sources, defense in depth, defensive CoA)
• Applicable Use Case (to detect Threat Actor actions)
• Threat Actor Action
• Forcing User to Targeted Drive by Download
• Data sources
• Mail, Proxy, DPI, IDS/IPS
• Applicable Use Cases
• Suspicious file type download (executable, DLL, archive file, …)
• Suspicious mail headers (Intel based)
• Mismatched HREF attribute
EXAMPLE
Reconnaissance Weaponize Delivery Exploitation Installation C2 Action
EXAMPLE
Reconnaissance Weaponize Delivery Exploitation Installation C2 Action
• Threat Actor Action
• RDP Lateral movement
• Data sources
• Win, DPI
• Applicable Use Cases
• Chained RDP connections
• RDP with unusual charset
• Multiple RDP from same host in short time
THREAT INDICATORS
• Directly derived from Threat Actor actions drawn in the AS
• Linked to observables within organization systems (logs, files, network
sessions, etc.)
• Support both the logic and the data sources requirements in a UC
• Sources:
• Known Knowns (IOC’s)
• Known Unknowns (Threat Intel)
• Unknown Unknowns (Incident Analysis)
https://en.wikipedia.org/wiki/Donald_Rumsfeld
MUST READ
MITRE ATT&CK
• “Model and framework for describing the actions an adversary may take while operating within an enterprise network”
• Knowledge base of threat actors behavior
• Ten common tactics in which techniques can be applied
• Provides Examples, Mitigation, and Detection advice for each technique
• Note: Focus on post exploitation and Windows ecosystem
https://attack.mitre.org/
DETECTION LOGIC The art of the possible:
• What detection capabilities are available and what can be achieved if additional ones become available
• Use Case 4: internal user accessing malicious site
• IDS, DNS, Proxy, Packets, and Firewalls are capable of detecting this and available to the SOC team
• Use Case 3: suspicious VPN connection
• DCHP, VPN logs are not available to the SOC team
• Management gets clear picture of possible enhancements in the detection capability (prioritization)
IDS DNS Proxy DHCP VPN Packets Wifi Firewall Email Windows Antivirus
Use Case1 Yes Yes Yes Yes Yes
Use Case2 Yes Yes Yes Yes Yes Yes Yes
Use Case3 Yes Yes Yes Yes Yes Yes Yes
Use Case4 Yes Yes Yes Yes Yes Yes
IDS DNS Proxy DHCP VPN Packets Wifi Firewall Email Windows Antivirus
Use Case1 Yes Yes Yes Yes Yes
Use Case2 Yes Yes Yes Yes Yes Yes Yes
Use Case3 Yes Yes Yes Yes Yes Yes Yes
Use Case4 Yes Yes Yes Yes Yes Yes
IDS DNS Proxy DHCP VPN Packets Wifi Firewall Email Windows Antivirus
Use Case1 Yes Yes Yes Yes Yes
Use Case2 Yes Yes Yes Yes Yes Yes Yes
Use Case3 Yes Yes
Use Case4 Yes Yes Yes Yes Yes Yes
INCIDENT RESPONSE PROCEDURES (IRP’S) • There must be commonality in key areas areas:
• Triage
• Closure
• All other areas of the IRP should be targeted against the specific
threat
• Attention should be paid to ensure that there is no conflict with existing
IRP’s within the Use Case Library (KISS)
• Ideally the IRP should be mapped to a data feed for automation
• Threat (e.g. VERIS Action category.variety)
• Custom Data Feed (e.g. SIEM Rule Name)
USE CASE LIBRARY
Taxonomy should reflect
SOC goals:
• Threat
• KC phase
• Data source
• Impacted Business
Line
• Output
• …
WRAP UP
BENEFITS OF A SOC USE CASE FRAMEWORK
• End to End Capability
• All building blocks in one place
• Puts together Detection AND Response
• Adaptable to different platforms (SIEM and IMS)
• Only low level logic must be converted
• Use Cases selection is based on the organization’s needs
• Tailored detection and response
34
CONCLUSIONS
• We can’t detect everything
• Even if we could, we would not be able to respond to
everything anyway
• Therefore we must prioritize making our detection
targeted
• A Use Case library, built upon the organization’s threat
model, helps in making detection targeted against the
most relevant threats
Thank You david.gray@rsa.com @D4VID_GRAY
angelo.perniola@rsa.com @AngeloPerniola
top related