securing web applications a case study presented by: doreen meyer, security programmer university of...

Securing Web Applications

A Case StudyPresented by:

Doreen Meyer, Security Programmer

University of California, Davis

Robert Ono, IT Security Coordinator

University of California, Davis

Copyright Doreen Meyer and Robert Ono 2008. 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


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


11


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.


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.


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


15

Preparation and DeploymentCommunication Target Communication Tools

Directors and Managers • High-level discussions to introduce security issue and solutions

• Policy and standards• Demonstrations

Web Developers • Pre-acquisition and post-acquisition meetings

• Policy and standards• Demonstrations• FAQs• Mailing List• Wiki for collaboration and documentation• Internal training – basic and advanced

System Administrators • Technical 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


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


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.


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


20

Lessons learned – web site preparation

Using development or test servers

Preparing databases

•Reviewing forms

•Changing email addresses

•Configuring authentication

Evaluating cookies

Watch out for wikis


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.


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)


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


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


25


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


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


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 thebaseline 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 http://security.ucdavis.edu/appscan.cfm

• UC Davis Cyber-safety Policy http://manuals.ucdavis.edu/PPM/310/310-22.htm

• UC Davis Security References http://security.ucdavis.edu/

• UC system-wide security policy requiring authorization controls http://www.ucop.edu/ucophome/policies/bfb/is3.pdf

38

http://security.ucdavis.edu/appscan.cfm

References

• OWASP: http://www.owasp.org

• NITKO: http://www.cirt.net/nikto2

• Cenzic Hailstorm: http://www.cenzic.com

• HP WebInspect: http://www.hp.com

• IBM AppScan http://www.watchfire.com/products/appscan/default.aspx

• IBM AppScan demo https://www.watchfire.com/securearea/appscan.aspx

• NTObjectives NTOSpider: http://www.ntobjectives.com

39

securing web applications a case study presented by: doreen meyer, security programmer university of...

Documents