1. 1 Network Quarantine At Cornell University Steve Schuster Director, Information Security Office

2. 2 Overview ► Cornell’s incident response strategy ► Introduction to Network Quarantine ► Review of Scan at Registrations System (SARS) ► Post Mortem (What we did intelligently) ► Future considerations and direction

3. 3 Security Support Structure ► Contact Center  Part of Customer Services and Marketing  Address end user support ► Patch support ► Virus remediation ► Network Operations Center (NOC)  Part of Systems and Operations  Initial security triage  Incident response ► Blocks ► Notifications ► IT Security Office  Development of operational procedures  Technical solutions  Backline support

4. 4 Some Security Challenges at Cornell ► A general openness and decentralization leads to a larger number of incidents ► Responding to incidents can be staff intensive ► Unmanaged (students) systems arrive on our network several times each year ► Incident notification is a challenge ► Individual remediation is desired ► Wide range of end user support needs

5. 5 Responding to Incidents ► Security Office will react and contain campus systems that are compromised or highly vulnerable ► NOC had a mix of tools and manual processes for opening case, notifying impacted parties and implementing containment ► Security Office often sends NOC containment requests that were tedious to service with current tools ► Response to wide range security issues put much strain on Contact Center ► Current mechanism for containment was not fully effective and didn’t work in some environments

6. 6 Network Quarantine ► Objectives  Provide better end user communication based upon observed incident  Articulate self-remediation information and requirements when appropriate  Improve cost effectiveness of security support ► Noc ► Contact Center  More effective system isolation  Better incident tracking and remediation for local support providers  Quicker/escalated response for critical systems

7. 7 Network Quarantine (Basic Features) ► The right action is taken depending upon type of system  “Registration” 10 space  DMZ blocked  “Critical system” notification ► Response for systems identified as critical is escalated to Security Office and appropriate local support provider ► Incidents can be created, modified and closed via web and socket interfaces  Latter allows batch and automation ► NQ interacts with Vantive, creating new case when incident opened ► Modifications to an incident trigger e-mail to user, net admin and updates to Vantive ► Specific incident remediation information provided for end users ► With appropriate credentials, CIT personnel, including Contact Center, and campus system administrators can search for and review incidents

8. 8 Network Quarantine ► An incident  Incident type and description  Method of containment  Self-release option  Type of remediation  Specific support and remediation messages to users  Supporting documentation  Action tracking ► Network Quarantine Network Quarantine Network Quarantine

9. 9 Network Quarantine (Specific Features) ► For each new incident  New incident type for tracking  Establishment of resolution requirements  Incident specific message to users ► Users receive much better communication ► Self-release feature  Users are able correct the issue  Save staff time at the Contact Center ► Process automation, better user communication and self-release has saved money

10. 10 Network Quarantine (Cost Savings) ► Prior to NQ  Virus remediation costs/incident ► Contact Center – Average 10 minutes ► NOC – Average 3 minutes  System compromise costs/incident ► Contact Center  Simple support -- 20 minutes  Full rebuild – 1-4 hours ► NOC – Average  Average 5 minutes ► With NQ  Virus remediation costs/incident ► Contact Center – Same but many self-release ► NOC –under 1 minute  System compromise costs/incident ► Contact Center  Simple support -- 20 minutes  Full rebuild – 1-4 hours ► NOC – Average  Under 1 minute ** Significant savings realized using self-release and better end user support

11. 11 Scan at Registration System (SARS) ► All on-campus student computers were automatically scanned upon registration ► Objects  Drastically reduce the number of infected or compromised student systems coming to campus  Promote better security practices

12. 12 Enabling Features of NQ that Supported SARS ► Automation of containment and remediation ► Redirection to Network Quarantine infrastructure ► Articulated steps to support self-remediation ► Incident tracking

13. 13 Scan at Registration System (SARS) ► Requirements for ResNet registration  Each computer system must be registered with a valid NetID  Each computer must be configured to a minimum set of security standards ► No open writable fileshares ► All administrative accounts must have a password ► Must be patched

14. 14 Student Registration Process ► Every on-campus student went through the follow process  Plug into network and get redirected to ResNet Registration page  Authentication with NetID and fill in necessary information for registration  Wait 90 seconds for registration to complete and system check to occur  If the system passed all three tests ► Registration compete  Else ► Redirected to NQ ► Informed of the problem and provided directions for remediation ► Rescan upon completion of remediation ► Repeat

15. 15 Scan at Registration Statistics ► Approximately 6500 systems scanned over move in weekend ► Of all systems scanned  65% were probably firewalled  35% were not firewalled ► 25% were clean ► 10% had at least one of the three problems ► Close to 12% of the systems had at least one problem (780) ► Around 85% of all quarantined students were able to perform self remediation

16. 16 Network Quarantine On-Boarding Metrics

17. 17 Post Mortem ► Gaining early support from Contact Center and NOC was an absolute requirement ► Can’t under estimate the stress of move in weekend (the parent affect) ► Trust is important but “bail out” features go further  If the scanning or quarantine infrastructure failed registration would continue as before  If the Contact Center could not support the demands of quarantined students all could be released immediately

18. 18 Future Considerations ► Should scanning be expanded to other constituents and infrastructures? ► Should we be more aggressive with our scanning?  Scan more frequently  Deeper analysis ► Should we limit ourselves to network scanning or install end point components? ► Should we establish minimum expectations for all computers connecting to our network?

19. 19 Screen Shots

20. 20 Network Quarantine (Incident Types)

21. 21 Network Quarantine (Incident Types)

22. 22 Network Quarantine (Incident Messages)

23. 23 Network Quarantine (Incident Containment)

24. 24 Network Quarantine (Incident Remediation)

25. 25 Network Quarantine (User’s View)

26. 26 Network Quarantine (User’s View)

27. 27 Network Quarantine (User’s View) 128.XXX.XXX.XXX