Crime, SSL and Data Protection
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.
https - HTTP over Secure Sockets Layer (SSL), or correctly nowadays Transport Layer Security (TLS)
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.
Posted on: 12 April 2011 at 20:30 hrs
Comments are filtered automatically and should appear shortly after they been checked.
Because the details were going over the Internet in plain text, it lead to the risk that the highly personal and confidential information could have been captured over the Internet, over unencrypted and poorly encrypted wireless links leading to unknown risk to the person and alleged attacker.
CEOP put in SSL quite quickly thus resolving that security issue but then failed to close down another way of accessing the insecure reporting page which was the http address accessed either through typing the full url in or accessing the http page through the Search Engines. That security issue was notified to them and they then fixed that.
Another issue is around how CEOP failed to provide full, open and honest disclosure of the incident. In some sense, their lack of full disclosure has led to some of the questions in this article and noticably the final request for CEOP to `...Set the record straight'.
Instead the statements made by CEOP delberately attempted to;
a) downplay the severity of the security incident,
b) mislead regarding the full range of population that was impacted by the incident
c) mislead the public as to what the security incident actually was about i.e. they portrayed that it was only pages linked by Google etc that were affected when it was actually a reporting page on their website
d) mislead that the security vulnerability could only be exploited by determined and sophisticated hackers when in fact it is presumed that such data is compromised when not protected by SSL.
e) failed to advise the affected population regarding the mitigating factors that they could apply to reduce the risk of CEOP's failure to apply effective security.
Thank you for the additional insight and your views. I am always worried if any security controls (e.g. SSL) are put in "quite quickly". It's not simply a matter of throwing a switch - let's hope CEOP got it right, and that they have properly assessed and ranked all types of security and privacy risks, not just ones the public tell them about.