i-scope privacy security policies draftv02 - cordis · work!package! wp3$%$smart$services$ task!...

Deliverable’s Title

of 55

CIP-‐ICT-‐PSP-‐2011-‐5 – 297284

i-‐SCOPE

Interoperable Smart City services through an Open Platform for urban Ecosystems

D.03.03 -‐ Privacy and security policies

PIA and TVRA Steps 2, 8, 10

WP 3 – Smart services T.3.3 -‐ Privacy and security policies


of 55

Work package WP3 -‐ Smart services

Task T.3.3 Privacy and security policies

Dissemination level PU (public)

Contributor(s) C3L

Reviewer(s) Name (Institution)

Editor(s) Scott Cadzow (C3L)

Partner in charge(s) C3L

Due date M15 (latest 15th April 2013)

Submission Date Xxxxxxxxxxxxxxxxxxx


of 55

Table of contents Table of contents ........................................................................................................... 3

Acronyms ....................................................................................................................... 5

Definitions ...................................................................................................................... 8

References ................................................................................................................... 25

1 Purpose of the document .................................................................................. 27

2 What is policy in i-‐SCOPE? ................................................................................. 27

2.1 General definition .......................................................................................... 27 2.2 Novelty in policy statements in i-‐SCOPE ........................................................ 28

2.2.1 Test structures in policy statements .................................................... 28 2.2.2 The role of ExTRA in policy statements ............................................... 28

2.3 ITSec and Common Criteria ........................................................................... 29 2.4 Architecture of privacy and security in i-‐SCOPE ............................................ 30 2.5 Data collection in support of DP&P compliance ............................................ 32

3 Actors, roles and responsibilities in i-‐SCOPE ...................................................... 33

3.1 Policy to assure non-‐discriminatory practice ................................................. 33

4 Objectives for privacy and security protection .................................................. 36

4.1 Identity management .................................................................................... 36 4.2 Objectives from D01.03 as policy seeds ........................................................ 37

4.2.1 Privacy and Data Protection ................................................................ 37 4.2.2 Confidentiality ..................................................................................... 40 4.2.3 Integrity ............................................................................................... 40 4.2.4 Availability ........................................................................................... 40 4.2.5 Accountability ...................................................................................... 41 4.2.6 Authenticity ......................................................................................... 41

5 CC functional capabilities to be supported resulting from i-‐SCOPE policy ........ 43

5.1 Identification and authorisation capabilities ................................................. 43 5.2 Confidentiality capabilities ............................................................................ 46 5.3 Integrity capabilities ...................................................................................... 46 5.4 Non-‐repudiation capabilities ......................................................................... 46

6 Policy derived from TRUSTe Program ................................................................ 48

6.1 Rationale for using the TRUSTe program ....................................................... 48

7 ExTRA file for i-‐SCOPE policy statements ........................................................... 49

8 OAuth 2.0 as target for authentication and authorisation model ..................... 50

9 DP&P compliance policy example text .............................................................. 52

9.1 Overview ........................................................................................................ 52


of 55

9.2 General feelgood statement of intent ........................................................... 52 9.3 Statement regarding the information collected ............................................ 52 9.4 Statement regarding provision of Data Security measures ........................... 53 9.5 Statement regarding protection of children and "at risk" groups ................. 53 9.6 Statement regarding access to information .................................................. 53 9.7 Statement regarding contact and liability ...................................................... 53

10 Anti-‐discrimation policy example text ............................................................... 54

11 INDEX ................................................................................................................. 55


of 55

Acronyms API Application Programming Interface

CA Consortium Agreement

CAP Composed Assurance Package

CC Common Criteria

CCRA Arrangement on the Recognition of Common Criteria Certificates in the field of IT Security

CIAAA Confidentiality Integrity Availability Authenticity Accountability

CM Configuration Management

DAC Discretionary Access Control

DDoS Distributed Denial of Service

DM Data Manager

DoS Denial of Service

DoW Description of Work

EAL Evaluation Assurance Level

ESO European Standards Organisations

ETSI European Telecommunications Standardisation Institute

ExTRA Extensible notation for Test purposes, Requirements and Assertions

GA Grant Agreement

GA General Assembly

GHz Gigahertz

GIS Geographical Information Systems

GUI Graphical User Interface


of 55

IC Integrated Circuit

IOCTL Input Output Control

IP Internet Protocol

IT Information Technology

MB Mega Byte

NGN Next Generation Network

OM Operational Manager

OS Operating System

OSP Organisational Security Policy

PC Project Coordinator

PC Personal Computer

PCI Peripheral Component Interconnect

PIA Privacy Impact Assessment

PKI Public Key Infrastructure

PP Protection Profile

QRM Quality and Risk Manager

RAM Random Access Memory

RFID Radio Frequency Identification

RPC Remote Procedure Call

SAML Security Assertion Markup Language

SAR Security Assurance Requirement

SB Stakeholders Board

SFP Security Function Policy

SFR Security Functional Requirement


of 55

SPD Security Problem Definition

ST Security Target

TB Technical Board

TCP Transmission Control Protocol

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking

TL Task Leader

TOE Target of Evaluation

TPlan Test Purpose language

i-‐SCOPE system

TOE Security Functionality

i-‐SCOPE systemI

i-‐SCOPE system Interface

TVRA Threat Vulnerability Risk Analysis

UIM Urban Information Model

UML Unified Modeling Language

VPN Virtual Private Network

WPL Work Package Leader

XACML eXtensible Access Control Markup Language


of 55

Definitions acceptance criteria criteria to be applied when performing

the acceptance procedures (e.g. successful document review, or successful testing in the case of software, firmware or hardware)

acceptance procedures procedures followed in order to accept newly created or modified configuration items as part of the TOE, or to move them to the next step of the life-‐cycle

administrator entity that has a level of trust with respect to all policies implemented by the i-‐SCOPE system

adverse actions actions performed by a threat agent on an asset

assets entities that the owner of the TOE presumably places value upon

assignment the specification of an identified parameter in a component (of the CC) or requirement

assurance grounds for confidence that a TOE meets the SFRs

attack potential measure of the effort to be expended in attacking a TOE, expressed in terms of an attacker's expertise, resources and motivation

augmentation addition of one or more requirement(s) to a package

authentication data information used to verify the claimed identity of a user

authorised user TOE user who may, in accordance with the SFRs, perform an operation


of 55

base component entity in a composed TOE, which has itself been the subject of an evaluation, providing services and resources to a dependent component

Behavioral Targeting the collection and use of information on an Individual's Online activity over a period of time for the purpose of developing and using predictive models to determine potential future behavior or interests.

call tree identifies the modules in a system in diagrammatic form showing which modules call one another

class set of CC families that share a common focus

Clear and Conspicuous a notice that is reasonably easy to find, and easily understandable in terms of content and style to the average reader.

CM documentation all CM documentation including CM output, CM list (configuration list), CM system records, CM plan and CM usage documentation

coherent logically ordered and having discernible meaning For documentation, this addresses both the actual text and the structure of the document, in terms of whether it is understandable by its target audience.

cohesion module strength manner and degree to which the tasks performed by a single software module are related to one another coincidental cohesion module with the characteristic of performing unrelated, or loosely related, activities communicational cohesion module containing functions that produce output for, or use output from, other functions within the module


of 55

compatible (components) property of a component able to provide the services required by the other component, through the corresponding interfaces of each component, in consistent operational environments

complete property where all necessary parts of an entity have been provided In terms of documentation, this means that all relevant information is covered in the documentation, at such a level of detail that no further explanation is required at that level of abstraction.

complexity measure of how difficult software is to understand, and thus to analyse, test, and maintain

component smallest selectable set of elements on which requirements may be based

component TOE successfully evaluated TOE that is part of another composed TOE

composed assurance package assurance package consisting of requirements drawn from CC Part 3 (predominately from the ACO class), representing a point on the CC predefined composition assurance scale

composed TOE TOE comprised solely of two or more components that have been successfully evaluated

configuration item object managed by the CM system during the TOE development

configuration list configuration management output document listing all configuration items for a specific product together with the exact version of each configuration management item relevant for a specific version of the complete product


of 55

configuration management discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.

configuration management evidence everything that may be used to establish confidence in the correct operation of the CM system

configuration management output results, related to configuration management, produced or enforced by the configuration management system

configuration management plan description of how the configuration management system is used for the TOE

configuration management system set of procedures and tools (including their documentation) used by a developer to develop and maintain configurations of his products during their life-‐cycles

configuration management system records output produced during the operation of the configuration management system documenting important configuration management activities

configuration management tools manually operated or automated tools realising or supporting a configuration management system

configuration management usage documentation

part of the configuration management system, which describes, how the configuration management system is defined and applied by using for example handbooks, regulations and/or documentation of tools and procedures

confirm declare that something has been reviewed in detail with an independent determination of sufficiency

connectivity property of the TOE allowing interaction with IT entities external to the TOE

consistent relationship between two or more entities such that there are no apparent contradictions between these entities


of 55

counter, verb meet an attack where the impact of a particular threat is mitigated but not necessarily eradicated

coupling manner and degree of interdependence between software modules common coupling relationship between two modules sharing a common data area or other common system resource content coupling relationship between two modules where one makes direct reference to the internals of the other

covert channel enforced, illicit signalling channel that allows a user to surreptitiously contravene the multi-‐level separation policy and unobservability requirements of the TOE

delivery transmission of the finished TOE from the production environment into the hands of the customer

demonstrable conformance relation between an ST and a PP, where the ST provides a solution which solves the generic security problem in the PP

demonstrate provide a conclusion gained by an analysis which is less rigorous than a “proof”

dependency relationship between components such that if a requirement based on the depending component is included in a PP, ST or package, a requirement based on the component that is depended upon must normally also be included in the PP, ST or package

dependent component entity in a composed TOE, which is itself the subject of an evaluation, relying on the provision on services by a base component

describe provide specific details of an entity


of 55

determine affirm a particular conclusion based on independent analysis with the objective of reaching a particular conclusion

developer organisation responsible for the development of the TOE

development product life-‐cycle phase which is concerned with generating the implementation representation of the TOE

development environment environment in which the TOE is developed

development tools tools (including test software, if applicable) supporting the development and production of the TOE

domain separation security architecture property whereby the i-‐SCOPE system defines separate security domains for each user and for the i-‐SCOPE system and ensures that no user process can affect the contents of a security domain of another user or of the i-‐SCOPE system

element indivisible statement of a security need

encountered potential vulnerabilities potential weakness in the TOE identified by the evaluator while performing evaluation activities that could be used to violate the SFRs

ensure guarantee a strong causal relationship between an action and its consequences

evaluation assessment of a PP, an ST or a TOE, against defined criteria

evaluation assurance level set of assurance requirements drawn from CC Part 3, representing a point on the CC predefined assurance scale, that form an assurance package


of 55

evaluation authority body that sets the standards and monitors the quality of evaluations conducted by bodies within a specific community and implements the CC for that community by means of an evaluation scheme

evaluation scheme administrative and regulatory framework under which the CC is applied by an evaluation authority within a specific community

exhaustive characteristic of a methodical approach taken to perform an analysis or activity according to an unambiguous plan

explain give argument accounting for the reason for taking a course of action

exploitable vulnerability weakness in the TOE that can be used to violate the SFRs in the operational environment for the TOE

Expressed Consent The affirmative consent (opt-‐in) to a practice by the Individual, after being provided notice, but prior to implementing the practice,

extension addition to an ST or PP of functional requirements not contained in CC Part 2 and/or assurance requirements not contained in CC Part 3

external entity human or IT entity possibly interacting with the TOE from outside of the TOE boundary

family set of components that share a similar goal but differ in emphasis or rigour

Foreign Language Privacy Statement the Participant's Privacy Statement translated into a language other than English.

formal expressed in a restricted syntax language with defined semantics based on well-‐established mathematical concepts


of 55

functional cohesion functional property of a module which performs activities related to a single purpose A functionally cohesive module transforms a single type of input into a single type of output, such as a stack manager or a queue manager.

functional interface external interface providing a user with access to functionality of the TOE which is not directly involved in enforcing security functional requirements

Geo-‐location Data information obtained through an Individual's use of a Mobile Device and is used to identify or describe the Individual's actual physical location at a given point in time.

guidance documentation documentation that describes the delivery, preparation, operation, management and/or use of the TOE

identity representation uniquely identifying entities (e.g. a user, a process or a disk) within the context of the TOE

implementation representation least abstract representation of the i-‐SCOPE system, specifically the one that is used to create the i-‐SCOPE system itself without further design refinement Source code that is then compiled or a hardware drawing that is used to build the actual hardware are examples of parts of an implementation representation.

Individual the discrete person to whom the collected information pertains.

Inferred Consent consent which is implied by an Individual, regarding the collection, use, disclosure, distribution of PII after notice and opportunity to withdraw consent (opt-‐out) is given by Participant, but not taken by the Individual.


of 55

informal expressed in natural language

installation procedure performed by a human user embedding the TOE in its operational environment and putting it into an operational state

inter i-‐SCOPE system transfers communicating data between the TOE and the security functionality of other trusted IT products

interaction general communication-‐based activity between entities

interface means of interaction with a component or module

internal communication channel communication channel between separated parts of the TOE

internal TOE transfer communicating data between separated parts of the TOE

internally consistent no apparent contradictions exist between any aspects of an entity

i-‐SCOPE system data data for the operation of the TOE upon which the enforcement of the SFR relies

i-‐SCOPE system interface means by which external entities (or subjects in the TOE but outside of the i-‐SCOPE system) supply data to the i-‐SCOPE system, receive data from the i-‐SCOPE system and invoke services from the i-‐SCOPE system

i-‐SCOPE system self-‐protection security architecture property whereby the i-‐SCOPE system cannot be corrupted by non-‐i-‐SCOPE system code or entities

iteration use of the same component to express two or more distinct requirements

justification analysis leading to a conclusion


of 55

layering design technique where separate groups of modules (the layers) are hierarchically organised to have separate responsibilities such that one layer depends only on layers below it in the hierarchy for services, and provides its services only to the layers above it. Strict layering adds the constraint that each layer receives services only from the layer immediately beneath it, and provides services only to the layer immediately above it.

life cycle model description of the stages and their relations to each other that are used in the management of the life-‐cycle of a certain object, how the sequence of stages looks like and which high level characteristics the stages have

life-‐cycle sequence of stages of existence of an object (for example a product or a system) in time

life-‐cycle definition definition of the life-‐cycle model

logical cohesion procedural cohesion characteristics of a module performing similar activities on different data structures

Material Change degradation in the rights or obligations regarding the collection, use, or disclosure of PII for an Individual. This usually includes changes to Participant's:

1. Practices regarding notice, collection, use, and disclosure of PII and/or Third Party Personally Identifiable Information;

2. Practices regarding user choice and consent to how PII and/or Third Party Personally Identifiable Information is used and shared; or

3. Measures for information


of 55

security, integrity, access, or individual redress.

Mobile Device a portable electronic geo-‐location enabled device which allows the user to process, receive, and send data without being limited to a specific geographical location.

modular decomposition process of breaking a system into components to facilitate design, development and evaluation

monitoring attacks generic category of attack methods that includes passive analysis techniques aiming at disclosure of sensitive internal data of the TOE by operating the TOE in the way that corresponds to the guidance documents

non-‐bypassability (of the i-‐SCOPE system) security architecture property whereby all SFR-‐related actions are mediated by the i-‐SCOPE system

object passive entity in the TOE, that contains or receives information, and upon which subjects perform operations

Online the state where an Individual is connected by computer or Mobile Device to one or more other computers, Mobile Devices, or networks, as through a commercial electronic information service or the internet.

operation usage phase of the TOE including “normal usage”, administration and maintenance of the TOE after delivery and preparation

operation (on a component of the CC) modification or repetition of a component

operation (on an object) specific type of action performed by a subject on an object


of 55

operational environment environment in which the TOE is operated

organisational security policy set of security rules, procedures, or guidelines for an organisation

package named set of either security functional or security assurance requirements

Personally Identifiable Information [PII] any information or combination of information that can be used to identify, contact, or locate a discrete Individual.

potential vulnerability suspected, but not confirmed, weakness preparation activity in the life-‐cycle phase of a

product, comprising the customer's acceptance of the delivered TOE and its installation which may include such things as booting, initialisation, start-‐up and progressing the TOE to a state ready for operation

Primary Purpose use of PII that is reasonably expected by the Individual (i) at the point of collection; and (ii) including compatible uses in features and services to the Individual that do not materially change expectations of user control and third party sharing. Such use may be at least those uses described in the Participant's terms of service governing the Participant's products or services which give rise to the Individual's interaction with the Participant.

Privacy Statement the statements of Participant's information collection and usage practices, as such practices are updated from time to time. Participant's Privacy Statement includes, but is not limited to:

1. A single, comprehensive statement of all the Participant's information practices ("Comprehensive Privacy Statement");

2. A summary notice highlighting


of 55

the Participant's information practices ("Short Notice"); or

3. 3. Disclosure of specific information practices posted at the point of information collection ("Just in Time Notice").

production production life-‐cycle phase follows the development phase and consists of transforming the implementation representation into the implementation of the TOE, i.e. into a state acceptable for delivery to the customer

Protection Profile implementation-‐independent statement of security needs for a TOE type

Protection Profile evaluation assessment of a PP against defined criteria

prove show correspondence by formal analysis in its mathematical sense

Publicly Available Information [PAI] any information reasonably believed to be lawfully made available to the general public from:

residual vulnerability weakness that cannot be exploited in the operational environment for the TOE, but that could be used to violate the SFRs by an attacker with greater attack potential than is anticipated in the operational environment for the TOE

role predefined set of rules establishing the allowed interactions between a user and the TOE

Secondary Purpose the use of PII in a way that is not reasonably expected by the Individual relative to the transactions or ongoing services provided to the Individual by Participant or the Participant's Service Provider. Such purpose may or may not be described by Participant's terms of service governing Participant's products


of 55

or services which give rise to the Individual's interaction with the Participant

secret information that must be known only to authorised users and/or the i-‐SCOPE system in order to enforce a specific SFP

secure state state in which the i-‐SCOPE system data are consistent and the i-‐SCOPE system continues correct enforcement of the SFRs

security attribute property of subjects, users (including external IT products), objects, information, sessions and/or resources that is used in defining the SFRs and whose values are used in enforcing the SFRs

security domain collection of resources to which an active entity has access privileges

security function policy set of rules describing specific security behaviour enforced by the i-‐SCOPE system and expressible as a set of SFRs

security objective statement of an intent to counter identified threats and/or satisfy identified organisation security policies and/or assumptions

security problem statement which in a formal manner defines the nature and scope of the security that the TOE is intended to address

security requirement requirement, stated in a standardised language, which is meant to contribute to achieving the security objectives for a TOE

Security Target implementation-‐dependent statement of security needs for a specific identified TOE


of 55

selection specification of one or more items from a list in a component

semiformal expressed in a restricted syntax language with defined semantics

sequential cohesion module containing functions each of whose output is input for the following function in the module

Service Provider anyone other than the Participant or the Individual that performs, or assists in the performance of, a function or activity which may involve the use or disclosure of PII or Third Party PII. Such use must only be on behalf of Participant or Individual and only for the purpose of performing or assisting in that specific function or activity as agreed to by the Participant and Individual.

specify provide specific details about an entity in a rigorous and precise manner

strict conformance hierarchical relationship between a PP and an ST where all the requirements in the PP also exist in the ST This relation can be roughly defined as “the ST shall contain all statements that are in the PP, but may contain more”. Strict conformance is expected to be used for stringent requirements that are to be adhered to in a single manner.

subject active entity in the TOE that performs operations on objects

target of evaluation set of software, firmware and/or hardware possibly accompanied by guidance

temporal cohesion characteristics of a module containing functions that need to be executed at about the same time

Third Party Personally Identifiable PII that is collected by Participant from an


of 55

Information [Third Party PII] entity other than the Individual

Third Party(ies) an entity(ies) other than the Participant or the Individual which is not directly affiliated with the Participant; and, if affiliated with the Participant, where such affiliation is not reasonably known to the Individual.

threat agent entity that can adversely act on assets

TOE evaluation assessment of a TOE against defined criteria

TOE resource anything useable or consumable in the TOE

TOE security functionality combined functionality of all hardware, software, and firmware of a TOE that must be relied upon for the correct enforcement of the SFRs

transfers outside of the TOE i-‐SCOPE system mediated communication of data to entities not under the control of the i-‐SCOPE system

trusted channel a means by which a i-‐SCOPE system and another trusted IT product can communicate with necessary confidence

trusted IT product IT product, other than the TOE, which has its security functional requirements administratively coordinated with the TOE and which is assumed to enforce its security functional requirements correctly

trusted path means by which a user and a i-‐SCOPE system can communicate with the necessary confidence

user data data for the user, that does not affect the operation of the i-‐SCOPE system

verify rigorously review in detail with an independent determination of sufficiency


of 55

vulnerability weakness in the TOE that can be used to violate the SFRs in some environment


of 55

References 1 ETSI TS 102 165-‐1: "Telecommunications and Internet converged Services

and Protocols for Advanced Networking (TISPAN); Methods and protocols; Part 1: Method and proforma for Threat, Risk, Vulnerability Analysis"

2 ETSI TR 187 020: "Radio Frequency Identification (RFID); Coordinated ESO response to Phase 1 of EU Mandate M436"

3 ETSI TR 187 011: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Security; Application of ISO-‐i-‐SCOPE system-‐2 requirements to ETSI standards -‐ guide, method and application with examples"

4 ISO/IEC 15408-‐2: "Information technology -‐ Security techniques -‐ Evaluation criteria for IT security -‐ Part 2: Security functional requirements"

5 ETSI EG 202 387: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Security Design Guide; Method for application of Common Criteria to ETSI deliverables"

6 Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data.

7 i-‐SCOPE project – Description of Work (DoW) 8 ETSI TR 187 010: "Telecommunications and Internet converged Services and

Protocols for Advanced Networking (TISPAN); NGN Security; Report on issues related to security in identity management and their resolution in the NGN".

9 Universal Declaration of Human Rights: http://www.un.org/en/documents/udhr/

10 Directive 2002/58/EC of the European Parliament and of the council of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications).

11 Recommendation of the OECD Council in 1980 concerning guidelines governing the protection of privacy and transborder flows of personal data (the OECD guidelines for personal data protection).

11 ISO/IEC 27000 (2009): "Information technology -‐ Security techniques -‐ Information security management systems -‐ Overview and vocabulary".

12 ISO/IEC 27001 (2005): "Information technology -‐ Security techniques -‐ Information security management systems -‐ Requirements".

13 ISO/IEC 13335: "Information technology -‐ Security techniques -‐ Guidelines for the management of IT security".

14 Article 29 Data Protection Working Party Opinion 5/2010 on the Industry Proposal for a Privacy and Data Protection Impact Assessment Framework for RFID Applications.


of 55

15 EUROPEAN DATA PROTECTION SUPERVISOR, Opinion of the European Data Protection Supervisor on the communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions on "Radio Frequency Identification (RFID) in Europe: steps towards a policy framework" COM(2007) 96, 2008/C 101/01.

16 i-‐SCOPE; Interoperable Smart City services through an Open Platform for urban Ecosystems; Deliverable D1.4; System architecture

17 ARTICLE 29 Data Protection Working Party: Opinion 13/2011 on Geolocation services on smart mobile devices; Adopted on 16 May 2011

18 Privacy Impact Assessment Handbook v2 Available from: http://www.ico.gov.uk/upload/documents/pia_handbook_html_v2/files/PIAhandbookV2.pdf

19 European Convention on Human Rights as amended by Protocols Nos. 11 and 14; Council of Europe Treaty Series, No. 5

20 i-‐SCOPE; Interoperable Smart City services through an Open Platform for urban Ecosystems; Deliverable D01.1 "Use Case Analysis and User Requirements"

21 ETSI 202 533: "Methods for Testing and Specification (MTS); TPLan: A notation for expressing Test Purposes"

22 i-‐SCOPE deliverable D01.03 (TVRA)


of 55

1 Purpose of the document

This document is a report on the privacy and security policies related to i-‐SCOPE services and client technologies taking into account issues related to the localisation of people, their preferences, etc. that need to be implemented in the overall system to give sufficient assurance to users of the system that their privacy and security is adequately managed. The document extends from D01.03 of the i-‐SCOPE project and re-‐assesses the results from the initial PIA and TVRA to address, specifically, the policies that have to be implemented by the pilot partners as a framework for the specific countermeasures that will be described in detail in i-‐SCOPE deliverable T04.08.

The document applies the paradigms Privacy by Design and Design for Assurance to the policy framework that underlies the overall security and privacy protection framework of i-‐SCOPE. It also introduces a novel approach to the writing of policies for distributed multi-‐stakeholder systems with the characteristic that relationships established between stakeholders (and/or their network representations) are transitional with strict temporal and locational significance.

2 What is policy in i-‐SCOPE?

2.1 General definition

Policy acts as a framework element that guides expectation and defines responsibility. The practical impact of policy is that where a policy exists it defines the parties it affects, the context in which it applies, the consequences and value of the policy, and the penalties for breaching the policy.

By its nature a policy is political thus policies in general cannot be correct but support a particular view of how a system is to work. Thus a general policy statement may be that "the i-‐SCOPE system will not gather data for sale or distribution to 3rd parties". Whilst this is a common system policy construct found in a wide range of web services, for i-‐SCOPE this policy misses a number of key elements that make it impractical for large scale distributed systems due in the main to the loose definition of the system, of 3rd parties, and what is meant by gathering.


of 55

2.2 Novelty in policy statements in i-‐SCOPE

2.2.1 Test structures in policy statements

The novelty in i-‐SCOPE is to recognize that in distributed systems and what we refer to as the cloud there may be no easily pre-‐determined relationship between parties that are covered by the policy. Thus rather than having policies as long legal documents requiring detail reading prior to accepting and asking the system to do something it is proposed that policy statements are short, sharp, machine processable statements with a fully defined syntax.

The syntax and thus the structure of i-‐SCOPE's policy statements are to be written in the ETSI standardized notation ExTRA which is a development of the earlier notation TPLan (ETSI 202 533: "Methods for Testing and Specification (MTS); TPLan: A notation for expressing Test Purposes" [21]). The structure of precondition-‐stimulus-‐response is reconsidered as context and actors, action of the actors, and how the system will respond. The input to the policy engine is the set of objectives identified in the TVRA (i-‐SCOPE's deliverable D01.03 [22]).

It is proposed in the present document to show the role of ExTRA as the notation to express statements of objectives as policy statements. The rationale is that policies are statements of intent and so are objectives thus the rules for constructing objectives, e.g. those defined in ETSI TR 187 010 [8], apply to policy statements too. The ExTRA statements in the present document are indicative only as the detail implementation is an exercise for i-‐SCOPE WP4.

A second novelty is that policy statements, in the security and privacy protection domain at least, are written with a target of functional capabilities as described in ISO/IEC 15408-‐2 [4]. What this means is that a policy that the system shall not provide service before the requesting party has been successfully identified and authenticated is to be written using the capabilities of ISO/IEC i-‐15404-‐2's functional class Identification and Authentication.

It is further proposed that every policy statement can be externally validated to determine if the web service offered complies to specific requirements. This is also one of the reasons for the use of ExTRA (see 2.2.2 below) to specify policy statements as it allows the policy to be tested by ensuring each policy statement becomes a rule that can be implemented in software and tested procedurally.

2.2.2 The role of ExTRA in policy statements

The current draft of ExTRA identifies 3 types of ExTRA specification types: Requirements; Assertions; Test Suite Structure (containing test purposes), where for


of 55

the purposes of i-‐SCOPE the policies are of the form Requirements and each policy is structured following the basic structure of ExTRA statements given below.

with { ... } -- preconditions

ensure that {

when { ... } -- stimuli

then { ... } -- responses and other behaviour

}

The extensibility of ExTRA is used to define the i-‐SCOPE entities, actors and capabilities, along with grouping of policies in specific groups. The further extension of ExTRA to describe the Common Criteria's functional capabilities and thus the requirements of i-‐SCOPE will be explored further in the course of WP4.

Consistent with the aims in §2.2 and §2.3 it is proposed to also use ExTRA to tie policy and functional capability. This requires that part of the activity in preparing the present document has been to prepare the functional capabilities from ISO/IEC 15408-‐2 as ExTRA statements.

NOTE: As part of the validation of this approach work in parallel to the development of ExTRA in ETSI's MTS committee has been undertaken to write the ETSI TS 187 003 and ETSI TS 187 002 specifications using this approach and to submit them to ETSI TC NTECH for approval.

2.3 ITSec and Common Criteria

The guiding principle for the processing in i-‐SCOPE is that the Personal Identifying Information (PII) in the system is protected from unlawful or unconsented processing. Their processing is subject to the principles enshrined in Directive 95/46/EC [6] on the protection of personal data and Directive 2002/58/EC [10] which require that personal data are processed with the explicit and informed consent of the user.

Key to the understanding of the Data Protection and Privacy (DP&P) legislation is the relationship between, and identification of, each of the data subject, data processor and data controller. Legally it is the data controller who establishes the policy and the data processor that enacts the policy where the data subject has given the necessary explicit and informed consent. In systems such as i-‐SCOPE there is a continuous movement of data which is augmented, modified, re-‐scoped, re-‐owned and for which the jurisdiction is subject to change over time this form of system requires policy to be either agreed for all parties prior to the system being established including any potential extensions to the system and the use to which data is put, or to carry an


of 55

evolving protection relationship. It is this latter approach which is the purpose of the investment made by i-‐SCOPE in policy and covers a set of non-‐repudiation capabilities within the core functional framework of i-‐SCOPE that act as technical instantiations of policy management. Objective DPPO-‐2 (Compliance to the Accountability principle) from D01.03 in fact explicitly states that the data controller is accountable for complying with measures which give effect to the DPP principles and that the data controller is ultimately responsible for the personal data gathered through the application in question.

2.4 Architecture of privacy and security in i-‐SCOPE

The overall means of achieving privacy and security in i-‐SCOPE is to adopt a model of distributed authorities. This model has been adopted in the ITS standards programme and i-‐SCOPE (in common with FP7 projects i-‐Tour and SUNSHINE) is adopting and extending it for the special cases of smart cities and direct citizen input.

The set of authorities is summarized below and between them they offer support to pseudonymity and non-‐repudiation of consent in a distributed processing environment.

• Identification authority

– Manages the i-‐SCOPE user identities and their credentials for authentication

• Authorisation authority

– Manages the access control (RBAC, MAC, TBAC) for any controlled entity in the i-‐SCOPE system

• Consent authority

– Determines and manages how proof of consent is used within access control

– Acts in concert with RBAC and MAC


of 55

Figure 1: i-‐SCOPE's extension of the ITS Security Architeture (from TS 102 940) []

Where the "novelty" of i-‐SCOPE's policy (see §2.2) describes policy using structured statements written in ExTRA (or at least using the planned extension to TPLan) the set of proofs that policy is being followed is achieved using particular functional capabilities described in part 2 of the Evaluation criteria for IT security (commonly referred to as "Common Criteria). Key capabilities for policy management are those capabilities under the title of "non-‐repudiation" services which in the i-‐SCOPE project are extended and used to enforce non-‐repudiation of consent, and non-‐repudiation of processing as well as the basic functions of non-‐repudiation of transmission or reception of information. The former is used to maintain proof in the system that consent was given, whilst the latter is used to maintain proof in the system that processing was carried out. In both cases the audit logs are maintained by trusted 3rd parties and used only in the case of dispute. As the logs themselves are PII they have to be protected from unauthorized disclosure and from tampering which will be achieved by means to be described in WP4 of the i-‐SCOPE project.

Maintaining the security level over time entails continual adaptation to the progress of Information Technologies (IT). A relatively high level of security is indeed necessary to make unauthorised changes to recorded data impossible without trace (integrity), to identify unequivocally the origin of data and to ensure that data are always available when needed/requested. What was considered state of the art previously and which were hard to attack several years ago become easier to crack now as IT becomes more and more developed and sophisticated.


of 55

NOTE: Recent changes recommended for Common Criteria have suggested that EALs are deprecated and replaced by a different measure assessing the strength of design to provide security across a wide range of attributes. The new instrument, for Commercial Off The Shelf (COTS) devices and systems in the main, will be the Community Protection Profile (cPP) which will be open to development by a wider community of experts. Whilst the cPP process is not completely defined it is expected that standards development organisations such as ISO, CEN, CENELEC and ETSI may be authorized to prepare and publish cPPs.

i-‐SCOPE will work with relevant parties in the Common Criteria and Standards Development Organisations (SDOs) to try and ensure that the suite of deliverables in the security and privacy protection area developed within the i-‐SCOPE project are as close as possible to the proposed cPPs in structure in order that any future commercialisation of the results from i-‐SCOPE can choose to develop them as formal cPPs for use in system procurement.

2.5 Data collection in support of DP&P compliance

It is necessary to show that an entity the collects data does so in compliance with the DP&P regulation. The entity or action that underpins DP&P is "informed consent" and in addressing this i-‐SCOPE is working with ETSI TC ITS WG5 to add an entity "Consent Authority" to the ITS Security architecture. The detail protocol that acts between the ITS-‐S (which is also the i-‐SCOPE client device) and the Consent Authority is still under development but is being developed based on the protocol model of Obligation of Trust (OoT). In the OoT protocol two parties can exchange difficult-‐to-‐repudiate digitally signed obligating constraints (or Notification of Obligations (NoO) which detail their requirements for sending their sensitive information to the other party), and proof of acceptances (or Signed Acceptance of Obligations (SAO), which acknowledge the conditions they have accepted for receiving the other party’s sensitive information). In common with the approach proposed for the ETSI TC ITS WG5 standardisation effort and with activities being addressed in the FP7 i-‐Tour and SUNSHINE projects the specific model extends OoT concept to encompass "Security Policy Directives" and "Privacy Policy Directives" as instances of the NoO which are distributed and signed by the parties to the privacy (by consent) and security associations resulting in equivalents to the SAO.

The overall result that is achieved is that there will be support for "non-‐repudiation of consent" in which the system and users build a strong proof of having given consent to specific processing of precisely defined data.


of 55

3 Actors, roles and responsibilities in i-‐SCOPE

3.1 Policy to assure non-‐discriminatory practice

In addition to DP&P compliance, and in many views underlying the scope of the DP&P regulations, are a wide ranging set of non-‐discrimination rules that make it illegal (in general as the implementation of and penalties for breaking such rules are not harmonised across the EU) to discriminate against anyone because of:

-‐ age

-‐ being or becoming a transsexual person

-‐ being married or in a civil partnership

-‐ being pregnant or having a child

-‐ disability

-‐ race including colour, nationality, ethnic or national origin

-‐ religion, belief or lack of religion/belief

-‐ sex

-‐ sexual orientation

These are called protected characteristics and are also the set of personal data that have to be protected by DP&P from any disclosure. Protection from discrimination has to be assured in the following situations:

-‐ at work

-‐ in education

-‐ as a consumer

-‐ when using public services

-‐ when buying or renting property

-‐ as a member or guest of a private club or association

Discrimination can come in one of the following forms:

-‐ direct discrimination – treating someone with a protected characteristic less favourably than others


of 55

-‐ indirect discrimination – putting rules or arrangements in place that apply to everyone, but that put someone with a protected characteristic at an unfair disadvantage

-‐ harassment – unwanted behaviour linked to a protected characteristic that violates dignity or creates an offensive environment

-‐ victimisation – treating someone unfairly because they've complained about discrimination or harassment

It can be lawful to have specific rules or arrangements in place, as long as they can be justified.

The terms used in privacy regulation to identify roles and responsibility are transposed in Table 1 to identify the i-‐SCOPE stakeholders that are expected to act with the same role and responsibility.

Table 1: Terms used in privacy regulation and responsible party (stakeholder) in i-SCOPE

DPP role Definition i-SCOPE stakeholder taking role

data controller

natural or legal person, public authority, agency or any other body which alone or jointly with others determines the purposes and means of the processing of personal data

The host (the pilot city government)

data processor

natural or legal person, public authority, agency or any other body which processes personal data on behalf of the controller

The host (the pilot city government) and the set of software they implement.

data subject

person who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity

Citizen

data subject's consent

any freely given specific and informed indication of his wishes by which the data subject signifies his agreement to personal data relating to him being processed

n/a

The i-‐SCOPE model aims to give strong binding of the relationships between each of the DP&P roles in such a way that the data subject (the i-‐SCOPE user) has strong assurance that the data processor (DP) has been authorized by the data controller (DC). What needs to happen is that the DS has confidence (cryptographically this is termed assurance) that the DP is acting in accordance with same set of policies that have been agreed between the DS and DC. This is achieved in a combination of ways:

• A hash of the policy defined by the DC is signed by the DC and distributed to the DS and DP alongside the policy itself (a digital signature).


of 55

o This shows that the DC is the source of the policy o When countersigned by the DS it may be used as proof of acceptance

of the policy. • The DC indicates to the DS those DPs it has authorised to enact the policy

o The model does allow for pseudonymous attachment of DS to the DP (as per the model developed for co-‐operative ITS in ETSI and other standards bodies.

• The DP can create a signed record of the attachment of the DS o This is part of the support for non-‐repudiation of consent as the DP

has agreed to act in accordance with the specific policy on behalf of the specific DS and DC.

In WP4 of the i-‐SCOPE project the actual cryptographic mechanism will be defined as will the detail language of the policy statements.

Figure 2: Alternative sequence for chart for accessing protected object

In Figure 2 an alternative view of the same technical problem is given where the DP and DC entities are reconsidered as policy elements. The DP maps to the Policy

sd Policy sequence

i-SCOPE user

PEP PDP PAP PIPProtected Entity

In access control the architecture consists of 4 elements:⦁ PAP Policy Administration Point -‐ Point which manages

policies⦁ PDP Policy Decision Point -‐ Point which evaluates and

issues authorization decisions⦁ PEP Policy Enforcement Point -‐ Point which intercepts

user's access request to a resource and enforces PDP's decision.

⦁ PIP Policy Information Point -‐ Point which can provide external information to a PDP, such as LDAP attribute information.

Entity Access Request(AuthorisationCredential)

CapturedMessage(Entity Access Request)

ValidationRequest(AuthorisationCredentials)

ValidationConfirm(true_false)

Open()


of 55

Decision Point (point which evaluates and issues authorization decisions) and to the Policy Enforcement Point (point which intercepts user's access request to a resource and enforces PDP's decision). The DC in turn maps to the Policy Administration Point (point which manages policies) and the Policy Information Point (point which can provide external information to a PDP).

4 Objectives for privacy and security protection

4.1 Identity management

Identity management for the security and privacy domain is closely related to the crime of identity theft and in particular the ability of a user to masquerade as another user and to perform actions in their name that lead to some form of loss (e.g. of reputation). The core analysis for providing measures to protect identity come from ETSI TR 187 010 [8] and some of the main arguments from there are repeated here modified for the specifics of the i-‐SCOPE environment.


of 55

The CRAVED criteria is used to assist in classifying the value of an object to theft. The analysis for identity in general and the role of identity in i-‐SCOPE is shown in Table 2.

Table 2 CRAVED criteria in the i-‐SCOPE environment for identity theft

Criteria Criteria clarification Applicability to identity Concealable The target can easily be

concealed by the thief or, at least, is not easily identifiable as not belonging to the thief

Yes. Identity is abstract so is concealed as a matter of course.

Removable The target is not physically fixed or otherwise secured

Yes. If available an identifier can generally be copied, in some instances such as a removable SIM or encoded into a smartphone can be removed physically.

Available The target is both visible and accessible to the thief

Yes. An identity becomes visible when used and its component identifiers and characteristics can be accessible in a number of ways (though not, necessarily, at a single location).

Valuable The target has either intrinsic monetary value or personal value to the thief

Yes. Although an identity may not have any direct value in itself, it can be used to acquire other items and services which do have value to the holder.

Enjoyable Possession of the target provides pleasure to the holder either through monetary or personal gain

Yes. Possession of an identity does not provide pleasure in itself but it can provide access to services and goods which the holder might find enjoyable.

Disposable The target can be sold by the thief for monetary or other gain

Yes. Once all of its component identifiers and characteristics have been acquired, there is a ready market for them, particularly for the purpose of carrying out concealed criminal activities. In the context of i-SCOPE as a social network (this applies to all social networks) this is a growing risk where identities are sold for development of botnets and similar large scale fraud networks.

4.2 Objectives from D01.03 as policy seeds

4.2.1 Privacy and Data Protection

i-‐SCOPE when deployed has to meet the expectations of privacy established in the Organisation for Economic Co-‐operation and Development (OECD) Declaration of Human Rights [9], the EU Data Protection laws [6], [10] and the EU Convention on human rights [19] and which can be summarised as defining the following top level objectives for the system.


of 55

• Access to services should only be granted to users with appropriate authorization;

• The identity of a user should not be compromised by any action of the system;

• No action of the system should make a user liable to be the target of identity crime;

• No change in the ownership, responsibility, content or collection of personal data pertaining to a user should occur without that user's consent or knowledge;

• Personal data pertaining to a user should be collected by the system using legitimate means only;

• An audit trail of all transactions having an impact on personal data pertaining to users should be maintained within the system.

Table 3 lists specific objectives addressing those arising from the Data Protection and Privacy legislation. The table is extended by identifying specific actions to be taken in i-‐SCOPE to meet the objective.


of 55

Table 3: Data protection and privacy objectives statement for i-SCOPE Ref. Objective Comments

DPP0-1 Privacy by design Privacy and security friendly technologies are to be designed to ensure that applications respect the fundamental right to privacy and the data protection legislation.

The present document is one of the proofs of the application of the privacy by design objective for i-SCOPE. DPPO-2 Compliance to the

Accountability principle The data controller is accountable for complying with measures which give effect to the DPP principles. The data controller is ultimately responsible for the personal data gathered through the application in question.

In i-SCOPE the middleware acts as the data processor and the data controller is a role shared by the middleware host and the stakeholders offering the data. DPPO-3 Compliance to the Data

Collection limitation: Information and transparency on use

The operators of i-SCOPE should develop and publish concise, accurate and easy to understand information for each of their applications regarding the need to ensure that users are aware of how, when and where data is collected, processed and maintained.

Whilst i-SCOPE in the initial phase can be considered as experimental and will operate in more controlled conditions than for many commercial offerings the role of all data shall be highlighted. DPPO-5 Compliance to the Data

collection limitation: Consent.

Before collecting personal data - for example, when contracting with the data subject – the i-SCOPE operator should obtain the prior and unambiguous consent of the data subject or inform him/her of the collection of personal data and the indicated purposes of use according to appropriate national and regional regulations.

A log should be maintained of the results of all consent actions. The recommendation for implementation is that consent is bound to an object and if the capability of the object is modified then any existing consent has to be re-instated by the affected user. DPPO-6 Compliance to the Data

collection limitation: Data collection methods

Data collection methods. An operator should not acquire personal data by fraudulent or other dishonest means. Data collection without prior consent may be argued to be dishonest.

DPPO-7 Compliance to the Data collection limitation: principle of purpose limitation

As established in DPPO-3, when handling personal data, the i-SCOPE operator should specify the purposes of use of personal data.

DPPO-8 Right of access, rectification, deletion to personal data

Data subjects, using means easily accessible, should be entitled to know the information contained in the system together with any processing related to that information.

DPPO-9 Compliance to the "Right to be Forgotten" principle

Extends the rights in DPPO-8 to require that the i-SCOPE operators delete all references to an individual insofar as the law allows1

DPPO-10 Data quality principle to be applied

This requires personal data to be relevant and not excessive for the purposes for which they are collected. Thus, any irrelevant data should not be collected and if it has been collected it cannot be retained.

All of the above objectives apply to all activities. Where data is gathered against an entity this data should be open to verification by the affected parties (opinion may be made by party A but against party B thus party B has the right of verification) DPPO-11 Anonymisation and

minimization i-SCOPE should minimize the processing of personal data using anonymous or pseudonymous data where possible.

DPPO-12 Security safeguards Personal data, including unique identifiers, should be protected by reasonable security safeguards against such risks as loss or unauthorized access, destruction, use, modification or disclosure of data.

1 In some cases the system may have to retain data on the activities of an individual in line with law enforcement requirements and fiscal legislation that applies in the region of deployment.


of 55

4.2.2 Confidentiality

The following security objectives related to the confidentiality of stored and transmitted information are specified:

Co1. Information sent to or from an authorized user should not be revealed to any party not authorized to receive the information.

Co2. Information held within the i-SCOPE client should be protected from unauthorized access.

Co3. Details relating to the identity and service capabilities of a user should not be revealed to any unauthorized 3rd party.

Co4. Management Information sent to or from an i-SCOPE client should be protected from unauthorized access.

Co5. Management Information held within an i-SCOPE client should be protected from unauthorized access.

Co6. It should not be possible for an unauthorized party to deduce the location or identity of a user by analyzing communications traffic flows to and from the i-SCOPE client.

Co7. It should not be possible for an unauthorized party to deduce the any historic data of the actions of an end-user by analyzing communications traffic flows to and from the end-user's device.

4.2.3 Integrity

The following security objectives related to the integrity of stored and transmitted information are specified:

In1. Information held within an i-SCOPE client should be protected from unauthorized modification and deletion.

In2. Information sent to or from a registered user should be protected against unauthorized or malicious modification or manipulation during transmission.

In3. Management Information held within an i-SCOPE client should be protected from unauthorized modification and deletion.

In4. Management Information sent to or from an i-SCOPE client should be protected against unauthorized or malicious modification or manipulation during transmission.

4.2.4 Availability

The following security objectives related to the availability of i-‐SCOPE services are specified:


of 55

Av1. Access to and the operation of services by authorized users should not be prevented by malicious activity within the i-SCOPE environment.

4.2.5 Accountability

The following security objectives related to the accountability of users are specified:

Ac1. It should be possible to audit all changes to security parameters and applications (updates, additions and deletions).

Ac2. It should be possible to audit all core data modifications made by users.

4.2.6 Authenticity

The following security objectives related to the authenticity of users and transmitted information are specified:

Au1. It should not be possible for an unauthorized user to pose as an i-SCOPE client when communicating with another i-SCOPE client.

Au2. It should not be possible for an i-SCOPE client to receive and process management and configuration information from an unauthorized user.

Au3. Restricted services should be available only to authorized users.

For this to work and for such data to fall outside of the scope of the Data Protection Act (DPA) (the UK instantiation of the DP&P) the anonymised information should not lead to the identification of individuals when matched with data available elsewhere. In practice this requires knowledge of where data available elsewhere is stored and makes some assumption of tools such as k-‐anonymity being applied.

"There is clear legal authority for the view that, where a data controller converts personal data into an anonymised form and publishes it, this will not amount to a disclosure of personal data -‐ even though the disclosing organisation still holds the ‘key’ that would allow re-‐identification to take place," it said. "This means that the DPA no longer applies to the disclosed information."

Under the DPA personal data must be processed fairly and lawfully and for specific, explicit and legitimate purposes only. Organisations must have a lawful basis for processing individuals' personal data, such as having obtained individuals' consent to do so or if they can show that it is "necessary for the purposes of the legitimate interests" they are pursuing, as long as those interests are not "overridden by the interests for fundamental rights and freedoms of the data subject".


of 55

However, organisations that properly anonymise personal data do not have to abide by the DPA's "strict requirements" in order to process that anonymised information, the ICO said. The watchdog did admit though that "the risk of re-‐identification through data-‐linkage is essentially unpredictable" and that therefore organisations must "carry out as thorough a risk analysis as is possible -‐ at the initial stage of producing and disclosing anonymised data."

Within the i-‐SCOPE project as many different data sets and services are visible techniques such as k-‐anonymity may be deployed to minimise the likelihood of achieving data-‐linkage. This is discussed in the context of the common criteria unlinkability functional capability later in the present document.


of 55

5 CC functional capabilities to be supported

resulting from i-‐SCOPE policy

NOTE: This chapter forms part of the output of WP4.8 but is addressed in the present document as it is a logical extension of D03.03.

5.1 Identification and authorisation capabilities

Identity capabilities, wherein identity refers to the behavioral as well as to the static elements of identity, are the primary elements of policy. Therefore this section covers those functional capabilities required in WP4.8 to specifically enable a policy of identity and therefore PII protection in i-‐SCOPE.

An identifier has a specific meaning within a specific context and identity problems occur most frequently when either contexts are not unique or the scope of an identifier is extended beyond its original context (for example, by using a telephone number for something other than for making telephone calls). As elements of identity, identifiers are often used to support a claim of identity but such out-‐of-‐context uses of identifiers can generally be easily guessed in an identity fraud attempt. Where an identity can be restricted to a single purpose (with or without supporting authentication data) it may be more difficult to use it as the basis of identity fraud.

NOTE: In many cases it may not be practical to limit an identity to a single purpose as it would require retrospective modification of common practice. However, the principle should still be considered.

There is a significant role in modern communications systems to use identity federation as a means to minimise the cost and complexity of identity management. In the i-‐SCOPE context there should be no barrier to use of federated identity though the overall functional capabilities offered by i-‐SCOPE should not be changed.


of 55

The list of functional security requirements to be met by i-‐SCOPE shown in table 5 is derived from an analysis of both the security objectives and the risks associated with IdM in i-‐SCOPE. For each requirement, a functional class (as defined in ISO/IEC 15408-‐2 [4]) is identified and this is used in the development of functional security requirements for i-‐SCOPE.

Table 5: IdM functional security requirements Functional requirement Functional class (from

ISO/IEC 15408-2 [4]) 1 Access to iSCOPE should only be granted to users with appropriate authorization 1.1 The operator shall be the only entity able to create

the identifiers in class 2 Access control policy

1.2 The operator shall be the only entity able to destroy identifiers in class 2

Access control policy

1.3 i-SCOPE shall support the transfer of identifiers and identities between domains

Export to outside TSF control

1.4 i-SCOPE shall be able to enforce the use of i-SCOPE generated secrets for authentication

Specification of secrets

2 The identity of an i-SCOPE user should not be compromised by any action of i-SCOPE

2.1 i-SCOPE shall protect the identities of its users from illicit misuse and abuse

2.2 The identity of the identity provider should not be retrievable from analysis of a class 2 identifier

Unobservability

2.3 i-SCOPE shall endeavour to keep personal data accurate and up to date within the scope necessary for the achievement of the purposes of use

2.4 Personal data shall be protected by reasonable security safeguards against such risks as loss or unauthorized access, destruction, use, modification or disclosure of data

Access control policy; Stored data integrity; Export to outside TSF control

2.5 iSCOPE shall detect use of authentication data that has been forged by any user of i-SCOPE

User authentication

2.6 i-SCOPE shall detect use of authentication data that has been copied from any other user of i-SCOPE

User authentication

2.7 i-SCOPE should provide a cryptographic symmetric challenge response mechanism to support user authentication

User authentication

2.8 i-SCOPE shall provide a cryptographic asymmetric digest mechanism to support user authentication

User authentication

3 No action of i-SCOPE should make an i-SCOPE user liable to be the target of identity crime

3.1 i-SCOPE should provide the means for users to transact anonymously

Anonymity

3.2 i-SCOPE operators shall take reasonable measures to avoid collecting data capable of identifying an individual by referring to a database, in cases where such a possibility exists


3.3 i-SCOPE shall prevent use of authentication data that has been forged by any user of i-SCOPE

User authentication

3.4 i-SCOPE shall prevent use of authentication data that has been copied from any other user of i-SCOPE

User authentication


of 55

Functional requirement Functional class (from ISO/IEC 15408-2 [4])

4 No change in the ownership, responsibility, content or collection of personal data pertaining to an i-SCOPE user should occur without that user's consent or knowledge

4.1 i-SCOPE should obtain the prior and unambiguous consent of the data subject for the collection of personal data and indicate the purposes of use before collecting personal data


4.2 i-SCOPE shall inform the data subject of the collection of personal data and the indicated purposes of use before collecting personal data


4.3 When handling personal data, i-SCOPE shall specify the purposes of use of personal data


4.4 i-SCOPE should not change the purposes of use beyond the scope in which new purposes can reasonably be considered to be compatible with the original purposes


4.5 Before i-SCOPE changes the purposes of use beyond the scope in which new purposes can reasonably be considered to be compatible with the original purposes, it should inform a data subject of the change or obtain prior and unambiguous consent


4.6 i-SCOPE should not handle personal data, without obtaining the prior consent of the data subject, beyond the scope necessary for the achievement of the specified purposes of use


4.7 i-SCOPE should not provide personal data to a third party without obtaining the prior consent of the data subject.

Export to outside TSF control

4.8 There should be a general policy of openness about developments, practices and policies with respect to personal data.


5 Personal data pertaining to an i-SCOPE user should be collected by i-SCOPE using legitimate means only

5.1 i-SCOPE shall not acquire personal data by fraudulent or other dishonest means

Information flow control policy


of 55

Functional requirement Functional class (from ISO/IEC 15408-2 [4])

6 An audit trail of all transactions having an impact on personal data pertaining to i-SCOPE users should be maintained within the boundary of i-SCOPE

6.1 i-SCOPE shall maintain an audit log of all class 2 identifiers created and destroyed

Security audit event storage

6.2 i-SCOPE shall maintain an audit log of all user identities transferred to or from another legal entity


6.3 i-SCOPE shall maintain an audit log of all requests for consent for the collection of personal data and the responses received from the data subject


6.4 i-SCOPE shall maintain an audit log of all instances where it has informed the data subject of the collection of personal data


6.5 Means should be readily available for establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data collector

Security audit data generation

6.6 Audit records shall be viewable only by authorized parties


6.7 i-SCOPE shall be able to associate each auditable event with the identity of the user that caused the event

Security audit data generation

5.2 Confidentiality capabilities

FFS

5.3 Integrity capabilities

Where integrity assurance is provided by means of digital signature in support of identity and access control no further capabilities are described.

5.4 Non-‐repudiation capabilities


of 55

CC functional capability

i-SCOPE statements arising Requirements to be addressed in WP4

FCO_NRO.1.1 The i-SCOPE system shall be able to generate evidence of origin for transmitted PII at the request of the recipient

FCO_NRO.1.2 The i-SCOPE system shall be able to relate the [assignment: list of attributes] of the originator of the information, and the [assignment: list of information fields] of the information to which the evidence applies.

FCO_NRO.1.3 The i-SCOPE system shall provide a capability to verify the evidence of origin of information to [selection: originator, recipient, [assignment: list of third parties]] given [assignment: limitations on the evidence of origin].

FCO_NRO.2.1 The i-SCOPE system shall enforce the generation of evidence of origin for transmitted PII at all times.

FCO_NRO.2.2 The i-SCOPE system shall be able to relate the [assignment: list of attributes] of the originator of the information, and the [assignment: list of information fields] of the information to which the evidence applies.

FCO_NRO.2.3 The i-SCOPE system shall provide a capability to verify the evidence of origin of information to [selection: originator, recipient, [assignment: list of third parties]] given [assignment: limitations on the evidence of origin].

FCO_NRR.1.1 The i-SCOPE system shall be able to generate evidence of receipt for received [assignment: list of information types] at the request of the [selection: originator, recipient, [assignment: list of third parties]].

FCO_NRR.1.2 The i-SCOPE system shall be able to relate the [assignment: list of attributes] of the recipient of the information, and the [assignment: list of information fields] of the information to which the evidence applies.

FCO_NRR.1.3 The i-SCOPE system shall provide a capability to verify the evidence of receipt of information to [selection: originator, recipient, [assignment: list of third parties]] given [assignment: limitations on the evidence of receipt].

FCO_NRR.2.1 The i-SCOPE system shall enforce the generation of evidence of receipt for received [assignment: list of information types].

FCO_NRR.2.2 The i-SCOPE system shall be able to relate the [assignment: list of attributes] of the recipient of the information, and the [assignment: list of information fields] of the information to which the evidence applies.

FCO_NRR.2.3 The i-SCOPE system shall provide a capability to verify the evidence of receipt of information to [selection: originator, recipient, [assignment: list of third parties]] given [assignment: limitations on the evidence of receipt].


of 55

6 Policy derived from TRUSTe Program

6.1 Rationale for using the TRUSTe program

The TRUSTe program is one of a (very) small set of certification programmes that allow a website to show compliance to set of straightforward privacy policies. It is not the purpose of i-‐SCOPE to mandate the use of any particular commercial service therefore it is only the structure of such a programme that is examined in this document and how it fits to i-‐SCOPE.

A key point of all such programmes is that to have any credibility the manager of the programme deployment has to accept accountability for their actions to manage privacy. This is also a core requirement of the DP&P regulation and the programme manager in TRUSTe terminology is equivalent to the data controller role. The practices validated by the TRUSTe programme mimic those identified in D01.03 as general principles for i-‐SCOPE's adherence to the DP&P requirements.

The specific reason for considering the TRUSTe approach is that it is externally validated to determine if the web service offered complies to specific requirements. This is also one of the reasons for the use of ExTRA to specify policy statements as it allows the policy to be tested by ensuring each policy statement becomes a rule that can be implemented in software and tested procedurally.

Principle Managed validation

Collection Limitation Participant shall only collect PII where such collection is:

Limited to information reasonably useful for the purpose for which it was collected and in accordance with the Participant's Privacy Statement in effect at the time of collection; or

With notice to and consent of the Individual

Use of PII Participant shall use PII in the provision of those services advertised or provided for, and in accordance with their posted Privacy Statement in effect at the time of


of 55

collection, or with notice and consent as described in these Program Requirements.

a): Information collected by the Participant or the Participant's Service Provider may be used to tailor the Individual's experience on the Participant's Online property.

Choice Participant shall offer the Individual control over their collected Personally Identifiable Information as follows: Participant must provide the Individual an opportunity to withdraw consent to having PII used by the Participant for a Secondary Purpose.

a. Participant must provide the Individual a Just in Time Notice and the opportunity to withdraw consent to having PII disclosed or distributed to Third Parties, other than Service Providers, at the time PII is collected;

b. Participant shall honor and maintain the Individual's choice selection in a persistent manner until such time the Individual changes that choice selection; and

c. Participant shall provide a means by which the Individual may change their choice selection.

7 ExTRA file for i-‐SCOPE policy statements

To be provided in WP4 of i-‐SCOPE project.


of 55

8 OAuth 2.0 as target for authentication and

authorisation model

It is proposed that as far as is possible that i-‐SCOPE uses off the shelf and "open" software as far as possible. Whilst the TVRA (see D.01.03) suggests that strong security procedures are put in place to supplement the

OAuth 2.0 brings three important enhancements over what was available in OAuth 1.0:

1. Simplicity: Client developers don’t need to do any cryptography or use a library to call OAuth 2.0 protected resources. The token can be passed in the HTTP headers or as a URL parameter. While HTTP headers are preferred, a URL parameter is simpler and allows API exploration with a browser.

2. Token choice: implementers can use existing tokens that they already generate or consume. There are extension points so that the client can sign the token instead of it being a bearer token.

3. Separation of roles: if the token is self-‐contained, then the resource can verify the token independently of the authorization server. Resources don’t have to call back to the authorization server to verify the token on each call, enabling higher performance and separation of security contexts.

Some of the related standards that are already well under way and in use include the OAuth Assertion Framework, the OAuth SAML 2.0 Assertion Profile and OAuth JWT Assertion Profile, JSON Web Token (JWT), the JSON Object Signing and Encryption (JOSE) specs – JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), and JSON Web Algorithms (JWA), and OpenID Connect.


of 55

Figure 3 : OAuth message sequence

The

sd OAuthModel

Client ResourceOwner AuthorisationServerResourceServer

AuthorisationRequest()

AuthorisationGrant()

AuthorisationGrant()

AccessToken()

AccessToken()

ProtectedResource()


of 55

9 DP&P compliance policy example text

9.1 Overview

The DP&P compliance policy has to identify what is collected, for what purpose it is collected, how long it is retained, and how the affected party can ask for its removal.

9.2 General feelgood statement of intent

A general criticism of most privacy statements is that they contain the fatuous statement "Your privacy is important to us". As compliance to regulation is essential by law it is not necessarily that privacy is important to the provider, it is simply that failure to recognise the importance of protecting private information is essential to the lawful operation of the provider.

i-‐SCOPE recommends against such feelgood statements of intent.

9.3 Statement regarding the information collected

This notice applies to all information collected or submitted through the operation of the i-‐SCOPE facilities. The types of personal information that may be collected at these pages include:

o Name o Address o Email address o Phone number o Credit/Debit Card Information

As a social network, in the broad sense of building a community of interest where data is shared by many interested parties, information may be submitted about other people or legal entities. Whilst i-‐SCOPE may not be aware of all such entries it may be necessary to protect the entities being referred to and thus i-‐SCOPE may make recommendations to anonymise such entries or seek consent from the affected parties that data about them is published.

The purpose of i-‐SCOPE gathering PII is in order to complete the transaction with the i-‐SCOPE system in a way that allows legal compliance to be conformed with and to ensure that the transactions made through i-‐SCOPE can be completed satisfactorily.


of 55

9.4 Statement regarding provision of Data Security measures

To prevent unauthorized access, maintain data accuracy, and ensure the correct use of information, i-‐SCOPE has put in place appropriate physical, electronic, and managerial procedures to safeguard and secure the information made available to it.

9.5 Statement regarding protection of children and "at risk" groups

In order to properly protect at risk groups i-‐SCOPE will take all measures allowed within the law to verify the identity of its users. Such measures may include use of 3rd parties to verify age, sex and identity in such a way to protect the legitimate use of i-‐SCOPE's services and to prevent exploitation of any "at risk" group.

9.6 Statement regarding access to information

i-‐SCOPE works to ensure that legitimate requests to access information are honoured. This includes ensuring proper identification of users and recording of how data is used such that it can be accessed and if required deleted (as required under the "right to be forgotten" clauses in recent DP&P legislation).

9.7 Statement regarding contact and liability

The Data controller of i-‐SCOPE shall be available and contact details published including the route to arbitration and independent DP&P authorities.


of 55

10 Anti-‐discrimation policy example text

NOTE 1: This text should be included in all formal public statements from i-‐SCOPE and in particular its demonstrator partners.

NOTE 2: Where existing policies exist, for example within the operation of demonstrator partners, the main points outlined in the example text of the anti-‐discrimination policy should be verified.

It is the policy of all the i-‐SCOPE partners to ensure that the deployment of i-‐SCOPE technical capabilities provide equality of access to all, irrespective of:

• gender, including gender reassignment

• marital or civil partnership status

• having or not having dependents

• religious belief or political opinion

• race (including colour, nationality, ethnic or national origins)

• disability

• sexual orientation

• age

The partners of i-‐SCOPE are opposed to all forms of unlawful and unfair discrimination. The partners of i-‐SCOPE are committed to:

• promoting equality of opportunity for all persons • promoting a good and harmonious learning environment in which all men

and women are treated with respect and dignity and in which no form of intimidation or harassment is tolerated

• preventing occurrences of unlawful direct discrimination, indirect discrimination, harassment and victimisation

• fulfilling all our legal obligations under the equality legislation and associated codes of practice

• complying with our own equal opportunities policy and associated policies • taking lawful affirmative or positive action, where appropriate


of 55

11 INDEX Design for Assurance, 27 ExTRA, 28 OECD, 37 Organisation for Economic Co-‐

operation and Development. See OECD

Privacy by Design, 27 TPLan, 28 TVRA, 28

i-scope privacy security policies draftv02 - cordis · work!package! wp3$%$smart$services$ task!...

Documents