AT

1
Enterprise Worm Mitigation-- A Community of
Interest based approach
Bill Aiello Computer Science UBC
2
The Network Effect for (In)Security

• Where were we twenty years ago?
• PSTN signaling over a separate network
• Layer 2 data networks single administrative
  domain, closed user group
• 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
• 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

3
IP Network Security Vulnerabilities

• IP Protocol Vulnerabilities
• No admission control for data services
• Susceptible to flooding attacks
• Weak source authentication in
• 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.

4
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

5
SecurityWhy so complicated?The Network Security
Matrix
6
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

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

8
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 doesnt 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

9
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
  desktopsbut 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

10
Restricting LAN Connectivity

• Smart HubReverse 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
• Philosophycentralized policy, distributed
  enforcement
• Goal protect hosts and servers from an infected
  host A if they dont communicate with A in the
  course of normal business

11
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 doesnt 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

12
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
• Imposing simply and rigid rules will severely
  affect usability
• Need automated methods for inferring existing,
  implicit rules
• Our work uses several weeks of training data to
  infer traffic profiles
• 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
• Filter known anomalies in training set
• Usability legitimate traffic may be blocked if
  not in training data
• 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)

13
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

14
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
After a trigger
15
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

16
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
• Extended Profile decreases number of trigger
  events by 50 at 50 percentile and 20 at 90
  percentile depending on TD

17
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

18
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

19
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