1 dependable intrusion tolerance alfonso valdes (valdes@sdl.sri.com) magnus almgren, dan andersson,...
Post on 26-Dec-2015
214 Views
Preview:
TRANSCRIPT
1
Dependable Intrusion Tolerance
Alfonso Valdes (valdes@sdl.sri.com)
Magnus Almgren, Dan Andersson, Steve Cheung, Bruno Dutertre, Yves Deswarte, Hassen Saïdi,Tomas Uribe
July 2001
AcknowledgementsResearch sponsored under DARPA Contract N66001-00-C-8058. Views presented are those of the authors and do not represent the views of DARPA or the Space and Naval Warfare Systems Center
2
Dependable Intrusion Tolerance
Intrusion Detection to Date Seeks to detect possibly infinite
number of attacks in progress Relies on signature analysis and
probabilistic (including Bayes) techniques
Response components immature No concept of intrusion tolerance
New Emphasis Detection, diagnosis, and
recovery Finite number of attacks or
deviations from expected system behavior
Seek a synthesis of intrusion detection, unsupervised learning, and proof-based methods for the detection aspect
Concepts from fault tolerance are adapted to ensure delivery of service (possibly degraded)
3
Outline
Architecture overview Initial implementation experience Simulation analysis of response tradeoffs (5 minute talk at
Oakland Conference) On-line verifiers (Tomas Uribe/Hassen Saïdi)
4
Architecture
e EMERALD Network ApplianceSensor SubnetProxy-AS SubnetExternal traffic
e e2
AppServer
AppServer
AppServer
AppServer
Proxy
5
Archtecture (2)
Proxy
e e2
AppServer
AppServer
AppServer
AppServer
e EMERALD Network ApplianceSensor SubnetProxy-AS SubnetExternal traffic
Proxy
Proxy
Proxy
6
The Sensor Picture
Application Server
EMERALDHost
Monitor
Critical APP
EMERALDAPP
Monitor
Proof BasedTrigger
Tolerance Proxy
EMERALDHost
Monitor
Proxy function
On-Line Verifier
IDS Network Appliance
EMERALDAMI
Net Experts
BlueSensor
eBayes-TCP
Application Server
EMERALDHost
Monitor
Critical APP
EMERALDAPP
Monitor
Proof BasedTrigger
Application Server
EMERALDHost
Monitor
Critical APP
EMERALDAPP
Monitor
Proof BasedTrigger
Application Server
EMERALDHost
Monitor
Critical APP
EMERALDAPP
Monitor
Correlation
Note: The Net appliance has a passive interface for the network traffic. Net appliance and app servers have write-only access to sensor subnet (for alert reporting). Proxies use sensor subnet for alert reporting and management.
e
7
Proxy Implementation
Built as module in Squid proxy
Squid functionality:
Accept HTTP connection
Read client HTTP request
Check ACLs
Load balancing
Send reply to client
New functionality
Interface to sensor subsystem to change policy if needed
Check content agreement (depends on dynamic policy)
Alert the sensor subsystem if content disagrees
8
Ensuring Correct Content
In agreement modes, we compare content from more than one APP server
For efficiency and bandwidth, we actually check MD5 checksums for all polled servers
If these agree, we obtain content from one of the servers and actually verify the MD5 at the proxy
If this agrees with the previous MD5 check, the content is forwarded to the client
For efficiency, we get MD5 only from all but one and MD5 plus the full body of the request from the remaining server. Then if the tests succeed, the proxy already has the content and we save one request
9
Four policy levels Benign - 1 GET request
Duplex (default regime at system start)
1 HEAD (get MD5 only) and 1 GET (MD5 plus content).
If MD5 agree, send content to client
Otherwise, go to Triplex
Triplex -
2 HEAD- and 1 GET-request.
If MD5 all agree, send content to client. If majority obtained, consider minority AS COMPROMISED. Send content to client, rebuild AS, continue Triplex
Full Agreement - Not implemented yet
Transition to a more permissive regime after some time of normal activity
10
Simulation Analysis
System is modeled as 14 Poisson processes Processes include client requests, server replies, challenge/response
requests (from proxy, to assess content validity), random failures, attacks (which make transitions between attack states), IDS false alarms, IDS detections,...
Process rates are state dependent Requests, attacks, failures always ON. Response process is ON if there are
active requests. False alarms are always ON, detections are ON if there are active attacks in a detectable state.
System performance is based on true state. Tolerance response is based on sensor reports
Responses include various levels of content agreement as well as server reboot
Objective: Minimize dropped requests and requests with invalid replies (the latter come from a root-compromised app server)
All tolerance responses have a cost with respect to these objectives, but not responding can also cost
11
Initial Results
Requests arrive at 1000/unit time. Total reply capacity is 4000/unit time. Attack rate is 50/unit time.
Redundancy is beneficial, but diminishing returns beyond 2 App Servers (Total server capacity is 4000/unit time)
Frequent challenge/response requests improve system objectives
App Servers % Drop % Invalid1@4000/time 3.62 2.78
2@2000/time each 0.04 1.263@1333/time each 0.16 0.594@1000/time each 0.99 0.51
Challenge % Drop % Invalid0 0 26.21
100 0.43 1.89500 0.99 0.51
1000 0.31 0.33
12
Status and Plans
Status (end of year 1) Architecture definition Continually refining specification Clarification of the sensor landscape Initial implementation of Single proxy system (static content) Specification of on-line verifiers
Plans - Multi-proxy system Additional protocols such as challenge/response Dynamic Content Implement on-line verifiers
13
Summary
Exploring response tradeoffs as part of a larger dependable intrusion tolerant system study
Explicitly model shortcomings of foreseeable IDS technology with respect to false alarms, missed detections, inaccuracy, and delay
Considering emerging correlation and asset distress monitoring technologies
Recognize that actions have a cost, but no response has a cost as well
Gives some idea of value of redundancy, enforcing agreement, rebooting servers, etc. with respect to some figure of merit
14
(Backup) Poisson Processes
Poisson process: Event stream where inter-event times have an exponential distribution. Parameter is referred to as the process rate, typically denoted
Mathematical properties of multiple simultaneous Poisson processes lead to tractable implementation:
Overall process is Poisson, with overall rate equal to the sum of the rates of the individual processes
Next event is of a given class with the following probability:
overall ii
P Next event is of class i i
overall
15
Proxy Capabilities Simulated
IDS detect probes and root compromises, but occasionally fail to detect or are too slow, or generate false alerts
Asset distress monitor (blue sensor) can detect a “down” server by rate of failed requests
Proxy detects AHBL when request queue overflows Challenge/Response: Periodically issues a request to all servers,
for which the reply is known Can detect compromised server if reply is invalid Can detect a “down” server These detections are typically much later than from an IDS
Available responses are: Invoke a content agreement regime for client requests with 2..n
servers Reboot a server
16
Processes and Rates
Process Rate per unit time CommentRequest 1000
Reply 4000 totalActive if there are active requests
Challenge/Response 500
Compete with client requests for server bandwidth
Non-malicious crash 1
Reboot 100So E(reboot time)=0.01
Probe attack 50Probe_to_root 10Probe_to_crash 5Probe_to_term 5Root_to_crash 5
Root_to_term 5Attack in this state compromises host
Probe_detect 10
Root detect 50Must detect before root_to_term
False Detect 5
Note: Time units not specified. These rates should be viewed as relative.
top related