Yes, had you forgotten it's Data Privacy Day tomorrow? See StaySafeOnline for events in the US and Canada. Not sure why it's a Saturday — maybe to give the weekend journalists a story they can prepare in advance, and then take the day off.

While there is a programme of events, data protection has been in the news this week following the publication on Wednesday of the European Union's proposed reform of data protection legislation, promoted under the banner of aiming:

There has been extensive documentation and justifications published to accompany the draft directive. There is of course plenty of coverage elsewhere, and I would recommend reading the following:

• Initial response from the ICO on the European Commission's proposal for a new general Data Protection Regulation, UK Information Commissioner's Office
• EDPS welcomes a "huge step forward for data protection in Europe", but regrets inadequate rules for the police and justice area European Data Protection Supervisor
• Pan-EU consistency in data protection reform welcome, but burden on business a problem, says expert, Out-Law.com

So, what does it mean? For now, these are just proposals, and what will eventually be made into law will be something very different. But it does indicate the way things are going, and is a reminder to website and application owners & developers of the need to take privacy considerations into their projects now, since the cost of changes later may be prohibitive. And, they should be doing this already, but there may be more obligations for those processing personal data in the future. There is potentially more complex functionality required for tracking consent, achieving data portability, handling withdrawal of consent and undertaking data removal.

And, there is the topic of mandatory notification of "serious" breaches.

Data Privacy Day might be a day of reading after all.

The proposed new European Data Protection Directive will be announced tomorrow.

Apart from the leaked draft document, there has been plenty of comment (e.g. here, here and here), Viviane Reding, Vice-President of the European Commission, has also been speaking up.

Meanwhile IAB Europe has been busy behind the scenes discussing online behavioural advertising (OBA) and IAB USA has been blogging about its self-regulatory programme. Lots happening then with privacy, advertising and online marketing.

We will find out tomorrow if the leaked document was representative of the final proposals.

A blog pots today by David Lacey reminds us that ecommerce is not just about online shopping and celebrity buzz.

In No Fix in Sight for SCADA Security, he discusses the cyber threats to critical infrastructure, referencing recent comments made by Shell. Is more red tape the answer? Possibly, but it has to be the right red tape.

Why government intervention? This blog post discusses the economics of cybersecurity and why intervention by government sometimes might help.

The UK's data protection agency Information Commissioner's Office (ICO) has updated the previous guidance on the use of cookies and similar tracking technologies, under the revised Privacy and Electronic Communications Regulations which came into force on 26th May this year.

In a press release today, organisations were warned they are not doing enough during the lead-in period to formal enforcement.

The updated Guidance on the Rules on use of Cookies and Similar Technologies provides concrete advice and practical guidance on the legal requirements, their interpretation and what are considered acceptable practices. The guidance was issued as a result of a review of progress to date which shows a lack of knowledge and action from web site owners. Of most concern are likely to be persistent cookies, cookies issued by third parties, cookies issued immediately a user visits a web site, are used for any sort of profiling or which span multiple website hostnames or multiple domains.

If you have any analytics, advertising, tracking or content provision by third party web sites, beware — you may just find the terms and conditions of service state you are responsible for obtaining and managing consent.

If you are a web site owner, take note and act now, if you have not already done so. From May 2012, the ICO will be accepting complaints from users, and will then contact web site owners to ask them to respond to the complaint and explain what steps they have taken to comply with the regulations. Therefore, document what you are doing and the decisions taken.

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

Further to the recent guidance and announcement of enforcement plans, the first demonstration of what this might entail for web sites which undertake user-tracking or store user data, has been revealed.

The UK Information Commissioner's Office (ICO) utilises up to six cookies on the ICO web site (four relating to Google Analytics). Alexis Fitzgerald discusses the implementation in his Web Application Security - From The Start blog. There is no cookie to say you have opted out of accepting cookies — which is good — but for now the site does leave that rather annoying message at the top of every page which persists in the print version too. Giving consent also sets a cookie "ICOCookiesAccepted".

I see the ICO has stated the session identifier "ASP.NET_SessionId" is an "essential site cookie". It is set by default as soon as you visit the site, and thus presumably is exempt from the regulations for consent due to being "strictly necessary for the provision of an information society service". Take note.

Well, many web sites manage not to use session identifiers except in a subset of the site, such as for authentication and authorisation checks in areas limited to certain users. I wonder whether there really is any functionality on the ICO web site which really requires this session cookie to work?

Putting that aside, the cookie is "session-only" and should be destroyed when the browser is closed. But some web browsers are not routinely closed, and this would leave evidence that the site had been visited. In the case of the ICO web site, it would almost always be an insignificant matter, but there could be situations when even accessing the this might be deemed unacceptable or suspicious, leading to some sort of potential harm to an individual. Other web sites are likely to copy the ICO approach, so it is interesting the ICO has not removed the need for a session identifier cookie for general site browsing.

My baseline tips for cookies used for session management would be:

• Have only one session management cookie if possible
• Ensure session management cookie(s) expire automatically
• Destroy sessions server-side once they have expired, or when their use is no longer required, and after a fixed time period
• Do not store any personal data or business data in the cookie value — just store a long highly-random, difficult to predict identifier which has some meaning server-side
• Restrict session cookie scope to the site's particular domain and URL path
• Set the HTTPOnly, and if SSL is used SSLOnly, cookie attribute
• And preferably, limit where session identifiers are required (i.e. not the whole site)

These are just a starting point. If the session management cookie is part of authentication processes, there are further recommendations for implementation.

No doubt, additional advice on the new cookie regulations and standard practices will be forthcoming in due course. Of course, the ICO could have removed client-side web analytics completely, reducing the number of cookies to one (and this may not really be required either).

As mentioned previously, the new UK regulations on cookies, etc came into force today, 26th May 2011.

The Information Commissioners Office (ICO) announced yesterday that web site owners will have up to a year to comply with the law. The ICO also published guidance on its approach to enforcing the new rules and other powers as part of the revised the Privacy and Electronic Communications Regulations (PECR), which are subject to its own Data Protection Regulatory Action Policy.

A US survey of has found that 88% of companies spend more money on coffee than on web application security. We (in the UK) seem to legislate more on fruit juice than either coffee or web application security.

Whilst it was encouraging to read the section on security in the ICO's new Data Sharing Code of Practice, we do seem to have rather more detailed legislation on things like fruit juice than information security. The Fruit Juices and Fruit Nectars (England) (Amendment) Regulations 2011, which were laid before Parliament in April and come into force on Monday, define the minimum Brix levels (sugar content) for fruit juices from concentrate. Wouldn't it be great to see some similar highly specific legislation on securing online applications (and labelling) like this across Europe?

But, back to the coffee... Cenzic have issued their Web Application Security Trends Report Q3-Q4, 2010 which provides an analysis of reported vulnerabilities and breaches attributable to web applications. Its results confirm other recent reports that cross site scripting and SQL injection continue to dominate, despite these issues having being know about for a long time, and there being readily available methods to solve them.

But Cenzic and Barracuda Networks also commissioned the Ponemon Institute to survey 600 IT and IT Security professionals in the United States. The report's findings showed that most companies are spending more on coffee than keeping their web sites secure.

I'm sure the findings for tea in the United Kingdom would be similar. After all, there is a British Standard about how to make tea (BS 6008:1980/ISO 3103:1980). I can't find the application security standard from BSI (...just yet).

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.