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.

In How Much Logging, Monitoring and Alerting? I suggested logging implementations are often incorrect for most web sites and web applications.

The logging should be defined in terms of its intended use. We're talking here specifically about information security, so what might the uses and logging be?

1. To confirm data and process integrity and availability:
   • completeness and consistency
   • response times
   • function/process abandonment
   • session timeout
   • up-time
   • data changes
   • data mirroring, back-ups and archiving
2. To identify and provide enough information for investigation of:
   • errors and unexpected conditions
     • code errors
     • database access and performance
     • web server errors
     • third party services
     • lack of storage space
   • data breaches
   • use and mis-use
     • authentication successes and failures
     • access (authorisation) failures
     • excessive use
     • data validation failures
     • fraud and other criminal activities
     • suspicious, unacceptable or unexpected behaviour
   • modifications to configuration
   • security reports from users and third parties
3. To provide data:
   • subject access requests
   • freedom of information requests
   • litigation document requests
   • police and other regulatory investigations
4. To monitor content changes:
   • database fields
   • file contents
   • generated web page content
5. To demonstrate compliance:
   • internal policies and standards (e.g. information security policy, quality standards)
   • contractual obligations (e.g. PCI DSS)
   • change control
   • use of other's intellectual property
   • legislation (e.g. Data Protection Act)
   • regulation (e.g. Financial Services Authority)
   • external standards (e.g. Web Content Accessibility Guidelines [WCAG] 2.0 conformance claim)

It's important the logging is centralised so that alerts and reporting can be drawn from across all sources (web, application, file and database servers, network devices, etc). The scope and extent of logging ought to be be determined by business needs and the threats. For a typical e-retail site, the payment, check-out and any registration facilities will require greater logging than other parts. In some cases it may be appropriate to set particular thresholds for additional logging (e.g. transactions above a certain value, requests from particular clients, users in some geographic locations). This is easier if the requirements can be built into projects at an early stage.

The logging then needs to be tied in with appropriate monitoring, alerting and reporting. If you want alerts raised automatically, you'll have to think of what conditions initiate these. Referring back to specifications, threat models and test cases can be of use with this.

If you don't have to collect sensitive data, it saves you having to justify it, keep it securely, monitor access to the data and ensure it is destroyed completely at the end of its retention period. I came across this example from The Nuffield Trust.

Minimising the collection and retention of sensitive data is highlighted as a protection measure in the report for the Information Commissioner's Office Privacy by Design and the recent US National Institute of Standards and Technology (NIST) draft Special Publication 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) - see also my previous post Protection of Personally Identifiable Information.

The links to download publications from The Nuffield Trust give a web page with a hyperlink to download the Adobe Portable Document Format (PDF) version anonymously, as well as the option to register with an explanation why The Nuffield Trust thinks it would be useful to do this.

Why do so many other organisations make registration mandatory for access to resources, often available free-of-charge elsewhere? See also Too Little and Too Much Authentication.

In a post this week by Jared Spool, he describes The $300 Million Button about a web site where removing the registration step at check-out increased sales by 45%. And, they didn't have all that sensitive data to look after. Interestingly he also notes that almost half the previous customer accounts were duplicates.

Just a note, the forms to log in, register and recover the password on this example page—and the actions of these—should be undertaken over an encrypted connection (i.e. SSL/TLS) to protect the data in transit; so, the trust's page is an example of both good practice and bad practice.

Sometimes information leaks from web applications due to the presence of old, or superceded, functionality.

Here's a software, but non-web, related example I saw last week. Seat reservations on National Express East Coast trains are printed from their reservation system and include the seat position and part of the route reserved. Reservation slips are attached to the seats like the one shown below:

But one nearby seat on the same train had some additional information displayed - possibly the passenger's family name?

The seat was actually empty for the journey so we'll never know if this was really a passenger's name. In this example it's not a problem of course, but it might indicate that there is a field in the data entry system that can be used to store additional details. And, here it is being printed on the reservation slip.

Perhaps names used to be included and the field remains, but shouldn't be completed nowadays. Luckily the booking agent didn't write something like 'awkward customer' or '2 cards bounced' here. That would have been a problem.

So back to web applications... the above scenario could apply to an administrative data entry form in a content management system or e-commerce management system. The reason and use of 'old' fields may be forgotten over time as staff change - but mean that information is published in unsuspecting ways.

Maintaining a schedule of how all data input values relate to outputs is time-consuming, but potentially important. Thorough testing can help where it's not possible to build and maintain such a schedule.

This week one of my friends is staying with me. She attended the launch of a new interior design web site yesterday and asked some pertinent questions during the demonstration.

During the walkthrough of the shopping cart and checkout, real credit card data belonging to the demonstrator's assistant were entered on the projection screen in front of a large audience including journalists. My friend pointed this out, but too late - they had to continue. Demos should always try to use appropriate test data whenever possible - in this case it's likely the site, or a copy in a test environment, could have been set up to use test card data - so-called "magic numbers" - with a test merchant account provided by the payment gateway provider.

The web site can act as a store front for individual designers, such as my friend, and she asked where the customers were opting in for the use of their personal data, and who had access to it - the site operator or the end supplier (designer). This seems a very valid question. Apparently that hadn't been looked at yet.

Even the "best" projects seem to have a lack of data protection forethought. In this case, it clearly wasn't a problem with the budget, but the planning and system design.

Functions to unsubscribe, be removed, cancel or opt out from newsletters, mailings and email alerts can be used to undermine web site security.

Many techniques are used to unsubscribe including:

• Email message to a particular address, possibly with a keyword like "unsubscribe" in the subject or body
• One click opt out unsubscribe hyperlinks
• Hyperlink to a form with additional validation
• Log into an account management area to make a change to communication preferences
• Pre-paid response postcard
• Telephone call to a helpdesk.

Some examples from email alerts are shown below:

It is important to make it simple for people to opt-out of such services, but there are a number of problems that can get built into such systems:

• Hyperlinks that only pass an email address as a parameter can be used to find whether particular addresses (such as known individuals) are registered/subscribers - this could be used for user name enumeration if there is a separate log in area and the user names are email addresses
• Hyperlinks with only predictable identifiers can be guessed
• Systems could be used maliciously to unsubscribe other people's accounts
• Hyperlink options could automatically log people in to their accounts - this should not occur since the links could be accidentally forwarded on to other people
• Any validation (authentication) systems must be at least as secure as other functions such as log in to access account details, so that the unsubscribe facility cannot be used to obtain log in credentials (e.g. limit the number of attempts possible, log failed attempts, lock accounts, add delays to failed attempts, etc)
• Unsubscribe by hyperlink or email must have the same level of checks (not more or less) as non-electronic means (telephone call, written, etc) otherwise the weakest method could be used by a malicious person
• Text-only versions either not including or not rendering the unsubscribe hyperlinks correctly (e.g. wrapping the link), so that only rich-text email users can see and use the links
• Anything sent by email is normally not considered secure
• Do not give away any other sensitive information on either successful, or unsuccessful completion (e.g. "Thank you Margot Dyson, we will send a letter to your address in Hastings to confirm this request")
• Clearly distinguish between opting out of particular correspondence, types of contact (e.g. direct marketing), all correspondence and closing accounts altogether - you may have to contact the person for some other valid reason.

In all cases, the completion of unsubscribing should be accompanied by a message to the person informing them of the change of status (by email or some other method). Where this hasn't closed their account, and they can log on to undertake other processes, the event should also be recorded for them to see in a list of recent actions.

In my post earlier this week on Server Login Protection, I mentioned how file transfer protocol (FTP) is commonly used, and should not be. A data breach this week hints that FTP was the method of access that lead to the data theft.

The Breach blog reported a breach involving Gloria Jean's Coffees' e-commerce site. Their privacy and security statement aludes to higher standards:

The notification letter to the New Hampshire Department of Justice in the United States (US) says the company:

But the strange thing is that it is an e-commerce site and that some of the data stolen was credit card information - card number, name, address and card verification value (CVV), also known as the card security code (CSC) - obtained by modification of the application scripts on the web server. In other words, inbetween the encrypted transfer (using SSL) to the web server and before sending this by an encrypted method to the payment gateway.

Enforcement of the Payment Card Industry (PCI) Data Security Standard (DSS) is much further advanced in the US. So either the site wasn't compliant in which case large fines are winging their way towards Gloria Jean's Coffees Corp, or the auditors may have missed something important here.

See also the related Keeping Up-to-Date with Security Breaches.