The UK's Office of Fair Trading (OFT) promotes and protects consumers' interests by ensuring markets work well, and that businesses act fairly and competitively. The government has asked the OFT to develop a longer term national strategy for consumer protection and enforcement on the internet. The strategy is intended to promote a safe and vibrant internet market.

As part of this strategy development, the OFT has launched a consultation on E-consumer Protection. The objectives are to improve the effectiveness of online markets and increase the level of consumer trust, so that consumers have a real option to use the internet for transactions, as equally as any other channel. The aim is also to ensure that enforcement of consumer protection online is as good as anywhere else in the world.

The main consultation document outlines some useful statistics about the UK internet economy using data from the European Commission's Consumer Markets Scoreboard 2010, the OECD and the OFT's Attitudes to Online Markets (publication due shortly). For example, 71% of the UK's retailers use e-commerce/internet sales channel for retail, and internet/online accounted for 9.5% of UK retail trade (£38 billion) in 2009. Apparently UK consumers have a high level of trust in UK sellers/providers' protection of their consumer rights and that they are adequately protected. However, it is not all good news as almost 20% of UK internet users are not transacting online, with a third of these stating concerns about the security of their personal and financial information as the reason. Overall, two-thirds of all internet users are worried about unauthorised access to their personal information. There are also concerns about being conned by companies online. The consultation document outlines how consumers may be becoming complacent about security but that they lack awareness of issues such as mis-use of cookies and behavioural advertising.

The OFT suggests these problems reduce confidence, lead to lower levels of demand, and consequently lower levels of supply. Households can miss out on potential savings and this is especially problematic for low income households (LIH). The consultation document proposes that agencies should work together to empower consumers, promote business compliance and develop effective enforcement. It proposes a number of high-level actions under the themes of consumer education, tool provision and hardening, business information, cooperation and deterrence, and enforcement capability building, coordination and leveraging intelligence.

The outcome of this consultation will have a large impact on organisations in the business-to-consumer (B2C) sector (there is also some discussion of whether C2C should also be addressed). If you are an online retailer, perhaps get in touch with your trade organisation and ask them whether they are responding, or do so yourself.

There are five general response questions, and further more-detailed questions about the high-level actions and monitoring proposed. Responses can be submitted online, by email and by post. The consultation period closes on 13th October 2010.

Yesterday, the UK Information Commissioner's Office (ICO) launched their Personal Information Online Code of Practice.

The new code is available online as an eBook together with associated guidance for individuals Protecting Your Personal Information Online. Hopefully the code will also be available as a standalone PDF for offline use and in print.

The Personal Information Online Code of Practice has been improved substantially since the draft for consultation was issued in December. The code describes the benefits of protecting personal information including increased trust, reduced reputational risk, better take-up of services, reduced risk of data breaches and associated enforcement action, improved competitive advantage, increased quality of data and decreased customer/client/citizen support costs.

I am pleased to see so many practical tips tied to real-world examples such as whether IP addresses are personal data (answer: probably). It is difficult to get the balance of detail and readability correct, but I think this document will hit the mark for many busy web site owners.

The code points to other matters that should be considered (e.g. risk assessments), but correctly doesn't details precisely how these are undertaken.

Update 9th July 2010: The Personal Information Online Code of Practice is now available both as a PDF and in print on request.

Today the the Ministry of Justice (MoJ) has announced a Call for Evidence on current data protection legislation, asking for views on how the European Directive and the Data Protection Act (DPA) are working, the impact of data protection on individuals and business, and whether the current powers and penalties of the Information Commissioner could be strengthened.

This evidence is to assessed and used to inform the UK's position in negotiations on a new EU instrument for data protection, which are expected to begin in early 2011.

The 56-page Call for Evidence document is divided into seven chapters on the topics evidence is sought on— definitions, data subjects' rights, obligations of data controllers, powers and penalties of the Information Commissioner, the principles-based approach, exemptions under the DPA, and international transfers:

• Call for evidence
• Press release

Interestingly some of the questions ask for views on data breach notifications, whether the eight principles of data protection should be more prescriptive and how consent is sought. All potential issues for web site owners.

The Call for Evidence is seeking evidence from individuals, private organisations, charities and public authorities, and is due to close on 6th October 2010.

Sometimes when I'm out socially and people ask what I do, the conversation progresses to concerns about their own web site. They may have a hobby site, run a micro-business or be a manager or director of a small and medium-sized enterprise (SME)—there's all sorts of great entrepreneurial activity going on.

It is very common for SMEs not to have much time or budget for information security, and the available information can be poor or inappropriate (ISSA-UK, under the guidance of their Director of Research David Lacey, is trying to improve this). But what can SMEs do about their web presence—and it is very unusual not to have a web site, whatever the size of business.

Last week I was asked "Is using <company> okay for taking online payments?" and then "what else should I be doing?". Remember we are discussing protection of the SME's own web site, not protecting its employees from using other sites. If I had no information about the business or any existing web security issues, this is what I recommend checking and doing before anything else:

• Obtain regular backup copies of all data that changes (e.g. databases, logs, uploaded files) and store these securely somewhere other than the host servers. This may typically be daily, but the frequency should be selected based on how often data changes and how much data the SME might be prepared to lose in the event of total server failure.
  • check backup data can read and restored periodically
  • don't forget to securely delete data from old backups when they are no longer required
• Use a network firewall in front of the web site to limit public (unauthenticated user) access to those ports necessary to access the web site. If other services are required remotely, use the firewall to limit from where (e.g. IP addresses) these can be used.
  • keep a record of the firewall configuration up-to-date
  • limit who can make changes to the firewall
• Ensure the host servers are fully patched (e.g. operating system, services, applications and supporting code), check all providers for software updates regularly and allow time for installing these.
  • remove or disable all unnecessary services and other software
  • delete old, unused and backup files from the host servers
• Identify all accounts (log in credentials) that provide server access (not just normal web page access), such as used for transferring files, accessing administrative interfaces (e.g. CMS admin, database and server management/configuration control panels) and using remote desktop. Change the passwords. Keep a record of who has access and remove accounts that are no longer required and enable logging for all access using these accounts.
  • restrict what each account can do as much as possible
  • add restrictions to the use of these accounts (e.g. limit access by IP address, require written approval for use, keep account disabled by default)
• Check that every agreement with third parties that are required to operate the web site are in the organisation's own name. These may include the registration of domain names, SSL certificates, hosting contracts, monitoring services, data feeds, affiliate marketing agreements and service providers such as for address look-up, credit checks and making online payments.
  • ensure the third parties have the organisation's official contact details, and not those of an employee or of the site's developers
  • make note of any renewal dates
• Obtain a copy of everything required for the web site including scripts, static files, configuration settings, source code, account details and encryption keys. Keep this updated with changes as they are made.
  • verify who legally owns the source code, designs, database, photographs, etc.
  • check what other licences affect the web site (e.g. use of open source and proprietary software libraries, database use limitations).

Do what you can, when you can. Once those are done, then:

• Verify the web site and all its components (e.g. web widgets and other third party code/content) does not include common web application vulnerabilities that can be exploited by attackers (e.g. SQL injection, cross-site scripting).
  • use resources such as the OWASP Top Ten and WASC Threat Classification
  • build security requirements into future developments
• Check what obligations the organisation is under to protect business and other people's data such as the Data Protection Act, guidance from regulators, trade organisation rules, agreements with customers and other contracts (e.g. PCI DSS via the acquiring bank).
  • impose security standards and obligations on suppliers and partner organisations
  • keep an eye open for changes to business processes that affect data
• Document (even just some short notes) the steps to rebuild the web site somewhere else, and to transfer all the data and business processes to the new site.
  • include configuration details and information about third-party services required
  • think about what else will need to be done if the web site is unavailable (does it matter, if so what exactly is important?)
• Provide information to the web site's users how to help protect themselves and their data.
  • point them to relevant help such as from GetSafeOnline, CardWatch and Think U Know
  • provide easy methods for them to contact the organisation if they think there is a security or privacy problem
• Monitor web site usage behaviour (e.g. click-through rate, session duration, shopping cart abandonment rate, conversion rate), performance (e.g. uptime, response times) and reputation (e.g. malware, phishing, suspicious applications, malicious links) to gather trend data and identify unusual activity.
  • web server logs are a start, but customised logging is better
  • use reputable online tools (some of which are free) to help.

That's just the basics. So, what would be next for an SME? If the web site is a significant sales/engagement channel, the organisation has multiple web sites, is in a more regulated sector or one that is targetted particularly by criminals (e.g. gaming, betting and financial), takes payments or does other electronic commerce, allows users to add their own content or processes data for someone else, the above is just the start. Those SMEs probably need to be more proactive.

This helps to protect the SME's business information, but also helps to protect the web site users and their information. After all, the users are existing and potential customers, clients and citizens.

Oh, the best response I had to someone when I was explaining my work: "You're an anti-hacker than?". Well, I suppose so, but it's not quite how I'd describe it.

Any comments or suggestions?

Like many other document and files on your web site, PDFs can leak information in more than one way. Apart from the normal content, there is often meta data, information from previous versions and sometimes, links to internal resources.

On Wednesday, the Financial Services Authority (FSA) reported they had acquired a list of 38,000 names, addresses and telephone number that boiler rooms were using to target potential investors in worthless shares. The FSA wrote a letter to all the people listed. They also published the letter's outline format as a PDF. Unfortunately four enabled hyperlinks in the document do not reference the www.fsa.gov.uk website as intended, but instead a file on someone's computer, probably at the FSA.

Oh dear. Nothing too serious this time, but everything that is published should be checked for validity before release, and verified after publication. This should include all information, not just the normal visual content. The FSA should know better. Publishing to print (e.g. the letters) removes some of this additional information where publishing to an electronic format (e.g. PDF) doesn't always. All publishing should follow standard procedures and approvals processes should include checks for additional information.

Embedded data may leak business information (e.g. previous changes, authors' comments, file paths, account names, intellectual property) or personal data (e.g. location data, names), and possibly give malicious users information that will help them exploit the organisation's systems.

Also, some good news for the FSA, it has survived the change of government.

Information in a web application could be the most valuable asset. A research study of UK executives' attitudes to data protection risks and data breaches was published by the Ponemon Institute at the end of March.

The report, Business Case for Data Protection - A Study of CEOs and other C-level Executives in the United Kingdom (and a US version), was sponsored by Ounce Labs (now part of IBM). A representative sample of 115 respondents were surveyed across a range of small, medium and large enterprises. Almost 80% of the organisations surveyed had suffered a data loss in the previous 12 months. The report lists a useful priority ranking of the six most critical types of data to business operations:

1. Financial information
2. Intellectual property
3. Non-financial confidential information
4. Employee information
5. Business customer information
6. Customer or consumer information

Of course other parties (e.g. partners, suppliers and customers) might view the last two as most important to themselves.

The findings were broadly similar to the 2009 survey. Maintaining reputation and brand was the most commonly stated important organisational goal that depends on data protection and there seemed to be many fewer organisations for which ensuring regulatory compliance was such a goal. The ranking of business functions the respondents felt needed to collaborate to achieve data protection goals changed somewhat, but generally the survey seems to add weight to the previous year's findings. Even the "average cost per compromised record" seemed to be about the same (the number is in the report if you are interested).

But determining the impacts (direct and indirect costs) of data breaches is one aspect of calculating the value of information. Recently judges in the US have been trying to determine the loss when data were stolen in the case of Albert Gonzalez for the TJX breach (who has now been sentenced).

The ICO's report on the business case for investing in proactive privacy protection, The Privacy Dividend, describes alternative aspects for valuing information—and not just from the business' own perspective. This seems to be the discussion the US judges were having.

Another report, published two weeks ago, from SAS and the London Business School on Valuing Information as an Asset discusses the internal business value. The report argues for a proactive, asset-centric, value-based approach to the management of information, rather than a security-centric approach, which could otherwise limit access to data rather than enabling its exploitation. Without placing a value on information, and therefore an economic incentive, data breaches (real breaches not lost media) will continue.

Information in web applications should add value and therefore it needs to be protected from internal and external threats. That shouldn't mean it can't be exploited to fulfill its potential (within appropriate legal, ethical and other constraints). By considering what this potential is and its values to various parties are during the design of the system, appropriate security and privacy measures can be built in that support and enhance the business functions, not detract from the organisation's goals.

Special Publication (SP) 800-122 Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) has been published by the US National Institute of Standards and Technology (NIST). Are you using personal data on your web site?

SP 800-122 provides a useful read for people responsible for assessing privacy and for those designing and implementing privacy controls within information systems and business processes. Importantly it mentions web applications which are increasingly being used as part of business processes. By their nature, data will pass through systems more exposed to public threats.

In the UK, the best starting point for advice is the Information Commissioner's Office guides and other resources, especially the Data Protection Guide and the pages and reports on building privacy in. However, SP 800-122's impact classification methodology, lists of safeguards, examples and scenarios are useful whatever your jurisdiction.

But do note, the definitions, requirements and obligations in NIST SP 800-122 of course relate to US legislation and not to the UK Data Protection Act 1998. In particular they don't cover all eight UK data protection principles. Apart from background reading, they can therefore also be of use for UK organisations considering, or who already have, customers or some other presence in the US.

An article about the upcoming new regime for the classification and labelling of chemicals reminded me to write about software assurance (i.e. software security) labelling (and since web sites are software). From 1 December 2010, the UN Globally Harmonized System of Classification and Labelling of Chemicals (GHS) comes into force, implemented in Europe by the Regulation (EC) No 1272/2008 of the European Parliament and of the Council of 16 December 2008 on classification, labelling and packaging of substances and mixtures (CLP), amending and repealing Directives 67/548/EEC and 1999/45/EC, and amending Regulation (EC) No 1907/2006.

CLP implications and guidelines are explained by the UK Health and Safety Executive (HSE) but are defined fully in the UN's documentation. The headline chemical labelling indicates the potential damage/harm that can occur, rather than the content/properties of the agent. I like this "impact" approach. Nutritional labelling on the other hand generally tends to focus on ingredients and their properties, but some food labelling is also beginning to attempt to classify low/medium/high fat/saturates/sugars/salt levels, which is more akin to the impact approach.

Jeff Williams (CEO of Aspect Security and Chair of OWASP Foundation) proposed a Software Facts label five years ago at OWASP Appsec Europe. This would be similar to appliance energy usage labels, food nutrition facts label, material safety data sheets or laser safety classes. That idea was taken up by NIST and the Software Assurance Consortium (SwAC) to develop another proposal.

Comment here and here around the same time in 2005 describes some of the challenges. Indeed many more aspects of the software development lifecycle impact upon the creation of secure software. But simplicity is needed in the presentation of such information—perhaps some high-level impact related indicators augmented by the more detailed information for different audiences (e.g. users, operators, administrators, system achitects). SwAC's version seems to be somewhat aimed at software development teams, instead of people in end user organisations, especially those involved with procurement decisions. Whilst some people will want to know the data behind a classification, most businesses and consumers will need something more akin to the CLP headline labels relating to business (or personal) impact as a starting point for their decisions.

• How dangerous is this software?
• How reliable is it?
• How does it affect privacy?
• How does the IT environment affect these?
• How are these affected by changing the default settings?

This a big challenge. Just specifying the privacy practices for a web site can be complex. ENISA's Common Assurance Maturity Model (CAMM) project is trying to define how cloud service providers can be compared to allow users to make informed decisions about the risks. Perhaps that project will develop into some form of labelling scheme, or at least provide ways for typical consumers of the services to determine their own risks as simply as possible.

I don't know the status of the SwAC project but will now make the effort to find out.

What do your web-enabled personal data processing systems look like? Are they black holes you keep clear of?

Are you aware how personal data enters your information systems and business processes, how it is used, where it it stored, where it is transferred and how it is disposed of? Probably not, well at least not fully. And full information about purpose and consent? Almost certainly not.

Consider this scenario... a charity collects donations from supporters and uses a third-party for it payment screens to minimise the scope of Payment Card Industry Data Security Standard (PCI DSS) cardholder data environment. However, the charity needs to maintain details of the donors' names and addresses for those who have indicated they are UK taxpayers and have opted in for their donation to be topped up by the government's gift aid scheme.

The charity doesn't want to put donors off by asking for their address more than once, so therefore chooses to use the cardholder's billing address as their record for gift aid, even thought these might not be the actual donor.

But what happens to this cardholder name and address? Imagine a phonecall from a supporter who is surprised that their cardholder address, which is different to their usual postal address, has received marketing materials from the charity? Is this scenario fact or fiction? Yes it was real.

The charity was contravening these data protection mandates:

• confidentiality (the charity's own policy)
• fair processing (first principle, Data Protection Act 1998)
• specified purposes (second principle, Data Protection Act 1998)
• accuracy (fourth principle, Data Protection Act 1998)
• consent (data fundamentals Direct Mail Code of Practice, Institute of Fundraising).

Luckily neither the payment card primary account number (PAN) nor sensitive authentication data (e.g. security code) were being recorded which could have meant PCI DSS compliance issues as well. But the possible accuracy and confidentiality problems by using billing details of the cardholder, and the lack of consent for using cardholder addresses for marketing purposes were a real concern. Until this incident, the business owner had not realised how personal data were flowing through the system and being used.

How might this type of problem be avoided? Like building security in, early consideration of privacy and the value of personal data in system development including the use of risk assessments (for example privacy impact assessments) would provide a better understanding of the data flows, processes and risks. Another benefit is that proactive privacy protection contributes to good security.

Make sure you don't have any black holes.

Thinking of creating a mobile phone application for your business? A major privacy failure with an iPhone application has been reported on the Zero Day blog and is a useful case study.

All iPhone apps have to be approved by Apple to "protect consumer privacy, safeguard children from inappropriate content, and avoid applications that degrade the core experience of the iPhone". But the application Quip from Addy Mobile Inc provides provided unlimited photo texting with the slogan "Why pay more for MMS? Don't you pay enough for your iPhone already?". Well, many of the application's users are paying for it now.

It seems the images (typically photos) were stored on a publicly-accessible web site, with the only access "control" being a random directory (folder) name five characters long—something that is easily iterated through to find photos and breach their customers' privacy. What makes it worse is that many of these messages and images were also turning up in public search engine results leaking sensitive information.

I was unable to find any privacy notice or privacy policy from the company:

The cached search results indicate the images are being stored using Amazon Web Services (AWS) S3. This is not a cloud computing specific issue. It could just as well be on a web site hosted by the company itself. The Quip web site (http://www.quiptxt.com), Quip message site (http://www.quiptxt.com) and Quip S3 image repository (http://quipimg.s3.amazonaws.com) are all currently offline. The comany issued a statement via Reddit. As the Zero Day blog says, these vulnerabilities would have been trivial to fix and protect the confidentiality of users' message text and photos. Using any of common sense, threat modelling, risk assessment or security verification should have identified the problems. I'm sure lawyers in the US will be circling. Since Apple approved the application, let's hope they are ready in case the lawyers knock on their door as well.

Addy Mobile Inc may itself be unavailable soon.