Symposium On Usable Privacy and Security Carnegie Mellon University 25 July 2008 Expressions of Expertness The Virtuous Circle of Natural Language for Access Control Policy Specification Philip Inglesant M Angela Sasse - University College London David Chadwick Lei Lei Shi - University of Kent, Canterbury, UK

SOUPS 2008Page 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 2008Page 3 of 14 Access control and authorization “Access control is the ability to permit or deny the use of a particular resource by 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 2008Page 4 of 14 The Context of this research: PERMIS PERMIS 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 2008Page 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 UsersRolesPermissions 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 2008Page 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 2008Page 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=" " >.... The user does not have to know about the computer’s world

SOUPS 2008Page 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 2008Page 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 2008Page 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 2008Page 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 2008Page 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 instances Clerks, 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 of Field is a type of resource. Address is a field. Printers are a type of resource. HP Laserjet 1 is a printer. from

SOUPS 2008Page 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 2008Page 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 Human Centred Systems Group Information Systems Security Group

SOUPS 2008 SPARCLEPERMIS 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 modelRole Based Access Control Based on predefined User Categories, Actions, etc Based on formal OWL ontology

SOUPS 2008 Name Date of Birth Address Postcode 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