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