It does cost more to produce a secure product than an insecure product.

Most people will still shop somewhere, go to a hospital, or enroll in a university after they have had a data breach.

Why do we spend on security?  How much should we be spending?

• Security imposes extra costs on organizations
• The "security tax" is relatively well knnown for network and IT security - 5 to 10% (years of Gartner, Forrester, and other studies)
• No comparable data for development or web apps
• Regualtions and contracts usually require "reasonable measures".  What does that mean?

OWASP Security Spending Benchmarks Project

• 20 partner organizations, many contributors
• Open process and participation
• Raw data available to community

Reasons For Investing in Security

• Contractual and Regulatory Compliance
• Incident Prevention, Risk Mitigation
• Cost of Entry
• Competitive Advantage

Technical and Procedural Principles

• Managed and Documented Systems
• Business-need access
• Minimization of sensitive data use
• Security in Design and Development
• Auditing and Monitoring
• Defense in Depth

Specific Activities and Projects

• Security Policy and Training
• DLP-Type Systems
• Internal Configurations Management
• Credential Management
• Security in Development
• Locking down internal permissions
• Secure Data Exchange
• Network Security
• Application Security Programs

The 10000' View For Most Organizations

• Legal and Regulatory Compliance: Because we have to
• Incident Prevention, Risk Mitigation and Cost of Entry: Because this is what everyone else does
• Competitive Advantage: Really?

Regs are Not App Sec Friently...

• Regulations, contracts, and RFPs are usually based on the notion of "reasonable effort" - state regulations, HIPAA, FTC, SEC, Red Flags Rule
• When regulations do get technical, they focus on old school security fetishes like firewalls, SSL, encryption, biometric passes and server rooms

A Few Examples

• PCI Prioritized Approach
• Massachusetts 201 CMR 17.00
• The encryption exemption in state data breach notification laws
• HIPAA Notification Form
• Recent SEC Action
• Most of the contracts/RFPs/Vendor security whitepapers I have seen...

A Real World Example of Where Your PII Lives...

• Small company with a few dozen employees sells widgets over the Internet
• Pay an outsourced team to develop a Joomla/Drupal/whatever site to build a widget-lovers community where users can connect.  All sorts of PII involved in the app
• They deploy their site on a shared hosting/VPS model and basically only interact with the App from a web admin interface
• They know a bit about the technical details of their app but not much.  Actually, no actual web developers were really involved in the building or deployment of the app

Here is What Company A Did...

• Asked their developer team in India to develop code securely.  Referenced OWASP Top 10 or similar list.
• Told their dev team that services and DB users needed to run with minimum privilege.  Dev team balked.  Company A agreed to pay a bit extra.
• ...
• ...

Here's What Company B Did...

• Installed anti-virus on all employee machines
• Bought a firewall for the corporate network
• Maybe even got two-factor tokens for network access
• Made sure everything is going over SSL everywhere,.
• Put a biometric reader in the data center
• Encrypt all laptops

Company B is more likely to be in compliance with state laws and other regulations.

Company B is also more likely to suffer a data breach.

So the only thing left to finance your application security program is the "reasonable spend" argument...

As a community we need to get some consensus on what constitutes a reasonable spend...

About the OWASP Security Spending Benchmarks Project

• First survey focused on general web application spending.
• Second survey focused on cloud computing.
• Responses currently being gathered for third survey
• Approximately 50 companies profiled in each case
• We do not collect IP addresses
• Most of the partners are security vendors
• Relatively small respondent base
• Meant to stimulate a discussion on security spending benchmarks

Percentage of Development Headcount Spent on Security

• 41% had less than 2%
• 20% had 5-10%
• 18% didn't know
• 10% had 2-5%

Percentage IT Budget on Web Application Security

• 33% don't know
• 24% had 5-10%
• 12% had 1-5%
• 12% had 10-20%

Organizational Responsibility for Security Reviews

• 67% in IT Security

47% of companies surveyed provide developers with security training via internal resources.

• Organizations that have suffered a public data breach spend more on security in the development process than those that have not.
• Web application security spending is expected to either stay flat or increase in nearly two thirds of companies
• Half of respondents consider security experience important when hiring developers

Cloud Summary

• SaaaS is in much greater use than IaaS or PaaS.
• Security spending does not change significantly as a result of cloud computing.
• Organizations are not doing their homework when it comes to cloud security.
• The risk of an undetected data breach is the greatest concern with using cloud computing, closely followed by the risk of a public data breach.
• Compliance and standards requirements related to cloud computing are not well understood.

Future of Project

• Currently collecting responses for the third survey
• Partners assist in promoting survey, analyzing results, and providing strategic input
• Current status of project can always be found on OWASP website
• New partners are always welcome

• Before anyone starts building complex systems, they need to design.
• We create threat models on completed designs.
• What about during design?
• Book: "Core J2EE Patterns Best Practices and Design Strategies"
• If you use J2EE development, chances are you're using patterns documented here
• Core J2EE patterns are used extensively
• Patterns are used in JSF, Velocity, Struts, Tapestry, Spring, and Proprietary Frameworks

Example: Project: Analyze Patterns

Use to Implement:

• Synchronization Tokens as Anti-CSRF Mechanism
• Page-level authorizations

Avoid:

• XSLT and Xpath vulnerabilities
• XML Denial of Service
• Disclosure of information in SOAP faults
• Publishing WSDL files
• Unhandled commands
• Unauthorized commands

Project Goals

• Analyze patterns for security pitfalls to avoid
• Determine how patterns can implement security controls
• Provide advice portable to most frameworks

A security pattern is not the same as a security analysis of a pattern.

Uses

• Designing new web application frameworks (make the next generation of frameworks secure by default)
• Designing new apps that use the patterns
• Source code review of existing apps
• Runtime assessment of existing apps
• Integrate with threat modeling of new or existing apps

You can help:

• Tell developers
• Improve the analysis

Next Steps?

• Add code review and examples to the existing pattern book
• Look at other pattern books to see if there are other patterns that we should analyze

Our Dream

• New web application framework idea + Design-time security analysis = Secure-by-default web application framework

OWASP Testing Guide v3 - Spiders/Robots/Crawlers

1. Automatically traverses hyperlinks

2. Recursively retrieves content referenced

Behavior governed by the robots exclusion protocol.  New method is <META NAME="Googlebot" CONTENT="nofollow">  Not supported by all Robots/Spiders/Crawlers.  Traditional method is robots.txt located in web root directory.  Regular expressions supported by minority only.  "User-agent: *" applies to all spiders/robots/crawlers or you can specify a specific robot name.  Can be intentionally ignored.  Not for httpd access control or digital rights management.

Testing - Robots Exclusion Protocol

1. Sign into Google Webmaster Tools
2. On the dashboard, click the URL
3. Click "Tools"
4. Click "Analyze robots.txt"

Search Engine Discovery

Microsoft Remote Desktop Web Connection: intitle:Remote.Desktop.Web.Connection inurl: tsweb

VNC: "VNC Desktop" inurl:5800

Outlook Web Access: inurl:"exchange/logon.asp"

Outlook Web Access: intitle:"Microsoft Outlook Web Access - Logon"

Adobe Acrobat PDF: filetype:pdf

Google caught onto this and is now displaying a "We're sorry" message with certain searches.  To get around, use different search queries that returns overlapping results.

Google Advanced Search Operators: "site:" and "cache:"  Two ways of using "site:".  EIther as "site:www.google.com" where you get that specific subdomain's results or "site:google.com" where you get all hostnames and subdomains. Use "cache:www.owasp.org" to display an indexed web page in the google cache.  There is also a site operator labeled "Cached" which will do the same thing.

You can get updates of the latest relevant Google results (web, news, etc) using Google Alerts.

Download Indexed Cache

Google SOAP Search API.  Query limited to either 10 words or 2048 bytes.  One thousand search queries per day and limited to search results within 0-999.  Up to 10K possible results from 10 different search queries.

$Google_SOA_Search_API -> doGoogleSearch( $key, $q, $start, $maxResults, $filter, $restricts, $safeSearch, $lr, $ie, $oe );

See presentation for response.

Proof of concept tool is "dic.pl" or "Download Indexed Cache" that downloads the search results.  Licensed under the Apache License 2.0.  Tool produces a URL and cachedSize response.

OWASP Google Hacking Project

Tools built using Perl using CPAN Modules SOAP::Lite, Net::Google, and Perl::Critic.  Development environmetn is based on Eclipse with EPIC Plug-in.  Subversion repository is at code.google.com.

Roadmap

Upcoming presentations at ToorCon X in San Diego, SecTor 2008 in Toronto, Canada, and RUXCON 2K8 in Sydney, Australia.

"TCP Input Text" Proof of Concept

"Speak English" Google Translate Workaround

Refactor and 3rd Project review of PoC Perl Code with public release at RUXCON 2K8 in November 2008.

Check in at code.google.com after RUXCON 2K8

4 hr "half day" training course Q1 2009