This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

May 4th, 2010 Security Conference Call

From HL7Wiki
Revision as of 23:20, 10 May 2010 by Finaversaggi (talk | contribs) (→‎Security and Privacy Ontology Project)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Security Working Group Meeting

Back to Security Main Page

Attendees

Agenda

  1. (05 min) Roll Call, Approve minutes 27 April 2010, Call for additional agenda items & Accept Agenda
  2. (10 min) Rio Update
  3. (45 min) Security and Privacy Ontology Project

Minutes

1. Action Items

  • Rio Meeting:
    • Project Report-Outs:
      • Tony Weida: Slides providing an overview for the Security & Privacy Ontology projec
      • Ioana: Slides for Security & Privacy DAM, CDA R2 IG),
      • Don/Pat: Slides for PASS Audit
  • Ballot Reconciliation
    • Security & CBCC Co-Chairs will send an announcement to the Security & CBCC lists alerting that ballot reconciliation for open ballots will be conducted on regularly scheduled Security & CBCC Work Group conference calls following the Rio WGM (CDA R2 IG for CD, (D2) and Composite Security and Privacy Domain Analysis Model)
      • Specific agenda reminders will be sent to the list each week ballot reconciliation is scheduled to take place, ensuring that anyone who wants to participate is aware of these sessions
  • RBAC Permissions Catalog - Authors
    • Suzanne: Will investigate the HL7 Preview site to determine whether the authors listed for the RBAC Permissions catalog are correct

2. Resolutions

  • Ballot reconciliation for our open ballots (CDA R2 Implementation Guide for Consent Directives, D2 and Composite Security & Privacy DAM) will be completed on the two-hour Security and CBCC WG calls following the Rio WGM

3. Updates/Discussion

Rio Update

  • The joint SOA/Security meeting will be hosted by SOA on Wednesday, Q2.
  • CBCC is invited to attend that session as well
  • Bill Braithwaite (Security/CBCC), Galen Mulrooney, Ann Wrightson (SOA) and Bernd Blobel (Security) will be in attendance in Rio. David Rowed will be the acting co-chair for CBCC
  • Focus will be on report-outs for each of the projects with an eye to educating the participants who are not normally able to attend our regular work group meetings (outside the USA) but who have interest in the Security and Privacy issues.
  • Report-outs for each project will provide an overview for each project consisting of 2-3 slides per project
  • There has been some discussion about using LiveMeeting so that those who can not be present in Rio could contribute to the meeting, but it is not looking like that will be possible.
    • Lynn Laakso reported there was discussion about the possibility of having GoToMeeting available, but even that is not looking promising
    • Internet bandwidth is an issue and there is even a scarcity of projectors that will be available.
  • Joint Security/CBCC meeting will be held Q3/Q4 Monday
  • Bernd is publishing the agenda for Security along with the concerns about environmental issues (internet access, projectors, etc.)
  • It will be difficult to make quorum. The best we may be able to do is give local attendees an opportunity to present their perspective
  • Bernd has placed ballot reconciliation on the agenda to provide the forum for anyone in attendance to comment, however, Bernd has not been actively involved in the ballot, so it may be challenging for him to capture discussion related to ballot reconciliation
  • Since many of the participants commenting on the Composite Security & Privacy Domain Analysis Model (DAM) will not be present at the Rio meeting, we’ve proposed that ballot reconciliation will be conducted in the weeks following the WGM during regularly scheduled conference calls
  • Mike made a motion that we conduct ballot reconciliation for our open ballots (CDA R2 Implementation Guide for Consent Directives, D2 and Composite Security & Privacy DAM) on the two-hour Security and CBCC WG calls. Motion seconded by Serafina.
    • Vote: 12/0/0
  • Chairs will take an action to investigate how this should be announced

PASS Audit Update

  • During Monday's (May 3rd) meeting, Rob Horn presented work that he and John (Moehrke?) started on the creation of an ATNA Disclosure Record.
  • There was an action item to map the different disclosure scenarios to the platform independent model (PIM), looking for gaps
  • Pat is currently developing a transform from the PIM to DICOM 3881 so we can move down to the PIM to DICOM 3881 as a semantic signifier for the Request Disclosure Record service
  • During next week’s PASS call, we will review additional scenarios and their mapping

Security and Privacy Ontology Project

Update

  • Tony: There is not a lot to report since last week’s demonstration. As of last week, the intention in the short term is to look into references brought to light last week (REI from the University of Maryland) as well as Google search references.
    • We are continuing to flesh out the RBAC representation in the OWL model to demonstrate additional capabilities such as being able to identify inconsistencies in policy specifications based on OWL reasoning as well as to demonstrate the ability to combine or merge policies or consent directives using OWL.
  • Use cases – posted on the Security & Privacy Ontology project wiki
    • Steve posted a Functional Role use case and is working on an additional use case - Multi-role, where a user has to be assigned more than one role to gain access. This use case is illustrated in XACML – Multi-Role permission.
      • For example, to be granted access to a clinical object, a user has to have a combination of roles (e.g., physician and member of hospital staff). The access control decision function requires that the requestor has a combination of roles.
      • The group had questions about the validity of the Multi-Role use case. Some within the group felt the use case was not something we needed to worry about.
    • Most of the use cases on the Security & Privacy Ontology Wiki are intended to be used by the system’s access control function to make decisions.
    • In addition to the use cases presented by Steve, Tony raised an issue during last week’s call that may result in other use cases that reflect the difference between build-time (or design time) and run-time functionality.
    • If the categorization included in the ontology is intended to enable build-time, then the build-time process is an engineering process (manual process). In this case, a Security administrator allocates Access Control information to the various objects in the EHR (e.g., tagged as a clinical object or an administrative object). A Build-time ontology assists the Security administrator in allocating attribute values to objects as opposed to providing categories that could be used by the system for run-time decisions.

Discussion

  • Mike: What problem are we trying to solve? There are two things to be enforced: policies and obligations. Obligations are off the table for now. Policies exist and there are run time attributes (the attributes are not fixed).
  • Steve: A Security administrator tags specific objects with access control information. For example, a Security administrator tags a radiology order as a radiology object. Or a radiology order could be tagged as something more broad –a clinical object. That would then become part of the access control policy rules that go into the access control decision function. The access control decision function is the automated function within the access control system. The manual process of tagging that object uses the categories defined in the ontology but it would not be an automated process.
  • John: Why are we’re talking about manual or automated processes? At decision time, the policy in the context of the access decision are known; whether they were known for 20 years or for two pico-seconds, it doesn’t matter, the knowledge is available for the access control decision. What matters is that the policies need to be executable and the context of the access control decisions need to be known.
  • Mike: This is getting us into design. We’re providing a set of vocabularies people can use to create permissions and write policies. We’re not writing policies. Whether it’s a high or low level in the ontology doesn’t matter. You could argue that it might be best to pick something at the lowest level (e.g., a lab report), where the policy is that you have to have permission that covers the lowest level (lab reports). If the user has permission that says I can read or write t the highest level (all reports), then the lower level (lab report) is included in the user’s assertion. The ontologies become useful on the user side. All the user has to do is assert a permission equal to or greater than what the policy requires. What is determined to be the requirement for the level of access to the object is part of design and we shouldn’t be worried about that.
  • John: We need to enable that policies can be written, but not actually show the mechanism used to write the policies.
  • Steve: So the point of the ontology is to enable the designer or the security administrator to represent the access control policy in the access control decision function?
  • Mike: No that’s the point of vocabulary. Vocabulary is just a list of objects. The object you want to control needs to be called by one of the names in that list of objects. There may be an ontology, but it is up to the designer to pick the name that he wants to call the object. The user has to be able to assert permission equal to or greater than that object. That’s where an ontology might be involved.
  • Steve: In terms of the object vocabulary, if the categorization scheme is intended to enable the security administrator to select which objects to place permission on, then we can use a categorization scheme such as clinical discipline (which you may not want to configure the security system based on), but which may help that security administrator to find the particular object they are looking for.
  • John: I think we’re falling into a trap – the idea of being able to group these is very location-specific. That is the reason we have a Permissions Catalog and not a Role Catalog. The same definition for a role can mean different things in terms of what they are allowed to do in different regions.
  • Steve is presenting use cases that are illustrating how the ontology could be beneficial, e.g., used by an administrator to assign permissions based on definitions of objects.
    • It may be premature to have normative categories, but it may be relevant to create informative categories that could enable the security administrator to configure the system. If we’re unwilling to do that, what is the purpose of the ontology?
  • Mike: The primary purpose for the ontology is to help the Access Control engine to make decisions.
    • OASIS is investigating the notion of using an ontology decision point to determine the allowable permissions when the policy is being evaluated.
    • The primary use case is to facilitate engine operations to make decisions.
    • Other use cases proposed by Steve may be possible, so we shouldn’t be too critical at this point. You could make an argument for justifying an ontology that supports a security management scheme.
  • Steve: If this is just to facilitate the system administrator to configure the Security system, the categorization doesn’t have to very formal because the system administrator can impose their own judgment. But if it is intended to facilitate an automated engine, it needs to be formalized. Before we’re ready to make blanket decisions about something called a report we need to know what is the impact of saying that.
  • Pat: Are these use cases meant to feed the ontology, to ensure that the ontology is complete? Or are they the reason for the ontology’s being? I’m trying to understand why we are we having to further justify the need for the ontology with these use cases since the project scope has already been approved. It sounds like you want the use cases to drive the granularity of the ontology.
  • Steve: Yes, the precision and accuracy of the ontology. What are the high level categories that are relevant to the access control decision point?
  • Pat: Couldn’t we just create a set of scenarios or use cases – identify privacy and security problems, not just for the ontology, but in the Privacy and Security domain and then ensure that the ontology can satisfy those scenarios and use cases? The specific use for an ontology as a use case, I don’t understand.
  • Steve: I think coming up with categories for roles and operations can be done to reflect both use cases we’ve been discussion. But for objects...
  • Pat: I thought part of our scope is to build bridges between existing ontologies. For clinical objects, SNOMED is the clinical ontology. I am against trying to do a short form of an ontology for clinical objects when we can link to SNOMED.
  • Steve: We analyzed SNOMED last year, and found it was inadequate to represent objects within an EHR-S. Part of the point of this project is to come up with a categorization scheme that can be useful for access control – for security and privacy, to present to SNOMED for inclusion in their ontology. SNOMED doesn’t have a clinical ontology for security at this point that is useful.
  • Pat: I understood that they don’t cover privacy and security concepts in SNOMED, but I thought that SNOMED covered the clinical objects we need.
  • Steve: That is not correct.
  • Pat: Then the scope of the project has changed significantly. Do we have the domain expertise to be creating clinical objects?
  • Mike: We do, but we’re not changing the scope of the project. Steve is correct, we have the notation to integrate this work with SNOMED. The scope statement says we would do this by mapping to current SNOMED objects.
    • That may be through a bridge ontology.
    • Bernd believes we shouldn’t attempt to do that directly, but we could build a bridge, like a butterfly table in a database.
    • It’s possible that we could present the ontology we come up with to SNOMED and ask that they include it as a new domain inside SNOMED. They’ve indicated a willingness to include things other than clinical concepts, so they might include this HL7 work related to privacy and security.
    • At the start of this project, we need to focus on our goals which might change over time, but for now, we should stick with the Information Model we have. And a good place to start is with the RBAC.
  • Steve: The two use cases, one which enables a manual process, the other which enables an automated process, will help us decide to what extent we need OWL to categorize the object vocabulary.
  • Pat: All we need to do is to identify attributes that are candidates for categorization, especially when we’re talking about localization. We don’t have to put the categorization in the ontology itself, but recognize that these are things that could be used to categorize.
  • Steve will publish the use cases on the Security and Privacy Ontology project wiki. We can review next week and come to a decision as to which of the use cases we want to tackle.
  • Prior to adjourning the meeting, Steve raised a question about the RBAC Permission Catalog ballot on the preview site. It still has the original authors from last year (version 1). Should we update the authors to reflect the authors as of February 2010.
    • Suzanne will investigate the Preview site and update as needed

The Meeting was adjourned at 2:00 PM EDT.



Back to Security Main Page

Retrieved from "https://wiki.hl7.org/w/index.php?title=May_4th,_2010_Security_Conference_Call&oldid=36369"