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?

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...

I had the chance to read a recent paper on the privacy risks of collaborative filtering. These are the types of systems which provide recommendations and suggestions based on other users' activity, such as products bought or looked at.

The paper "You Might Also Like:" Privacy Risks of Collaborative Filtering by Joseph A. Calandrino, Ann Kilzer, Arvind Narayanan, Edward W. Felten and Vitaly Shmatikov is summarised on Joseph Calandrino's blog, but describes inference of individual transactions from the outputs of collaborative filtering systems, thus revealing information without a user's knowledge or consent.

The approach described in the paper does not require the creation of fake user accounts or enter purchases or ratings into the target systems, and it does not assume the target user's transactions are available in either an identifiable or anonymised form. Instead the algorithm monitors changes to the recommender systems over a period of time, which when combined with auxilliary information, can be used to infer some of the target user's previous transactions i.e. not to predict future events but to infer past events.

There is some fairly serious mathematics in the paper, but don't let that put you off reading the rest of the paper.

I wonder if this approach could be used to infer answers in personal knowledge question based password recovery functions?

Whilst on the theme of the privacy protection, this afternoon I attended the launch of the Information Commissioner's Office (ICO) Data Sharing Code of Practice, at the House of Commons.

If you remember there was a public consultation at the end of 2010, and the final document is now complete. I contributed to my company's written response, as well as to a response by OWASP on the security aspects of data sharing.

The event was sponsored by John Leech MP, Alun Michael MP and Dominic Raab MP, and the new code of practice was introduced eloquently by the Information Commissioner, Christopher Graham. He made the important point that the ICO is about enabling safe use of personal data, and that blocking the use of personal data is not its role. In fact, consumers and citizens can benefit from transfers and sharing of their data — it just has to be done legally. He described the guidance as "making sense on paper, and in the real world".

Note this is statutory guidance which has therefore been approved by the Secretary of State and laid before Parliament. It does not impose new legal obligations nor is an authoritative statement of the law. But both courts and the Information Commissioner must take into account the contents of the code when determining any question arising from proceedings, or functions being performed by the ICO under the Data Protection Act (DPA).

It applies to all sectors — public and private — although there is some sector-specific guidance included. Importantly it applies to both routine systematic data sharing as well as one-off data sharing tasks. The guidance notes data protection principles also apply to the sharing of information within an organisation, such as between divisions, departments and teams. Examples and case studies used in the document include "a retailer providing customer details to a payment processing company", "a mobile phone company intends to share details of customer accounts with a credit reference agency" and "a marketing company wants to share data with a fulfilment company so it can send out free samples". Practical, yes.

I was interested to read the new document to see what changes had been made in the period since the consultation. The draft document was quite good, but the final guidance is an order of magnitude better. It looks as though considerable re-writing, greater explanation, and addition of a glossary and quick-reference checklist have improved its content and usability. Additionally, I am pleased to see many more practical private-sector examples have been included throughout the main body, and in the case studies in Annex 3.

In terms of information security, the primary aspects are detailed in Section 7, which lists good practice to take in respect of information shared with other organisations, highlights the need for building a security-aware culture, identifies the need to take reasonable steps to ensure the receiving organisation understands the nature and sensitivity of the information, the need to consider all modes of transmission, and provides two short lists of physical and technical security measures to be considered. One which stands out in particular is:

Well, that's quite specific! And, good advice.

So, data controllers take note. If you are involved with specifying or designing online (or other) business systems, read the whole document — it really will help. The code of practice does not itself have the force of law (the DPA does), but it describes good practice, and the ICO can only take enforcement over breaches of the DPA. But as the guidance says doing nothing, risks breaking the law.

The whole structure of the document is:

1. Information Commissioner's Foreward
2. About this code
3. What do we mean by "data sharing"?
4. Data sharing and the law
5. Deciding to share personal data
6. Fairness and transparency
7. Security
8. Governance
9. Individual's rights
10. Things to avoid
11. The ICO's powers and penalties
12. Notification
13. Freedom of Information
14. Data sharing agreements
15. Data sharing checklists

The annexes are:

1. The Data Protection principles
2. Glossary
3. Case studies

Coincidentally today a potential £200,000 penalty was imposed by the ICO for a recent web site personal data loss, and the full amount was only avoided because the sole trader had already ceased trading.

The code of practice has not yet been published on the ICO web site. I will check again tomorrow morning.

Update 11th May 2011: The ICO has now announced and published the Data Sharing Code of Practice and checklists on their web site.

Whilst on the subject of new information security reports from WhiteHat Security and Veracode, here is another one to add to your reading material.

The 2011 Data Breach Investigations Report examines data from data breach investigations for Verizon's customers. So, a lot wider than application security, but useful reading.

The information about how long it takes from point-of-entry to compromise, and compromise to discovery are interesting. Especially when the vast majority of data breaches are apparently discovered by third parties — not the target of the attack themselves.

Will that be you?

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.

The costs and benefits of investing in information security seem to be a popular topic.

In January, I mentioned two new reports on the benefits of building in application security — Secure Application Development - A Preventative Approach That Pays and Secure SDL Positive ROI Possible. Another report by the Ponemon Institute looks at the cost of compliance with information privacy-related legislation, regulation and policies, and the cost of non-compliance.

The True Cost of Compliance is the result of a survey of 45 US organisations from a range of sectors. While perhaps less relevant to readers of this blog, it's worth a glance. The results of the survey, and similar ones, need to be taken in the context of the warning on page 27:

Although it's good to have access to data like this, the numbers presented seem to have rather over-optimistic precision. Generally though, the findings might be what you would guess (read the report!).

See also the related Ponemon 2011 update on cost of a data breach.

The European Network and Information Security Agency (ENISA) has published a report on "Data Breach Notifications in the EU" to support the introduction of mandatory personal data breach notification following the EU Telecommunications Regulation Reform Package in 2009. That legislation requires the new rules to be transposed into the national laws of the 27 member states by May 2011.

The report will not only be useful to public authorities such as data protection agencies (DPAs), but also for those in the electronic communication sector directly affected by the legislation — communications providers including telecoms companies and internet service providers (ISPs). It will also be of use to any organisation developing policies and processes in the area of internal or external notification, regardless of whether r not there is a legal requirement.

The report is largely based on the results of a survey of 46 organisations conducted using interviews and questionnaires. The organisations primarily included DPAs, telecommunications operators and some other private sector organisations located in Europe. There is a good description of the legislative background including examples of existing local requirements/guidance in Germany, Ireland, Spain and the United Kingdom. In the UK, there is currently no legal duty to notify breaches (see ICO guidelines), but other mandates such as contracts, policies or requirements of trade organisations might dictate otherwise. There is a also a summary of working definitions and criteria for personal data, data subjects and data breaches across Europe, which is not as homogenous as you might hope.

The chapter about the private sector provides a good insight into operators' existing notification practices and incident handling procedures. It also examines the divergent objectives between regulatory authorities and the private sector. Remember that "breaches" are not only incidents relating to data loss. All aspects of privacy legislative contraventions need to be considered.

The ENISA report concludes with a list of aspects requiring further definition to simplify the transition to mandatory notification, and to ensure better harmonisation across the member states. Time may be against all these occurring before May 2011.

Other sectors - keep watching!

Sometimes when I'm out socially and people ask what I do, the conversation progresses to concerns about their own web site. They may have a hobby site, run a micro-business or be a manager or director of a small and medium-sized enterprise (SME)—there's all sorts of great entrepreneurial activity going on.

It is very common for SMEs not to have much time or budget for information security, and the available information can be poor or inappropriate (ISSA-UK, under the guidance of their Director of Research David Lacey, is trying to improve this). But what can SMEs do about their web presence—and it is very unusual not to have a web site, whatever the size of business.

Last week I was asked "Is using <company> okay for taking online payments?" and then "what else should I be doing?". Remember we are discussing protection of the SME's own web site, not protecting its employees from using other sites. If I had no information about the business or any existing web security issues, this is what I recommend checking and doing before anything else:

• Obtain regular backup copies of all data that changes (e.g. databases, logs, uploaded files) and store these securely somewhere other than the host servers. This may typically be daily, but the frequency should be selected based on how often data changes and how much data the SME might be prepared to lose in the event of total server failure.
  • check backup data can read and restored periodically
  • don't forget to securely delete data from old backups when they are no longer required
• Use a network firewall in front of the web site to limit public (unauthenticated user) access to those ports necessary to access the web site. If other services are required remotely, use the firewall to limit from where (e.g. IP addresses) these can be used.
  • keep a record of the firewall configuration up-to-date
  • limit who can make changes to the firewall
• Ensure the host servers are fully patched (e.g. operating system, services, applications and supporting code), check all providers for software updates regularly and allow time for installing these.
  • remove or disable all unnecessary services and other software
  • delete old, unused and backup files from the host servers
• Identify all accounts (log in credentials) that provide server access (not just normal web page access), such as used for transferring files, accessing administrative interfaces (e.g. CMS admin, database and server management/configuration control panels) and using remote desktop. Change the passwords. Keep a record of who has access and remove accounts that are no longer required and enable logging for all access using these accounts.
  • restrict what each account can do as much as possible
  • add restrictions to the use of these accounts (e.g. limit access by IP address, require written approval for use, keep account disabled by default)
• Check that every agreement with third parties that are required to operate the web site are in the organisation's own name. These may include the registration of domain names, SSL certificates, hosting contracts, monitoring services, data feeds, affiliate marketing agreements and service providers such as for address look-up, credit checks and making online payments.
  • ensure the third parties have the organisation's official contact details, and not those of an employee or of the site's developers
  • make note of any renewal dates
• Obtain a copy of everything required for the web site including scripts, static files, configuration settings, source code, account details and encryption keys. Keep this updated with changes as they are made.
  • verify who legally owns the source code, designs, database, photographs, etc.
  • check what other licences affect the web site (e.g. use of open source and proprietary software libraries, database use limitations).

Do what you can, when you can. Once those are done, then:

• Verify the web site and all its components (e.g. web widgets and other third party code/content) does not include common web application vulnerabilities that can be exploited by attackers (e.g. SQL injection, cross-site scripting).
  • use resources such as the OWASP Top Ten and WASC Threat Classification
  • build security requirements into future developments
• Check what obligations the organisation is under to protect business and other people's data such as the Data Protection Act, guidance from regulators, trade organisation rules, agreements with customers and other contracts (e.g. PCI DSS via the acquiring bank).
  • impose security standards and obligations on suppliers and partner organisations
  • keep an eye open for changes to business processes that affect data
• Document (even just some short notes) the steps to rebuild the web site somewhere else, and to transfer all the data and business processes to the new site.
  • include configuration details and information about third-party services required
  • think about what else will need to be done if the web site is unavailable (does it matter, if so what exactly is important?)
• Provide information to the web site's users how to help protect themselves and their data.
  • point them to relevant help such as from GetSafeOnline, CardWatch and Think U Know
  • provide easy methods for them to contact the organisation if they think there is a security or privacy problem
• Monitor web site usage behaviour (e.g. click-through rate, session duration, shopping cart abandonment rate, conversion rate), performance (e.g. uptime, response times) and reputation (e.g. malware, phishing, suspicious applications, malicious links) to gather trend data and identify unusual activity.
  • web server logs are a start, but customised logging is better
  • use reputable online tools (some of which are free) to help.

That's just the basics. So, what would be next for an SME? If the web site is a significant sales/engagement channel, the organisation has multiple web sites, is in a more regulated sector or one that is targetted particularly by criminals (e.g. gaming, betting and financial), takes payments or does other electronic commerce, allows users to add their own content or processes data for someone else, the above is just the start. Those SMEs probably need to be more proactive.

This helps to protect the SME's business information, but also helps to protect the web site users and their information. After all, the users are existing and potential customers, clients and citizens.

Oh, the best response I had to someone when I was explaining my work: "You're an anti-hacker than?". Well, I suppose so, but it's not quite how I'd describe it.

Any comments or suggestions?

Like many other document and files on your web site, PDFs can leak information in more than one way. Apart from the normal content, there is often meta data, information from previous versions and sometimes, links to internal resources.

On Wednesday, the Financial Services Authority (FSA) reported they had acquired a list of 38,000 names, addresses and telephone number that boiler rooms were using to target potential investors in worthless shares. The FSA wrote a letter to all the people listed. They also published the letter's outline format as a PDF. Unfortunately four enabled hyperlinks in the document do not reference the www.fsa.gov.uk website as intended, but instead a file on someone's computer, probably at the FSA.

Oh dear. Nothing too serious this time, but everything that is published should be checked for validity before release, and verified after publication. This should include all information, not just the normal visual content. The FSA should know better. Publishing to print (e.g. the letters) removes some of this additional information where publishing to an electronic format (e.g. PDF) doesn't always. All publishing should follow standard procedures and approvals processes should include checks for additional information.

Embedded data may leak business information (e.g. previous changes, authors' comments, file paths, account names, intellectual property) or personal data (e.g. location data, names), and possibly give malicious users information that will help them exploit the organisation's systems.

Also, some good news for the FSA, it has survived the change of government.