Transcript Enterprise Security - Department of Computer Science

Enterprise Worm Mitigation-A Community of Interest based approach
Bill Aiello
Computer Science
UBC
CASCON 2005
1
The Network Effect for (In)Security
•
Where were we twenty years ago?
–
–
•
Since then, IP and the Internet have grown exponentially and surpassed the
PSTN, Frame and ATM. Why?
–
–
–
•
Internetworking/Interoperability: IP originally designed to “glue” together different
layer 2 and layer 3 technologies
Open access: Access is not controlled by a single administrative domain. It is not a
closed user group
Control plane and data plane carried over same network fabric: Allows disparate
network services to be integrated
These combine to create the Network Effect
–
•
PSTN: signaling over a separate network
Layer 2 data networks: single administrative domain, closed user group
Once an open network has a large number of nodes with whom to communicate and
a large number of services, new hosts have a great deal of incentive to connect to the
network
The flip side--the Network Effect for (In)Security
–
For each new host connected to the network, every other host is a potential attacker
and every network service is a potential attack point.
Securing an integrated, packet-based IP network is a much more complex task
than securing segregated/circuit switched networks
CASCON 2005
2
IP Network Security Vulnerabilities
IP Protocol Vulnerabilities:
–
No admission control for “data” services
•
–
Weak source authentication in:
•
–
Susceptible to flooding attacks
UDP/TCP protocols, routing table update protocols, Domain Name Service protocols
Protocols/mechanisms for authentication and QoS must be added on top of
basic protocol suite for some services
Software Vulnerabilities:
–
Frequent implementation errors in OSes, protocols and applications
•
•
–
Cause of the large majority of security incidents
An unfortunate fact of life for the foreseeable future
An accurate and up-to-date software inventory and a well-defined change
control process are needed
Configuration Vulnerabilities
–
Syntax for configurations are low level, complex and vendor specific
•
–
Configuration provisioning is currently prone to error
Scalable, vendor agnostic automated provisioning and management tools are
required.
CASCON 2005
3
Security Threats
•
Base Vulnerabilities + the Network Effect for Insecurity make
large-scale automated attacks possible
– Worms, Viruses, and DDoS
•
Unmanaged complexity gives hackers additional opportunities
– Software modules are very large and complex
– Individual hosts require great care to manage--few are receiving
such care
• Timely software updates
• Proper configurations
– Networks are very large, very complex, very heterogeneous, very
hard to manage
– Network perimeter is disolving
– Evolution from client-server to automated workflow
•
Hackers take advantage of all this complexity and chaos
– Install zombies, trojan horses, backdoors
– Use as launch points for DDoS attacks, worms, spam
•
Routing infrastructure attacks a looming threat
CASCON 2005
4
Security—Why so complicated?
The Network Security Matrix
Cryptography & Software Eng
Protocol Security
Host & Software Security
Security/Config Provisioning
IP Backbone, IP Access Networks
System Monitoring, Detection and
Mitigation
Traffic Monitoring, Detection,
Mitigation
5
CASCON 2005
Security Architecture
Security Assessment
UDP/TCP
Statistics, AI & Adaptive Methods
Design &
Deployment
Management &
Service
Managed IP
Access
MPLS
VPN
IPsec
VPN
Media
Signaling
Security/Config Management
End-to-End Services/Applications
Current Initiatives
• Enterprise-level Worm Mitigation
• Enterpise-level virus mitigation through host diversity
• ISP-level DDoS Mitigation
– Traffic Anomaly Detection, control and data plane correlation
• ISP & Enterprise Configuration Provisioning & Management
• VoIP Security
• Interdomain Routing Security
CASCON 2005
6
Viruses,Worms, DDoS
•
Worms and Viruses
– Many sources, many destinations
– Carriers have mixed incentives to block or thwart them
– Enterprises feel the most pain from worms and viruses and thus
have a lot of incentive
•
DDOS
–
–
–
–
–
Many sources, few destinations
exhaust b/w on a link
exhaust server resources
Enterprise has few tools to combat DDoS attacks
ISP may have some tool and it has incentives to do so
• Main idea: Deploy farms of resources, e.g., scrubbing farms, email server
farms, etc. Reroute attack traffic through shared resources.
CASCON 2005
7
Enterprise Pain
•
Enterprises are feeling the most pain from viruses and
worms
– Carriers have mixed incentives to block virus and worm
propagation in their networks
• + marketing
• - hard to do it in a way that doesn’t break real applications
•
Two main problems
– Large monocultures of complex, vulnerable code
– The enterprise lan and enterprise desktops are complete
chaos
•
Our main approach
– Restriction of lan and desktop behavior
CASCON 2005
8
Beyond Communities of Interest
Reducing Desktop Chaos
•
Potential Enterprise Restrictions
A. Software download: restrict and enable automated up-to-date
database view
–
Can be done for Windows 2000/XP
B. Software configuration: automate provisioning and enable database
view
•
Need strong config management tools
C. Communities of interest:
•
•
•
•
Most desktops only need to talk to a handful of servers
Desktops almost never need to talk to other desktops—but this is
precisely how many worms propagate
Restrict Who x who x what on the LAN
These restrictions can be automatically coupled to the applications
and configuration of each desktop
–
•
E.g., a desktop can only talk to one email server and that server is governed
by the email client installed on that machine.
All policies and meta data should be stored and managed in
centralized databases
–
–
Policies may allow user to “auto-provision” through, say, a Web
interface for some resources
But user choices are recorded in central database
CASCON 2005
9
Restricting LAN Connectivity
•
Smart Hub—Reverse Firewall
– Transparent to PC and rest of network
• Looks like an ethernet hub to other devices
– Layer 3 and 4 aware
• Enforces connectivity policies based on layer 3 and 4 (and possibly app
layer) info
– Capabilities
• Filtering (firewaling)—particularly traffic from a PC
• Connection and/or rate limiting
• monitoring/analyzing and reporting
– Philosophy—centralized policy, distributed enforcement
– Goal: protect hosts and servers from an infected host A if they
don’t communicate with A in the course of normal business
Mgmt proc
PC
IP1,
MAC1
IP3,
MAC3
L3-aware
bridge
CASCON 2005
LAN
IP2,
MAC2
Router
10
Policies
•
•
•
Internal hosts--within the enterprise
External hosts--outside the enterprise
Firewalls: Protect internal hosts from potentially malicious
external hosts
– Rules for dropping or passing packets from external hosts to
internal hosts
– This doesn’t help during a worm outbreak that breaches the firewall
•
The worm perspective: internal hosts are also potentially
malicious
– Need rules for dropping or passing packets from internal hosts to
internal hosts
– Rules based on protocol, origin/client IP, dest/server IP, server port
•
Design space for rules. Three axes:
– Manageability, Usability, and Security
– We stick to simple manageable policies and explore their
usability/security tradeoffs
CASCON 2005
11
Greenfield vs Brownfield
•
•
In a greenfield environment may be possible to impose quite rigid
internal-to-internal communication policies
Our work aimed at a brownfield environment--an existing complex
enterprise network
–
–
•
Our work uses several weeks of training data to infer traffic profiles
–
–
•
Imposing simply and rigid rules will severely affect usability
Need automated methods for inferring existing, implicit rules
Capture ever packet header on a subnet, stitch packets together into flows
300 hosts, 4.5 Tbytes of data
High level issues
–
Security: Anomalous traffic in training data
•
–
Usability: legitimate traffic may be blocked if not in training data
•
•
Filter known anomalies in training set
Need to allow some out of profile traffic
Policies--two components
–
Profiles and throttling disciplines (rate of out-of-profile packets and the action
to take when the rate is exceeded)
CASCON 2005
12
Profiles
• Simple Profiles
– Protocol,Server,Client,Port (PSCP) Profile
• All four tuples in the training data
• Most closely resembles actual communication
– Protocol,Server,Client (PSC) Profile
• All three tuples in the training data
• E.g., if a client queried a server on a given port, the client could
subsequently query the server on any port
• Servers are mostly servers and clients and mostly clients
• Better usability but less security than the PSCP Profile
– Protocol,Sever (PS) Profile
• All the two tuples in the training data
• E.g., if any client queried a server, then every host can query
that server
CASCON 2005
13
Throttling Disciplines
• Trigger = threshold and window
– If the number of out-of-profile connections exceeds the
threshold within the window then an action is taken
Before a trigger
Block all traffic
Block out-ofprofile traffic
Allow out-ofprofile traffic
Strict
Relaxed
After a trigger
Block just out-ofprofile traffic
Open
CASCON 2005
14
Ephemeral Ports
• For a large number of applications, an original connection
to a server on a port launches a connection on a ~random
server port
– The latter is called an ephemeral port
• The most restrictive profile, PSCP, is doomed to have bad
usability
• The other profiles are too permissive to have good
security
• One lesson: need a profile that distinguishes between
ephemeral and non-ephemeral communication
• We use clustering algorithm to distinguish the two
– Non ephemeral communication is used to generate a PSCP
Profile
– Ephemeral communication is used to generate a PSC Profile
with a small caveat
CASCON 2005
15
Usability Simulations
•
•
•
Use data from test weeks
Set a profile
Set a throttling disciple with set threshold and window
– Thresholds of 0, 1, 5, 10, 15, 20
– Windows of 1 hour and 1 day
•
Set a reset time--time it takes the admin to reset a host after a
trigger
– 1 minute, 10 minutes, 1 hour
•
•
Simulation required to count the number of blocked
connections
E.g.: Relaxed TD, threshold of 10, window of 1 hr, reset time of
10 minutes
– Fewer than 10 blocked connections for all profiles at 50 percentile
– Fewer than 100 blocked connections for all profiles at 90 percentile
•
•
Strict < Relaxed < Open
Extended Profile decreases number of trigger events by ~50% at
50 percentile and ~20% at 90 percentile depending on TD
CASCON 2005
16
Security Simulations
•
•
•
Set a profile
Set a throttling discipline with threshold and window
Set a port for the simulated worm
– We used 25, 80, 53, 135, 137, 139, 443, 445
• Large number of exploits and actively monitored
•
Set a success rate s for a compromised host to infect another
vulnerable host in a round
– Models the ability of a worm to identify vulnerable hosts
– Most experiments done with s = 1%
•
•
•
•
Perform many trials, one for each randomly choosen initial host
Stop when no more hosts are infected
Measure number of hosts infected
Measure time to completion
CASCON 2005
17
Security Simulations
• For port 137, n = 10, s = 1%
• For strict and relaxed TD
– No more than 3 infected host on any run
– No more than 25 rounds on any run
for all of the profiles
• The open throttling discipline is a different story
– On some runs, the worm infected all vulnerable hosts
– On others, the worm was contained
– True for all profiles
CASCON 2005
18
Conclusion
• A combination of
– The extended profile
– The relaxed throttling discipline
Appears to have both reasonable usability and good
security properties
• Lots more work to test this preliminary conclusion and to
explore other profiles and throttling disciplines
CASCON 2005
19