Sandia SRS Red Team Results Information Design Assurance Red Team John Clem Kandy Phan DARPA SRS PI Meeting 15 Dec. 2005 Sandia is a multiprogram laboratory

Sandia SRS Red Team Results

Information Design Assurance Red Team

John ClemKandy Phan

DARPA SRS PI Meeting 15 Dec. 2005

Sandia is a multiprogram laboratory operated by Sandia Corporation, a Lockheed Martin Company,for the United States Department of Energy’s National Nuclear Security Administration

under contract DE-AC04-94AL85000.

QuickTime™ and aBMP decompressor

are needed to see this picture.




• IDART™ Objectives• Initial Analysis• Results PMOP, CORTEX, PASIS• General Observations• Lessons Learned• Q&A

Outline




IDART Objectives

• System Analysis– Increase system understanding– Test system responses to adversarial inputs– Attack assumptions/claims– Confirm strengths and reveal weaknesses

• Red Team– Open…– Flexible– Objective– Fair




Initial Analysis

• Reviewed three SRS technologies for live red team readiness

• Two technology development projects were chosen for a live red team engagement

• One technology project was chosen for an attack brainstorm only

• Criteria– Technology implemented?– Stable?– Potential for tangible results?




PMOP

• Adversary Model:

– A regular user with malicious intent– Operating system vulnerabilities are out of scope




PMOP targets

• 3 Separate Components on 3 systems

– 1. Rule System– 2. “File Save As …” Dialog Box– 3. Wrapped Shell




PMOP: Rule System

MAFGUI

(Legacy dependency)

PMOP

JESSRule engine

Rule file

allow …

deny …

Rules to enforceMission plan to check




PMOP: MAF GUI Client




PMOP: Example Rule File

(defrule MAIN:first-leg-must-be-a-takeoff(MISSION_EVENT_ROW (EVENT_TYPE ?&~"TO") (EVENT_SEQ_ID ?id1) (prev -1))=>(error-feedback "first-leg-must-be-a-takeoff " ?id1))

(defrule MAIN:aircraft-cannot-exceed-supported-weight-of-airbase… (WEIGHT ?acweight&:(> ?acweight ?abweight)) )=>(error-feedback "aircraft-cannot-exceed-supported-weight-of-airbase "))




PMOP: Rule System

• Strengths: – Fast– Accurate– XML

• Weaknesses:– Need stronger input validation (e.g. XML)– Scalability/Consistency of rules– Domain/Expert knowledge dependent




PMOP: “SaveAs” Dialog Box




PMOP: Wrapped Shell




PMOP: Wrapper Config File

authorize connect in ws2_32.dll with Inst_connectauthorize bind in ws2_32.dll with Inst_bindauthorize sendto in ws2_32.dll with Inst_sendtoauthorize recvfrom in ws2_32.dll with Inst_recvfrom

// mediators for MSO SaveAs and Open Dialogstransform FindFirstFileExW in kernel32.dll with Inst_FindFirstFileExWtransform FindNextFileW in kernel32.dll with Inst_FindNextFileWmonitor FindClose in kernel32.dll with Inst_FindClose




PMOP: Wrapper Config File

<file inherit="true" override="false" resource="%appdata%\Mozilla\Firefox\profiles.ini"> <read action="allow" audit="false"/> <write action="allow" audit="false"/> <execute action="deny" audit="true"/> <com action="deny" audit="true"/> </file>




PMOP: Wrapped Shell

• Strengths: – Canonicalization of file names– Granularity

• Weakness:– Scalability of configurations

• Results:– NT wrappers did well protecting the JBI directory




CORTEX

Master DB

Tasters(Lead)

Proxy Replicator

Learner

RTS: Controller

Red TeamClients




CORTEX

• Strengths:

– Fast response/Efficient of learner – Block mechanism/“Binary poison” – Scalability in number of tasters– Single entry point – Real automatic system




CORTEX

• Weaknesses:

– Instrumentation capabilities – Instability of proxy and controller (buffers?)– Algorithm to switch tasters– Invalid error messages – Failure detection for tasters




CORTEX

• Red Team flags:– 1. Crash system twice with same attack – 2. False positives – 3. Take down system

• Results:– Flag 1 not achieved – Flag 2 achieved– Flag 3 achieved

• Instability did not allow full testing or attribution of effects




PASISIncreasing Intrusion Tolerance via Scalable Redundancy

General Observations• Strengths

– Provable guarantees assuming limited number of Byzantine servers and unlimited number of Byzantine clients

– Invisible to ordinary user– Very efficient in normal operation– Plausible attack requires sophisticated adversary with

extensive real-time knowledge of network state– Sensible implementation successfully thwarts obvious

lines of attack (timestamp manipulation, message replays)




PASIS (2)

• Weaknesses– Presupposes extensive PKI– Interactions with underlying file system implementation

can be complex, hard to specify, could undermine liveness/linearizability guarantees

– Possibility of large overhead, adversary can force system to do a lot of redundant work (live engagement needed to confirm this)

– Not entirely clear how to update system while running (add/drop servers, change parameters or algorithms)




PASIS (3)

Attack Brainstorm Results (attack graph)




PASIS (4)

Conclusions• In theory there may be conditions showing PASIS

protocol is not bullet-proof• Weaknesses are in underlying assumption of

scaled PKI; always correct file system interactions; lack of defined maintenance procedures

• Strengths are in strong proofs; transparency; efficiency; significant adversary attack requirements




General Observations

• Red Team success with causing false positives– Low cost attack– DoS

• System state under attack difficult to know• Weak threat models still being used by

developers• System security not inherent

– Dependent on other things (implementation)– What happens when you build a system of

systems?




General Observations (2)

• Implementations have been shown to include shortcuts bypassing the theoretical model specifications

• Scoring has pros and cons– There can be COI

• Red Team discouraged from trying novel attacks due to low likelihood of success

• Red Team could run up the score based on uninteresting variations of successful attacks




Lessons Learned

• Murphy was here (again)• Live Red Team experiments/exercises are not low

overhead– Certain amount of overhead for even one day

• Need stable implementations– Homogeneous platforms increases reliability

• Hardware• OS• Applications

– Redundant platforms improves efficiency– Certain metrics difficult to measure without this




Lessons Learned (2)

• Frozen version• Need developer instrumentation to understand

system state• Advantageous for developers to have/consider

more sophisticated threat models early• Need/use shortcuts to adequately model

adversary pressure– These are exercise assumptions– This adds value/reduces cost




Value Added

• Different Perspective (Malicious)• Experience• Clarifies understanding• Provides new insights• Structure for analysis




Q&A/Discussion

IDART Contact Information

John [email protected]

Kandy [email protected]

mailto:[email protected]

mailto:[email protected]

Documents

Sandia SRS Red Team Results Information Design Assurance Red Team John Clem Kandy Phan DARPA SRS PI Meeting 15 Dec. 2005 Sandia is a multiprogram laboratory