March 23rd, 2010 Security Conference Call

Security Work Group Weekly Conference Call

Attendees

• Tabitha Albertson
• Tom Bonina
• Bill Braithwaite
• Steven Connolly
• Allen Hobbs
• Don Jorgenson
• John Moehrke Security Co-chair
• Milan Petkovic
• Pat Pyette
• Scott Robertson
• Ioana Singureanu
• David Staggs
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe
• Craig Winter

Agenda

1. (5 min) Roll Call, Approve minutes from Security March 16, 2010 & Call for Additional Agenda Items
2. REPORT OUTS
   • (5 min) PASS Audit update
   • (5 min) Privacy Policy Reference Catalog update
   • (5 min) Security and Privacy Ontology project
3. ACTIVE PROJECTS
4. (100 min) Harmonized Security and Privacy DAM Consolidated Peer Review Comments latest version following this meeting

Minutes

3. Updates/Discussion

PASS Audit update

• Pat: Timeline for the PASS Audit Service ballot:
  • Initial draft for review will be posted on the PASS wiki site on March 24.
  • PASS project group will call for an internal vote to determine whether to forward on March 29. We will be accepting pre-ballot comments up through April 2.
  • Assuming the PASS project group decides to move forward, on April 5th, we go for a vote in the SOA Work Group, and on April 6th, we will look for supporting votes from the Security and CBCC workgroups
  • April 6-9 will be used to put finishing touches on the document if approved by all WGs, and April 9th is the last day to submit for ballot.
• Content focuses on the capabilities and the service required to extract information from an Audit Service to support Disclosure Accounting. This will include both conceptual level and platform independent level and a mapping of conceptual Privacy business artifacts and concepts to what we know about RFC-3881 and health care auditing standards.
• Another aspect of the ballot is related to Submit audit record. That calls out DICOM Supplement 95 and the IHE report audit event, part of ATNA as references and the ballot recommends those options.
• Ioana: If you recall, during the first release of the Composite Privacy DSTU, we had the consent directive override record information model. You may be able to reuse portions of that to account for disclosures, even though it was designed to account for overrides. Everything other than the OverrideRecord (action, Information Artifact that was accessed, the person who access it) is probably the same. That model is not in the current version of the Privacy DSTU, but can be found in Subversion (SVN) under Future Use
• Pat will review the DAMs to make sure that the concepts in the Audit work align with the concepts in the Privacy and harmonized Privacy and Security DAMs. Wherever they don’t, we will bring that back to this group for discussion.

Privacy Policy Reference Catalog

• Pat: Nothing to report on this project. The latest version of the project scope statement is now posted on GForge but haven’t yet sent it to the Steering Division as yet. Pat has requested Suzanne and/or Richard’s help to identify the email address for the appropriate Steering Division and will forward the scope statement as soon as that has been located.
• Will update the group in future meeting.

Security and Privacy Ontology Project

• Mike reports that the project scope statement will be presented to TSC next Monday. He does not expect any further issues to be raised. In addition, the SOA Work Group will modify their Ontology project scope to reflect the Security & Privacy Ontology plan.

Harmonized Security and Privacy DAM Consolidated Peer Review Comments

Remaining comments submitted for Peer Review were reviewed by the group.

• Steve Connolly comments related to the use cases included in the background section were deferred to the ballot reconciliation process since the use cases have already approved for inclusion in the DAM.
  • Comment #17 Automate Policy Resolution was resolved to merge the two use cases (Automated Policy Resolution and Negotiate Privacy Policy) into a single elaboration (i.e. sequence diagram) and to delete the “Negotiate Privacy” technical use case since some negotiations will continue to be manual processes.
• Pat Pyette comments:
  • Comment #3 is an area where there may be a need to harmonize security and privacy terminology related to “protected information”. Security policies are concerned with anything controlled by policy and calls it a protected resource or protected information. Privacy is not necessarily as broad. It is more focused on Personal Information or Personal Health Information.
    • John: Personally identifiable information is inclusive of IIHI and PHI. There is not a problem but we should make sure that it is clear that the terms that are used in the Privacy DAM are inclusive of the terms used in Security, but it is not the reverse. This is not something new that we have to invent.
    • Bill Braithwaite: I think we have to decide where we’re going to make the cut. The European Union definition of Personal Information (PI) is the broadest, and the HIPAA definition of Individually Identifiable Health Information (IIHI) is a subset, and then Protected Health Information (PHI) is a further subset of IIHI that is in fact protected by the privacy and security rules.
    • Ioana: The problem is that protected information could include information other than health information, so it could be broader than IIHI.
    • Bill: In Europe, Personal Information is protected by law; in the US it is not.
    • Ioana: Let’s borrow John’s mantra and say that it is policy based. The policy decides whether any one of these types of information is the subject of the policy.
    • Pat: As long as we’re clear in terms of the scope of the DAM, we can choose a term and live with it.
    • Ioana: The policy will determine which type of information to protect. In the US, personal information will not be covered, but in Europe it will be. We want this DAM to cover all realms. We’re just providing some criteria that are relevant in a certain context. We should define all and say that depending on local, whatever happens to
    • Bill: What we’re doing is defining the term Protected Information that is a subset of Personal Information based on policy.
    • The group agreed that from a Security perspective, the best solution is to define and use the term Protected Information noting that IIHI and/or Personal Health Information (PHI) are subsets of Protected Information which are covered by policies.
  • Comment #8: Question about the why the Consent Directive state machine diagram is different from that used in PASS Access Control. If the Consent Directive is a subset of the ACS, that should be called out.
    • Resolved to add the Policy Lifecycle state machine diagram from PASS ACS to the DAM. There are fewer states in the CD state machine because they are different objects. One of Bernd Blobel’s comments also recommended the addition of the PASS Policy Lifecycle diagram.
• Mike suggested that we include one of the diagrams from PASS Access Control, but rather than including the diagram itself, we will just reference it.

Meeting adjourned at 2:00 PM EDT

No significant motions or decision were made