Further to my previous notes about HTML 5 security, a superb reference document was published earlier this month.

Michael Schmidt (Compass Security) wrote his master's thesis about HTML5 security in May 2011 and has published an extract for everyone to access.

HTML5 Web Security describes issues, vulnerabilities, threat & attack scenarios and countermeasures across 80 pages including numerous well thought-out diagrams, and is backed up with detailed references and an appendix full of attack details.

The main sections are:

• 2.2 Cross-origin resource sharing
• 2.3 Web storage
• 2.4 Offline web application
• 2.5 Web messaging
• 2.6 Custom scheme and content handlers
• 2.7 Web sockets API
• 2.8 Geolocation API
• 2.9 Implicit relevant features of HTML5
  Web workers, new elements, attributes and CSS, Iframe sandboxing and server-sent events

If you are already developing HTML, or planning to, read this document as soon as possible and update your requirements documents, specifications, design documents, coding standards, and test plans to incorporate the knowledge.

The document would be worth buying if it were a book, but it has generously been made available publicly. Yes, I am still reading the document, and so far have only one very minor complaint — it would be good to have a content list. Maybe in version 1.1?

The UK's Centre for the Protection of National Infrastructure (CPNI) has updated its guidance on protecting business applications with the publication this month of a new document on developing and implementing secure web applications.

Development and Implementation of Secure Web Applications is a well-written and digestible 81-page A4 document arranged in seven main sections:

• Introduction to web application security
• General aspects of web application security
• Access handling (authentication, session management and access control)
• Injection flaws
• Application users and security
• Thick client security
• Preparing the infrastructure

It appears to replace the good, but somewhat dated document "Briefing 10/2006 - Secure web Applications - Development, Installation and Security Testing" created by their predecessor National Infrastructure Security Co-ordination Centre (NISCC), and issued in April 2006. The new document is more compact and focused, and I think I prefer it. Yes of course it is more up-to-date, and while it would be possible to argue why some things are included and not others, these others things tend to be explained further in the references. It's clear there is considerable overlap with information from OWASP and the Microsoft SDL, but I'm sure the reverse is true to an extent too.

It is very encouraging CPNI have taken the time to produce an updated document, but that probably reflects the types of risks facing their audience. I am especially pleased to see the section on infrastructure, since application security cannot be an island on its own. I would say the guidance is probably on the medium-to-heavy weight side of advice, but that is probably appropriate for critical national infrastructure, and the document does discuss threat modelling initially. It might seem overwhelming to some organisations new to the subject, and that might need some help on what to do first.

I think the document could perhaps do with more cross-referencing to additional information resources elsewhere. Yes, documents can always be improved, and I am sure we will find niggles and faults with use, but threats evolve and so does our knowledge.

Today I came across a useful marketing-related discussion of common e-commerce trustmarks.

Which E-commerce Trustmarks Are Most Effective? describes a study of twenty different security-related trustmarks that cover SSL certificates, payment card merchant identity, business accreditation and that all-embracing term "security".

The 150 US respondents identified which logos they recognised, and then ranked them according to level of "reassurance". Very few trustmarks were actually recognisable, but those that were appeared to provide some level of increased trust. Of course, the top three (PayPal, Verisign and McAfee) are different types of thing — a payment service provider, an SSL certification authority and a site information security scanning service. Maybe it doesn't matter what service you provide as long as it is recognisable?

The blog post also lists other ways to increase user trust, and suggests that good checkout design can trump trustmark logos.

No mention of browser SSL indicators, security labelling, national reputation or HTTP security headers! And neither are having lots of credit card logos displayed nor "PCI DSS compliant" beside a PCI SSC logo which of course aren't trustmarks, but are used as such by some organisations.

Maybe UK customers would respond differently?

I have been invited to run a workshop at the next Software Assurance (SwA) Forum in Arlington, Virginia.

The Software Assurance Program of the US Department of Homeland Security's National Cyber Security Division co-sponsors SwA Forums semi-annually with the US Department of Defense and the National Institute for Standards and Technology (NIST). The events aim to bring together government, industry, and academia with vested interests in software assurance to discuss and promote integrity, security, and reliability in software.

My session on Wednesday 14th September in the track on "SwA at the Code Level" will relate to the content of the full-day training course "Application Attack Detection & Response" I am providing at OWASP AppSec USA the following week in Minneapolis.

At the SwA Forum I am also looking forward to the subsequent workshops on Dimensions of Static Analysis-Based Assurance with Mike Oara, OWASP Acquisition Language for Software Assurance with Jeff Williams, and Scaleable Application Security Practices with Jim Manico. I am also hoping to hear about any updates to the previously mentioned Software Assurance Pocket Guides.

Please do attend. The 5-day programme is packed with useful sessions on practical software assurance topics..

SwA Forum - Fall 2011 is being held at the Software Engineering Institute (SEI), 4301 Wilson Blvd, Arlington, VA 22203, from 12th to 16th September 2011. There is no charge for the event but prior registration is required.

Do you remember Lush Cosmetics' rather public payment card data and personal data loss announced in January 2011? After 4 months of being compromised, the problem was recognised, customers were notified and the web site was shutdown.

Lush had allowed people's data to be stolen via its own web site. We still await to hear what the fines and other penalties will be levied under the Payment Card Industry Security Standards Council (PCI SSC) Data Security Standard (DSS) if they are found to have been non-compliant at the time. However the UK's Information Commissioner's Office (ICO) became involved due to the related loss of 5,000 individual's personal data and confirmed in a press release on Wednesday this week that Lush Cosmetics had also breached the Data Protection Act 1998. Formed in 1994-1995, Lush Cosmetics has been a registered data controller (No. Z8189523) since late 2003.

As expected, no enforcement notice or monetary penalty has been issued, but Lush Cosmetics Limited's Managing Director, Mark Constantine, has signed an undertaking to ensure that personal data are processed in accordance with the seventh data protection principle concerning security, and in particular take the following measures to improve the protection of personal, and cardholder data:

1. Appropriate technical and organisational measures are employed, and maintained, to prevent the unlawful processing of customer data, particularly within web based systems;
2. Only the minimum amount of customer personal data is stored and that this is retained only for as long as a relevant business need exists;
3. Computer systems storing customer personal data must be subject of regular penetration testing , with activity logs retained for an appropriate period of time and frequently interrogated for evidence of malicious attack;
4. The processing of customer credit card data is conducted by a PCI compliant external service provider;
5. The data controller shall implement such other security measures as it deems appropriate to ensure that personal data is protected against unauthorised and unlawful processing, accidental loss, destruction, and/or damage.

...as long as the Data Protection Act, or succeeding legislation are in force. So correctly a focus on Lush's web systems, including penetration testing of systems holding personal data. But also other appropriate security measures as necessary. Let's hope Lush aren't left thinking penetration testing is the answer — security needs to be considered at all stages of acquisition, development, deployment and operation.

And yes, that's right, the ICO is insisting on compliance with PCI DSS. The ICO made it clear in the press release of its expectations for PCI DSS compliance by other online retailers, that will otherwise risk enforcement action by the ICO.

This seems to be a valid approach, since fines, investigation costs, etc may still be levied for lack of PCI DSS compliance too. But I have some concerns with how Lush are portraying their squeaky-clean new status in the web site's terms and conditions:

I'm not entirely sure that moving all cardholder data off-site to a PCI DSS compliant third party processor necessarily means much about the security of other data on the Lush web site and elsewhere at Lush, or much about systems outside the cardholder data environment. Is this just meaningless bubbly rhetoric to provide false assurance, or maybe Lush still does not understand what they are doing? Complying with regulatory and contractual mandates isn't the same as believing in "filling the world with perfume and in the right to make mistakes, lose everything and start again". Some of that "honest meaning" mentioned by Lush would be welcome here too.

Personally I think the PCI SSC should be a bit more strict about how their name can be used to endorse systems. Hey, clerkendweller.com meets PCI DSS compliance criteria too! There's no cardholder data to begin with...

Last week the government launched its Consumer Empowerment Strategy which examines ways of helping the most vulnerable and disadvantaged who may not otherwise benefit from rapid technological and social change.

The strategy document Better Choices: Better Deals was published by the Department for Business Innovation and Skills and the Cabinet Office. At the same time, the Office of Fair Trading released a supporting document on Empowering Consumers of Public Services Through Choice-Tools (structured sources of information, discussion, and comparison that help consumers compare and choose between alternative service and product offerings).

Well there is a lot in these reports which will be off-topic for most readers here, but I thought I would highlight two matters.

Firstly, the intent to create a self-regulatory quality mark for web sites is outlined. This is targeted only at consumer feedback sites and comparison sites with the intention of promoting responsible businesses and to help consumers identify which online tools they can trust. It will be interesting to see if there are any minimum security and privacy criteria for sites to be awarded the quality mark. Perhaps the consumer reviews are honest, but what if it "loses" your personal data or gives you a dose of malware at the same time? The strategy also notes the need for targeted enforcement action against businesses that illegally and deliberately undermine the effectiveness of consumer feedback.

Secondly, the document also mentions a new web directory Brand-i launched by The Trading Standards Institute, and paid for by business partners, to allow consumers to identify if a web site is the official e-commerce store for that brand or how to report it if it is not. Very good intentions, but it seems unusual it doesn't have a .uk domain, and perhaps this site should be SSL-only, and be another candidate for an extended verification (EV) SSL certificate? After all, how will consumers know they can trust the source & information about the brands on their screens?

On Sunday morning, I was intrigued to read on Web Application Security - From the Start about a security vulnerability supposedly found on the Child Exploitation and Online Protection Centre (CEOP) web site.

But it is apparently true, the short story on the BBC web site seemed to be confirmed in their interview with CEOP which was mentioned by @StewartRoom, @xklamation, @siliconglen, and received further coverage yesterday in IT Pro and IT Week. I wondered where this report came from and how the Information Commissioner's Office (ICO) became involved so quickly. IT Week suggests a member of the public tested the CEOP site and then told them of the problem; presumably CEOP then reported it to the ICO.

Don't get me wrong, I think the ICO should investigate whether there has been a breach of the Data Protection Act 1998, but some of the information released so far doesn't seem correct. The BBC story includes several statements supposedly attributed to CEOP's Chief Executive Peter Davies. But I cannot quite believe CEOP would say some of these things about a web form to report alleged offenders, so perhaps sadly there is some over-zealous PR going on, or misinterpretation by the BBC's journalist.

A later item on The Register Child protection Website Insecurity Fixed paints a slightly different picture, suggesting the form is, and always has been, using SSL only, but that there was a link to a non-SSL address which then redirected. I must say, I'm inclined to believe The Register's version more than the BBC. I think we have to leave it up to whoever is investigating to get to the true facts, but it does seem to be creating a link between personal data protection and the use of SSL.

It is perhaps not always clear to government agencies what administrative, physical and technical security practices should be implemented to protect a web site, and who makes the decisions. The government's Central Office of Information (COI) have never published any web standards and guidlines on security or privacy protection, perhaps feeling it is some other agency's responsibility (maybe CESG, CPNI or even the ICO?).

The security measures implemented for a web form like this ought to be similar to those defined in open standards, and common sense alone would tell you this is an obvious place for using appropriately designed HTTPS. Anyone auditing or verifying the security aspects would have made this clear in large red letters, but waiting until after being made live is incomprehensible too. Security and privacy need to be considered from early stages in every project, and built in to the final system. There are existing standards for that too.

But I am concerned about some statements which have been reported. If they are true, I am worried.

"All secure website carried the prefix https, compare[d] to http for insecure ones"

False. Using HTTP over SSL does contribute to the protection of a user's, or organisation's, data in transit and also gives some degree of identity assurance. There is even a campaign to increase adoption. But SSL is not the same thing as a web site being secure. A web site using SSL can still be vulnerable to attacks (e.g. SQL injection, cross-site scripting, cross site request forgery) leading to contamination with malware or data damage, loss and destruction.

SSL does not stop breaches of the Data Protection Act.

"It's been fixed now"

Really, that quickly? There's more to implementing SSL than just turning it on. Last year I mentioned some other concerns about CEOP and trust, but you cannot check or test a web site without authorisation. On Sunday, @siliconglen also asked why they CEOP were not using an extended verification (EV) SSL certificate. For many purposes I'm on record as saying EV certificates are not needed, but here I agree, I think an EV certificate should be used. And really, why not have the whole site SSL.

Of course, all organisations would do well to ensure that their SSL certificates are valid, applied appropriately to the applications and that SSL is configured securely, such as ensuring weak protocols and ciphers are not available. They should also think about whether any data can be cached locally on the web browser, whether other domains have access to the web page contents, and what exactly is done with the sensitive data once it is saved on the web site. How secure are the information systems and subsequent processes?

Fix and verify.

Conclusion

Other public and private sector organisations take note. It will be interesting to see the outcome of the ICO investigation and whether this incident leads to a change in attitude, or even sets a precedent for online data protection requirements.

SSL has its problems, see here, here and here, but it would be wrong not to implement it. After all we've been using it for over ten years to help protect credit card data in online shopping; information from children about possible offenders is an order of magnitude more important than payment card data.

I just hope some of the statements that appeared in the BBC article about SSL were misinterpreted, and don't become the accepted understanding. CEOP please set the record straight.

Spring does seem to be a popular time for organisations and vendors to issue reports. I'm sure we'll be seeing more in the run up to Infosec Europe 2011, but I will keep you informed of anything topical.

The European Network and Information Security Agency (ENISA) issued Data Breach Notification Insights in January and in the last few weeks has issued three other reports which may be of some general interest.

Botnets: Measurement, Detection, Disinfection and Defence

Botnets: Measurement, Detection, Disinfection and Defence describes 25 different practices to measure, detect and defend against botnets. These are discussed under the objectives of mitigating existing botnets, preventing new infections and minimising the profitability of botnets and cybercrime. The recommendations are then discussed for particular groups — regulators & law enforcement, internet service providers, researchers, end users and companies.

Mapping Security Services to Authentication Levels

This report examines e-identity management in the European Union, and in particular the activities of STORK (Secure idenTity acrOss boRders linKed). It looks at the various authentication levels and their mapping to public electronic services in the eGovernment programme framework.

Resilience of the Internet Interconnection Ecosystem

The authors of the latest ENISA report discuss Internet vulnerabilities, concerns about the sustainability of current business models, and the interactions of dependencies and economics. They describe the issues and propsoe eleven recommendations to increase the Internet's resilience.

Online behavioral advertising continues to be in the news (see also previous here, here and here). The US Federal Trade Commission (FTC) has now issued a preliminary staff report which has been widely discussed (including here, here, here and here.)

The FTC's work was prompted by the lack of success with "notice-and-choice" and "harm-based" models to provide adequate and meaningful consumer protection, despite various industry initiatives such as self-regulation. The FTC report proposes a new framework and suggests organisations should adopt a privacy-by-design approach in their information systems and business processes, provide greater clarity in explaining their use of personal data and, for practices that are not "commonly accepted", provide information so that people can make informed and meaningful choices. One example of this, and the aspect which seems to have the most attention, is the ability for consumers to make a universal choice whether they allow their data to be used in behavioural advertising i.e. have the ability not to be tracked. And the FTC suggests organisations need to make their actions more transparent, and also help in the effort to educate consumers.

Note, the FTC document refers to "consumers" due to their area of responsibility, but the concepts could/should also be relevant to other personal data (e.g. employees, citizens).

But what does "no tracking" mean? There are already some initiatives in this area (e.g. the Network Advertising Initiative (NAI) Opt-out Tool and the Interactive Advertising Bureau (IAB) Self-Regulatory Program for Online Behavioral Advertising). The FTC has testified that the mechanism should be browser based allowing consumers to opt out easily and permanently. There has been debate about how "Do Not Track" might be achieved online, and a suggestion is organisations honour a new HTTP header. The "X-Do-Not-Track" header would be sent if the user (consumer?) had set this as their preference (or not deselected it?). See http://donottrack.us/ for more discussion.

Tracking might involve cookies and recording data such as the type of device, configuration, user location & IP address, and using this to serve targetted "behavioural advertising".

Cleaning your own web server log files of tracking data is not going to be enough.

Any system that receives HTTP requests, including advertisers would have to honour the setting. But this does not just apply to advertisements. Look for anything hosted on another system such as:

• inline content (news, images, videos)
• JavaScript libraries
• trust seals (e.g. SSL certificate verification, privacy seals, trust schemes, tested for security, etc)
• web analytics
• widgets (e.g. buttons).

And these might be server from your own systems, not just third parties. Personal data may also be stored by the application on the user's own system locally. The question also arises what exactly constitutes "tracking", and whether audit and security event logs would be considered as tracking. Even traffic management and anti denial-of-service (DoS) systems track users to a degree, as of course does session management. Practices necessary to perform the designated service are likely to be acceptable, providing data are not kept indefinitely, and it is the usage for purposes which the user might not have expected, which is the real concern. Do users "expect" seceuity event logging? The examples on the http://donottrack.us/ discuss prevention of logging in web server log files, not other usages such as session management or incident monitoring. So guidance will be required.

The issue of tracking and personal data leakage may come as a surprise to some web site owners, and it was to the NHS, but is rather old news really. Like knowing all the components that make up your web site, and all the allowable entry points, knowing where you are sending data really is a baseline information requirement. The NHS example relates primarily to leakage of sensitive data to other parties, and the Obama example to security risks (see extended explanation.) The results of the FTC's final report next year will affect internet users worldwide as similar policies are likely to be adopted in other countries.

The FTC is asking for comments on its proposals by 31st January 2011. Their own suggested questions are listed in Appendix A of the report.

Service and ownership location can be fundamental selection factors for online users. The importance of confidence in the UK's digital economy was highlighted in the Digital Britain Report (2009) and more recently in the Cabinet Office's Cyber Security Strategy of the United Kingdom/Fact Sheet on Cyber Security and EURIM's Can Society Afford to Rely on Security by Afterthought Not Design?. Building trust in the .UK brand is a necessary part of a healthy competitive economy.

Hand-in-hand with creating "the best place to do online business", the UK needs to increase visibility of the geographical properties of its online organisations. I wonder if in time, we will have more "country of origin" information, like the security labelling mentioned on Friday, to help users (employees, customers, clients, and citizens) make informed choices about who they will share information with and buy products & services from.

A ruling last week by the EU Court of Justice suggests that companies directing their activities at foreign consumers, will affect where they can take legal action, or have legal action taken against them. "Directing" may include using a domain name of another country, using a .com domain name, quoting international contact details, mentioning country names (e.g. delivery rates) or offering country/lanuague options.

We have already seen moves to ensure .uk domains are not used for criminal activities, but is the domain name enough? No. Without getting jingoistic, as the ruling indicates, there are all sorts of additional geographical properties that affect users' rights and the ability for governments to enforce legislation. An equivalent to the "Security Facts" label might be "Location Facts":

where "GB" is the ISO 3166-1-alpha-2 code for the United Kingdom. In the example on the left, the application is hosted in Germany and has some data transfers to the United States because of web analytics, SSL verification and inline advertisement code hosted there. Of course, the situation can be complex, and in a single label it can be difficult to describe all the important geographical properties, but let's at least try. Knowing the locations of each element of the supply chain is less relevant to the end user than the details above.

These two examples are just made up to emphasize the possibilities and are not meant to be xenophobic in any way. Consumers, and other web product users, should be able to find out who they may be interacting with and the scope for redress in the event of a problem, so they can make their own choice? This is no different to having the place of origin on food product labelling.

This quotation from the forward by James Paice, Minister of State for Agriculture and Food, to the British Retail Consortium's new guide on Principles on Country of Origin Information couldn't explain it better:

It would seem to be as appropriate for web products too. Of course, there are many other issues that affect user trust—jurisdiction being just one.

Can we trust self-labelling? Well for consumers, the Advertising Standards Authority's remit will include digital assets like web sites from 1st March 2011. Honesty plays a big part too, but consumer groups (e.g. the Confidence Code for energy comparison web sites) have some punch, and trade associations could develop standards for their members. Ultimately, the power of markets and groups of individuals would hopefully keep other organisations in check.