180 likes | 287 Views
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. Outline. Motivation Defense Enabling APOD Technology
E N D
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
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 • 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 • 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 • 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.
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 • 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.
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 • 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 • 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 • 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 • 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
Strategies Tactics Mechanisms Developing Survivability Solutions Runtime Cost / Complexity Multi-Layered Defenses local distributed Coordinated distributed
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 • 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
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 • 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 • 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