STRATEGY SESSION November 3, 2008 NETWORK PLANNING TASK FORCE

NPTF Meeting dates Page 2 February 18-Operational review (Completed) April 21- Security strategy session (Completed) July 21-Updates & planning discussions (Completed) August 11- Strategy discussions (Completed) September 15- Security strategy discussion (Completed) November 3- Strategy discussions/some preliminary rates November 17- Finalize rate setting for FY ’10

Agenda Page 3 Strengthening PennKey – CoSign – Shibboleth – Central certificate authority – Two-factor authentication – Central authentication logging – Password to Passphrase PennGroups (Authorization) Communication Name Next Generation PennNet (Campus backbone) Wireless Local intrusion-detection Some preliminary rates

CoSign Project Synopsis – The time and effort to maintain and enhance Penn-developed Websec was not cost effective – Websec will be retired in June of 2009 and will be replaced with CoSign web authentication Benefits of CoSign Web Authentication – CoSign is actively developed/maintained and widely used within the Research and Education community – CoSign is subject to ongoing security reviews and releases – The implementation will better position Penn to support future authentication goals such as 2-Factor authentication and the use of Shibboleth (federated web authentication between institutions) – Foundation for future security improvements such as enhanced password policies, multifactor authentication and single sign-on – Simpler implementation by internal and external web application developers – Simplified audit trails for incident response Page 4

CoSign CoSign Status – Available in production as of October – Development of Penn specific CoSign documentation complete – Development of best practices in progress based on continuous customer feedback – Platform level sessions scheduled through November – Support coordinated through Provider Desk – Active approach to coordination and communication with application areas Page 5

Shibboleth 2.0 Project Synopsis – Shibboleth is an open source and standards based web Single Sign On (SSO) authentication and authorization service which will front end the Penn CoSign authentication service – Shibboleth is a component web authentication strategy with CoSign Benefits of Shibboleth – Users’ privacy and identity are not compromised when authenticating via Shibboleth to access protected services, resources and applications – Supports integration with 3rd party vendor applications requiring Penn authentication (e.g. Blackboard) – Shibboleth provides attribute based authorization decisions using PennGroups (Authorization) – Positions Penn for future federation with other institutions Shibboleth is a standard in the academic community Users access Penn resources using their home organization credentials Penn users access federated institutions resources using PennKey Page 6

Shibboleth 2.0 Shibboleth Status – Initial analysis and strategic planning complete – Phased development approach Pilot implementation for internal SSO and Penn authentication scheduled for 1Q09 Subsequent phases will support federated authentication and authorization based on federation associations – Detailed evaluation of InCommon federation application requirements and process initiated Cost for the joining the federation not identified (about $50k) and not likely to happened in FY’10. Page 7

Central Authentication Logging Project Synopsis – Implementation of a central log/repository capturing PennKey authentication attempts – Provide a reporting/querying and communication mechanism for alerting ISC Security personnel on invalid authentication attempts Benefits of Central Logging – Accurate tracking of authentication success and failures – Better information for University security personnel to research and address unauthorized attempts – Enhanced ability to protect University of Pennsylvania data and applications from repeated unauthorized access attempts and security breaches through proactive analysis of previous attempts – While central authentication logging will require the collection of certain data about the authentication attempt, the data logged would be limited to data such as PennKey, Date and Time, IP Address, Application being accessed, etc.; the visibility of the logs will be limited to ISC personnel working on analysis if any breach has been attempted Page 8

Central Authentication Logging Milestones – Develop, review and approval of final requirements and standards – Development of logging solution – Pilot solution – Fraud detection strategy and solution in Phase 2 of project Recommendation – Delay the development work associated with Central Authentication Logging. This is about $230k. – In FY’10 we will again evaluate the need for the project versus the current risk to determine if we should resume the project for FY’11. – If the NPTF feels strongly about doing CA logging sooner, they could approve CSF funding for it. Page 9

Two Factor Authentication Project Synopsis – Implementation of second authentication factor for users attempting to access University resources through the PennKey web authentication process – Investigating 2 options Hardware token solution providing a One Time Password (OTP) for supplementing PennKey password/passphrase Cell phone alternative to physical token Benefits of Two Factor Authentication – Increased security for users attempting access of protected data and application through PennKey authentication – Protection of University data and systems through tighter authentication controls and reduced security breaches Page 10

Two Factor Authentication Two Factor Milestones – Develop scope, options and strategy for pilot – Vendor selection; development and pilot implementation – Identify application area(s) to implement pilot solution and define support model for pilot – Post-pilot analysis, document lessons learned and propose wide-scale deployment and support recommendations to ISC Senior Staff for review and funding requirements Recommendation – Evaluate alternatives to a costly (over $400k) full-scale implementation of Two Factor Authentication. – In lieu of a full-scale project, we will evaluate small-scale approaches of up to 500 users. Page 11

Central Certificate Authority Project Synopsis – Proposed implementation of a central certificate authority (CA) to support Penn applications currently using SSL certificates as well as support of future initiatives Benefits of Central CA – PKINIT extension of the Kerberos protocol – Device certificates for 802.1x network access control – Supports secure communications between internal services – Supports inter-domain Shibboleth services in federated environments with other institutions – Positions Penn in the higher education community with regards to PKI. There is significant development in central certificate efforts (e.g. Internet2 USHER higher education PKI CA effort) Central CA Milestones – Define scope and project plan – Implement by July 2009 Page 12

Passphrase Implementation Project Synopsis – ISC implementation of a new passphrase policy for PennKey credentials – Updating the current PennKey password pages to support passphrases – Implementation and transition period for users to convert to passphrase will be from March to October 2009 – Passphrase will be of longer length (15 to 64 characters), allow the use of dictionary words and user selected Benefits of Passphrases : – The use of longer passphrases increases protection against brute force attacks against University systems – Provides users with easy to remember passphrases rather than complex shorter passwords – Discourages users from writing down passwords which risks identify theft and security compromises Page 13

Passphrase Implementation Passphrase Status/Future Milestones – Initial analysis and strategic planning complete – ISC planning development and testing of new policy against the KDC and Cracklib (password vetting tool) – Systematic alerts to users over transition period (Notification on Websec and CoSign logon pages, focused notification to users who have not changed to passphrase based on last reset timestamp on KDC, automatic redirection to change passphrase page in October 2009) Page 14

PennGroups (Authorization) Project Synopsis – PennGroups is our implementation of the Internet2 open source Grouper product – Provides applications across the Penn’s schools and centers a central infrastructure to manage groups and make authorization decisions PennGroups Benefits – Using an open source solution provides the University with a robust group management framework – Contributing to that initiative integrates Penn specific enhancements without maintaining a separate source code instance – Provides a central infrastructure for group information and establishes a core group hierarchy with distributed responsibility of group management/creation to schools and centers – Managed through a common UI and web services; streamlines maintenance of authorization data – Group membership data is dynamically updated from source systems making authorization decisions more accurate Page 15

PennGroups (Authorization) PennGroups Status – Access to PennGroups via web services is currently available in production – PennGroups LDAP server to launch by November 7 th – Pilots in production Paid Time Off (PTO) uses PennGroups so a user can select a supervisor (typically faculty) that doesn’t manage their time off through PTO. ISC Warehouse Apps uses PennGroups to allow access based on the person’s org Page 16

Communication Names Project Synopsis – The implementation of a separate and unique communication name used for , IM and personal webpage rather than using the PennName – Communication Name will be stored in PennCommunity and follow the PennName data flow Benefits of Communication Names – Based on the current PennKey implementation, there is a problem of a shortage of “good” PennKey/PennNames for the new members of the University community – Communication Names will allow for a public view name for a user’s , instant messaging capabilities and personal webpages – Communication Name persistence will not follow the PennName persistence rules Communication Names Milestones – Communication Name policy is currently being defined – Preliminary discussions have been conducted defining implementation options and data flow – Once policy is defined, development will be scheduled – Initial analysis indicates some incremental support costs may be necessary. Page 17

Development Efforts Page 18 1QFY092QFY093QFY094QFY091QFY102QFY103QFY104QFY10 CoSign Shibboleth Central Certificate Authority Two Factor Authentication Authentication Logging Passphrase PennGroups Development Analysis Development AnalysisDevelopment Analysis Development Selection Development Transition Milestone Key Targeted Production Phasegate Review Production Pending Funding Development Pilot Contingency Pilot

Strengthening PennKey Funding CoSign - No incremental funding necessary; replaces websec Central certificate authority - linked to Cosign project, no incremental funding required Shibboleth - Project already underway; no incremental funding required Two-factor authentication - Funding may be required Central authentication logging - Funding required Password to Passphrase - No funding required, nominal costs PennGroups (Authorization) - No incremental funding Communication Name - Funding may be required Page 19

Next Generation PennNet Campus backbone (Preparing for full convergence) – Capacity 166 of 229 main campus buildings have gigabit Ethernet connections 87 buildings have single mode fiber connections – Reliability 56 of 96 buildings have dual gig connections – We continue to evaluate the cost benefit, risks and feasibility with doing dual gig to all 229 buildings. We will discuss NGP in more detail in the Spring Page 20

Next Generation PennNet – Preliminary cost estimates to add dual gig to all these 133 buildings appears to be prohibitive and frequently will not add additional reliability. Redundant pathway and fiber costs Additional building entrance equipment and “router ports” Would require IP renumbering in most cases – We can also discuss UPS and using existing building generators for building and closet electronics. Our recommendation is not pursuing this in FY’10 due to the very high cost and insufficient need. – VoIP deployment is less than 10% of the phones, not counting students. – In the last year, we have logged only 36 hours of electrical outages across campus. » However our tracking of power outages is not 100% reliable (Penn likely has more outages than we can detect.) » We will continue to work with FRES Operations on improvement of tracking power outages on campus Page 21

Next Generation PennNet Closet electronics – 93% of closet electronics are gig capable. All electronics will be gig by June 2009 – There has been a strong movement to 100 meg connections from 10meg By the end of FY’10 well over 50% will be 100 meg – Our recommendation is starting in FY ‘10 (or perhaps January 2009), to have 100 meg, half duplex be the default connection – Due to the enhanced feature set of our closet electronics, our recommendation would also be to move from a 3-year to a 4-year depreciation of this equipment. – That decision, plus the volume increase of approximately 4000 SAS ports managed by ISC provides scale economies that will result in a significant cost reduction of 25% for these connections. – We recommend that the cost for both a 10 meg and 100 meg connection be $5.25 for FY ‘ meg ports are still necessary for ResNet, VoIP, etc. – We will be able to continue our current standard rate of $20 to convert a single connection. We will use time and material (at a lower cost )for large projects such as converting entire buildings. Page 22

Wireless Update - Current Status Wireless-PennNet retirement completed on 06/30/08 Consolidation of all wireless networks – AirPennNet expansion (SAS and SEAS buildings) AirSAS retired and replaced with AirPennNet and AirPennNet-Guest. SEAS has AirPennNet and AirPennNet-Guest AirPennNet-Guest Network in operation starting FY ‘09 – Completed per subnet IP ranges to provide scalability and management – Coordinated with LSP’s to set IP ranges for AirPennNet and AirPennNet-Guest Networks AP count in production: 1349 AP’s – ResNet 483 AP’s – Remaining campus 866 AP’s – Wireless in over 80 buildings – Operates A,B,G(54 meg max shared) AirPennNet website completely reworked – Coverage maps, FAQ, technical information – Page 23

Wireless Update Short Term Strategy (FY’09) Continue with wireless expansion per customer demand Make no major changes or hardware upgrades to the current wireless infrastructure Evaluate Next Generation Wireless Testing new controller-based architecture, n – 100 meg shared. A,B,G,N functionality – Thin APs with controllers RFP drafted and submitted to 3 vendors (Cisco, Meru, Aruba) Evaluations in progress. Decision by January 2009 Small pilot (building) by March 2009 Purchase by end FY ‘09 for FY ‘10 deployment (if cost effective) Design of Campus User Rapid/Self Service to Enable Guest Access Targeting end of FY ‘09 Pilot Page 24

Wireless Update Medium Term Strategy (FY’10) Conversion to controller-based architecture – Centralized (few) or distributed (many) controllers Strengths – Potential savings in staff time (installation, management, & support) – Dynamic wireless coverage and signal strength – Rogue AP detection and elimination – Enables client mobility and eliminates client roaming tendency problems between AP’s inside buildings – May offer ability to stage n roll out. Weaknesses – Hardware costs increase (possibly a controller per building) – Single point of failure per building or group of buildings Page 25

Wireless Costs Costs – Preliminary estimates indicate a significant increase to monthly rate due to higher AP and AP controller costs – Will not have actual costs until Spring 2009 Recommendation (assuming technical requirements met) – Convert to controller based architecture in FY ‘10 – Implement controller based APs using n in stages Gives us time to work out client and support issues in our mixed environment Target very high density locations – ResNet, Huntsman, VPL (end FY ‘10) Convert remaining buildings in FY ’11 Issues – Should we consider 4-year depreciation to help spread out costs? – Should we wait a year and deploy later at a lower price point? – Should port charges subsidize wireless? Page 26

Intrusion Detection (Perimeter) We have been successfully deploying centralized perimeter and core intrusion detection using Arbor Networks products for 5 years on PennNet. – Arbor system is used for network capacity planning, traffic characterization, and peering analysis – Used as a proactive tool to insure the security and reliability of PennNet Performs signature based attack detection Flags anomalous traffic that might indicate an attack Monitors scanning of unallocated Penn address space,usually indicating potential attack sources – We will continue to track advancements and investigate upgrading this service Additional funding may be necessary for FY’10. Page 27

Intrusion Detection (Local) In FY ‘09 NPTF funded $25k of the Central Service Fee to write a strategy, do analysis, develop several options, develop a support model and deploy a pilot for local intrusion detection. Three models have been developed. 1.Firewall integrated IDS – Focus on IDS options and capabilities available with the recommended Juniper Netscreen firewalls. – The support and cost model will be similar to the local firewall model » Develop knowledge and expertise, do basic documentation of options on the web, and provide 2 nd -tier support. » Do initial consulting with departments regarding options and considerations for their local environments. » Assist with local implementations as a direct charge service. Page 28

Intrusion Detection (Local) 2.Standalone IDS – Already being used behind customer-owned firewalls » SOM (CCEB) » Annenberg School – Difficult & costly to implement in shared buildings 3.Centralized IDS – Very costly – We are not recommending doing this option. – Arbor may play a role in a centralized intrusion detection system in the future. We welcome schools or centers that want to participate in testing and piloting local IDS. Departments that are already using the Juniper Netscreen firewalls are obvious candidates. Page 29

Page 30 Preliminary Rates For FY’10 Monthly PennNet port rates – 10 Meg go from $6.03 to $5.25 (8.7% cost reduction) – 100 Meg go from $7.03 to $5.25 (25% cost reduction) – Gig rates remain the same at $30/month Gig cannot be wide-spread until we have a 100 gig core and 10 gig building connections. Likely in FY’11. PVN rates go up from $15.50 to $16.50, reflecting increases by our vendors. All analog voice rates stay the same rates are still being evaluated ACD rates will increase slightly All consulting rates slightly higher, t hese have not gone up in 2-3 years.

IM-Jabber (part of our Unified Communication strategy) – ISC will continue to offer it at no cost to everyone in FY’10. – In FY’11 the rate will be $12/year if you do not have a VoIP or account with ISC. Port configuration charge – vLANS continue to be $1.25 per month – However, we will implement a monthly charge of $1.25 for other port configurations other than the default (half duplex). Full Duplex Port Mirroring – Standard set up fees remain the same New building vLAN and port setup: $1300 plus $200 per wiring closet Augment existing vLAN setup $20 activation fee per port Page 31 Preliminary Rates For FY’10

Page 32 FY’09 VoIP Rates FY’10 VoIP Rates $15.32Line$17.00Line $6.03Port$5.25Port $8.00Cisco set$5.00Polycom set $3.00Voice mail$3.00Voice mail $32.35 Total$30.25Total The above is a 9% cost reduction Most usage continues to be billed at a 50% decrease over analog telephony. We will continue the no cost conversions to VoIP in FY’10. Preliminary Monthly Rates For FY’10