Regulatory Developments

A bot is a program, maliciously installed on a computer, that allows that computer and thousands of others to be controlled by attackers. Bots are one of the major problems on the Internet, involved in many spam campaigns and distributed denial of service attacks, as well as allowing attackers to read private information from the computer’s disk and keyboard. Some bots even allow cameras and microphones to be monitored by the attacker. Detecting and removing bots is therefore in the interests of both individuals and internet providers. RFC6561 describes the technical issues around detecting and notifying Internet users whose computers may have been infected by a bot, and also highlights the need to take account of legal, economic and reputational issues when doing so.

One of the main problems with bots is that they are now very good at concealing themselves alongside legitimate programs and internet traffic. The RFC notes that

With the introduction of peer-to-peer (P2P) architectures and associated protocols, the use of HTTP and other resilient communication protocols, and the widespread adoption of encryption, bots are considerably more difficult to identify and isolate from typical network usage.  As a result, increased reliance is being placed on anomaly detection and behavioral analysis, both locally and remotely, to identify bots.

Unfortunately neither anomaly detection nor behavioural analysis can be perfect: both may be triggered by legitimate Internet activity that happens to generate patterns that look like those of a bot. This means that any detection and notification process must be aware that some of the computers “detected” will not be in fact be infected. Even for computers that are infected, removing the bot may require more than the average level of technical skill, or involve actions such as deleting and re-installing the operating system that users are not willing or able to do. As an increasing number of devices are connected to the Internet, it seems likely that bots will infect equipment that the user simply cannot disinfect, such as games consoles, set-top boxes or smart meters.

Detecting infected systems also raises significant legal and technical concerns. Since Internet Service Providers know who their customers are, examining their traffic to identify devices that may be infected will involve processing of personal data; detailed inspection of traffic may even come within the scope of Interception law. Such laws may have exemptions for particular actions by network operators, but these are likely to be tightly constrained and require additional privacy protection. Even if the action is lawful, attempts to protect users in this way can be mis-understood – either as unjustified “snooping” or as an attempt to sell security services – resulting in end-users rejecting them.

There are some examples of successful botnet mitigation schemes, and a UK Parliamentary committee has recently called for ISPs to do more in this area. However it’s clear that any scheme needs to be very carefully designed, with input from technical, legal and communications experts.

The RAND feasibility study on a European Cybercrime Centre raises some interesting issues around reporting of cybercrime. Since even in the real-world the accuracy and meaning of crime statistics seem to be a matter of debate, it’s little wonder that cybercrime seems particularly hard to measure. Unfortunately there seems to be a particular vicious circle that businesses don’t report crimes because they don’t think police have resources to deal with them and the resulting low number of reported crimes makes it hard for the police to justify using resources on it.

That highlights two of the different purposes for crime reporting – to solve crimes and to inform the allocation of resources. A third is to detect trends in volumes and types of crime so that law enforcement and systems providers can be better prepared to deal with them. Unfortunately each purpose tends to need different information, and quite possibly different sources, so information collected for one purpose may be hard to use for another. Trends are easier to pick up from statistics that are gathered systematically, such as those from virus and spam filtering, than from voluntary reporting; anonymity might make businesses more willing to report that they had been a victim of crime (useful for statistics and intelligence) but such reports probably couldn’t be used as evidence to prosecute the offenders. Any reporting scheme therefore needs to think carefully what its information will be used for and ensure that it collects the right information and from the right sources to deliver that.

Another issue is what crimes should be counted as “cyber-” anyway? The Council of Europe’s Cybercrime Treaty (2001) covers a lot of crimes where the computer or network is just a communications tool (for example IPR and content-related crimes), whereas the European Union’s Framework Decision on Attacks on Information Systems (2005) looks only at crimes where a computer or network is the target (illegal access to information systems, illegal system interference and illegal data interference). Thus even in legal and law enforcement circles there doesn’t seem to be a common understanding of the term, and what Internet users will expect of a “cybercrime reporting point” is even harder to predict.

The RAND report quotes figures from an American system for reporting “Internet Crimes” (www.ic3.gov) that illustrate some of the potential problems. Despite a very wide definition of Internet Crime as “any illegal activity involving one or more components of the Internet”, still only 26% of reports to the service were considered valid. The top ten complaints all seem to be types of fraud (”non-delivery of goods”, “auction fraud”, “check fraud”, “419″, etc.) and I don’t think any of them would fall within even the wide Council of Europe definition of “cybercrime”. The main purpose of IC3 is to forward complaints to the relevant agency for them to be investigated, though it makes clear that it cannot guarantee that investigations will take place. However 74% of its visitors, who thought they had found a way to resolve their Internet problem, will have been disappointed at the very first step when they discovered that their complaint was out of scope. A cybercrime reporting service might have an even higher disappointment rate. How to turn people away without further lowering their confidence in Internet safety may be the hardest problem for a cybercrime reporting scheme.

A feasibility study by RAND of the proposal for a European Cybercrime Centre (ECC) suggests that the result risks becoming a bit lopsided. The proposal made in 2010 as part of the the Commission’s Internal Security Strategy seemed to be for a small organisation – perhaps a dozen people or so – to help Member States improve their own provisions against cyber-crime:

By 2013, the EU will establish, within existing structures, a cybercrime centre, through which Member States and EU institutions will be able to build operational and analytical capacity for investigations and cooperation with international partners. The centre will
improve evaluation and monitoring of existing preventive and investigative measures, support the development of training and awareness-raising for law enforcement and judiciary, establish cooperation with the European Network and Information Security Agency (ENISA) and interface with a network of national/governmental Computer Emergency Response Teams (CERTs). The cybercrime centre should become the focal point in Europe’s fight against cybercrime.

As I said in Janet’s response to the House of Lords Select Committee at the time, this would be well worth doing; but is already quite a challenge as the RAND study found that different countries have given widely varying remits to the national cybercrime activities that the Centre would work with. For example the UK’s Serious Organised Crime Agency, and several others, aim to reduce harm from serious organised crime; in Sweden the central agency is said to take on novel crimes where it can learn things; in other countries the cyber-crime centre must apparently investigate all crimes of which it becomes aware.

However since 2010 a couple of other problems seem to have been added to the ECC’s remit: first that because there is no consistent reporting of cybercrime across Europe no one actually knows how big the problem is; and second that the police don’t have sufficient technical support for existing investigations. So as well as the original activities the RAND report discusses the ECC designing and commissioning (but not running) software that will allow Member States to create their own websites where members of the public can report cybercrimes, and also providing technical support (mostly expected to involve forensic examinations and analysis) for Member State investigations where local skills are not available. Even in the report’s “low-demand” scenario this technical work is expected to require an additional 23 staff; in the “high-demand” scenario it would be 240. Although “cooperation and collaboration is regarded as one of the most important aspects and where the ECC could add the most value” it seems that at least the majority, and possibly a vast majority, of its staff will actually be doing something else.

The report concludes that

…the aspects related to the phenomenon of cybercrime defy simplistic understanding; evolve rapidly in line with how society uses cyberspace; require technical knowledge to understand and the mapping of long term trends and patterns is fraught with complexity. In order to have any chance of success, a future ECC will need to conduct its activities in the context of these characteristics

This seems to require a flexible organisation that can identify new issues in the area of cybercrime, work in collaboration with a “broad-based capability within member states” to identify and disseminate good practice in dealing with them, and then move on to the next of those rapid evolutions. An organisation with up to 90% of its staff dedicated to addressing current skill and resourcing problems may struggle to achieve the required flexibility.

The European Commission has now announced that it will be setting up the ECC within Europol, but it’s not clear from the announcement whether the activities of the organisation have been re-balanced.

The Government Data Service have published draft identity and privacy principles for federated access management (FAM) systems. It’s interesting to compare these with the approach that has been taken by Research and Education Federations to see whether we have identified the same issues and solutions.

The first thing that caught my eye was that the authors seem to share, even exceed, my doubts about whether Consent is the right legal basis for on-line services. Even when users explicitly agree: “We are very concerned that many Users do not know what permissions they have given nor do they read privacy policies of organisations based outside the EEA” (personally, I’d be very surprised if privacy policies inside Europe are any better read!). Since consent has to be informed and freely-given, that suggests that a lot of the “consent” that services currently rely on isn’t actually valid in law. The first principle “User Control” therefore avoids the word “consent” and says instead that users must “approve” any processing of their personal data. However the commentary confuses things by saying that this does actually mean “consent”. The legal commentary gives what I hope is actually the intention – that processing will be based either on consent or the fact that processing is necessary for the purposes of a contract with the user (for necessary processing, information still has to be available, but it’s less critical that every user reads it). Given that the Principles are written in the context of government services, I’m surprised they don’t also mention the justification (provided by both the EU Data Protection Directive and UK Data Protection Act) that processing is necessary to fulfil a legal obligation. Renewing my TV or driving licence and submitting a tax return – uses of current Government on-line identity systems – don’t feel much like contracts to me. Nor do they feel like the sort of Exceptional Circumstances covered by Principle 9 which is the only other place where justifications for processing are introduced.

The second principle, Transparency, is a clear legal requirement, but the commentary makes the good point that it is also an important factor in “engendering trust” among users of on-line systems.

The Principle of Multiplicity isn’t a legal requirement, but can be seen as another aspect of trust-building. The Principle requires that users have a free choice of Identity Provider and can choose multiple Identity Providers if they wish. Service Providers are allowed to insist that the chosen Identity Provider must offer sufficient Level of Assurance for the particular service, but cannot insist on a particular Identity Provider. This seems to be intended to protect users against inappropriate compulsion by Service or Identity Providers to disclose more information than is necessary (Principle 6 on Portability in fact prohibits anyone from compelling disclosure) and also to prevent Service or Identity Providers from collating information about an individual’s use of different services. Research and Education federations have looked at the same problems, but addressed them by assuming that the Identity Provider (typically the user’s university, college or school) is “on their side” and will use technical measures such as unique per-service opaque identifiers to prevent linking by Service Providers and to minimise the information disclosed. The idea of Multiplicity also seems to break down where, as is normal in Research and Education, the Identity Provider additionally provides authoritative attributes about the user: for example that they are a member of the organisation that operates the Identity Provider. For these attributes there only is a single authoritative source – only my university can assert that I am covered by its site licence for on-line content, only the Engineering Council can assert my professional status – so the Principle may need modification for them. I suspect the final clause of the Principle also says more than it intends: “A Service Provider does not know the identity of the Identity Assurance Provider used by a Service-User to verify an identity in relation to a specific service”. If this actually means what it says – that a Service Provider must not know who it is relying on for an Identity Assertion – then the required technology and legal processes are going to be very complex. I suspect the intention is actually that one Service Provider must not be able to find out which Identity Provider I used for other services.

Data Minimisation is another Principle derived directly from law. The rationale also contains another hint that the authors really are thinking of a distinction between processing on the grounds of necessity and processing on the grounds of consent, since it allows a user to “request [an Identity] Provider to hold information beyond the minimum necessary”: in other words to process some information because of necessity and other information because of consent.

Data Quality (Principle 5) looks like a reflection of the legal requirement, but the wording of the Principle seems to allow a user to  do nothing and deliberately leave their information out of date. At least for those Identity Providers who are committed to providing accurate information, I would expect there to be a requirement for the Identity Provider to check accuracy periodically and to warn relying Service Providers where information may be too stale to be relied on for a particular use. Since I commit a criminal offence if I do not update my driving licence details when I move house, I would expect the DVLA at least to want reassurance that address information it received from an Identity Provider had been checked recently.

The portability part of the Access and Portability Principle (Principle 6) implements a proposal that has been suggested for Service Providers in the proposed Data Protection Regulation where it has been noted that it requires a new way of working, and perhaps technology changes, for them. The Principle also applies it to Identity Providers, and apparently to all information they hold, which may involve further technical, process and legal challenges. For example if I decide to transfer my identity information from one provider to another, does the second provider have to rely on the identity verification done by the first one? And if I transfer all an Identity Provider’s records of my activity (which appears to be envisaged by the commentary) then what will be the position if a recipient Identity Provider is required to present them as evidence of something that happened before the transfer? In discussion of lifelong identifiers, Research and Education federations have identified the point of transfer between Identity Providers as an opportunity for loss of identity or masquerading. Since we haven’t yet worked out a robust solution to this problem, it will be interesting to learn if the Government sector have.

The Governance/Certification Principle sets a high standard, that all Service and Identity Providers must be certified, including independent audits of their design and processes. While there has been some discussion of audits in Research and Education federations these have concluded that, other than for services with particularly sensitive or high-value information, the cost of external audits was not justified. Again, this may reflect the fact that our users will normally have a deeper and significantly stronger relationship with their Identity Provider. We have tended to assume that if the organisation’s systems and processes are good enough for the more intense and more sensitive information processing involved in the employee/employer or college/student relationships then they are likely to be more than sufficient for the organisation’s also acting as Identity and Attribute Provider.

The Problem Resolution Principle reflects a concern that as federated identity systems get more complex, it may be hard for the user to work out who they need to contact to resolve a problem. In the Article 29 Working Party’s Opinion 1/2010 on the Concepts of Controller and Processor their solution appeared to be to identify key decision making organisations and place particular responsibility on them (see, in particular, Example 15). The GDS Principles envisage an even more distributed system where there are no such key points of control/responsibility, so instead propose an Ombudsman (or Ombudsmen!) who can require participants to deal with problems. Research and Education systems tend, again, to rely on the close relationship between the user and their “home” organisation and the shared interest they are presumed to have in resolving problems.

The final Principle covers “Exceptional Circumstances”, where processing may take place that is not in accordance with the Principles. This will only be permitted if the processing is authorised by legislation (since the commentary mentions “Parliamentary Scrutiny” I’m not sure whether the intention is to limit this to primary legislation), is linked to one of the justifications for privacy invasion contained in Article 8(2) of the European Convention on Human Rights, and is subject to a Privacy Impact Assessment by all relevant Data Controllers (it’s not clear what will happen if those data controllers do not agree that the Impact is proportionate!). The authors note that law enforcement powers are likely to involve Exceptional Circumstances; another area where problems seem likely is where current powers to disclose information are created by common law, rather than legislation (e.g. Norwich Pharmacal and other production orders). A recent European case has ruled that a Directive requiring information to be kept for law enforcement purposes does not stop that information subsequently being accessed for different purposes under different laws.

Summarising, I don’t think the GDS Principles highlight any new issues that we haven’t considered in designing and linking Research and Education federations. There are some differences between their solutions and ours, but these all seem to arise from the stronger relationship between user and Identity Provider in our case, and the fact that our Identity Providers may also procure services and be authoritative sources of attributes on behalf of their users. Rather than contracts or legal duties arising directly between the user and the service provider, situations such as site licences and professional qualifications mean that service providers often have stronger relationships with the organisation than the individual. In turn, our users have a stronger relationship, and more common interest, with their Identity Providers than the GDS can assume. That gives us alternative ways to protect users’ privacy (one of the main benefits of Federated Access Management is that service providers no longer need to manage accounts and personal details for individual users). However because there may well be no direct contract or legal obligation between the user and service, we have to use a different legal provision (“necessary for the legitimate interests” of the IdP and SP) – which itself contains additional protection of the user’s rights – to justify the personal information that we do process and disclose. Interestingly the new draft Regulation contains a hint of a “contract for the benefit of the individual” (Art 44(1)(c)) which might one day provide a common framework for both types of federated access management system.