Effective Access Control Policy Specification Using Controlled Natural Language

1. 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 Symposium On Usable Privacy and Security Carnegie Mellon University 25 July 2008

2. What do we mean by “Expressions of Expertness”? Need: Non-security specialists to express access control in formal terms • They are experts concerning their own resources: they know who should be given access to what to do which action Grid computing – similar to cluster computing – linked computers working together Systems can be distributed geographically Across administrative domains But struggle to express this in formal terms which the computer can interpret • Only the user knows what they “really want” SOUPS 2008

3. 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 2008

4. The Context of this research: PERMIS PERMISis 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

5. Policy specification Actions Users Roles Permissions Resources Permission assignment Role Based Access Control RBAC permissions are always positive, although there can be constraints. Permissions not granted are implicitly denied – “Deny all, except …” • 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 Delegated assignment User assignment PERMIS allows you to delegate the ability to assign roles to Role/Attribute Administrators SOUPS 2008

6. 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

7. Permissions, actions, resources, roles, & other entities, and relations between them Controllednatural language may be more “natural” and less ambiguous than full natural language Our approach: Controlled natural language based on an ontology Requests and responses between user and computer User’s world Computer’s world The user does not have to know about the computer’s world X.509_PMI_RBAC_ Policy OID=".091007.1"> .... SOUPS 2008

8. 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

9. 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

10. 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

11. Overall results • Not daunted bycontrolled 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

12. 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 The underlying mechanism makes itself felt • Not quite natural language • Having to declare elements • Prepositions after verbs 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. • Using the building blocks • classes and instances • Underlying model does not match the users’ expectation • What do they need to know? How can we overcome the problems? SOUPS 2008

13. 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

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

15. Human Centred Systems Group p.inglesant@cs.ucl.ac.uk http://www.cs.ucl.ac.uk/staff/P.Inglesant/ http://hornbeam.cs.ucl.ac.uk/hcs/ Information Systems Security Group http://www.cs.kent.ac.uk/research/groups/iss/ SOUPS 2008

16. SOUPS 2008

17. Department A Department B Users cannot see the whole of the Database; what they can see depends on their roles: 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 Name Date of Birth Address Postcode Database Analysts can see only DoB and Postcode SOUPS 2008

18. When Clerks and Process owners join Department A … … John assigns their roles to them Department A Department B When Analysts join Department B, Anne assigns their roles to them SOUPS 2008