Computational Resiliency

1
Computational Resiliency

• Steve J. Chapin, Susan Older
• Syracuse University
• Gregg Irvin
• Mobium Enterprises

2
Computational Resiliency
CR the ability to sustain operation and
dynamically restore the level of assurance
during an attack. A computationally-resilient
application can sense, tolerate, and react to
attack.
3
Computational Resiliency
Is not...
Is...

• A mix of application libraries, system software,
  and theory
• A complementary solution
• Focused on the application (karate)
• Introspective

• An intrusion detection system
• although it might use one
• A front-line defense
• A system-wide defense focused on negative policy

4
Computational Cockroaches1
No matter how hard you try, you just cant wipe
them out.

• Breed -- use rapid replication to maintain
  numbers.
• Hide from light -- sense attacks and migrate
  away.
• Adapt -- reconfigure application use camouflage
  and other tools to make oneself harder to hit.

1Thanks to Cathy McCollum for the roach analogy.
5
Three-Pronged Approach

• Strong theoretical basis
• reason about conformance to policy
• Computational resiliency library
• dynamic application management
• System software support
• scheduling/policy frameworks
• sensors

6
Theoretical Framework

• Support reasoning about application and system
  behavior subject to resource constraints and
  application configuration
• Formal notation based on ?-calculus
• ?-calculus covers migrating threads,
  communicating agents, dynamic topologies
• Extend for location and resource awareness
• cf. distributed join-calculus, ?1-calculus,
  D?-calculus
• Capture notion of sufficiently equivalent
  efficiency

7
Computational Resiliency Library

• Dynamic multithreading
• Migration
• Replication
• Camouflage
• Functionality reconfiguration
• Policy-based management

Build on SCPlib
8
Library Technology (SCPlib)
Processors may be microprocessors, SMP machines,
or special devices.
Reconfigurable Threads may move
between processors to accommodate failures or
changes to resource availability.
Reconfigurable Channels provide uniform
communication mechanism in SMPs and networks.
thread
9
Replication with Group Communication
10
Basic CRlib Mechanisms for Dynamic Reconfiguration
11
Camouflage

• Simple
• rename process, respawn process
• More complex
• change functionality (via split/merge)
• process size/behavior patterns
• mimic interface of real programs
• decoy processes

12
Policy-based Management

• Applications/users specify CR policy
• number of replicas ? mutation policy
• migration policy ? checkpointing
• As much as we can, draw on past and concurrent
  work in policy specification and management at
  DARPA (we really would rather not build this yet
  again)

13
System Support

• Schedulers that understand CR policies, resultant
  resource demands, user/process priority
• Build on our past work in scheduling (MESSIAHS,
  Legion)
• High potential for collaboration

14
Testbed Environment
SGI Origin 200 SMP
Intel 4-way
SUN Sparc
Intel 8-way
PC
Wireless Hub
Gigabit Switch
AFRL
Routers
Radar Sensor
PC/ Alpha cluster
Sensor
SGI Indigo
Mobium
PC
15
IW-Hardened Applications

• Collaborate with Real-Time Sensors project at
  Syracuse (DARPA ITO)
• Develop IW-hardened multispectral imaging
  application (TBD), e.g.
• Land mines using UAVs
• Camouflaged equipment and personnel
• Missile threats - plume signatures
• Concealed weapons
• Treaty compliance/surveillance using UAVs

16
Real Time Multi-spectral Camera

• Deliver up to 110 frs/sec
• Full pixel resolution at 1024x1024
• Filter wheel with 12 filters ranges from 500nm to
  1050nm
• motor controlled variable frame rate, and
  exposure time

17
Spectral-Screening PCT

• Entropy 2.25

• Entropy 0.726

• Delta SNR 4.508 dB

18
Risks and Concerns

• Self-DOS
• cost of response vs. the cost of attack
• cost of defense in the absence of attack
• manipulation via corrupted sensors
• avoid if possible document if unavoidable
• Timing issues and race conditions
• can we react fast enough in the face of heavy
  attack? Attacks during reconfiguration?
• Observation reducing the effectiveness of our
  methods

19
Technology Transfer

• Mobium Enterprises
• subcontractor on this effort
• integrate this technology with DARPA applications
• CASE center at Syracuse
• NY state-sponsored incubator
• sole purpose is tech transfer of computing
  technology to startups in central NY

20
Milestones

• 6-12 months
• core calculus
• extend SCPlib to create basic CRlib
• simple camouflage
• decoys
• prototype IW application using basic CRlib

21
Milestones II

• 15-24 months
• rough equivalence in calculus
• initial use of calculus to analyze schedules and
  configuration changes
• functionality mutation
• policy specification frameworks

22
Milestones III

• 36-42 months
• Advanced camouflage
• CR-aware schedulers
• Final IW-hardened application
• policy specification framework using calculus
• IW exercises to test system every 6 months
  starting at 1 year

23
Hypothetical Example

• Rocky
• highest priority
• expands out of safe zone
• replication
• Dudley
• lowest priority user
• stays inside safe zone

• Bullwinkle
• expands out of safe zone
• splits computation to obtain higher concurrency
• employs replication, checkpointing

24
The Attack...

• Natasha -gt Rocky
• caught by IDS
• Boris -gt Bullwinkle
• successfully kills some of Bullwinkles processes
• Snideley -gtDudley
• caught at firewall (Curses, foiled again!)

25
The Reaction

• Rockys application
• retreats into the safe zone
• Bullwinkles application
• employs camouflage
• puts out decoys
• recovers from checkpoint
• Dudleys
• does nothing, but must release resources to
  Rockys application

26
Jays Questions

• Attacks/Threats
• We dont have a specific model at this time
• Alerts by IDS, noticing when our threads are
  killed/incapacitated
• Policies well support
• Positive policies regarding the behavior and
  properties of our applications