1 10/31/05 NETWORK PLANNING TASK FORCE Information Security

2 Agenda ■Overview of ISC’s Security Architecture ■Discussion ■Scan and block ■Edge filtering ■VPN or other options ■Local firewall support ■Critical host policy

3 Security Architecture

4 Scan and Block ■Opportunity: Networks of unmanaged machines would be more secure if we could scan them at network connection time and then periodically (e.g. every four hours) for common backdoors. Vulnerable machines could be quarantined until they are remediated. Hacked machines could be kept off the network until remediated. ■Solution: Deploy a “scan and block” system to help prevent network access by compromised or vulnerable computers. ■Authenticated wired and wireless network access, with brief scan of hosts for major vulnerabilities at connection time. ■Quarantine those with problems found, until they can be patched or repaired. ■Allow those that “pass” the scan to access the network. ■Schedule deeper scans once connected. ■Advantages ■Limits the spread of worms, and will be more effective when coupled with edge filtering. ■Requires logging in. ■Disadvantages ■False positives ■Adds complexity to network access and makes troubleshooting difficult. ■Requires logging in. ■Implementation Considerations: ■Planned for implementation in the residential system Summer, ■What are the possibilities of implementing this in other “transient” networks like wireless Law, Dental, Library, etc. ■Funding required.

5 Scan and Block To PennNet -OR- Access Network Quarantine and Remediation Network Production Service Network Scanning Server Remediation Server

6 Scan and Block To PennNet -OR- Access Network Quarantine and Remediation Network Production Service Network Scanning Server Remediation Server

7 Some of the vendors with products in this (relatively new) space ■ Cisco Clean Access (nee Perfigo) ■ Lockdown Networks ■ Bradford Networks ■ Impulse Point ■ Risk Analytics (LAN Switchboard) ■ Bluesocket, Vernier authenticating gateways

8 Timeline ■ ISC work to design a solution for Network Access Protection started in summer ■ SUG and IT Roundtable talks in June ■ Evaluations of packaged vendor solutions began in September ■ Goal of deployment in residential buildings for start of Fall Could be expanded thereafter. Jul 04 Jan 05 Jul 05 Jan 06 Jul 06 Solutions Design EvaluationsPurchase & Integrate, or Build Planned Deployment Initial SUG And ITR Talks

9 Edge Filtering ■Opportunity: Windows machines at Penn get hacked more frequently than they would if there were better perimeter protection blocking NetBios at the edge. ■Option 1: Block NetBios on internal router interfaces (subnets) upon local request. ■Advantages ■Provides protection from the most common worms and attacks for only those subnets where such protection is desired. ■Disadvantages ■More complex to administer ■Limited protection ■May not be as granular as people want ■Would reduce mobility – local campus access across subnets would be blocked.

10 Edge Filtering (cont.) ■Option 2: Block NetBios at edge routers. ■Advantages ■More complete protection ■Allows mobility on campus ■Disadvantages ■May necessitate a campus VPN solution ■Implementation Considerations: ■Primary implementation timing considerations are: ■Availability of a VPN or some other option to provide secure remote access to NetBios services ■The need to broadly communicate that filtering will be implemented and how to get secure, remote access. This is probably a 3-5 month communication effort. ■Determining the exception lists will add to delivery time. ■Need to pick a firm date for implementation like July 1, ■This approach above could be implemented with existing funding. ■We recommend option 2.

11 VPN or Other Options ■Opportunity: If NetBios is blocked either at the edge or on internal routers, faculty, staff, students with legitimate need for remote access to Windows file sharing, Exchange, etc. need a mechanism or approach to get through the filters. ■Option 1: Central Campus VPN Service ■Advantages ■Besides providing remote access to Netbios, also provides network encryption for those applications that aren’t amenable to a network encryption solution. ■Disadvantages ■Cost ■Complexity, both centrally for ISC and for users ■Implementation considerations: Could be implemented FY07 if funded.

12 VPN or Other Options ■Option 2: Allow NetBios in a reserved range of addresses. External traffic bound for Netbios services on all other Penn IP addresses would be blocked. NetBios would be remotely available for machines in the subnet. ■Advantages ■Cost saving over VPN solution ■User simplicity ■Local IT control ■Disadvantages ■Requires renumbering IP addresses by LSPs ■Implementation Considerations ■Could be implemented FY06 with existing funding ■Requires work-arounds to support Windows browsing. ■Option 3: Block NetBios at the edge and manage host-by-host exception lists in the edge filtering rules. ■Advantages ■Cost saving over VPN solution ■User simplicity ■Disadvantages ■Complex administration ■Reduced control for server administrators compared to option 2. ■Implementation Considerations ■Could be implemented FY06 with existing funding if exception list is small (200 campus-wide) and changes infrequently.

13 VPN or Other Options ■Option 4: Replace remote access to NetBios services with functional equivalents that don’t use NetBios – e.g. Exchange Server 2003 RPC over HTTP and a campus “MyFiles” service, likely using WebDAV. ■Advantages ■File Handing – Better way to share large documents without . ■Less complex for end users and support providers. ■Built in clients. ■Disadvantages ■Requires changes from Exchange Administrators and individual end users. ■End users must run Outlook 2003 ■Implementation Considerations ■Could be implemented FY07 if funded. ■More investigation required.

14 Local Firewall Support ■Opportunity: There is currently no supported firewall product. Each group that implements a firewall has to climb the learning curve independently. ■Proposed Solutions: ■ISC to select a recommended firewall product. ■ISC to provide a for-fee firewall consulting service. ■Streamline ISC intake for this service to coordinate with TSS, Networking and Security. Work to improve awareness of ISC’s support for local firewalls. ■Recommend external consultants. ■Implementation Considerations: ■Target to implement May 2006.

15 Rationale for Distributing Security Responsibility ■Goal: Find the proper balance of what security services to provide centrally vs. perform locally. ■Planning Assumption: For local services, you may either “do-it- yourself” or hire ISC for-fee. ■Rationale: ■Provide services centrally when they can be most efficiently and effectively done over the network. ■Provide security services locally when it is more effective and efficient to perform them locally. ■Examples: ■Vulnerability and compromise scans be effectively and efficiently performed centrally, except for machines behind firewalls. ■Password cracking can be most effectively and efficiently done locally with host-based password cracking software.

16 Proposed Next Version Critical Host & Proposed Services NEW LOCAL DUTYSUPPORTING ISC PRODUCT/SERVICE By 1/1/07, scan critical hosts for vulnerabilities monthly.Provide training on security scanners – ISS, Nessus, Scanline Provide a for-fee security scanning service By 1/1/07, run password cracking software monthly.Recommend platform-specific cracking software. By 7/1/07, place critical hosts with confidential data behind a firewall. Establish a supported firewall product, matched with for-fee, vendor-provided firewall administrator training. Provide a for-fee firewall consulting service to select and configure a firewall. Publish a list of approved and qualified firewall consulting services. By 7/1/07, implement a program of local Intrusion Detection or Prevention to detect common network attacks promptly. Recommend an intrusion detection product and provide supporting training. By 7/1/07, encrypt confidential data stored on Personal Computing Devices. Recommend encryption tools (e.g. encrypting file systems, PGP) By 7/1/07, all access to Critical Hosts by individuals with Administrator or Root-level privileges must use two-factor authentication. Commit to provide supporting documentation and infrastructure Deploy documentation and infrastructure. Establish two-factor authentication standard