A Use Case Framework for

Intelligence Driven Security

Operations Centers
David Gray, @D4VID_GRAY

Angelo Perniola, @AngeloPerniola

So whats a Use Case?
Audience Participation:1
Session: 1849

Q: Have you heard of Use Cases before this

Presentation?
Yes
No
Yes and have deployed within a SOC

Results
What we will talk about
Context background and history
Our solution - Use Case Framework
Granular walkthrough of each step
The benefits
From huuu?!? to yeah!!!
 Whoami
Angelo Perniola, Sr. RSA ACD Consultant
10 years of Information Security
Ex Italian Army Officer; in love with basketball, triathlon
and infosecurity
David Gray, Practice RSA ACD Consultant
8 years of Information Security
Ex Royal Air Force Malware Team Leader
The work presented today is based on field
experiences of the whole RSA ACD team
Context
Use Case Framework at a glance

Data
Objective Threat Stakeholders Logic Testing Priority Output
Reqs.
Use Cases 1.0 (or 0.1-beta )

End to End solution framework

More Granularity
Incorporates all information required to Create,
Monitor and Test a Use Case (not only
alerts/reports!!!)
Puts together Detection AND Response
Able to reflect the detection logic from different
technologies/vendors
Objective
Why we need the Use Case and what
we want to accomplish
Along with Threat, this is of major
importance to a Manager
Improves Effectiveness of SOC by
targeting resources
Threat
What we want to Defend against
Should identify some scenarios we
are looking to detect
Give background to why the Use
Case has been created
Stakeholders
SOC
Stakeholders are not necessarily the owners Manager/
CISO
of the Use Case
They are analysts involved in detecting
threats and responding to incidents
Incident
Any external parties should be incorporated Coordinator
IT OPS
Law Enforcement Contacts
MSSPs
L1/L2
Analyst
Data Requirements
The raw Log/Packet/Flow/Endpoint Data sources that
are required to be able to detect our Threat
Consultation with local Content Team is key
External feeds should be incorporated:
Threat Intel (e.g. RSA Live, Open Source/Commercial )
Context (CMDB, VIP list, change requests, )
Logic
How we are going to detect our malicious
behaviour
This can be a high level overview
More value comes from being as specific as possible
Logic [cont.]
Example (high level):
Example (technology dependant):
@RSAAlert(oneInSeconds=0)
SELECT * FROM Event(service = 21 OR service = 80 AND ip_src NOT IN (SELECT ip_src from
AuthorizedIPs)).win:time(10 minutes)
MATCH_RECOGNIZE (
MEASURES U as u, D as d
PATTERN (U D)
DEFINE
U as U.service = 21 AND 'put' = any (U.action),
D as D.service = 80 AND 'get' = any (D.action)
);
Testing
How we know the Logic will produce a
(reliable) alert
Key to validating the Content Rules
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
Priority
Provides guidance to SOC Analysts
Dependent upon policies and business
requirements
Any changes to Priority as a result of asset
value should be considered
i.e An Active Directory Server would have a higher
priority than that of a Users workstation
Output
Reports
Dashboards
Incident Response Procedures
Failure to prepare is preparing to fail
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
Workflow/Procedural Steps
Summary The Big Picture
Use Case Elements
Data
Objective Threat Stakeholder Logic Testing Priority Output
Requirement

Element Descriptions
Detection Content rules Logic Classification
Those with Output of
The threat Info. sources and filters, validation category and
Purpose and responsibility Use Case. In
which the e.g. logs, etc. to process to level for the
goal of the relating to this Example
logic seeks to packets, host process data confirm that threat based
procedure the a Response
identify configuration and identify it addresses on impact
procedure Workflow
, CTI, etc. threat the risk and urgency

Example: Remote Access C2 Communication

Compromised FW, Web Proxy Connect to
Monitor and Reporting Procedure to
host L1, L2 Pinchpoint FPC domain Host: P3
alert on web Engine; be followed
succumbing Analysts Context previously Critical System:
C2 malicious SA ESA when C2 is
to attacker SOC (CMDB, TI added to P2
host Rules detected
takeover Manager, feeds) blacklist
ITOPS
Audience Participation:2
Session: 1849

Q: Which section(s) of the Use Case Framework

is(are) of most use to you?
Threat
Stakeholders
Logic
Testing
Output: Incident Response Procedures

Results
Audience Participation:3
Session: 1849

Q: Do you consider the proposed framework to be

complete or do you think something is missing?
Yes
No
No Clue

Results
The Road Ahead

Consolidate framework
SLAs
UC fine tuning and improvement
IRPs scalability
Threat Indicators
Create Use Case scenarios (focus on threats)
Publicise the Framework and establish an
industry standard
Apply What You Have Learned Today
Next week you should:
Investigate if your organisation already utilizes Use Cases
Highlight any gaps in coverage
In the first three months following this presentation you
should:
Establish your most critical Use Cases and create Framework
Within six months you should:
Deployed your Critical Use Cases
Have a Library of Use Cases and associated IRPs
Identified remaining Use Cases requiring deployment
Conclusions
SOCs cant function effectively
without properly designed Use Cases
A framework provides flexibility but
still keeps Use Cases targeted
A Use Case is Detection AND
Response
 Questions (and thanks for your resiliency )

David.Gray@rsa.com Angelo.Perniola@rsa.com