Difference between revisions of "Security & Privacy DAM"
| (8 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[Security|Back to Security Main Page]] | [[Security|Back to Security Main Page]] | ||
| − | == | + | [[SSOA Privacy and Security Conceptual Information Model in FHIM]] |
| + | =Security and Privacy Dam R1(S&P DAM) Parking Lot for Errata= | ||
| + | Purpose of this page is to document issues and questions about the S&P DAM, which may be addressed in a S&P DAM R2. | ||
| − | ===S&P DAM R1 Description | + | =='''Authority'''== |
| + | |||
| + | ===S&P DAM R1 Description=== | ||
====Issues==== | ====Issues==== | ||
| + | John Moerke: "If the group says that “Authority” is restricted to Jurisdictional and Provider Organizational; then just mark my comment non-persuasive. I personally believe that there are other ‘Authorities’, specifically the use of ‘Authority’ in the context of Privacy is not represented here." | ||
| + | |||
| + | Mike Davis: "I agree with John that patients have “Privacy authority” and that such authority exists, however, it only exits in context of jurisdictional and organizational policy as a subset (sounds like…hierarchy). There is no universal “privacy” context otherwise and in this sense the US HIPAA provides patients privacy authority for authorizations (disclosures) while leaving acceptance of such to the organization. Elsewhere in states, patient privacy is similarly handled in the context of jurisdictional policy. Propose the ontology of authority as: Jurisdictional (Global, Federal and state etc.), organizational, personal." | ||
| + | |||
| + | Kathleen Connor: "Suggest that we use PMAC policy authority and policy bridging. Patient has policy authority over patient's preferences. When that is bridged with the already bridged jurisdictional and organizational policies, the result is the patient's consent directive. This would align with S&P DAM description of the ConstraintPolicy Class [page 24]: | ||
| + | |||
| + | A constraint policy is intended to constrain an existing policy. For example, a ConstraintPolicy | ||
| + | instance may be used to represent a privacy consent directive that sets specific ‘limitations’ on a default | ||
| + | organizational policy regarding substance abuse data (e.g., 42 CFR Part 2). A policy (BasicPolicy or | ||
| + | CompositePolicy) can be constrained by the use of profiles for tailoring a policy instance. Complex | ||
| + | constraints (e.g., an OCL expression) may be applied and managed separately. For this definition and for | ||
| + | management purposes, it is possible to separate externally-defined constraints and specify a | ||
| + | 'ConstraintPolicy' with clearly defined associations to the constrained policy according to component model principles. Effectively, the result of applying constraints is just another CompositePolicy." | ||
| + | =='''Grantee'''== | ||
| + | Grantee seems to merge concept of Grantor as well. Suggest disambiguating and adding Grantor class. | ||
| + | |||
| + | ===S&P DAM R1 Description=== | ||
| + | |||
| + | Class: DelegationPolicy [page 25]: | ||
| + | ''A delegation policy is intended to assign access rights to a specific individual or organization (a grantee). ISO 22600-2 defines delegation as 'conveyance of privilege from one entity that holds such privilege, to another entity'. A DelegationPolicy 'defines what authorizations can be delegated to whom'. | ||
| + | Association 'DelegationPolicy.grantee' of type ' Grantee' with cardinality of [*] | ||
| + | The person or organization that is the subject of delegation. This is the entity that receives the | ||
| + | privilege granted by the DelegationPolicy.'' | ||
| + | |||
| + | Class: DelegationPolicy [page 25] | ||
| + | ''A delegation policy is intended to assign access rights to a specific individual or organization (a grantee). ISO 22600-2 defines delegation as 'conveyance of privilege from one entity that holds such privilege, to another entity'. A DelegationPolicy 'defines what authorizations can be delegated to whom'. | ||
| + | Association 'DelegationPolicy.grantee' of type ' Grantee' with cardinality of [*] The person or organization that is the subject of delegation. This is the entity that receives the privilege granted by the DelegationPolicy.'' | ||
| − | ==Level of Assurance (LoA)== | + | =='''Level of Assurance (LoA)'''== |
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | ===Issues=== | |
| − | + | 1) Is there a vocabuluary for authentication LoA? | |
| + | * Tony Weida's question: | ||
| + | |||
| + | John’s comment pointed out the two aspects of level of assurance which the CSP-DAM combines in that single attribute. Is that likewise acceptable in the ontology (e.g., for consistency with the CSP-DAM and the NIST spec mentioned below)? | ||
| + | |||
| + | The CSP-DAM attribute is of type integer, with interpretation of the integer values unspecified. [http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf NIST document This NIST document "Electronic Authentication Guideline"]specifies four levels of assurance (Levels 1, 2, 3 and 4). Can we point to them, or is there a better source? | ||
| + | |||
| + | * John Moehrke's response: | ||
| + | NIST 800-63 stopped short of defining a vocabulary, they only defined an informative 4 levels. They specifically stopped short as to go to a vocabulary would require writing policy and they didn’t have the authority. There is some efforts to define a vocabulary. Bill Braithwaite is an expert on this topic. The effort is a prime focus of the NSTIC efforts. | ||
| + | |||
| + | 2) Does Level of Assurance only apply to Initiator authentication and attribute ACI and not to target, request, and context ACI? | ||
| + | |||
| + | Kathleen pointed out 10810-3 discussion about assurance of the ACI bindings. Mike stated that LoA is term of art, and more specific than binding assurance because the "levels" for initiator credential LoA is quantified by authoritative sources such as NIST 800-632 and Kantara | ||
| + | |||
| + | Kathleen asked whether there is a term for this binding assurance that we can use in the DAM even though these might not have levels quantified by authoritative sources. | ||
| + | |||
| + | 10810-3 [page 7] | ||
| + | ''5.2.2.4 Binding ACI to initiators, targets and access requests | ||
| + | Binding ACI to an element (i.e. an initiator, target or access request) creates a secure linkage between an element and the ACI allocated to that element. The binding provides assurance to access control functions and other elements both that the ACI is indeed assigned to the particular element and that no modification has occurred since the binding was made. | ||
| + | Binding is achieved by using an integrity service. Several binding mechanisms are possible, including some that are dependent on the location of the element and the ACI, while others may depend on some cryptographic signing or sealing process. The integrity of the binding of ACI to elements needs to be protected within initiator and target systems (e.g. by relying upon operating system functions such as file protection and process separation) and, also, in the | ||
| + | exchange of ACI. Since there may be several possible representations of an element’s ACI (both within systems and between systems), different binding mechanisms may be used for the same ACI. Under some security policies, the confidentiality of ACI also needs to be maintained.'' | ||
| + | |||
| + | Initiator ACI; | ||
| + | ''– a means to validate the binding of the access control certificate to a specific initiator so that it cannot be used by another initiator; | ||
| + | Target ACI; | ||
| + | "– a means to validate the binding of the access control certificate to a specific target so that it cannot be used to access another target;– a means to validate the binding of the access control certificate to a specific access request so that it cannot be used with another access request[...]'' | ||
| + | |||
| + | ===S&P DAM R1 Description=== | ||
| + | |||
| + | Class: AuthorizationPolicy [page 23]: | ||
*Attribute 'AuthorizationPolicy.levelOfAssurance' of type ' INT' with cardinality of [0..1] | *Attribute 'AuthorizationPolicy.levelOfAssurance' of type ' INT' with cardinality of [0..1] | ||
Level of Assurance (LoA) refers to the degree of certainty that | Level of Assurance (LoA) refers to the degree of certainty that | ||
| Line 24: | Line 80: | ||
*(2) a user owns the credentials they are subsequently presenting to access the resource. | *(2) a user owns the credentials they are subsequently presenting to access the resource. | ||
| − | LoA is relevant to authentication, authorization, and access control. A BasicPolicy requires the level of assurance as indicated within the AuthorizationPolicy specialization. | + | LoA is relevant to authentication, authorization, and access control. A BasicPolicy requires the level of assurance as indicated within the AuthorizationPolicy specialization.'' |
| + | |||
| + | ===Background=== | ||
| + | |||
| + | *[http://gforge.hl7.org/gf/download/docmanfileversion/7190/10054/HL7LOABillBraithwaite092012.pptx Levels of Assurance Bill Braithwaite] | ||
| + | *[http://healthcaresecprivacy.blogspot.com/2011/03/authentication-and-level-of-assurance.html John Moehrke's Blog on Authentication and LoA] | ||
| + | |||
| + | =='''Location/Workstation'''== | ||
| + | |||
| + | ===Issues=== | ||
| + | Kathleen Connor: DAM R1 calls out “location/workstation” as an RBAC constraint and put a use case/policy specific limitations on the relation of a user to a location/workstation to a specific permission. Suggest that DAM R2 consolidate location and workstation as types of the context/environment class, 0…* of which may be components of a BasicPolicy, which looks like this [minus a lot of classes]. | ||
| + | |||
| + | [[File:Core DAM classes with user.png]] | ||
| + | |||
| + | ===S&P DAM R1 Description=== | ||
| + | |||
| + | Class: Location [page 20]: ''Access may be granted only to initiators on specific end-user systems, workstations or terminals or only to initiators in a specific physical location. This class is required to support user authorization as specified by the business requirements (Security use case S.1). | ||
| + | Association 'Location.providerOrganization' of type ' ProviderOrganization' with cardinality of [1] This association identifies the organization where the location is scoped. | ||
| + | Attribute 'Location.workstationId' of type ' ST' with cardinality of [1] This attribute is used to specify the precise workstation used by an information user. '' | ||
| + | |||
| + | =='''Privacy Policy'''== | ||
===Issues=== | ===Issues=== | ||
| − | + | While there can be many Privacy Policies associated with a Consent Directive, and a Privacy Policy may be composed of many Privacy Rules, it's not clear that the many Privacy Rules composing a Consent Directive is a constraint on the superset of Privacy Rules from all the Privacy Polices with which the Consent Directive is associated. (Not sure if this is the correct interpretation of this diagram) There may be a need to create a "Composite Privacy Rule Set" rather than PrivacyRule as a component of Consent Directive. | |
| − | ===S&P DAM R1 Description [ | + | ===S&P DAM R1 Description=== |
| + | [[File:S&P DAM Privacy Figure 1.4 Consent Directive Overview Diagram.png|Figure 1.4: Consent Directive Overview Diagram]] | ||
| + | Page 36: "a client's privacy consent represents a further constraint of default privacy policies applicable in that territory." | ||
| + | |||
| + | =='''TOPIC NAME'''== | ||
===Issues=== | ===Issues=== | ||
| + | |||
| + | |||
| + | ===S&P DAM R1 Description=== | ||
Latest revision as of 04:10, 4 November 2014
SSOA Privacy and Security Conceptual Information Model in FHIM
Contents
Security and Privacy Dam R1(S&P DAM) Parking Lot for Errata
Purpose of this page is to document issues and questions about the S&P DAM, which may be addressed in a S&P DAM R2.
Authority
S&P DAM R1 Description
Issues
John Moerke: "If the group says that “Authority” is restricted to Jurisdictional and Provider Organizational; then just mark my comment non-persuasive. I personally believe that there are other ‘Authorities’, specifically the use of ‘Authority’ in the context of Privacy is not represented here."
Mike Davis: "I agree with John that patients have “Privacy authority” and that such authority exists, however, it only exits in context of jurisdictional and organizational policy as a subset (sounds like…hierarchy). There is no universal “privacy” context otherwise and in this sense the US HIPAA provides patients privacy authority for authorizations (disclosures) while leaving acceptance of such to the organization. Elsewhere in states, patient privacy is similarly handled in the context of jurisdictional policy. Propose the ontology of authority as: Jurisdictional (Global, Federal and state etc.), organizational, personal."
Kathleen Connor: "Suggest that we use PMAC policy authority and policy bridging. Patient has policy authority over patient's preferences. When that is bridged with the already bridged jurisdictional and organizational policies, the result is the patient's consent directive. This would align with S&P DAM description of the ConstraintPolicy Class [page 24]:
A constraint policy is intended to constrain an existing policy. For example, a ConstraintPolicy instance may be used to represent a privacy consent directive that sets specific ‘limitations’ on a default organizational policy regarding substance abuse data (e.g., 42 CFR Part 2). A policy (BasicPolicy or CompositePolicy) can be constrained by the use of profiles for tailoring a policy instance. Complex constraints (e.g., an OCL expression) may be applied and managed separately. For this definition and for management purposes, it is possible to separate externally-defined constraints and specify a 'ConstraintPolicy' with clearly defined associations to the constrained policy according to component model principles. Effectively, the result of applying constraints is just another CompositePolicy."
Grantee
Grantee seems to merge concept of Grantor as well. Suggest disambiguating and adding Grantor class.
S&P DAM R1 Description
Class: DelegationPolicy [page 25]: A delegation policy is intended to assign access rights to a specific individual or organization (a grantee). ISO 22600-2 defines delegation as 'conveyance of privilege from one entity that holds such privilege, to another entity'. A DelegationPolicy 'defines what authorizations can be delegated to whom'. Association 'DelegationPolicy.grantee' of type ' Grantee' with cardinality of [*] The person or organization that is the subject of delegation. This is the entity that receives the privilege granted by the DelegationPolicy.
Class: DelegationPolicy [page 25] A delegation policy is intended to assign access rights to a specific individual or organization (a grantee). ISO 22600-2 defines delegation as 'conveyance of privilege from one entity that holds such privilege, to another entity'. A DelegationPolicy 'defines what authorizations can be delegated to whom'. Association 'DelegationPolicy.grantee' of type ' Grantee' with cardinality of [*] The person or organization that is the subject of delegation. This is the entity that receives the privilege granted by the DelegationPolicy.
Level of Assurance (LoA)
Issues
1) Is there a vocabuluary for authentication LoA?
- Tony Weida's question:
John’s comment pointed out the two aspects of level of assurance which the CSP-DAM combines in that single attribute. Is that likewise acceptable in the ontology (e.g., for consistency with the CSP-DAM and the NIST spec mentioned below)?
The CSP-DAM attribute is of type integer, with interpretation of the integer values unspecified. NIST document This NIST document "Electronic Authentication Guideline"specifies four levels of assurance (Levels 1, 2, 3 and 4). Can we point to them, or is there a better source?
- John Moehrke's response:
NIST 800-63 stopped short of defining a vocabulary, they only defined an informative 4 levels. They specifically stopped short as to go to a vocabulary would require writing policy and they didn’t have the authority. There is some efforts to define a vocabulary. Bill Braithwaite is an expert on this topic. The effort is a prime focus of the NSTIC efforts.
2) Does Level of Assurance only apply to Initiator authentication and attribute ACI and not to target, request, and context ACI?
Kathleen pointed out 10810-3 discussion about assurance of the ACI bindings. Mike stated that LoA is term of art, and more specific than binding assurance because the "levels" for initiator credential LoA is quantified by authoritative sources such as NIST 800-632 and Kantara
Kathleen asked whether there is a term for this binding assurance that we can use in the DAM even though these might not have levels quantified by authoritative sources.
10810-3 [page 7] 5.2.2.4 Binding ACI to initiators, targets and access requests Binding ACI to an element (i.e. an initiator, target or access request) creates a secure linkage between an element and the ACI allocated to that element. The binding provides assurance to access control functions and other elements both that the ACI is indeed assigned to the particular element and that no modification has occurred since the binding was made. Binding is achieved by using an integrity service. Several binding mechanisms are possible, including some that are dependent on the location of the element and the ACI, while others may depend on some cryptographic signing or sealing process. The integrity of the binding of ACI to elements needs to be protected within initiator and target systems (e.g. by relying upon operating system functions such as file protection and process separation) and, also, in the exchange of ACI. Since there may be several possible representations of an element’s ACI (both within systems and between systems), different binding mechanisms may be used for the same ACI. Under some security policies, the confidentiality of ACI also needs to be maintained.
Initiator ACI; – a means to validate the binding of the access control certificate to a specific initiator so that it cannot be used by another initiator; Target ACI; "– a means to validate the binding of the access control certificate to a specific target so that it cannot be used to access another target;– a means to validate the binding of the access control certificate to a specific access request so that it cannot be used with another access request[...]
S&P DAM R1 Description
Class: AuthorizationPolicy [page 23]:
- Attribute 'AuthorizationPolicy.levelOfAssurance' of type ' INT' with cardinality of [0..1]
Level of Assurance (LoA) refers to the degree of certainty that
- (1) a resource owner has that a person's physical self has been adequately verified before credentials are issued by a registration
authority, and
- (2) a user owns the credentials they are subsequently presenting to access the resource.
LoA is relevant to authentication, authorization, and access control. A BasicPolicy requires the level of assurance as indicated within the AuthorizationPolicy specialization.
Background
Location/Workstation
Issues
Kathleen Connor: DAM R1 calls out “location/workstation” as an RBAC constraint and put a use case/policy specific limitations on the relation of a user to a location/workstation to a specific permission. Suggest that DAM R2 consolidate location and workstation as types of the context/environment class, 0…* of which may be components of a BasicPolicy, which looks like this [minus a lot of classes].
S&P DAM R1 Description
Class: Location [page 20]: Access may be granted only to initiators on specific end-user systems, workstations or terminals or only to initiators in a specific physical location. This class is required to support user authorization as specified by the business requirements (Security use case S.1). Association 'Location.providerOrganization' of type ' ProviderOrganization' with cardinality of [1] This association identifies the organization where the location is scoped. Attribute 'Location.workstationId' of type ' ST' with cardinality of [1] This attribute is used to specify the precise workstation used by an information user.
Privacy Policy
Issues
While there can be many Privacy Policies associated with a Consent Directive, and a Privacy Policy may be composed of many Privacy Rules, it's not clear that the many Privacy Rules composing a Consent Directive is a constraint on the superset of Privacy Rules from all the Privacy Polices with which the Consent Directive is associated. (Not sure if this is the correct interpretation of this diagram) There may be a need to create a "Composite Privacy Rule Set" rather than PrivacyRule as a component of Consent Directive.
S&P DAM R1 Description
Page 36: "a client's privacy consent represents a further constraint of default privacy policies applicable in that territory."
