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

December 07, 2010 Security Conference Call

From HL7Wiki
Revision as of 17:39, 14 December 2010 by Suzannegw (talk | contribs) (→‎Agenda)
(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

Back to Security Main Page

Agenda

  1. (05 min) Roll Call & Accept Agenda (meeting minutes are not ready for 11/30 meeting)
  2. (15 min) NCVHS Letter and segmentation discussion (continuation) - Link for full document: Access Control System Modes and Segmentation Mike Davis

Access Control System Modes The follow modes of access control system operation are defined based upon possession or lack of possession of access control attributes.

a) Those who have permission to access the resource (e.g., ANY permission that grants access)

b) Those who are denied access to the resource (e.g., possess NO permission for the resource)

c) Those who are normally denied access but may choose to break-the-glass (BTG) and gain access if they deem it appropriate (e.g. they break the barrier by "choice" rather than by asserting any further/special permissions).

d) Those who are normally denied access but may gain access by elevating privilege

e) Bypass. Insecure system state in which access control decision/enforcement is intentionally disabled or circumvented by authorized users. (such as a ‘maintenance’ mode)

Note 1: 1. Regarding "Bypass/override". This vocabulary is overloaded with Canada using it (as I recall) equivalent to BTG. A distinctly different meaning of bypass is a maintenance/programming mode (in which the system is purposely placed in a non-secure state circumventing security controls). :


Break-the-Glass (BTG) USE CASE

Example BTG Use Case illustrating Case both case a) and c) above:

Definitions:

  • Security Domain. A set of users, a set of protected objects and the security policy that binds the two.
  • Access Control Decision Information (ACI). ISO 10181-3 Access Control defines classes of access control ACI. Classes of access control decision information (ACI) include: Initiator, Target, Access request, Operand, Contextual, Initiator-bound, Target-bound, Access-request bound.
  • Permission. Per ANSI-INCITS 359-2004 a Permission is an approval to perform an operation on one or more RBAC protected objects.
  • Segment. (is there a good definition or a ’standard definition’ for this or not? Question from Mike; Mike suggests/has provided one)

A totally included subset of the information objects in a security domain possessing common/identical attributes of the domain security policy(e.g. all records with Target ACI=”VIP”, all records with Contextual ACI=”Psychiatric Ward”, all records with Target bound ACI=”Care Team AND patient record =”Smith”).

Comment: (Bill?) This is not apparently from a regular user. I would’ve have thought it would have had to do with the data fields contained within a given unit of a record as opposed to a ‘set’ of records

Pat – that’s why Rob opposed the segment definition in the letter – Rob – I’d like to hear the rest of Mike’s examples that may be relatively aligned with my issues; it is looking at is cross-pations but not sure if it is cross patients

Mike – this is illustrative of a set of domains

Action: User (initiator) operates in Domain A and has proper permissions/roles to perform assigned tasks. In the course of activities, this user desires to search for a record within a defined VIP segment of Domain A under a purpose of use = “XXX” and Domain A policy=”YYY”:



Domain A POLICY: Grant Initiator access to Domain A objects with Target sensitivity attribute=”X” IFF Initiator role=”Y” and (Initiator sensitivity attribute = “X” OR BTG Warning=”Yes”).

Mike: Gong back to the definition above: A totally included subset of the information objects in a security domain possessing common/identical attributes of the domain security policy (e.g. all records with Target ACI=”VIP”, all records with Contextual ACI=”Psychiatric Ward”, all records with Target bound ACI=”Care Team AND patient record =”Smith”).

Note 1: Access to most domain data is obtained with role Y=”Clinician” and target sensitivity attribute = “Null”, however VIP records are marked with Sensitivity attribute = “VIP” and therefore the user must either already hold this attribute or assert the BTG Warning attribute at runtime.

1. The user authenticates and accesses the system using the “Clinician” role suitable for the purpose of use of “Treatment”.

2. S/He searches for a record

3. The record has Target attribute=VIP.

4. If the user possess the Initiator sensitivity attribute “VIP” (or better) then access is granted (this is NOT BTG),

5. If the user does not possess the “VIP” attribute, then the access control system throws an exception which causes the application to present the user with the BTG warning banner (e.g., Acknowledge understanding that your activities will be audited, supervisor will be notified, etc do you accept YES/NO?).

6. The user accepts the warning=”Yes”.

7. The request is resubmitted this time with the attribute BTG warning=”Yes” (this is BTG).

8. The access control system grants access (re-evaluates the policy including the run-time BTG warning acknowledgement which is now present).

Note 2: Possession of the sensitivity attribute (STEP 4) is functionally equivalent to the proposed BTG Permission (can access VIP Segment objects where permission operation=”access” and protected object=”VIP Segment Objects”) and presumes a pre-existing authorization attribute. Asserting an authorization attribute already held is NOT BTG. Note 3: Lack of any authorization attribute specific to the segmented data and the user “Choice” to accept the BTG Warning is the key element of BTG that distinguishes it from other access modes.

Rob – I think this is more aligned than not, I have questions but more on the words you are using. When I look at what your domain and your segments, it speaks of ‘segments’ are a piece of the record; the word segment is always a ‘section’ in a larger thing; but during our discussion here—I think of data object. What you’re thinking of a segment---which I think is in your definition; all of the data which you’re calling is an attribute; you’re looking at a domain as ‘’some collection, ‘’ whether it is a single patient record. Segment in the context of this discussion where it lines up with—where a segment would be equal all data elements; what it defines what that segment means is that the data element has some attribute that in some way is identified with the kind of information that you would have to have access to that you would need to make a privacy/consent decision on; i.e. a lab test—which I view as protected –as it could reveal HIV infection. That means that this data object belongs to the data segment that has been assigned an “attribute” that indicates they are an HIV kind of thing; what you’ve describe in general terms—it works, if you think about things like domain being a record, or health care data accession, where you are looking at multiple patients; in that case domain spreads to a larger set of records, then ‘’your-word-segment ‘would align with all the data objects /data elements inside that set of records which the attributes have been set and that you have said in your definition of segment. This actually fits as long as we carefully align the traditional vocabulary words when used in records, etc.

Mike – in the way segment is defined is very general – I don’t say what the information object is; that’s up for you to define. The set of information objects could be single record with attributes on a single thing. It could be all records in an organization--says Kaiser; or all records being exchanged in HIE among those set of users. It’s very general in that concept; you pick your domain and you want to enforce privacy, you HAVE to identify what the policy is, and who the users are. In segment has to do not with a physical thing but more of a logical attribute.

Rob – there is inconsistency; In the NCVHS letter they were using segmentation as a verb; the NVCSH letter talked about the kinds of things that needed to be segmented; if the process describes functions there must be a way to do what you’ve described in your segment discussion. Where there is a way of identify associated with a thing, then becomes a part of a segment; somehow we identify these data has attributes that gets to the verb of ‘’segmenting’ or being about to associate things in the records (data objects) with these attributes—that act. we don’t speak to HOW it happens, the security systems can operate on it.

Jon – have a proposed ‘ a subset of contents that is defined by criteria”

Mike – is that different from what I’ve described

Jon – calls out specifically by definition, as a subset of content (not a subset of records)

Mike – I use ‘information object;

Rob - I think you are saying the same thing; I’m partial to information object—it has boundaries that you can grab---or redact.

Jon – the key thing about a segment is that it is defined by criteria

Mike- which I call an attribute. From the security point of view; in 101-83 it defines classes of criteria or attributes for which an access control decision can be made; its more than just the attributes that can be applied to a segment go beyond the criteria does not have to be a data label on a field… It can be a ward or care team or time based or a collection of things…it’s a very flexible way to view segmentation that meets many healthcare, security and privacy types of policies; and it’s a logical segmentation not a physical one.

Rob – and that’s the key piece… we’re talking about subsets more than we’re talking about segments

Bill – we should take some words from the definition and change the name to something more specific to our situation: Security and privacy policies are used to take criteria against a data object and use those to take value to attributes which are associated to that data object ; those in turn define security subsets in the domain name i.e. ‘Domain A’ information object… can we change the word segment to security sub-set.

Richard – the term of ‘art’ here in US is ‘’segment’’ it comes from the highest level of ONC.

Rob – I agree with Bill; subset that will raise other things with other folks

Bill – that why I say ‘security sub-set’

JohnM – it doesn’t necessarily pull all concepts together; this may start an I want my privacy segment, or some other segment; if we can adopt this new term of art; it’s a very expansive form that Mike has laid out, we can do what we have to do rather than wrapped around the word to be used.

Jim K – let’s suppose this duck has been in the psychiatric ward but breaks a leg… does that mean the broken leg business can’t be dealt with?

JohnM – these are examples…these are not normative lists

Rob – given the right way of constructing this. They would set up the policy where the policy is if the record of a patient is a resident on the pysch ward; but if they set up the policy differently—the things that need to be protected or redacted are information objects that are segments are appropriately attributed as speaking to the psychiatric care, then the problem will be included

Scott – those way psychiatric notes would be excluded, but general medicine would be okay.

Rob – Right, I feel 1. Mike hit the nail on the head; 2. The thing Jim just raised; the letter spoke to the act of identifying information objects correctly to associate those things in the letter that they identify as important.

This part of the puzzle that once you’ve done that we can have s a security system; I have a system that will tell you see the broken leg part but not the psychiatric notes; but you have to put in a process where the information objects have the correct attributes; which goes back to what tony is working on; you’re not going to get physicians to tag things—not because they don’t want to or it s hard but they but most have already been automatic (like in a psych ward because its location)

Jon – the attributes may then be already derived rather than assigned or ‘stamped’

Rob – right… those would be sensitive (generic) information types/sensitive diagnosis; people can describe policy that if the note references a condition that is a sensitive condition, then I want that information redacted, then Mikes policy process will get into the details—the fact that the data information object can also be redacted or not. A diagnosis that is put in a note, the simplest approach would be would be to remove the five words but the rest of the note remains. This is why the word segment is scary; if it lives inside a note then the whole note may have to be redacted or are we just removing the five words—will the information still mean the same thing? How much do you redact? How do you do it correctly?

Jon – that may be a quality of implementation issue.

Rob – when we begin to understand that we’re not tagging segments of a note but identifying attributes/data elements that can appear anywhere in the record—how do we correctly manage that record or the elements in side that set of records based on the fat they now have free floating things. John m – we need to separate out the theory from the practical as well; we’re going in circles—you’re bringing up practical realities which I love; what Mike is bringing before you is the academic, puristic thought; that the access control engine is bringing out anything you can possibly define; the practical reality is--if you allow policy to be written against any possible value including free text searches, it will become untenable. We will have to decide how this stuff will work. I think you are expecting the system that is publishing a document to do an assessment of the data sensitivity and set some meta data that assists with the understanding of the access control engine as to the data classification. That is a practical function based on a practical issue, based on a basic issue not a theoretical function; ultimately whatever policy they feel they have to implement; someone will have to figure out how to implement them. Ultimately you start to create these things that say-- great there is a data classification—high—low--ultra low and have the publisher make the decision. The academic discussion is---do we understand what segmentation is; that the access control engine can have rules that are based on data or the meta data or about the meta data or parts of the meta data; we can go in circles about the same topic.

Rob – I don’t’ know that we’ve circled yet today.

Jon – is it fair to say that that we need to define the purist and theoretical in front of us right now

Mike – that an important part. Getting all the cats lined up and that are on the same page. We are conceptually in a different space; the model here provides a unifying framework that I claim that meets the needs of security system and provides a logical consistent mechanism for describing attributes that allow the security and privacy policy I wrote that allows break-the glass, recognizing that in healthcare we don’t kill patients.

Rob – the example Jim gave doesn’t’ require break the glass. I don’t see this as hard—it’s what Tony is improving; if we say there are kinds of information objects that have privacy concerns that are not open and available in a system that Mike is showing.

Discussion on Ontology classes, definitions and policy types Information Referenced

Action Items

Back to Security Main Page

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