Date post: | 22-Dec-2015 |
Category: |
Documents |
Upload: | georgiana-flowers |
View: | 218 times |
Download: | 3 times |
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
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 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
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 email 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 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
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