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.

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.

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.

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.

Three regional OWASP application security conferences are planned for later this year.

OWASP runs the most comprehensive application security conferences with a very high standard of training courses, speakers and delegates to network with. The next three conferences are:

• August 20-23: AppSec EU Research 2013, Hamburg, Germany
• October 1-4: AppSec Latam 2013, Lima, Peru
• November 18-21: AppSec USA 2013, New York, USA

The calls for training and papers are open for AppSec EU and AppSec USA. I hope to attend both of these. AppSec Asia will occur again in spring 2014.

The SANS Analyst Program has published a white paper by Jim Bird and Frank Kim.

SANS Survey on Application Security Programs and Practices describes the results of a sponsored survey of 700 employees with responsibilities for security, management and software development. The aims of the survey were to identify the drivers for application security programs, the greatest risks, how resources are prioritised, what practices are being undertaken, which tools and services are used, programme challenges, and the maturity and effectiveness of the programmes.

Similar to the 2011 report from Forrester Research, the most import driver for application security programmes (secure software development life cycles) are regulatory/compliance requirements with Payment Card Industry (PCI), US Sarbanes–Oxley Act (SOX) and the US Health Insurance Portability and Accountability Act (HIPPAA) being the most common.

The comprehensiveness of application security programmes is reviewed for internally-developed, outsourced application development, and commercial off the shelf (COTS) applications. Apart from policies and vulnerability awareness, and risk assessments/due diligence of third parties, the survey primarily reports on technological controls and practices. These are static analysis code review, dynamic analysis (e.g. vulnerability scanning), manual penetration testing, and use of web application firewalls (WAFs) and using WAFs for virtual patching.

There is no mention of other practices that can contribute such as defining security requirements, producing guidance materials, training, design and architecture reviews, secure deployment (see more in the Software Assurance Maturity Model, BITS Software Assurance Framework, BSIMM, etc).

See also the related Application Security Gap Study and Protection Against Business Logic Attacks.

Two organisations have recently announced skill standards in the software security and wider information assurance areas.

The UK's The National Skills Academy has announced new draft IT National Occupational Standards (NOS) for information security. These are for:

• Information Security Risk Assessment and Management
• Secure Development and Information Security Architecture
• Information Security Testing and Information Assurance Methodologies
• Operational Security Management
• Incident Management, Investigation and Digital Forensics
• Information Security Audit
• Information Governance

Secondly, as part of the Build Security In Software Assurance Initiative, the US Department of Homeland Security's Office of Cybersecurity and Communications has announced its draft Software Assurance (SwA) Competency Model. This was developed to create a foundation for assessing and advancing the capability of software assurance professionals. The draft model is supported by other materials on the related Software Assurance Curriculum web site from CERT.

The current hot topic in the news is the revelation that horsemeat has contaminated the UK's food supply chain. This follows on from recent findings that suggest halal food supplied to some prison contained pork.

The outrage about eating horses and about retail products not containing ingredients other than those listed on the label has raised concerns about how the integrity of the food supply chain can be ensured. There is much more legislation around food standards (for example coffee and juice), and better labelling, but food appears to suffer from similar risks as the software supply chain.

Well there are usually no easy answers, but for once it seems the software assurance community is ahead of food standards. If you don't want unknown ingredients in acquired software code, take a look at:

• Notional Supply Chain Risk Management Practices for Federal Information Systems, NISTIR 722, Interagency Report, NIST, 2012
• Software Assurance in Acquisition and Contract Language, Software Assurance Pocket Guide Series, Software Assurance, US Department of Homeland Security, 2012
• Software Supply Chain Risk Management: From Products to Systems of Systems, Technical Note CMU/SEI-2010-TN-026, Software Engineering Institute, Carnegie Mellon University, 2010
• Evaluating and Mitigating Software Supply Chain Security Risks, Technical Note CMU/SEI-2010-TN-016, Software Engineering Institute, Carnegie Mellon University, 2010
• An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain, SAFECode, 2010
• Framework for Software Supply Chain Integrity, SAFECode, 2009
• Software Supply Chain Risk Management and Due Diligence, Software Assurance Pocket Guide Series, Software Assurance, US Department of Homeland Security, 2009

For some light relief on the horsemeat story, see the jokes here and here.

Applications that accept payments and are installed on consumer mobile devices, not used exclusively used for a single payment application, such as smart phones, tablets and PDAs have been excluded from the PCI SSC's validation programme Payment Application Data Security Standard (PA-DSS). These types of mobile payment acceptance applications are known as Category 3 - payment applications operating on any consumer electronic handheld device that is not solely dedicated to payment acceptance for transaction processing.

Mobile payment Acceptance FAQs, published in June 2011, recommended that Category 3 applications intended for use in the cardholder data environment are developed using PA-DSS as a baseline for protection of payment card data and in support of PCI DSS compliance, until the development of appropriate advice, guidance, and/or standards to ensure that such applications are capable of supporting a merchant's PCI DSS compliance. On Friday the PCI SSC published new guidance for developers.

PCI Mobile Payment Acceptance Security Guidelines v1.0 September 2012, describes firstly 3 objectives and guidance for application payment transactions:

1. Prevent account data from being intercepted when entered into a mobile device
2. Prevent account data from compromise while processed or stored within the mobile device
3. Prevent account data from interception upon transmission out of the mobile device

Secondly, guidance on 15 risks and controls in the supporting environment (mobile platform and associated applications):

1. Prevent unauthorized logical-device access
2. Create server-side controls and report unauthorized access
3. Prevent escalation of privileges
4. Create the ability to remotely disable payment application
5. Detect theft or loss
6. Harden supporting systems
7. Prefer online transactions
8. Conform to secure coding, engineering, and testing
9. Protect against known vulnerabilities
10. Protect the mobile device from unauthorised applications
11. Protect the mobile device from malware
12. Protect the mobile device from unauthorized attachments
13. Create instructional materials for implementation and use
14. Support secure merchant receipts
15. Provide an indication of a secure state

Recognising that no one party has sole responsibility for security of Category 3 applications, a table in Appendix B of the guidance suggests responsibilities for the 18 practices. The responsibilities are assigned to device manufacturers (e.g. Apple, Huawei, Motorola, Nokia, Samsung), operating system developers (e.g. Apple, Google, Microsoft), application developers (e.g. you?), and merchants as end-users or payment acceptance service providers.

The guidance also provides a list of ten additional sources of information to support the guidance. Further advice and standards on mobile payments are expected from the PCISSC in 2013.

In the next post, I will discuss some related updated guidance from Visa.

Summer must be the time to publish consultations before everyone goes away on holiday. the European Commission (how the EU works) has published a consultation regarding information risk assessment and breach notification.

The public consultation briefing describes how the European Commission is seeking to adopt a joint strategy with the High Representative of the Union for Foreign Affairs and Security Policy, that will ensure a secure and trustworthy digital environment, while protecting fundamental rights and EU core values. It is considering three approaches:

• Voluntary cooperation and information exchange between member states, the public and private sectors as happens currently
• Taking up minimum capabilities at a national level and promote a more structured approach to cooperation and information exchange
• Legislation to define minimum network and information security (NIS) capabilities for member states, a dedicated network for cooperation and information exchange, and most interestingly requirements for the private sector to adopt "NIS enhancing actions"

Within the last option, the Commission is considering a requirement to adopt risk management practices and to report security breaches to networks and information systems "that are critical to the provision of key economic and societal services (e.g. finance, energy, transport and health) and to the functioning of the Internet (e.g. e-commerce, social networking)".

The Commission has prepared a response form (web form, PDF) that asks a series of wide-ranging questions of governments, businesses and citizens, and there is scope for long answers and for submitting additional documents. The responses will be used to identify strategic actions and contribute to its impact assessment of the proposals. If your trade organisation or professional association is not planning a response, chase them up now.

The consultation runs until mid October 2012 (the 12th or 15th depending upon which document you believe).