Multiple Views on Multiplicity Computing: Opportunities Viewed through a Cyber-Security Lens
CREST Workshop
Rick Schantz, Partha Pal, Aaron Paulos, Joe Loyall, Kurt Rohloff Distributed Systems Technology Group
March 23, 2012
CREST Workshop Rick Schantz, Partha Pal, Aaron Paulos, Joe Loyall, - - PowerPoint PPT Presentation
Multiple Views on Multiplicity Computing: Opportunities Viewed through a Cyber-Security Lens CREST Workshop Rick Schantz, Partha Pal, Aaron Paulos, Joe Loyall, Kurt Rohloff Distributed Systems Technology Group March 23, 2012 1982: R&D
March 23, 2012
2
3
System-wide QoS
Distribution Middleware QoS Network QoS Common Middleware Services QoS Operating System QoS Application or Domain-specific QoS
Contract
QoS Adaptive Control
Contract
QoS Adaptive Control
Contract
QoS Adaptive Control
ACE/TAO RT ORB ACE/TAO RT ORB ACE/TAO RT ORB IntServ/RSVP Operating System IntServ/RSVP Operating System IntServ/RSVP Operating System IntServ/RSVP Operating System IntServ/RSVP Operating System IntServ/RSVP Operating System
Contract
QoS Adaptive Control
Contract
QoS Adaptive Control
ACE/TAO RT ORB ACE/TAO RT ORB
5
Gracefully handle degraded and hostile situations Effectively utilize resources
utility?
sets of tasks called application strings.
– Take weighted sum of string utilities – Weighting for relative importance of strings.
– Timeliness – Availability – Quality – Throughput
s j N i s j m i
UA w UA
i
1
System Utility Mission Utility Mission Utility Mission Utility String Utility String Utility String Utility
j
allocation.
improvement.
system behavior.
deployed missions.
failures.
Information Supplier/ Consumer Information Supplier/ Consumer
End-to-end QoS management must
– Manage all the resources that can affect QoS, i.e., anything that could be a bottleneck at any time during the operation of the system (e.g., CPU, bandwidth, memory, power, sensors, …) – Shape the data and processing to fit the available resources and the mission needs
– Includes capturing mission requirements, monitoring resource usage, controlling resource knobs, and runtime reallocation/adaptation Information Supplier Information Consumer
Network
Control and Monitor CPU Processing
– CPU Reservation or CPU priority and scheduling – Have versions that work with CPU broker, RT CORBA, RTARM
Control and Monitor Network Bandwidth
– Set DiffServ CodePoints (per ORB, component server, thread, stream, or message) – Work with DSCP directly or with higher level bandwidth brokers – Priority-based (Diffserv) or reservation-based (RSVP)
Dynamic QoS realized by
Coordinated QoS Management
Shape and Monitor Data and Application Behavior
– Shape the data to fit the resources and the requirements – Insert using components, objects, wrappers, aspect weaving, or intercepters – Library that includes scaling, compression, fragmentation, tiling, pacing, cropping, format change
System resource managers allocate available resources based on mission requirements, participants, roles, and priorities Local resource managers decide how best to utilize the resource allocation to meet mission requirements
QoS Administration Information Services QoS Manager (ISQM)
QoSPolicyContext; PreferenceContext Policy actions
Task Manager LQM Service Task queues
Insert task Extract task Get thread to assign to task
Thread Pool
Info instances Client IDs (broker, filter, read IO only) Insert info Extract info
Pluggable Policy Store
Orchestration instance Policy
QoSContext
Context attributes
Task Creation
Operation task object Operation
Client
Status information Metrics
Xlayer
QoS Context Information instance (via Information Channel)
Bandwidth Manager
BW allocation Parsed policy values
Mission Management QoS Display
LQM Service Client Monitoring Service Task (Broker, Read Info, Filter, Query, Archive) Rate Limiting Control Client
Status information
Submission Mgr LQM Service
Information instance (via Information Channel)
Filter Mgr
2000s Multi-Layered QoS Management for Service-Oriented Distributed Information Systems
QoS Administration Aggregate QoS Management Local QoS Management QoS Mechanisms
Mission-level QoS policies
user prefs.
Mission-level QoS policies
user prefs.
QoS enforcement mechanisms
filtering, replacement
QoS enforcement mechanisms
filtering, replacement
QoS management across multiple users
allocations, importance
QoS management across multiple users
allocations, importance
Enforce QoS policies at local decision points
information
process/info shaping
Enforce QoS policies at local decision points
information
process/info shaping
No system is perfectly secure– only adequately secured with respect to the perceived threat.
Prevent Intrusions Prevent Intrusions
(Access Controls, Cryptography, Trusted Computing Base)
1st Generation: Protection
Cryptography Trusted Computing Base
Access Control & Physical Security
Detect Intrusions, Limit Damage
(Firewalls, Intrusion Detection Systems, Virtual Private Networks, PKI)
2nd Generation: Detection
But intrusions will occur
Firewalls Intrusion Detection Systems Boundary Controllers VPNs PKI
But some attacks will succeed
Tolerate Attacks Tolerate Attacks
(Redundancy, Diversity, Deception, Wrappers, Proof-Carrying Code, Proactive Secret Sharing)
Intrusion Tolerance Big Board View of Attacks Real-Time Situation Awareness & Response Graceful Degradation Hardened Operating System
9
attacks is increasing – some of these attacks will succeed
layered defense-in-depth concept
assets (information, services, …)
Applications
Detect
Attacks
Protect
React
uncertain and incomplete) information – utilizes advanced reasoning and machine learning
10
11
Self-Regenerative Survivable systems Survivable and Secure Systems Adaptive Distributed Object Middleware 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 1999 1998 1997 DARPA AFRL DHS/HSARPA AQuA OIT APOD: Applications that Participate In Their Own Defense
ITUA: Intrusion Tolerance Through Unpredictable Adaptation DPASA: Designing Adaptation And Protection into a Survivability Architecture
QuOIN CSISM*
Red Team Assessments
*Cognitive Support for Intelligent Survivability Mgmt
Unpredictability Unpredictability Byzantine FT Byzantine FT Survivability Architectures and Survivability Architectures and IMSes Cognitive Survivability Management Cognitive Survivability Management Autonomic Defense Autonomic Defense Defense Enabling Defense Enabling
Focus Area
APS: Advanced Protected Services
2010 2011 2012
Survivable SOA Systems Survivable SOA-based Systems
Military (USAF) Joint Battlespace Infosphere (JBI) information management system exemplar made survivable and subjected to sustained attacks over several weeks by multiple independent red teams
Results
Challenge: Develop automated mechanism that would interpret the reports and decide the effective course of action CSISM Approach: 3 level decision making- reactive, deliberate and learned; use theorem proving and coherence to reason about accusatory and evidentiary information contained in reported events
Results
information wrt encoded knowledge
team exercises
additional research
12
and configuration in order to survive
introduced to survivable systems for interpreting reported events and making decisions
13
Slide courtesy Dr. Howard Shrobe, DARPA
2010 DARPA CRASH PROGRAM
Slide courtesy Dr. Howard Shrobe, DARPA
16
17
Host hardware layer Host hardware layer OS layer OS layer
App App
containerized applications to enable various forms of restarts (recovery-focused adaptation) Containerization to isolate application execution Mediated channels enables the defense to
with devices on its own terms
specific preventive adaptation on container’s interaction through mediated channels
top of mediated containers to facilitate immunity-focused adaptation HW layer HW layer OS layer OS layer
App App
Precious state Precious state Disposable state Disposable state
– But the real attack likely happened in the past – Attacker has been successfully executing his tasks – And until now, we had no clue
18
4 e.g., A is corrupt when f(x,y,z)= true e.g., rollback and restart, but to which past state? time Undesired condition Attacker objective was achieved at tX but we did not realize until tZ
tX tZ
Observed by the CZ policies Work toward immunity RwM Experimentation
19
Crumple Zone(CZ) are VMs interposed on basic channels
Policy & Control
Xen DDVM Guest VM-1 Ethernet Bridge
VM-3 acts as the logical intermediate hop between VM-1 and DDVM
Crumple Zones, enforcing policies on mediated channels are built on specialized guest VMs like VM-2 and VM-3
Policy & Control
Guest VM-3 Guest VM-2
VM-2 acts as the backend to VM-1 and frontend to DDVM for block devices
NW Interaction Storage Interaction Xen interrupts and signaling
App
Guest OS
APPVM NW CZVM ST CZVM
Only the Xen hypervisor and Dom0 is treated as TCB A3 Conglomerate: the collection of VMs dedicated to the defense of a protected application
should be possible to
– Reproduce application’s past execution
– Explore alternate execution history
– If an immune conglomerate is found, then that attack is ineffective – Provides an infrastructure as well as the collection of recorded information and supporting tools for analysts and cyber defenders to analyze a zero day attack and develop a countermeasure
diagnosis and patch identification
20
21
This is what is happening inside the diversity generator
Binary Rewriting Binary Rewriting Configuration Generator Configuration Generator Compilation with transforms Compilation with transforms Set of transforms, each with its own purpose SRC SRC V’’ Compilation with aspects Compilation with aspects SRC SRC Aspect Specified Aspect + Multiple semantically equivalent object code variants with different vulnerability profile Object code variants with new defensive behavior (e.g., add a new filter in Apache/PHP) V’’ V Set of tools and gadgets V’’ Object code variants with added checks and reporting
JVM SEL IPTables File System Block Storage Permission Permission Quota Quota Collect statistic Collect statistic
Spec
P’’ P’’
Modifications to CZ policies EXECUTE and TRANSFORM aspects CZ INSPECT aspect CZ
22
OS
Key Key Application
Traditional
connection
Processor & Memory
OS
Key Key Application Dubious Dubious Application Dubious Application Dubious Application Dubious Application Dubious Application
Now/Emerging
23
Record and replay, experiment-based diagnosis, patching and recovery! Use diversity generator to create polymorphic components that exhibit different vulnerability profile Suddenly resources may not be that bountiful!
Host OS (Hypervisor) Guest OS Guest OS Guest OS Guest OS
Dom0 Dom0
Guest OS Guest OS Guest OS Guest OS Guest OS Guest OS
Crumple Zone
Application
Crumple Zone
Application
Diversity Generator Experimen t Controller spawn use
24
But wait– clouds are gathering steam! Recorded information, Replay experiments, Diversity generation, Experiment- based diagnosis and patching all can potentially be done in the cloud! But have we come full circle? Do we really trust the cloud with our critical data and computation?
Host OS (Hypervisor) Guest OS Guest OS Guest OS Guest OS
Dom0 Dom0
Guest OS Guest OS
Crumple Zone
Application
Guest OS Guest OS Guest OS Guest OS
Crumple Zone
Application
Experimen t Controller Diversity Generator spawn use
Diversity Generator
Guest OS Guest OS
Crumple Zone ApplicationGuest OS Guest OS
Crumple Zone Applicationspawn use
25
26
FPGA-based Lattice FPGA-based Lattice Crypto Primitives
FHE Operations FHE Operations Encrypt, EvalAdd, EvalMult, Recrypt CPU-Based CPU-Based Primitives SIPHER CPU libraries SIPHER CPU libraries Selection of CPU libraries for lattice-based primitives Selection of CPU libraries for lattice-based primitives Source Program Circuit Rep. of Circuit Rep. of Program Calls to FHE operations Calls to FHE operations Translation of source program to circuit representation Translation of source program to circuit representation SIPHER FPGA Circuits SIPHER FPGA Circuits Selection of FPGA circuits for lattice-based primitives Selection of FPGA circuits for lattice-based primitives GPU-Based GPU-Based Primitives SIPHER GPU libraries SIPHER GPU libraries Selection of GPU libraries for lattice-based primitives Selection of GPU libraries for lattice-based primitives Selection implementation for FHE Evaluations Selection of calls to FPGA, CPU or GPU implementation for FHE Evaluations
High Level Languages Complexity Speed Middleware Abstraction Layers Low Level Implementation Complexity Speed
Data Encrypted with FHE Scheme Untrusted host supports running of program on encrypted data FHE Operations filter down to appropriate FPGA, CPU or GPU implementation based on available resources.
29