Transcription
Usable Security and Privacy: A Case Study of DevelopingPrivacy Management ToolsCarolyn. Brodie, Clare-MarieKarat, John KaratIBM T. J. Watson Research Center19 Skyline DriveHawthorne, NY 105321-914-784-7237cbrodie, ckarat,jkarat@us.ibm.comABSTRACTPrivacy is a concept which received relatively little attentionduring the rapid growth and spread of information technologythrough the 1980’s and 1990’s. Design to make informationeasily accessible, without particular attention to issues such aswhether an individual had a desire or right to control access toand use of particular information was seen as the more pressinggoal. We believe that there will be an increasing awareness of afundamental need to address privacy concerns in informationtechnology, and that doing so will require an understanding ofpolicies that govern information use as well as the developmentof technologies that can implement such policies. The researchreported here describes our efforts to design a privacymanagement workbench which facilitates privacy policyauthoring, implementation, and compliance monitoring. Thiscase study highlights the work of identifying organizationalprivacy requirements, analyzing existing technology, on-goingresearch to identify approaches that address these requirements,and iteratively designing and validating a prototype with targetusers for flexible privacy technologies.Categories and Subject DescriptorsH5.2. Information interfaces and presentation: User Interfaces.K4.1. Public policy issues: PrivacyGeneral TermsManagement, Design, Experimentation, Security, HumanFactors.KeywordsPrivacy, privacy policies, security, social and legal issues,design.Copyright is held by the author/owner. Permission to makedigital or hard copies of all or part of this work for personal orclassroom use is granted without fee.Symposium On Usable Privacy and Security (SOUPS) 2005,July 6-8, 2005, Pittsburgh, PA, USA.Jinjuan FengUniversity of Maryland BaltimoreCounty, Information Systems Dept.1000 Hilltop CircleBaltimore, MD 212501-410-455-3888Jfeng2@umbc.edu1. INTRODUCTIONAs organizations come to rely on the collection and use ofpersonal information in order to provide quality services to theircustomers, patients, constituents and return on investment totheir share holders, the ability to protect that information andenforce privacy polices becomes more important.Theincreasing number of reports of privacy violations due toexternal break-ins as well as accidental and malicious misuse ofpersonal information by individuals within an organization isonly exacerbating the problem. While an increasing amount ofresearch concentrates on identifying security and privacyweaknesses and how to address them, making this technologyusable remains an important issue. The Computing ResearchAssociation (CRA) Conference on Grand Research Challengesin Information Security and Assurance has identified the abilityto “give end-users security controls they can understand andprivacy they can control for the dynamic, pervasive computingenvironments of the future” as a major research challenge [14].As Whitten and Tygar [35] point out, “security mechanisms areonly effective when used correctly” and this is often not the casedue to usability issues with security software. In this paper wepresent the design of a set of privacy utilities that are intended toassist organizations with the creation, implementation, andinternal auditing of privacy policies. We will discuss how weused knowledge of organizational user needs gained during anearlier phase of the project as the basis for analysis of currentprivacy technologies and on-going research to create an abstractarchitecture for an organizational privacy solution. Then basedon that architecture, we have designed and prototyped a privacymanagement workbench to assist organizations in creating andmanaging their privacy policies.We chose the domain of organizational privacy policy creationand enforcement because use and misuse of personalinformation (PI) is an area of increasing concern in manygeographies and domains around the world. Organizations needusable methods to ensure that the information policies they putin place are enforced correctly without negatively affecting theirbusiness processes. Research has shown that many invasions ofprivacy are not intentional [1]. When designing systems that usepersonal information, we must not only secure them so that
information cannot be accessed by unauthorized users but alsofrom authorized users for unauthorized purposes.Privacy can mean many things to many people. In the contextof our research and this paper, we define privacy as the right ofan individual to control information about themselves ratherthan as the right to individual isolation [27, 30]. The OECDprinciples [30] provide high level privacy standards for dealingwith personal information and have widespread consensus.These have provided input to legislation in many parts of theworld that requires organizations to have privacy policies andconstrains organizational collection and use of personalinformation to differing degrees. This legislation varies by bothgeography and domain [24]. These variations as well as theinherent differences between domains [10,11] and between thebusiness practices of different organizations means that it is notlikely that a single privacy policy can be created to cover allpersonal information. The research reported in this paper hasfocused on how technology can be used by organizations tocreate and enforce the range of privacy policies needed to meetthe varied requirements.2. RELATED WORKThere are many aspects of privacy that have been the subject ofresearch, including research on the public perceptions of theneed to protect PI, research and development of many types ofprivacy preserving technologies, as well as research into thecurrent approaches that are being used by organizations toprotect the PI of their customers, constituents, patients, andemployees. In this section we will discuss recent research intothe public perceptions of privacy within organizations and howthey affect individual willingness to share data, technologicalapproaches for enforcing privacy policies, and finally howorganizations are protecting PI today.Research has identified high levels of consumer concernsregarding privacy [17, 18, 31] in a large range of geographiesand domains. A multi-national consumer privacy survey in 1999investigated US, German, and UK consumers’ attitudes towardprivacy in different industries [18]. Seventy-eight percent of thepeople in the survey reported that they have refused to provideinformation in the past due to concerns about PI misuse. Aprivacy and business survey in 2000 conducted for theAustralian government revealed that 95% of the respondentsthink it is necessary to implement laws to protect PI and alsodocumented that approximately 50% of the respondentsroutinely and intentionally provide inaccurate PI [31]. A morerecent Forrester report found that 97% of North Americanconsumers believe that online privacy concerns are real and94% reported that they believe the benefits they receive forsharing personal information do not outweigh their concerns[13]. In the health care domain, physicians and practitionersare concerned about serious threats to patient privacy due toinformation gathering methods, record accuracy and access, andunauthorized secondary use [11]. In the education sector, aStanford University report reveals that PI is not effectivelyprotected [34].Researchers have responded to these concerns through thedevelopment and analysis of machine readable privacy policiesand the development of mechanisms for helping end-users tounderstand the policies and organizations to enforce the policies.One area of research is on the development and use of machinereadable privacy policy schemas for enabling privacyfunctionality. P3P [15] is one of the first privacy policylanguages that has been standardized by an internationalstandards body, the W3C. P3P is an XML based language thatallows organizations with Websites to create machine readableversions of their privacy policies. Generally, P3P allowsorganizations to specify rules that contain the type of data, thetype of use, the user of the data, the purpose of the use, and howlong the data will be retained. From the end-user or client pointof view, automated agents, such as the AT&T Privacy Bird [8]and browsers such as Microsoft’s Internet Explorer [26] can usethe P3P policies to provide individual users with the ability toquickly determine if the Website’s privacy policies match theirprivacy preferences. Other proposed schemas, such as APPEL,have expanded on the goal of helping individuals to quicklydetermine if a Website’s policies match their preferences byallowing the user to define rule sets for describing acceptableorganizational privacy policies [36].While the ability to quickly understand a site’s privacy policyand determine if the site conforms to their preferences is helpfulto end-users, it is important to understand that there is noguarantee that the policy is actually implemented as specifiedwithin the organization. This fact has lead to research into howmachine readable (XML schema languages) privacy policies canbe used by organizations to enforce policies. Karjoth andSchunter [22] analyzed how enterprise privacy policies differfrom security policies and how well P3P can express anenterprise privacy policy. Based on this analysis, they proposea privacy policy model that can be used for internal accesscontrol within an enterprise. New XML schemas designed toenforce privacy policies include, the Enterprise PrivacyAuthorization Language (EPAL) [7] and XACML with aprivacy profile [29]. These allow more expressive policies thatinclude hierarchical policy elements, conditions on rules, and auser definable set of obligations. EPAL is being considered bythe W3C standards body and XACML with a privacy policyprofile is being considered by OASIS. The ability to use alanguage like EPAL to capture and logically enforce the privacypolicies of large, complex organizations has been studied andformalized by Backes, Pfitzmann and Schunter [9].In addition to policy analysis, researchers have been exploringenforcement mechanisms for some time. Anderson [4,5]proposed a security policy model for the British MedicalAssociation that described how to implement and managecompartmented security in health care. In an update in 2000, hereported that it had been implemented successfully in threeBritish Hospitals [5]. Since that time there has been researchinto how machine readable policies can be used internally byorganizations to enforce their privacy policies. Some approacheshave concentrated on allowing policies defined by individuals todictate how their information is used [12], while many othershave concentrated on enforcing privacy policies created at theorganizational level. An example of this is the HippocraticDatabase [3] in which P3P is used to define access rules that arethen enforced by the Hippocratic Database. IBM’s TivoliPrivacy Manager is another example of an approach that hasused P3P to define privacy policies which are then enforced bydeploying monitoring software around data stores that sendsrequests for PI to a server which then determines if the access
conforms to the privacy policy and logs both the attempt and theenforcement decision [19].Even with all of the research that indicates that there is growingconcern about privacy issues and the possible technicalapproaches that have been developed to protect PI, mostorganizations that depend on the use of personal information intheir business processes have done little to implement thepolicies through technology [21, 33]. Privacy policyenforcement is still often accomplished through predominatelymanual procedures. According to a 2003 study conducted byPonemon for the IAPP [32] only 19% of the organizationssampled report that they are currently using any privacyenabling technology. This confirms the situation described byForrester with respect to privacy [17]. This Forrester reportdescribes differences between consumer and executive views ofprivacy practices in industry. According to this report, themajority of executives who participated in the study (58%)believe that their companies are doing a good job of addressingprivacy issues while customer concerns about privacy remainshigh. In fact, the majority of executives did not know whethertheir customers even checked the privacy policies or not andfew see the need to enhance their privacy practices. Theseresults were echoed by research in the Asia-Pacific region [31].More recent research indicates that many organizationsrecognize that privacy is an issue for them. They currently donot know how to use technology to help them enforce theirprivacy policies. The Ponemon study [32] reported thatalthough 98% of the companies in their survey have a privacypolicy, 52% believe they do not have the resources toadequately protect privacy. Furthermore, most organizationsstore PI in heterogeneous server system environments andcurrently they do not have a unified way of defining orimplementing privacy policies that encompass data collectedand used by both Web and legacy applications across differentserver platforms [6]. This makes it difficult for organizations toput in place proper management and control of PI, for the datausers to access and work with the PI inline with the privacypolicies, and for the data subjects to understand rights regardinguse of their PI. It has been suggested that one reason thatorganizations are not employing new privacy enablingtechnologies to protect PI is that these technologies are currentlyvery difficult to use [14,35]. In practice user-centered designtechniques have contributed to the development of some highlyusable security systems [20, 37]. Based on this evidence, ouremerging focus has been on applying HCI-based researchtechniques to answering how organizations could createpolicies, and how technology might be used to enforce thepolicies and provide audit capabilities to ensure compliancewithin the organization.We believe that this focuscomplements the diverse range of privacy research that is beingconducted by making privacy technologies accessible toorganizations so that technology can enable the protection ofprivacy and not just be a force which reduces individual rights.description of this work can be found in [21]. In this researchfifty-one individuals who were responsible for either thecreation and/or implementation of privacy policies within theirorganizations responded to an email survey. The participantscame from industry and government organizations in NorthAmerica, Europe, and Asia Pacific. The participants were askedto identify their top privacy concerns, the types of functionalitythey felt would be valuable to them in addressing theseconcerns, and what actions their organizations were currentlytaking to address privacy issues.We then held in-depth interviews with a subset of thirteen of thesurvey participants. The goals of these interviews were to builda deeper understanding of the participants’ and theirorganizations’ views regarding privacy, their privacy concerns,and the value they perceived in the desired privacy technologythey spoke of in the context of scenarios of use involving PI intheir organizations. The majority of the interview sessions werecentered on discussion of a scenario of use provided by therespondent regarding PI information flow in their organizationand follow-up questions related to it. We wanted to identify andunderstand examples of how PI flowed through businessprocesses in the organization, the strengths and weaknesses ofthese processes involving PI, which of these processes areautomated and which are manual, and the additional privacyfunctionality they need in the context of these scenarios.The participants reported that protecting their customers,patients, constituents, and employees PI requires a multifacetedapproach. The organization must develop an implementableprivacy policy, educate employees and the people they serve onthat policy and the importance of privacy in general, identifywhere PI is stored and used within their business processes, andthen develop both manual procedures and technologicalsolutions to enforce the policy they have created. One of themain goals with this research was to help organizations in theirefforts by identifying how technology could be used to assistthem in protecting the PI they collect and use. Using the surveyand interview data that we collected, we developed a set of fivekey privacy concepts that are important to meeting the needs oforganizational users of privacy protecting technologies. Theyinclude:1.It is important to provide users with one integratedsolution for an organization’s heterogeneousconfiguration even if it consists of a set of utilitiesthat provide users with a similar set of functionalityand interaction methods for systems that areimplemented differently on different technologies.2.The privacy functionality must be separated fromthe application code for cost, consistency, andflexibility reasons – users do not want to have tomodify all of their applications individually to ensurethat PI is protected.3.There needs to be the ability to support anappropriate level of granularity for applying theprivacy policy. For example, the ability to controlaccess at the field level in a database.4.There must be the ability to work with bothstructured and unstructured information. This3. PROJECT BACKGROUNDThe research presented in this paper builds on our team’sprevious research in which we identified privacy needs withinorganizations through email survey questionnaires and thenrefined the needs through in-depth interviews with privacyresponsible individuals in organizations. A more complete
includes protecting field level data and handling PIwithin documents in appropriate ways.5.There must be simple and flexible privacyfunctionality that is designed to meet the needs of theuser community that owns each subtask in the privacyprocess. For example, CPO’s and/or business processowners often write the privacy policies. They must beable to author policies that will end up in machinereadable form without having IT skills.4. Architectural Analysis of PrivacyFunctionalityUsing the set of key design concepts for any privacy solutionthat we identified in earlier phases of this research, we analyzedexisting privacy architectures to identify areas in which usercentered design techniques could be applied to best meet theneeds of organizational privacy users. To facilitate thedescription of this analysis we have created a generalization ofmany approaches to protecting the privacy of PI which is shownin Figure 1. In this figure a privacy policy authoring utility isused to create privacy policies that are stored in a machinereadable format. This machine readable privacy policy is thenused by a privacy enforcement mechanism that is positionedbetween applications and data stored within the organization’sconfiguration.The architecture also dictates that theenforcement mechanism should create a log of privacy eventswhich can be analyzed by the organization’s audit mechanism inorder to report on compliance with the privacy policy. Thegeneralized architecture drawing in Figure 1 is purposefullyabstract so that it can be used to describe the common elementsand mechanisms in a variety of possible privacy implementationapproaches.considered. Likewise, there are many different approaches toprivacy policy enforcement that have been proposed includingquery re-writing [2], data access monitoring and the use of arules based enforcement engine [19], and the application of amodified access control mechanism [4,5]. Also, not allapproaches in the literature include all components in thedrawings. For example, the model proposed by Anderson usesan enforcement mechanism based on the concepts for multilevelsecurity research as well as an audit mechanism, but does notaddress the use of machine readable privacy languages. Whilewe recognize that each of these types of solutions do have thepotential to be valuable to organizational users, we have foundthat all share some high level strengths and weaknesses in termsof the key privacy design concepts we described in our earlierresearch [21].Based on our analysis we found that the technologies that arebeing researched and developed can be used to meet three of thefive key privacy design concepts identified. In consideringconcept 1, we compared the user scenarios that we collectedfrom the organizations that participated in our interviewresearch and the range of privacy solutions that we found in theliterature. We did not find one solution that obviously met all ofthe users needs for providing a single solution that wouldprotect data within large organizations’ highly heterogeneousand widely distributed configurations. Nor does it seem likelythat one could be designed anytime soon. However, there are atleast two approaches to addressing this problem. One approachis the creation of a common set of privacy utilities that providesusers with a single method for creating, visualizing and auditingprivacy policies that could then be enforced using theappropriate range of technologies. Another possible approach isfor a set of utilities to be provided to a central PI store on asingle platform that has a privacy policy enforcementmechanism. This would create a PI “vault”. Other distributedapplications would then request data from that system.We recognize that there are privacy enabling technologies thataddress concepts 2 and 3. Many of the privacy approaches thathave been identified allow the privacy enforcement to beseparated from the application. For example, the HippocraticDatabase [2] allows applications to query the database as theyalways have. The query re-writing done by the JDBC layerensures that only PI accesses or updates allowed by the policyoccur. Likewise, data store monitoring approaches such as thatemployed by Tivoli Privacy Manager [19] separate theapplication from the privacy auditing and/or enforcement. Eachof these approaches also has the potential to allow privacyenforcement at the database field level.Figure 1. Abstract Privacy ArchitectureDifferent types of machine readable policies have beenproposed and are at different points in the standardizationprocess. P3P is currently a privacy language standard and isused to define privacy policies in some approaches [3, 19].Other standards that allow for more expressive policies, such asEPAL and XACML with a privacy profile are also beingAlthough we found approaches that can address the first threekey privacy concepts, we have not found any approach thataddresses either of the last two concepts. In the case of concept4, the representatives of the organizations that we interviewedtold us that they needed to be able to provide privacy protectionfor information within unstructured documents. Perhaps textanalytics research combined with a privacy enforcementmechanism may be able to address this need in the future.Finally, while there has been research into the design ofinteraction methods to allow end users to define privacy policieswith their preferences regarding sharing data with e-commercecompanies [16] and with pervasive devices [23], none of theprivacy technologies we analyzed addressed the last key privacy
design concept (concept 5) that we identified. Organizationalusers have a need for simple and flexible interaction methodsfor dealing with complex, organizational privacy policies thatcan be used by individuals who do not have IT skills.Therefore, this is the need that we decided to address in ourresearch. We identified three areas where highly usable privacyutilities were needed. The first is a utility to assist users increating and understanding privacy policies. The second is autility to assist users in implementing the privacy policy. Thedesign of this utility is partially dependent on the choice ofenforcement engines used. Finally the third utility enablesorganizations to conduct internal audits of their privacy policies.While our research has focused on all three areas, our work inthe privacy policy creation area is the most mature and is theleast dependent on a particular enforcement engine. Therefore,we will concentrate on this utility in this paper.During the survey and interview research, many of theparticipants indicated that privacy policies in their organizationswere created by committees made up of business processspecialists, lawyers and security specialists as well asinformation technologists.Based on the range of skillsgenerally possessed by people with these varied roles, wehypothesized that different methods of defining privacy policieswould be necessary. Figure 2 shows the abstract architectureupdated with a more detailed privacy policy creation utility.The figure shows the privacy policy creation utility divided intothree parts. There is a privacy policy authoring utility that usesand stores natural language policies, a transformation utility fortranslating the policy into machine readable policies, and avisualization utility for helping users understand theimplications of new and existing policies. The architecturalview of this utility was used to guide the design of a prototypeprivacy management tool.5. Designing and Evaluating a Privacy PolicyPrototypeUsing the completed survey and interview research and thearchitectural analysis, we designed and developed a prototype ofa privacy policy management workbench called SPARCLE(Server Privacy ARchitecture and CapabiLity Enablement).SPARCLE is written in dynamic HTML and is a “Wizard-OfOz” prototype. By this, we mean that the prototype allowsusers to see how the functionality would operate, but that it isnot fully functional. The use of this prototype allowed the teamto obtain user feedback on the types of functionality included inthe prototype before a fully functional version was developed.The overall goal in designing SPARCLE was to provideorganizations with tools to help them create understandableprivacy policies, link their written privacy policies with theimplementation of the policy across their IT configurations, andthen help them to monitor the enforcement of the policy throughinternal compliance audits. Once we designed the prototype,we conducted a series of walkthrough sessions in which weutilized the prototype to discuss an appropriate scenario withrepresentatives of health care, government, and financeorganizations. In this paper, we will concentrate on thetechniques we designed and developed for authoring privacypolicies and assisting organizations in understanding the policiesthat have been created.Figure 2. Abstract Privacy Architecture with Privacy PolicyCreation Utility Expanded5.1 Authoring Privacy PolicyBased on the architectural drawings above and building onresearch into using natural language processing for policydevelopment [25], SPARCLE was designed to support userswith a variety of skills by allowing individuals responsible forthe creation of privacy policies to define the policies usingnatural language or using a structured format to define theelements and rule relationships that are then directly used in thecreation of a machine readable version of the policy.SPARCLE keeps the two formats synchronized. For users whoprefer authoring with natural language, SPARCLE transformsthe policy into a structured form so that the author can review itand then transforms it into a machine readable format such asEPAL [7], XACML [29] or other appropriate privacy languages.SPARCLE translates the policies of organizational users whoprefer to author rules using a structured format into both anatural language format and the machine readable version.During the entire privacy policy authoring phase, users canswitch between the natural language and structured views of thepolicy for viewing and editing purposes. Once the machinereadable policy is created, it is possible to employ anyenforcement engine that is capable of using the elements of thestandardized privacy policy language to ensure the policy isenforced for data stored in the organization’s on-line data stores.Figure 3 contains a screen capture of SPARCLE’s naturallanguage interface for defining privacy policies. SPARCLEsupports a set of privacy tasks that were identified from the datacollected using the survey and interview research. Theidentified tasks include: authoring the policy in natural language(step shown in Figures 3), transforming the policy into policyelements (step shown in Figure 4), mapping the user categories,mapping the data categories, mapping the purposes and actions,mapping the conditions, mapping the obligations, and verifyingthe policy. The mapping steps are used to associate policyelements with system objects, and enable the separation of highlevel and detailed policy specification. The verify step allowsusers to confirm that all parts of the policy have been mapped.In SPARCLE these tasks are represented by the tabs shown atthe top of Figure 3. The page also contains general informationabout the policy, (the name, date created, and file source of the
policy, and a description of the policy authoring task to beperformed) a list of privacy policy templates that could be eitherprovided by the tool for particular domains and geographiesbased on laws or created by the organization for customizationand use by its divisions, and an Example Rule Guide describingthe elements that make up a privacy policy rule. The guide isbased on analyses of privacy policy rules specified in [7].The guide defines the basic components that are necessary in anenforceable privacy policy rule including user categories,allowed actions, data categories, purposes, as well as optionalcomponents such as conditions and obligations. Finally, a textentry a
earlier phase of the project as the basis for analysis of current privacy technologies and on-going research to create an abstract architecture for an organizational privacy solution. Then based on that architecture, we have designed and prototyped a privacy management workbench to assist organizations in creating and managing their privacy .
