Download Report

XACML Privacy Policy Editor for Critical
Infrastructures
Nils Ulltveit-Moe1 , Henrik Nergaard1 , Terje Gjøsæter1 , and Jennifer Betts 2
1 Universitetet
i Agder, Jon Lilletuns Vei 9, 4879 Grimstad, Norway
{nils.ulltveit-moe, henrin10, terje.gjosater}@uia.no
2 School of EEECS Queens University Belfast, Belfast, Northern Ireland
[email protected]
Abstract. This paper describes a Scratch-based eXtensible Access Control
Markup Language (XACML) editor ViSPE that can be used for designing authorisation and anonymisation policies, and how these policies can be enforced
by using the Reversible anonymiser. Private and confidential information can be
protected based on identified security requirements, as described in two case
studies. The first case covers privacy-enhanced IDS-alarm handling in a traffic
control centre, and in the second case, we mitigate insider threats with a secure
configuration deployment policy.
Keywords: XACML· Privacy · Security · Anonymisation · Critical Infrastructure
1
Introduction
This paper demonstrates modelling of privacy and trust policies using a novel highlevel 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: Section 2 covers issues of privacy in
Critical Information Infrastructures (CII), and present 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 Section 5 we make our conclusions. Finally,
Section 6 presents some ideas for future work.
adfa, p. 1, 2011.
© Springer-Verlag Berlin Heidelberg 2011
2
Privacy in Critical Infrastructure
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) system1 in order to demonstrate
privacy-enhanced intrusion detection services, as shown in Fig. 7.
2.1
Privacy Enforcement Mechanism
Fig. 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].
1
https://www.prelude-ids.org
Fig. 1. Overview over XACML anonymisation scheme
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/machinereadable, but not trivial to write without comprehensive editor support. While there are
editors that support writing of XACML policies, like UMU-XACML2 or the WSO2
Identity Server3, 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.
2
3
UMU-XACML editor: http://umu-xacmleditor.sourceforge.net
WSO2 Identity Server: https://docs.wso2.com/display/IS450/Creating+an+XACML+Policy
Fig. 2. The ViSPE editor with resource definition examples
Fig. 3. XACML obligation corresponding to the Declassify resource block
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.
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. The two scenarios
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 deanonymise 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.
IDS Alarm Anonymisation Policy for a Traffic Control Centre
Fig. 5. ViSPE anonymisation policy for the privacy-enhanced IDS case
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 𝐸𝐾1 using its secret key 𝑆𝐾1 . 𝐸𝐾1 is then used to decrypt the encryption key 𝐾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. 𝐸𝐾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.
Fig. 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 user4. 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
PIA 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.
4
Note that this only is a truly ephemeral key if the renegotiation time is set to zero.
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 cosign 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.
Policy for Secure Deployment of Configurations in a Smart Grid D/R system
Fig. 6. Encryption scheme for secure deployment of security configurations
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 Fig. 4, and Fig. 6.
The authorisation map defines the two users/roles: a field engineer who has access
to the first key share 𝐾1,1 , and a test manager who has access to the other key share
𝐾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].
Fig. 4b, and Fig. 6 shows how the encryption scheme works. The field engineer first
needs to decrypt his ephemeral key 𝐸𝐾1 using his secret key 𝑆𝐾1 . 𝐸𝐾1 is then used to
decrypt the first key share 𝐾1,1 . The test manager unlocks her key share in a similar way
by decrypting 𝐾1,2 using 𝐸𝐾2 decrypted with 𝑆𝐾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 𝑙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.
3.3
Experiments
Fig. 7. Anonymiser test scenario
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. Fig. 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) [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 for 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.
Acknowledgements
The project has been sponsored by the FP7 EU projects:


SEMIAH - Scalable Energy Management Infrastructure for Aggregation of
Households, ICT-2013.6.1-619560 (http://semiah.eu).
PRECYSE - Protection, prevention and reaction to cyberattacks to critical infrastructures, FP7-SEC-2012-1-285181 (http://www.precyse.eu);
References
[1]
[2]
[3]
[4]
T. (ed) Moses, OASIS eXtensible Access Control Markup Language (XACML)
Version 2.0. 2005.
N. Ulltveit-Moe and V. Oleshchuk, ‘Decision-cache based XACML authorisation and anonymisation for XML documents’, Comput Stand Interfaces, vol. 34,
no. 6, pp. 527–534, Nov. 2012.
N. Ulltveit-Moe and V. Oleshchuk, ‘A novel policy-driven reversible anonymisation scheme for XML-based services’, Inf. Syst., 2014.
H. Nergaard, N. Ulltveit-Moe, and T. Gjøsæter, ‘A Scratch-based Graphical Policy Editor for XACML’, in ICISSP 2015 Proceedings of the 1st International
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
Conference on Information Systems Security and Privacy ESEO, Angers, Loire
Valley, France, 2015, pp. 182–191.
D. J. Malan and H. H. Leitner, ‘Scratch for Budding Computer Scientists’, in
Proceedings of the 38th SIGCSE Technical Symposium on Computer Science
Education, New York, NY, USA, 2007, pp. 223–227.
M. Resnick, J. Maloney, A. Monroy-Hernández, N. Rusk, E. Eastmond, K. Brennan, A. Millner, E. Rosenbaum, J. Silver, B. Silverman, and Y. Kafai, ‘Scratch:
Programming for All’, Commun ACM, vol. 52, no. 11, pp. 60–67, Nov. 2009.
A. Cavoukian, S. Taylor, and M. E. Abrams, ‘Privacy by Design - Essential for
Organizational Accountability and Strong Business Practices’, Identity Inf. Soc.,
vol. 3, no. 2, pp. 405–413, 2010.
Intel Security, ‘BERserk Vulnerability Part 1: RSA signature forgery attack due
to incorrect parsing of ASN.1 encoded DigestInfo in PKCS#1 v1.5’. Intel, 2014.
J. G. E. Karnin and M. Hellman, ‘On Secret Sharing System’, IEEE Trans Info
Theory, vol. IT-29, pp. 35–41, Jan. 1983.
B. Kuechler and V. Vaishnavi, ‘On theory development in design science research: anatomy of a research project’, Eur. J. Inf. Syst., vol. 17, no. 5, pp. 489–
504, 2008.
R. E. Mayer and J. Jackson, ‘The Case for Coherence in Scientific Explanations:
Quantitative Details Can Hurt Qualitative Understanding’, J. Exp. Psychol.
Appl., vol. 11, no. 1, pp. 13–18, 2005.
B. Stepien, S. Matwin, and A. Felty, ‘Advantages of a non-technical XACML
notation in role-based models’, in 2011 Ninth Annual International Conference
on Privacy, Security and Trust (PST), 2011, pp. 193–200.
B. Stepien, A. Felty, and S. Matwin, ‘A Non-technical User-Oriented Display
Notation for XACML Conditions’, in E-Technologies: Innovation in an Open
World, vol. 26, Springer Berlin Heidelberg, 2009, pp. 53–64.
B. Stepien, A. Felty, and S. Matwin, ‘A Non-Technical XACML Target Editor
for Dynamic Access Control Systems’, IEEE, pp. 150–157, 2014.
H. Zhao, J. Lobo, and S. M. Bellovin, ‘An Algebra for Integration and Analysis
of Ponder2 Policies’, in IEEE Workshop on Policies for Distributed Systems and
Networks, 2008. POLICY 2008, 2008, pp. 74–77.
A. M. (ed), OGC 07-026r2 Geospatial eXtensible Access Control Markup Language (GeoXACML) version 1.0. Open Geospatial Consortium, Inc., 2007.
N. Ulltveit-Moe and V. Oleshchuk, ‘Enforcing mobile security with locationaware role-based access control’, Secur. Commun. Netw., p. n/a–n/a, 2013.
N. Ulltveit-Moe and V. Oleshchuk, ‘Mobile Security with Location-Aware RoleBased Access Control’, in Security and Privacy in Mobile Information and Communication Systems, vol. 94, R. Prasad, K. Farkas, A. U. Schmidt, A. Lioy, G.
Russello, F. L. Luccio, O. Akan, P. Bellavista, J. Cao, F. Dressler, D. Ferrari, M.
Gerla, H. Kobayashi, S. Palazzo, S. Sahni, X. (Sherman) Shen, M. Stan, J. Xiaohua, A. Zomaya, and G. Coulson, Eds. Springer Berlin Heidelberg, 2012, pp.
172–183.