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

November 10th 2009 Security Conference Call

From HL7Wiki
Jump to navigation Jump to search

Security Work Group Weekly Conference Call

Meeting Information

Attendees

Agenda

  1. (05 min) Roll Call, Approve Minutes & Call for Agenda Items
  2. (45 min) Security DAM artifacts peer review
  3. (10 min) Ioana: Security and Privacy Domain harmonization questions

Action Items

 Please submit further questions and comments on the Security DAM to the Security CBCC ListServs in between meetings

Ioana will elaborate on the following, which will be included in the domain analysis model document:

  • Instances of composite policy
  • Policy vs. BasicPolicy
  • Role as subclass of Policy

Minutes

 The action items above reflect the outcome of the following discussion.  We will continue to review the Security Artifacts in upcoming meetings.

Security and Privacy Domain harmonization questions & Security DAM artifacts peer review

What Ioana tried to do in this process was to align the concepts in the Privacy Domain Analysis with those we’ve identified in the Security DAM. There are some similarities, however, for the most part, the Security Domain Analysis Model is very different. Here are some outstanding questions.

  • Question 1: What is the relationship between ConstraintPolicy and ConsentDirective?
  • In areas where there is overlap, the models appear to be identical – for example, the way in which information/content is referenced by the policies. Where it’s not clear is whether CompositePolicy in the Security domain maps to ConsentDirective.
    • The follow up question, when we look at the Security DAM, is What is ConsentDirective? A ConstraintPolicy, a BasicPolicy, a CompositionPolicy?
      • ConstraintPolicy if it constrains the organization
      • ObligationPolicy – redisclosure
  • Question 2: Is Level of Assurance a User attribute or an AuthorizationPolicy attribute?
  • Question 3: Is Role.confidentiality relevant for a Security policy?
  • Role in the Security DAM has a sensitivityCode, which indicates the sensitivity of the data the Role can access.
    • In the HL7 RIM Role has a confidentialityCode, which indicates if there is something specific about the Role definition that would preclude it from being shared or accessed.
    • Does confidentiality have an aspect where a specific structural or functional role corresponds to a specific role the organization is trying to apply Access Control over?
  • Question 4: Are there Privacy policies where data integrity is relevant to Privacy Policy?
    • Validating the Security Data Integrity attribute (InformationReference.integrityInd). There is no corresponding attribute in Privacy.


Summary of the Discussion:

Question 1: What is the relationship between ConstraintPolicy and ConsentDirective?

  • Mike: A ConstraintPolicy is one instantiation of a Consent Directive, so a Consent Directive can be either one. It can be a policy in it’s own right or it can be a constraint on existing policy. It has both aspects.
  • Ioana: Depending on the situation, the ConstraintPolicy could be any one of these policies or only a ConstraintPolicy. We have many specializations of policy.
  • Mike: The use case I have as an example of a Consent Directive as a policy is where a patient in HIPAA gives authorization for disclosure. The organizational policy in that regard is to not make a disclosure unless there is an existing patient policy. The patient policy wouldn’t be a constraint on that, it actually makes the policy. So that’s an instance of a policy. In more general terms, the patient constrains existing policy. Patient says “I don’t want Dr. Bob to see my records”. That’s a constraint.
  • Ioana: Would it be fair to say it’s a ConstraintPolicy if it constrains the organization policy and it may be any other kind of policy if it extends it? This is a case where negotiation occurs and the organization would declare whether they are willing to enforce that policy.
  • Mike: In the case where I mentioned with respect to HIPAA disclosure, and I would expect that Richard has a use case relative to CFR 42 Part 2, those are by law, given to patients, so the patient asserts the policy. It would be negotiated in the sense that it is a valid policy that will be enforced. I think it simply represents an instance of policy. I don’t think there are many of these (HIPAA, CFR 42 Part 2) in US laws.
  • Ioana: You just said something that made me think about an ObligationPolicy that is associated with a consent for disclosure. The ObligationPolicy says that the receiver of the information has to destroy the information after a certain period of time. That’s what WITS does today when a client is transferred from one provider to the next.
  • Richard: CRF Part 2: says, you can take my data but you cannot re-disclose to anyone else.
  • Ioana: Document retention is an organizational policy. Sometimes there is an issue with this kind of obligation. If policy is too restrictive it may contradict other policies.
  • Mike: The constraints modify existing policy. In general, I think about it as a constraint on a Role, or a doctor, potentially on the data itself. But I think we’ve got it right here. Patient policies can map directly to constraints. That would be the Constraint Catalog. The other thing is that they map directly as a type of policy and they look like a policy – they give the organization authority to do something like disclose information. Or a policy that says, re-disclose this information that might appear as a constraint on one of these other classes. But I think it does map right into any one of these classes. I don’t think anything is missing. We haven’t identified a gap, but I think it’s useful to clarify there are constraints and there are policies and the patient Consent Directive potentially has both, probably more commonly it’s a constraint. Maybe for Richard everything looks like a policy.
  • Steve: One question: You have ConstraintPolicy as a specialized policy. Would it be more appropriate to have the BasicPolicy have ConstraintPolicy as part of its class?
  • Mike: That’s just the representation, how you represent it. Remember the ConstraintPolicy can be a patient’s Consent Directive, but in general, in Security, the ConstraintPolicy can be a security constraint as well. It’s not just restricted to the privacy realm.
  • Steve: Can it be a stand-alone policy? The set of constraints? (see Security and CBCC Listserv for off-line discussion/clarification thread on this question)
  • Mike: I don’t think so. I think by definition it constrains policy
  • Ioana: I’d like to recap the UML notation. The empty triangle indicates a Super class – a more generic class. The ConstraintPolicy is a type of BasicPolicy and it constrains a CompositionPolicy. A CompositionPolicy is also a kind of policy that contains other basic policies. We had a ConstraintPolicy as a constraint on a CompositionPolicy, and that CompositionPolicy contains one or more basic policies. And the BasicPolicy could be specialized: DelegationPolicy, AuthorizationPolicy, ObligationPolicy or RefrainPolicy. My constrained policy could constrain an organizational policy that is a type of CompositionPolicy that contains a set of obligations or refrains. So in the case of CFR 42 Part 2, the default policy says do not disclose substance abuse records without meeting this criteria. The ConstraintPolicy says do disclose to this particular type of organization for this particular type of purpose, etc. So a ConstraintPolicy is not a part of a BasicPolicy, but it is a kind of BasicPolicy itself.
  • Steve: And the way the Constraint Catalog was developed, it was not a policy within itself, it was a set of constraints to be applied to a policy,
  • Ioana: If I instantiate this ConstraintPolicy, I am going to have the same elements that I would have in a BasicPolicy…so a ConstraintPolicy could have the exact same elements as a BasicPolicy, but constrained of course.
  • Rob: Steve’s issue seems to be different. To me, it looks like you would create a ConstraintPolicy and there is no BasicPolicy. You create a ConstraintPolicy and it has all the necessary stuff in it. I don’t see how you reference, as a constraint, there’s no element that references another policy. I guess it references a CompositionPolicy but it doesn’t reference another policy. So if you’re constraining something, you have to create the ConstraintPolicy, and have the regular policy and the constraint all in one policy. It doesn’t make sense. It seems a little redundant.
  • Ioana: What this is saying is that ConstraintPolicy is constraining a specific CompositionPolicy.
  • Rob: I think that makes sense, but that means there’s a ConstraintPolicy that has all the other information in it, so why does it reference a CompositionPolicy? It seems the constraints should only be the constraints and not all the policy stuff.
  • Ioana: The ConstraintPolicy is still a policy.
  • Rob: I understand that, but it raises the issue, do you as a rule, say constraint policies don’t have all the policy stuff in them?
  • Ioana: They could, it depends on what you’re constraining. If you’re making specific statements about operations and roles and information references, those would appear in the ConstraintPolicy.
  • Mike: There are several other things to discuss in this call, if you have some specific things to discuss, could you please send it to the listserv for offline discussion.
  • Ioana: Some of this is basically class hierarchy, specializations of the others. This particular model is based on ISO standards and makes use of inheritance more than we’re used to. If something is hanging off the most generic class, all the specializations will have that association. Everything else inherits from Policy.
    • I will take as an action item, to instantiate a ConstraintPolicy and a BasicPolicy as examples for clarity. Definitions for all these terms will be included as well. (BasicPolicy, ConstraintPolicy, etc.)
  • Mike: The model is frozen, so if folks have comments, they can comment on the ballot.

Question 2: Is Level of Assurance a User attribute or an AuthorizationPolicy attribute?

  • Ioana: Level of assurance refers to the degree of certainty that the credential was verified prior to registration; the assurance that the user owns the credential. I put it as an attribute of User. But is this a user Level of Assurance, or is this a person identity Level of Assurance? I thought it went with the credential, so that’s why I put it with the User.
  • Mike: I think it appears that way in a credential, but I think the Level of Assurance is established by organizational policy so that a user gets the credential for a particular purpose from the Security services at a Level of Assurance that’s required. So a user may have credentials at different levels of assurance depending upon the resource or the target that’s being accessed and the policy regarding that. Some targets may require PKI, biometrics, some passwords, some nothing. So the Level of Assurance belongs to the Organizational policy and the user inherits that in a specific instance.
  • Don: Which organization? It goes with the credential.
  • Mike: It’s assigned by the organizational policy or jurisdictional policy. It’s either organizational or jurisdictional in nature, but it doesn’t belong to the users. So when the organization issues the credential, the credential that’s issued, describes an attribute of Level of Assurance and that’s associated with that particular credential only, which is associated with a request for a particular resource according to a particular policy. So it’s linked back to the policy and the user inherits that level of insurance from the credential and the policy.
  • Richard: I’m confused about the organization you’re talking about. One is the owner of the resource and the other is the Identity manager.
  • Mike: It’s the organization that issues the credential. Not the owner of the resource.
  • Pat Pyette: We’re talking about two different policies. One is the one who assigns the credential to the requester. The other is what Level of Assurance do I need to allow a request to…
  • Mike: But it’s attached to the policy in both cases. So whether I say, by this policy I’m issuing this, but the receiver may deny that assertion based on their policy, and may say this is not good enough, you need to give me a higher Level of Assurance claim.
  • Pat Pyette: Does that mean that you think we should move Level of Assurance up to a BasicPolicy or the policy itself?
  • Mike: The level of Assurance doesn’t have to do with the Level of Assurance of the policy, it has to do with the Level of Assurance of an identity attribute. So you’re wondering why we have an identity attribute in an AuthorizationPolicy and the reason for that is there are instances where the authentication itself is sufficient to make an authorization decision, you don’t need anything else. So we put it in for that specialized purpose.
  • Pat Pyette: We would use this to determine whether a policy is applicable for any particular request.
  • Mike: Right, so in some instances the policy may say, I’ll give you access to my resource if you give me a credential that identifies you at a level 3. That’s the policy.
  • Ioana: So would that be part of the AuthorizationPolicy that you need to assert a Level of Assurance high enough. So I’m going to move Level of Assurance to be an attribute of the AuthorizationPolicy.
  • Steve: Can you tell me what the difference is between this and non-repudiation?
  • Mike: Non-repudiation is completely different. In non-repudiation, a user cannot deny having done something, that they produced a particular document. A recipient cannot later deny having received it. Non-repudiation has to do with repudiating something that you’ve asserted in the past.
  • Steve: So it is an attribute that is attached to a message or a document?
  • Mike: That’s right, so the attribute is typically a signature or a wrapper around the document that irrefutably associates that with the recipient or the originator, but has nothing to do with this authentication Level of Assurance thing other than potentially saying that the wrapper should be at some Level of Assurance. The intent was to describe this as the Level of Assurance for the identity of someone or something that would be part of some kind of a policy. I think I had in mind, identity assurance, but the Level of Assurance has to do with the Level of Assurance that would be used to make an authorization decision, not the Level of Assurance for non-repudiation, while that’s a policy, it’s not an AuthorizationPolicy.
  • Rob: In that context, if this is moved up to an organizational attribute, when you do these kinds of things it will be there, and then you have to assume it’s assuring anything that’s associated with that object. For instance, I’m assuring identity, but I’m not assuring this other element. Will this work here?
  • Mike: I hope it does because this is about authorization policies, not authentication policies.
  • Ioana: You’re already authenticated with a higher or lower Level of Assurance.
  • Rob: What other than identify would you be attempting to assure. It should be identity, therefore that’s all you have to do.
  • Mike: I’m open to anyone that has a different use case. The use case that got us into this and said, oh we’re missing a class is the Identity one.
  • Ioana: I have a different question. Would the Level of Assurance be an organizational policy and would it also be an attribute of specific person identity? Is that information carried along only with the policy or is it also carried with the credential?
  • Mike: It’s carried with the credential. So a user doesn’t own as an attribute, a Level of Assurance. It’s assigned by the organization and it’s assigned at run time based upon the target, the policy regarding the target being accessed. So the credential that a user presents may be different from instance to instance based on the target. That’s why in some instances, a password may be sufficient, in others, it requires biometric. Those are indicated by the Level of Assurance attribute. So you may present something that requires two actor authentication, etc. Something that requires the position of a hardware token…the policies behind those levels of assurance. We’re not describing those policies, we’re simply creating a vocabulary that allow the organizations to define them.
  • Ioana: This was my mistake. In all the ISO models, they like to model the session. So when you log you have your credential and you would have as part of your credential the Level of Assurance.
  • Mike: When you log in, there’s a two-factor thing. When you log into something in your authentication service for example, you present to that authentication service, a set of credentials that it knows you by. Then when you’re cross enterprise communication, your authorization service will create a credential (and signs it) for you as required by the service that you’re requesting access to. The SOA model. The user in this case is not authenticating directly to the service provider, there is some indirection there.
  • Ioana: But in the PMAC model, when you authenticate directly there is a session object that is created, and part of that session object your credentials are persisted. You may have additional authorization information added to your login information as part of that session.
  • Mike: The credential itself will likely have the Level of Assurance. It may also have the mechanism that was used to provide that Level of Assurance, whether it’s a PKI credential a smart card, a biometric fingerprint. In any case, unless anyone objects, I think we’ve correctly described this class as more associated with the policy than the user. The user gets this credential and uses it, but doesn’t directly own the Level of Assurance.
  • Ioana: This describes the policy basically. In the context of declaring the policy, the Level of Assurance is probably the AuthorizationPolicy.
  • Richard: So this policy pertains to anything, it’s considered to be something used by an Access Control service used by a particular enterprise.
  • Pat Pyette: The more we talk about this, the more I think we had it correct originally. The Level of Assurance is assigned an identity so when a request comes in there are claims that are made against a specific identity along with the Level of Assurance that says here are the claims and here’s the Level of Assurance that we got. So those things are tied to the identity. I recognize that the policy needs to specify that at some point in time, there may not be a Level of Assurance that’s required, but that Level of Assurance is always tied to an identity.
  • Mike: But it’s tied by inheritance, not directly. The attribute the user receives is inherited by the Level of Assurance prescribed by the policy. It’s not owned by the user directly.
  • Pay Pyette: It is always associated with the identity, which in this case is represented by user.
  • Mike: I agree with this. It’s associated with the credential that’s created for the user, but it would be incorrect to link it directly to the user. You’re correct, this credential that the user gets has an association to the user.
  • Ioana: The way I understand it now, is that part of the Level of Assurance is assigned to you when you log in. When you’re authenticated. So this is all based on context. It’s really the “definitional” elements of the user that we care about like the roles, the location and ability to assign a person is important, but the person identity is not important.
  • Mike: I’ll just give Pat another example that came up in HITSP last week. I have a Level of Assurance white paper that I provided to HITSP. We know that the federal government requires a Level of Assurance three for assertions, but in the civilian community that would incur significant expense that would require upgrade to existing mechanisms, so it’s not particularly a welcome policy. So the potential here is that in a lot of these requests are made between organizations, so what you end up with is the user authenticates to his internal system, and that could be a password, and then a credential is created and signed by the ACS by that system and that’s what is presented to the other organization. So that credential could be signed by the organization at a higher level than the user, so the integrity of the credential itself could be at a level 3 or 4, whereas the user behind the organization could have potentially authenticated at a lower level. So we’re not saying that the user was known to that backend application. The application is saying I’m controlling this by my policies and I’m giving you a credential at level 4, which goes into my system. And I own that and I pass it back to users according to my policy and so this is a way of finessing something like this. It’s under discussion and it’s argumentative, but it’s a way of looking at this.
  • Pat Pyette: How would this attribute actually be used? I originally thought it would be used as a criterion for policy selection, but the more I think about it, the less I think this is true. It’s more simply an attribute that says the Level of Assurance is greater than 3, then permit. If it’s less than 3, then deny.
  • Rob: When you say permit, you mean, whatever is requesting to do something is at a level greater than or equal to the Level of Assurance. The only place it might apply is the Level of Assurance of the entity that wants to do something.
  • Pat Pyette: Given that use, if everyone thinks it belongs as an attribute of an AuthorizationPolicy, I’m OK I think.
  • Ioana: The use that you indicated is what I had in mind. It’s a matter of interoperability.
  • Don: How comprehensive are the user attributes supposed to be?
  • Ioana; The DAM is supposed to focus on those things that are most important, so if we’ve missed a unique ID that was not important, that’s OK, but if we’ve missed an important trait of a specific object that you think we’ve left out, then we need to add it.
  • Don: Just to clarify, Level of Assurance is one of the user attributes, it’s a credential attribute. But there are other user attributes, Level of Proofing, all can be important in Access Control.
  • Mike: Typically level of proofing is part of what you would look into the definition of Level of Assurance, and in-person proofing or that type of thing is implicit in the assignment of a level. We don’t want to miss anything important.
  • Ioana: Are you thinking that level of proofing is an attribute of the user identity and Level of Assurance is part of the AuthorizationPolicy?
  • Don: Yes
  • Ioana: I think what I’m hearing is that we’re going to leave level of proofing as implied and the Level of Assurance as explicit.
  • Mike: I think that’s true because it’s a bit of a policy issue and we’re not trying to define how a domain may choose to constrain these attributes with jurisdictional policy, but to define the attributes by which they can express security AuthorizationPolicy. Does that make sense?
  • Don: Right now it depends on the semantics we’re associating with Level of Assurance.
  • Mike: This particular class is not defined particularly. In the US domain, it would be 1,2,3 or 4. That’s the definition and it would be asserted from the NIST 8063 or something like that.
  • Ioana: When you log in, your domain will assign you a Level of Assurance based how sure we are that you are who you say you are.
  • Mike: This isn’t about Identity Management, it’s about Access Control. The precursor to getting a credential.
  • Don: But attributes associated with that credential are used to make the Access Control decision. *Mike: I agree with you. When we create an assertion or credential that’s being passed, it’s going to have a series of attributes. In the simplest case, we wouldn’t have anything other than the request for a target, the action on the target, and if you think about SAML, we would have an identity assertion. The identity assertion would have the user’s ID and it would have the attributes of that this is this user with this national provider identifier and per SAML, it would say the kind of authentication that was provided. So we’re using Level of Assurance as an attribute that would be in that assertion. And that alone is sufficient to make an authorization decision in some cases. You don’t have to think about the users role. I think this domain model should have in it the classes that would be in the thing, the attributes of the user being asserted, whatever they are, which is why we put this LOA business in here. We should be able to look at this information model from the authorization point of view and say what attributes from this are required from the user to make an authorization assertion. I want the model to contain all the attributes that are necessary in the request interface that has to do with user authorization decision information, and there are other kinds of attributes that can be asserted, but the one I think we’re interested in are the user asserted attributes. I’m hoping that in the normative part of this ballot that Don, Pat and I can extract those classes, which must be or are optional in that interface that we’ve specified in SOA.
  • Don: So if we have any that we want to discuss, this would be the venue.
  • Mike: But we’ve closed the model to further modification, so we want to ballot what we have. We’re moving forward to ballot this. We’ll take comments on it and there will certainly be new work that will bring new classes to bear that we’ve omitted. I’d rather spend the time looking at the use cases. The ballot is OK as it is, and we’ll take new work and put it aside for now. I recognize that this is not going to be perfect, but we have to be able to defend the alignment that Ioana has put in here for these classes against the kinds of questions that are being raised here now.

Question 3: Is Role.confidentiality relevant for a Security policy?

  • There is also a minor point regarding Role.confidentiality. This is not the issue in HL7 Harmonization, but it is a question regarding this analysis model. This is a question, there is no right or wrong answer. The RIM has identified as a possible attribute of a Role, a confidentiality code. Let’s say you have a late-term abortion provider, actually that’s probably a sensitivity code, but is there something specific to a role name or ID that would be part of the Access Control policy that matters in this context?
  • Mike: I’m having trouble thinking of a use case where the role attribute is used to make an Access Control decision. So if the role is marked as being confidential, meaning itself is should not be disclosed to someone else, then how does this affect an Access Control decision? It’s more of a confidentiality issue. So if a user can’t present a role necessary for access control, they won’t get access. That’s a consequence, but the confidentiality of the role is protected.
  • Ioana: I just wanted to confirm this understanding.
  • Pat Pyette: I can’t think of anyway in which confidentiality of a role would impact anything.
  • Mike: There’s a confidentiality Policy that would have to be considered, the information is unclassified or secret or not disclosable, or whatever attributes you want to pick for it that is part of an authorization decision. The user is authorized access to some class of information that has a confidentiality marker on the information.
  • Ioana: This would be a confidentiality marker o the role that is out of scope for this.
  • Steve: The use case that you mentioned would be one application. Late term abortion provider and you want to restrict that information to certain users. But you would need to use your role to access other records within the system/
  • Ioana: If you want to exclude that role when you’re requesting information from another organization, you could be denied based on that exclusion.
  • Pat Pyette: One more question: Role is a specialization of CompositionPolicy and I am trying to understand why.
  • Ioana: This is because it is based on ISO PMAC model. A role is a CompositionPolicy. I think we asked Bernt a question about this, and the answer is correct, that Role is a CompositionPolicy.

Question 4: Are there Privacy policies where data integrity is relevant to Privacy Policy?

  • Ioana: The last item is probably more appropriate for discussion in the CBCC call – the question about the data integrity indicator (in the InformationReference class). Data Integrity is part of Security, but it has not come up at all in the Privacy discussions. Maybe it’s not relevant to Privacy, but this could be a question to the Privacy experts on the CBCC call. Is this a gap, or is this the way it should be? (discussion continued on the CBCC call)

Meeting adjourned at 3:00 PM EST. No significant decisions or motions were made.

Retrieved from "https://wiki.hl7.org/w/index.php?title=November_10th_2009_Security_Conference_Call&oldid=29088"