Symposium On Usable Privacy and SecurityCarnegie Mellon University 25 July 2008

Expressions of ExpertnessThe Virtuous Circle of NaturalLanguage for Access Control Policy Specification

Philip Inglesant

M Angela Sasse - University College London

David Chadwick

Lei Lei Shi - University of Kent, Canterbury, UK

SOUPS 2008 Page 2 of 14

What do we mean by “Expressions of Expertness”?

Need: Non-security specialists to express access control in formal terms

But struggle to express this in formal terms which the computer can interpret

• They are experts concerning their own resources: they know who should be given access to what to do which action

• Only the user knows what they “really want”

Grid computing – similar to cluster computing – linked computers working together

Systems can be distributed geographically

Across administrative domains

SOUPS 2008 Page 3 of 14

Access control and authorization

• “Access control is the ability topermit or deny the use of a particular resourceby a particular entity” - Wikipedia

• AuthZ is more important than AuthN but has been studied less

• Authorization is inherently complex but, for usability, “complexity is the enemy of success” - Karat Brodie & Karat 2005

SOUPS 2008 Page 4 of 14

The Context of this research: PERMISPERMIS is an integrated AuthZ infrastructure

Open source

Works with Grid, Apache Web servers, .Net, and others

• PERMIS makes access control decisions …

• … as defined by your access control policies

• … written in XML

SOUPS 2008 Page 5 of 14

Role Based Access Control

RBAC permissions are always positive

Permissions to do actions on resources are assigned to roles, not users

Assignment of Roles to Users by Administrators in (remote) Domains

→ RBAC model presents conceptual difficulties

Policy specification

User assignment

Users Roles Permissions

Actions

Resources

Permission assignment

PERMIS allows you to delegate the ability to assign roles to Role/Attribute Administrators

Delegated assignment

RBAC permissions are always positive, although there can be constraints. Permissions not granted are implicitly denied – “Deny all, except …”

SOUPS 2008 Page 6 of 14

Overcoming conceptual difficulties: existing approaches

• PERMIS Editor: GUI-based approach– Conceptual Design - metaphors to match users’ mental

models– Prominent warning: “this is DENY ALL, EXCEPT”

• Controlled natural language approaches– Fundamentally – reduce distance between user’s

intentions their expression– SPARCLE – for privacy and other policies– Virtuous Circle – input and output of AuthZ policies

SOUPS 2008 Page 7 of 14

Our approach: Controlled natural language based on an ontology

Permissions, actions, resources, roles, & other entities, and relations between them

User’s world

Computer’s world

Requests and responses between user and computer

Controlled natural language may be more “natural” and less ambiguous than full natural language

X.509_PMI_RBAC_Policy OID=".091007.1"> ....

The user does not have to know about the computer’s world

SOUPS 2008 Page 8 of 14

Carrying out our approach

• Phase 1: Interviews and focus groups– 45+ Resource owners in Grid computing– How do they think about their AuthZ requirements?– How do they express them?

• Phase 2: Design of ontology and controlled language processing– From findings of Phase 1– Keep it open but above all easy– Basic building blocks – users construct policies

according to their needs

SOUPS 2008 Page 9 of 14

Example

Print is an action.Printers are a type of resource.Printer has print.HP Laserjet 1 is a printer.

Manager and staff are roles.Manager is superior to staff.Staff can print on HP Laserjet 1.Manager can print on all printers.

David and John are administrators.David can assign manager to all users.John can assign staff to users from DepartmentCS.

read is an action.write is an action.records are a type of resource.records has read and write.name, dobs, addresses, postcodes are a resource.

analyst and clerk are roles.analysts can read from dob and postcode.

…

SOUPS 2008 Page 10 of 14

Evaluation: can users express their real world intentions?

• Lab-based observations: 17 target users• Neutral or application-specific scenarios• Recorded and analysed for time and number of

tries, classes of problem and comments

→ How usable is the basic interface? Are users daunted by the blank screen?

→ Can users understand the building blocks and use them to construct workable policies?

SOUPS 2008 Page 11 of 14

Overall results• Not daunted by controlled natural language

interface• Time and tries are higher than we would like:

– mean 24:27 minutes in 4.47 tries

• Largely overcomes conceptual difficulties– No tendency to “deny” access to resources

But: • Problems with features of controlled natural

language

• Difficulties constructing from the “building blocks”

SOUPS 2008 Page 12 of 14

The underlying mechanism makes itself felt

→ Underlying model does not match the users’ expectation

→ What do they need to know? How can we overcome the problems?

• Not quite natural language– Having to declare elements– Prepositions after verbs

• Using the building blocks– classes and instancesClerks, Owners and Analysts are roles.

Name, DoB, Address and Postcode are resources.

Clerks can write to Name, DoB, Address and Postcode.

Owners can read all fields.

Address is a type of resource.… instead ofField is a type of resource.Address is a field.

Printers are a type of resource.HP Laserjet 1 is a printer.from

SOUPS 2008 Page 13 of 14

What do they need to know? How can they know it?• More informative timely feedback

– Line by line parsing– Don’t silently fix problems – only the user knows what

they “really want”– Drop-down boxes to disambiguate

• 2-way street between GUI and controlled language– An integrated interface

SOUPS 2008 Page 14 of 14

Review and conclusions• Need: expression of formal AuthZ by non-experts• Question: Is controlled natural language is more

“natural” than GUI?• Design and evaluation of controlled language• Can users express access control needs?

– Overall: well understood and usable, but -– Underlying mechanisms make themselves felt

• Meeting the needs of the user in their own terms– Feedback– Integrated interface

SOUPS 2008

p.inglesant@cs.ucl.ac.uk

http://www.cs.ucl.ac.uk/staff/P.Inglesant/

Human Centred Systems Group

Information Systems Security Group

http://www.cs.kent.ac.uk/research/groups/iss/

http://hornbeam.cs.ucl.ac.uk/hcs/

SOUPS 2008

SPARCLE PERMIS

Privacy policies (although other types envisioned)

Authorization policies by resource owners

Protects data items in an organisation

Protects any collection of resources, actions and roles

Supports a generic privacy control

Supports PERMIS with delegation of authorities

Bespoke privacy model Role Based Access Control

Based on predefined User Categories, Actions, etc

Based on formal OWL ontology

SOUPS 2008

NameDate of BirthAddressPostcode

Department A

Department B

Database

Analysts can see only DoB and Postcode

Clerks in Dept A can add and change date of birth, name, address and postcode

Process owners cannot change any data but can read it all

Users cannot see the whole of the Database; what they can see depends on their roles:

SOUPS 2008

Department A

Department B

When Clerks and Process owners join Department A …

… John assigns their roles to them

When Analysts join Department B, Anne assigns their roles to them