Securing Web Applications A Case Study Presented by: Doreen Meyer, Security Programmer University of California, Davis Robert Ono, IT Security Coordinator University of California, Davis Security Professionals Conference 2008 – SEC08 Copyright Doreen Meyer and Robert Ono This work is the intellectual property of the authors. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the authors.

Session Focus As the number of Web applications providing remote access has grown, attackers have focused their attention on identifying and exercising Web application security vulnerabilities. This session will review the selection and deployment of a centralized Web application security scanning system. Attendees will be able to better guide the development of a similar program from the lessons that UC Davis has learned from this project. 2

Session Agenda 3 Security Problem Background Project Initiation Criteria & Selection Preparation and Deployment Technical and Administrative Architecture Conclusions

Problem Background 4 Evolving nature of security breaches Notification issues and costs Unlike other campus security systems Part of a broader campus security program

Web Application Security Issues 5 Cross site scripting Injection flaws Malicious file execution Insecure direct object reference Cross-site request forgery Information leakage & improper error handling Broken authentication & session management Insecure cryptographic storage Insecure communications Failure to restrict URL access

General web application scanning system options  Enterprise or desktop  Reporting format  QA integration  Source code or fault injection Vulnerability Evaluation 6

Project Initiation 7 UC system-wide interest UC Davis product review UCLA Request for Proposal  Leverage purchase power  Develop system-wide expertise

Project Initiation 8 Timeline  UCD product review and selection (1/07-6/07)  UCOP RFP release (2/07)  Cenzic, NTObjectives, SPI Dynamics, Watchfire  UC contract award to SPI Dynamics and Watchfire(4/07 and 7/07)  UC Davis license (7/07)

Criteria and Selection Enterprise offering Scope of vulnerability detection Scan options: scheduling, recurring, baseline Severity/priority ratings in reports Report database with reporting options 24x7 support, severity levels, escalation Solution updates Discontinuation options 9

Criteria and Selection Lessons learned – solution options Broad range of available solution user licenses (Full Use vs Read-only vs Assignable) Service restrictions may limit service provider options Domain restriction may still provide additional scanning coverage Single license product may have different functionality than enterprise product. 10

Lessons learned – desirable features Evaluate capability to create custom rules within solution templates Capability to access basic scan templates when running advanced scans Seek granularity of user and administrative authorization within the product Capability to monitor license use Computer-based training not essential Criteria and Selection 11

Preparation and Deployment 12 $150K, 25 licensed users for enterprise version On-site pre-deployment planning visits by Watchfire On-site pre-deployment implementation and tuning On-site training for 25 users by Watchfire staff

Original Plan  Licensed, trained staff could run scans for others in the unit/school/college.  Licensed, trained staff could assign viewing rights to staff who could access the resulting scans.  With a web security tool, technical staff have the resources and skills to ensure that their web sites will be secure. Preparation and Deployment 13

Lessons Learned Staff within units/school/colleges feel unduly burdened running scans for their units License pool was increased by 20 licenses 12/07 to accommodate license requests. Training sessions (run by UCD security staff) shall be ongoing. Preparation and Deployment 14

Preparation with Watchfire project manager Determined roles and rights Made sure service was running properly Configured selection template for basic use Configured custom mid-tier (advanced user) role Preparation and Deployment 15

Preparation and Deployment Communication TargetCommunication Tools Directors and ManagersHigh-level discussions to introduce security issue and solutions Policy and standards Demonstrations Web DevelopersPre-acquisition and post-acquisition meetings Policy and standards Demonstrations FAQs Mailing List Wiki for collaboration and documentation Internal training – basic and advanced System AdministratorsTechnical acquisition and deployment discussions Policy and standards Solution demonstrations 16

Lessons Learned Need ongoing in house basic and advanced training, Web and print media are insufficient. Wiki essential for collaboration and reference material Monthly user group meetings reinforce training and product use  Interest is heightened when focus is on a topical web security vulnerability and how Appscan can assist with detection Preparation and Deployment 17

Training by Watchfire trainers Watchfire application administrator – two days Basic Watchfire training class -- one day, four to six students per class. Advanced Watchfire training class -- 4 hours, lecture style Preparation and Deployment 18

Lessons learned Instructor must have access to a test site with vulnerabilities. During training, include examples of how two or three of the most commonly identified vulnerabilities are exploited (OWASP 10?) During training, include how Watchfire detects vulnerabilities. Preparation and Deployment 19

Preparing a web site for a security scan Identify purpose of the scan, URL Identify testing account and password Identify web page identification mode (manual explore or auto-discover) Select scan template Identify advanced needs: scan window, complex authentication process, form values, parameter and cookie special handling Preparation and Deployment 20

Lessons learned – web site preparation Using development or test servers Preparing databases Reviewing forms Changing addresses Configuring authentication Evaluating cookies Watch out for wikis Preparation and Deployment 21

Lessons learned – web site preparation Use manual explore. Start small. Use a dedicated account for site access. Work with someone who knows the site content. View your web logs during the scan. Verify security scan activity. The running time for a scan is longer than you might expect it to be. Preparation and Deployment 22

Resolving a scan report Compliance reports (OWASP Top 10, SANS Top 10/20, HIPAA, PCI, SOX) Inventory reports (broken links, site inventory, page count) Security reports (remediation tasks, security issues) Preparation and Deployment 23

Resolving a scan report Learn about the issue type Track the issue ( mark as fixed, label false positives) Analyze the security tool request and resulting web site response Preparation and Deployment 24

Lessons learned – resolving a scan report The responsibility for web site security is a hot potato among managers, web content developers, QAQC, and system administrators. The expertise needed to fix a coding problem cannot always be found within the unit that originally wrote the code. Popular ‘recipes’ may be insecure Preparation and Deployment 25

Technical and Administrative Architecture Enterprise server components include:  Scanner  Web interface (IIS)  Database (Windows SQL Server) Components can run on one or more servers.  Current configuration: One Dell PE 2950 with 8 GB RAM 26

Technical and Administrative Architecture Lessons learned Optimize the database layout and memory usage. Schedule downtime for bundled application updates. It may be difficult to run this service behind a hardware firewall. Link Appscan authentication to central authentication service 27

Technical and Administrative Architecture Complementary enterprise tools for web application security analysis:  Section 508 compliance checks (IBM Rational Policy Tester: Accessibility Edition)  AJAX and web services checks (Appscan Standard Edition)  Static source code analysis (Fortify)  Application (Layer 7) firewalls 28

Conclusions 29 Valuable security toolset added to a broad security program Confirm institutional readiness for investment Create strategies to encourage developers to integrate scanning into the development process Limitations to Web application security scanners One tool may not fit all needs

Questions? 30

2007 Specifications Architecture and system submissions Does your solution support an enterprise services model, where the Web application scanning service is centrally administered, campus units can request a scan configuration from the central service and view only their scan report(s)? If so, describe the available authentication and authorization model and describe how scan reports are protected so that one campus unit cannot view the scan results of another unit. List any system prerequisites for your product including hardware, networking, database, web server and any other requirements. Include all hardware and software specifications needed to run and support your software. Does your product permit specification of base-line scan results so that the results of subsequent applications scans can be compared with the baseline over time? If the vulnerabilities identified by the application scanner change over time, how is this reflected in the baseline comparison report? 31

2007 Specifications Architecture and system submissions (continued) Can scans be scheduled in advance and, if so, please describe. Can scans be scheduled on a recurring basis and, if so, please describe. Are scan results stored in a database that can be accessed by third part report generation tools, such as Crystal Reports? List any known conflicts with other applications. Include version numbers if applicable. Will you support login account and password resets? Describe how data access can be enabled or disabled 32

2007 Specifications Security Does the product provide the ability to monitor user access and traffic patterns (e.g., number of contacts, lengths of activity, peak zones, etc.)? Please describe your product’s design and test strategy to protect against Internet security breaches such as SQL Injection attacks. Please describe safeguards built into your product to eliminate or substantially reduce the security risks that the product is built to detect. Please describe installation and implementation configurations necessary to insure that the product itself does not pose a security risk. 33

2007 Specifications Security (continued) What are the provisions for secure transmission between the security scanner and application being scanned? What are the provisions for secure transmission between the configuration client and the application scanner? SSL is required if web based communication. What are the provisions for secure report transmission between the scanner and the reporting mechanism(s)? How is the application scanner protected from security threats? How is the application component holding scan results protected from security threats? 34

2007 Specifications Security (continued) Describe the mechanism for user authentication and support for granular authorization. Does the application scanner include a report on the current top ten vulnerabilities reported by the Open Web Application Security Project (OWASP)? If not, which vulnerabilities are excluded? What is the company commitment to ensure application scanner is continuously updated to reflect changing top ten OWASP identified Web application vulnerabilities? 35

2007 Specifications Support services Describe your support services structure (technical and functional) and how you plan to support the University. Where is your primary support location and what are the hours of service? How long do you guarantee support for each release? Define your standard Service Level Agreement. Define your problem severity levels and include the target response times and restorable actions to customer issues by severity level. What is the problem escalation procedure available to a client the size and stature of the University? What tool and documentation would be provided for product self support/diagnosis? Describe the process for reviewing, approving and prioritizing suggested changes and enhancements. 36

2007 Specifications Support services (continued) What release is being proposed in your response and when will it be available? What is your procedure for handling and resolving “bugs”? How do you differentiate between an upgrade release and the release of a new product? What is your update/enhancement schedule? Describe your product’s major releases and revisions schedule and approach. Describe procedures and formats for how releases and revisions are distributed. Specify the process your company follows in advance of discontinuing support of a version to migrate to a version you continue to support. 37

References UC Davis AppScan Enterprise UC Davis Cyber-safety Policy UC Davis Security References UC system-wide security policy requiring authorization controls

References OWASP: NITKO: Cenzic Hailstorm: HP WebInspect: IBM AppScan IBM AppScan demo NTObjectives NTOSpider: