hacqit: hierarchical adaptive control of qos for intrusion tolerance
DESCRIPTION
To Users. FW. Mini-LAN. Monitor. &. Adapter. Server 2. Server 2. Sensors. Server 2. Server 2. Server 2. Server 2. Server 2. Server 1. HACQIT: Hierarchical Adaptive Control of QoS for Intrusion Tolerance. James E. Just Karl Levitt. The UC Davis Computer Security Laboratory. - PowerPoint PPT PresentationTRANSCRIPT
HACQIT:Hierarchical Adaptive Control of QoS for
Intrusion Tolerance
James E. JustKarl Levitt
Mini-LAN
FW
Monitor&
Adapter
Sensors
To Users
Server 2Server 2
Server 2Server 2
Server 2Server 2
Server 2Server 1
July 18, 2000 2
Outline• Team• Overview• Goals• Approach• Major risks and risk management• Hypotheses, experiments and metrics• Policy assumptions and enforcement• Schedule• Technology transfer• Conclusions
July 18, 2000 3
HACQIT Team
• Teknowledge Corporation– Quorum integrator – Distributed intelligent control– Architecture based development– Information assurance and CC2
• UC Davis– Fault tolerance– Intrusion detection and response– Attack modeling
July 18, 2000 4
The HACQIT Idea• Utilize robust hierarchical control to achieve IT, i.e.,
deliver critical COTS services to critical users– Significantly raise adversary work factors– Focus on useful military applications– Policy driven
• Leverage current and new technologies– QoS/Quorum – DeSiDeRaTa, AQuA, QCS, others– IA&S – wrappers, intrusion and integrity sensors, active
monitoring & response, randomization, VPNs, attack modeling (Jigsaw concepts), honeypots
– Fault tolerance – separation, diversity, replication & check-pointing, fail-over
– Others – out-of-band signaling, etc• Incrementally deliver capabilities
July 18, 2000 5
Project Goals• Prototype HACQIT controlled cluster delivering
– 4 hours of intrusion tolerance under– Active Red Team attacks (network based) on hosts– Providing policy determined critical services from– COTS/GOTS applications to– Critical users (also policy determined) at– 75% capacity
• Extensible model base for IT control• Focus
– COTS HW & SW based for near term utility– Architecture based framework for longer term
extensibility (hierarchical and fractal)
July 18, 2000 6
Approach• Focus on military applications (e.g., MS Office,
email, portions of ACOA ACTD software, RT)• Prototype HACQIT
– Extend selected Quorum, IA&S, and other technologies • Migration (Desiderata), fault tolerance (Aqua), sensing (wrappers,
instrumented connectors) and integration (QoS Condition Service, QCS) to provide the initial intrusion tolerance framework for initial application
• Integrated management and response system– Leverage additional sensors for integrity monitoring and
control for operating systems, applications, & data– Test, iterate and extend for various types of applications
• Implement extensible model (concepts, rules, etc.) for assessment & response at various levels
July 18, 2000 7
HACQIT Scope
• Will address– QoS control for critical services to critical users– Hierarchical, extensible object control model– Host attacks on availability and integrity– Variety of COTS/GOTS applications– Policy specification of above
• Won’t address– Network infrastructure attacks (e.g., routers or
communication flooding attacks)– Development of new sensors or mechanisms, but will
leverage them– Integrity of data sources used as inputs
July 18, 2000 8
HACQIT “Reference Model”
WAN
User User 2
FW
LAN
Server 2Server
2Server 2Server
p
FW
HACQIT Controlled Cluster
User 2User
2User 2User
N
User J
Server 2Server
2Server 2Server 1
Primaries Backups & Decoys
Monitor & Adapter
i
qo
User M
Server r
User P
Communications with other HACQIT Controllers
Server = Critical Service
= Non-Critical ServiceServer
= Attacker
User = Critical User
User = Non-Critical User
= Sensors Key
Server rServer r
July 18, 2000 9
HACQIT Cluster Architecture
VPN
Out of Band Control Pathways
Note: Each server is connected to LAN through switch controlled only by
Monitor/ Adaptor Monitor/ Adaptor is not connected to mini-LAN but only to out of band control
pathways
Mini-LAN
FW
Monitor &
Adapter
Sensors
To CriticalUsers
Server 2 Server 2
Server 2 Server 2
Server 2 Server 2
Server 2 Server 1
Primaries Backups & Decoys
To Other Controllers
July 18, 2000 10
Intrusion Tolerance Condition Service
HACQIT Responders
HACQIT IT Condition Service
Mediator Mediator Mediator
Intrusion Sensors
Integrity Sensors
Performance Sensors
IT Condition Visualization
IT Event Log, Other Clients
IT Policies and Specs.
July 18, 2000 11
Typical Usage Architecture
FW
Server 2Server 2
Server 2Server p
Monitor &
Adapter
Sensors
HACQITManagedCluster
Server 2Server 2
Server 2Server 1
Primaries Backups & Decoys
Communications with other HACQIT Controllers
WAN
User User 2
FW
LAN
User 2User
2User 2User
N
User J
i
qo
User M
Server r
User P
Server rServer r
VPNs
July 18, 2000 12
Use Case• Assume a backup (hot or cold);• Detect an intrusion:
– If intrusion does not constitute a threat to the critical application, then start a procedure to expunge the attack and block future occurrences, return;
– If attack threatens the critical application, then switchover to backup, expunge the attack from the primary, block future occurrences of the attack, return;
• Detect a performance or integrity problem in critical application (including data files), operating system, or other critical process that indicates an undetected intrusion– Switchover to backup, expunge the attack from the primary, block
future occurrences of the attack, return
July 18, 2000 13
DeSiDeRaTa
Select action
Metrics
Analysis
Enactment
H/W metrics
Distributed hardware
Diagnosis
Monitor
Sensors
Filter
Eval
Act
Actuator
RT paths
Resource discovery
Spec. File
July 18, 2000 14
AQuA
GossipNameServerGossipNameServer Gateway
Server QuO
Gateway
Server QuO
Gateway
Object QuO
ObjectFactory
Gateway
ObjectFactory
Gateway
ObjectFactory
Gateway
ObjectFactory
Gateway
ObjectFactory
Gateway
ProteusDependability
Manager
Gateway
ProteusDependability
Manager
GatewayGateway
Client QuO
Gateway
Client QuO
Gateway
Client QuO
Gateway
Object QuO
Maestro/ Ensemble Group Communication System
July 18, 2000 15
QoS Condition Service
QoSVisualization
Client
QCS Provider
QCSRepository
QCS Manager
QoS LoggingService
DesiderataMediator
InstrumentedConnector
QoS Condition Service (QCS)
InstrumentedConnector Instrumented
Connector
TAOEvent
Channel
TAOEvent
Channel
QCS Agents
QCSClients
QCS Clients API
QCS Agents API
App. 2 Out Mediator
App. 1 Out Mediator
App. 2 In Mediator
App. 2 In Mediator
July 18, 2000 16
Intrusion Tolerance Condition Service
HACQIT Responders
HACQIT IT Condition Service
Mediator Mediator Mediator
Intrusion Sensors
Integrity Sensors
Performance Sensors
IT Condition Visualization
IT Event Log, Other Clients
IT Policies and Specs.
July 18, 2000 17
Illustrative Extended GlobalGuard IDS Architecture
InferenceEngine
Interface
AttackModelSpecification
JIGSAW
Application, System &NetworkSpecification
DBS
Query
User InterfaceCISL
CIDFTest File
Other Input
Probe
JIGSAW to I. E.
Translator
DBS to I. E.
Translator
Sensor Array
Sensor to I. E. Preprocessor
CIDF Components
Responses
July 18, 2000 18
Attack Categories & CharacteristicsAttack
Category Service
Attacked Performance Or Integrity
How It Is Launched Impact Of Attack How It Is Detected
How It Can Be Mitigated
Buffer overflow
OS Priv. Program
Integrity Long message to service
Service runs attacker program in privileged mode
Parameter check; Change to return address; Detect wrong priv. program
behavior
Kill process after detection
Race condition
OS Priv. Program
Integrity Exploit interval between check and use
Service runs attacker program in privileged mode
Detect attacker-caused delays in program
Detect wrong privilege program behavior
Kill process after detection
Overflow a system table by inside process
OS and Applic.
Performance Create excessive number of processes
Denial of service to processes, possibly system crash
Anomaly in table Missed deadline
Kill process after detection
Overflow a system table from outside
OS and Applic.
Performance Send excessive number of packets
Denial of service to processes, possibly system crash
Anomaly in table Missed deadline
Kill process after detection Block packets
Modify critical applic. program
Applic. Integrity Obtain priv. status and then modify a user file
Critical program or data is modified
Change to critical file Wrong application behavior
Switch to backup and revert to saved file
Others TBD
July 18, 2000 19
JIGSAW Concept Template Extended[abstract] concept <concept_name> [extends concept_name]
requires [sensor|capability|config] <CapabilityTypes:LABEL_LIST>+with<expression list>end;
provides<CapabilityTypes:LABEL_LIST>+with<assignments>*end;
action<external actions>*[reportable <when|unless> <condition>]end;
response<external response class required to stop “attack” now>*end;
end.
July 18, 2000 20
Major Risks• Attacks
– Against monitoring & control components– Common mode attacks– Active blocking after unknown attack
• Accurate and rapid intrusion sensing & avoidance• Backups
– Restoration speed (applications & connections)– Corruption (logical isolation from primary)
• Overhead for different types of applications• Recovery of the primary server in a timely manner
(not a major focus of base program)• Workload to use and maintain
July 18, 2000 21
Major Mitigations• Diversity (hw, sw, versions, etc)• Randomization of initialization/response• Content monitoring (and selective logging) of
input/output streams• Out of band control system• VPNs among critical users and servers• Wrappers for low level sensing and control• Adaptive control• Deception (decoys, honey-pots, fishbowls, etc)• Restrictions on services
July 18, 2000 22
Hypotheses• The QoS mechanisms developed under the
Quorum program can be extended to enable a managed cluster of COTS computers to provide intrusion tolerant services for critical COTS/GOTS applications to selected users on a LAN/ WAN
• The proposed architecture will cost-effectively support application requirements ranging from traditional user-oriented client-server applications to mission critical, real-time distributed applications
July 18, 2000 23
Testable Goals
• Enable 75% of critical function capacity to be maintained under coordinated attack over the network for four hours using COTS hardware and software with emphasis on denial of service and integrity attacks and
• Add a new user while under attack• Add a critical service while under attack
July 18, 2000 24
Experiment Plan
• Test goals every annually (at least) months against active Red Team on incrementally harder applications– Simple file based applications to client server to
near-real time control– Red Team guidelines need to be worked out
July 18, 2000 25
Policy
• Enforcement– Application specifications
• Performance levels• Response abilities
– Definition of critical users and services– Response guidance
• Infocon postures• Response mechanisms and availability• Tradeoffs
– Response directives
July 18, 2000 26
HACQIT Schedule
1.3 Integrity Sensor/Maintenance
1.7 Experimentation
1.6 Integration
1.5 Component Enhancement
1.2 System Design
1.1 Program Coordination
1.6.1 Component Integration1.6.2 System Integration
1.5.3 Instrumented Connectors
1.5.2 Fault Tolerance Subsystem
1.2.1 Architecture1.2.2 Design
1.5.1 Migration Subsystem
1.5.5 Sample Application
1.3.2 Wrappers1.3.1 Lightweight Integrity Sensors
1.2.3 Interface Specification
1.4.1 Host Level1.4.2 Cluster Level
1.5.4 QCS Extensions
Specification Extension
TestingIntegrity Measures
CDL Extensions
Location TransparencyIntegrity Measures
Testing
Sensing
TestingControl Interfaces
Human Oriented Client ServerNRT Distributed Application
Options2.0 New ITS Technology Integration3.0 Auto-Generation of Integrity Comp4.0 Diagnosis and Recovery Extensions
Year 1 Year 2 Year 3 Year 4
1.4 Adpative Response Development
July 18, 2000 27
Milestones• Year 1
– Applications• Office• Email• Collaboration• Intranet web server
– Control• Specification based performance and integrity• Replication and switchover
• Year 2– Applications
• Simple planning application• Network-based military planning• Real time application
– Control• Detected intrusions• Limited restoration
• Options– Integration of new ITS technologies– Automatic generation of integrity monitors– Extensions for diagnosis and recovery
Note that these milestones are more aggressive than the
official SOW. Depending on the results of detailed design
effort, some adjustments may be necessary
July 18, 2000 28
Technology Transfer• Who needs intrusion tolerant server capabilities for critical
users and services – user pull– Government -- military and civilian– Commercial -- large corporations, ISPs and others who offer out-
sourced application services• Development and maintenance organizations for above
– Government development efforts (e.g., IO COP, GCCS)– Government ACTDs (e.g., AIDE, ACOA, CINC 21?)– Commercial security product/service providers (including
Teknowledge?) -- significant commercialization costs• Mechanisms
– Demonstrations– Ongoing communications– Publications– Code availability
July 18, 2000 29
Conclusions
• Ready to start• Very ambitious goals
– Leveraging other efforts will help– Downscoping may be required– Better insights after detailed design
• Questions
July 18, 2000 30
Backup
July 18, 2000 31
Technical Plan• Decide on assumptions for the environment to be
supported, i.e., decide on the application domain.• Decide on the intrusion types to be accommodated
initiallly. • Develop the overall architecture.• Decide on a set of intrusion tolerance paradigms to be
mechanized as part of the architecture.• Using COTS hardware and software, and available tools in
support of security (including intrusion detection tools) and fault-tolerance, develop a prototype system. To a significant extent, Quorum tools will be used.
• Develop an experimental plan to demonstrate the advances offered by our system.
July 18, 2000 32
Intrusion Tolerance Paradigms• Error detection• Error analysis• Intrusion confinement through separation of
processes• Checkpointing in support of backups• Switchover to a backup• Achieving attack resistance in components that
support intrusion tolerance, i.e., avoiding a hard core.
• Recovery of the primary and reinstatement of its service
July 18, 2000 33
Hierarchy of Sensing & Control
Level Sensors Control
Network & FW
Platform
Cluster
Multi-cluster, CC2, DASSA
July 18, 2000 34
Plans: Capability MilestonesCapability Jan 00 July 00 Jan 01