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.

Never spy on your web site visitors. Users of your web site/application will not appreciate it. It may also be illegal.

The story in the Times newspaper concerning Council Uses Terror Law to Spy on Shirker in Shower reminded me how easy it is to get carried away with inappropriate monitoring and analysis.

Like employment contracts for staff, make sure your web site privacy policy defines what data you collect, and for what purposes. Don't be tempted to mine this data for other purposes (e.g. marketing) especially if it includes personally identifiable information and users have not opted in for this use.

Check who and what has access to web site and web application logs and audit trails, including archives and back-ups. People with access need to be trained how to handle such data appropriately, for what purposes and to ensure they do not violate laws.

This data should also be subject to an agreed data retention and disposal policy.

An econsultancy.com blog posting concerning search engine optimisation (SEO) and website security caught my eye. Website security as SEO discusses how compromise of your web site or web server might lead to it hosting malware and the disastrous, and rapid, decline in search engine referrals.

The discussion references What's An Exploit Worth To Your Google Traffic? which explains the experience of CenterNetworks, a collection of sites helping various industry professionals learn more about topics such as social networking, Web 2.0 and social media. Following a compromise that left malware being served to visitors from their site, traffic was reduced significantly:

Here's what Google might display after a potential customer clicks on your natural search link, for a web site I almost visited this week:

With one web page being infected every 4.5 seconds by a new malware attack (New Web-Based Malware Attack Hits Internet with Huge Rate of Infections, 15 May 2009), it is legitimate web sites that are spreading the problem (Legitimate Websites are Hosting Most of the Web-Based Malware Due to Poor Security Measures, 15 May 2009).

Many organisations spend a significant amount on search engine optimization (UK Search Engine Marketing Benchmark Report, April 2009)—a single vulnerability could throw much of that investment away. I have three recommendations:

• think about what you would have to do if the same situation occurred to your web site
• get your web site tested for vulnerabilities that could be exploited to host malware
• make sure you have ways to detect the situation, if it arises, as soon as possible.

And, do them now.

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.

Organisations tend to do far too little or far too much web site logging, monitoring and alerting. And thus, meaningful reporting becomes infeasible.

I took the following photograph at the Brunswick residential and shopping centre in Bloomsbury, London. I pity the person who has to work out which fire alarm bell is ringing and which part of the building it relates to.

Web sites and web applications I review usually fall into one of three monitoring classes:

• None
• Marketing related only
• All the bells and whistles.

The marketing-related aspects usually include server log analysis including visitor analytics, search engine monitoring, click-through rates, conversion rates and sometimes availability monitoring. Security aspects are normally never considered, even though these affect customer trust and the ability for organisations to protect and monitor their own and their customer's data.

A few web sites have detailed systems monitoring and alerting, watching for reputational aspects, sales process monitoring, unauthorised file and configuration change monitoring, successful and failed log ins, error conditions, usage patterns, fraud identification, network intrusion detection, computer systems log analysis, and so on.

The latter type often have too much monitoring, and alerts begin to be disabled. The level of security monitoring, alerting and reporting needs to be set during the requirements and design stage of projects, and should be proportional to the information security risks. There is no one size fits all solution, and a blind checklist approach can lead to un-necessary "alarm fog" that means real problems go undetected.

I will list some of the type of things worth monitoring for typical types of web applications in a subsequent post on security logging.

Update 20th February 2009: See subsequent post Security Logging Requirements.

It's important to display a record of changes, activities and actions made by a web site user so they can check they requested these, and to confirm they have been completed.

Change history issues are summarised in the paper referenced from my posting Are Your Customers Infected with Malware Too?, but what should one look like?

I came across this good example for editing a web profile:

It's simple, spans a long time period and is very readable. I'd hope that any changes made by the organisation's staff (e.g. an offline update, an online update on behalf of the user, change of account status) would also be displayed here.

There should also be prominent text explaining what to do if the user doesn't recognise anything in the log.

I'm thinking about whether to write some posts on my recommendations for logging, monitoring and alerting.

Much as I hate to suggest you need more monitoring, web sites and web applications shouldn't be left alone. So I'll write more about this in the new year.

In the meantime, here's my seasonal card—even Christmas trees have CCTV cameras in them now:

Seen in a London shopping centre, early December 2008.

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.

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.

You might not have revenue-earning banner adverts on your web site. But here are some more ways other organisations find to advertise on your property.

In my post a month ago Someone Could Be Advertising on Your Web Site I mentioned the need to check all domains - not just the one being used by your corporate web site. Whilst doing some research on companies regulated by the Financial Services Authority, I came across some more examples for you.

This advertisement appears when a domain, used by a company only for its email, is requested in a web browser:

And, this one is apparently for a web site which has been removed, yet the domain is also currently being used for email:

But it's not always non-standard domains that can have problems. I was very surprised to see these links appearing at the top of one firm's home page and the pop-up advert window:

I wonder if anyone has checked their site recently? Try to keep a schedule of all domain names owned and used by your organisation. Record the registrars, contacts, renewal dates and any associated certificates. Periodically test all the domains to check they are only being used for your own approved purposes, and are not providing advertising space for others, or leaking details about your organisation or systems.