Difference between revisions of "January 9th, 2012 Security Working Group Conference Call"
m (moved January 9th, 2011 Security Working Group Conference Call to January 9th, 2012 Security Working Group Conference Call: correction to year entry) |
|||
(One intermediate revision by the same user not shown) | |||
Line 76: | Line 76: | ||
* Looking at privacy policy. It’s one thing to take these classes and attributes and render them in OWL format. In terms of documenting what they are intend to mean. The policy (privacy)… at a high level this is a different way of describing the same thing. It may be just the privacy DAM was done separately and integrated into the composite dam or it was felt that the privacy rules would be more intuitive to write privacy policy or some fundamental distinction that I don’t’ know of. | * Looking at privacy policy. It’s one thing to take these classes and attributes and render them in OWL format. In terms of documenting what they are intend to mean. The policy (privacy)… at a high level this is a different way of describing the same thing. It may be just the privacy DAM was done separately and integrated into the composite dam or it was felt that the privacy rules would be more intuitive to write privacy policy or some fundamental distinction that I don’t’ know of. | ||
− | * The | + | * The security points of view: A policy is a policy. The privacy rule is a policy that comes from the patient or the jurisdiction or organization that reference to the element of privacy which is control of who gets to see certain types of information. Its security normally implemented as a constraint—but it doesn’t have to be. It can be a policy in its own right—authorization of discourse can be only given by the patient. There is a certain element that providing a convenient handshake between security and privacy people can have for a harmonized approach. Privacy needs need to be met and not swept away in the policy statement. They are very concerned that the patients’ view and expression was going to be different than how it’s going to appear in a security IT system. |
The instance of a privacy according to the DAM could be mechanically ranlatered into security policy expressed according the this model, except of course the operations, collect access, use disclose … that relates to conversation I had with Kathleen about trying o take the data operation and relate them again to the privacy operations. | The instance of a privacy according to the DAM could be mechanically ranlatered into security policy expressed according the this model, except of course the operations, collect access, use disclose … that relates to conversation I had with Kathleen about trying o take the data operation and relate them again to the privacy operations. | ||
Line 102: | Line 102: | ||
We should prioritize the different branches in priority manner. | We should prioritize the different branches in priority manner. | ||
− | By next week | + | By next week Tony will provide a work plan to discuss that we can review at the WGM. |
+ | |||
+ | ACTION ITEM: Add Work Plan, how do we get to May Ballot to Tuesday Q3/Q4 add to the agenda | ||
Motion to adjourn: Kathleen | Motion to adjourn: Kathleen | ||
+ | |||
Adjourn: 1101 PST | Adjourn: 1101 PST | ||
Latest revision as of 23:17, 13 February 2012
Contents
Security Working Group Meeting
Attendees
- Kathleen Connor
- Ed Coyne
- Mike Davis Security Co-chair
- Jon Farmer
- Suzanne Gonzales-Webb CBCC Co-chair
- Jim Kretz
- Glen Marshall
- John Moehrke Security Co-chair
- Milan Petkovic
- Ken Salyards
- Richard Thoreson CBCC Co-chair
- Tony Weida
Agenda
- (05 min) Roll Call, Approve Minutes & Accept Agenda
- (15 min) Security and Privacy Ontology / Security and Privacy Ontology Wiki Page Tony Weida
- (15 min) Risk Assessment Class - John Moehrke
- (15 min) Item3
- (5 min) Other Business
Meeting Minutes
'Roll Call, Approve Minutes & Accept Agenda
Note: Risk Assessment Class has been cancelled for the January WGM per John Moehrke
- Should we advertise more? Approach different WG?
- There was an expansion of the last class to bring in more attendees
- have WG appoint a Risk coordinator
- John will be attending other classes to get feedback
- There is belief that WG members are finding their needs met in other places
- Internal / cookbook work is continuing to be pulled into SAEF and such.
Note: We are not losing momentum internally in HL7 development methodology. We have just not found people who are willing to pay $400 to spend 4 hours on a Risk tutorial.
Security and Privacy Ontology / Security and Privacy Ontology Wiki Page Tony Weida
• The initial focus of the ontology was RBAC. (Barrington feedback ?) Would like to see a more general approach based on the security and privacy point, which will take some of the RBAC items and factor them out. So that you can still have them if you want them. In the process of the modeling exercise and taking the uml classes in the DAM.
• Questions that have come up. The DAM is an analysis model and the ontology is an integrated fact. There are several cases where there appears to be multiple ways to do similar things in the ISO 22600 specification
• Authorization Policies: Define permitted actions, content (except in roles), target, action
• Obligation polices are event-triggers and define actions to be performed by manager agents (subject (except in roles), action, event
'everything is explicitly permitted unless otherwise noted per Kathleen. In the realm of what is permitted you may have additional constraints which can expressed in a negative way (you cannot do ‘x’) or as a mandate—you are obliged to do ‘y.’
Authorization policy in ISO 22600 as well as in the DAM has enabled actor type Boolean which inverts its logical sense. This attribute this enables or declines a policy. How does AuthorizationPolicy with enable=false differ from RefrainPolicy? If set to false then there would not be a refrain policy
Bill – What I think we’re talking about is business process constraints rather than RBAC constraints which are different.
If you set Boolean to 1 or 0 … it’s a mapping to the resource—it’s not a decision to the result of whether it was true or false. The problem is the duplicative—-providing the same functionality. It’s a question of a definition---what we mean in the classes. We don’t have that kind of conflict.
There are multiple ways to do the same things. Do we want that or not… first things first.
In the security perspective, you have several kinds of policy which can be combined together. The composite policy. Its not specifically tying one policy with another. i.e. authorization policy says you can do x… there is no connection.
Mike - We have these policies and you write them. And then they are combined to create a basic policy. The enable Boolean, does not mean the same thing as refrain. Enable Boolean has a different meaning here… that’s thought the purpose of the Boolean here (agreed by JM)
We will be meeting with Bernd next week at the WGM—he can provide more words.
Mike - General authorization is not the Boolean. Tony is trying to interpret this beyond what it’s supposed to be Kathleen – agreed, this is something that needs to be interpreted better in the DAM
'BRING THIS ITEM UP AT THE WGM add to the agenda (PURPOSE of the BOOLEAN) to ask Bernd to clarify'
- Looking at privacy policy. It’s one thing to take these classes and attributes and render them in OWL format. In terms of documenting what they are intend to mean. The policy (privacy)… at a high level this is a different way of describing the same thing. It may be just the privacy DAM was done separately and integrated into the composite dam or it was felt that the privacy rules would be more intuitive to write privacy policy or some fundamental distinction that I don’t’ know of.
- The security points of view: A policy is a policy. The privacy rule is a policy that comes from the patient or the jurisdiction or organization that reference to the element of privacy which is control of who gets to see certain types of information. Its security normally implemented as a constraint—but it doesn’t have to be. It can be a policy in its own right—authorization of discourse can be only given by the patient. There is a certain element that providing a convenient handshake between security and privacy people can have for a harmonized approach. Privacy needs need to be met and not swept away in the policy statement. They are very concerned that the patients’ view and expression was going to be different than how it’s going to appear in a security IT system.
The instance of a privacy according to the DAM could be mechanically ranlatered into security policy expressed according the this model, except of course the operations, collect access, use disclose … that relates to conversation I had with Kathleen about trying o take the data operation and relate them again to the privacy operations.
Back to protégé… the data operations were categorized a subcategory (data operation)
- Another issue. There was a lot of work done to create RBAC based operations from the security definitions and made into a standard (data operations code system it’s useful for saying the RBAC catalog is based on standard vocabulary. If we want to use the vocabulary; we will have to have a message that conveys a consent directive, they are at the point we need to hook back to the reference model. The codes now cannot be used.
- We can go into the intermediary value sets. We would have to look at the data operations into suitable values sets which would go to information models. they went into a separate code system which appeared to be usable on a standalone basis. It would be reasonable to put in the ActCode.
• Why would we hard code such a thing into the ontology. • The ontology in general should not be US specific in general
• We want to work at this in a more methodical fashion… getting comments, concurrence on a regular basis.
• Mike Remind me: do all the classes that you are displaying right now, do they have definitions behind them • Tony Many do, but not all—we are getting there. There are several logical definitions (which are more important) not all have text definitions. The English definitions we want to be as consistent as possible • It seems the logical definitions has less to argue about than the text one. If we can get concurrence between the group. • One mechanism for that is the hosted browser. There is also the process of converting all of this to a word documents (fairly time consuming) I hope to do the initial passes views of the browser. In the case of enterprise architect. It’s very nice to do the modeling in the model and then mechanically create a word document from the model. Protégé unfortunately does not have the capability to do that and OWL capability is very limited. • Kathleen – weren’t we going to try and import it as is was created so that we can look at the ontology the vocabulary and ontology relationship are in sync. • Tony – I spend a number of times from OWL to protégé to enterprise architect are brand new and limited and it doesn’t seem The group needs to come some consensus to achieving the may ballot –how can we on the calls get participants to support ; rules we should take, we are not updating the core information model because of anything we see in int---that’s out of scope. We should make the best lemonade out of what we have. If we as a group take the logical definitions I the thing that the ontology needs to have in order to ballot, then the group should be reviewing these things…if there are too many we can take a handful that are related and work through them to see if there are any questions or obvious omissions. HOW DO WE GET TO A MAY BALLOT – that’s the questions.
We should prioritize the different branches in priority manner.
By next week Tony will provide a work plan to discuss that we can review at the WGM.
ACTION ITEM: Add Work Plan, how do we get to May Ballot to Tuesday Q3/Q4 add to the agenda
Motion to adjourn: Kathleen
Adjourn: 1101 PST