The Ponemon Institute has realeased its latest survey of UK data losses.

The findings of the 2009 Annual Study: Cost of a UK Data Breach indicate that personal data losses ("breaches") are still increasing in cost (per record). The report discusses the growth of data breaches due to malicious attacks and botnets, how prevalent these are compared with other losses and the relative costs. The report also presents comparitive data for losses involving third parties, and for organisations who have experienced their first data loss.

Although we hear a lot about lost or stolen devices (laptops, USB sticks, mobile phones, etc) and malicious/criminal attacks, the most common primary cause for the losses was negligence.

The recent news that the German government is considering buying stolen personal data of its citizens who it suspects of tax evasion is worrying. This sort of activity may fuel personal data theft by leavers and disgruntled employees.

The report is available in PDF format.

Strange as it might seem, some people publish, usually unwittingly, detailed information about the structure of their databases by revealing SQL (Structured Query Language) code.

I don't mean in error messages (which should of course never be displayed to web site users):

Nor in the generated web page source code (you wouldn't do that would you?):

Nor even when it's in a URL (I won't ask):

No, what I mean is when the code is simply indexed and appears on the site's own web pages (often as search result listings), and which then sometimes subsequently picked up by Google, Bing and so on:

So what's going on here? Without more information, I can only surmise, but I think these web sites are using catalogues (pre-built registers or collections) to index the web pages. However some of the pages have static content and others are dynamically built using database queries. So the indexing tool is recording the text from the scripting language rather than what is generated "at run time" to the web site user. These scripts should not be indexed, and thus leaked, in this way; instead the static results need to be merged and ranked with appropriate links to dynamically-created pages. If I search a dictionary web site for "query", I don't want a link to a page that has this in the code, I want the actual pages that define or reference the word "query".

The danger of automated indexing, is that it can include all types of unforeseen files in its catalogue, including backup and old copies of files, unless the indexing strategy is considered carefully:

Having the SQL displayed in this manner makes it much easier for someone to compromise the data, damage the site or its users.

Sometimes finding all the web applications in an organisation can be the difficult part in trying to assess what risks exist.

Transport for London don't just have web sites and, I suspect, an intranet. They have been gradually moving from whiteboards for live underground travel news at tube stations:

And now have electronic versions:

I don't know what technology is being used here, but other information boards have been seen to display web browser error messages leaking network information:

But, what about elsewhere? I saw this on the live electronic advertisement boards at Bond Street station this weekend:

Sorry it's a bit blurred, but I was going up the escalator at the time. Several, but not all the displays had their system names shown rather than an advertisement. It certainly looks like an IP address, but is there a web application inside? I've previously highlighted other information systems and displays that seem to be IP-enabled.

An investigation of your network, examining what is listening on which ports, and correlating this with the actual network traffic, might reveal more web applications than you thought.

This weekend the clocks change as we revert from British Summer Time (BST) to Greenwich Mean Time (GMT) at 02:00 BST on Sunday 25 October 2009 and the clocks go back, giving an extra hour.

What does this mean for web site security? Does running 01:00 to 02:00 twice matter? Well some brave web application owners will be disabling their systems like this online bank:

And, I don't think it's just being done as a finale to the current Energy Saving Week. Most people, quite rightly, won't be taking this rather severe step. Another millennium bug anyone? The date/time should be considered rather like other untrusted user input. Most problems will probably fall into the "business logic" category such as:

• Failure of time-based logic where dates are being compared.
• Assumptions of uniqueness in time-stamped output (e.g. by a single-threaded process).
• Running tasks again leading to possible:
  • loss of data due to overwriting
  • duplication of exports or emails
  • creation of inaccuracies in management information.
• Chronological ordering anomalies leading to other faults.

It's not just banks and other financial organisations that may have difficulties.

The time change may expose some other vulnerabilities that only exist at changeover time and/or during the next overlap hour.

• Circumvention of brute force attacks on user authentication mechanisms.
• Increased risk due to extension of a session's validity where local time is recorded.
• Failure in data validation routines for time-related comparisons.
• Incubated vulnerabilities where a time-related aspect causes the attack to be possible.
• Denial of service due to extension of account lock-out.
• Using time as a loop counter.
• Additional errors caused by any of the above leading to information leakage.

Recording the offset of local time to GMT/UTC and synchronisation should certainly be done, but may not resolve the time overlap issues. The effects on long-running "saga" requests might be especially difficult to determine. Time dependencies need to be specified and considered through the development lifecycle. Perhaps the bank is right after all?

A friend forwarded me a wine offer from his bank. But the email from his bank included additional information meant to verify the authenticity of the sender.

The bank included the last part of his postcode in the body of the message as well as his title and family name. If those were meant to be for verification purposes, why did it suggest he forward the email to someone else?

Yes, the forwarded email has all the verification details embedded in it. No, it's not the username and password, but it's everything someone would need to construct a phishing email that would be very hard to distinguish from a real one.

This has the feel of using a security measure as a marketing gimmick. Mixing marketing emails and those necessary for servicing a bank account is a difficult balance, but this is way off the mark.

Privacy Notices Codes of Practice is being launched today by Richard Thomas, the Information Commissioner.

Apart from the minor concern that Richard Thomas had included his signature in the document, the draft looked like it would be a very useful code of practice for most small-to-medium organisations including local government and professional organisations. One issue I raised at the time was the potential for aggregation of data to have more meaning than the individual parts, and that this should be considered in privacy notices so that users are aware of any potential problems. Some of the web form examples included didn't necessarily include other (non-privacy related) good practice such as for web accessibility and web usability. There was also some lack of clarity over the use of the word "security", e.g. "Security and Privacy Statement", which I hope has been corrected.

The explanation of fairness, and good and bad examples paper and web form layouts in the draft from the Information Commissioner's Office (ICO) were particularly helpful.

I'm looking forward to seeing the final version.

Update 10:30 hrs 12th June 2009: The ICO has published a press release and the final Privacy Notices Code of Practice.

Update 14:20 hrs 12th June 2009: The final version has incorporated over 60 suggestions as a result of the public consultation, including the issues of aggregation and use of the word "security". Watch out for legislation relating to Assessment Notices and dealing with failures to act on Assessment Notices.

The new British Standard 10012:2009, Data Protection - Specification for a Personal Information Management System, has been published.

British Standard 10012:2009 was the subject of an earlier draft for public comment (DPC) and I worked with the OWASP Industry Committee on a response.

BS 10012 is not an alternative to the excellent guidance for organisations now produced by the UK's Information Commissioner's Office, but instead is a specification for a personal information management system (PIMS). A PIMS is a governance process for all types of personal information within a company but could also be used for other types of sensitive data. BSI's slant on this is that a PIMS, and therefore BS 10012, could help maintain and improve compliance with the Data Protection Act (DPA) 1998.

A good start and one to watch.

The most successful phishing scams include the construction of a virtually identical website to the targeted organisation. Most of the content is usually cloned from the original legitimate website. A recent paper discusses measures that can be taken to help identify the source of the cloned content for fraud investigations.

Companies with well-known brands have always had to battle to maintain their trademarks and brands in the physical world. Here's a takeaway shop using the London Underground logo:

But what about the online world? How do you identify the person who stole your assets including designs and content? Farmers have been long-term users of tagging and tattooing to track animal movements, record health information or even to help find the mother for a lost lamb at this time of the year.

There are even proposals to use electronic ID tags for sheep. But web application content can't be tagged physically in the same way.

Gunter Ollman's paper Anti-Fraud Image Solutions reviews the subject, outlines and compares the techniques and limitations of adding traceable markers to web application content. These include steganography, watermarking, image meta data, mosaic layouts, semagrams, file names and hidden graphics. If you are lucky, the marker will be identifiable in the cloned phishing site, giving information on the possible source.

Gunter reminds us that no technique is infallible and the identification of the source of the cloned site by no means indicates the true perpetrator.

This type of tracing may also be useful for marking non-production, archived or backup web application source code and media, to assist with leak source identification. In this scenario, the thief (or accident-prone employee) does not necessarily have the goal of reproducing the original website and therefore the perpetrators may not be looking for hidden tracers to remove.

This week a friend contacted me about his business website. It seemed his company had paid for both a .co.uk and .com domain name, but the latter was not currently mapped to her site.

It seems the web developer wasn't being co-operative and she was asking for some advice. It appeared that neither domain were registered in my friend's company's name—both named the developers. This makes things much more difficult if the developers are slow to respond to change requests, or fail to renew your domains, or you fall out with them or they go out of business.

But I came across another example on Wednesday. I had to drive through London and later in the day I went to pay the £8.00 charge using the congestion charge online payment service from Transport for London.

I looked at the SSL certificate's details and was very surprised to see the organisation named on the certificate (known as the distinguished name field for organization) was not "Transport for London" but "Cobweb Solutions Ltd", presumably this company.

Whilst this may not be contrary to the SSL Protocol Specification, it is contrary to expectations and good practice. If this were a retail website (where you choose to buy rather than being obligated to pay!), would a cautious potential customer trust the site? The information has also given away vital clues to a malicious user on the software development company and thus perhaps possible approaches to breach the system. Cobweb Solutions' own site has a shopping basket/e-commerce system that has a similarly attributed secure certificate:

Like domain names, your own website SSL certificates, regardless of SSL certificate type should be in your own organisation's name, not anyone else's. In fact this also usually makes the proces of purchasing a certificate simpler.

On my friend's domain name issue, she has contacted the relevant domain name registrars using their disputes process to ask for the details to be updated. She is also checking whose name is on the web hosting contract.

The first stage of attack is reconnaissance. Therefore don't give the enemy information they shouldn't have.

I photographed this public information screen at the weekend. It looks like it's part-way through being commissioned, but it was displaying important network information.

In this case I suspect the information isn't particularly helpful to someone who wants to display their own messages instead of the official ones, but it is leaking information about how the system works. This particular installation probably isn't part of the critical national infrastructure, but is any more case being taken there?

Web sites often give away too much information in their error messages, filenames, source code, headers and cookies. This information can be used to help compromise the site.