Transcript DETER overview - Information Sciences Institute

Overview:
Cyber Defense Technology
Experimental Research (DETER)
Testbed
Terry V. Benzel, C. Neuman
Information Sciences Institute
University of Southern California
1
DETER Team
• USC – ISI
– Terry Benzel, Bob Braden, Dongho Kim, Cliff Neuman
• UC Berkeley
– Eric Fraser, Anthony Joseph, Keith Sklower
• Sparta
– Ron Ostrenga, Steve Schwab
2
AGENDA
8:30 Welcome: Dr. Joseph Evans, NSF, and Dr. Douglas Maughan, DHS
8:45 DETER/EMIST Overview: Terry Benzel, USC – ISI, George Kesidis,
Penn State
9:30 DETER Workbench: Bob Braden, USC – ISI
ESVT: A Toolkit Facilitating use of DETER: Peng Lui, Penn State
[10:00 – 4:00] Parallel Hands-on Demo and Experiments in Conf
room
10:00 Using Source Models to Evaluate Enterprise Worm Defenses:
Nick Weaver, Vern Paxson, Scott Crosby, ICSI
10:45 Break
11:00 Requirements and Tools for Routing Experiments:
Sandy Murphy, Sparta, S. Felix Wu, UC Davis
11:45 lseb: Trace Drive Modeling of Internet-Scale BGP Attacks
and Countermeasures:
Patrick McDaniel, Penn State
12:15 Lunch
3
AGENDA (continued)
1:15 Evaluation of Worm Defense Systems Through Experimentation:
Karl Levitt, Jeff Rowe, UC Davis, Phil Porras, SRI
2:30 DDoS Defense Experiment Methodology -- Impact of Traffic
Generation
Selection on Precision of Detection and Response Characterization:
Stephen Schwab, Sparta Inc
3:15 Break
3:30 Methodology and Tools for High-Fidelity Emulation of DDoS Attacks
Sonia Fahmy, Purdue University
4:15 Cyber Early WArning System (CEWAS):
Abhrajit Ghosh, Rajesh Talpade, Sudha Ramesh, Telcordia
4:45 General Discussion and Q&A
5:00 Adjourn
4
Project Background
• DETER and EMIST are two companion efforts
• George Kesidis will overview EMIST
• Period of Performance Sept. 03 – Aug. 06
• Funded by NSF and DHS HSARPA
• Joe Evans NSF, Doug Maughan DHS PM’s
• Operating as one unified project
5
DETER+EMIST Vision
... to provide the scientific knowledge required to
enable the development of solutions to cyber
security problems of national importance
Through the creation of an experimental infrastructure
network -- networks, tools, methodologies, and supporting
processes -- to support national-scale experimentation on
research and advanced development of security
technologies.
6
DETER Testbed Goals
• Facilitate scientific experimentation
• Establish baseline for validation of new approaches
• Provide a safe platform for experimental
approaches that involve breaking network
infrastructure
• Create researcher- and vendor-neutral environment
• Provide access for wide community of users
7
Experiment Methodology and
Security Workbench
TOPOLOGY
?
TRAFFIC ATTACK DATA-CAPTURE
PALETTESs
METHODOLOGY
& GUIDANCE
EXPERIMENT
AUTOMATION
Experimenter’s select from a palette of
predefined elements: Topology,
Background and Attack Traffic, and
Packet Capture and Instrumentation
Our Methodology frames standard,
systematic questions that guide an
experimenter in selecting and
combining the right elements
Experiment Automation increases
repeatability and efficiency by
integrating the process to the DETER
testbed environment
8
DETER Architectural Plan
• Construct homogeneous emulation clusters
based upon University of Utah’s Emulab
• Implement network services – DNS, BGP
• Add containment, security, and usability
features to the software
• Add (controlled) hardware heterogeneity
• Specialized devices – Routers, IDP, IPS, black
boxes
9
DETER Experimental Network
Based On Emulab
Cluster of N nearly identical experimental
nodes, interconnected dynamically into
arbitrary topologies using VLAN switches.
Pool of N processors
PC
PC
PC
160
N x 4 @1000bT
Data ports
Switch Control
Interface
Programmable Patch Panel (VLAN switch)
10
Example DETER Topologies
11
Testbed Software
Begin with Utah’s Emulab software.
 Add containment, security, and usability features
 Collaborate with Utah on new development
User access: Web interface [Emulab] to define,
request, control an experiment.
Encrypted tunnels across Internet
(SSL/SSH/IPsec)
 No direct IP path into experimental network.
12
User
Internet
DETER Testbed
Cluster Architecture
Control
DB
Ethernet Bridge
with Firewall
‘User’ Server
User
files
User Acct &
Data logging
server
Web/DB/SNMP,
switch mgmt
Boss
VLAN
Users
VLAN
Router
with Firewall
Node Serial
Line Server
…
Master Server
External
VLAN
Control Hardware
VLAN
Power Serial
Line Server
Control Network VLAN
139 Control ports
PC
PC
PC
160
139 x 4 @1000bT
Data ports
Power
Controller
Switch Control Interface
Programmable Patch Panel (VLAN switch)
13
Interconnecting Clusters
Two clusters: USC -ISI, UCB
One control site (ISI)
– One user entry point, accounts, control
Connection
– CENIC: CalREN-HPR
VLAN switches interconnected using IPsec tunnels
– Form one pool of nodes to be allocated
– User can control whether span multiple clusters
14
User
Internet
FW
ISI Cluster
FW
UCB Cluster
User
files
‘User’
Server
'Boss'
Server
Download
Server
Node Serial
Line Server
Node Serial
Line Server
PC
IPsec
Control Network
PC
…
PC
Power
Cont’ler
Control Network
Power
Cont’ler
PC
…
PC
IPsec
Cisco and Nortel switch
trunk
trunk
Foundry and Nortel switch
15
Hardware Status and Plan
ISI
64 x IBM
pc733
11 x Sun
pc2800
Cisco 6509
64 x Dell
pc3000
2x
Juniper
IDP-200
8 x 1Gbps
5x
Juniper
M7i
4 x 1Gbps
1x
Cloud Shield 2200
4 x 1Gbps
2x
McAfee
Intrushield 2600
2 x 1Gbps
80 x Dell ?
Nortel 5510
1 GBps (4 later)
~150Mbps with IPSec
UCB
30 x Sun
bpc2800
32 x Dell
bpc3000
40 x HP
64 x Dell ?
Nortel 5510
Foundry 1500
1 GBps (4 later)
16
Handling Scary Code
Objective: Variable-safety testbed
– Adaptable to threat level of experiment
– Supports shared, remote experimenter access for lowthreat code; varying degrees of isolation.
– Research question: can we design DETER to safely handle the
entire range of threats, or will really scary stuff have to run in some
other isolated containment facility?
Security
Usability
DETER
?
Isolated
Containment
Emulab
17
DETER Testbed Security is Critical
• Defenses employed by the test-bed must
balance the requirements of containment,
isolation, and confidentiality, with the need for
remote management of experiments.
• Experiments will be categorized according to the
consequences of loss of containment, and
procedures applied according to that
categorization.
18
Achieving Security
Operational
–
–
–
–
Procedures for proposing and reviewing experiments.
Guidelines for categorizing safety of experiments.
Vetting of investigators and experiments
Procedures used by investigators
Technical
– Firewall, routing, intrusion detection and network
isolation techniques.
– Data protection, system protection, and state
destruction techniques.
19
Experiment Safety Panel
• Experiment description provided by investigator:
– Identify containment, isolation, confidentiality, and
other security considerations.
• Panel assesses proposed category:
– Determines safety category, level of isolation required
– Assesses if isolation can be maintained
– Imposes technical measures to assure isolation
requirements are met.
20
Security Consideration Matrix
Threat from experimental agents
A1
A2
A3
A4
-- Attack traffic trace analysis
-- Simulations that generate attack traffic
-- DDoS attacks and tools in circulation
-- Previously released viruses and worms
- still in circulation, eradicated, or
defenses deployed
A5 -- Current/new viruses, worms, DDoS, etc
- moderate to severe threat
- defenses not broadly deployed
Impact of the experiment
I1 -- Minimal traffic generation or
performance degradation
I2 -- High but bounded traffic
I3 -- Flooding of single link or site
I4 -- Floods network and severely
degrades performance
Management requirements
M1
M2
M3
M4
-- Disconnected from Internet
-- Self-contained batch mode acceptable
-- Remote submission and collection
-- Remote real-time monitoring and control of
parameters
M5 -- Full remote control needed
for interactive experimentation with high
bandwidth needs
Sensitivity of experiment data
S1 -- Results eventually to be open
S2 -- Results commercially sensitive
S3 -- Results extremely commercially
sensitive -- disclosure gives a
way proprietary approaches
S4 -- Results extremely safety sensitive-instructive to those trying to
breach security
21
Containment Mechanisms
• Physical separation
– Transfers in and out when experiments not running, perhaps via
physical media.
• Virtual separation
– VPN’s and network overlays allow secure connectivity over
Internet.
• Firewalled separation
– Connectivity may be reduced when experiments are running.
• Decontamination procedures
– After an experiment runs
– When data is removed from testbed
22
DETER Experimenters Community
•DETER testbed is itself an important
research and engineering problem
•Do not expect a ready-made “turnkey”
platform
•Expect to become active participants in the
community of security researchers
•Help shape the development of the DETER
testbed.
23
Access to Testbed
• Open to community – request via email:
[email protected]
• Important addresses:
– www.isi.edu/deter
– www.isi.deterlab.net
– http://emist.ist.psu.edu
– www.emulab.net
• Hiring – email [email protected]
24