Keywords

1 Introduction

Privacy is an increasingly important business concern in health care, financial services, and other organizations. Organizations that collect and use personal information face the growing challenge of conducting their business effectively while managing privacy risks and compliance requirements [1]. Organizations have adopted various strategies to protect personal data privacy. In particular, in the financial sector laws and regulations have been created to protect privacy data such as Basel II, Sarbanes- Oxley Act (SOX), Gramm-Leach-Bliley Act (GLBA) [2].

Access control policies are defined as rules, which regulate how users can access resources [3]. These access control policies are created based on models. The classical models are Mandatory Access Control, Discretionary Access Control and Role Based Access Control [4]. Access control models cannot enforce privacy policies and designed access control policies do not include privacy requirements such as purpose binding, conditions and obligations [5].

In order to enforce privacy policies in organizations, access control policies satisfying the privacy requirements in the requirements engineering should be formally identified [6]. Existing privacy policy languages such as P3P [7], APPEAL [9], E-P3P [8], EPAL [10] and XACML [4] do not completely solve privacy issues, and they are isolated from requirements analysis. As a result, defined privacy policies do not comply with system requirements. There are many frameworks for access control requirements modelling such as i* framework [12], GBRAM and its extension [13], analytical role modelling framework (ARMF) [14], and Knowledge Acquisition in Automated Specification [15].

The focus of this research study is to model privacy requirements into access control policies. Our research is aimed at delivering a model of designing privacy aware systems by incorporating privacy requirements into access control policy. The framework for modelling privacy access control policies was created. This framework is developed by extending ARMF [14]. Sections 2 and 3 present our framework for modelling privacy access control policies and its heuristics for defining and verifying these policies. In Sect. 4 we summarize the findings by focusing on the aim and objectives of study and provide future work.

2 A Framework for Modelling Privacy Access Control Policies

The framework was developed based on ARMF [14], by adding the purpose meta-concept and corresponding relations. Purpose specification principle has been selected to investigate how access control policies can be defined and how it can be enforced during the requirements modelling. It also has been selected as the only principle stated in the Law of the Republic of Kazakhstan [6]. The framework uses notations of Z language [16].

Policies define restrictions to access valuable assets (privacy data). Such an access is required to carry out tasks. The tasks cannot be processed in a way that may be incompatible with the purposes for which the data have been collected. To include these notion into the framework the following meta-concepts are needed:

[Asset] – represents privacy data that we wish to protect;

[Task] – the activities that an organizational unit or individual carries out;

[Purpose] – personal data that shall be collected for specified, lawful and legitimate purpose or purposes and not processed in ways that are incompatible with the purposes for which data have been collected.

The meta-concepts of an agent and role are identified as follow:

[Agent] – represents a physical person;

[Role] – an assignment of an obligation, of performing some function, which is a composite element representing the organisational function, organisational domain, and authority. Three types of roles are defined according to organizational structures: roles based on seniority, roles based on function, and roles based on market. The meta-concepts are as following:

[Authority] – represents the seniority of a role;

[Org_Function] – a functional grouping within an organisation;

[Org_Domain] – represents a “market based” grouping i.e. a grouping that is delegated a market to serve such as a set of clients in a specific geographic location.

The meta-concept role is a composite of authority, organizational function, and organizational domain and is defined formally as follows:

Role ≙ [authority: Authority; org_function: Org_Function; org_domain: Org_Domain]

The inheritance between organizational functions is formally defined as follows:

Inheritance_f ≙ {inhf: Org_Function ⇸ Org_Function; org_function: P Org_Function| (∀of: org_function • of ∉ inhf + (|{of}|))}.

The inheritance of roles is formally defined as follows:

Inheritance_r ≙ {inhr: Role ⇸ Role; role: P Role| (∀r: role •r∉ inhr + (|{r}|)}.

The aggregation hierarchy for organizational domain is formally identified as follows:

Aggregation_d ≙ {aggd: Org_domain ⇸ Org_domain; org_domain: P Org_domain| (∀od: org_domain • od ∉ aggd + (|{od}|)}

Formally the task aggregation is defined as follows:

Aggregation_t ≙ {aggt: Task⇸ Task; task: P Task|(∀t: task • t ∉ aggt + (|{t}|))}.

Purpose aggregation is defined as follows:

Aggregation_p ≙ {aggp: Purpose ⇸ Purpose; purpose: P Purpose| (∀ p: purpose • p ∉ aggt + (|{p}|))}.

The relationship between tasks and purposes is represented by a task purpose dependency relation as follow:

Task_purpose_dependency ≙ {task_purpose_dependency: Task →Purpose |(∀t: Task. ∃ 1 p: Purpose • (t, p) ∈ task_purpose_dependency) ∧ (∀t: aggt + (|{t}|). ∃ 1 p:aggp + (|{p}|) • (t, p) ∈ task_purpose_dependency)}.

The relation between purpose and asset or assets is represented by purpose asset dependency as follow:

Purpose_asset_dependency ≙ {purpose_asset_dependency: Purpose →P Asset; purpose: P Purpose; asset: P Asset| (∀p: purpose. ∃a: asset • (p, a) ∈ purpose_asset_dependency)}.

The relationship between asset and organizational domain is formally identified as:

Asset_domain ≙ {asset_domain: Asset → Org_Domain| (∀a: Asset. ∃ 1 od: Org_domain • (a, od) ∈ asset_domain)}.

Policies will be defined using the following composite type:

Authorization_Policy ≙ {role: Role; task: Task}

There are implicit assumptions in this defined policy: firstly, the policy applies to any subtask if the task in the policy; secondly the organizational domain in the role of the policy applies to all assets associated with the task through the following relations:

Task_purpose_dependency ≙ {task_purpose_dependency: Task →Purpose |(∀t: Task. ∃ 1 p: Purpose • (t, p) ∈ task_purpose_dependency) ∧ (∀t: aggt + (|{t}|). ∃ 1 p:aggp + (|{p}|) • (t, p) ∈ task_purpose_dependency)};

Purpose_asset_dependency ≙ {purpose_asset_dependency: Purpose →P Asset; purpose: P Purpose; asset: P Asset| (∀p: purpose. ∃a: asset • (p, a) ∈ purpose_asset_dependency)}.

3 Heuristics for Defining and Verifying Policies

Application of ARMF extensions is applied through six steps: (i) identifying organizational groups (ii) identifying level of authority (iii) defining roles (iv) identifying tasks, assets, purposes (v) defining policies, and (vi) verifying policies.

Once we have identified organizational functions, we need to show specialization hierarchy using the principle of inheritance as follow: Definition: inhf: Org_Function ⇸ Org_Function; Constraint: org_function: P Org_Function •(∀of: org_function • of ∉ inhf + (|{of}|)).

Similarly, once we have identified organizational domains, we need to show them in aggregation hierarchy as follow: Definition: aggd: Org_domain ⇸ Org_domain;

Constraint: org_domain: P Org_domain • (∀od: org_domain • od ∉ aggd + (|{od}|).

Levels of authority need to be assigned to groups. Once we have identified authority’s levels we need to show their seniority as follow:

Definition: senior: Authority ⇸ Authority; Constraint: authority: P Authority • (∀a: authority • a∉ senior + (|{a}|)).

In next step we need to identify tasks and their associated purposes and then assets related to purposes in the organization: Definition: aggt: Task⇸ Task; Constraint: task: P Task • (∀t: task • t ∉ aggt + (|{t}|)).

Next, we need to identify purposes for defined tasks, which enable tasks to have access to asset or group of assets. Identified purposes are needed to be organized in hierarchical structure. It can be done by aggregation hierarchy as follow:

Definition: aggp: Purpose⇸ Purpose; Constraint: purpose: P Purpose • (∀ p: purpose • p ∉ aggt + (|{p}|)).

After that we need to show task purpose dependency as follow:

Definition: task_purpose_dependency: Task →Purpose: Constraint: (∀t: Task. ∃ 1 p: Purpose • (t, p) ∈ task_purpose_dependency) ∧ (∀t: aggt + (|{t}|). ∃ 1 p:aggp + (|{p}|) • (t, p) ∈ task_purpose_dependency).

The relation between purpose and asset or assets is represented by purpose asset dependency: Definition: purpose_asset_dependency: Purpose →P Asset; Constraint: no constraint.

The relationship between asset and organizational domain is formally identified as follow: Definition: asset_domain: Asset → Org_Domain; Constraint: no constraint.

Once we have identified organizational context, roles and tasks we now define policies as follow: Definition: Authorization_Policy ≙ {role: Role; task: Task}; Constraint: no constraint.

The final step is to verify policies through scenarios. In creation scenario the following domain concepts should be instantiated. Instantiation of domain:

Definition: insd: Org_Domain ⇸ Org_Domain; Constraint: org_domain: P Org_Domain • (∀od 1; od2: org_domain • od 2 ∈ insd (|{od 1}|) ⟹ insd (|{od 2}|)=∅); Constraint: ∀ od 1; od 2: Org_Domain • od 1 ∈ aggd (|{od 2}|) ⟹ (insd (|{od 1}|)≠∅ ∧ insd (|{od 2}|)≠∅) ∨ (insd (|{od 1}|)= ∅ ∧ insd (|{od 2}|)= ∅).

Instantiation of role: Definition: insr: Role ⇸ Role; Constraint: role: P Role • (∀r 1; r2: role • r 2∈ insr (|{r 1}|) ⟹ insr (|{r 2}|)=∅); Constraint: ∄ role: Role • (insr (|{role}|) = ∅ ∧ insd (|{role.org_domain}|) ≠∅) ∨ (insr (|{role}|) ≠∅ ∧ insd (|{role.org_domain}|) = ∅); Constraint: ∄ policy: Authorization_Policy • insr(|{policy.role}|) ≠∅.

Instantiation of task: Definition: inst: Task ⇸ Task; Constraint: task: P Task • (∀t 1; t2: task • t 2 ∈ inst (|{t 1}|) ⟹ inst (|{t 2}|)=∅)

Instantiation of purpose: Definition: insp: Purpose ⇸ Purpose; Constraint: purpose: P Purpose•(∀p 1; p2:purpose•p 2∈ insp(|{p 1}|)⟹ insp (|{p 2}|)=∅)

Instantiation of asset: Definition: insa: Asset ⇸ Asset; Constraint: asset: P Asset • (∀a 1; a2: asset • a 2∈ insa (|{a 1}|) ⟹ insa (|{a 2}|)=∅)

Instantiated roles are assigned to agents as follow: Definition: role_assignement: Agent ↔ Role. Constraint: no constraint.

There is needed to model the carrying out of a task by an agent. This will be represented by relation performs, which defines an agent performing a task:

Definition: performs: Agent ↔Task; Constraint: ∀ p: perform • ∀task: ran performs • inst(|{task}|) ≠ ∅. Constraint: ∀p: performs • ∀task : ran performs •∀ ins_purpose: task_purpose_dependency (|{task}|) • ∃ purpose: task_purpose_dependency (|inst(|{task}|)|) • purpose∈ insp(|{ins_purpose}|).

Constraint: ∀p: performs • ∀task : ran performs •∀ ins_asset: purpose_asset_dependency (|{purpose}|)• ∃ asset: purpose_asset_dependency (|insp(|{purpose}|)|) • asset∈ insa(|{ins_asset}|).

After identifying a scenario, we determine relation performs between specific agent and corresponding instantiated task. It can be done by using elimination rules and substituting instantiated elements, which was used in creating performs relation.

4 Conclusion

This paper has addressed the problem of modelling access policies in order to ensure that security goals can be achieved and that operational requirements are consistent with access policies. The framework includes a meta-model and a set of heuristics. The meta-model represented a link between organizational context and privacy enforcement in order to capture the whole privacy domain. Heuristics were determined for defining policies and scenarios.

The limitation of this research is that proposed framework was created in Z language. This language requires a special knowledge in a set theory and mathematical logic. In addition, heuristics for defining and verifying policy were not illustrated by any example. The future research for this research study is implementation of the proposed framework in banks. In addition the future research can be done by considering other policies and validating them in the case studies.