Usable Security

DISCUSSION SESSION
Policy Management: A Central Theme for Usable Privacy and Security Systems
Moderator: John Karat, IBM T.J.  Watson Research Center

Twenty-five people jammed CIC 2201, a conference room intended for 12, in a session that turned out to be much more popular than anticipated.  It is somewhat surprising that so many SOUPS attendees showed interest in policy management, since there were only 1 or 2 papers on policy management presented at the conference.  Nevertheless, it seems that people are coming to recognize the importance of policy management to usable privacy and security.  This recognition is encouraging.

John Karat of IBM, the session moderator, started off the session with a summary of the key problems in policy management:

- natural language (NL) policy specification
- structured formats for policy specification (e.g., XACML)
- mapping from NL to structured formats
- mapping from structured formats to concrete policy that can be implemented by a database system
- policy verification, i.e., checking for conflicts, for compliance with higher-level legislation and policies, testing policy before deployment
- enforcement, i.e., actually running a system that takes requests and allows or denies access according to a concrete policy
- transaction logging
- auditing

The conversation started with a discussion about semantics.  The first question raised was whether a policy is the same as a rule.  Some felt the terms “policy” and “rule” are synonymous, while others felt a policy is a set of rules.  The second question raised was over the difference between “privacy” and “confidentiality”.  Andrew Patrick felt confidentiality is one of many means for implementing privacy, while John Karat and others felt that confidentiality policies cover what happens to data after it has been collected; privacy policies cover confidentiality plus data collection. 

The leading topics of conversation centered around the difficulties that arise in mapping from high-level policies to rules that are actually implementable by system admins or by a database system itself.  There seemed to be a sense among the privacy researchers in the room that privacy requires more than just a mechanism for access control.  In particular, privacy situations can be so complex and context-dependent, that some rules can only be adequately expressed in natural language.  However, policies written in natural language are subject to interpretation.  George Madzy of the State Department mentioned Xacta, a tool for policy implementors map from higher-level policies to implementable rules.

Another key topic that arose was compliance, meaning two things: first, compliance of a policy with legislation or higher-level policies; second, compliance of actual system behavior with system policy.  The former type of compliance is checked at the policy authoring stage, while the second type is checked during an audit. 

A good deal of time was devoted to a problem posed by Lee Iverson and Diana Smetters: in some domains, particularly healthcare, it is sometimes necessary to throw out all barriers to information access during an emergency, i.e., sometimes you want no policy in place.  Many in the room agreed that there is a need for emergency plans to do away with access control in some situations.  However, Clare-Marie Karat pointed out that policies can be expressive enough to allow for emergency clauses.  The group agreed that privacy policy problems are highly context-dependent, and there seems to be a need for very expressive policy-authoring languages.  There was general agreement that proper abstraction levels for different classes of users are needed, and that proper mental models need to be fostered.  Policy visualization techniques may help greatly in this regard.

Toward the end of the session, discussion turned to usability issues.  Clare-Marie Karat, who has actually done interviews with policy makers in large enterprises, noted that a big usability challenge is designing policy-authoring systems for policy makers who are not technical people.  There is a need for systems that present a layer of abstraction that can be understood by non-technical people, rather than just by system administrators. 

==========

BULLET POINTS:
Semantic distinctions between:
- policy and rule
- confidentiality and privacy

Perhaps biggest problem in PM: mapping from high-level laws and policies to lower levels and ultimately to implementation (Xacta tool)

Fostering proper mental models is important, but so is developing tools that work at the right, user-understood, level of complexity.

Gap in organizations between policy-makers and IT staff, who implement policies.  Thus policy-makers have no idea whether their intentions are actually being carried out.

One problem with policy-controlled access is that in some domains, there are emergencies in which you need to throw out all barriers to information access.  But, technically, this provision could be handled with a policy that defines emergency contexts in which all information access control is disabled.

General agreement on emergency access need, but auditing is important.  For example, doctor who needs emergency unrestricted access to patient data should be logged for possible later audit.

Tension - sometimes allowing information access in the first place is inappropriate.

Usability aspects:
- Finding the right system models to match user mental models
- Need for advanced policy visualizations to help comprehend complex policies, see conflicts in policies, and foster correct mental models
- policy-makers are often not technical people, and they especially need tools for simplfying policy authoring to the domain with which they are familiar, not to low-level system access control
- ways to show whole thread of progression from law, to NL policy, to structured policy, to implementation
- context of use is important — stationary or mobile, emergency or non-emergency

TRANSCRIPT
John Karat (JK) - This group recognizes that policy is a key component of usable privacy and security.

JK - IBM has started open collaborative research (OCR) initiative with CMU and Purdue on policy management to develop open source materials for policy management. 
What are the components of policy management?
- natural language policy specification (high-level policy statements)
- abstract structured policy in a format like XACML
- mapping to concrete policy, that is, attaching entities in abstract policy to things a system knows about; for example, mapping “pharmacists” to specific users in a system
- implementations and configurations
- policy verification, i.e., check for conflicts, check for compliance with legislation, test policy before implementation
- enforcement, i.e.  actually running a system that looks at requests and determines whether they are allowed or denied under policy
- policy auditing and compliance checking

Roy Maxion (RM) - is a policy just a rule? 
Answer: No, a policy is a set of rules.  Well, maybe it is a rule.

Andrew Patrick (AP) - thinks this is important for business reasons.  Companies want to know if what is happening in their systems is consistent with their policies.  They need to pass audits to comply with law.  AP will be focusing on [deleted by request] for helping companies check compliance.

Mohammed Ali (MA) - ran tests on Privacy Bird, found room for improvement
found need for human factors work
if people read P3P policies directly, they do as well as people using Privacy Bird at understanding policies

Danny Fernandez (DF) - also thinks this is important.  Wonders if there is any importance in making a distinction between confidentiality and privacy?  Privacy is a low-level issue about control of data, confidentiality is broader. 

AP - Confidentiality agreements could be one way of managing privacy.

RM - you didn’t answer the question.  What is the difference between privacy and confidentiality?

Peter Lamb (PL) - you can avoid confidentiality by not collecting the information in the first place.

JK - privacy includes collecting data, whereas confidentiality is only about sharing data when it has already been collected.  Thus, privacy can encompass confidentiality.

George Madzy (GM) from State Dept.  - Problem has always been getting to fine-grained policy.  Different people interpret high-level policies in different ways.  Privacy means what a business can collect, what it does with info after collected, and what it does with information.  The greatest thing he’s seen is a security publication with a matrix showing terms from legislation to things that can actually be implemented, e.g., mapping from a term like “secure passwords” to a “90-day strong password”

Clare-Marie Karat (CMK) - There are different levels, and we have to deal with them all and be able to map from higher levels to lower

GM - Xacta is a tool for mapping a rule to specific things an IT person knows how to implement given a particular policy paradigm

Diana Smetters (DS) - How does a policy relate to what it actually is in practice?  Often company or customers want to know.

AP - We need tools that work at the level of intentions.  Some of that is mental models.  people need to understand problems, solutions, and the context they’re working in.

Gentleman from SEI - this is just like requirements engineering in software.

CMK - our research has shown there is a huge gap between what policy makers lay out and what is actually happening in an organization.  We need a more reliable experience.

DS - there are policies that are not just about complying with legislation

Rosa Heckle (RH) - Policy is dependent on context

Konstantin Bernosov (KB) - privacy legislation is important

PL - people don’t always know whether their policy complies with legislation.

Lee Iverson (LI) - I’m interested in stated policies.  In electronic healthcare records there are strong policies, but rules get thrown out in emergencies or transfers of information to other organizations.  So what are the pragmatic means of dealing with policy rules?

CMK - Yes, organizations do this, but they want to log this activity.  Healthcare organizations we’ve dealt with have been firing employees for mishandling data.

LI - some would be happy to prevent inappropriate activities, but have a need to define contexts in which all barriers to access are eliminated

CMK - Yes, but there’s no reason you can’t simply incorporate such situations into a policy

LI - But do we have the technology to do this in a specific, yet context-free way?

JK - How does the terminal at which the doctor is logged on know that this is an emergency?

PL - these problems existed before electronic databases

JK - Allow access, but understand you will be logged and may be audited

KB - in some cases, no only are accesses logged, but access notifications are sent to patients when someone has accessed their data.

JK - yes, you could include such a function as an obligation in a rule.

KB - You need to know what high-level rule allowed a particular access

CMK - Yes, that’s an important problem that we’re addressing

KB - It’s complicated, and there’s an explosion of complexity.

JK - Policies are complex.  So, we kind of need NL to express them, but unconstrained NL is hard to map to something implementable.

KB - We don’t have privacy enforcement control separate from access control, so fancy policies just get translated into the same access controls, removing some of the true expressiveness of the policy language.

CMK - People are trying to twist access control mechanisms to implement privacy policies, but this is not always appropriate

Eric Toan - you shouldn’t just allow “access but audit”, you should actually deny access in the first place. 

KB - yes, but it depends on the context of a specific application.

PL - There’s a distinction in Australian law between use and disclosure.  A physician can use info to treat you, but can’t share that info with a journalist.

Jaime M (JM) - you shouldn’t allow override ability all the time

CMK - All these kind of exceptions and overrides can be built in to policy.

PL - There are fallback positions.  If patient can’t give consent, doctors have to act ethically.

DS - It’s a tradeoff of risks and benefits.  When you’re writing policies, you may have a mental model of conservativity, but maybe you don’t imagine a disaster like Katrina, so you should have some override switch for drastic emergencies.

PL - What about interaction aspects?

CMK - People are really struggling with concepts, let alone usability.  Advanced policy visualizations are needed to help people comprehend their policies and to foster accurate mental models.

AP - you should adapt policies to reflect reality.

JM - admins will eventually be overwhelmed by the sheer number of rules that exist.  You want to be able to find conflicts quickly.  Let’s apply some visualization techniques from other domains to policy visualization.  With little investment in visualization techniques, people are already understanding policies much better.

CMK - Skills of users are important.  Policy-writers are often not technical people, and you need tools to help those kind of people understand their policies.

JM - yes, but the administrator is also not being helped.  They don’t have the tools they need to find conflicts.

PL - Technical controls are not everything.  In Australia, a police officer with legitimate access was selling info to criminals.

Cynthia Kuo (CK) - Do you feel it’s any easier to figure out what rule should be set?

PL - The situation in Australia is complicated.  The Australian Constitution was modeled on the US.  In order to implement a policy you need to think about what your organization is doing w.r.t.  laws.  It’s hard to go from law to implementation.

AP - We did some work to help map from laws to implementation.

JK - Unlike US, most countries do have privacy commissioners.  Compliance means being able to show the thread from law to implementation.  We need a system that shows the systematic refinement from laws to policy to implementation, and all steps in between.

PL - Something like that has been done.

MA - You can have a policy that is general and shows linkages.  The best practices right now is to define emergency procedures beyond regular operational procedures.

DF - As we are in a usability symposium, we have seen a lot of tools and studies.  Personally, I’m interested in how well does the tool fit the person.  Any computer tool has to deal with short attention span and limited cognitive resources.  For any usability study, these are basic things.  How about thinking how usable is a tool for a person given this?

CMK - It is important to consider context in which users are using tools.  Is it in an office?  Is it in a busy enviroment?  In an emergency?

This entry was posted on Friday, July 14, 2006 at 10:18 under General. You can leave a comment here or trackback from your own site. Use the comment feed to follow comments on this entry.