March 2nd, 2010 Security Conference Call

Security Work Group Weekly Conference Call

Attendees

• Tabitha Albertson
• Bernd Blobel Security Co-chair, absent
• Jim Buckner
• Steven Connolly
• Mike Davis Security Co-chair, absent
• Suzanne Gonzales-Webb CBCC Co-chair, absent
• Rob Horn
• Don Jorgenson
• John Moehrke Security Co-chair
• Milan Petkovic
• Pay Pyette
• Ioana Singureanu
• Serafina Versaggi scribe
• Craig Winter

Agenda

1. (05 min) Roll Call, Approve Minutes Feb 23rd, 2010 & Call for Additional Agenda Items
2. (40 min) Harmonized Privacy and Security DAM Peer Review
   • Negotiate Policies Use Case - deep dive

ACTIVE PROJECTS

• (15 min) Security and Privacy Ontology project

Announcements

An update to the Harmonized Security Domain Analysis Model presentation has been posted on GForge in the Doc section under the Security Domain Analysis (DAM)Project folder

• Update to this presentation includes:
  • Added analysis for Use Case S.4 Negotiate Privacy Policy
    • Slides were added at the end of the presentation
    • They show how the use case relates to technical implementation of the Access Control System (ACS)
    • The elaboration shows how to automate the use case – as there needs to be a way for the consenter to submit privacy preferences that could be adjudicated by the ACS in an automated fashion since the use case is a set of manual steps
    • The elaboration assumes that the work for the use case is performed by automated systems
    • Sequence diagram shows the final step of the negotiation (consenter has the choice to accept the outcome of the negotiation or to reject it, in which case, nothing is done
  • The Related Information and Associations slides show the information related to the Negotiate Privacy Policy use case and the relationships between the classes to arrive at the Information Model
  • The model has NOT been changed – these slides are merely to describe the analysis flow from the business use cases to the technical use cases, sequence diagrams and information model.

Minutes

1. Action Items

• Team: Please submit peer review comments to the Harmonized Security Domain Analysis Model by COB March 4, 2010

3. Updates/Discussion

Harmonized Privacy and Security DAM Peer Review

The group agreed to use today's meeting to address some questions and comments related to the Negotiate Privacy Policy use case (S.4) even though due to a number of absences today (due to HIMSS and RSA), we would need to repeat much of the discussion next week. The following summarizes today's comments:

1. The operations described in the Negotiate Policies sequence diagram are not defined in the draft Harmonized DAM. These operations were defined in the original Security DAM and will be included in the next draft revision
2. It was felt that the sequence diagram does not make it clear whether it is describing the Negotiate Privacy Policy use case (which is a manual process) or the Automated Policy Resolution use case S.3
   • The sequence diagram is intended to describe an automated version of the manual workflow described in the S.4 use case. The manual process is out of scope for this project and the purpose of this effort is to focus on those aspects which can be made interoperable
     • There is a challenge in taking a manual process and turning it into a process where systems assume some of those responsibilities (i.e., the responsibility for creating a consent directive form)

• • • The operation submitPrivacyPreference actually includes two steps: (1) a request from the consenter for a blank privacy references form, (2) the consenter submits their privacy preferences. For the purpose of simplicity in the diagram, these two steps are compressed and represented as a single action
    • The parameters included in the operations indicate these operations are of a structured (not unstructured-manual) type
• It will be clarified that the Access Control System in the Negotiate Policies sequence diagram is in a different domain than the PHR domain (the consenter’s privacy preferences are not declared within Sunnybrook Hospital’s domain, otherwise there would be no need for this use case)
  • The negotiation process is centered around consent directives that are derived from existing policies that might be slightly modified by an organization (i.e., the organization constrains jurisdictional policy)
  • The point of this use case is to describe the situation where the consenter presents privacy preferences that are outside the organization’s policy
    • The intent of the sequence diagram is to depict the two possible outcomes: one where the consenter’s privacy preferences do not conflict with organizational/jurisdictional policies (legally binding policy is returned from the ACS) and the Consent Directive is added to the Consent Directive Management System (within the organization’s domain) and two, where there is disagreement between the consenter’s expressed privacy preferences and the organizational/jurisdictional policies in which case there is no legally binding policy created based on the consenter’s preferences and a Consent Directive is not added to the organization’ Consent Directive Management System
• It was pointed out that it is NOT the function of an ACS to return a policy. An ACS evaluate requests for protected resources. This puts a new requirement on an Access Control System, so perhaps the actors within this sequence diagram need to be adjusted
• The intent of the form is to represent an example of the way in which a consenter can express the privacy preferences that may or may not be allowed by the privacy policy against which the preferences are evaluated
• As soon as there is a conflict detected by a system, the manual process must be invoked – the automated process is only when there is an agreement between preferences and existing policies
• There is a question as to whether there is sufficient encoding to detect conflicts between expressed privacy preferences and existing organizational/jurisdictional policies. This requires knowing the encoding of the policies
• To detect conflicts, there must be a standards-based way to encode policies, which John argues is not yet available
• The concept of negotiation was something that was only raised last year by HITSP when many assumed that negotiation was in scope. Others within HITSP felt that negotiation was always human behavior, not computer-behavior. At that time, the Security WG decided to take this on to analyze. As we delve further into this analysis, we may have to revisit the use cases and further analyze the concept of negotiation
• The group is encouraged to submit their questions and comments on the Peer Review form so they can compiled and responded to. be taken into consideration and so the group can continue with more formal discussions on future calls