Applications That Participate In Their Own Defense (APOD):
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

Michael Atighetchi Partha Pal, Franklin Webber, Christopher Jones PowerPoint PPT Presentation


  • 51 Views
  • Uploaded on
  • Presentation posted in: General

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,[email protected] Outline. Motivation Defense Enabling APOD Technology

Download Presentation

Michael Atighetchi Partha Pal, Franklin Webber, Christopher Jones

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Michael atighetchi partha pal franklin webber christopher jones

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


Outline

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


Evolution of cyber security paradigms

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


Defense enabling a distributed application

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

  • Survivability Toolkit

    • Strategies

    • Tactics

    • Mechanisms

  • Adaptive Late-Binding Middleware

    • QuO encapsulates defenses into reusable configurable components

Attacks

Application

Host 1

Application

Host 3

Application

Host 2


Foundation of adaptive behavior

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.


Quality objects quo architecture

in args

OBJECT

(SERVANT)

OBJECT

(SERVANT)

in args

Contract

Contract

CLIENT

CLIENT

OBJECT

(SERVANT)

OBJECT

(SERVANT)

operation()

OBJ

REF

out args + return value

IDL

SKELETON

IDL

STUBS

OBJECT

ADAPTER

Network

ORB

ORB

ORB

ORB

IIOP

IIOP

IIOP

IIOP

Network

Quality Objects(QuO) Architecture

Application

Developer

CORBA DOC MODEL

Mechanism

Developer

Application

Developer

CLIENT

CLIENT

operation()

OBJ

REF

out args + return value

Delegate

Delegate

QoS

Developer

Qosket

SysCond

SysCond

SysCond

QUO/CORBA DOC MODEL

SysCond

IDL

SKELETON

MECHANISM/PROPERTY

MANAGER

IDL

STUBS

OBJECT

ADAPTER

Mechanism

Developer


Adaptive strategies

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.


Apod tactics overview

Detect

Snort alert

#con > thresh

ARP corruption

outbound flood

React

block IP source

block IP source

block MAC source

rate limit

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


Example tactic squelching insider floods

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

Server

Client

Other Client


Other tactics used in validation

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

    • Incorporatesan 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.


Apod mechanisms sensors

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


Apod mechanisms actuators

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


Developing survivability solutions

Strategies

Tactics

Mechanisms

Developing Survivability Solutions

Runtime Cost / Complexity

Multi-Layered Defenses

local

distributed

Coordinated

distributed


Putting it all together

M1

M1

M1

M2

M1M3

M1

Bus

M1

M2

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

Blocking Suspicious Traffic

Containing ARP Cache PoisoningChoking TCP Connection Floods

Squelching Insider Floods

Port & Address Hopping

Bandwidth Broker

Localized Tactic

Defense

Complexity

Mechanism

SERSVP, IPsec, OO-DTE

Self-stabilizing Software Bus

Snort, Iptables, Netstat

Iproute2, Shutdown

local

distributed

coordinated distributed

M1


Apod red team experiments

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


Red teaming attacks and results

Time to Denial by Live Attack

100

90

Time

(minutes)

80

70

60

50

40

30

20

10

0

Runs

client 2

client 3

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.


Results

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.


Concluding remarks

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]


  • Login