pi meeting 21 june 2007 adventium labs tom haigh charles payne general dynamics johnathan gohde l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Strengthen, Prepare, Detect, React (SPDR) to Mitigate the Insider Threat PowerPoint Presentation
Download Presentation
Strengthen, Prepare, Detect, React (SPDR) to Mitigate the Insider Threat

Loading in 2 Seconds...

play fullscreen
1 / 21

Strengthen, Prepare, Detect, React (SPDR) to Mitigate the Insider Threat - PowerPoint PPT Presentation


  • 162 Views
  • Uploaded on

PI Meeting 21 June 2007 Adventium Labs: Tom Haigh, Charles Payne General Dynamics: Johnathan Gohde. Strengthen, Prepare, Detect, React (SPDR) to Mitigate the Insider Threat. Outline. Insider threat problem and examples SPDR approach Accomplishments in past 6 months

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Strengthen, Prepare, Detect, React (SPDR) to Mitigate the Insider Threat' - lapis


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
pi meeting 21 june 2007 adventium labs tom haigh charles payne general dynamics johnathan gohde
PI Meeting

21 June 2007

Adventium Labs: Tom Haigh, Charles Payne

General Dynamics: Johnathan Gohde

Strengthen, Prepare, Detect, React(SPDR) to Mitigate the Insider Threat
outline
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
mi problem examples
MI Problem & Examples
  • Malicous insider (ARDA Workshop, 2005)
    • Is in organization: Ames (CIA), Hansenn (FBI), Montes (DIA)
    • Has approved/necessary access, privilege, orknowledge 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.
spdr solution
SPDR Solution

Workstation with Embedded DRED Security Processor

Inspect

Proxy

Honeypot

Filter

Encrypt

(Malicious)

Insider

SPDR Reasoning Engine

Attribution

Response

Attack Plan

Recognition

Mission &

Provenance

Monitoring

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.

accomplishments
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
slide6

SPDR Architecture

Off-line

Policy

Database

Plan

Library

Sensor Configuration

Plan Generation

Plan

Library

Attribution

Online

Mission

Progress

Event

Traps

Mission

Monitor

Provenance

Monitor

Plan Recognition

Per user

Policy

Mission

Progress

Plan

Likelihood

Signed

Metadata

Implemented

Responses

Response

Sensor

Configuration

Sensed

Events

Response

Commands

Distributed

Security Modules

mission provenance monitors
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
slide8

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
evaluation testbed summer 2007
Evaluation Testbed – Summer 2007

Air Ops

Workstation

(Dell)

Strike Ops

Workstation

(Dell)

CDC

Workstation

(Dell)

Intel Ops

Workstation

(Dell)

card reader

DRED-1

(Sunfire)

DRED-2

(Sunfire)

DRED-3

(VIA-C3)

DRED-4

(VIA-C7)

FW/Router

Smart Switch

DRED-x

(t.b.d.)

DRED-y

(t.b.d.)

Rogue

Workstation

(Dell)

SPDR

Security

(Sunfire)

External

Networks

Non-Mission

Workstation

(Dell)

Common Server

EMail, File

(HP/Compaq)

3 layered plan generation
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

D

P1 (strategic)

Zone level abstract

path analysis

(100 objects)

Y

B

C

Reduces problem size

two orders of magnitude.

Generates all interesting

plans in a few seconds.

B

C

P2 (tactical)

Only need detail

for 2 zones

(1000’s of objects)

HB

Sensor/effector relevant annotations

P3 (observable)

Observable host-to-host

and intra-host actions

(very simple plans)

AnnotationA

0xFFBA

HC

example level 1 2 outputs
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 Plan 1. : 6 expansions

yappr plan recognition module
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
dred prevent
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

dred detect
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

dred respond
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

dred manage
DRED: Manage

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]

User-based Policy

(dynamic)

DRED-based Policy (static)

dred status
DRED Status

July

diverse implementations

Sunfire Bump-in-the-wire (2)

Mungo-based breadboard (1)

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 user-based policy

January

log collection and consolidation

integration with DSM Manager and Mission Monitor

performance tests

slide19

1

Program Review

3

2

Deliverable (update)

Final Report

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.)

1

6

4

4

SPDR Plans and Timeline

FY-07

FY-08

Dec Mar Jun Sep Dec Mar Jun

1: Requirements, Architecture, Design,

Evaluation Plan (CDRL A003)

2: Spiral 1 (Component Development)

3: Spiral 2 (Integrated System)

4: Spiral 3 (System Hardening)

5: Test and Evaluation

6: Program Management & Travel

2

3

5

8

9

10

7

11

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)

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

Strengthen, Prepare, Detect, React (SPDR)

Research Challenges:

  • 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
  • Approach:
  • Adapt existing Adventium & SIFT reasoning technologies
  • Exploit evolving COTS hardware capabilities
  • Military relevance via GD-AIS application scenarios
  • 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)
slide21

Questions?

Comments?