Difference between revisions of "May 5th, 2009 Security Conference Call"
(→Agenda) |
|||
| Line 36: | Line 36: | ||
We will ask INCITS about their interpretation of an object is to resolve this issue. ('''Mike to do''') If necessary, we can update/change the standard to clarify it. | We will ask INCITS about their interpretation of an object is to resolve this issue. ('''Mike to do''') If necessary, we can update/change the standard to clarify it. | ||
| + | |||
| + | Some of the objects currently listed are not data containers but are processes. | ||
| + | We have committed ourselves to maintain the mapping for the current RBAC object list once we’ve involved ourselves with a standardized | ||
| + | There is overlap with SNOMED CT and with LOINC and we can take advantage of these overlaps. | ||
| + | |||
| + | Some of the other requirements suggested for the project include: (Steve) | ||
| + | * comply with ANSI-INCITS | ||
| + | * improve the interoperability – that would require some kind of harmonization on permissions, operations, and objects. In the RBAC standard we made our ‘’verb’’ tables—the object tables—normative, but did not make the permissions normative. | ||
| + | If you create permissions using standard objects and operations….then by default it’s normative. | ||
| + | |||
| + | Rather than specify you can create your own operation-object tables. The notion behind ANSI-359 is action-object pairs. They’re saying the roles are composed of action-object pairs, and before ANSI-INSIT roles were just names (structural names) with no real structure was the notion of action-object pairs that you can build on…some of which overlap within the roles (MD, Nurse)… if you identify an MD at VA, vs. an MD at Kaiser…the definition may be slightly different. You have to have something finer grained, you can enumerate them, their MD w/these numerations can be identified with another MD with other numerations. | ||
Revision as of 16:25, 12 May 2009
Contents
Security Working Group Meeting
==Attendees== (expected)
- Steven Connolly
- Mike Davis Security Co-chair
- Suzanne Gonzales-Webb CBCC Co-chair
- Milan Petkovik
- David Sperzel
- Richard Thoreson CBCC Co-chair
- Tony Weida
- Craig Winter
May 5 2009
Security Working Group Meeting
Agenda
- ’’ (05 min) Roll Call
- ’’ (05 min) Approve Minutes & Accept Agenda
- ’’ (15 min) RBAC Object Vocabulary (as of 5/5/2009)
ANSI-INSI 359 – any system resource…(workflow?—is that a system resource? per Mike yes. This is consistent w/earlier model of access control;”… …it contains or receives information.” (Steve) it produces artifacts.
The object definition is flexible, it receives data from users. The way the analysis was completed, we started with work flows, we then broke it down to tasks then steps to component pieces. The problem with work flow is that it could have multiple pieces. We start with scenario to work flow to task, a task can only be done by one user. It’s important that we have permissions. RBAC provides user authorization to use functions as well as to use objects.
- some of the issues may be resolved by splitting out the objects into artifacts.
Our intent is to control the operation of the system. (Execute is a verb, as is print and items like that.)
To participate in a workflow...that’s a verb. Within the workflow you have detailed functional 'things to do', it does not mean you can do all the details functional access involved.
An example of objects within a workflow might be: A bank service needs to send a check to a customer. Policy states that the bank personnel who authorizes and writes the check cannot be the same person who signs the check. There are two scenarios in the workflow, one scenario is authorizing/writing the check the other scenario is the signing of the check.
We will ask INCITS about their interpretation of an object is to resolve this issue. (Mike to do) If necessary, we can update/change the standard to clarify it.
Some of the objects currently listed are not data containers but are processes. We have committed ourselves to maintain the mapping for the current RBAC object list once we’ve involved ourselves with a standardized There is overlap with SNOMED CT and with LOINC and we can take advantage of these overlaps.
Some of the other requirements suggested for the project include: (Steve)
- comply with ANSI-INCITS
- improve the interoperability – that would require some kind of harmonization on permissions, operations, and objects. In the RBAC standard we made our ‘’verb’’ tables—the object tables—normative, but did not make the permissions normative.
If you create permissions using standard objects and operations….then by default it’s normative.
Rather than specify you can create your own operation-object tables. The notion behind ANSI-359 is action-object pairs. They’re saying the roles are composed of action-object pairs, and before ANSI-INSIT roles were just names (structural names) with no real structure was the notion of action-object pairs that you can build on…some of which overlap within the roles (MD, Nurse)… if you identify an MD at VA, vs. an MD at Kaiser…the definition may be slightly different. You have to have something finer grained, you can enumerate them, their MD w/these numerations can be identified with another MD with other numerations.
- (5 min) Other Business
