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