dfm covers

Setting Store on New Data Rules

Setting Store on New Data Rules

Mark Osborne takes a personal look at the challenges posed to UK & European
organizations by the 2006 directive

  EU Directives always cause debate. Think of the problems caused by the working-hours directive or the data protection directive. But the EU data retention directive has caused more than most. The title and reference is: ‘Directive 2006/24/EC of the European Parliament and of the Council of 15 March 2006 on the retention of data generated or processed in connection with the provision of publicly available electronic communications services or of public communications networks and amending Directive 2002/58/EC’1. What a mouthful! From here on we shall refer to it as the Directive. Its’ purpose (from Article 1, para 1) is to ensure that the “providers of publicly available electronic communications services or of public communications networks with respect to the retention of certain data that are generated or processed by them, in order to ensure that the data are available for the purpose of the investigation, detection and prosecution of serious crime”. It sounds clear enough. And not unreasonable… at least, apparently not. Just look around at the many lucrative conference, online forums and journals that have spent some time conjecturing, discussing and arguing about the true meaning of it all. There are many reasons that people seem to be in disaccord, but the main points of contention are:

  • Some people believe that the Directive is an infringement of their rights, and that it enables the authorities to bug all conversations and transactions on the Net. Add to the mix, the various reported comments from a number of authorities that the Directive’s stated requirements fall short of what they really wanted, and that some of guidance documents explicitly ask for items that could not be justified by the directive, and you can certainly see a level of discord.
  • People that wrote the directive claim that all the data required to be retained would be collected as part of normal business – yet much of the non-voice data is far from what is routinely collected. Indeed, it is expensive and difficult to obtain, especially when you consider the abundance of traffic on today’s Internet. Such a massive change will inevitably cause confusion. Many engineers across EU are saying to themselves, “How in the Hell am I going to get that data – I must have read it wrong!”.
  • The Directive doesn’t clearly identify what is meant by “the providers of publicly available electronic communications services”. Many people that should comply are avoiding doing so because “it only applies to ISPs.”

The original purpose of this document was to dispel these causes of confusion, particularly the second and third points, in the light of supporting documentation and the Directive itself. Initially, I had some sympathy for the arguments that the Directive was confusing, but I believed I had gained a level of understanding through multiple re-reads driven by the sheer need to implement something sensible. However, on revisiting the directive to construct this paper, I found myself believing the requirements to be relatively clear (by the standards set by other computer laws). Could it be that our industry relies on its legal requirements being spoon-fed to it by the very magazines, conferences and journals mentioned previously, and they, plus the activists from the first point above, could be engaged in successful campaign of obfuscation? Perhaps too many years spent solving security problems, caused by “events” that everybody said would never happen, have left me paranoid. I will let you decide the reason for confusion – but confusion there is. Lots of time has been spent on the Civil liberties issue, and as much as I sympathise, I am a bloke with a job to do and these guys aren’t really helping.

So, let’s go straight to Point 2: what do we need to store?

Data retention requirements are described in Article 5 of the Directive. As I have said, on my first reading, I found the requirements complex. However, I must have been suffering from some kind of mid-life crisis, as, on later reflection, the data requirements are actually not very difficult to understand. The data requirements are sub-divided into two general types as they are specified. These are:

  • Fixed network telephony and mobile telephony
  • Internet access, Internet e-mail and Internet telephony
  • From this we can plainly see, with no hypothesis or extrapolation (don’t worry, that will come!), that we are supposed to record information about four categories of network traffic:
  • Fixed network telephony and mobile telephony
  • Internet access
  • Internet e-mail
  • Internet telephone
  • Fixed network telephony and mobile telephony

My expertise in this area derives from my sitting next to many experts in this field, which is a dubious qualification at best. That said, the stated requirements appear succinct and with some experience in the area, most telecom security pros will come up with a valid implementation. The stated requirements for fixed network telephony and mobile telephony are:

  • (A1i) the calling telephone number – as this will be a customer, the name and address of the subscriber or registered user;
  • (B1i) The telephone number(s) called or the number endpoint if it has been forwarded or transferred, routed; If it is your customer you should retain the name(s) and address(es) of the subscriber;
  • (C1) the date and time of the start and end of the communication;
  • (D1)the telephone service used;
  • (E1) Where a mobile is concerned, data to identify the handset and its data necessary to identify the location of mobile communication equipment:
  • The calling and called telephone numbers – surely a careless repetition in the document as these requirements are already stated
  • The International Mobile Subscriber Identity (IMSI) of the calling party; (mobile only)
  • The International Mobile Equipment Identity (IMEI) of the calling party; (mobile)
  • The IMSI of the called party; (mobile only)
  • The IMEI of the called party; (mobile only)

In the case of pre-paid anonymous services, the date and time of the initial activation of the service and the location label (Cell ID) from which the service was activated; (mobile only)

  • (f1) the location label (Cell ID) at the start of the communication;
  • (f2) data identifying the geographic location of cells by reference to their location
  • Labels (Cell ID) during the period for which communications data are retained


The full article appears in Issue 2 of Digital Forensics Magazine, published 1st February 2010. You must log in with a valid subscription to read on...


Please make cache directory writable.

Submit an Article

Call for Articles

We are keen to publish new articles from all aspects of digital forensics. Click to contact us with your completed article or article ideas.

Featured Book

Learning iOS Forensics

A practical hands-on guide to acquire and analyse iOS devices with the latest forensic techniques and tools.

Meet the Authors

George Bailey

George Bailey is an IT security professional with over 15 years of experience


Coming up in the Next issue of Digital Forensics Magazine

Coming up in Issue 42 on sale from February 2020:

Forensic Syntactical & Linguistic Investigation

Mark Iwazko presents a case study regarding a Forensic Syntactical & Linguistic investigation: Instructed by the Moscow General Council of one of the actual big four accountants. Read More »

Forensic Readiness: A Proactive Approach to Support Forensic Digital Analysis

An increasing number of criminal actions are inflicting financial and brand damage to organizations around the globe. An impressive number of such cases do not reach the courts, mainly because of the organization’s inefficiency to produce robust digital evidences that are acceptable in the courts of law. Read More »

Subscribe today

Using Error-Patterns for Attribution: An Applied Linguistics Technique

Corpus Linguistics within Second Language Acquisition has developed models of error patterns made by defined groups of second language learners. This knowledge base can be leveraged by a knowledgeable analyst to attribute content to a subset of authors. Read More »

Every Issue
Plus the usual Competition, Book Reviews, 360, IRQ, Legal

Click here to read more about the next issue