In Advertising Standards - Security Standards I mentioned how online marketing claims are subject to the UK Code of Non-Broadcast Advertising, Sales Promotion and Direct Marketing (CAP Code) from the Advertising Standards Authority (ASA).

Each month the ASA publishes a list of adjudications, and a recent one caught my eye. In the ASA Adjudication on UK2 Group a claim of "100% network uptime in 2011" was found to have breached CAP Code (Edition 12) rules 3.1 and 3.3 (Misleading advertising), 3.7 (Substantiation) and 3.11 (Exaggeration).

The complaint by a (consumer) customer was upheld since "UK2 had not provided any documentary evidence to demonstrate that their web hosting service achieved 100% uptime in 2011". UK2 had attempted to justify their uptime claim by saying that an individual server being offline did not affect the performance of the network. In this case, the customer's view of the service was the total package.

Whilst this does not specifically relate to application security, this appears to be quite similar to unsubstantiated claims such as "being secure" and "we protect your data". We do not know what the informally resolved cases relate to but it will probably only be a matter of time before we see challenges to application security claims for B2C services.

Following my posts about Security Labelling, the effect of Location and Trust .UK, I read about an early draft of proposed privacy labelling icons.

Privacy policies can be a nightmare and some bright people got together to discuss ideas and this lead to a workshop in London earlier this year.

Well, there are now some suggestions for privacy icons which would help users understand the purposes of use, with whom it is shared and how long it is kept for. These could complement well written privacy notices.

Many of the issues with the proposal are discussed in the project's blog posts and associated comments. The largest obstacles I see are where different "policies" apply to different user roles and mis-labelling by site owners, even if they participate. In the former, customer data may be held for longer than other visitor data, and employee data may be help for decades (and may be required by law). All sites will want "good labels" and it might be easy to say the privacy labels apply to some users/some processes, and yet not label the other uses. The definition of "intended use" is also open to interpretation — an issue currently being discussed by the US Federal Trade Commission. However, I think this is a great initiative and encourage you to get involved.

On a related topic, remember the UK ICO's consultation on its draft Data Sharing Code of Practice closes tomorrow.

User tracking on web sites appears to be a growing concern amongst the public. The current What They Know campaign by the Wall Street Journal (WSJ) is making marketers techniques more widely known.

The mis-use of web cookies has received significant press coverage in the past, and now the mis-use of beacons (also known as web bugs) and Flash cookies (also known as Local Shared Objects or LSO cookies) is attracting attention. The WSJ examined popular sites and reported their findings online.

The value of personal data can be calculated in more than one way, is being debated and used for data protection business cases—marketers already know its value to them.

Marketers should be concerned that their own data collection and usage practices comply with legal and other requirements, and that these are described clearly to users in a comprehensible privacy notice. But if you have third-party content included within your pages, you also need to address those organisation's usage of the data they collect from your visitors. Third-party code may not just be from advertisers, but includes users analytics, embedded data feeds, video, photos and JavaScript libraries hosted elsewhere. For behavioural advertising purposes, check out the guidance from the IAB-UK.

Where possible try to ensure your web site's core functionality and design are unaffected if users choose not to accept content from other domains whilst viewing your pages.

Oh, and check your own site out with the Privacy Choice tool and ensure it is correct. Despite the name "privacy scan", it doesn't of course cover all the privacy aspects you need to take into account!

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?

There's a great post summarising what has been discovered about personal data retention my the major search engines on the Tech and Law blog.

The original posting summarises the discussions between the EU Article 29 Working Party and the search engines with a more recent summary of what the search engines are actually collecting, and when they are disposing of the data. Tech and Law is asking if anyone has additional information to share on this.

Useful, while you are thinking about your own data retention policies.

I have updated the chart detailing the most important guidance, standards, legislation and organisations that can affect web development security and privacy in the UK.

The Principal Influences on UK Web Applications is published on my company's web site and details the changes made since the previous version in August. The information is laid out as a mind map diagram, and as a text tree.

Not all the items are relevant to every web site—some aspects are sector specific—but much of the guidance from organisations, in guidelines and in standards can be of use beyond their intended audiences.

But this chart isn't just about web site security and privacy. The chart can also be useful for organisations implementing an information security management system (ISMS) that need to keep up-to-date with compliance requirements, and those with a need for knowledge on wider information assurance (IA) aspects. There's quite a lot of overlap.

It's that time again when organisations want your opinion on how well they've been performed in the previous year. I'm often quite happy to provide feedback, but sometimes prefer this to be anonymous.

Many of these surveys use third party services to display the form and collect the data, but very few have privacy notices or details you would expect/require on a corporate web site (e.g. the company registration number and registered address). But I can't remember one of these where the option for complete anonymity is provided. The links often include a code in the address URL (an argument name with a value) which I suspect identifies the recipient.

I copied the link and removed the value from the argument and was presented with a horrible error message which gives clues as to what the site is doing. Perhaps a database query that can't find NULL as an identifier?

Then I tried it with the argument completely removed.

So very sloppily put together. At least hide this script error message. Better still, inform me why this code is necessary and give options for anonymity. After all, some feedback is better than none.

If you're going to use third party services, ask them what security verification has been undertaken and to what standard. They should be able to provide details of a recent independent audit if they don't allow their customers to verify security themselves.

Following on from Tuesday's topic of terms and conditions for interactive advertising, the US Network Advertising Initiative (NAI) has just released their 2009 compliance report.

The NAI is an association of 35 US advertising networks, data exchanges, and marketing analytics services providers including Advertising.com, Google and Yahoo.

The NAI Compliance Report 2009 discusses compliance by its members with its self-regulatory code of conduct governing the collection, use, and disclosure of data for online advertising services by its member companies (the NAI Code). The NAI Code has its own definition of personally identifiable information (PII) and sensitive information and its own protection principles. The NAI found its members to be broadly in compliance with the code, apart from ten members that did not disclose specific retention periods for data collected.

Whatever your views of behavioural advertising, industry initiatives like this to improve, and report on, standards are a welcome contribution. No doubt the code will evolve over time, but it is a good starting point. The code perhaps lacks requirements for measuring the accuracy of data or requiring ways for consumers to correct information about themselves, and it would be useful to know what checks are being undertaken as part of the audit. For example "Reasonable security is determined in light of several factors including, but not limited to, the sensitivity of the data, the nature of a company's business operations, the types of risks a company faces, and the reasonable protections available to a company" could be interpreted in a number of ways and some guidance on what is "reasonable" both from the organisation and individual's points of view would be welcome.

P.S. Happy new year.

At this time of the year, gardeners have usually seen the best of their summer displays, and thoughts turn to tidying up the garden before the winter.

The publication of a new report from the Ponemon Institute on Data Security in Development & Testing is a timely reminder that like gardens, our web site and web application development and test systems need periodic attention, otherwise they can go wild too. The report describes the findings from a survey of IT practitioners in the United Kingdom and United States on the adequacy of their policies and technologies in place to protect real data used in development and testing. The survey is included in the report, so you can compare your own organisation.

Take some time to identify how real data are being used in your development and test systems, and determine what sensitive data is being used, stored, transmitted and how it is deleted. Are you allowed to sue the data for development and testing? Check who has access to the data, from where, and what the risks are.

If you undertake some form of masking or other anonymisation technique, do read and take into account a new summary of research and discussion by Paul Ohm in his paper Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization.

Put plans in place now, that will make next year easier. No manure required.

A recent proposed revision of the policy on web tracking technologies for US federal web sites by the Office of Management and Budget set out four principles regarding user analytics and tracking.

• Adhere to all existing laws and policies (including those designed to protect privacy) governing the collection, use, retention, and safeguarding of any data gathered from users.
• Post clear and conspicuous notice on the website of the use of web tracking technologies.
• Provide a clear and understandable means for a user to opt-out of being tracked.
• Not discriminate against those users who decide to opt-out, in terms of their access to information.

The document recommends avoiding outsourced tracking and outsourced data analysis—issues not thought about by many organisations. Just because a third-party service is cheap, doesn't necessarily mean it's the appropriate method to use. I'm less convinced about the example of using cookies to record opt-outs.

The proposed revision attracted a well-considered joint response from the Center for Democracy & Technology and the Electronic Frontier Foundation. They suggested three additional principles.

• Limit use of tracking data.
• Limit retention of tracking data.
• Obtain third-party verification.

The response also referenced their May 2009 Open Recommendations for the Use of Web Measurement Tools on Federal Government Web Sites which recommended the following:

• Use data only for measurement.
• Prominently disclose.
• Offer choice.
• Limit data retention.
• Limit cross-session measurement.
• Obtain third-party verification.

Whilst none of the final guidelines will be mandatory outside the US federal sector, the issues raised are worth consideration by all commercial and non-commercial web sites. For example, the recommendations and principles above could be used to help guide a privacy impact assessment of an organisation's own use of web analytics and tracking technologies.