1 / 27

Network Quarantine At Cornell University

Network Quarantine At Cornell University. Steve Schuster Director, Information Security Office. Overview. Cornell’s incident response strategy Introduction to Network Quarantine Review of Scan at Registrations System (SARS) Post Mortem (What we did intelligently)

burton
Download Presentation

Network Quarantine At Cornell University

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Network QuarantineAtCornell University Steve Schuster Director, Information Security Office

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

  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. 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 Network Quarantine (Cost Savings) ** Significant savings realized using self-release and better end user support

  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. 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. 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. 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. 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. Network QuarantineOn-Boarding Metrics

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

  20. Network Quarantine(Incident Types)

  21. Network Quarantine(Incident Types)

  22. Network Quarantine(Incident Messages)

  23. Network Quarantine(Incident Containment)

  24. Network Quarantine(Incident Remediation)

  25. Network Quarantine(User’s View)

  26. Network Quarantine(User’s View)

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

More Related