eIS Theme 8: Trust and Security Second Workshop Usability and Interoperability in AuthN/AuthZ Angela Sasse Philip Inglesant

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Easy Expression of Authorisation Policies Usability of AuthZ Policy-based access control and specification of policies Joint project with David Chadwick and Kent Reduce scope for misconceptions and mistakes Input and output in controlled natural language Overcoming existing problems Avoiding need for knowledge of RBAC structure The overall aim of the project is to support e-Science resource owners who are not security experts to create authorisation policies for their e-science applications.

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Usability & security in the specification of access control policies Phase 1: Qualitative interviews Expressions of security terms Issues in Grid security Phase 2: Meeting usability needs in policy specification Extend GUI with controlled natural language Evaluation of beta-level implementation Analysis – does it overcome problems? Are there new issues? What and why?

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Phase 1: Qualitative interviews: what are the usability needs? What are Grid users’ security needs and how do they express them? Individual and focus groups 45 participants Researchers using Grid in: PP, chemistry, medical, modelling, Arts & Humanities etc. System administrators eg. Central IS Service providers, developers & Grid pioneers

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Findings: Issues in Grid access control Grid used by many different research areas Many different reasons to use Grid Many different security requirements Real-world situations are complex and changeable Example: field-level access to db; research groups of a university But need for accurate specification of Grid access control Examples: Medical research; commercially valuable data Even if there are “no” security needs - data integrity

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Why are people using Grid? Access to large volumes of data, large amounts of data storage, or safe long-term storage of data Sharing data with the research community, such as repositories of metadata or images, and accessing specialised data High-Powered Computing needs, typically provided by multi-workstation systems, within one domain/across administrative domains Specialised applications such as computer modelling or visualisation, often within a Virtual Research Environment

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Different security level needs and why High needs – must be certain of security Medical research Commercially sensitive or valuable data Privacy – access subject to approval or for a certain use Conversely - need to enable access to those who should have it Funder might require findings to be made public Sharing data across a research group Need to make particular resources available Subject to some constraints, eg. time budget, overnight run

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Other access concerns Data at different levels of granularity Database fields Constraints: time, where a person is from, title Anonymised/pseudonymised data But may be vulnerable to access to different datasets Many different kinds of accesses “Grid resources” – filestore, data, HPC Run a particular program (eg. proprietary software) Access only to full members of the campus grid Maintenance problem – as groups join/leave the grid

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Implications for Usable AuthZ Hard to control Traditional – Unix-style, allocating users to groups - is this scalable? May be enough if staff turnover is small and access control is basic Different kinds of access resemble Web 2.0 To be honest, if I had to set security policies for all the users, I'd be really annoyed, I'd probably just have two level authentication, that said "I'm the administrator, I can do what I want", "everyone else is a lowly user, and all they can do is submit jobs and see their own jobs” Policy-based access control How much is it being used?

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Usability of access control models Access control models are beyond resource owners’ experience Resources owners know the resources under their control but.... struggle to express it in formal terms R-what? – policy components Earlier research found some common misconceptions Deny all except, delegated SoA, “subject domain” Partially overcome with GUI Editor

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Personae of resource owners Grid pioneers Developers Service providers And as such are also sysadmins … System administrators Grid may be peripheral to what they do Clusters & head nodes may have traditional Unix control E-Science users May be new users of Grid May have had admin responsibilities given to them

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Phase 2: Meeting usability needs in policy specification PERMIS authorisation infrastructure PERMIS Policy Editor GUI designed to reduce burden of expression And guide users to specify complete policies Overcomes some basic misconceptions using Conceptual Design and other HCI methods The structure of the policy space Deny all except

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ The PERMIS Controlled Natural Language interface A more fundamental way to reduce scope for misconceptions And mistakes - slips Natural language output as well as input The virtuous circle of policy specification Based on GATE natural language processing Ontology as intermediary between NLP and policy

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Does natural language fix the problems? Evaluation: 17 participants 1 basic scenario and 1 more advanced Usability of controlled natural language Basic idea is easy to grasp Simple scenario took mean 4.47 attempts/24:27 minutes Participants understand building blocks – resources, actions, permissions, roles

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Overcoming conceptual problems Only give permissions – no tendency to “exclude” “Subject domain” is intuitive - once users work out how to express it But – delegated role assignment is less intuitive “administrator” is a special role with special “assign” privileges Some people assigned “roles” to all users or expressed as “adding” users to roles Suggests they have not understood

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Problems in controlled natural language Linguistic cueing Some basic usability problems in controlled natural language, eg. use of prepositions – “Clerk can read on database” Need to pre-specify entities – a feature Clerk can read databsae Problems specifying resources level of resources – what does the policy apply to? or how to specify them

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Name and DoB and address and postcode and record are resources. Clerk can write to name, to DoB, to address to postcode and to record. Owner reads all from record. Participant: Do I need to even specify that a record exists, or can I specify, you know? Database is a type of resource. Ourdb is a database. Participant: I've said "database" is a resource - should I make the elements resources, rather than the database? Examples of specifying resources

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Understanding the problems Are the controlled natural language problems basic usability problems? No. The computer needs unambiguous input but the natural language is in the users’ real world

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Abstract & Concrete thinking Users understand “building blocks” in concrete terms Resources, roles, actions, etc are just classes in the ontology Users don’t understand the ontology (and should not have to) Class/Instance problem Computers are a type of resource. Dirac is a computer. is useful but … Postcode is a type of resource. … instead of Field is a type of resource. Postcode is a field. Or – this works but does not correspond to the example: Postcode is a resource.

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Towards a new security paradigm Need to “push and prod” to overcome misconceptions Users can learn by understanding what works Immediate feedback NLP and GUI work together Disambiguation with drop-down boxes

eIS Theme 8: Trust & Security 2 nd Workshop: Usability and Interoperability in AuthN/AuthZ Ways forward Ontology at centre of policy? Access control policies – the way forward?