This wiki has undergone a migration to Confluence found Here
Difference between revisions of "May 11th, 2010 Security Conference Call"
Jump to navigation
Jump to search
Finaversaggi (talk | contribs) |
Finaversaggi (talk | contribs) |
||
Line 48: | Line 48: | ||
---- | ---- | ||
Steve reviewed two additional [http://wiki.hl7.org/index.php?title=Security_and_Privacy_Ontology#Use_Cases use cases] posted to the S&P Ontology project wiki. These use cases are based on [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=18199 ''ISO 10181-3''] ''- Security frameworks for open systems: Access control framework'' | Steve reviewed two additional [http://wiki.hl7.org/index.php?title=Security_and_Privacy_Ontology#Use_Cases use cases] posted to the S&P Ontology project wiki. These use cases are based on [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=18199 ''ISO 10181-3''] ''- Security frameworks for open systems: Access control framework'' | ||
− | #[http://wiki.hl7.org/index.php?title=Security_and_Privacy_Ontology_Use_Cases#Enable_Design_of_Access_Control_System Enable Design of Access Control System] | + | *''Use Case #1: '' [http://wiki.hl7.org/index.php?title=Security_and_Privacy_Ontology_Use_Cases#Enable_Design_of_Access_Control_System Enable Design of Access Control System] |
− | #[http://wiki.hl7.org/index.php?title=Security_and_Privacy_Ontology_Use_Cases#Facilitate_an_Automated_Decision_Function Facilitate an Automated Decision Function] | + | *''Use Case #2: ''[http://wiki.hl7.org/index.php?title=Security_and_Privacy_Ontology_Use_Cases#Facilitate_an_Automated_Decision_Function Facilitate an Automated Decision Function] |
*ISO 10181 refers to a process that states a Security Policy is written in natural language and it uses broad terminology to express. It goes through a process in which a Security Domain Administrator (SDA) takes the policy and interprets that policy into rules that are then entered into an access control system. | *ISO 10181 refers to a process that states a Security Policy is written in natural language and it uses broad terminology to express. It goes through a process in which a Security Domain Administrator (SDA) takes the policy and interprets that policy into rules that are then entered into an access control system. | ||
*Use case #1 is a manual process – an SDA takes the security policy and converts it into rules that can be entered into the access control decision function. | *Use case #1 is a manual process – an SDA takes the security policy and converts it into rules that can be entered into the access control decision function. | ||
Line 57: | Line 57: | ||
#(manually) apply the appropriate security rules to that to be entered into the access control system. | #(manually) apply the appropriate security rules to that to be entered into the access control system. | ||
#*The purpose of this use case is to enable the manual process of finding the objects. It is not meant to imply that the categorization scheme is entered into the Access Control Decision function. | #*The purpose of this use case is to enable the manual process of finding the objects. It is not meant to imply that the categorization scheme is entered into the Access Control Decision function. | ||
− | *The Basic Scenario – the objects are divided into two categories: clinical documents and administrative objects. The security policy is very simple. It distinguishes between clinical and administrative objects. *The alternative scenario: the only an alphabetical categorization is used. That provides a base level, minimum requirement. We assume that the list of objects (say, 1000 objects), browsing through that list is difficult by categorizing them alphabetically; yet it fulfills the requirements by decreasing the size of the list (alphabetically), and aids the administrator to find the object, but it does not provide any information that are the security requirements for the object. This is applied by the security administrator. | + | #*The Basic Scenario – the objects are divided into two categories: clinical documents and administrative objects. The security policy is very simple. It distinguishes between clinical and administrative objects. |
− | **Politically speaking, the alternative scenario is probably the least disruptive because everyone can agree on an alphabetical scheme, but it does not provide information regarding the security value of those objects. | + | #*The alternative scenario: the only an alphabetical categorization is used. That provides a base level, minimum requirement. We assume that the list of objects (say, 1000 objects), browsing through that list is difficult by categorizing them alphabetically; yet it fulfills the requirements by decreasing the size of the list (alphabetically), and aids the administrator to find the object, but it does not provide any information that are the security requirements for the object. This is applied by the security administrator. |
− | + | #**Politically speaking, the alternative scenario is probably the least disruptive because everyone can agree on an alphabetical scheme, but it does not provide information regarding the security value of those objects. | |
+ | #*So the value of use case #1 is to decrease the size of the list of objects to aide the SDA to discover the objects. | ||
*In ISO 10181, the process which is taken to get to an automated use case, you have to go through the manual use case. The next use case, #[http://wiki.hl7.org/index.php?title=Security_and_Privacy_Ontology_Use_Cases#Facilitate_an_Automated_Decision_Function Facilitate an Automated Decision Function], is the automated use case, but a pre-condition is to go through the manual use case. | *In ISO 10181, the process which is taken to get to an automated use case, you have to go through the manual use case. The next use case, #[http://wiki.hl7.org/index.php?title=Security_and_Privacy_Ontology_Use_Cases#Facilitate_an_Automated_Decision_Function Facilitate an Automated Decision Function], is the automated use case, but a pre-condition is to go through the manual use case. | ||
*Last week, Tony described two different kinds of use cases: build-time versus run-time. Enable Design of Access Control System is an example of a build-time use case; the second, Facilitate an Automated Decision Function is an example of a run-time use case (operational mode). | *Last week, Tony described two different kinds of use cases: build-time versus run-time. Enable Design of Access Control System is an example of a build-time use case; the second, Facilitate an Automated Decision Function is an example of a run-time use case (operational mode). |
Revision as of 22:41, 15 May 2010
Contents
Security Working Group Meeting
Attendees
- Tabitha Albertson
- Steven Connolly
- Mike Davis Security Co-chair
- Suzanne Gonzales-Webb CBCC Co-chair
- Rob Horn
- Don Jorgenson
- Jim Kretz
- Rob McClure
- John Moehrke Security Co-chair
- Pat Pyette
- Richard Thoreson CBCC Co-chair
- Serafina Versaggi scribe
- Tony Weida
- Craig Winter
Agenda
- (05 min) Roll Call, Approve minutes 4 May 2010, Call for additional agenda items & Accept Agenda
- (55 min) Security and Privacy Ontology Project
- New Use Case Review and Acceptance
- Ongoing Projects
- PASS Audit Update
- US Realm Value Sets
Minutes
1. Action Items
- Team: please review the use cases posted on the Security & Privacy Ontology wiki site. Come prepared to provide your input as to which use cases in scope and out of scope so that we can take a vote on this during an up coming meeting.
2. Resolutions - none
3. Updates/Discussion
Rio Working Group Meeting Announcement
- Ballot reconciliation will commence at the Rio WGM – Tues Q3, starting at 12:45 PM EDT.
- A GoToMeeting Link has been established for those who wish to dial in:
- Please join my meeting.
- Join the conference call:
- Meeting ID: 803-352-145
Security and Privacy Ontology Project
The focus of today's discussion was on the purpose of use cases in the process of defining an ontology for Security & Privacy
Steve reviewed two additional use cases posted to the S&P Ontology project wiki. These use cases are based on ISO 10181-3 - Security frameworks for open systems: Access control framework
- Use Case #1: Enable Design of Access Control System
- Use Case #2: Facilitate an Automated Decision Function
- ISO 10181 refers to a process that states a Security Policy is written in natural language and it uses broad terminology to express. It goes through a process in which a Security Domain Administrator (SDA) takes the policy and interprets that policy into rules that are then entered into an access control system.
- Use case #1 is a manual process – an SDA takes the security policy and converts it into rules that can be entered into the access control decision function.
- The use case is designed to illustrate how an ontology would be used by that security administrator to assist in that activity.
- There is an assumption that the SDA is not a clinical documents subject matter expert so the purpose is to provide a categorization scheme that is aligned with the security policy so the administrator can
- easily find the object(s) they are interested in so they can
- (manually) apply the appropriate security rules to that to be entered into the access control system.
- The purpose of this use case is to enable the manual process of finding the objects. It is not meant to imply that the categorization scheme is entered into the Access Control Decision function.
- The Basic Scenario – the objects are divided into two categories: clinical documents and administrative objects. The security policy is very simple. It distinguishes between clinical and administrative objects.
- The alternative scenario: the only an alphabetical categorization is used. That provides a base level, minimum requirement. We assume that the list of objects (say, 1000 objects), browsing through that list is difficult by categorizing them alphabetically; yet it fulfills the requirements by decreasing the size of the list (alphabetically), and aids the administrator to find the object, but it does not provide any information that are the security requirements for the object. This is applied by the security administrator.
- Politically speaking, the alternative scenario is probably the least disruptive because everyone can agree on an alphabetical scheme, but it does not provide information regarding the security value of those objects.
- So the value of use case #1 is to decrease the size of the list of objects to aide the SDA to discover the objects.
- In ISO 10181, the process which is taken to get to an automated use case, you have to go through the manual use case. The next use case, #Facilitate an Automated Decision Function, is the automated use case, but a pre-condition is to go through the manual use case.
- Last week, Tony described two different kinds of use cases: build-time versus run-time. Enable Design of Access Control System is an example of a build-time use case; the second, Facilitate an Automated Decision Function is an example of a run-time use case (operational mode).
- This use case does not use the terminology used in ISO 10181, but for all intents and purposes, it is the access control decision function (ADF) which is referred to in ISO 10181.
- After the targets and information requestors have been categorized and the rules applied to the ADF, this use case describes how the ADF responds when an information request is received by the system.
- Basic Scenario: A MD makes a request to see a patient’s clinical data, and the ADF evaluates that against the rules already populated in the system. Does the request conform to a rule or not. Yes, access is permitted,
- Alternative Scenario, request does not conform to the rules and access is denied.
- Although these use cases are simplistic, the belief is that the use cases point out a couple of disagreements as to what the ontology is expected to provide.
- The two use cases describe functions and how are we going to use the use cases; how are they going to be used by the system? Use Case #1 – minimum requirement – simply used by the SDA to set up the access control system. To continue, use case #2 – the ontology becomes part of the ADF. The rules in the ADF rely on the ontology to make a decision
- Pat: Is the expectation that the ADF goes out to an ontology service or a terminology service to evaluate the rules? I have a hard time understanding real-time reliance on an ontology other than in a very abstract way.
- Mike: Reiterated the work that OASIS is currently undertaking – where they are investigating the use of an ontology to extend XACML. There is a proposal to create an ontology decision point as part of the XAML specification. Turns out various produces in this space already implement ontologies as their internal structure. But these are proprietary, not standard-based. These are used to more efficiently process rules and are offered as a competitive advantage. Providing a health care ontology facilitates the industry’s efforts to do this.
- Pat: But how does this use case help us to build an ontology and to know when we’re done or that we’ve met a particular business requirement? How we use the ontology downstream (the OASIS work for instance) is out of scope for our project. How do we use these use cases to drive the content of the ontology, or if that’s not the intent of these use cases, I misunderstood.
- Steve: This is exactly the intent of these use cases. What is sufficient for the ontology. Is an alphabetical categorization sufficient? Or on the other end of he spectrum, an ontology that would be used in an ADF in which we can establish rules, that would be part of the ADF.
Rob Horn: My understanding is that the ontology would not be part of the ADF. I though the use of the use cases would be to be sure that with the ontology we can say the statement that need to be said.
- In the use case, you need to make statements such as Dr. Bob makes a request to read Sam’s encounter data. Can I say that using the terms and relationships of the ontology.
- Steve: Dr. Bob is making the request to the EHR inside of which is the Access Control System inside of which is the ADF.
- Mike: The OASIS example, the XACML committee produces an architecture and a way of expressing security policy. XACML architecture has mechanical components like a policy information point that stores policy attributes. Different business domains provide the vocabulary that would be attributes that go into a policy information point.
- This ontology will provide a hierarchy of health care specific information that an engine would use – it is the gas for the engine. This use case is pointing out how an ontology would benefit the policy decision point, the components of a 10183-3 ISO solution and providing an instance of that. What we’ve done so far has not specified anything about conformance.
- Start with flat terms, then we put an ontology in place to describe the relationship between the terms.
- Rob Horn: How do you know the ontology work is finished? I thought that when we’re able to express the things that are happening in the use case using the ontology, then we’re finished.
- Pat: I understand that we want to use an ontology to make access control decisions. I just didn’t think that was the work of this project. That’s the OASIS work. How do we make sure our ontology is correct, that those concepts and terms and relationships are correct. I assumed that we would use those use cases to collect the concepts, terms and relationships from those use cases and make sure there is an equivalent in the ontology. Rather than identifying use cases saying this is how we’re going to use the ontology.
- Mike: It sounds like we’re re-inventing the wheel from your description. I think Steve’s use case is raising things up a level. It is providing a framework for the utility. Bu I don’t think we need to go back to raw use case development to define the terms. We have an information model. In terms of an access control system we know all the components.
- Pat disagrees. The initial concept of the ontology was based on the fact that when we started to put the Privacy DAM with the Security DAM that we would end up with impedance mismatch. Disclosure, for instance, that’s a privacy term. What does it mean from a security perspective. We don’t have a mapping for that. I thought that is what the ontology was supposed to do – to correct the impedance mismatch between the domain analysis models as opposed to how will we use the ontology once it’s finished.
- Steve: We specified that we would focus on access control in the near term.
- Mike: I don’t think we specified in the scope statement that the purpose was to do some reconciliation between privacy and security. That may be something that happens, but the scope statement says that we would create an ontology that would be useful for systems making access control decisions. We have a vocabulary through the HL7 Permission Catalog supposed RBAC and we would start with something like that to create an ontology of the permission catalog which has been something specifically brought up before this group.
- Pat: The impression I was under is that is where we were going to start, but not where we were going to end. It sounds like the discussion is that it is access control based on RBAC and the permission catalog and end of story. I could be getting the wrong impression...
- Mike: Can you accept that the use case that Steve is presenting is a use case for access control, an investigation into the vocabularies and the creation of an ontology for that use case. That high-level use case is a way of bounding a problem view. That helps us to determine when we’re done. By working through real-world use cases, we go back to our Information Model and apply it to one of these use cases. We conduct investigations of the use cases, so the use cases are the things that we’re interested in doing and the scope is whatever is in the use cases. Hopefully these will be informative and we use the information model as the defined source of the vocabularies if they exist.
- Pat: That explanation clarifies the situation
- Definition of the use cases should establish when we’re done (relatively speaking). We don’t have a specific goal at this point, for example to cover every concept in the information model.
- Steve: The first five use cases on the wiki were written with the idea that they would be used by an ADF. We create an ontology of actions, an ontology of objects, an ontology of roles. These would be in the access control system and used to make access control decisions. After having written those, I realize that I may have been jumping the gun by assuming these ontologies would be used inside the access control system. There is obviously other places where ontologies could be used as well. So that’s why I went back to write the final use cases to set the operating framework. I realize this is confusing, but I think there is another situation that Mike referred to blast week, where the ontologies are used to write policy. So that’s not a use case that I have incorporated here, but that could be valuable.
- Richard: That seems to me to be the most useful use case. The kinds of choices people want to make.
- Don: I checked the project scope statement, and that is actually #1 to be covered by the ontology.
- Mike: I agree, we need to flesh out in addition to the use cases to enforce the policy, we need to create use cases to express the policy.
- John: In what way is this ontology similar or different than the security DAM and why are we not starting with the same use cases?
- Mike: That’s a good point. It gets back to the fact that we should not be creating use cases from scratch. We should be using use cases that are derived from the RBAC work and the Security DAM work.
- I’m viewing the use cases that Steve is presenting here more from setting the work areas that we’re interested in. We have one that cover the notion of an ontology as the means to perform access control decision function. We need one that provides an ontology that would be useful for describing privacy policy. We want to take out of the IM the things that would be useful for policy purposes and putting those concepts into an ontological framework. The use case for that is describing the need to do that to create a consent directive for example.
- Steve: I assume that the use case for the harmonized DAM are included and that my intention is that these extend those use cases. Last week when I discussed the multiple role value use case, you said that’s already in the harmonized DAM; if it is represented that I agree, that use case is superfluous. There is no intent to duplicate the use cases that are included in the DAM.
- Action Item for the team: please review the use cases posted on the Security & Privacy Ontology wiki site. Come prepared to provide your input as to which use cases in scope and out of scope so that we can take a vote on this during an up coming meeting.
Meeting was adjourned at 2:00 PM EDT
Ontology project discussion continued during the following CBCC WG hour