Data: Access Control for Privacy Preserving Perimeter Protection System

. In this paper, we address the issues of personal data protection for privacy preserving perimeter protection system, particularly, the access control for real-time data streamed from surveillance tools and also for data stored in facility’s storage. Furthermore, we also provide an access control model proposed speciﬁcally for such system and access control system implemented in Java.


Introduction
Critical buildings and infrastructures (e.g. nuclear power plants) require strong and unlikely breakable physical security protection from physical or forceful attacks. To protect such infrastructures beyond the use of conventional methods such as fences, we normally use different surveillance tools (e.g. visual cameras) to observe and detect activities around the protected infrastructures. In most cases, the surveillance covers only the private zones, but sometimes it goes beyond by covering a larger area (e.g. public area) in order to have an early warning, which provides enough time to react in case of attack. However, including the public area into the surveillance perimeter poses challenges for personal data protection since surveilling the public areas, without the approval from concern government authority, are not permitted in some countries like in EU or USA [4]. Thus, when designing perimeter protection system covering public area, one needs to take into account the personal data protection aspect [3,8]. We introduce, in this paper, an access control model and system designed particularly for P5 (Privacy Preserving Perimeter Protection Project) system [2]. The proposed access control system aims at ensuring that personal data are properly protected and only authorized The work presented in this paper is supported by the European Commission's FP7 programme P5 Project (Grant agreement No: 312784). The content of this paper is the sole responsibility of the authors and it does not represent the opinion of the European Commission and the Commission is not responsible for any use that might be made of information contained herein. people can use those data for purpose they intend for. The rest of the paper is organized as follows. Section 2 is about P5 project and system architecture. Section 3 introduces the privacy-aware access control model. Section 4 presents the access control scenarios and policies definition for P5 system. Section 5 talks about access control architecture and implementation. Section 6 is related work and contributions while Sect. 7 is conclusion.

P5 Project and P5 System Architecture
P5 is the European and FP7 FUNDED (http://www.foi.se/p5) project for the protection of critical infrastructures to benefit the sustainability of society and future well-being of the European Citizens. The goal of the P5 project is an intelligent perimeter proactive surveillance system that works robustly under a wide range of weather and lighting conditions and that has strong privacy preserving features. In P5's system architecture (see Fig. 1), there are many modules forming the entire P5 system, from the the lowest layer hosting sensors that provide different data types to the upper layer modules, such as "attributes analysis", "detection/localization", "multi-source heterogeneous data fusion", "object classification, tracking and behavior and intents recognition", "early warning" and "man machine interface". Each one of the modules is a problem by itself, however, in this paper we address only the issue of access control for real-time data streamed from surveillance tools and data stored in facility's storage. There are three modules, in the proposed architecture, which ensure privacy preservation and personal data protection: (1) Privacy-aware access control module (PACM) is responsible for controlling access to raw data. This module is responsible also for enforcing access control policies. (2) Privacy-aware filter is responsible for filtering the privacy-related information. (3) Trusted Third Party (TTP) module provides a way to manage access control policies, to protect the raw data and to audit the access to raw data. TTP administrator can be a trusted private or government entity, which is authorized for the job. It is important to note that since our main addressing issue in this paper is the design of privacy-aware access control system, we address only PACM.

Privacy-Aware Access Control Model
Access Control Requirements. To identify the access control requirements for privacy preserving perimeter protection system, we conducted two different studies. Firstly, we worked with legal group to study the EU Directive 95/46/EC [4]. Secondly, we did a formal survey and also conducted a broad range of data collection and analysis. For the field works, we visited existing perimeter protection systems installed in the protected facilities in United Kingdom (UK) and Sweden, such as National Air Traffic control in UK and OKG Nuclear Power Plant in Sweden. Based on the result of our survey and legal studies, we can classify the access control and data protection requirements into four main points.
1. Legal Requirements: based on the article 2, 10 and 11 of Directive 95/46/EC, we can define the following legal requirements. (1) Data controller needs to notify data subject every time of access. (2) Processing of private data is limited to the purpose for which data are intended for. (3) Consent from data subject is required when processing personal data. 2. User Management Requirements: security personnel manages access to control room as well as sensors. An assigned group of users, while they are on duty, is allowed to be in control room to view real time data streamed from sensors. In case of emergency where there are intruders attacking the facility, users in control room are allowed to access raw data. Other assigned group of users can access raw data in storage, but special access permission is needed. The main purpose of storing data from sensors is for forensic purpose. 3. System Performance Requirements: since we deal also with real-time data, access control to such data stream must be reasonably fast to avoid the delay to data stream. 4. Security and Data Protection Requirements: processing of private data must be secured. We need to make sure that only authorized people can get access to data. Data controller should be a trusted entity that overlooks the management of access control policies as well as data in storage.
Based on the above requirements, we define the following access control model. Access Control Model. We introduce Context-and Privacy-aware RBAC [3] (CP-RBAC), an access control model designed for controlling access to private data in privacy-preserving perimeter protection system. In CP-RBAC, access authorization is based not only on the user's role, but also on contextual information, such as temporal-, spatial-and environment-context. Furthermore, the concept of privacy is also introduced into the model. In the proposed model, contextual information is used as constraint for both the role admission and data permission assignment (see Fig. 2). The purpose of access and obligation are also the binding constraints on data permission to preserve and protect the privacy. CP-RBAC (see Fig. 2) consists of the following entities.
-U is a set of users (u) where u ∈ U . R is a set of roles (r) where r ∈ R. Then, we formulate the privacy-sensitive policy (RP): The detailed formulation of privacy-sensitive policy is as follows.
-The set of Data Permission DP = {(a, d) | a ∈ A, d ∈ D} -The set of Privacy-sensitive Data Permission P DP = {(dp, p, c, o) | dp ∈ DP, p ∈ P, c ∈ C, o ∈ O} -Privacy-sensitive Data Permission to role Assignment PDPA ⊆ R × P DP , a many-to-many mapping privacy-sensitive data permission to role.
Contextual Data are the information surrounding user, data and reason that user needs to execute the action. Contextual information can be anything, such as user's personal data, location or time. Obligation is defined as the action that user or system needs to fulfill before or after accessing data. For example, notifying data controller every access.

Access Scenarios and Policy Definition for P5
We present the access scenarios and access control policies for P5. Then, we express those policies with the access control model we presented in Sect. 3.

1) Access Raw Data in Real Time
(P1): we define the role "guardian"and users in this role are able to view real-time raw data streamed from sensors. However, they can do so only in case of emergency. Users can trigger emergency if and only if there is a positive acknowledgement from early warning module, which is responsible for providing a warning message when it detects an abnormal behavior of the objects. Moreover, to be able to keep track user's activities, users are required to notify system every time access to raw data. With above policy description, we are able to mine the following information.
With the above information and policy expression in Sect. 3, we can formulate the following access policy.

PDPA to role "Guardian"(P1)= (Guardian, (View, streaming video), Observing-suspicious-object, (acknowledgement-from-early-warning= positive), Notify=yes))
2) Replay Recent Past Raw Data (P2): this happens when guard in the control room wants to replay recent past video stream. We define "recent past video stream" as the video stream that has been recorded within the last 30 min Users in role "guardian"are allowed to review recent past video stream. The same rule in P1 is applied in P2. However, one more context is required that is the life of video stream, which is set to be 30 min. The life of video stream context limits the access to the past videos, which are older than 30 min. Any access to older past video streams needs to be controlled by policy P3. With the above policy description, we are able to define the policy (P2) as follows.

PDPA to role "Guardian" (P2)= (Guardian, (View, streaming video), Observing-suspicious-object, (acknowledgement-from-early-warning= positive ∧ life-of-video ≤ 30 min), Notify=yes))
3) Access Raw Data in Storage (P3): authority may need to access past raw data for an investigation (e.g. a crime scene in the coverage area). However, in order to get access to raw data facility manager needs to send the request to TTP with proof. Proof is an official document justifying the mission. We define the role "Facility-security-manager"and users in this role are able to request TTP for accessing raw data in storage. In addition to that, users need to mention their purpose of request. We define three types of purpose: (1) Internal auditing, (2) Investigation and (3) Observing-suspicious-object. Moreover, to be able to keep track users' activities, users are required to notify system every access. With above policy description, we are able to mine the following information.

Access Control: Architecture and Implementation
The access control system (see Fig. 3) consists of the following components. Policy Enforcement Point (PEP) handles request from user and forwards it to PDP; PEP also enforces the policy by using different policy enforcement mechanisms: role to purpose alignment and notification. Policy Decision Point (PDP) is responsible for validating access control policies with the support of information provided by Policy Information Point (PIP). PIP is responsible for providing all needed information to PDP during policy validation phase. We define four contextual variables. (1) Proof is an official mission document that user needs to provide when requesting access to raw data in storage. (2) Early warning, this module is a part of P5's architecture (see Fig. 1). (3) User to role alignment provides information concerning the assignment of users to roles. (4) Working hours is the timetable of each user. We have implemented a context-and privacy-aware access control (CP-RBAC) system based on our proposed architecture (see Fig. 3) using Java. We have used XACML version 2 as the format for access control requests, responses and policies [1]. We have also made use of Java

Related Work and Contributions
After our thorough study of different access control models, we arrive to the conclusion of using RBAC [3] in P5 project, but with extension. We have also studied different models, such as DAC, MAC [3,5,6], ABAC [10] and OrBAC [9]. In context of P5 environment setting, most of access control models (like DAC and MAC) fail to respond to the requirements since such systems generally have very complex access control policies as we have illustrated in Sect. 3. P-RBAC [3] is another family of RBAC where the concept of privacy is introduced, but it does not address the contextual information. Moreover, it does not have the concepts of context-aware role admission and personalised role permission. With above reasons, we propose an access control model that takes into account the aspects like privacy [2,7]. To provide privacy preservation feature, the concept of purpose and obligation are introduced.
Contributions. Firstly, we propose the privacy preserving perimeter protection system architecture. Secondly, access control model that can be used to express privacy-aware access control policies in P5 system. The third contribution is the implementation of such access control system.