Keywords

1 Introduction

This paper demonstrates modelling of privacy and trust policies using a novel high-level graphical policy editor. The privacy requirements are based on the results of two case studies, done as part of two EU-projects. The results of these analyses are then used to propose how policies can be implemented using the eXtensible Access Control Markup Language (XACML) [1], enhanced with the reversible anonymisation protocol in [2, 3]. The policies are modelled using our visual policy editor ViSPE [4], which is implemented in Smalltalk based on the children’s programming language Scratch [5, 6]. ViSPE focuses on providing an easy to use interface for defining XACML policies for access control, anonymisation and encryption of information in XML documents or messages. The paper demonstrates how the policy editor can be used for mitigating insider threats as well as protecting private or confidential information.

The rest of this article is organised as follows: Sect. 2 covers issues of privacy in Critical Information Infrastructures (CII), and presents the tools and technologies used to mitigate the issues in the two case studies. Section 3 presents the two cases, including the policies created to support them. Section 4 provides a brief discussion of ViSPE and its applicability to the cases, and in Sect. 5 we make our conclusions. Finally, Sect. 6 presents some ideas for future work.

2 Privacy in Critical Infrastructures

There are several important objectives for privacy regulation. Personal data and similar information must only be collected using legitimate means and for legitimate purposes to comply with data protection legislation. Access to personally identifiable information (PII) and/or confidential information must only be granted to those with appropriate authorisation. Identities must not be compromised by any action of the system. No change in ownership, responsibility, content or collection of personal data must take place without the knowledge and consent of the data subject. An audit trail of all actions having an impact on personal data and confidential information must be maintained within the system to allow for forensic analysis in the event of a data breach.

Our long-term goal is to build and extend the ViSPE policy editor combined with our reversible anonymisation scheme to model such privacy requirements. We can already model a range of scenarios, however other remain as future work, for example adding policy controlled secure logging obligations. The privacy enforcement tool is based on the reversible anonymisation scheme [3]. It has been integrated with the Prelude-IDS Security Incident Event Management (SIEM) systemFootnote 1 in order to demonstrate privacy-enhanced intrusion detection services, as shown in Fig. 7.

2.1 Privacy Enforcement Mechanism

Figure 1 gives a high-level overview over the XACML based anonymisation scheme for anonymising XML documents or messages [2]. The scheme consists of an initial authorisation policy with a set of XACML Obligations, which amongst others define multiple XPath resource definitions identifying XML elements or attributes that need to be authorised. The XACML Policy Enforcement Point (PEP) of the anonymiser will subsequently loop through all resource definitions and extract and authorise each match of the XPath resource against the XACML Policy Decision Point (PDP).

The PEP sends the resource identifier with each resource to be authorised, so that the respective XML element authorisation policy is evaluated to decide whether the given XML element should be authorised or not. If the XML element is authorised, then an XACML Obligation describes how the element should be anonymised, for example whether the data should be replaced with a fixed string (e.g. “confidential”) or whether it should be padded using a character (e.g. pad-with X). The anonymisation scheme supports a decision caching protocol in order to improve efficiency [2], and can also describe cache timeout values and similar parameters from the XACML Obligations.

The anonymisation scheme has been extended to support XACML controlled reversible anonymisation of XML documents or messages based on storing the anonymised information encrypted in different security levels, so that only authorised users or roles can access this information [3].

Fig. 1.
figure 1

Overview over XACML anonymisation scheme

Full size image

The reversible anonymisation protocol is based on a hybrid encryption scheme where a user can unlock an encryption key using her secret key, and this encryption key is furthermore used to unlock an authorisation mapping which contains the encryption keys for the security levels the user has access to. The reversible anonymiser supports advanced functionality, such as default PERMIT, or default DENY anonymisation policies, multiple security levels and policy defined key sharing, so that several users or roles must collaborate to reverse the anonymisation. This paper shows how we have created a high-level abstraction for creating XACML-based anonymisation policies using the Scratch-based policy editor ViSPE [4].

2.2 ViSPE’s Graphic Primitives for XACML Policy Elements

XACML is an XML-based policy-definition language. The syntax is human/machine-readable, but not trivial to write without comprehensive editor support. While there are editors that support writing of XACML policies, like UMU-XACMLFootnote 2 or the WSO2 Identity ServerFootnote 3, the novel editor ViSPE takes a new approach by presenting XACML elements as graphical blocks [4]. ViSPE allows non-programmers like policymakers to implement privacy, anonymisation and authorisation policies using a high-level graphic XACML-like policy language, which is generated into XACML XML policies.

The blocks follow the same structure as the underlying XACML syntax. This makes it easy to visualise the containing element of a tag. The colour differentiation between blocks is also a helpful tool for quickly orienting the start and end of a tag element.

The editor also includes specialised blocks tailored to present the obligations and their assignments. This means that the user does not need to have knowledge of the underlying XACML syntax, e.g. for the different obligations supported by the anonymiser.

The editor is shown by Fig. 2, and includes two example XACML Obligation blocks in ViSPE, while Fig. 3 shows the more verbose XACML implementation of the first block. The Declassify block implements an obligation to declassify the content of an entire XML element or attribute from a security level secret, so that this attribute is shown in the anonymised document when a default DENY anonymisation policy is being used. The Anonymise block on the other hand explicitly anonymises data in the document and stores this in a security level secret for default PERMIT protocols. The ViSPE block is far easier to read and understand than the underlying XACML Obligation. The editor furthermore uses a consistent colour scheme for Obligation blocks, so that it is easy to recognise which blocks that will be mapped to Obligations.

Fig. 2.
figure 2

The ViSPE editor with resource definition examples

Full size image
Fig. 3.
figure 3

XACML obligation corresponding to the Declassify resource block

Full size image

XACML is very verbose and not easy to read or write. While the graphical block representation is much more compact, the readability is also better, since it highlights the important parts of each block while hiding the verbose syntax.

3 Case Studies

Here, we will present two use cases that highlight the issues at hand. The first is a critical infrastructure network related to a traffic control centre, and the second is a multinational smart grid demand/response operator.

Fig. 4.
figure 4

The two scenarios

Full size image

3.1 Case 1: Privacy in Critical Cyber-Infrastructure

This case describes how to define a default DENY privacy policy for an outsourced managed security service provider, so that a first-line security analyst can only see information defined as non-sensitive in the privacy policy, while an authorised Computer Emergency Response Team (CERT) doing attack investigations is authorised to de-anonymise the information in the Intrusion Detection System (IDS) alarms. An advantage with such a policy, is that only information that is explicitly allowed will be presented to the first line security analyst, effectively implementing privacy by default [7]. In this scenario, the operators on the critical infrastructure network of the traffic control centre may trigger IDS alarms that may in turn leak PII if they are not anonymised.

Fig. 5.
figure 5

ViSPE anonymisation policy for the privacy-enhanced IDS case

Full size image

IDS Alarm Anonymisation Policy for a Traffic Control Centre. In the traffic control centre, security monitoring using IDS is outsourced to a managed security service company. It is assumed that possible exposure to PII sampled in IP packets from the traffic control center must be avoided, so that this information does not leave the network perimeter of the traffic control center. This means that IDS alarms normally will be anonymised, however it will be possible for a trusted Computer Emergency Response Team (CERT) to investigate suspected attacks on the traffic control network when necessary.

This case assumes that the security operator escalates suspected attacks to the Computer Emergency Response Team (CERT), which is trusted to de-anonymise the secret information in order to perform a more in-depth forensic analysis. This is implemented using the encryption key schema in Fig. 4a, where the CERT Team first needs to decrypt the ephemeral key \( EK_{1} \) using its secret key \( SK_{1} \). \( EK_{1} \) is then used to decrypt the encryption key \( K_{1} \), which can be used to decrypt the secret information in security level ‘secret’. The de-anonymiser then replaces the anonymised content in the IDS alarm with the decrypted information. \( EK_{1} \) is regenerated after a given time interval (one day), which allows for reusing it for subsequent de-anonymisation operations for the given user, as long as the key is valid.

Figure 5, shows the full anonymisation policy, created in ViSPE. The policy allows for using symbolic names (for example security level secret), which is easier to understand than the numeric IDs used in the mathematical notation in [3]. Some parts of the obligation attributes are optional for the user to define. These are presented as an oval placeholder which generates the default values if left alone.

The anonymisation specification/decision cache declaration consists of two visual blocks Default policy and Authorized-elements that are mapped to XACML Obligations. The first block specifies the default policy, which is set to default DENY in order to ensure that all information by default is being anonymised (privacy by default). The second block is an XACML Obligation with id authorize-elements, which is performed on successful initial authorisation. This obligation consists of a set of one or more Resource declarations defining XPath expressions of XML resources to be authorised, and Assertion scope declarations which are XPath expressions that can be used for conditional policy evaluation based on document content. These are mapped to XACML AttributeAssignments (simplified to Assignments in ViSPE). The XPath expressions identify XML resources and attributes in the input document which need to be authorised. The next block is the security level declaration, which defines the name of the security level ‘secret’, and the encryption key used to encrypt the security level. The security level ‘secret’ corresponds to level ‘1’ in the mathematical notation in Fig. 4. The encryption key block also contains the time duration until the key needs to be regenerated, in order to reduce the effect of compromised security level keys. The Authorisation map defines the connection between an authorised user or role, the public key associated with this user or role, and the security levels that this user or role has access to. We use an intermediate encryption key (ephemeral key) which acts as an alias for the userFootnote 4. The authorisation map can be defined for a set of one or more users/roles, security levels or key shares.

3.2 Case 2: Reducing Insider Threats

Insider threat is a common problem, particularly for critical infrastructures, where they can have severe consequences. It is important to emphasise that insider threats are not necessarily malicious, but may be the result of responding to a phishing email, or from a simple error. This case study investigates how a critical infrastructure, for example a Smart grid Demand/Response system, can reduce the risk of accidental or malicious deployment of faulty system configurations by implementing a security policy using the graphical XACML editor. Staff may not always have background checks performed before hiring, even in critical infrastructures, and may not receive training in security and privacy. In a pilot study conducted among critical infrastructure providers for the privacy impact assessment developed for the PRECYSE project, it was found that less than half of respondents carried out employee background checks, and half conducted staff training in security and privacy, at least annually.

One way to mitigate both types of insider threat is to implement a multi-party authorisation (MPA) policy; that is to require more than one authorised employee to co-sign for deployment of security-critical configuration changes. If there is a mistake made by an inexperienced employee, or an intentionally malicious change in the new configuration, it should be detected by one of the co-signing parties. This will discourage malicious attacks, as well as encourage employees to do a careful examination of a policy. In the secure policy deployment scenario of this case, a changed policy needs to be examined and co-signed by 2 authorised persons before deployment.

Fig. 6.
figure 6

Encryption scheme for secure deployment of security configurations

Full size image

Policy for Secure Deployment of Configurations in a Smart Grid D/R system. The anonymisation specification consists of a default DENY policy, without declassifying any information, which means that a resource authorisation policy will not be necessary. The security level declaration defines one security level, and the security level encryption key is split into two parts as shown in part (b) of Figs. 4 and 6.

The authorisation map defines the two users/roles: a field engineer who has access to the first key share \( K_{1,1} \), and a test manager who has access to the other key share \( K_{1,2} \). This means that the field engineer and test manager must collaborate on deploying a given system configuration, which reduces the risk of accidentally or maliciously deploying the wrong system configuration. It is necessary that the system configuration file is signed, so that the application installing it can verify and enforce that only trusted system configurations are installed. The signing can either be done explicitly, or one can use the inner signature created by the Anonymiser PEP, which contains a signature of the original document before anonymisation (not shown in the figures). This adds another layer of security in case the field engineer attempts to install the wrong system configuration, or even worse, that a malicious field engineer attempts to install a fake system configuration using a forged digital signature. This is not only a theoretical assumption, since RSA signature forgery attacks based on implementation weaknesses have been demonstrated [8].

Figures 4b, and 6 shows how the encryption scheme works. The field engineer first needs to decrypt his ephemeral key \( EK_{1} \) using his secret key \( SK_{1} \). \( EK_{1} \) is then used to decrypt the first key share \( K_{1,1} \). The test manager unlocks her key share in a similar way by decrypting \( K_{1,2} \) using \( EK_{2} \) decrypted with \( SK_{2} \). The deanonymiser will now add the two keys modulo the key size using the Karnin, Greene and Hellman scheme [9], in order to retrieve the encryption key for security level \( l_{1} \) which stores the encrypted parts of the system configuration file. The deanonymiser then decrypts security level 1, and replaces the anonymised text with the decrypted text. It then verifies that the inner signature of the system configuration is OK and deploys the system configuration. This allows for policy controlled secure deployment of system configurations, in order to reduce the risk of insider threats. This shows one of the simplest key sharing schemes. More elaborate schemes are possible, involving more stakeholders, more key shares, several security levels and more complex policies.

Fig. 7.
figure 7

Anonymiser test scenario

Full size image

3.3 Experiments

We have implemented and tested the privacy-enhanced IDS scenario using the policy in Fig. 5. ViSPE can generate policies for both use cases, but the reversible anonymiser needs some extensions to handle deployment of configuration files. This will be implemented as future work in the SEMIAH project. Figure 7 shows an alarm triggered by the policy from the IDS case, running in the Reversible anonymiser and presented by the PreludeIDS/Prewikka SIEM console. ViSPE is implemented in the Pharo Smalltalk environment. We have previously shown that it has sufficient performance for advanced policy scenarios [4]. The performance of the reversible anonymiser is satisfactory for small to medium-size IDS deployments, as discussed in [3].

4 Discussion

This article illustrates how privacy requirements identified during a privacy impact assessment can be implemented as XACML policies using the Visual Policy Editor (ViSPE). Our graphical editor provides a high-level user interface for designing authorisation and anonymisation policies. This approach works better than existing general purpose XML editors or specialised XACML editors by providing an overview picture of the policy which includes all necessary information required to understand the policy, while hiding much of the syntactic verbosity and complexity of XACML. Another reason why this approach works better can be drawn from analogies in Design Science Research, where users have been shown to be notoriously bad at following deep information, for example hyperlinks, even though they have been explicitly instructed to do so [10]. Providing an overview picture of the entire policy, while hiding unnecessary details therefore provides users with a better understanding of how the underlying policy works. This is also consistent with cognitive load theory, which predicts better learning from leaner presentations [11].

It also avoids defining a high-level policy language which is substantially different from XACML, like several other projects have done, for example the Axiomatics Language for Authorisation (ALFA), the non-technical notation in [12–14] or Ponder2 XACML integration [15]. We believe our approach achieves much of the same goal in terms of usability by providing a simplified graphical representation of XACML, with support for higher level abstractions. It also supports active user feedback on which blocks that fit together in order to reduce the risk of ill formed policies.

Definition of obligations is an optional part of XACML, since the content of the obligation depends on the implementation of the PEP. This makes it difficult to support obligations in general, since these typical are vendor specific extensions. We have however added support for the obligation format of the Reversible anonymiser to ViSPE. This is a clearly defined obligation protocol for anonymising XML documents. As shown in Fig. 5, the use of a graphical editor for building policies simplifies the policy creation process and clarifies the purpose of the policy significantly for the reader.

5 Conclusion

The paper illustrates designing policy-maker-friendly XACML authorisation and anonymisation policies for XML documents or messages using the ViSPE policy editor. The editor implements a novel blocks-based anonymisation language implemented in Smalltalk, and is based on the visual programming language Scratch. The policy editor has been adapted to support the PEP interface of the reversible anonymiser, amongst others by adding specific blocks for anonymising and deanonymising information. The policies can subsequently be enforced using the Reversible anonymiser [3]. This allows for complying with identified security and privacy requirements in order to control access to private or confidential information.

6 Future Work

Future work includes adapting the reversible anonymiser and ViSPE to XACML 3.0 which offers better support for target matching, and obligations. We also plan to extend the reversible anonymiser with logging functionality so that policy makers can give polices different logging obligations, accessible only having correct authorisation. Furthermore, we plan to enhance ViSPE to support GeoXACML, in order to enable location based policies [16], as well as location-aware role-based access control [17, 18]. ViSPE is still an early prototype. We have therefore left usability testing as future work.