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 - [email protected]
Top Related