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 2

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

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 - Share. Point • Test results culturally challenged 4

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 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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

Sharepoint tracking system 15

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 16

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 3 rd party software applications that may be handling financial information 17

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 18

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

For more information Lynn Ray, CISO, Towson University Phone – 410. 704. 6339 e. Mail - lray@towson. edu 20

Questions 21