26 January 2010

Retention

Posts relating to the category tag "retention" are listed below.

26 January 2010

Web Site Security and Privacy Mapping

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.

Partial image of the 'Principal Influences on UK web Applications' mind map diagram

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.

Posted on: 26 January 2010 at 08:51 hrs

Comments Comments (0) | Permalink | Send Send

05 January 2010

Another Year, Another Survey

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?

Partial screen capture showing the first ASP error message 'Field error - Either BOF or EOF is True'

Then I tried it with the argument completely removed.

Partial screen capture showing the second ASP error message 'Procedure or function usep_SelSelSurveyEncodedDetails expects parameter @ENCODED_ID' which was not supplied

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.

Posted on: 05 January 2010 at 08:56 hrs

Comments Comments (0) | Permalink | Send Send

01 January 2010

NAI Code Compliance Report 2009

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.

Members that collect, transfer, or store data for use in OBA [Online Behavioral Advertising], Multi-Site Advertising and/or Ad Delivery & Reporting shall provide reasonable security for that data.

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.

Posted on: 01 January 2010 at 14:57 hrs

Comments Comments (0) | Permalink | Send Send

18 September 2009

Tidy Up That Test Data

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.

Flower bed and stone urn in Regent's Park, London, August 2009

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.

Posted on: 18 September 2009 at 10:40 hrs

Comments Comments (0) | Permalink | Send Send

25 August 2009

User Analytics and Tracking

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.

Posted on: 25 August 2009 at 08:37 hrs

Comments Comments (1) | Permalink | Send Send

12 June 2009

Privacy Notices Code of Practice

Privacy Notices Codes of Practice is being launched today by Richard Thomas, the Information Commissioner.

Partial view of the cover from the draft 'Privacy Notices Code of Practice'

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.

Posted on: 12 June 2009 at 08:19 hrs

Comments Comments (0) | Permalink | Send Send

12 December 2008

Rising Data Protection Act Costs

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.

Part of the cover from the Ministry of Justice's document showing the title.

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.

Posted on: 12 December 2008 at 07:25 hrs

Comments Comments (0) | Permalink | Send Send

03 October 2008

Too Little and Too Much Authentication

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:

Some answers to common questions about registration and emails from the Classic FM website, including topics such as 'Why am I asked for information such as my postcode, gender and date of birth when registering or filling in forms on the website?' and 'Will my personal details be safe?'

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.

Posted on: 03 October 2008 at 11:16 hrs

Comments Comments (0) | Permalink | Send Send

Retention : Web Security, Usability and Design
http://www.clerkendweller.com/retention
ISO/IEC 18004:2006 QR code for http://clerkendweller.com

Page http://www.clerkendweller.com/retention
Requested by 38.107.191.119 on Friday, 12 March 2010 at 02:09 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use http://www.clerkendweller.com/page/terms
Privacy statement http://www.clerkendweller.com/page/privacy
© 2008-2010 clerkendweller.com