User-friendly and Tailored Policy Administration Points

Manuel Rudolph

Fraunhofer IESE, Fraunhofer-Platz 1, Kaiserslautern, Germany

1 RESEARCH PROBLEM

Today, more and more sensitive personal and

business-related data is collected and processed. Se-

curity solutions aim to protect such data from misuse,

but often come along with usability issues (Gutmann

and Grigg, 2005).

Security policies are an established instrument for

specifying security demands. Policy Administration

Points (PAPs) offer a policy vocabulary, which the

policy creator can use to express the desired security

demand as a security policy. Such security policies

and the security mechanisms to which they refer can

become very complex. Mistakes in the speciﬁcation

of security policies lead to misbehavior in the secu-

rity mechanisms, which can cause, for instance, un-

intended data leakage and may convey a false feeling

of security to the policy creator. Hence, speciﬁcation

mistakes must be minimized by providing appropriate

PAPs that guide the policy creator in the best possible

way through the policy speciﬁcation process.

A well-known example for a PAP used by non-

professionals is the Facebook menue for privacy and

security settings. A study from Liu et al. revealed that

users in many cases expected a different effect from

their speciﬁed privacy settings than it was in reality

(Liu et al., 2011), which indicates a wrongly speciﬁed

security policy.

Intuitive and user-friendly usability of a PAP is, in

my opinion, a basic requirement when letting users

specify security policies. However, most current

PAPs are neither easy to use nor easy to understand

for less experienced policy creators. Examples for

PAPs that do not sufﬁciently consider usability issues

range from the Windows Local Group Policy Editor

for managing the security settings of Windows clients

to the PERMIS Policy Editor (Chadwick and Otenko,

2003; University of Kent, 2011) for specifying role

based access control policies.

One problem is that most PAPs that have been

found during a preliminary state of the practice re-

search were designed generically to be used by dif-

ferent policy creator types, in different domains, or

even both. This generality causes an overly high ex-

pressiveness of PAPs, which inevitably increases the

complexity of the speciﬁcation process as well as of

the PAP implementation. Higher complexity is likely

to increase the error-proneness of policy speciﬁca-

tion. In addition, in an organization with several types

of policy creators that have different permissions for

specifying security policies, an overly expressive PAP

may allow policy creators to specify security policies

for which they do not have clearance.

To avoid these problems, two essential steps to-

ward more usable PAPs are suggested. First, PAP de-

signers should aspire toward reducing the complexity

and expressiveness of the security policy vocabulary

and the policy speciﬁcation process by better tailor-

ing them to the respective application domain and to

the expected user community. Second, PAPs should

be made more user-friendly, especially for less expe-

rienced policy creators.

Thus, the following essential research question is

addressed:

How can we efﬁciently develop Policy Administra-

tion Points that are providing a user-friendly security

policy speciﬁcation process with a security policy vo-

cabulary tailored to the application domain and the

policy creator?

2 TERMINOLOGY

In this paper, we use the following terminology:

• Application Domain Model: Set of entities, activ-

ities, and assets in a system or an organization to

which elements of a security policy refer and their

relation in the context of the application domain.

• Application Domain Meta Model: Model deﬁning

the syntax and semantics of an application domain

model.

• Security Policy Language: Grammar to formulate

security policies in a uniﬁed format used in secu-

rity policy templates.

• Security Policy Template: Security policy pattern

formulated in the security policy language that

can be instantiated to a security policy.

Rudolph M..

User-friendly and Tailored Policy Administration Points.

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

Figure 1: Terminology.

• Security Policy Constraint: Constraint that ap-

plies to security policy templates describing a re-

striction to a security policy template or a depen-

dency between two or more security policy tem-

plates within a security policy model.

• Security Policy Model: Application domain-

speciﬁc model that links security policy templates

and security policy constraints as well as addi-

tional properties to the security policy templates.

• Security Policy Meta Model: Model deﬁning the

syntax and semantics of a security policy model.

• Security Policy Vocabulary: Subset of the security

policy model speciﬁcally tailored to the needs of

the policy creator and the expected policy usage

context.

• Policy Administration Point: Human-Computer-

Interface that consumes a security policy vocabu-

lary to provide a set of security policy templates

that can be instantiated as security policies for the

speciﬁcation of security demands.

• Policy Creator: Entity that has a security demand

and speciﬁes it as a security policy using a Policy

Administration Point.

• Security Policy: Instance of a security policy tem-

plate that describes the intended behavior of the

policy enforcement components in a system in a

given situation.

– Speciﬁcation-level Policies: Description of

what must and must not happen throughout the

execution of a system or within an organization.

– Implementation-level Policy: Reﬁnement of

speciﬁcation-level policies stating how the

speciﬁcation-level policies will actually be en-

forced.

• Security Model: Collection of application domain

independent, recurring security mechanisms.

• Security Meta Model: Model deﬁning the syntax

and semantics of a security model.

The relation between the different elements is

shown in Figure 1. Recall that the application domain

model describes the entities that perform activities on

assets in a given application domain. Some of the ac-

tivities on assets are malicious and declared as threats.

The threats from the application domain model are

used in security policy templates to describe a situa-

tion which must be prevented or at least mitigated. In

addition, security policy templates deﬁne reactions or

countermeasures to speciﬁc threats that actually can

prevent or mitigate these threats. Security policy tem-

plates are formulated in a natural language-based se-

curity policy language.

3 OUTLINE OF OBJECTIVES

The research question can be broken down into three

main objectives. First, a security policy model for

organizing security demands in the form of security

policies or security policy templates must be elabo-

rated that can generate tailored security policy vocab-

ularies. Second, an elicitation method for gathering

security demands from an application domain and ﬁll-

ing the security policy model must be devised. Third,

a usability-enhanced PAP that can consume a security

policy vocabulary must be developed.

ICISSP2015-DoctoralConsortium

3.1 Security Policy Model

Currently, there is a lack of management solutions

for security policies. In practice, security policies are

written in natural language in a document and must

then be deployed either in an organizational or in a

technical manner. For each special case, a new set of

security policies must be adapted from existing docu-

ments or developed from scratch. Deﬁning or diver-

sifying security policies at runtime is even harder, if

supported at all. Furthermore, it is complicated and

time-consuming to model and disclose dependencies

between security policies.

To facilitate security management, an appropriate

model for security policies helps. The security policy

model must be able to store security policies and secu-

rity policy templates in a uniﬁed form, to link security

policies to each other in order to deﬁne dependencies,

and to integrate restrictions that apply to security poli-

cies in a speciﬁc application domain.

If different individuals in an organization are em-

powered to specify security policies, new challenges

arise. An individual may be allowed to specify secu-

rity policies only from a limited security policy vo-

cabulary. Accordingly, not all valid security poli-

cies might be allowable due to restricted policy en-

titlement of individual policy creators. A central

organization-wide security policy model can be en-

riched with information about permissions, restric-

tions, and other properties with respect to security

policies.

The reusability of security policy model instances

should be investigated because instantiating a security

policy model from scratch for every application do-

main would be a very effort-consuming process. To

improve reuse of security policy knowledge, security

policies and security policy templates that are used in

different application domains should be generalized

and stored as a security model that acts as a knowl-

edge base.

The essential research question thus is: How must

a security policy model look like that is capable of

managing and linking security policy templates and

corresponding security policy constraints?

3.2 Elicitation of Security Demands

from an Application Domain

There are a lot of security guidelines that provide

countless potential security policies as recommenda-

tions for organizations and their information systems.

But it remains a challenge to select the appropriate

policies for a concrete case. Furthermore, standard

security policies do not reﬂect the speciﬁc character-

istics of an organization or its information systems.

Thus, security policies must be adapted to their appli-

cation context.

Having only a standardized set of security policies

that always applies leaves little scope for case-by-case

security decisions. In some cases, users or administra-

tors must be enabled to specify security policies that

deviate from the standard policies. Therefore, they

use PAPs. A generic PAP to specify any kind of se-

curity policy might be too powerful or too generic—

and therefore too complicated—for the average policy

creator.

Depending on the application domain in which the

PAP will be used for specifying security policies, dif-

ferent requirements exist with respect to IT security.

To reduce the complexity of a PAP and to tailor it to

a given domain, a domain-speciﬁc security policy vo-

cabulary is necessary. This requires a domain-speciﬁc

instantiation of the security policy model. The in-

stantiation of the model demands a domain-speciﬁc

elicitation of security policies. Because the security

policies that the policy creator want to specify may

differ from case to case, case-speciﬁc security policy

templates must be provided. Therefore, the general

schema of relevant security policies needs to be ana-

lyzed. In doing so, varying elements of the policy can

be identiﬁed and declared as variables. Variables can

be either single parameters or policy elements, such as

additional actions or conditions. For each policy tem-

plate, security policy constraints, such as valid param-

eter values or dependencies on other policy templates,

need to be elicited.

So far, no established method is known to me

for eliciting the information necessary to instantiate

a security policy model with security policy tem-

plates and security policy constraints. Devising such

a method is proposed in this thesis.

The essential research question is: How can we

systematically elicit security policy templates includ-

ing security policy constraints from an application

domain?

3.3 User-friendly Policy Administration

Points

A PAP enables a policy creator to specify a secu-

rity policy. Depending on the application domain,

the PAP must support the speciﬁcation of varying sets

of security policies. It would be a huge effort to de-

velop PAPs for each application domain from scratch.

Therefore, generic customizable PAPs should be de-

veloped that can be conﬁgured to adapt to the given

application domain. Basically, we strive for a PAP

that is adapted to the application domain simply by

User-friendlyandTailoredPolicyAdministrationPoints

Figure 2: Schematic overview of the framework.

importing a suitable security policy vocabulary.

Different types of policy creators shall be enabled

to specify security policies. These policy creators

have different background knowledge about security,

technology, or about the speciﬁc domain. Therefore,

each policy creator type needs a different level of ﬂex-

ibility, usability, and guidance during the policy spec-

iﬁcation process, and the expressiveness of the PAP

must be adapted accordingly.

One way to regulate expressiveness is to change

the speciﬁcation paradigm. Policy creators can have

varying degrees of freedom depending on the speci-

ﬁcation paradigm offered by the PAP. A speciﬁcation

paradigm with a low expressiveness is, for instance, a

list of predeﬁned security policies the policy creator

can select from. In relation, a wizard for combining

and instantiating parameterized policy templates is a

speciﬁcation paradigm with a higher expressiveness.

The expressiveness of the PAP is also regulated

by the imported security policy vocabulary. Note that

the security policy vocabulary is only a subset of the

policy model. Vocabulary extraction is regulated by

ﬁltering mechanisms. Filter criteria can be, for exam-

ple, the permission model inside the security policy

model or parameters of the security policy templates,

such as the linked security principle. Furthermore, the

PAPs can be enriched with guidance functionality to

tailor them to the individual policy creator type.

The essential research question thus is: How can

usable Policy Administration Points for a speciﬁc type

of policy creators be developed that self-adapt to a

security policy vocabulary?

4 EXPECTED OUTCOME

The expected outcome is a method that tailors PAPs

and the policy vocabulary to the requirements of an

application domain and the policy creators (see Fig-

ure 2). The method consists of the following steps:

• elicitation of security policy templates and con-

straints from various stakeholders within the ap-

plication domain

• instantiation of the security policy model with the

elicited information

• extraction of a tailored policy vocabulary

• conﬁguration of usability-enhanced PAPs using

the policy vocabulary

The proposed method extends the state of the art

by supporting the systematic identiﬁcation of proper

sources for security policies within an application do-

main and their methodical assessment for eliciting

the domain-speciﬁc policies. In addition, a security

policy model will be suggested that improves policy

management by allowing to express dependencies be-

tween different policies as well as constraints for in-

dividual policies. Based on this policy model and

the systematic elicitation of domain-speciﬁc policies,

PAPs for end users are better tailored to the speciﬁc

security demands of the various policy creator types

in an application domain and are made more usable.

The following measurable beneﬁts are expected when

using the proposed method:

• Due to higher usability and user speciﬁc tailoring,

policy speciﬁcation in PAPs becomes less error-

ICISSP2015-DoctoralConsortium

prone, which results in fewer wrongly speciﬁed

security policies.

• The process of policy speciﬁcation becomes more

intuitive, easier to use, and less time-consuming

even with limited background knowledge and

minimal or no prior user training, which increases

the acceptance of a policy enforcement mecha-

nism such as data usage control both by the user

and the enterprise.

• The development effort for providing tailored

PAPs is reduced.

5 STAGE OF THE RESEARCH

The research is in its beginning, but ﬁrst results have

been achieved and partially published.

A preliminery state of the art research on the three

main research questions and a state of the practice re-

search on existing policy speciﬁcation tools have been

conducted.

A ﬁrst version of the policy elicitation methodol-

ogy has been proposed, tested with partners within

a European project, and published (Rudolph et al.,

2014). Further improvements and tests will follow.

Two prototypes of usable and adaptive Policy Ad-

ministration Points are under development. Each PAP

implements a different policy speciﬁcation paradigm.

Building ﬁrst adaptive PAP prototypes very early

will allow to derive requirements from bottom-up for

the policy vocabulary and the security policy model.

The development of the elicitation methodology will

in addition provide requirements from the top-down

perspective.

A ﬁrst draft version of the syntax and the seman-

tics of the underlying policy vocabulary have been de-

veloped. Manually written policy vocabularies can be

consumed by the PAP prototypes, which then self-

adapt to the given vocabulary. One of those PAPs

is currently being integrated in an industrial setting.

In the future, the policy vocabulary will be generated

from a security policy model, which is still under de-

velopment.

6 METHODOLOGY

This section describes the plans for achieving the

three main objectives presented before. The three ob-

jectives will not be tackled in strict order but partially

in parallel in order to use insights gathered from one

objective in another one.

6.1 Security Policy Model

For elaborating the security policy model, the follow-

ing steps are planned:

1. The results of the preliminary state of the art re-

search as well as the gathered insights from the

draft versions of the policy elicitation methodol-

ogy and the adaptive PAP prototypes will be ana-

lyzed to deﬁne requirements for the security pol-

icy model.

2. Before the security policy model can be devel-

oped, security policies must be better understood.

The elements and characteristics of security poli-

cies must be analyzed. Therefore, exemplary se-

curity policies from different application domains

are collected and compared. Generic elements

of those policies are identiﬁed. Rules that deﬁne

valid combinations of the policy elements are de-

termined. From these results, a security policy

language is derived. For testing the security pol-

icy language, security policies from different do-

mains are formulated using the policy language.

3. An object-oriented security policy model is de-

veloped that is capable of storing security pol-

icy templates. One possible template for the pol-

icy “Each MP3 ﬁle may only be opened 3 times”

could be “<ﬁletype> may only be opened <n>

times”. Security policy templates are formulated

in the security policy language and can therefore

be split in their elemental parts. Elements of the

policy templates may be combined into new pol-

icy templates. The model should also be capable

of storing security policies as instances of secu-

rity policy templates and linking them to the cor-

responding template. Additional parameters may

be attached to the security policy templates. Ex-

amples are, for instance, a permission model that

deﬁnes allowable policy creators, or ﬂags that dif-

ferentiate between technically and organization-

ally enforceable as well as between speciﬁcation-

level and implementation-level security policies.

This differentiation becomes relevant for map-

ping a speciﬁcation-level policy to correspond-

ing reﬁned implementation-level policies. In prin-

ciple, PAPs can specify speciﬁcation-level poli-

cies without any concrete technical enforcement

mechanism as well as precise implementation-

level policies. The former can be either reﬁned

to implementation-level policies or released as an

organizational rule to be enforced in an arbitrary

non-technical way. Dependencies between pol-

icy templates can be modeled as object relations,

for example, to map speciﬁcation-level policies to

implementation-level policies. The categorization

User-friendlyandTailoredPolicyAdministrationPoints

of policy templates and their mapping to security

properties is also supported. In addition, descrip-

tions that explain the effect on the target, depend-

ing on whether the policy is or is not deployed,

can be attached to policies. It must be researched

which additional information is necessary in the

security policy model.

4. The security policy templates can be instantiated

by policy creators to express their security de-

mands. Depending on the application domain or

on the policy creator, there may exist constraints

regarding security policies allowable for deploy-

ment. For example, not all security policy tem-

plates or not all parameter values within a secu-

rity policy template may be allowed for the in-

stantiation of a security policy template. Thus,

a predeﬁned selection of parameter values or pa-

rameter thresholds should be determined. Further-

more, dependencies between policies can be con-

strained. For instance, repelling or attracting poli-

cies may exist in the application domain. Exam-

ples for repelling policies could be contradictory

policies such as ”Business documents must not be

opened outside the enterprise premises“ and ”All

documents can be opened at home after entering a

password“.

5. It is planned to evaluate the suitability of the secu-

rity policy language and the security policy model

by instantiating security policy models with se-

curity policies from two different application do-

mains. As, so far, no method for eliciting secu-

rity policies from the application domain has been

elaborated, the author assumes that a complete list

of security policy templates and corresponding se-

curity policy constraints is available. The elici-

tation method proposed in Section 6.2 will, after

being elaborated, be used to provide such a list. It

will be tested in a case study whether all security

policy templates and security policy constraints

can be inserted into the model and all necessary

relations and dependencies can be modeled.

6. A comparison of the two security policy models

shall reveal opportunities to reuse security knowl-

edge for another application domain. If this is

possible, a generic security model acting as a

knowledge base could be elaborated. The model

will comprise common security characteristics of

assets. For example, regularly used security prin-

ciples such as conﬁdentiality, integrity, or avail-

ability can be described in the model. Those fun-

damental security characteristics can probably be

stored as generic security policy templates. Thus,

such a model can reveal security policy templates

that should be considered during the policy elici-

tation in an application domain to establish a con-

sistent level of security.

6.2 Elicitation of Security Demands

from an Application Domain

It is planned to devise the security demand elicitation

method in the following way:

1. Before security policy templates and security pol-

icy constraints can be elicited in an application do-

main, the domain itself must be better understood.

It must be clariﬁed what kind of relevant elements

exist in the application domain and what kind

of relations exist among them. Elements could

be entities that perform actions, actions that can

be performed, and assets deserving protection on

which actions can be performed. Together, an ad-

verse action performed by an unauthorized entity

on a valuable asset describes a threat. In addition,

security-related properties of entities and assets

should be considered. A domain model is pro-

posed that describes the elements and their rela-

tions in the domain. It will be researched whether

elements of the domain model can be mapped to

or related to elements in the security policy model.

Such mappings and relations can support the elic-

itation of security policies. The application do-

main model must be instantiated for each applica-

tion domain in cooperation with domain experts

before starting the security policy elicitation.

2. To be able to gather security policies, proper in-

formation sources must be identiﬁed. Potential

sources can be different stakeholders in the ap-

plication domain, such as system operators, se-

curity ofﬁcers, requirements engineers, or end

users. Entities from the application domain model

can be stakeholders, too. Existing documenta-

tion regarding security guidelines, enterprise reg-

ulations, and legal obligations can be additional

sources for relevant security policy templates. A

list of the generally most promising information

sources should be elaborated as a starting point

for each policy elicitation. A method for identify-

ing additional sources will be proposed.

3. Security policies are systematically retrieved from

the identiﬁed stakeholders. Requirements engi-

neering techniques are used for the elicitation of

security policies from stakeholders and other in-

formation sources. To this end, the most appro-

priate requirements engineering techniques in the

state of the art must be identiﬁed and probably

adapted for eliciting security policies. The do-

main model instance and the security model will

ICISSP2015-DoctoralConsortium

help to focus on the relevant assets in the respec-

tive application domain. It must be researched

what kind of security policy level (speciﬁcation-

level policies, implementation-level policies, or

both) can and should be collected during the elici-

tation phase. In addition, it must be determined

which part of the security policy templates can

by elicited from which source. Stakeholders can

demand speciﬁc reactions on threats, and techni-

cal experts must validate whether those demands

are technically enforceable. Security policies are

elicited in natural language and split into their ba-

sic elements, and their structure is speciﬁed in the

security policy language. Parameterizable parts of

the policy are identiﬁed and security policy tem-

plates are created. These templates and the corre-

sponding security policy instantiations are stored

in the security policy model.

4. Besides the actual security policies, we may

need to determine additional security policy con-

straints. Recall that collected security policies are

parameterized and used as templates; but not all

feasible parameter values may be allowed in the

given domain. Thus, a predeﬁned selection of

parameter values or parameter thresholds should

be determined. Additionally, information about

attracting and repelling policies should be deter-

mined. A list of relevant security policy constraint

types is elaborated and a method for gathering

those is developed. Security policy constraints are

stored in the security policy model and linked to

the corresponding security policy templates.

6.3 User-friendly Policy Administration

Points

It is planned to develop PAP prototypes consuming

tailored policy vocabularies in order to evaluate their

usability and effectivity:

1. The security policy vocabulary that the policy cre-

ator can use in the PAP must be extracted from

the security policy model. The security policy vo-

cabulary is a subset of the security policy model

and contains all information that the policy creator

needs when specifying a security policy. It must

be researched which information is necessary for

the PAP to enable policy creators to specify their

individual security policies. The necessary infor-

mation depends on the speciﬁcation paradigm of

the PAP. Examples for speciﬁcation paradigms are

the selection of predeﬁned security policies, the

instantiation of security templates with a prede-

ﬁned set of parameters, or the combination of dif-

ferent policy elements to a security policy. The se-

curity policy vocabulary for a speciﬁc PAP must

be extracted from the security policy model and

imported into the PAP. Therefore, a data format

for storing a security policy vocabulary must be

developed. It must be capable of storing security

policy templates and security policy constraints

as well as their relations. Additional information

about security policies may be attached. The se-

curity policy model is extended by an export ﬁlter

that extracts only necessary information into the

security policy vocabulary.

2. State-of-the-practice usability concepts are col-

lected and rated regarding their applicability to

PAPs and the policy speciﬁcation process. In ad-

dition, existing policy speciﬁcation tools are ana-

lyzed regarding their usability.

3. Different generic customizable PAP prototypes

are developed. These PAPs are designed for dif-

ferent policy creator types and differ in their spec-

iﬁcation paradigms. Such a PAP can import a se-

curity policy vocabulary and self-adapt to it. A

policy creator using the adapted PAP can specify

all security policies that are valid according to the

security policy templates and security policy con-

straints deﬁned in the selected security policy vo-

cabulary. Besides tailoring the PAP to the char-

acteristics of different policy creator types, the

collected usability concepts are considered during

the development of the PAP to provide the policy

creator with a more user-friendly security policy

speciﬁcation process.

4. Finally, the tailored PAPs and the extracted secu-

rity policy vocabularies are evaluated. The evalu-

ations of these two targets must be separated be-

cause an insufﬁcient quality of the security policy

vocabulary would most probably negatively affect

the evaluation of the PAP using this vocabulary.

The evaluation of the proposed method will be

carried out in application domains different from

the one used for developing the security policy

model, the PAPs, and the elicitation method. This

shall demonstrate that the applicability of the pro-

posed method is not restricted to a speciﬁc set

of application domains. The quality attributes

to be evaluated are effectiveness, efﬁciency, un-

derstandability, and user satisfaction, which—if

increased—collectively lead to a higher usability

of the PAPs. Satisfaction can be measured by the

subjective feedback of the test persons, efﬁciency

by the time needed to specify security policies,

effectiveness by the fraction of correctly speci-

ﬁed security policies, and understandability by the

fraction of correctly speciﬁed security policies in

User-friendlyandTailoredPolicyAdministrationPoints

relation to the test persons’ estimations of cor-

rectly speciﬁed security policies. The effect of

different complexities of security policies on the

speciﬁcation process must be considered during

the evaluation. A ﬁrst controlled experiment will

evaluate the security policy vocabulary. PAPs us-

ing the already evaluated security policy vocabu-

lary will be evaluated in a second controlled ex-

periment. In summary, three parameters inﬂuence

the evaluation and must be taken into account: the

complexity of the security policies, the applica-

tion domain, and the PAPs chosen. Thus, several

exercises to describe security demands that can be

speciﬁed as security policies using the proposed

security policy vocabulary will be assigned to the

probands in the controlled experiments. The dif-

ferent exercises lead to security policies of differ-

ent complexity. In the ﬁrst controlled experiment,

security policies must be formulated in natural

language on paper, using a printed and human-

readable version of the security policy vocabulary

(i.e., policy templates and policy constraints). In

the second controlled experiment, two different

PAPs are instantiated with the already evaluated

security policy vocabulary and are used by the

probands to specify the same security policies as

in the preceding exercises. To prevent a learning

effect, a proband from the ﬁrst experiment may

not take part in second one.

7 STATE OF THE ART

The tailoring of PAPs involves the three main sub

problems policy elicitation, policy modeling and pol-

icy speciﬁcation. Below, the related work covering

the respective problem domains is brieﬂy surveyed.

The elicitation of security policy templates is re-

lated to the elicitation of security requirements and

risks. To this end, the whole spectrum of standard

techniques for requirements engineering (Tenerow-

icz, 2008), such as structured interviews of the in-

volved stakeholders or creativity workshops assessing

security issues, and risk assessment methodologies

(Smith et al., 2013) can be used in principle as well as

(mis)use case modeling (Alexander, 2003; McGraw,

2006). Mead et al. propose Security Quality Require-

ments Engineering (SQUARE) as a systematic pro-

cess for eliciting security requirements (Mead et al.,

2005; U.S. Computer Emergency Response Team,

2007), but without describing speciﬁc elicitation tech-

niques. However, most of the proposed elicitation

methods are not tailored to and have not been eval-

uated in the speciﬁc context of security requirements

or policy elicitation, respectively. The elicitation step

proposed in this paper will use state-of-the-art tech-

niques for the elicitation of security demands from

various sources. It must be evaluated which tech-

niques lead to the best results depending on the type

of information source.

Valuable sources for general security demands can

be security checklists, control question catalogs, and

security ontologies that have been proposed in the

literature (U.S. National Institute of Standards and

Technology, 2014; U.S. National Institute of Stan-

dards and Technology, 2008; German Bundesamt f

Sicherheit in der Informationstechnik, 2005; Com-

mon Criteria Maintenance Board, 2012; U.S. Depart-

ment of Defense, 1985). The elicitation step will con-

sider those sources.

Several policy enforcement frameworks have been

described in the literature, some of which include se-

curity policy models or PAPs, respectively.

SPARCLE (Vaniea et al., 2008; Karat et al., 2009)

is a security and privacy policy framework for en-

forcing access control policies. It transforms policies

speciﬁed in constrained natural language into a for-

mal language and later in a machine-readable repre-

sentation. It analyzes the formal policies, identiﬁes

conﬂicts and dominance relations, determines policy

coverage, and provides suggestions for conﬂict reso-

lution. In (Vaniea et al., 2008), Vaniea et al. report

on experimental evaluations of improving the usabil-

ity of policy speciﬁcations. Compared to SPARCLE,

my framework is not limited to access control poli-

cies. It uses, for example, adjustable security policy

templates in natural language as the policy speciﬁca-

tion paradigm instead of constrained natural language

as SPARCLE does. Furthermore, the usability pat-

terns applied to SPARCLE’s PAP are different from

the ones planned to be applied to the proposed frame-

work’s PAPs, which are described in (Vollat, 2012).

KAoS (Institute for Human & Machine Cogni-

tion, 2013) is a set of platform-independent services

that enable users to specify and enforce security, pre-

dictability, and controllability policies. KAoS deﬁnes

a policy as an enforceable, well-speciﬁed constraint

on the performance of machine-executable actions by

a subject in a given situation. KAoS policies, ex-

pressed in Web Ontology Language (OWL2) (World

Wide Web Consortium, 2012), can be speciﬁed as au-

thorization policies and obligation policies, but other

types of policies can be constructed from these two

primitive types. KAoS provides a PAP for experts that

is neither tailored to a speciﬁc application domain nor

provides a user-friendly speciﬁcation process for non-

experts, as it is intended in my framework.

Another approach for the elicitation and repre-

ICISSP2015-DoctoralConsortium

sentation of security constraints is Secure Tropos

(Mouratidis and Giorgini, 2007). The Tropos method-

ology aims to model security concerns throughout

the whole development process. The Secure Tro-

pos paradigm is based on agent-oriented software

engineering and centers around the concepts of ac-

tors, their goals, obligations, capabilities, security

constraints, and dependencies. The notation used

is based on UML, and constraints can be formally

expressed (and veriﬁed) with the Object Constraint

Language (OCL) (Object Management Group, 2014).

The stakeholder and security requirements identiﬁca-

tion used in Secure Tropos is another option that could

be used in my approach, but its applicability has not

yet been tested.

In addition to the already mentioned policy frame-

works, there are various other policy languages for

the speciﬁcation of machine-readable policies, for ex-

ample the Ponder language (Damianou et al., 2001),

SSPL (Al-Morsy and Faheem, 2009) or Rei (Kagal

et al., 2003). For a brief overview of available policy

languages, see (De Coi and Olmedilla, 2008; World

Wide Web Consortium, 2012).

ACKNOWLEDGEMENTS

The research presented in this paper is supported

by the German Ministry of Education and Research

projects Software Campus (grant number 01IS12053)

and Software-Cluster SINNODIUM (grant number

01IC12S01F) as well as by the European Commis-

sion in the context of the Research Framework Pro-

gram Seven (FP7) project SECCRIT (Grant Agree-

ment No. 312758). The sole responsibility for the

content of this document lies with the author.

REFERENCES

Al-Morsy, M. and Faheem, H. (2009). A new standard secu-

rity policy language. Potentials, IEEE, 28(2):19–26.

Alexander, I. (2003). Misuse cases: use cases with hostile

intent. Software, IEEE, 20(1):58–66.

Chadwick, D. W. and Otenko, A. (2003). The permis x. 509

role based privilege management infrastructure. Fu-

ture Generation Computer Systems, 19(2):277–289.

Common Criteria Maintenance Board (2012). Common

Criteria for Information Technology Security Evalua-

tion, CCv3.1 Revision 4 (CCMB-2012-09-001, -002,

-003). http://www.commoncriteriaportal.org/cc/.

Damianou, N., Dulay, N., Lupu, E., and Sloman, M. (2001).

The ponder policy speciﬁcation language. In Slo-

man, M., Lupu, E., and Lobo, J., editors, Policies

for Distributed Systems and Networks, volume 1995

of Lecture Notes in Computer Science, pages 18–38.

Springer Berlin Heidelberg.

De Coi, J. L. and Olmedilla, D. (2008). A review of trust

management, security and privacy policy languages.

In SECRYPT, pages 483–490. Citeseer.

German Bundesamt f

ur Sicherheit in der Information-

stechnik (2005). BSI: IT-Grundschutz Catalogues.

https://www.bsi.bund.de/EN/Topics/ITGrundschutz/

itgrundschutz.html (a more recent ver-

sion from 2013 in German is available at

https://www.bsi.bund.de/DE/Themen/ITGrundschutz

/itgrundschutz node.html).

Gutmann, P. and Grigg, I. (2005). Security usability. Secu-

rity Privacy, IEEE, 3(4):56–58.

Institute for Human & Machine Cognition (2013).

KAoS Policy Services Framework: User Guide.

http://ontology.ihmc.us/KAoS/KAoSUsersGuide.pdf.

Kagal, L., Finin, T., and Joshi, A. (2003). A policy language

for a pervasive computing environment. In Policies

for Distributed Systems and Networks, 2003. Proceed-

ings. POLICY 2003. IEEE 4th International Workshop

on, pages 63–74.

Karat, J., Karat, C.-M., Bertino, E., Li, N., Ni, Q., Brodie,

C., Lobo, J., Calo, S. B., Cranor, L. F., Kumaraguru,

P., and Reeder, R. W. (2009). Policy framework for

security and privacy management. IBM J. Res. Dev.,

53(2):242–255.

Liu, Y., Gummadi, K. P., Krishnamurthy, B., and Mislove,

A. (2011). Analyzing facebook privacy settings: User

expectations vs. reality. In Proceedings of the 2011

ACM SIGCOMM conference on Internet measurement

conference, pages 61–70.

McGraw, G. (2006). Software security: building security

in, volume 1. Addison-Wesley Professional.

Mead, N. R., Hough, E., and Jr., T. R. S. (2005). Se-

curity Quality Requirements Engineering (SQUARE)

Methodology. Technical Report CMU/SEI-2005-TR-

009, Software Engineering Institute, Carnegie Mellon

University, Pittsburgh, PA.

Mouratidis, H. and Giorgini, P. (2007). Secure tropos: A

security-oriented extension of the tropos methodol-

ogy. International Journal of Software Engineering

and Knowledge Engineering, 17(02):285–309.

Object Management Group (2014). Object Constraint Lan-

guage (OCL). http://www.omg.org/spec/OCL/.

Rudolph, M., Schwarz, R., and Jung, C. (2014). Security

policy speciﬁcation templates for critical infrastruc-

ture services in the cloud. (in press).

Smith, P., Busby, J., Langer, L., Sch

oller, M., and

Shirazi, N. (2013). SECCRIT Deliverable D3.1

Methodology for Risk Assessment and Management.

https://seccrit.eu/publications/publicreports.

Tenerowicz, C. L. (2008). Elicitation Techniques.

https://conﬂuence.cornell.edu/display/BAF/Elicitation

+Techniques.

University of Kent (2011). Permis.

http://sec.cs.kent.ac.uk/permis/index.shtml.

U.S. Computer Emergency Response Team (2007).

SQUARE - Requirements Engineering for Improved

System Security.

User-friendlyandTailoredPolicyAdministrationPoints

U.S. Department of Defense (1985). DoD 5200.28-

STD: Trusted Computer System Evaluation Criteria.

http://csrc.nist.gov/publications/history/dod85.pdf.

U.S. National Institute of Standards and Technology (2008).

NIST Special Publication 800-55, Revision 1: Perfor-

mance Measurement Guide for Information Security.

http://csrc.nist.gov/publications/PubsSPs.html.

U.S. National Institute of Standards and Technology

(2014). NIST Special Publication 800-53, Re-

vision 4: Security and Privacy Controls for

Federal Information Systems and Organizations.

http://csrc.nist.gov/publications/PubsSPs.html.

Vaniea, K., Karat, C.-M., Gross, J. B., Karat, J., and Brodie,

C. (2008). Evaluating assistance of natural language

policy authoring. In Proceedings of the 4th Sympo-

sium on Usable Privacy and Security, SOUPS ’08,

pages 65–73, New York, NY, USA. ACM.

Vollat, C. (2012). Graphical user interface development for

usable policy administration points (paps). Master’s

thesis, University of Kaiserslautern.

World Wide Web Consortium (2012).

Web Ontology Language (OWL).

http://www.w3.org/2001/sw/wiki/OWL.

ICISSP2015-DoctoralConsortium