A Question and a Case StudyFindingsImplicationsReferencesEscape From the Matrix: Lessons froma Case-Study in Access-Control Requirements∗[Poster Abstract]Kathi [email protected] KrishnamurthiBrown [email protected]. A QUESTION AND A CASE STUDYThe freedom to share information online has made theability to restrict that sharing critical. Access-control poli-cies are thus a central and growing part of contemporaryWeb-based system security. Many policy languages—bothindustrial and academic—are essentially defined in terms ofrole-action-resource triples. As authors of non-trivial poli-cies [2], however, we have often preferred to describe rulesin other forms as well: for instance, as information flows be-tween end-points without having to specify the intermediateoperations by which the information may be transmitted.We thus set out to understand the different ways in whichusers express their policy expectations.To this end, we conducted interviews to gather require-ments for a Web-based application to manage faculty jobapplications for a computer science department.1In suchsystems, applicants submit their materials (vita, statements,etc.) via a Web interface. The software emails a letter-submission url to each reference letter writer. Departmentfaculty, and perhaps graduate students, can view and com-ment on the applications online. Administrative staff handlevarious requests from members of the department. Techni-cal (computing support) staff maintain the infrastructure.Even in this setup, there can be significant disagreementabout some access decisions (as our interviews confirmed):Should applicants be allowed to check which of their refer-ence letters have arrived (and when)? Should students in thedepartment know who has applied? Should administrativestaff be able to read the reference letters?Twelve faculty gave recorded interviews about their “se-curity” requirements, each lasting 20–30 minutes. As allparticipants had extensive experience with the problem do-main, we did not describe it to them. Even though we askedabout security, the vast majority of participants focused oftheir own accord on access-control. Once participants hadrun through the cases that had occurred to them, we askedfollow-up questions about roles and resources not yet cov-ered. We let participants speak free-form rather than struc-turing the discussion.2. FINDINGSAnalogy and Relationship are Fundamental Idioms.Participants’ reliance on analogy was striking, particularly∗A full version of this paper is online as Brown CS TR 09-05.1The resulting software, which has been used to conductmultiple searches, is available for free from the authors.given the variety of forms in which it arose. They used analo-gies both to express rules and to justify them, often com-bining the two. They routinely phrased rules or rationalesin terms of relationships between roles and resources. Nineof the twelve participants stated at least some rules usingthe form “treat X the same as Y ” (possibly “with the excep-tion of Z ”). Sometimes the analogies were used to expressa negative, rather than positive, expectation (that two rolesshould not be treated similarly). Participants often spokeof relationships between the sets of permissions accordedparticular roles. For example, one participant wanted per-missions of one role to lie between those of two other roles,but didn’t know what set of restrictions might achieve that.The Org Chart is Dead, Long Live the Org Chart.Security-requirements processes often start from whateverdocumentation an organization has available about the sys-tem to be secured and the staff who will use it [1, 3]. Or-ganizational charts are potentially useful starting points forspecifying access control, as they suggest preliminary rolesand relative levels of responsibility within the organization.Hierarchies between roles with respect to levels of privilegeemerged naturally during our interviews. However, in twocases, the privilege hierarchy that emerged from the inter-views reversed or contradicted relationships that would havebeen in the org chart. This suggests that the org chart,vested with authority, is actually dangerous as a startingpoint for forming role-hierarchies within policies.Policy Authors Don’t Track Roles in Space and Time.An individual’s access privileges can change over timeeven as the policy remains fixed: an individual’s role mightchange, or the access guards might depend on the statusof a resource (such as whether an application is complete).Role overlaps and changes, in particular, can result in infor-mation leaks. Only four participants raised the possibilityof overlaps and changes, such as graduate students who be-come applicants and applicants who become faculty. Whilethe annual cycle of faculty hiring may have masked theseissues, participants tended to not reference time at all.Social Contracts Identify and Protect the Real Assets.Thinking about access-control policies in terms of con-crete resources, as tabular- or rule-based authoring does,can sometimes entirely miss the point. Our interviews re-vealed that the single most important resource was one thatshows up nowhere in tables and rules: the department’s rep-utation. Often, this was the resource that people were reallytrying to protect, even though they were stating concreterules about other (tangible) resources based on how theythought those decisions would impact this resource. Whileonly one participant explicitly mentioned reputation, oth-ers cited correlating concerns such as practices in other de-partments, departmental loyalty, and the tension betweenthe educational value and (unstated) consequences of let-ting students have too much access to application materials.Participants Exhibit Personality Styles.We were struck by the different approaches—bordering on“personalities” or “styles”—that participants adopted duringthe interviews: social thinkers were conscious of the valuesthat policies encoded regarding department culture, colle-giality, and social contracts with applicants and letter writ-ers; problem avoiders saw policy as protecting against un-desirable situations; pragmatists focused on realities suchas making sure policies wouldn’t interfere with workflow oron granting access based on similar data available to usersfrom outside the system; protectionists framed most com-ments around what principles of confidentiality or least priv-ilege would