WhiteHat Security in the United States has published another edition of its Website Security Statistics Report. This would seem to be the 13th edition, although the numbering label appears to have been dropped.

Like previous editions, the 2013 report contains a wealth of valuable information about the prevalence of web site security vulnerabilities, the time required to resolve them, the drivers for application security, accountabilities for system/data breaches, and what type of security activities are being undertaken in the software development processes to prevent vulnerabilities occurring in production releases.

Information leakage and cross-site scripting continue to be the most prevalent issues found. SQL injection is still notable, although its prevalence has reduced slightly over the last eight years, but it is certainly not yet extinct. The most common drivers for security are reported to be compliance and risk reduction.

But I am most excited about the industry-sector scorecards included for banking, financial services, healthcare, retail and technology industry. These summarise the report's data for each sector in an easily comprehensible manner. They are ideal templates for an organisation's own high-level web site security metrics dashboards.

As mentioned before, the definition of "serious vulnerabilities" in previous versions of this report included only those with a High, Critical or Urgent severity as defined by PCI DSS naming conventions, exploitation of which "could lead to server breach, user account take-over, data loss or compliance failure". The current edition seems to have changed this to "those in which an attacker could take control over all, or some part, of the website, compromise user accounts on the system, access sensitive data, violate compliance requirements, and possibly make headline news". So somewhat wider, but it would be good to know more about this definition.

Registration is required to download the report at the link provided above.

Have you ever wondered what applications are typically being used in enterprise-scale organisations and what the risks are? A report by Palo Alto Networks has analysed over 3,000 worldwide traffic assessments to produce an aggregated summary report.

This is the first of three posts relating to publications that came out some time ago — I am just catching up, but hopefully they are worth mentioning. This first post relates to the oldest, a report published in February.

The Application Usage and Threat Report, 10th Edition provides regional data on the use of personal, business and custom/other applications on enterprise networks. The last category relates to 8-10% traffic that does not match any known application such as a custom internal application or a commercial application not yet identified in the assessment, and could include malware. The report provides data on:

• Usage of applications by category (e.g. social networking, file sharing, photo, video)
• Application functionality overlap
• Bandwidth usage by category
• Malware and exploit prevalence
• Use of transport layer security.

The conclusions include that social networking, file sharing and video applications are not the most common threat vectors; attackers are masking their activities through custom or encrypted applications. The report's data can be analysed dynamically using a well-designed online tool where the data point information is viewable for each chart element.

The PCI DSS E-commerce Guidelines v2 were a welcome update to the previous version of the document.

One of the new aspects included in the revised guidance was a discussion of the most common e-commerce implementation models (section 3.4) and what responsibilities the merchant and other parties have (section 3.5) under PCI DSS. The models discussed are:

• Merchant-managed e-commerce implementations
  • Proprietary/custom (bespoke) developed shopping cart/payment application
  • Commercial shopping cart/payment application (typically PA-DSS validated)
• Shared-management e-commerce implementations
  • Third-party embedded application programming interfaces (APIs) with direct post
  • An inline frame (or "iFrame") that allows a payment form hosted by a third party to be visually embedded within the merchant's page(s), sometimes also including other intermediaries
  • Customer redirection to a third-party hosted page for payment entry
• Wholly outsourced e-commerce implementations.

While some merchants believe they are "wholly outsourced" already, the definitions should be read. The guidance reminds merchants they still have primary responsibility for particular PCI DSS requirements. In the case of inline frame and hosted payment page approaches, this includes for example securing the web page(s) containing the iFrame code and redirection code and/or function(s) respectively.

During a recent exercise I was involved with, to identify security requirements using the OWASP Cornucopia Ecommerce Website Edition card game, a merchant's payment page hosted by a payment services provider was assessed. The process highlighted additional information security risks than those already mentioned in the PCI DSS information supplement. These related to aspects the merchant still has control over despite the outsourcing — in the exercise it was identified the merchant could customise the template of the payment service provider's page and include self-hosted (by the merchant) content referenced by the template (logo, card brand images, style sheet, and a JavaScript file). I am not sure the existing guidance is explicit enough on this aspect, and some merchants may therefore have a false sense of security, and their own risks, regarding the protection of payment cardholder data in these "semi-outsourced" (i.e. shared responsibility) situations.

If a website security assessment identified any third-party hosted content on authentication, account management or payment web pages — even JavaScript library files and web analytics code — this would normally be worthy of mention. Therefore, I think we should also take note of this merchant-controlled content appearing on payment pages/forms elsewhere, especially if the level of security assurance is different between the two (as is often the case). Merchants can outsource in an attempt to de-scope for PCI DSS and reduce the number of applicable requirements (e.g. to use SAQ A for such an online-only merchant). This may not be adequate if the merchant (its employees, contractors, systems, partners, suppliers etc) still has some control over the partially/wholly outsourced (e.g. payment service provider) hosted page/form.

Merchants should include security review and verification activities during template change processes. But regardless of PCI DSS compliance, what other technical security controls could be considered when selecting an outsourced online payment page or form? If I was a merchant, I would prefer to choose one that enables and enforces the following web application security wish list, in addition to the outsourcer's own existing PCI DSS compliance requirements:

• Page template administration
  • Each user (e.g. each designated merchant employee) with the ability to upload or edit templates to have a unique identity, and no use of shared accounts
  • Two factor authentication for all access to the outsourcer's systems (e.g. file transfers, web administrative interfaces, web services)
  • User account access limited to a small set of merchant IP addresses
  • Encrypted connections for authentication and template upload/edit
  • Event alert to nominated address/system on template change
  • Automatic stripping of any other party hosted (i.e. non outsourcer and non merchant) content from the template with related event alerting
  • Accessible audit trail of changes
• Payment form/page hosting
  • Only available using Transport Layer Security
  • No other party (i.e. non outsourcer and non merchant) content
  • No use or reliance on any merchant, outsourcer or other party HTTP cookies
  • X-Frame-Options HTTP header, with the value "DENY" for a page that is not framed, else with a value "ALLOW-FROM ..." that (supporting web browsers) only permits the particular form to be framed by the specific individual merchant's whitelist hostnames
  • HTTP Strict Transport Security Header
  • X-Content-Security-Policy/X-WebKit-CSP/Content-Security-Policy header with a strict policy that does not allow any content from other parties (or perhaps just some types of content from the merchant's selected hostnames
  • MIME type and character set HTTP headers correctly defined
  • Strong anti-caching HTTP headers
• Payment form submission
  • HTTP method POST enforced, and no other method permitted
  • Only possible using Transport Layer Security.

This is a somewhat long list, but it would be interesting to know which commonly used payment outsourcers can provide this level of assistance to ecommerce merchants.

Do you profile your customers, clients and citizens with data from your applications?

The European Commission's Article 29 Working Party has published an opinion, in the form of an advice leaflet, to provide input into the current discussions on European data protection reform.

The paper supports that the scope of Article 20 covering processing of personal data for the purpose of profiling or measures based on profiling, and that there should be greater transparency and control for data subjects of profiling and subsequent measures based upon the profile generated, and thus acknowledges the this creates more responsibility and accountability for data controllers.

However, the paper suggests profiling and measures should only be subject to additional control if they significantly affect the interests, rights or freedoms of the data subject.

See further discussion here and here.

OWASP is conducting a survey among senior information security leaders and managers and needs your help. The results will be published in the OWASP CISO Report 2013, which shall be released in Autumn.

The project team (Tobias Gondrom, Marco Morana, Eoin Keary and Ivy Zhang) have asked if we can share this invitation with security contacts in companies and other organisations. This would be a great help to achieve a broad outreach and derive valuable data and insights for OWASP and the industry as a whole.

If you are a CISO, please complete the survey; otherwise please forward details to relevant contacts.

Today's OWASP London event was very successful.

The majority of attendees had never been to an OWASP event previously, and three-quarters were developers. My own presentation has been uploaded to:

• Open Office presentation including the animated game
• Static PDF

I have also uploaded an updated version of OWASP Cornucopia - Ecommerce Website Edition (v1.01) with some minor changes and additions:

• Framework-specific card deck discussion added
• Additional FAQs created
• Descriptive text updated
• New cover image, and previous cover image moved to back
• Cut lines added
• Alternative rules and deck subset descriptions added
• Project website and mailing list added
• Cornucopia King cross-reference to AppSensor updated.

Play to win!

Update 10th June 2013: The video recordings from are now available. The videos can be accessed via the links on the EU Tour 2013 London page. The recording of my own OWASP Cornucopia Ecommerce Website Edition presentation is here.

Cornucopia Ecommerce Website Edition v1.00 was uploaded to the OWASP website in February and has now been upgraded to a full OWASP project.

Today, I have completed the new OWASP Cornucopia Project pages which include:

• Description and objectives
• Presentation given at OWASP Netherlands in March
• Links to all the references files, including a new security coding practice requirement identities, created last week
• Instructions on how to play
• Frequently asked questions
• Acknowledgements
• Road map and how to get involved
• Link to the PCISSC information supplement for PCIDSS referencing Cornucopia

Please let me know if you think I can add anything of use to the project pages.

I am also working on some minor updates to the ecommerce website edition's documentation and deck. I will be presenting the project at an event in London shortly.

Following the success of similar events in Latin America, a rolling tour of events with OWASP speakers will be occurring in European Countries, beginning with Cambridge this month.

This first event of the tour has been organised in conjunction with Anglia Ruskin University's Department of Computing and Technology for Monday 13 May 2013.

The agenda lists all the speakers:

• Adrian Winckles, OWASP Cambridge Chapter Leader & Senior Lecturer
• Ross Anderson, Cambridge University Computer Laboratory
• DI Stewart Garrick, Metropolitan Police ECrime Unit
• Justin Clarke, OWASP London Chapter Leader
• Eoin Keary, OWASP Board Member
• Steven van der Baan, OWASP Cambridge Chapter Leader
• ... and myself.

I will be speaking about application security vulnerability severity ranking and prioritisation. This will be of use if you have to create or consume vulnerability assessments and penetration test reports, or are involved in patch management or PCIDSS compliance.

Thank you to Fabio Cerullo and the OWASP team who made this tour happen.

The event runs from 11:00 to 17:15 hrs and is located in LAB 002, Lord Ashcroft Building, Anglia Ruskin University, Cambridge. It is free to attend, but advance registration is required.

Last week the UK's Department for Business Innovation & Skills published the 2013 Information Security Breaches Survey, created in conjunction with PwC.

The report presents the results of the survey and breaks the findings down for larger (>250 staff), medium and smaller (<50 staff) organisations. The term "cyber" appears 15 times and "APT" only once, so is generally hyperbole-free.

The most interesting data points for me are:

• 18% of "worst breaches" related to websites and internet gateways, and 4% to breach of laws/regulations
• For all breaches, operation disruption typically lasts a week, with 2-4weeks FTE effort responding to the incident, and a quarter of incidents leading to lost business
• Reputation losses were estimated to be between £10,000 and £100,000.

The report is available to download in full free of charge without registration.

The Verizon 2013 Data Breach Investigations Report has been published drawing on data from 19 organisations including the European CyberCrime Center.

The report includes information on 621 confirmed data breaches, the majority of which were financially motivated crime, followed by state-affiliated espionage. Although 93% of the breaches were attributable to outsiders, a significant proportion (14%) were attributable to insiders alone or insiders working with external agents. Attempts to intentionally access or harm information assets without authorisation by circumventing or thwarting logical security mechanisms (labelled "hacking" in the report" accounted for 52% of incidents. Of these, 22% related to the use of web applications.

The report can be downloaded free of charge without registration.