Transcript PowerPoint no sound - Applications that Participate in their Own

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
1 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
2 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 postfacto
• 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
3 APOD 05/09/2003
ISORC 2003
Defense Enabling a Distributed Application
•Survivability Aspects
–Dynamic defenses and adaptive
responses increase application
resiliency to attacks
=> operate through attacks
–Wide range of network and
host-based adaptive defenses
Attacks
•Survivability Toolkit
Application
Host 1
–Strategies
–Tactics
–Mechanisms
•Adaptive Late-Binding
Middleware
–QuO encapsulates defenses
into reusable configurable
components
4 APOD 05/09/2003
ISORC 2003
Application
Host 3
Application
Host 2
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.
5 APOD 05/09/2003
ISORC 2003
CORBA DOC MODEL
Quality Objects(QuO) Architecture
in args
CLIENT
OBJECT
operation()
OBJ
REF
(SERVANT)
out args + return value
IDL
SKELETON
IDL
STUBS
ORB
Network
IIOP
IIOP
in args
QUO/CORBA DOC MODEL
Application
Developer
CLIENT
(SERVANT)
out args + return value
Delegate
Qosket
SysCond
SysCond
IDL
MECHANISM/PROPERTY
MANAGER
SKELETON
STUBS
6 APOD 05/09/2003
IIOP
Network
ISORC 2003
QoS
Developer
SysCond
SysCond
ORB
Application
Developer
Contract
Contract
Delegate
IDL
Mechanism
Developer
ORB
OBJECT
operation()
OBJ
REF
OBJECT
ADAPTER
IIOP
ORB
OBJECT
ADAPTER
Mechanism
Developer
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 through
adaptive 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.
7 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
8 APOD 05/09/2003
Detect
React
Snort alert
#con > thresh
ARP corruption
outbound flood
block IP source
block IP source
block MAC source
rate limit
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.
Inside Attacker
Flood
Router
Router
Boundary
Controller
Client
9 APOD 05/09/2003
Server
Other Client
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.
10 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
11 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
12 APOD 05/09/2003
ISORC 2003
Developing Survivability Solutions
Strategies
Tactics
Runtime Cost / Complexity
Mechanisms
Multi-Layered Defenses
local
13 APOD 05/09/2003
ISORC 2003
distributed
Coordinated
distributed
Putting It All Together
Abstraction Layer
Protect As Best As Possible
Slow Down Attacker Through Adaptive Responses
Overall Strategy
Outrunning Component Failures
Attack Containment
Continuous Unpredictable Changes
Sub-Strategy
Localized Tactic
Blocking Suspicious Traffic
Containing ARP Cache Poisoning
Choking TCP Connection Floods
Squelching Insider Floods
Port & Address Hopping
Bandwidth Broker
Mechanism
Snort, Iptables, Netstat
Iproute2, Shutdown
SERSVP, IPsec, OO-DTE
Self-stabilizing Software Bus
local
distributed
M1
M1
Defense
Complexity
coordinated distributed
M1
M1
M2
M1
M3
Bus
M1
14 APOD 05/09/2003
ISORC 2003
M1
M2
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
15 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
(minutes)
Time to Denial by Live Attack
100
90
80
70
60
50
40
30
20
10
0
Runs
client 2
16 APOD 05/09/2003
ISORC 2003
client 3
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.
17 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]
18 APOD 05/09/2003
ISORC 2003