- What is a Privacy Impact Assessment?
- What is an RFID Privacy Impact Assessment, and how does it differ from a generic PIA?
- Is there a defined process to follow?
- Are there legal requirements to undertake a PIA?
- Then, why do a PIA?
- What falls within the scope of RFID? I have heard that it does not apply to smart cards and NFC.
- Which organisations should undertake a PIA?
- Who in the organisation should complete the PIA?
- I have heard about different PIA levels. What do these levels mean?
- How can I evaluate the privacy risk of a RFID application?
- Are there any metrics?
- What is Privacy by Design?
What is a Privacy Impact Assessment?
|It is a process for organisations to assess the privacy risks of a given business application. Sometimes such a PIA is focussed on the data protection aspects of the application.|
What is an RFID Privacy Impact Assessment, and how does it differ from a generic PIA?
|An RFID Privacy Impact Assessment considers the RFID system. This includes the RFID technology and the hosted components of the application. An RFID PIA therefore needs to take into account aspects of the RFID tag, the RFID interrogator (or reader), and the communication protocol between the two. A very significant difference between a properly undertaken RFID PIA is that it needs to take into account the privacy exposure of an individual tag holder when it is beyond the physical domain of the RFID operator. Here is a simple example. An organisation assigns ID cards to its employees. On any commuter trip you are likely to see people with these attached to a strap around their necks. With some RFID protocols the tag might still be readable when the employee is travelling to and from work. In an RFID PIA the RFID operator has to assess the risk of such exposure. So an RFID PIA is different from just ensuring that there is no ‘leakage’ of internally held data. The RFID PIA has to assess the risk of a tag being read by devices not controlled by the RFID operator.|
Is there a defined process to follow?
|Yes. This has been introduced in three phases:
1. In May 2009, the European Commission issued a Recommendation on the implementation of privacy and data protection principles in applications supported by radio- frequency identification. A Recommendation is the first legal step to common European law, but itself is legal advice to EU Member States.
2. In January 2011 a Privacy and Data Protection Impact Assessment RFID PIA Framework for RFID Applications, developed by an industry group was endorsed by the European Data Protection Authorities. An abstract of the Final Provision (see below) is that a DPA could expect to see a completed RFID PIA any time from mid-2011.This has rarely happened.
3. While the Framework provided a few procedural rules, it did not address the technical privacy characteristics of RFID technology. The European Commission took further action that resulted in Mandate M/436 Phase 2 being assigned to CEN to prepare a set of European Standards, Technical Specifications and Technical Reports. One of these is EN 16571 Information technology – RFID privacy impact assessment process, which was published in June 2014. This standard provides a clearly defined RFID process. It provides the basic rules that have been incorporated in the CNRFID-CSL RFID PIA software.
Are there legal requirements to undertake a PIA?
|No. The European Commission Recommendation is advice to the EU Member States. The Framework sets out a general commitment for undertaking an RFID PIA as endorsed by the Data Protection Authorities of the Member States. While EN 16571 provides a clearly defined process, and is required to be published in each EU Member State complying with it still remains a voluntary commitment by organisations that have implemented an RFID application.|
Then, why do a PIA?
|The European Commission Recommendation is advice to the EU Member States. The Framework sets out a general commitment for undertaking an RFID PIA as endorsed by the Data Protection Authorities of the Member States. While EN 16571 provides a clearly defined process, and is required to be published in each EU Member State complying with it still remains a voluntary commitment by organisations that have implemented an RFID application.The intention of the Recommendation was to raise awareness of RFID, gain user acceptance of the technology and encourage the take-up of the concept of Privacy by Design . The problem with most technologies is that their adoption is largely unregulated, market driven, and sometimes haphazard. So here are a few reasons why any responsible organisation should undertake an RFID PIA:
• You will gain a better understanding of the RFID system that your organisation is responsible for.
• It will prove that your organisation behaves as a responsible stakeholder and has good governance policies and procedures for RFID privacy.
• The Data Protection Authorities signed up to the RFID PIA Framework, and they are increasingly aware of the existence of EN 16571. If you handle personal identification information and/or personal behaviour information, it might pay to be pro-active and have the privacy facts to hand before any vulnerability is exploited. EN 16571 identities 41 types of data that fall into this category and are known to be encoded in RFID tags.
• There are links between privacy and security, so undertaking an RFID PIA might enlighten you about the security features of the RFID technology that you are using.
• Generally security of a computer system is the responsibility of in-house or external experts. RFID privacy not only impacts the internal systems, but can expose people that hold RFID tags and cards to external threats. The Recommendation and privacy organisations consider that protecting an individual’s privacy beyond the domain of the RFID system is the responsibility of the organisation operating an RFID system. A firewall might help stop the bad guy accessing data from within your organisation, but what happens about data on the tag.
• Undertaking the RFID PIA will increase staff awareness of privacy issues and help them explain your organisation’s policy.
• There are other standards as part of the RFID standards mandate issued by the European Commission. One addresses the need from an emblem to be displayed to indicate that RFID is involved. The emblem will be a clear indicator to anyone that RFID is being used. Another standard requires information to be publicly available about an RFID system. Without undertaking the PIA it is difficult to explain the countermeasures that are used in your application to reduce risk. Will your organisation take the lead in your sector and introduce the emblem and notification based on a sound RFID PIA? Or will you let others expose your application as lacking these badges of a well-designed RFID application?
• The RFID PIA is not a once-only process. It is an opportunity to develop a cost-effective strategy for future privacy enhancements to link i with tag and equipment purchases and systems upgrades.
What falls within the scope of RFID? I have heard that it does not apply to smart cards and NFC.
|Throughout the process from before the Recommendation was published, this has been a topic for discussion. Different people – including experts – define RFID narrowly (excluding smart card and NFC) or more broadly based of the fact that radio frequency is used. The Recommendation is clear, here is a definition:
‘radio frequency identification (RFID)’ means the use of electromagnetic radiating waves or reactive field coupling in the radio frequency portion of the spectrum to communicate to or from a tag through a variety of modulation and encoding schemes to uniquely read the identity of a radio frequency tag or other data stored on it.
EN 16571 adopts the same approach and covers 14 standardised technologies, including those commonly considered as smart card and NFC. It goes further and also addresses any RFID technology that uses any of the agreed frequencies.
Which organisations should undertake a PIA?
The Recommendation specifies that the PIA is to be undertaken by the RFID operator, and defines this as “the natural or legal person … that determines the purpose and means of the RFID application”.
This means that if one organisation is responsible for encoding the tag and others are responsible for RFID data capture, then each organisation has a responsibility for undertaking an RFID PIA. Also bear in mind that different applications may use the tag for different purposes. This will mean that different personal identity and behaviour data type can be involved. Even the data on the tag can be changed, so the RFID operator is responsible for the data on the tag that leaves its operation.
Who in the organisation should complete the PIA?
This is an interesting point and a challenge. Various people in an organisation certainly have an input and responsibility: privacy officer, IT security experts, and those with general risk management responsibilities.
The challenge is about the level of skill that anyone has about all the details of RFID. By issuing the RFID Standards Mandate, the European Commission recognised that there was a gap in the knowledge even among those implementing RFID systems. EN 16571 and the supporting Technical Reports go a long way to filling the gap, but the challenge still remains with absorbing and understanding the issues. The CNRFID-CSL software complies with EN 16571, taking the user through all the steps of the RFID PIA process to produce internal reports and the required RFID PIA summary that is required for public access.
I have heard about different PIA levels. What do these levels mean?
EN 16571 defines four levels of PIA, which are based on the RFID PIA Framework. Starting from the most stringent these are:
• Level 3, where data that is classed as personal identifier or behaviour is encoded on the RFID tag or card. EN 16571 lists 20 personal identifiers taken for various rules and guidelines on data protection that include date of birth and account details. There are seven data types for behaviour from the same legal sources, including age and religious belief.
• Level 2 is where the personal identifier data or behaviour data is not on the RFID tag but stored elsewhere in the application and can be linked to this from one of the RFID tag identifiers.
• Level 1 is where the RFID tag is carried by, or associated with, an individual, but where personal identifier and behaviour data is not stored on the application or the RFID tag. Remember that many RFID tags have a unique code either as part of the RFID protocol and / or the application.
• Level 0 is where none of the above conditions apply.
The situation changes with the application. A RFID tagged retail product with no more than a serialised product code while in the manufacturing plant or warehouse will probably result in a Level 0 PIA. However, if associated with productivity schemes for those manufacturing or process orders, and link the item to a person then it might even result in a Level 2 PIA being required. If the RFID tag is still in a readable state when it leaves a retail store then a Level 1 PIA is required, assuming that no additional data has been added to the tag.
The easiest way to be certain is to undertake a PIA for any application that is not at Level 0.
Note: The CNRFID-CSL does not address Level 0 applications. The order form for the software provides details of the types of application covered. If in doubt send an e-mail to email@example.com
How can I evaluate the privacy risk of a RFID application?
EN 16571 defines a risk assessment process that takes into account data on the tag, the particular RFID technology and devices being used, and any countermeasures that might be used in the application. The process itself is adapted from well-established security risk assessment procedures and uses some defined metrics . Let’s go through the steps that are set out in the standard, and also show how the CNRFID-CSL software can help:
1. Describe the RFID application. While only you can do this, you might find that the software provides a model for your application. We are working hard to cover more applications.
2. Identify the privacy assets. Risk assessment procedures normally talk of identifying and valuing assets. EN 16571 drills down a bit lower and considers particular data types. You need to identify the data on the tag and on the application. The type of data together with the place it is stored, determines the PIA Level that needs to be undertaken. The software presents each data type with the guideline value from EN 16571. Moreover it automatically defines the PIA level from the data that you state is on the tag and on the application. It uses this information behind the scenes in the subsequent steps.
3. Identify and evaluate the RFID and application threats. EN 16571 describes 40 threats. If you do this yourself, you need to consider, for example, whether a side channel attack or exhausting protocol resources are threats that need to be considered for your application. The CNRFID-CSL software is delivered with the relevant threats for the technology that you are using. It also has appropriate threat scores.
4. Assess the vulnerability of each threat. When EN 16571 was being developed there was little existing research on the extent that particular RFID threats were being implemented. The decision was made, and accepted by the European National Standards Bodies, that if a threat was demonstrated as being possible to exploit then it was assessed as having a medium vulnerability. Those familiar with IT computer vulnerability scoring methods will be aware that this is a very crude method, but it is better than nothing. The next level up is a real world exploit. CNRFID-CSL is continually monitoring this and will adjust the vulnerability level after discussions with relevant authorities. All the vulnerability scoring is built into the software.
5. Calculate the risk value for the application. This is a process that can be quite time-consuming even if you design your own spreadsheet, which of course takes time in itself. The CNRFID-CSL software will do this in a fraction of the time, but this is because the software has all the rules for doing the calculations. At the end of this step you have calculated the initial risk.
6. Select the countermeasures. EN 16571 identifies 49 countermeasures. Knowing if a particular countermeasure is relevant to your application is the challenge that you face. The CNRFID-CSL software does this for you in two steps. First it uses details of the products that you say you are using and identifies which countermeasures are possible to implement. Next it presents these in a way that aligns with the PIA level required for your application. All you have to do is declare which ones you have used in your application. Countermeasures are the way that you can demonstrate that you are taking RFID privacy seriously. Because this is so important, we are continually looking for countermeasures that can be applied and will update you of these as part of the software support service.
7. Determine the residual risk. If you do this yourself you might have an extensive spreadsheet with all the threats on one axis and the countermeasures on another. Even narrowing this down to what is relevant to your application will still be quite a task. In contrast, the software not only calculates an overall risk score for the application but calculates the residual risk based on the fact that some countermeasures can reduce the risk of more than one threat.
8. At this point you decide whether the risk is low enough, or you start the process again. Because the software retains your input, you can save a lot of time on re-running the PIA process. When you are satisfied, you have reached Step 8, where you accept the residual risk.
9. Complete and endorse the PIA report. The report is an internal document and the previous steps will indicate future actions that you might take that will improve the privacy of your RFID application, e.g. the introduction of some additional countermeasures. Because the software can be shared internally, anyone with access to it can contribute to the plan and the relevant management can endorse the PIA.
10. Complete and endorse the PIA summary. This is the document that needs to be published to show staff, customers, users and the data protection authority details of the data used in the RFID application, the countermeasures that you have applied, and the residual risk. The version produced by the software needs to be considered the master version. As you might want to present this in a style that suits your organisation, there are different export options.
Are there any metrics?
Yes. The risk assessment process defined in EN 16571 results in a risk score that can range from 0 to 8. The standard does not define a target value, but leaves this decision to the RFID operator. Once a number of users have carried out the PIA there might be some typical values for a class of application. However there are many variables.
The individual metrics are straightforward:
• Data types (and therefore the assets) have a value in the range 0 to 4 – with the guideline values specified in the standard.
• Threats are defined as low, medium, or high. Converted to numbers this is 0 to 2. The threat score is added to the asset value.
• Vulnerabilities are also defined as low, medium, or high. Converted to numbers this is 0 to 2. The vulnerability score is added to the asset value and threat score.
• Assume the highest value asset, the worst threat, and highest vulnerability and you get 4 + 2 + 2 = 8.
• The initial risk is reduced if an individual holds the RFID tagged item for a short period of time, based on rules defined in EN 16571.
• Countermeasures are applied to specific threats and can reduce the initial risk score by 1 or even reduce it to zero, when all the risks have been eliminated.
What is Privacy by Design?
|To quote Dr. Ann Cavoukian, Information & Privacy Commissioner, Ontario, Canada, “Privacy by Design is a concept I developed back in the 90’s, to address the ever-growing and systemic effects of Information and Communication Technologies, and of large-scale networked data systems. Privacy by Design advances the view that the future of privacy cannot be assured solely by compliance with regulatory frameworks; rather, privacy assurance must ideally become an organization’s default mode of operation.”
As the statement shows, Privacy by Design is often misunderstood as only requiring privacy features to be built into the technology, in this case RFID tags, interrogators and protocols. While such features exist in varying degrees in different RFID technologies (yes we are talking in the plural here and even ISO has over a dozen different standards in place), the emphasis that should be stressed is on the privacy aspects of the complete RFID system. Here is a simple example of not taking into account the complete system. RFID tags and RFID interrogators are different devices that have to conform to a common protocol, otherwise the system does not work. A tag might support an optional privacy feature – RFID has many optional features – but if the interrogator does not, then such a feature cannot enhance privacy. As EN 16751 shows, Privacy by Design needs to be applied to all the layers in an RFID system to achieve the appropriate level of privacy