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.

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.

I have just had time to catch up on my attendance and participation at Security B-Sides London 2013.

This community-led event was held at the town hall of the Royal Borough of Kensington and Chelsea on Wednesday 24th April, and was supported by a large number of speakers, educators, volunteers and sponsors. It was an extremely well organised, and useful, day.

Following the very well attended welcome and introduction from the B-Sides London crew, I went to an immensely valuable and engaging presentation by David Rook (aka Security Ninja) on how he introduced and developed an application security programme at his employer Realex Payments. He has got to the point where customers are approaching his company to act as a payment services provider due only to their knowledge of Security Ninja, and so the marketing department kindly designed cartoon-style presentation slides (like the one illustrated above). They also had these printed as booklets to hand-out to those attending the talk at B-Sides London. David described what was done, how it was achieved, and things he would approach differently in hindsight. I won't spoil the plot for you as you will be able to read the booklet yourselves (keep an eye open for a blog post (now available).

After this, I went down to the new Rookie Track where new presenters had been given support through mentoring to give 15-minute presentations. Firstly I listened to Artjom Vassiljev describe how he has built software security testing checks into a continuous integration process with Jenkins.

Following a quick coffee break and catch up with some friends & acquaintances, I returned to the Rookie Track and listened to Diarmaid McManus describe a new Eclipse plugin called ESP he has been working on to help integrate code review checks into developer's coding tools.

Ksenia Dmitrieva provided an introduction to HTML5 risks and gave explanations and examples of common attacks. She also explained the preventative measures which should be used to protect against these issues.

Post lunch, I tracked down Dinis Cruz and we set up our workshop on using OWASP O2 to visualise OWASP AppSensor behaviour. I introduced the concept of application-specific attack detection and response, and described how the ideas might be retrofitted relatively simply to an existing web application such as the bulletin board software phpBB. A review of phpBB's inherent capabilities and logging provide a useful hook for detection points, and responses can include adding users to phpBB's list of "banned IPs" and blocking IPs at the operating system level. Dinis continued with a live demo of the AppSensor demo application, created by Michael Coates, and then he went on to show how AppSensor's new web services Java code can be called directly from within a .Net application TeamMentor.It was good to bounce ideas off the workshop participants and get their thoughts and suggestions on the practicalities of implementing AppSensor-like capabilities.

Finally I saw Gavin Holt talking about "NoSQL & Big Data - A Way to Lose Even More Stuff" in which he described the common weaknesses in using NoSQL and attacks that attempt to access such systems and their data. I really liked the 15minute format on the Rookie Track and all three speakers I heard were really good.

Overall, an excellent day. Many thanks to the very professional B-Sides London team in particular for making sure it all happened.

Update 30th April 2013: Link to Security Ninja's slides added. Ksenia Dmitrieva's talk added.

Selecting and deploying a web application firewall (WAF) needs to be undertaken using robust due diligence procurement/acquisition processes.

A recent report (discussion) compares three different WAFs — two cloud-based systems and one that is integrated with web server software. The report describes testing SQL injection, cross-site scripting and local/remote file inclusion. I don't think the exact findings are of direct relevance to most real-world deployed applications, but the conclusions to be drawn are:

• Read this first
• Consider the rate of both false negatives and false positives
• Tune the WAF to your own application(s)
• Work your WAF - do not turn it on and forget about it
• Do not rely on a WAF

So, in summary, try before you buy.

See also Waffish Behaviour in 2012.

On Wednesday this week, Trustwave has published the full version of its latest global information security report. It is comprehensive, information-rich, and well designed.

2013 Trustwave Global Security Report (registration required) provides information from their incident investigations, updates from law enforcement agencies around the world (including SOCA), threat intelligence (attack sources, motivations, emerging techniques, attacks and defences), and some international perspective viewpoints. The sources used to aggregate data and draw conclusions from include their vulnerability scanning, penetration testing and incident response investigation services, publicly disclosed data breaches, email sources, published vulnerabilities, and analysis of malicious web sites. Even this cannot be said to be completely representative, but it is amongst the better data available.

Based on the incident investigation information, payment cardholder data was the primary target because it is highly saleable for subsequent use in fraudulent transactions. Secondly personal data is noted as having some monetary data. The primary targets were retail, food & beverage and the hospitality sector via their e-commerce and retail channels (web sites and point of sale/payment processing). These of course reflect organisations that are required to, or felt the need to, engage a company like Trustwave to perform incident investigation. Thus there will be a bias towards medium and larger organisations with personal, credit and debit card data.

Where large quantities of data were compromised, the incident investigations identified weak administrative credentials, SQL injection and remote file inclusion as the primary vulnerabilities, with data being exfiltrated using HTTP and HTTP over TLS, RDP, SMTP and SMB protocols due to missing egress firewall controls. The report recommends building a defence in depth strategy with multiple layers of security. In terms of important applications, a holistic approach that builds security in throughout the development and operation is required. In the section on international perspectives for EMEA, the report notes there is an increasing trend of medium-sized and non-banking organisations developing strategic application security programmes, where assurance activities are based on the business risk each application presents.

Information points from the WASC Web Hacking Incident Database are also presented. These relate to publicly reported incidents of web applications during 2012 that have an identified outcome. This does not pretend to be fully representative of all web application attacks, but it does represent many significant events. The most common attack methods were denial of service followed by SQL injection.

The top 10 application vulnerabilities (I believe the label on the table on page 50 possibly mistakenly includes the word "mobile") highlights how common cross-site scripting (XSS) and cross-site request forgery (CSRF) are, based on a sample of application penetration tests. Separate information is also presented for mobile application penetration tests, comparing the findings to the OWASP Mobile Top 10.

The other part of the report of interest to application software designers and architects is the statistical analysis of nearly 3.1 million encrypted passwords from Active Directory servers. In order of number of occurrences "Welcome1" is the most common password, followed by "STORE123", "Password1", "password", "Hello123", and "12345678". "training" and "Welcome2". "STORE123" sounds very like point of sale (POS) systems. These results and analysis of password composition and markup will be useful where there is a desire to limit the use of common passwords and formats.

Definitely worthwhile reading.

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.

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.

An updated information supplement on Payment Card Industry Data Security Standard (PCI DSS) E-Commerce Guidelines has been released by the PCI Security Standards Council (PCISSC).

PCI DSS E-commerce Guidelines v2 is the result of work by the PCISSC's E-commerce Special Interest Group, and provides guidance for business that sell goods and services over the internet.

The guidance includes an overview of e-commerce terminology and architectures, roles and responsibilities, and summarises common vulnerabilities in e-commerce environments (injection flaws, cross-site scripting, cross-site request forgery, buffer overflows, weak authentication and/or session credentials), and common security "misconfigurations". The latter is not all about configuration and includes for example "Using secure software development and coding practices for websites" (PCI DSS Requirements 6.3-6.5).

The document also lists eight key recommendations, and also includes two appendices — one is a cross-reference between identified PCI DSS requirements and the corresponding e-commerce guidance, and the second provides a checklist to help identify and assign responsibilities between the merchant and third party service providers.

A list of additional resources to help identify "industry-accepted best practices and guidelines" is provided referring to OWASP, SANS Institute, CERT Coordination Centre, the Centre for Internet Security and ISACA. It is a pity OWASP Cheat Sheets are not directly referenced. However, I am pleased to see that my own Cornucopia E-commerce Web Site Edition, a card game to help developers enumerate and discuss potential application security requirements using data from the OWASP Secure Coding Practices - Quick Reference Guide, is referenced in the section about OWASP.

There is news coverage elsewhere here, here, here and here.