Performing Risk Analysis and Testing: Outsource or In-house Performing Risk Analysis and Testing: Outsource or In-house? A Towson University Case Study Lynn Ray CISO Towson University

Introduction Background Outsource – Why or why not? Steps taken by TU Lessons learned Recommendations

Background Towson University Second largest in state next to University of Maryland at College Park 21K students (as of 2008) Baltimore-based 400+ distributed servers and network security devices Culture is based on traditional and online education

Originally in-house Utilized a full time experienced security engineer to perform tests Utilized open-source and commercial tools (Nessus, Canvas, etc.) Established some policies and procedures Devised and used an inhouse-developed incident tracking system - SharePoint Test results culturally challenged

Reasons for decision The security engineer left and replaced with students Software was too costly and complicated University System of Maryland internal audit started requiring results from scans and tests Payment Card Industry (PCI) compliance requirements Hackers increased focus on Web-based attacks Maryland state auditors and secuity standards requiring testing and monitoring University culture on security

Outsource pros Bring certified and trained expertise Use more advanced tools and bring their own In certain circumstances they can be more cost effective Easier compliance to federal and state regulations

Outsource cons There is some loss of control over the tests There is a lack of getting the results back bacause of company internal procedures Generally cost more than in-house Services are restricted to what is stated in the contract A level of trust will have to be established with the vendor

Step 1: Determined what to do Looked at what other universities were doing Determined what systems processed, transmitted or stored used credit card data Looked at the PCI Security Standard

PCI data security standards requirements Build and Maintain a Secure Network Requirement 1: Install and maintain a firewall configuration to protect cardholder data Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data Requirement 3: Protect stored cardholder data Requirement 4: Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program Requirement 5: Use and regularly update anti-virus software Requirement 6: Develop and maintain secure systems and applications

PCI data security standards requirements (cond't) Implement Strong Access Control Measures Requirement 7: Restrict access to cardholder data by business need-to-know Requirement 8: Assign a unique ID to each person with computer access Requirement 9: Restrict physical access to cardholder data Regularly Monitor and Test Networks Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 11: Regularly test security systems and processes Maintain an Information Security Policy Requirement 12: Maintain a policy that addresses information security

PCI Compliance Comply with Data Security Standard May use PCI vendor - http://www.pcicomplianceguide.org/ Users complete an annual questionnaire Include all systems that handle credit card information

Step 2: Research vendors Researched over 87 vendors because of a lack of knowledge of who is in the business Discovered some of the vendors were PCI certified https://www.pcisecuritystandards.org/pdfs/asv_report.html Established some general requirements when looking for vendors Vulnerability test methods Hands-off testing (vendor does all testing) Use simple purchase methods (credit card or contract?) Reference checks

Step 3: Setup testing Initially used credit card to obtain verndor services Identified 50 servers including ones covered under PCI Coordinated installation of vendor scanning appliance Establish firewall rules to support testing Scheduled quarterly vulnerability tests

Step 4: Devised procedures Created vulnerability/incident tracking procedures Implemented SharePoint tracking system to track vulnerabilities found Performed an annual questionnaire with functional areas using credit card data

Sharepoint tracking system

Step 5: Expanded analysis and testing criteria Decided to increse the number of servers to include the whole campus (approx 400 servers) Added penetration testing Minimum web testing Tested network security devices Established set dates and time-limits on vendor security appliance access to do testing

Lessons learned All requirements not addressed up front Compliance after thought Didn't test web systems for vulnerabilities Rough procurement Need to be more risk-centric Need check user access to 3rd party software applications that may be handling financial information

Compliance What’s applicable? Lack of knowledge - use outside expertise Implement security self-assessment program that involves others cross-campus Have effective institutional officers in Compliance Privacy Security

Recommendations Gather all testing and analysis requirements Determine compliance needs Contract for each type of test needed Get support from others – CIO champion Focus on risk-centered methodology Include in INFOSEC strategic plan Establish procedures and tracking system

For more information Lynn Ray, CISO, Towson University Phone – 410.704.6339 eMail - lray@towson.edu

Questions