E-consultancy.com Limited has completed their site migration to a new domain, a new platform and a new country.

In September I posted a message about moving web hosting offshore in response to the impending E-consultancy site migration.

Well the move has happened and the new domain is econsultancy.com —the "www" sub-domain and previous hyphenated "e-consultancy.com" domain redirect to the new site. I may have missed something, but as a member and contributor who agreed to the previous terms & conditions, I was expecting hear something before the move occurred.

Some users are required to agree to the new longer terms and conditions before proceeding, yet this seemed to be bypassable in some cases. I didn't have time to investigate the mechanism but noticed I wasn't asked with some browsers/computers and was on others.

There's no mention of data protection or privacy issues in the chief executive officer's blog posting about the new Econsultancy site despite all the previous discussion. I'm a little but disappointed to be honest since the web site is such a good resource for ecommerce (or e-commerce) and digital marketing professionals. The CEO does however tell us some of the technologies used—an un-necessary security information leak.

There has clearly been a lot of effort put in, and that's to be congratulated. But the privacy statement has these few words about security:

It looks like a mixture of boilerplate text and some additions. But the description and explanation why some security controls were omitted doesn't reflect good practice and is entirely insufficient for a £300,000 revamp of an ecommerce-enabled web site. Let's hope they have some sort of firewall in there somewhere!

I'm left with the feeling that perhaps security wasn't considered much during the re-development process. A missed opportunity.

Recent proposals from the Ministry of Justice in the government's response to the Data Sharing Review suggest the Information Commissioner will receive greater powers and charge more for data protection registration.

As a result of a consultation, the Ministry of Justice has proposed tougher powers for the Information Commissioner including:

• monetary penalties for deliberate or reckless loss of data
• after a warrant has been served, require the provision of information required to determine compliance with the Data Protection Act
• impose a deadline and location for the provision of information necessary to assess compliance.

The ability to determine Data Protection Act compliance could be difficult for many web enabled processes if there are insufficient controls, monitoring and reporting. I've already found the potential compliance issue is a consideration now for current and new web project specifications.

It is also suggested that the current flat rate notification fee is replaced by tiered a fee structure based on size of organisation (similar to the bands defined in the European Union's Recommendation 2003/361/EC regarding the SME definition) so that businesses with more than 250 employees or with a turnover greater than about £26 million will receive the highest charges.

You can read the full proposals in the response document The Information Commissioner's Inspection Powers and Funding Arrangements under the Data Protection Act 1998 and related press release.

The inclusion of other people's code in your own web pages increases the potential number of vulnerabilities and it can have an effect on compliance.

Seemingly harmless code from third party sites is often included to provide:

• advertisements (e.g. Google AdSense, DoubleClick, Amazon Associates)
• widgets (e.g. bookmarking and social networking tools)
• web analytics (e.g. Google Analytics, Omniture, Hitbox).

But these normally come with their own terms of service. Like any other component of your site you need to ensure your own privacy policy and, if there is personally identifiable information, your data protection act registration include the purposes (collection, use, retention, transfer) that the third party code requires.

Then the terms of service need to be actively monitored, since they can change unannounced. A recent example of this was the purchase of AddThis, a popular bookmarking widget provider, by Clearspring Technologies Inc at the end of September 2008.

The AddThis terms of service were updated and their widget code changed to include tracking cookies. This meant the widget created cookies on the host web site's domain, as if the host had set them themselves. This is because the widget's code is running in the context of the hosted page. See John Haller's write up for further information. Here's one snippet from the new terms of service:

If you have AddThis on your web site, are your users aware of these terms? A more common issue for web site owners than widgets is the use of web analytics services that have client-side code - typically JavaScript - embedded on each page.

Try to keep third party hosted code off your site, and certainly never have it in more sensitive areas such as registration, log in, password recovery, payments and restricted-access pages. If possible use server-side web analytics rather than adding client-side code.

"Privacy by Design" is the latest must-read document produced by the Information Commissioner's Office.

After a brief consultation period, the Information Commissioner's Office (ICO) has published its report on Privacy by Design to address the general lack of data protection and privacy safeguards. The report was prepared by Enterprise Privacy Group on behalf of the ICO and examines why good privacy practices are not being applied, what can be done to remove these barriers and how to build good privacy principles into all stages of the information systems development and data management life cycles.

Although the concepts relate to an organisation-wide approach for public or private bodies, everything is relevant to the development of an individual web application. Like any form of security the report recommends that measures - privacy enhancing technologies (PETs) - are built in from an early stage and not added on as an after thought. The report also advocates the use of privacy impact assessments (PIAs) and designing privacy protection into the business case for projects - all good stuff.

Update later on 28th November 2008: Bob Lewis has published an article today in Computer Weekly on how to respond to a data security breach and thus protect the people whose data has been lost and, where possible, the organisation's reputation and data. The useful suggestions should be tailored to your own organisation's requirements. For a web site or web application it may be difficult to identify when a breach has occurred and what data has been lost - this is where logging and monitoring can be of assistance. But remember, if you don't collect the data in the first place it can't be misplaced.

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.

Creation of representative data sets is very difficult and time consuming. Therefore, developers and testers often want live data from your web application to work with. This needs to be complete, current and representative. Make sure this is controlled - live data should never be used in development or testing. Live data are also sometimes requested for "running reports offline" - this can be just as risky and illegal.

For example, I've seen a developer testing their work on an email broadcast module send thousands of test messages to real customers of their client because they were working with an exact copy of the live data.

Live data may contain personally identifiable information, authentication credentials or other sensitive information such as contract values or intellectual property. Three methods that can be of help are:

• Extracting a subset - to limit the number of records
• Anonymise records - to remove personally identifiable information
• Masking - to hide sensitive information

On smaller, less complex, systems where the file & database structure and data content are well understood, this could be undertaken manually, or more likely with some pre-prepared scripts. If possible, these should be done on the devices hosting the existing data, so as not to have to manage the transfer of such data elsewhere first. The extract could be exported, treated and then removed from the server over a secure transmission protocol, to a possibly less-secure destination.

In more complex systems such as customer relationship management (CRM) and enterprise resource planning (ERP) applications, the effort of extracting subsets, transforming and masking data can be very time-consuming, complicated to maintain data integrity and difficult to ensure statistical consistency. A difficulty can be the introduction of inconsistences... for example in an insurer's data where the postcode and house insurance premium are inter-related. In these cases, tools can be purchased to help with the task. However, firstly understand the purposes for which the data extract will be used, and ensure that the tool can be used to generate suitable data sets.

Ensure the extracted data sets cannot be reverse engineered back into the original data, are tracked and disposed of securely at the end of their use. Don't forget that "data" can exist in formats other than database files and office documents... in images, multimedia files, caches, logs and backups.

Are there legal restrictions? Under the Data Protection Act 1998 (DPA), you need to inform subjects of your intended uses for the data they provide. If they haven't agreed to its use for testing your systems, you mustn't use it in this way. Remember, if the data cannot be used to identify individuals, the DPA doesn't apply.

Do you have any experiences to share?

Update 7th November 2008: The question of whether IP addresses are personally identifiable data often arises. Comments by Peter Hustinx, the European Data Protection Supervisor, at the RSA Conference Europe 2008 are a useful reminder that nameless data, such as IP addresses, could be personal data and are thus protected by data protection legislation.

Organisations thinking about web security sometimes mistakenly place more concern on their own protection, often their data, rather than of their users, and their users' data. Web site owners should be doing both.

Children and younger people can be especially vulnerable. If your web site may have younger users, or you have any content or functions with any kind of age restriction, make sure you review what you're doing.

Some resources and organisations for further information are:

• Good Practice Guidance for the Providers of Social Networking and Other User Interactive Services, from the Home Office; developed in conjunction with representatives from industry, charity and law enforcement agencies including the Child Exploitation and Online Protection Centre (CEOP) and the National Society for the Prevention of Cruelty to Children (NSPCC) and published in April 2008.
• Age Verification, Cross Media Rating and Social Networking - the European Commision's recent public consultation document and responses; the results report is expected later this month.
• The recently announced UK Council for Child Internet Safety (UKCCIS) following the Byron review report Safer Children in a Digital World.

and of course your own legal advisors.

Being able to identify users is a vital part of securing data. In practice too little or too much authentication information can be a problem.

In my posting last week on Personal Information Healthchecks Help Everyone I mentioned how the Which? Current Account Best Buy 2008 bank Smile were setting a bad example. David Lacey raised some good issues in Card fraud up - it's no surprise on his IT Security Blog where he discussed the need for mutual authentication between banks and their customers.

I have come across many banks, building societies, insurance companies, pensions funds and other organisations that phone their customers and ask for detailed sensitive information without authenticating who they are. Yes, banks regularly do this - especially when they suspect fraudulent use of your credit card or current account, but they have not thought how to prove their own identity.

But organisations often ask for too much information "for security reasons". This is getting rather like the catch-all "for health and safety" argument for petty issues or those that just require some good management. I have requested copies of bank leaflets by telephone that are readily available in their branches, but have been asked to provide account information. If I walked into the bank's branch, surely I could take a leaflet from the rack without providing details to identify who I am? Yet many web sites take this course as well, asking for all sorts of personal information to join an email list or to provide access to a document. I can understand some need to collect marketing data, but for example is a person's date of birth or full postal address really necessary? It is possible these may be used for later authentication, but it's often not clear.

When reviewing data controls, I like to think about:

• What information is being collected
• Why it is being collected
• What it will be used for
• How it will be looked after and destroyed at the end of its life
• If the data owner agreed to the above

Remember to explain to web site users why you are collecting particular data, like this good example from Classic FM:

Try to reduce the amount of data collected and stored - it's easier to manage it then, and you can't lose it.

It is not usually necessary to apply the same level of authentication to all types of data. Try to differentiate between security and marketing when asking web users to register. The security aspects are used subsequently to identify and authenticate someone - giving them access to data, processes, resources, and so on which other people are not allowed to access. Separately, marketing data might be used to analyse enquiries, to identify opportunities or to contact the person again.

The Information Commissioner's Office has released an online tool called the Personal Information Healthcheck to help consumers protect their personal information. It is also a useful quick training tool for web site developers and designers.

The Personal Information Healthcheck was announced in a press release this week by the UK's Information Commissioner's Office (ICO). Each question provides advice on protecting personal information with a summary and suggestions depending on the user's overall score.

I was pleased to discover the tool's diagnosis of my own behaviour was:

This type of initiative helps everyone, not just consumers. It also increases awareness of the ICO's lengthy but good Personal Information Toolkit released in January 2007. Web developers and designers should also use the healthcheck tool - it can help improve understanding of data security and Data Protection Act issues in their own projects. Question 11 for example asks if you use the same password or PIN for multiple accounts.

The online bank Smile fell into this trap when they joined the Verified by Visa (VbV) password protected identity checking service. Instead of asking their customers to provide a password for VbV, they transferred one of the online banking authentication credentials to Visa for this purpose. See the report in PCPro magazine. I don't understand how Visa accepted this method either.

Banks should be using best practice - I wonder why they decided to do it this way?