Enterprise Worm Mitigation-- A Community of Interest based approach

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. Statistics, AI & Adaptive Methods Traffic Monitoring, Detection, Mitigation System Monitoring, Detection and Mitigation Security/Config Management Security Assessment End-to-End Services/Applications Security Architecture Security/Config Provisioning Host & Software Security Protocol Security Cryptography & Software Eng Signaling Media UDP/TCP IPsec VPN MPLS VPN Managed IP Access IP Backbone, IP Access Networks Management & Service Design & Deployment Security—Why 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 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

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

10. IP3, MAC3 Mgmt proc L3-aware bridge LAN Router PC IP1, MAC1 IP2, MAC2 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

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

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 < Relaxed < Open • 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