1 APOD 05/09/2003 ISORC 2003

Applications That Participate In Their Own Defense (APOD):

Adaptive Use of Network-Centric Mechanisms in Cyber-Defense

Michael Atighetchi

Partha Pal, Franklin Webber, Christopher Jones{matighet,ppal,fwebber,ccjones}@bbn.com

2 APOD 05/09/2003 ISORC 2003

Outline

• Motivation– Defense Enabling

• APOD Technology– Toolkit to defense-enable applications

• Network-Centric Adaptive Defenses– Strategies, Tactics and Mechanisms

• Validation– Red-Team Experiments

• Concluding Remarks

3 APOD 05/09/2003 ISORC 2003

Evolution of Cyber Security Paradigms

• 1st generation: Prevent attacks– build an impenetrable static fortress through policy enforcement– Lesson: Impossible to build, Result is non-interoperable, brittle and expensive systems, New attacks continue to evolve

• 2nd generation: Detect attacks– augment policies by intrusion detection systems– Lesson: Novel attacks, false positives and false negatives, many are post-facto

• 3rd generation: Survive attacks– Prevent as best as possible, but assume some attacks will succeed, at least partially, and deal with the attack effects– Defense enabling: adaptive application-level responses to engage the attacker, and to tolerate and recover from (partially) successful attacks

4 APOD 05/09/2003 ISORC 2003

Defense Enabling a Distributed Application

ApplicationHost 1

•Survivability Aspects–Dynamic defenses and adaptive responses increase application resiliency to attacks=> operate through attacks

–Wide range of network and host-based adaptive defenses

•Survivability Toolkit–Strategies

–Tactics

–Mechanisms

•Adaptive Late-Binding Middleware

–QuO encapsulates defenses into reusable configurable components

Attacks

ApplicationHost 2

ApplicationHost 3

5 APOD 05/09/2003 ISORC 2003

Foundation of Adaptive Behavior

• QuO is a middleware framework that supports the development and execution of adaptation and adding it to an application. QuO is used for coordination and integration of network defenses in APOD.

• Adaptation can be driven by changes in an application’s operating environment.

– Host resources (CPU and memory usage)– Network resources (bandwidth, connectivity)– Host and Network Intrusion status– Replication Management

• Adaptive code is encapsulated in a middleware component called “qosket”.

– A qosket is a set of specifications and implementations that defines a reusable module of specific adaptive behavior.

• Qoskets can be added to a distributed object application with minimum impact on the application.

6 APOD 05/09/2003 ISORC 2003

Quality Objects(QuO) Architecture

ApplicationDeveloper

MechanismDeveloper

CLIENT

Network

operation()

in args

out args + return value

IDLSTUBS

IDLSKELETON

OBJECTADAPTER

ORB IIOP ORBIIOP

CLIENT OBJECT(SERVANT)OBJECT(SERVANT)

OBJREF

CLIENT

DelegateContract

SysCond

Contract

Network

MECHANISM/PROPERTYMANAGER

operation()

in args

out args + return value

IDLSTUBS

Delegate

SysCond

SysCond

SysCond

IDLSKELETON

OBJECTADAPTER

ORB IIOP ORBIIOP

CLIENT OBJECT(SERVANT)OBJECT(SERVANT)

OBJREF

ApplicationDeveloper

QoSDeveloper

MechanismDeveloper

CO

RB

A D

OC

MO

DE

LQ

UO

/CO

RB

A D

OC

MO

DE

L

Qosket

7 APOD 05/09/2003 ISORC 2003

Adaptive Strategies

• Coordinate the defense among the set of distributed application parts to form a coherent defense posture

– Overall Goal: Use protection and slow down attacker throughadaptive responses

• Strategy Examples:– “outrun”: move application components off corrupted hosts and on to

good ones at a rate faster than the hosts go bad.– “contain”: quarantine bad hosts and bad LANs by limiting or blocking

network traffic from them and, within limits, shutting them down.» Respond quickly with locally gathered information.» Can only quarantine so many hosts or LANs before application

performance becomes affected.» In follow on projects we are looking at having backup hosts to replenish

application capabilities depleted by quarantining bad application hosts.– “keep changing unpredictably”: quickly outdate information gathered

by the attacker.

8 APOD 05/09/2003 ISORC 2003

APOD Tactics Overview

• APOD tactics integrate sensors and actuator mechanisms to mount a local defensive response.

• 4 tactics have been developed so far linking sensors to actuators:

– Blocking Suspicious Traffic

– Choking TCP Connection Floods

– Containing ARP Cache Poisoning

– Squelching Insider Floods

Detect

Snort alert#con > threshARP corruptionoutbound flood

React

block IP sourceblock IP sourceblock MAC sourcerate limit

9 APOD 05/09/2003 ISORC 2003

Example Tactic: Squelching Insider Floods

• Uses network traffic accounting to keep track of packets/second and bits/second, and comparing means between observed and expected to determine a spike in outgoing traffic.

• If spike occurs, rate limiting is applied to outgoing traffic of a LAN.

Client

Server

Inside Attacker

Router Router

BoundaryController

Flood

Other Client

10 APOD 05/09/2003 ISORC 2003

Other Tactics Used in Validation

• Block Suspicious Traffic– Combines network intrusion detection system and firewall

mechanisms to catch attacker reconnaissance traffic and block further malicious traffic from the attacker host.

• Choking TCP Connection Floods– Joins TCP Connection counting with a firewall to block hosts that

request large numbers of connections to a single port.

• Containing ARP Cache Poisoning– Incorporates an ARP cache poisoning sensor and firewall to

monitor mapping of MAC to IP addresses and resets any mapping if they change as well as blocking traffic from offending MAC address.

11 APOD 05/09/2003 ISORC 2003

APOD Mechanisms - Sensors

• Sensors provide information to higher level defenses such as tactics

• Sensors are integrated into APOD by wrapping existing COTS sensors via QuO System Condition Object.

• List of sensors deployed in validation experiment:– Network Intrusion Detection: Snort– TCP Connection Flood: Netstat– ARP cache poisoning: ping, arp

12 APOD 05/09/2003 ISORC 2003

APOD Mechanisms - Actuators

• Actuators allow higher-level defenses to control resources in their environment in response to attacks

• Actuators are incorporated by wrapping existing COTS actuators via QuO System Condition Object.

• List of actuators used in validation experiment:– Network Traffic Filters: Linux iptables firewall– Bandwidth Management

» IntServ : RSVP, SecureRSVP» DiffServ: Bandwidth Broker

– VPNs: FreeS/WAN IPsec

13 APOD 05/09/2003 ISORC 2003

Developing Survivability Solutions

Runtime Cost / Complexity

Mechanisms

Tactics

Strategies

Multi-Layered Defenses

local distributed Coordinateddistributed

14 APOD 05/09/2003 ISORC 2003

Putting It All TogetherAbstraction Layer

Mechanism

Localized Tactic

Sub-Strategy

Overall Strategy

Snort, Iptables, NetstatIproute2, Shutdown

M1 M1 M1

M1

SERSVP, IPsec, OO-DTESelf-stabilizing Software Bus

Outrunning Component FailuresAttack ContainmentContinuous Unpredictable Changes

DefenseComplexity

Protect As Best As PossibleSlow Down Attacker Through Adaptive Responses

local distributed coordinated distributed

M1M2

M1M3

M1M2

Bus

Squelching Insider FloodsPort & Address HoppingBandwidth Broker

Blocking Suspicious TrafficContaining ARP Cache PoisoningChoking TCP Connection Floods

15 APOD 05/09/2003 ISORC 2003

APOD Red-Team Experiments

• Reasons for experiments– Validate APOD idea that dynamic adaptation defenses can prolong

an applications usefulness in a hostile environment

– Also, analyzing the overhead of APOD

• Sandia Labs Red-Team tasked with validating APOD– Outside, independent team

– Given full knowledge of application, APOD defenses added, and test network

• White-Team responsible for experiment executing and analysis

– Outside, independent team

– Measurement of metrics and post-experiment analysis

• Red-teaming happened in two distinct experiments

16 APOD 05/09/2003 ISORC 2003

Red-teaming Attacks and Results

• APOD defenses blocked or impeded the red-team’s progress.

– APOD defenses overcame or blocked many of the single attack runs.– The red-team was forced to combine different attacks to cause a

denial of service of the broker on the defense enabled application.– Of the attack runs that ended with the application in a denial of

service, the average time-to-denial was approximately 45 minutes from start of attacks, with a minimum of roughly 10 minutes. Without APOD defenses, service was denied immediately.

Time to Denial by Live Attack

0

10

2030

40

50

60

7080

90

100

Tim

e (

min

ute

s)

client 2 client 3

Runs

17 APOD 05/09/2003 ISORC 2003

Results

• The runtime overhead of adding the APOD defenses was approximately 5% to 20% to call latency depending which tactics and strategies were in place.

– We concluded that most of the latency increase was caused by the containment strategy and accompanying mechanisms that ran on the boundary control routers.

18 APOD 05/09/2003 ISORC 2003

Concluding Remarks

• Conclusion:– Dynamic adaptation has added value for an application by

prolonging its ability to provide useful service in the presence of attacks

– This is achieved at a reasonable runtime overhead– Red-Team experiments have been used for validating and “stress

testing” our defenses.

• APOD is being used in other survivability projects: – Using and expanding of APOD mechanisms, tactics, and strategies. – Other projects include ITUA, DPASA, and Dynamic Quarantine.

• Websites:– QuO: http://quo.bbn.com for Base Adaptive Middleware– APOD: http://apod.bbn.com for Defense Enabling Toolkit– ITUA: http://itua.bbn.com for Byzantine Unpredictable

Replication– Questions: Michael Atighetchi - matighet@bbn.com