Transcript Strengthen, Prepare, Detect, React (SPDR) to

Strengthen, Prepare, Detect, React
(SPDR)
to Mitigate the Insider Threat
PI Meeting
21 June 2007
Adventium Labs: Tom Haigh, Charles Payne
General Dynamics: Johnathan Gohde
SRS Phase II PI Meeting
21 June 2007
1
Outline
• Insider threat problem and examples
• SPDR approach
• Accomplishments in past 6 months
– Architecture and Evaluation
– Scenario implemented and working with Mission
Monitor (Demonstration)
– Attack planning, attack recognition and sensor
generation (Demonstration)
– Prototype DREDs with key features operational
• Plans for next 6 months
SRS Phase II PI Meeting
21 June 2007
2
MI Problem & Examples
• Malicous insider (ARDA Workshop, 2005)
– Is in organization: Ames (CIA), Hansenn (FBI), Montes (DIA)
– Has approved/necessary access, privilege, or knowledge of organization’s
information systems, information services, and missions.
– Is motivated to adversely impact missions by compromising confidentiality,
integrity, and/or availability
• Recent insiders:
– Information Week (May 10 2007), Leandro Aragoncillo, career Marine with
a top secret security clearance, served under two vice presidents in the
White House (2 yrs) and then the FBI (4 yrs), stole classified information
in an attempt to foster a political coup in the Philippines, his home country.
– The Washington Times (April 6, 2007) Richard Sylvestre, U.S. Navy
contractor sabotaged a national security computer network at a Navy
command center in Italy. A criminal complaint, “would have shut down the
entire network that tracks the locations of ships and submarines.”
– CICentre.com (March 7, 2007), Paul R. Hall, signalman on USS Benfold,
e-mailed Al Qaeda contact, advising that Battle Group would pass
through Straits of Hormuz in 19 days and would be highly vulnerable to
small weapons such as RPGs.
SRS Phase II PI Meeting
21 June 2007
3
SPDR Solution
Workstation with Embedded DRED Security Processor
Inspect
Proxy
Honeypot
Filter Encrypt
(Malicious)
Insider
SPDR Reasoning Engine
Attribution
Response
Mission &
Provenance
Monitoring
Attack Plan
Recognition
Attack Plan
& Sensor
Generation
Attack Plan and Mission Models
All Network Access controlled by Detection & Response Embedded Device (DRED).
Restricts range of feasible attack plans, hence reducing amount of reasoning required.
SRS Phase II PI Meeting
21 June 2007
4
Accomplishments
• Requirements, Architecture, Design, & Evaluation
– Submitted draft CDRL A003, 13 Feb 07
– Added Mission & Provenance Monitors, Attribution Engine
• Improved attribution
• Will include in July update of A003
• Initiated collaboration with BBN
– Both using Adventium’s network model
– Began discussion of integration options
• Defined and implemented evaluation scenario & mission monitor
– Carrier-base Anti-Surface Warfare (ASuW) mission planning
– Based on GD tactical SOA
– Demonstration today
• Restructured attack plan and sensor generation
– Improved efficiency and scalability
– Demonstration today
– Interface with plan recognition module (YAPPR)
• Operating DREDs
– Key functions operational
– Several form factors
SRS Phase II PI Meeting
21 June 2007
5
SPDR Architecture
Off-line
Policy
Database
Plan
Library
Plan Generation
Plan
Library
Sensor Configuration
Attribution
Mission
Progress
Plan Recognition
Per user
Policy
Plan
Likelihood
Implemented
Responses
Mission
Monitor
Event
Traps
Provenance
Monitor
Mission
Progress
Response
Sensed
Events
Online
Response
Commands
Distributed
Security Modules
SRS Phase II PI Meeting
21 June 2007
6
Signed
Metadata
Sensor
Configuration
Mission & Provenance Monitors
• MM tracks the progress of each mission with respect to its plan
– Uses functional dependency and timing model of the mission
– Receives mission message notifications from DREDs
– Reports mission step anomalies or delays to the PRM
●
PM preserves message data
& metadata that can be used,
if a mission fails, to help
identify the cause of the
failure and the user
responsible
–
Receives message information
from DREDs
–
Stores info in database for use in
attribution analysis
SRS Phase II PI Meeting
21 June 2007
7
Evaluation Scenario
•
•
•
•
Anti-surface warfare using Tactical SOA
(TSOA) developed by General Dynamics.
Carrier-based scenario: threat assessment,
flight plan development, hand-off to E-2C.
Embedded in general network traffic to
extend attack surface
2 classes of insider:
– On carrier network but outside mission
– Inside mission
SRS Phase II PI Meeting
21 June 2007
8
Evaluation Testbed – Summer 2007
Air Ops
Strike Ops
CDC
Intel Ops
Workstation
Workstation
Workstation
Workstation
(Dell)
(Dell)
(Dell)
(Dell)
DRED-1
DRED-2
DRED-3
DRED-4
(Sunfire)
(Sunfire)
(VIA-C3)
(VIA-C7)
card reader
FW/Router
Smart Switch
DRED-x
DRED-y
(t.b.d.)
(t.b.d.)
Non-Mission
Common Server
Workstation
EMail, File
(Dell)
(HP/Compaq)
Rogue
Workstation
(Dell)
SPDR
Security
(Sunfire)
SRS Phase II PI Meeting
21 June 2007
9
External
Networks
3-Layered Plan Generation
Test network model with over 20K
instances, built using automated scanner
NetBase Ontology (Class Definitions)
Build once, use often, for many networks
Is being used by BBN for CSISM
A
X
P1 (strategic)
Zone level abstract
path analysis
(100 objects)
D
Y
B
C
P2 (tactical)
Only need detail
for 2 zones
(1000’s of objects)
P3 (observable)
Observable host-to-host
and intra-host actions
(very simple plans)
B
HB
Reduces problem size
two orders of magnitude.
C
Sensor/effector relevant annotations
AnnotationA
0xFFBA
HC
SRS Phase II PI Meeting
21 June 2007
10
Generates all interesting
plans in a few seconds.
Example Level 1 & 2 Outputs
Top Level Goal g1: steal ssh_priv_key_edc…
Level 1, Plan 13 : [e,k,g,h]
e: vint(zone_client, zone_wireless, c_wap_service(zone_wireless), credz__J5)
g: read(credz_4l5, zone_internal, c_ssh_service(zone_internal), sshd_rexec_exploit)
h: read(ssh_privkey_edcfc828b41a41fe12cf476b721bc279ec657b31, zone_internal,
c_ssh_service(zone_internal), credz_4l5)
k: vint(zone_internal, zone_client, c_smtp_service(zone_internal), smtp_redirect_exploit)
92 Level 2 expansions:
( ( S1 S2 ) ( S3 S4 ) ( S5 S6 S7 ) ( S8 S9 S10 S11 S12 ))
( ( S1 S2 ) ( S3 S4 ) ( S5 S6 S7 ) ( S8 S9 S10 S13 S14 S12 ))
( ( S1 S2 ) ( S3 S4 ) ( S5 S6 S7 ) ( S8 S9 S10 S11 S12 ))
( ( S1 S2 ) ( S3 S4 ) ( S5 S6 S7 ) ( S8 S9 S10 S13 S14 S12 ))
( ( S1 S2 ) ( S3 S4 ) ( S5 S6 S7 ) ( S15 S16 S17 S18 S19 S12 ))
( ( S1 S2 ) ( S3 S4 ) ( S5 S6 S7 ) ( S15 S16 S17 S18 S19 S12 ))
( ( S1 S2 ) ( S3 S4 ) ( S5 S6 S7 ) ( S8 S9 S10 S11 S12 ))
…
S1 : connect(iface(med_gravity_wlan, ip_192_168_13_13), gravity_wap_service)
S2 : create_if(con(iface(med_gravity_wlan, ip_192_168_13_13), gravity_wap_service),
labs_wep_secret, med_labs_switch2, ip_10_0_1_2)
…
Plan 8. : 6 expansions
Plan 5. : 92 expansions
SRS Phase II PI Meeting
21 June 2007
11
Plan 1. : 6 expansions
YAPPR Plan Recognition Module
• YAPPR – Yet Another Probabilistic Plan Recognizer
–
–
–
–
SIFT, U. Edinburgh, DARPA Integrated Learning
Input: library of hierarchical task network plans (AND/OR graph)
Compiles plan library into form suitable for rapid online recognition
Online: sequentially estimates probabilities of possible intentions
given observation stream
• Tests on YAPPR scalability
– Randomly generated plan libraries of various sizes
– e.g. “Large” plan lib (near limits of current YAPPR implementation):
• 10 high level intentions (HLI)
• 10 distinct high level plans (HLP) of 10 steps each per HLI
• 10 distinct low level plans (LLPs) of 10 steps each per HLP
– Compilation times (an offline activity) on the order of 1 minute
– This is larger than we expect real plan library to be for AsuW
scenario
• Planner ---> YAPPR interchange format
– Plan library is emitted by planner in this form.
– Translator to YAPPR HTN representation is being tested at SIFT
SRS Phase II PI Meeting
21 June 2007
12
DRED in a Nutshell
SRS Phase II PI Meeting
21 June 2007
13
DRED: Prevent
•
Focus is on enforcing authorized behavior to thwart insider attack
•
Authorized behavior is what is required for this user for this mission
•
Prevention opportunities exist for network through application layers
SRS Phase II PI Meeting
21 June 2007
14
DRED: Detect
•
Focus is on discovering events that may suggest an insider attack and on
providing sufficient evidence to support (later) attribution of an attack.
•
DRED manager collects all events (except Mission Status)
•
Some event consolidation by the DRED is anticipated for efficiency
SRS Phase II PI Meeting
21 June 2007
15
DRED: Respond
•
Focus is on thwarting misuse and on supporting attribution
•
Each response is determined by the Response Module but coordinated
through, and directed by, the DRED Manager
•
Response may also include additional logging without further restriction
SRS Phase II PI Meeting
21 June 2007
16
DRED: Manage
User-based Policy
(dynamic)
•
DRED-based Policy (static)
Focus on what can be managed easily
– pf makes an effective 'policy router'
•
Split policy into static and dynamic parts (see above)
•
Leverage Adventium's policy management strategy for distributed policy
enforcement points [DARPA OASIS Dem/Val, DHS EFW/VPG]
SRS Phase II PI Meeting
21 June 2007
17
DRED Status
•
•
July
– diverse implementations
January
– log collection and consolidation
• Sunfire Bump-in-the-wire (2)
• Mungo-based breadboard (1)
– integration with DSM Manager
and Mission Monitor
– performance tests
– user-based pf rules
– IPsec between multiple DREDS
using X.509 authentication
– simple HTTP proxy
– snort, honeyd
•
September
– proxy configuration for message
compliance and mission status
– DRED policy management
– user authentication for userbased policy
SRS Phase II PI Meeting
21 June 2007
18
SPDR Plans and Timeline
FY-07
Dec
Mar
FY-08
Jun
Sep
Dec
Mar
Jun
1
1: Requirements, Architecture, Design,
Evaluation Plan (CDRL A003)
2
3
5
2: Spiral 1 (Component Development)
8
9
3: Spiral 2 (Integrated System)
10
4: Spiral 3 (System Hardening)
4
6
7
11
5: Test and Evaluation
1
2
3
4
6: Program Management & Travel
Program Review
1. CDRL A003 Delivered (Feb.)
Revisions in July 07, January 08, and June 08.
2. Initial DRED: User-based IP filtering and sensing (Mar.)
3. Initial planner: Strategic and tactical levels (Apr.)
NetBase ontology (network model) shared with BBN
4. Scenario defined: Carrier flight planning (Mar.)
6. Functional Model of Scenario (Jun.)
Deliverable (update)
Final Report
5. Components operational (Jul.)
Demonstrations in September
7. Testbed complete (Oct.)
8. Initial integration (Oct.)
9. E2E demonstration (Jan.)
10. Final software build complete (Mar.)
11. Red Team evaluation complete (May)
SRS Phase II PI Meeting
21 June 2007
19
Strengthen, Prepare, Detect, React
(SPDR)
Objective:
Thwart and attribute insider attacks by combining
AI-based plan generation, sensor synthesis and
plan recognition with HW-based, tamper resistant,
end-point sensing & control
Benefits:
•
•
•
Increased accountability
Rapid, targeted response to malicious insiders
Minimizes impact on benign activities, thereby
improving mission effectiveness
Research Challenges:
Approach:
•
•
•
Adapt existing Adventium & SIFT reasoning technologies
•
Exploit evolving COTS hardware capabilities
•
Military relevance via GD-AIS application scenarios
•
•
•
Thwart plausible, but unknown attacks
Identify malicious insiders even when all their actions are
authorized
Minimize impact on benign activities
Ensure sufficient strength of sensing and control
mechanism, so insider with physical access cannot disable
or avoid it.
Maintain compatibility with evolving DoD systems
–
–
–
Push security toward the endpoints
DoD Enterprise Sensor Grid Strategy
GIG vision of end-to-end encryption
Innovations:
•
A priori reasoning anticipates attacks, informs defenses,
and generates sensors
•
Intelligent attack recognition reduces false alarms and
supports targeted response creation
•
Unbypassable, tamper-resistant network endpoint for
sensing and control (important for insiders)
SRS Phase II PI Meeting
21 June 2007
20
Questions?
Comments?
SRS Phase II PI Meeting
21 June 2007
21