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

April 20th, 2010 Security Conference Call

From HL7Wiki
Jump to navigation Jump to search

Security Working Group Meeting

Back to Security Main Page

Attendees

Agenda

  1. (05 min) Roll Call, Approve minutes 13 April 2010 & Accept Agenda
  2. (55 min) Security and Privacy Ontology Project
    • Methods for modeling RBAC permissions in the Security/Privacy Ontology, with discussion of questions and examples

Minutes

1. Action Items

Reminder: Composite Security and Privacy Domain Analysis Model ballot is now open until May 9th. Please vote!

2. Resolutions

  1. Suzanne motioned to approve the minutes of 13 April; seconded by Pat Pyette
  2. Over the next couple of weeks during the CBCC call, time will be dedicated to review a draft outline for the Privacy Policy Reference Catalog white paper and a straw man example of what a privacy policy template will look like.

3. Updates/Discussion

The main topic on today’s agenda was the Security and Privacy Ontology project scheduled to extend through both the Security and CBCC meeting hours. Given that most attendees have been present at the start of the Security hour in the past few months, we dispensed with ongoing project updates for both Security and CBCC at the top of the first hour so as not to interrupt the flow of discussion once we got into the Ontology discussion.

Project Updates

Privacy Policy Reference Catalog
  • The TSC officially approved the project on Monday, April 19 after a friendly amendment to the scope statement to include a white paper as the first deliverable for the project. The white paper is intended to communicate to the rest of the HL7 community the purpose for the catalog, how it will be used and what it will look like.
  • We’ve been collecting a list of people who have expressed interest in participating in this project and who have various roles in the project, but we welcome anyone who is not already engaged and who wishes to be involved. Please contact Pat, Suzanne, Richard or Don to get involved.
  • One outstanding question is whether we want to dedicate specific project time on the CBCC agenda going forward for this project, other than just a status update.
    • Richard: I propose that an outline of the white paper be presented to the group at an upcoming meeting giving us more of a narrative description of the project than revealed by the Project Scope Statement. Then we can go back and see where the various participants want to plug in their resources.
  • It was resolved that over the next couple of weeks some time will be dedicated during the CBCC call to review a draft outline for the white paper and perhaps some presentation material on what the catalog is, what it contains, how it links to Consent Directives, and how all that can be used to establish and communicate patient privacy preferences across jurisdictions. It would be helpful to include a straw man example of what a privacy policy template looks like.
    • Richard questioned whether the privacy policies for hospitals, organizations and jurisdictions are included in this catalog as well as patient preferences. During the Information Modeling we’ve done in this area, we’ve worked on a standard that serves multiple purposes because the content is essentially the same.
      • Pat: Yes, the catalog will address all areas, but to be specific, the way the project has been communicated to the TSC is that we would contact and sample as many agencies and jurisdictions as we could to obtain those policies and create something that is common across all, but we won’t be creating and maintaining a catalog of specific policies, e.g., SSA, Canadian jurisdictions, etc.
  • If you have questions/issues that you would like to see specifically addressed in the white paper, please forward those questions (and preferably even answers) to Pat.
PASS Audit
  • The focus of this project is creating a standard for extracting information related to the disclosure of PHI
  • The draft conceptual information viewpoint has been posted on the PASS Wiki site. Comments are welcome.
  • We are currently in the process of walking through the Platform Independent Level Semantic Signifiers for the capability (Request and Response).
  • We’re expecting to complete a draft the Platform Independent Model (PIM) by the middle of May.
  • Once the PIM is complete work will begin on at least one platform specific model (PSM) that is directly implementable. The entire work item will be balloted in September.

Security & Privacy Ontology Project

The focus of today’s session is on methods for modeling RBAC permissions in the Security/Privacy Ontology, with discussion of questions and examples.

  • Tony provided a recapped of last week’s discussion for those who were not present.
    • Powerpoint presentation of an overview of OWL, a web ontology language which is a W3C specification and the de facto standard for representing formal ontologies, as well as Protégé knowledge engineering environment from Stanford, particularly the Protégé-OWL editor plug in.
    • This was followed by a demonstration in Protégé of an initial stab at representing a Security and Privacy ontology represented in OWL with focus on HL7 RBAC Constructs.

Tony then proceeded into today’s discussion:

  • The first tab that displays in Protégé is the annotations tab. This is where metadata about the overall ontology as well as statistics are documented
  • So far what has been done is to describe several sample objects based on the RBAC catalog, e.g., Operations, taking into account a hierarchical organization based on some of the work done last year.
  • One of the advantages of modeling like this in OWL, in addition to creating a hierarchy of artifacts for organization purposes, we can also give them formal descriptions based in logic so we can see in more precise terms how each of these things proposed supposed to be defined. So that when we discuss whether the definitions or hierarchies are right or not, we can speak in more precise and at a greater level of detail than we could if we used simply names of objects and more informal English descriptions.
  • Class hierarchy – in addition to the objects and operations, permissions and roles have been modeled
  • One of the key facilities of OWL and systems that work with OWL is the ability to use algorithms and software to reason about the description of classes and individuals and their relationship to each other.
    • The classifier software can take a collection of these descriptions and automatically organize them into a taxonomy that reflects their definitions and which can be thought of as a refined version of the defined taxonomy that is spelled out.
    • The solid circular icon to the left of the names represents Primitive Classes
    • The icon with the ≡ represents Fully Defined Classes
  • We also talked about Necessary and Sufficient conditions. If you can logically describe a concept in such a way that everything about the description is necessarily true about the class of interest, and on the other hand, everything that is described to recognize instances of classes, then the classifier can do more about how that class relate to other classes.
  • For example, among the Permissions created were several types of new orders:
    • NewLaboratoryOrder concept was annotated using its identifier from the Permission Catalog and given a logical definition under the equivalence class to indicate it is a complete definition for what it means to be a new laboratory order. It is defined as a Permission which operates on exactly one Laboratory object by the Create operation.

Approaches to building this ontology:

  • There are a couple of different approaches that can be taken, and both can work depending on the perspective you want to take when you model the ontology. It's most important to be consistent in the way things are modeled throughout in order to end up with consistent results.
    • One approach, the one taken here, reflects definitions as they were worded in the RBAC catalog. This particular permission refers to lab order in the singular. If someone wants to place an order for an order set, where an order set is a collection of different lab orders that are related and treated as a unit, then we could model collections of lab orders and give permission to that in the singular.
    • Another approach is expand the definition of the permission and say that instead of permitting ordering of exactly one lab order, change the cardinality to ‘’at least one lab order’’, the upper limit being unconstrained. If we take the position that the permission is one lab order at a time, a system that implements permissions based on an ontology such as this could let someone order a set of lab orders by seeing that they have the permission to do them one at a time and then letting the operation go through. Alternatively if we change the model to allow one permission to refer to multiple lab orders, which would be a more general approach, it would apply to a collection of orders at once and that would be a more powerful way to go.
  • John: The current permissions catalog is based solely on the set of use cases that were brought up during the time that the catalog was defined. If you have new use cases, then you analyze them and create new permissions.
  • Tony: As a reminder, the RBAC Permissions Catalog that was balloted presents a set of Operations and Objects as Normative and presents the current set of Permissions as “Non-normative” examples.
  • Suzanne mentioned that she has received a number of emails suggesting additional use cases for the RBAC catalog.
  • Tony: We’ve got a set of tools at our disposal. We’ve got the balloted RBAC specification, the on-going work on the Domain Analysis Model and now this Ontology project. The ontology project is a vehicle for exploring additional use cases and potentially for making changes to the way we model Permissions. One of the things we should think about is how we want this Ontology artifact to relate to other artifacts like the DAM and to what extent we want to keep them coordinated in the short term versus the long term.
  • John: I don’t think we know right now. These are all new things to us, and to HL7. How they will mesh is unknown. Every project that the Security and CBCC WGs has going is breaking new ground within HL7.
  • Richard: Is this groundbreaking work outside of HL7? Is this the first time people have thought about connecting a domain analysis model with ontologies?
  • John: Ultimately it may all become clear as to how these all mesh. From a high-level perspective, it makes sense as to how these things are related, but the details are unclear, especially since our DAM is still in ballot.
  • Steve: There is an OASIS effort that has linked a UML reference model to a reference ontology called the Reference Ontology for Semantic Service Oriented Architectures which is now posted on GForge. This is a public review document and is in a different domain, so it doesn’t deal with the same information that we’re dealing with. But it is one group’s effort in trying to define the high level concepts of a reference model and a reference ontology.
  • Tony: Back to this initial effort. This ontology artifact is just getting started. There are a couple of strategies for working though this: breadth first, versus depth first.
    • One possibility is to initially populate the RBAC portion with representative examples, and then move on to model other areas.
    • Alternatively, we could focus more intensively on the RBAC area and pay detailed attention to it. Personally I’m inclined to press on the RBAC portion at least for a while, looking to the RBAC and the DAM as sources of information for working on the ontology.
    • There are the related questions: how closely do we want to stick literally to the RBAC balloted material versus taking advantages to consider potential improvements like the one we were discussing earlier about the cardinality of laboratory orders.
  • In a related FYI, Tony mentioned that the Ontology Development Methodology presented by Steve is currently being modified and will be discussed in future calls

Benefits of OWL and Protégé

  • The RBAC catalog is a list of 101 different objects listed in alphabetical order.
    • With an ontology, we have the opportunity to organize these in a hierarchical order that makes it easier to perceive things, or if we want to add something new it is easier to see where it belongs.
  • A good property to consider is being able to “future-proof” the definitions for Permissions.
    • This is a double edge sword however. It’s very helpful to organize things in such a way that you automatically pick up things that you want to, but you don’t want to pick up things inadvertently, so you still have to think through the consequences of modeling things in a certain way.
  • Another valuable aspect of Protégé is that you can create individual instances of Objects, Operations, Permissions and people in Roles and use a Description Logic reasoner to describe a specific Permission someone is requesting to determine whether that Permission should be granted based on the way things are described in the ontology.
    • This is not to say that everybody needs to use the ontology directly when they implement a security system that handles permissions. But the fact we’re able to pose those examples and get permit and deny answers allows us to work through specifics of how the pieces of our model fit together and confirm, using a set of test cases that things work as expected.
    • Mike mentioned during our last call that some vendors are looking at using ontology decision points as part of their decision apparatus. In the short term, it might be useful to create a specific example to see how the Protégé Reasoner evaluates a request for a permission and grants it in one case and denies it in another based on the model we’ve described.
  • The OWL language allows you to hierarchically organize ontologies in a component model.
    • We can separate out pieces of RBAC which are Normative from illustrative examples like assignment of Permissions to Roles (Non-normative). We could start by creating a root ontology which represents the HL7 RBAC Objects and Operations and could include that in an example ontology which adds example Permissions.
    • We could then include the combination in a further example ontology for XYZ hospital where we create a set of Structural and Functional Roles that are in use at XYZ and then assign Permissions to those Roles.
    • This way, we represent all the different elements of Privacy and Security and have a clean way of separating out different aspects in terms of being Normative and Non-Normative, and Universal versus Local.

Questions about the approach to building this ontology

  • Richard: Where would concept of Patient Consent be located?
  • Tony: That is in a part of the model which we haven’t yet fleshed out. We’ve only gotten to the RBAC material. But we could start introducing other classes for Privacy Policies or Consent Directives. Those classes will refer to classes of Objects and Operations from the RBAC eventually. One of the goals is to be able to model these things in a unified framework.
  • Richard: Is the goal for the project is to work through all of the elements of Privacy and Security, or are you limiting your focus to only the RBAC catalog?
  • Tony: Ultimately the goal is to include all elements or Privacy and Security, but to start with, we will focus on RBAC. Whether you go depth first or breadth first, you probably end up in the same place.
  • Steve has posted two new use cases on the Security & Privacy Ontology Wiki that illustrate how having a hierarchical list of Operations and Objects could be used in designating Permissions.
  • Tony: You can think of the use cases as proposed requirements on the one hand and motivation on the other. I think everyone agrees that Operations can and should be organized hierarchically and it is possible to take advantage of that hierarchy to grant or deny Permissions at a suitable level of generality that allows you to be more concise in the way you express Permissions.
  • Richard: So the scope of the project is to come up with a hierarchical set of definitions for these Operations?
  • Steve: Yes, however we have not yet organized the Object vocabulary in a hierarchical form.
  • Richard: So is this where you’re proposing to use SNOMED-CT or an existing ontology?
  • Steve: In the original work, we looked at several external vocabularies and ontologies but none of them had the type of organization that we require.
  • Richard: It appears this tool could also facilitate the work that Pat and Don are doing on the Privacy Policy Catalog. When we get to the point where we add the privacy policies and consents to the ontology, it seems it will be useful in terms of deciding how to define these “templates” or the entries in the catalog. Basically the “templates” would reference this ontology, is that correct?
  • Don: We’re anticipating that there is a formal logic behind this. The ontology will inform the catalog.
  • Richard: Working through Operations, I remember that we could never get to an agreement.
  • Pat: This is exactly why we need this ontology. The disagreement was due to the fact that people were trying to cram Privacy concepts into Security concepts and they didn’t map one-to-one and they never will. He ontology will help to describe the relationship of a single privacy concept for instance to the one or more Security concepts and vice versa. The ontology is useful because it is not only vocabulary but it contains concepts and rules (relationships).
  • Richard: When you say vocabulary, is that the same as terminology or terms?
  • Tony: Although some people use specific words, there is no generally agreed upon distinction between vocabulary and terminology as technical terms. The line between vocabularies and terminologies on the one hand, and ontologies on the other hand is blurry. Maybe you could say that ontology is used to describe “high-end” terminologies. SNOMED-CT for example is referred to as a terminology, but it also many of the hallmarks of an ontology being based upon Description Logic (DL) and formal definitions of concepts that are organized using a DL classifier. Sometimes people talk about other types of reasoning that go along with ontologies as well. I think we can use ontology, terminology and vocabulary interchangeable without getting in trouble.
  • Pat: I am not arguing against the correctness of that statement, but I think that for our purposes, if we start talking about a vocabulary as an ontology within HL7, we will get in trouble.
  • Tony: There are at least a couple of good reasons for referring to this artifact as an ontology. First, because the project scope statement calls it an ontology. But more than that, to distinguish this from what people traditionally think of as an HL7 vocabulary, mainly things that are maintained in the HL7 vocabulary repository. This is more rigorous because it is based on formal definitions using description logic which is something that HL7 doesn’t do for its internally maintained ontologies. This ontology places a lot of emphasis on relationships, connecting concepts. Although strictly speaking, while HL7 rarely does it, the HL7 repository supports that ability as well. There are also administrative processes that HL7 carries out on different artifacts. There is an expectation that if HL7 is going to maintain a HL7 vocabulary, it’s for use in one of its message or document specifications that will be implemented, in particular that the elements of the vocabulary will be used to assemble value sets that will be associated with attributes in the messages or documents. While this ontology could be used that way down the road, we’re not anywhere near that yet.
  • Pat: As part of the work we’re doing on the PASS Audit project, I’ve started to assemble a list of all the privacy and security vocabulary that exists in the HL7 vocabulary, and amazingly, I’m finding much of it there, with a lot of overlap. Our work in this area may be very helpful in highlighting some of the issues surrounding HL7 vocabulary. While it may be challenging to get the work we are doing here to have some impact, if we don’t get it back into HL7, then we’re probably wasting our time.
  • Tony: One of the things that people have focused on in biomedical terminologies like SNOMED-CT is the ability to have multiple terms (words or phrases) associated with a single concept. By separating out the language constructs used to refer to concepts from the description logic representation of the concepts themselves, you can have different terms or synonyms in different languages which is useful for communicating across borders.
  • Don: In situations where a term is being used for two separate concepts, how do you deal with that?
  • Tony: One thing is to tie the concepts to unique meaningless identifiers. So the definitive reference will be the identifier as opposed to the term.

Next steps

  • Steve: What appears to be missing here are the conditions represented in the constraint catalog (time dependency, separation of duty, cardinality, etc.) How would you represent that in this ontology?
  • Tony: That requires some research and thought rather than an answer off the top of my head.
    • The constraint catalog is another dimension of the ontology, just as we were discussing Privacy Policies and Consent Directives as examples of other dimensions. A harder thing to tackle is the concept of the Constraint Catalog, like representing temporal information, e.g., this permission is only valid during certain hours.
    • The Constraint Catalog gives you more power and flexibility in granting or denying of Permissions. With basic RBAC, someone based on their Role gets Permission to act on a particular Object or is denied permission. Once you look at Constraints, it may depend on what time of day it is, where they are accessing the information from, etc., it becomes more complicated.
  • Richard: So we could potentially test things like policies using Protégé?
  • Pat: We have to be careful about what it is we’re testing. I would guess that OWL and Protégé are not the best tools for doing that type of testing.
  • Suzanne: Mike has been working on a testing tool in his lab.
  • Tony: This is not an all or nothing situation. Having built an ontology, you can show examples based on the relationships that have been established, you can make decisions to grant or deny permissions. But that's not the same as making the claim that if someone is implementing a production security system they ought to use Protégé to test that system.
  • Richard: What tool is being used by Mike in the lab? If you want to be rigorous, it would seem to be necessary to use a tool like Protégé so that these things (decision engines) are not just black boxes.
  • Steve: Would it make sense to add some constraints the ontology at this point, say time dependency, location, and start working through an exercise?
  • Tony: I could add a couple of types of constraints for discussion purposes.
  • Suzanne: I recommend that the questions Richard has are brought up be added to the agenda for next week to be discussed when the Security co-chairs are on the call.
  • Pat: Protégé is a tool used to build ontologies, it is not a silver bullet. Protégé is used to define concepts and establish relationships between concepts with formal logic, in this case, specific concepts in Privacy and here how they may map to specific concepts in Security. In some cases they won’t map and that’s OK. We also have instances of privacy policies that exist in most if not all jurisdictions. So the other question is, how do we test those policies. That’s a different problem and probably a different tool set is used to solve that problem.
  • Richard: So are there any existing tools for that problem? Are we focusing too much attention on OWL and Protégé?
  • Pat: The Privacy Policy Catalog is not meant to be an ontology, that is the point I was trying to make. The two projects are closely related in that we want to make sure that the Privacy concepts that come out of the policy work we do are reflected in the ontology. It’s basically, who comes first, and to make sure that were in synch.
    • There is a question I want to ask Tony related to our approach. There are already Security and Privacy Policy ontologies out there, for example, one on the US government open source site. Are we planning to use those as a spring board, or was the intent to do everything from first principles?
  • Tony: Please send references to those.
  • Don: There has been extensive work on OWL-based ontologies associated with developing access control ontologies that can be processed in standard inference engines. The REI work out of the University of Maryland is one of those ontologies. Formal logic processing through inference engines is probably not the best way to make run-time access control decisions. The ontology plays a role, but that’s not the same thing.
  • Tony: I wouldn’t want to be perceived as positioning OWL and Protégé as the silver bullet for this problem.
  • Richard: My point is that if we know of other tools that are out there we should discuss them.

Conclusion

  • Tony: So far we’ve started focusing on HL7 RBAC, and as we expand our attention we should be looking for existing work to absorb or adapt as appropriate.
  • On next week’s agenda, we will bring up the questions posed by Richard during today’s call.

Meeting was adjourned at 3:00 PM.

Back to Security Main Page

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