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

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

The report can be downloaded free of charge without registration.

I just came across KPMG's review of information leakage from corporate web sites, published in September.

Hopefully nothing new, but the report sums up the typical state of configuration of many web sites. Most web sites leak information publicly which is useful to an attacker to craft their subsequent search for vulnerabilities. KPMG simply reviewed the public-facing resources on 2,000 companies, from a wide range of sectors, in the Forbes 2,000 list to identify many missing security basics.

Publish and be Damned, Cyber Vulnerability Index 2012 is a quick read; what can you expect to discover?

• Large number of sensitive file locations and "hidden" functionality such as administrative interfaces (with banking the worst affected sector)
• Exposure of sensitive information in millions of online forum and newsgroup postings (with software & services the worst sector)
• Thousands of web servers with missing security patches or out-dated software (with Japan, Switzerland and Kazakhstan the worst countries, and Utilities the worst sector)

How well would your organisation do?

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!