Skip to end of metadata
Go to start of metadata


ISO 22600-2:2014

6.5 Role model

For managing relationships between the entities mediated by an activity, two different roles have to be

defined: organizational or structural roles at the entity’s side and functional roles at the act’s side (see

Figure 6).

Figure 6 — The generic role concept

Because the role concept is deployed in many different contextual relationships such as the professionals’

administration, certification procedures, roster management, etc., the role model and its deployment

has been separately defined in ISO 21298.

For enabling the deployment of this International Standard, the currently available main aspects

of ISO 21298 are presented in Annex A. Being under development, ISO 21298 is a living document.

Therefore, the reader is encouraged to inform himself about the matured role aspects by considering

the version of ISO 21298 available at the respective time.


page 19

Figure 9 — Role-based access control schema

The RBAC schema defines the assignment of permissions dedicated to a functional role which has

been assigned to a principal within a certain session. The functional role might be qualified by a

set of structural roles assigned to the same principal.


ASTM E 2595 Privilege Structural Functional Roles

6.3.2 Structural roles may specify broad relations between

entities in the sense of competence (for example, HL7 Reference

Implementation Model (RIM) roles), reflect organizational

or structural relations (hierarchies), as well as provide

qualifications for access to high-level organizational workflow.

6.3.3 Functional roles are bound to an act. Functional roles

can be assigned to be performed during an act. They may

correspond, for example, to HL7 RIM participation and provide

fine-grained access control information needed to access

protected objects and functions within the context of an

application.

6.3.4 As an expression of security policy, roles are easily

understood; however, more complex rules may not be readily

stated as roles. Rule-based access control (RuBAC), as opposed

to role-based access control (RBAC), allow users to

access systems and information based on predetermined and

configured rules (11). Both RBAC and RuBAC are expressible

in a common engineered policy language providing for uniform

enforcement and management. The following section

describes RBAC (structural and functional roles) and RuBAC

as elements of engineered security policy.

6.3.5 Structural Role Framework:

6.3.5.1 Structural roles12 place people in the organizational

hierarchy as belonging to categories of healthcare personnel

warranting differing levels of access control. Similar to organizational

roles, structural roles allow users to participate in the

organization’s workflow (for example, tasks) by job, title, or

position but do not specify detailed permissions on specific

information objects. Some structural role examples include:

physician, pharmacist, registered nurse supervisor, and ward

clerk. Structural roles may be found as noncritical certificate

extensions entries to an X.509 certificate as specified in

Practice E 2212.

FIG. 8 Use of Structural Role




target.

6.3.5.3 To accomplish this function, the user asserts or is

verified to possess, in addition to authentication information,

appropriate structural roles as a prerequisite authorization to

“connect” to the task or workflow containing the requested

session or target. An infrastructure access enforcement function

grants or denies access to the session or target based on the

structural role. Structural roles would be typically managed in

identity certificates (per Practice E 2212) or directories. Structural

roles allow an enterprise to grant, suspend, or deny access

(by means of the service-oriented verifier) to any or all

resources through a single point of management and control.

6.3.5.4 Guide E 1986 identifies healthcare persons for

whom role-based access control is warranted. These Guide

E 1986 person types define structural healthcare role names

used within this guide.

6.3.5.5 Guide E 1986 examples of structural roles for

healthcare professionals include:

(1) Physician (MD/allopath, osteopath, chiropractic,

naturopath, or homeopath),

(2) Advanced practice registered nurse (NP, NM, CAN, or

CNS),

(3) Pharmacist (DP),

(4) Physician assistant (PA),

(5) Technician,

(6) Medical laboratory technician (MLT),

(7) Occupational therapist (OTR/L),

(8) Phlebotomist,

(9) Paramedic,

(10) Admission clerk,

(11) Transcriptionist,

(12) Students,

(13) Administrative support staff and services, and

(14) Executive officers.

6.3.5.6 Structural Role Guidelines:

(1) By assigning Guide E 1986 healthcare personnel that

warrant differing levels of access control to defined healthcare

workflows, they can be used for engineering purposes to define

structural roles. These roles provide the requisite precursor role

that gives a person access to a “session” or “connection” in

ANSI International Committee for Information Technology

Standards (INCITS) RBAC. ASTM International structural

roles are readily mapped to U.S. National Uniform Claims

Committee taxonomies. Other mappings are possible.

(2) In a PMI, structural roles allow a user possessing that

role to participate in a work profile. By placing the access

control enforcement function for structural roles at a sufficiently

high level (as part of an enterprise authentication

service), structural roles can be used to grant, suspend, or

revoke access to all applications across the enterprise from a

single central location. This is useful for immediately revoking

privileges for a user across the enterprise for some reason (for

example, leaving the organization) or for providing an insulating

layer between users and applications. Without the correct

structural role, the user is unable to initiate sessions with any or

all applications.

(3) Considerations for use:

(a) To control granting of access to one or more applications

on an enterprise basis,

(b) To temporarily suspend user access to one or more or

all applications for a period of time,

(c) To permanently remove user access to one or more

applications on an enterprise basis,

(d) To grant access to an application data and function

where the access can be simply stated (for example, URL or

directory),

(e) To provide a simplified role hierarchy,

(f) To act as functional roles when the roles for an

application are simple,

(g) To quickly change access rights on a global or

enterprise basis,

(h) To manage authorizations at the enterprise level,

(i) As an instrument of governance,

(j) To establish broad requirements for external business

partner access,

(k) To determine purpose of use, and

(l) To enable emergency access.

(3) Pharmacist (DP),

(4) Physician assistant (PA),

(5) Technician,

(6) Medical laboratory technician (MLT),

(7) Occupational therapist (OTR/L),

(8) Phlebotomist,

(9) Paramedic,

(10) Admission clerk,

(11) Transcriptionist,

(12) Students,

(13) Administrative support staff and services, and

(14) Executive officers.

6.3.5.6 Structural Role Guidelines:

(1) By assigning Guide E 1986 healthcare personnel that

warrant differing levels of access control to defined healthcare

workflows, they can be used for engineering purposes to define

structural roles. These roles provide the requisite precursor role

that gives a person access to a “session” or “connection” in

ANSI International Committee for Information Technology

Standards (INCITS) RBAC. ASTM International structural

roles are readily mapped to U.S. National Uniform Claims

Committee taxonomies. Other mappings are possible.

(2) In a PMI, structural roles allow a user possessing that

role to participate in a work profile. By placing the access

control enforcement function for structural roles at a sufficiently

high level (as part of an enterprise authentication

service), structural roles can be used to grant, suspend, or

revoke access to all applications across the enterprise from a

single central location. This is useful for immediately revoking

privileges for a user across the enterprise for some reason (for

example, leaving the organization) or for providing an insulating

layer between users and applications. Without the correct

structural role, the user is unable to initiate sessions with any or

all applications.

(3) Considerations for use:

(a) To control granting of access to one or more applications

on an enterprise basis,

(b) To temporarily suspend user access to one or more or

all applications for a period of time,

(c) To permanently remove user access to one or more

applications on an enterprise basis,

(d) To grant access to an application data and function

where the access can be simply stated (for example, URL or

directory),

(e) To provide a simplified role hierarchy,

(f) To act as functional roles when the roles for an

application are simple,

(g) To quickly change access rights on a global or

enterprise basis,

(h) To manage authorizations at the enterprise level,

(i) As an instrument of governance,

(j) To establish broad requirements for external business

partner access,

(k) To determine purpose of use, and

(l) To enable emergency access.

FIG. 8 Use of Structural Role

E 2595 – 07

16

6.3.6 Functional Role Framework:

6.3.6.1 Functional roles consist of all the permissions on

health information system objects needed to perform a task.

Functional role names associate groups of permissions for

convenience in assignment to users. A user (claimant) may be

assigned one or more functional roles and thereby be assigned

all of the permissions associated with a corresponding healthcare

workflow. Permissions will ultimately be used to set the

system operations (for example, create, read, update, delete,

execute, and so forth) for data and software applications.

Functional roles may be found as entries in a user attribute

credential or stored in a distributed authorization directory.

6.3.6.2 Functional role activation cannot occur until the

session is established, so structural role authorization/access is

prerequisite to establishing a session or connection to the

target. In the extended control model, what is desired is a

decision on the user’s authorizations to perform operations on

the target’s protected objects. The result of the decision

information is used as an input to the verifier policy enforcement

point (PEP) for the purpose of access control.

6.3.6.3 Functional roles describe the permissions that a user

has available once the session is established and his/her roles

are activated. Functional roles are contained in applications,

directories, attribute certificates, and XACML extensions.

Functional roles specifically define, in terms of permissions,

what authorizations are required to access protected resource

functions and data. Functional roles that allow the user to

participate in the business process workflow are therefore

much more granular than structural roles. Functional roles

created from standards-based permissions have applicability

both within and across the enterprise and with business

partners. Functional roles are aligned with existing access

control mechanisms by mapping their constituent standard

permissions to underlying application enforcement mechanisms.

As described in Fig. 9, functional roles may have both

external/internal components.

6.3.6.4 The Health Level 7 (HL7) standards development

organization has begun an effort to develop standard

healthcare-wide permissions that can be used to define interoperable

roles. The HL7 effort is based upon a defined roleengineering

process broadly based upon work by Neuman and

Strembeck (13). Currently available as a draft standard for trial

use, these standard permissions allow for the expression of

functional roles that are ANSI, ISO, and OASIS compliant.

6.3.6.5 Functional Role Guidelines:

(1) Functional roles reflect rights needed to perform the

essential business functions that need to be performed once

access to the application session is granted. Functional roles

define what an entity can do once connected to a protected

resource.

(2) Considerations for use:

(a) Provide detailed fine-grained access rights needed to

specific application data and functions,

(b) Provide standards-based roles for specific communities

to avoid duplication and promote functional interoperability,

(c) For the purpose of supporting dynamic roles,

(d) For the purpose of supporting rich hierarchical strategies,

(e) To provide needed granularity to support roles by

location, by clinic, and so forth,

(f) To provide flexibility for expressing constraints and

other detailed rules,

(g) To support service-oriented architectures and allow

for separation of business and security rules,

(h) To simplify management,

(i) For interoperability and cross platform management or

for proprietary, application-specific purposes,

(j) Expressions in standard policy language such as

XACML,

(k) Support role provisioning,

(l) To develop functional roles by means of a documented

role-engineering process,

(m) Management of roles through an enterprise level

management group of healthcare professionals and subject

matter experts,


TABLE 3 Examples of Objects and Actions at Different Levels of

a Role Engineering Hierarchy (Role Ontology)

Action Role Engineering Object Role

Participate Work Profile Structural Role

Execute Task

Execute Scenario

Perform Step

Create, Read, Update, DeleteA Aggregation Functional Role

Execute Function Functional Role

Create, Read, Update, Delete Data Table

Create, Read, Update, Delete Data Element

A Many healthcare organizations do not “delete” objects, but instead add a new

object that replaces the older one. In this case, “delete” may be effectively

implemented as “addend.”



6.3.7.9 By analyzing workflow and decomposing actions on

objects, permissions and functional roles can be defined.

Neumann and Strembeck summarize their general approach in

the scenario-driven role engineering process (13).

6.3.7.10 Considerations for use:

(1) Identify and model usage scenarios,

(2) Derive permissions from scenarios,

(3) Identify permission constraints,

(4) Refine scenario model,

(5) Define tasks and work profiles,

(6) Derive preliminary role hierarchy, and

(7) Define RBAC model.

6.3.7.11 The scenario model, as shown in Fig. 11, illustrates

the hierarchy of work profile, task, scenario, and step. Permissions

are defined relative to steps (described in 6.3.7.12).

6.3.7.12 In the scenario-based role-engineering approach,

each action and event within a scenario can be seen as a step

that is associated with a particular access operation. Scenarios,

which are applied in a particular order to reach a predefined

task goal, act as sources for the derivation of permissions. The

user performing a scenario shall own all permissions that are

needed to complete every step of the scenario. Additional

considerations in implementing the role-engineering process

include:

(1) Create or adopt/adapt natural language scenarios that

describe a healthcare workflow.

(2) From the scenario description, prepare a sequence

diagram that captures actors and actions.

(3) In the diagram, identify where interactions with an

information system object occur at an appropriate and consistent

level of the role hierarchy (Table 3). These are called steps.

(4) Identify permissions required to perform each step.

Enter the permissions into a permission catalog.

(5) In the permission catalog, combine permissions that are

considered to be duplicates.

6.3.7.13 Optional:

(1) For each permission, refine/map it to actual low-level

system access control terms (for example, create, read, update,

delete, and execute).

(2) Document constraints in a constraint catalog.

6.3.7.14 Permission-Permission Constraints:

(1) Permission constraints are recorded as part of the

role-engineering process. For example, a constrained permission

occurs when only one role is allowed to perform a

particular task at any given time. A constraint occurs for a

permission when its definition is tied to cardinality. In this case,

the constraint on the permission would be the cardinality

specification. Examples of permission constraints include:

(a) Head nurse on a hospital floor (cardinality of one),

(b) Chief of staff (cardinality of one),

(c) Lab technician versus lab technician supervisor (separation

of duties),

(d) Provider’s access to a remote hospital that is not

his/her primary workplace (location), and


(e) Physician working in a clinic (time dependency)

versus physician working in the emergency room (ER) (no

time dependency).

(2) The discussion in 6.3.7.14(1) relies on the fact that the

functional role name is arbitrary and only has meaning as a

collection of ANSI INCITS compliant permissions. Furthermore,

the defined roles are necessarily specific to the organization

defining them and, hence, do not by themselves provide

any interoperability with business partners other than through

business partner agreement. To achieve true interoperability,

organizations will require standardization of the healthcare

permissions and a means to advertise and assert standard

rights.

6.3.8 Rule-Based Access Control Framework:

6.3.8.1 Rule-based access control allows enterprises to create

logical expressions that reflect security policy in ways that

would be difficult otherwise. Rule-based access control can be

used to express business rules, for example, that control access

to system resources at a detailed level. By separating business

rules for business process from those that control access, it is

possible to create new models for access control of fine-grained

decisions.

6.3.8.2 Rule-based access control may also be a promising

mechanism for dealing with complex privacy rules. For example,

the Health Insurance Portability and Accountability Act

provides patients the opportunity to request restrictions on

access to their data. Similar provisions are reflected in the laws

of many countries. Rule-based access control can possibly

enforce rules such as this in which there are no existing

well-defined security mechanisms.

6.3.8.3 Rule-based access control implemented as a service

in an enterprise authorization framework appears especially

attractive. For example, privacy rules could be enforced

globally without requiring recoding of each application handling

personal health information. Since the rules and their

enforcement occur outside of the application, it is possible to

create and enforce dynamically new policies never envisioned

when the applications were created, all without reworking or

touching the applications themselves.

6.3.8.4 While there is currently no standard way of implementing

rule-based access control, a standards-based language

is one way to express and leverage policy enforcement among

applications. Centralized policy management also provides for

consistent policy description and enforcement. The guideline

language for this standard is OASIS eXtensible Access Control

Markup Language (XACML).

6.3.8.5 Considerations for use:

(1) Identifying RuBAC as a component of enterprise

strategic planning, architecture, and migration approaches,

(2) Balancing RuBAC use between embedded application

code and service-oriented authorization approaches,

(3) Integrating RuBAC with other mechanisms such as

RBAC,

(4) Separating security logic embedded in legacy applications

from business code,

(5) Balancing “wire-level” protocols in application development

environments against network-level protocols such as

SOAP,

(6) Availability of hardware-based accelerators to speed

slower XML parsing (14),

(7) Availability of XACML graphical user interfaces rather

than manually constructing complex XACML expressions, and

(8) Use of standards-based protocols for exchanging Ru-

BAC policy with business partners.

6.3.9 Separating Security from Business Logic:

6.3.9.1 In designing a service-oriented PMI framework,

there is opportunity to distinguish between enforcement of

security policy from execution of business logic. To implement

RuBAC as a service, it is advantageous to separate and isolate

security and business application code whenever possible. This

separation is essential for security engineers to obtain a clear

definition of security boundaries, ensure security code is not

affected by changes to business logic, and support certification.

6.3.9.2 Consideration for use:

(1) Relieve business applications developers from writing,

managing, testing, certifying, and maintaining embedded security

code,

(2) Create security services that are independent of

application-level details and that can be managed and maintained

separately from application development, and

(3) Improve applications maintainability by separating

business and security layers.

6.3.9.3 Separating security from business logic can be

difficult. In general, access to a resource within business logic

deals with interaction upon a set of resources the user has

authority to access. Rules for separating security logic can be

identified using the criteria in 6.3.9.4.

6.3.9.4 Consideration for use:

(1) Involves a change of security state (for example,

confidential to nonconfidential),

(2) Involves enforcing confidentiality, integrity, or availability

of data,

(3) Involves enforcing concepts of least privilege, need to

know, or separation of duties,

(4) Involves enforcement of security regulatory requirements

through standards-based security mechanisms, and

(5) Involves the collection, parsing, and evaluation of

access control information defined at the beginning of this

section (initiator ACI, target ACI, action ACI, and contextual

ACI).

6.3.9.5 Privacy:

(1) Privacy is a special case of the authorization in which

access to personally identifiable information (PII) is controlled.

This type of authorization is usually based on the data being

retrieved. For example, it may be okay to access a customer’s

home address but not their home phone number. Healthcare

privacy policies for other than treatment, payment, or healthcare

operations can become complex. Even under these conditions,

local rules may prevail. Complex privacy rules, if not

carefully managed, could cause denial of service conditions

and patient safety issues. Privacy generally not known to

security personnel and adding privacy administrators to security

poses new issues. Enforcing privacy rules in security

would involve significant unplanned costs. Furthermore, security

standards that could enforce privacy 9authorizations9 do

not address privacy explicitly.


(2) Privacy protections, as commonly defined, require

knowledge of the application data values and some sort of

labeled security. Typical commercial off-the-shelf (COTS)

security subsystems, below ISO Layer 7, are architecturally

unaware of such values and do not support mandatory access

controls using data labels.

(3) Even though industry expects privacy and security to be

closely related, standards are lacking that define the relationships

among privacy protected healthcare data values, labels,

policies, and access controls.

(4) A major issue is that privacy is not a universal concept

at the detail level of law, regulation, localized social custom,

organizational policies, and personal sensitivities. Even if

XACML were used to convey privacy policies, there is

currently no standard vocabulary and grammar to express these

privacy details. Since individual healthcare record entries have

been described as having variable privacy issues, we also need

to deal with practical matters of bandwidth and storage space

allocated to data labeling. The practicality of labor or automated

techniques to label the data is also a concern.

(5) Considerations for use:

(a) If privacy rules do not require the same level of

assurance as security policies, consider enforcing complex

privacy rules using application code. This avoids the overhead

associated with security development, testing, certification, and

management as a “security policy.”

(b) If privacy rules can be expressed in simple namevalue

pairs, then use of privacy “policy point” may be an

option; however, such structures can also be readily created

without using security services.

(c) Security services of confidentiality, integrity, and

nonrepudiation are more understood in supporting privacy. In

assigning policy rules to security for enforcement of access

control, be aware that most security organizations do not

currently consider “privacy” as a type of security policy, nor do

they have experience in implementing detailed privacy polices.

(d) Consider application-layer “break-glass” barriers to

enforce privacy policies before allocating to security services.

(e) Consider the impact that privacy policies enforcement

may have in implementing “emergency access” when life or

threat of injury to the patient is at stake.

6.3.9.6 Business Process Execution Language (BPEL):

(1) As organizations implement a service-oriented approach

for managing their business processes, services are

becoming the fundamental elements of application development.

BPEL is a standard for orchestrating these services and

managing execution of business processes.

(2) Most business processes contain multiple decision

points in which certain criteria are evaluated. Based on these

criteria/business rules, business processes change their behavior.

Thus, these business rules drive the business process. These

rules are mostly embedded within the business process itself

causing the following problems:

(a) Most organizations lack a central repository. Consequently,

organization-wide change in policy cannot be applied

across all business processes.

(b) Business rules change more often than the processes

themselves. Thus, developers often have to commit lots of time

to changing and managing these embedded business rules.

(c) Business processes are capable of reusing the rules.

Hence, developers end up designing rules for each and every

process leading inconsistency or redundancy or both.

(3) Using a rules engine eliminates the above problems by

separating business processes from business rules. In this

approach, rules are exposed as services and BPEL processes

leverage these services by querying the engine when they reach

the decision points (15).

6.4 Provisioning:

6.4.1 Provisioning refers to the process of managing attributes

and accounts within the scope of a defined business

process or interaction. Provisioning an account or service may

involve the creation, modification, deletion, suspension, or

restoration of a defined set of accounts or attributes.

6.4.2 Provisioning of user access control credentials refers

to the creation, maintenance, correlation, synchronization, and

deactivation of user objects and user attributes, as they exist in

one or more systems, directories, or applications, in response to

automated or interactive business processes. Provisioning software

may include one or more of the following processes:

change propagation, self-service workflow, consolidated user

administration, delegated user administration, and federated

change control. Provisioning is typically a subsystem or

function of an identity management system that is particularly

useful within organizations in which users may be represented

by multiple-user objects on multiple systems.

6.4.3 Considerations for use:

6.4.3.1 Provides the ability to provision incremental updates

to policy and configuration data simultaneously across all

distributed decision/enforcement points,

6.4.3.2 Automates the process of user management (authorization,

roles, and authentication), and

6.4.3.3 An extensible, XML-based standard language.

6.5 Policy Enforcement Point Guidelines:

6.5.1 The design of a PMI can influence placement of the

PEP. In a distributed PMI, a PEP can be placed at the

application level or the enterprise level. The following factors

are important in deciding the proper placement.

6.5.2 Considerations for use:

6.5.2.1 Availability of the PEP,

6.5.2.2 Reduction of the number of PEPs,

6.5.2.3 Ability to manage centrally,

6.5.2.4 PEP lifecycle maintenance,

6.5.2.5 Physical security of the PEP,

6.5.2.6 PEP access to the network, and

6.5.2.7 PEP proximity to the application.

6.5.3 Co-location of the PEP with applications will decrease

latency. In these cases, a local policy store should be available

to allow the policy engine to work during extranet outages.

6.5.4 LDAP-Enabled Directory Service Versus Policy Engines:

6.5.4.1 The choice of claimant mechanism can have an

effect on performance and complexity of the PMI framework.

LDAP-based mechanisms are typically fast but provide simple

data, for example, whether the claimant is a member of a


specific role. Alternatively, policy engines can factor in several

independent elements into the authorization decision process.

Considerations are listed in the following:

(1) LDAP—Use of an LDAP-enabled directory service is

suggested when speed is required and the decision can be based

on possession of a certain role, especially structural roles (see

6.3.5).

(a) Considerations for use:

(1) Data retrieved consists of single strings,

(2) There is a sensitivity to processing overhead,

(3) There is a need for documented interface, and

(4) There is no need for evaluating policies.

(2) Policy Engine—Policy engines offer flexibility but

reduced speed compared to LDAP lookup when implemented

in general purpose software engines. Special purpose

hardware-based policy engines, on the other hand, offer advantages

over LDAP when evaluating complex rules, constraints,

and combining rules from multiple policy points. Note that

caching of decisions (within their validity period) from a policy

engine keyed by a hash of the request attributes can improve

performance significantly in an environment in which many

accesses are being made in a given period of time and many of

these involve the same request attributes.

(a) Considerations for use:

(1) Data retrieved consists of complex or multiple

elements,

(2) Requirement for the evaluation of multiple elements,

(3) Need to support complex policy languages (for

example, XACML), and

(4) Ability to tolerate slower response time.

6.5.4.2 Use of an LDAP-enabled directory service is suggested

when speed is required and the decision can be based on

possession of a certain role, especially structural roles (see

6.3.5). Note that caching of decisions (within their validity

period) from a policy engine keyed by a hash of the request

attributes can improve performance significantly in an environment

in which many accesses are being made in a given

period of time, and many of these involve the same request

attributes.

6.5.4.3 Policy engines are appropriate when evaluating

participation in a workflow, especially in functional roles (see

6.3.6). The privilege management infrastructure framework

may also use a combination of LDAP and policy engine (16).

6.6 Policy Decision Point (PDP):

6.6.1 Policy decision points (PDPs) can be implemented in

many ways depending on the model appropriate to the infrastructure

(see SAML 2.0 profile of XACML). The PDP is

responsible for deciding if an access control request should be

allowed or denied. The decision is based on policies available

to the PDP from one or more policy stores. Additional ACI can

be used by the PDP in making the access control decision. The

decision is returned to the requestor directly to the PEP or

through an intermediary such as a context handler.

6.6.2 Considerations for use:

6.6.2.1 Place PDP such that it can be centrally managed,

6.6.2.2 Use XACML to convey access control requests and

decisions,

6.6.2.3 Consider the security of the PDP and interprocess

communications,

6.6.2.4 Consider if the PDP located on the application (local

decisions) or network (global decisions) or both,

6.6.2.5 Consider mechanisms to provide assurance of the

decision provided to the PEP, and

6.6.2.6 Place PDP on hardware assisted accelerator to improve

performance.

6.6.3 Many design options are possible that increase security

and flexibility of the PDP support infrastructure (17).

6.7 Claimant Mechanisms:

6.7.1 Possible approaches to management of user privileges

in a service-oriented PMI architecture include:

6.7.1.1 Storage of privileges in a digitally signed credential,

6.7.1.2 Centralized storage of privileges (for example, in an

LDAP-enabled service), and

6.7.1.3 Assertions by an AA.

6.7.2 Storage of privileges in a digitally signed certificate

can be based on a public key certificate, an attribute certificate,

or an XACML attribute. The advantages to each approach are

summarized in ISO 9594-8 (2000). Public key certificates may

store privileges as noncritical extensions as described in

Practice E 2212. The use of an identity certificate in this way

tightly binds authentication to authorization and arguably

provides resilience to network failure. However, there are

several disadvantages in this approach.

6.7.3 Invalidating or changing any privilege owned by the

certificate holder would require revoking and reissuing the

certificate. Revocation of the certificate typically involves

listing the certificate identification number on a certificate

revocation list (CRL). As a result, the identity holder is unable

to use their card (or other token) until it is reissued. Since

identity certificates are typically in the possession of the holder,

the reissuing process is unwieldy. Note that use of the identity

certificate to store privileges does not provide resilience to

network failure, since the CRL must be consulted to validate

the certificate. Accordingly, identity certificates are more

appropriate for 9structural9 roles (see 6.3.5) rather than “functional”

roles (see 6.3.6).

6.7.4 One alternative is the use of a separate digitally signed

certificate, called an attribute certificate, designed to hold user

privileges. Additional infrastructure is required to issue and

manage this second type of digitally signed certificate. However,

there are several advantages in this approach.

6.7.5 The attribute certificate is issued and signed by an

attribute authority separate from the certificate authority that

manages identity certificates. Authorization and authentication

are still tightly bound by placing the user’s identity certificate

serial number in the holder field of the attribute certificate.

Revocation of the attribute can be accomplished using an

attribute certificate revocation list (ACRL). However, there is

no reason why a user should take physical possession of an

attribute certificate. Thus, the attribute certificates themselves

can be stored in an LDAP-enabled service. Revocation of the

certificate, therefore, involves replacement of the earlier attribute

certificate with the current attribute certificate. There is

no penalty in frequent changes of privileges held by the

attribute certificate seen in the previous mechanism.


6.7.6 There is an additional benefit to the additional infrastructure

required to support attribute certificates as pointed out

in Ref (6). Certificate authorities issuing identity certificates

are typically managed by a trusted entity outside the enterprise.

Adding infrastructure within the enterprise to support attribute

certificates helps keep sensitive privilege information from

outsiders. Attribute certificates are typically only needed by the

verifier, so there is no need to expose the privileges held by a

user to entities outside the enterprise.

6.7.7 LDAP Lookup (Role Lookup):

6.7.7.1 Role lookup can be supported by keeping role

information in an LDAP structure. LDAP provides fast search

and read functionality required in quickly collecting role

information required in determining privileges associated with

a user. The use of LDAP for role lookup is typically supported

by web application servers. Alternatively, LDAP can be called

from applications running independently of application servers.

The preferred approach is to deploy a PDP that performs

the role lookup in responding to an access control request. In

any case, LDAP role lookup is beneficial because it provides a

mechanism that separates the role information from the application

code requesting the information.

6.7.7.2 Role information can be provided from an assertion

(for example, an SAML assertion) reducing the need for LDAP

lookup.

6.7.8 Certificates—As discussed in 6.7.7, certificates provide

assurance by binding an identity to a certificate through

the use of a cryptographic key. Certificates can be used by

services to establish trust relationships throughput the PMI.

Trusted certificates can be used to provide assurance over

assertions made by trusted services of identity or privilege to a

relying party. Identity certificates can provide role information;

however, this information should be static in nature (that is,

structural roles) because changing role information in an

identity certificate necessitates cancellation and reissuance of

the certificate. Attribute certificates offer a better way to pass

nonstatic privilege and role (that is, functional role) information.

Certificates also provide means for confidentiality and

nonrepudiation.

6.7.8.1 Attribute Certificates:

(1) A user’s attribute certificate may contain a reference to

another attribute certificate which contains additional privileges.

This provides an efficient mechanism for implementing

privileged roles.

(2) Many environments which have authorization requirements

require the use of role-based privileges (typically in

conjunction with identity-based privileges) for some aspect of

their operation. Thus, a claimant may present something to the

verifier demonstrating only that the claimant has a particular

role (for example, “licensed healthcare provider” or “file

clerk”). The verifier may know a priori, or may have to

discover by some other means, the privileges associated with

the asserted role in order to make a pass/fail authorization

decision.

(3) Considerations for use:

(a) Lack of reliable communication system,

(b) Desire not to confirm information with issuing authority,

(c) Slow changing or relatively static roles, and

(d) Appropriateness of use to support functional role.

(4) The following are all possible:

(a) Any number of roles can be defined by any AA,

(b) The role itself and the members of a role can be

defined and administered separately by separate AAs,

(c) The privileges assigned to a given role may be placed

into one or more attribute certificates,

(d) A member of a role may be assigned only a subset of

the privileges associated with a role, if desired,

(e) Role membership may be delegated, and

(f) Roles and membership may be assigned any suitable

lifetime.

(5) An entity is assigned an attribute certificate containing

an attribute asserting that the entity occupies a certain role.

That certificate may have an extension pointing to another

attribute certificate which defines the role (that is, this role

certificate specifies the role as owner and contains a list of

privileges assigned to that role). The issuer of the attribute

certificate may be independent of the issuer of the role

certificate and these may be administered (for example, expired,

revoked, and so on) entirely separately.

(6) Not all forms of GeneralName are appropriate for use

as role names. The most useful choices are object identifiers

and distinguished names.

6.7.9 Medical Credentials:

6.7.9.1 One common type of privilege is the user credential.

These credentials are issued by a trusted authority and include

an identification string. Examples include licensing of medical

professionals by state boards and assignment of Drug Enforcement

Agency (DEA) numbers. A credential includes a type, an

issuer name, and an identifier. Geographically structured issuer

names can be useful to indicate state and other locality

information. Credentials are typically matched by type (for

example, “physician”) or type and issuer (for example, “physician

licensed in Virginia”).

6.7.9.2 If the credential issuer name is absent, then the

issuer name from the enclosing attribute or public key certificate

is used. If the certificate issuer name is absent, the

credential issuer name must be present. (Note that a certificate

may explicitly reflect more than one credential, from more than

one issuer, to minimize the number of attribute certificate

authorities (AAs) in a system.)

6.7.9.3 Considerations for use:

(1) Consider use of Practice E 2212 descriptions of the use

of noncritical X.509 fields to describe a user’s medical credentials

in an identity certificate,

(2) Consider use of medical credentials (current/

noncurrent, location of applicability) as an additional constraint

on granting authorizations to clinicians to health care

information, and

(3) Alternatively, clinician medical credentials could be

considered for inclusion as part of the security provisioning of

user attributes in a privilege management infrastructure.

6.7.10 SAML Assertions:

6.7.10.1 SAML assertions can be used to transmit security

information from an asserting party to a relying party. The


assertion can be made on behalf of a subject during authentication

or in response to a request from another SAML entity.

Assertions can be constructed from privilege or role information

stored in either a central store or from signed certificate

information.

6.7.10.2 Considerations for use:

(1) Flexibility in federated environment,

(2) Acquire additional information on claimant,

(3) Consideration on network availability and reliability,

(4) Existence of SAML service,

(5) Support for intra-enterprise assertions,

(6) Compatibility with SOAP and WS security, and

(7) Whether one needs simultaneous support for variety of

authentication mechanisms (for example, PKI Credentials,

Kerberos tokens, biometrics, and so forth).

6.8 Target Sensitivity Mechanisms—Management of target

attributes (for example, access control lists and sensitivity

labels) has traditionally been done on a per-system basis, and

there has been little standardization of the representation of this

information. This guide does not dictate how such information

is represented, but it does give suggestions based on several

document syntaxes (ASN.1 or XML).

6.8.1 Signed Data Encapsulation:

6.8.1.1 Attributes and other sensitivity information may be

bound to the digest of the target using the SignedData

construct of Specification E 2084. In particular, the use of

detached signatures (with the object conveyed separately from

the signature structure) would be appropriate. Sensitivity

information would be carried as signed attributes, with the

owner of the information being the signer.

6.8.1.2 The types of authorization information that can be

attached to a target include:

(1) Access control information (ACI), as described in

ISO 10181-3-00 and Guide E 1985,

(2) Cosignature requirements, as described in 6.9.8, and

(3) Descriptive information about the document (for example,

document type).

6.8.2 Use of XML:

6.8.2.1 Extensible Markup Language (XML) provides a

software- and hardware-independent tool for transmitting information.

It is expected that many documents will be expressed

using XML. The structure for such a document is

defined in a document-type definition (DTD) or an XML

schema.

6.8.2.2 Privileges may be defined as XML elements in

which the name of the element represents the privilege

identifier. Alternatively, an XML element can be associated

with one or more XML attributes that represent the privilege

identifier(s).

6.8.2.3 Privileges can be grouped into useful sets using

XML. For example, a set of privileges encoded into XML can

be associated with a uniform resource identifier (URI) such as:

“urn:application_name:attribute:privilege_set_name”

6.8.2.4 Alternatively, privilege sets can be associated within

a schema definition addressed by a unique namespace such as:

xmlns: privilege_set_name=“http://www.astm.org/:privilege_sets/

privilege_set_name/”

6.8.2.5 XML privilege sets can be used by the verifier to

associate the claimant to its scope of authority. Claimants can

be associated with standard groups or roles before evaluation

by the verifier. Alternatively, the verifier can associate the

claimant to one or more privilege sets through a database or an

LDAP-enabled directory service. The verifier can also look up

the requestor group or role association in an external XML

document using XPath.

6.8.2.6 A verifier using a privilege policy may act directly

on the XML elements (for example, by comparing attributes in

an authorization certificate to elements in the document). One

example of an XML-based policy that can be used to verify

privileges is the eXtensible Access Control Markup Language

(XACML). The following sections discuss the comparison

rules in detail. Generally, single-valued attributes will be

compared to a single (complete) element, while multi-valued

attributes will be compared to a collection of elements in a

model group.

6.8.3 Access Control Framework:

6.8.3.1 This section defines an access control information

(ACI) attribute that can be used to indicate to a recipient (or

trusted third party) which entities may read the target’s

contents.

6.8.3.2 Access is allowed to the target if the requester

matches an entry in the proper list (by name, role, group, or

organizational unit) and if the requester’s attribute certificate

matches all of the constraints contained in the target’s ACI

attribute. The constraints associated with the requester’s attribute

certificate would be contained in the Constraints

attribute in the requester’s certificate.

6.9 Policy Specification Mechanisms:

6.9.1 Although this guide does not dictate how privilege

policies are represented within an end system, XACML provides

a standard approach to authorization policies. Several

scenarios are evident.

6.9.2 Two entities may need to determine whether their

authorization policies are compatible, especially in a web

services environment (NIST Special Publication 800-95). If

their policies are compatible, the entities need to determine

specific policy variable values that are acceptable to both. In

this case, an XACMLAuthzAssertion, defined in the

“XACML Profile for Web Services (WS-XACML)” may be

used. Such an assertion may be included in a WS-policy

instance or provided as independent metadata.

6.9.3 An XACMLAuthzAssertion may also be used in a

web services environment by a service provider to publish an

authorization policy for retrieval by potential clients. Publishing

authorization policies is not appropriate for all environments,

but publishing certain aspects of an authorization policy

may be useful even where publication of an entire policy would

be a security problem.

6.9.4 Transferring XACML Policies:

6.9.4.1 Policies may need to be transferred from one entity

to another in a PMI. Some of the situations in which this is

required are:

(1) A PDP evaluates a policy that references other policies

by name. The other policies shall be fetched from a policy

administration point (PAP) when required for evaluation.


(2) A PDP may need to obtain its “root” policy from the

enterprise policy administration point as part of configuration.

(3) A resource may be transferred between security domains,

and the source domain may transfer a policy for

protection of the resource that the destination domain is

responsible for enforcing.

(4) Multiple sites may need to use common policies, even

though their PDPs are local for performance reasons. These

policies need to be transferred from the central PAP to each

site’s PDP.

6.9.4.2 While XACML defines a policy language, it is

designed to be one component in an overall authorization

system. It relies on other components to provide mechanisms

for verifying that policy instances were issued by a trusted PAP,

for protecting the integrity and confidentiality of instances of

policies, and for protocols used to query for and respond with

policy instances. XACML has been integrated with the OASIS

Security Assertion Markup Language (SAML) Version 2.0 as

one way of providing these necessary functions. SAML may be

used with XACML to protect ACI attributes as well as policies.

Fig. 12 illustrates the integration of SAML and XACML.

6.9.4.3 As shown in Fig. 12, when the enforcement point

requires an authorization decision, a request is made of the

PDP (1). The PDP evaluates the request against its available

policies and attributes and produces an authorization decision

(2) that is returned to the PEP. The PEP may obtain attributes

from on-line AAs (3) or from attribute repositories (4) into

which AAs have previously stored attributes (5). The PDP may

obtain attributes from on-line AAs (6) or from attribute

repositories (7).

6.9.4.4 The authorization decision of the PDP is based on

policies returned from the PAP (8) or retrieved from the on-line

policy repository (9). The policy repository serves as a cache of

policies previously stored by a PAP (10).

6.9.4.5 The XACMLPolicyQuery is an SAML query defined

in this profile that may be used to request policies from

a PAP, either by name or by applicability to a certain request.

A corresponding XACMLPolicyStatement is returned in an

SAML response. The XACMLPolicyStatement may be digitally

signed and may be associated with issuer and validity

period information, among other things.

6.9.5 Credential Matching:

6.9.5.1 The credential attribute was defined in 5.4. This is

issued by a trusted authority and includes an identification

string. Examples include licensing of medical professionals by

state boards and assignment of DEA numbers. A credential

includes a type, an issuer name, and an identifier.

6.9.5.2 To match a credential policy, the claimant’s certificates

shall, in combination, contain a matching credential for

each entry in the credential list. To match an entry, the

credential shall have the same credential type, and, if the entry

has an issuer name, the credential (or enclosing certificate)

shall have the same issuer name.

6.9.6 Security Label Matching—Security label matching

compares the initiator’s clearance to the target’s security label.

All of the following must be true for authorization to be

granted:

6.9.6.1 The security policy identifiers shall be identical,

6.9.6.2 The classification level of the initiator shall be

greater than or equal to that of the target (that is, there shall be



at least one value in the classification list of the clearance

greater than or equal to the classification of the target), and

6.9.6.3 For each security category in the target label, there

shall be a security category of the same type in the initiator’s

clearance and the initiator’s classification level shall dominate

that of the target.

6.9.7 General Assertion Matching:

6.9.7.1 A privilege policy consists of one of the following:

(1) ppPredicate—an assertion about a specific attribute;

(2) and relation—a list of constituent policies, all of which

shall be true for this policy to be true;

(3) or relation—a list of simpler policies, at least one of

which shall be true for this policy to be true;

(4) not function—a single policy, which shall be false for

this policy to be true; or

(5) orderedPPE—a list of simpler policies, which are

verified in the order specified.

6.9.7.2 Predicates may be:

(1) single value assertion—a single attribute value in a

target document (or context variable) is compared to an

attribute value in the assertion;

(2) set value assertion—the entire set of attribute values in

a target document (or context variable) is compared to the set

of values in the assertion;

(3) present—the attribute shall be present in the document;

(4) approximateMatch—the asserted value(s) match the

value(s) in the document, using some locally defined matching

algorithms (for example, phonetic matches or approximate

arithmetic matches); or

(5) extensibleMatch—the asserted value(s) match the value(

s) in the document using a matching rule defined using the

X.500 MATCHING-RULE macro.

6.9.7.3 Single value assertions allow authorization based on

a simple value comparison. For example, lessOrEqual might

restrict the signer to some monetary limit. The semantics of

each choice are:

(1) equality—The value in the document shall be equal to

that in the assertion. This assertion can be used with any

attribute type; complex attributes are compared using the DER

encodings of their values.

(2) substrings—The value of the document attribute shall

contain the asserted substrings in the specified order; the initial

substring of the value shall match the initial component of the

assertion (if present), the any components (if present) shall

appear in the value in the specified order, and the final

substring of the value shall match the final component of the

assertion (if present). The substrings shall not overlap in the

document attribute. This assertion can be used with any ASN.1

string type (for example, IA5 string, UTF8 string, and so forth).

(3) greaterOrEqual—The value in the document shall be

greater than or equal to that in the assertion. This assertion may

be used with integers, enumerateds, and octet strings.

(4) lessOrEqual—The value in the document shall be less

than or equal to that in the assertion. This assertion may be

used with integers, enumerateds, and octet strings.

(5) subordinate—The asserted value matches the leading

components of the value in the document attribute; it is only

valid for object identifiers and names (a sequence of relative

distinguished names).

6.9.7.4 Set valued assertions involve all values of an attribute

that are found in a target. For example, the standard

military compartment mechanism would dictate that the set of

compartments attached to a document shall be a subsetOf

those in the signer’s certificate. Similarly, a need-to-know

mechanism would use a nonNullIntersection assertion. These

attributes will be of type SEQUENCE OF or SET OF. The

semantics are:

(1) subsetOf—all attribute values in the document shall

appear in the assertion;

(2) supersetOf—all attribute values in the assertion shall

appear in the document; and

(3) nonNullIntersection—at least one attribute value in the

document shall appear in the assertion.

6.9.7.5 A predicate may contain the specific attribute values

to be compared against the target, or it may reference an

attribute in the claimant’s attribute certificate, which holds the

value to be compared against the target. In the second case, the

PrivilegeIDPair contains two attribute types; the first refers to

the target, and the second refers to the claimant.

6.9.7.6 Multiple-target attribute syntaxes are supported.

Currently, these include ASN.1 and XML. Since claimant

privileges are carried as ASN.1 attributes, an attribute type is

required in a privilege ID; an XML link is optional (to indicate

the corresponding content in the target XML document). The

link is structured as defined in the XLink, XPointer, and XPath

recommendations, with the additional constraint that it shall

reference one or more entire, contiguous XML elements (or

their attributes).

6.9.7.7 Mapping between standard ASN.1 types and XML

elements is done as follows (where possible, this maps to

ongoing work on XML schemas):

(1) An ASN.1 Boolean maps to an XML element content or

attribute with the following (case-insensitive) values: For

TRUE: true, yes, or 1. For FALSE: false, no, or 0. Only

equality matching is allowed.

(2) An ASN.1 integer maps to an XML element content or

attribute consisting of solely numeric characters, with an

optional sign character (+ or –) in front.

(3) An ASN.1 real maps to an XML element or attribute

which uses the ASN.1 value notation for a real number.

(4) ASN.1 bit strings and octet strings map to any XML

element content (#PCDATA). As the XML schema work

evolves, this should map to an XMLbinary object; such objects

may be encoded in base64 for transport, with the encoding

indicated either in the schema or as an attribute of the element.

(5) ASN.1 enumerated map to XML attributes of type

NMTOKENS (a list of strings) in which each string is the

identifier of one of the enumerated values.

6.9.7.8 AAs should ensure that policies are internally consistent

(for example, the same attribute type should not appear

in two logically contradictory clauses). Policies should be

signed by an AA; they may be conveyed in a claimant’s

authorization certificate or as separate objects.


6.9.8 Signature Requirements:

6.9.8.1 Multiple signatures may be conveyed as multiple

SignerInfo structures in a SignedData instance. Countersignatures

may be attached using the (unsigned) countersignature

attribute. Signature requirements are conveyed as a

privilege policy associated with a particular target and operation.

6.9.8.2 Each cosigner entry contains either the identity of a

cosigner (a role or an individual name or certificate identifier)

or a list of required signature purposes or both. If a role is

present, there shall be a signature on the document using that

role (as a signature attribute), and the signer shall be allowed to

act in the role (as indicated in the role attribute in the signer’s

authorization certificate). If a signer’s name is present, there

shall be a signature on the document that can be verified using

one of that user’s certificates. If a particular certificate is

identified (by name and key ID or by issuer name and serial

number), there shall be a signature on the document that can be

verified using the specified certificate. If a list of signature

purposes is specified, there shall be a signature on the document

using one of the purposes (in the signaturePurpose

signature attribute). If both a signer ID and signature purpose(

s) are present, the specified signer shall use one of the

listed purposes.

6.9.8.3 Each cosigner may optionally be assigned a weight

to allow a varying number of signers. The quorum specifies the

total weight required for the cosigner list to be ratified. In the

common case in which all weights are one, the quorum is

simply the number of cosigners needed. By assigning weights,

however, one could construct a scheme in which (for example)

the signature of the president, any two vice presidents, or any

four directors is required for authorization. A quorum of zero

indicates all list members shall sign the document. A particular

placement of the cosignature (joint signature on the document

or countersignature) (2) may be required.

6.10 Integration with PKI:

6.10.1 The PMI relies could be designed to rely on a public

key infrastructure (PKI) for identity certificates. These certificates

are used to authenticate the owner of an attribute

certificate to the verifier (using digital signatures). Each attribute

certificate references either the name or (more frequently)

an identity certificate of its owner. This decoupling of

the PKI and PMI provides several advantages already described.

6.10.2 Attribute certificates are issued by attribute authorities

(AAs). These AAs may be arranged in a hierarchy, similar

to a CA hierarchy. While identity certificates are requested by

the subscriber, issuance of attribute certificates may be unsolicited.

This would be the case in which the subscriber does not

control his privileges.

6.10.3 Revocation of attribute certificates is done in the

same way as identity certificates, (that is, using revocation

lists). Alternatively, online protocols like online certificate

status protocol (OCSP) may be used. However, there is

typically no need for the user to possess their AC physically.

Therefore, attribute certificates can be stored in a directory

service and simply updated whenever the contents of the

attribute certificate are outdated. In this model, certificate

revocation is not needed, since access to the attribute certificates

storage function provides the most current attribute

certificates for the user.

6.10.4 Two types of delegation may be used in a PMI:

6.10.4.1 AAs delegate their own authority to subordinate

AAs and end users. Thus, authority increases as one ascends

the AA hierarchy. Delegation checks are done on the AA

certificates.

6.10.4.2 Users request that their authorizations be delegated,

and the AA issues the certificate after performing

delegation checks on the delegator’s certificate. The delegation

hierarchy can be reconstructed using the delegatorAttributeIdentifier

extension in the attribute certificates.

6.10.5 Integration of the PMI with an existing PKI is

discussed further in ISO 9594-8 X.509.

6.11 Identity Management Systems:

6.11.1 Several functional areas within the PMI require a

secure identity management subsystem (IdM). IdM is responsible

for securely providing identity information and identity

management functions. Identity management functions include:

6.11.1.1 Administration functions (user provisioning, password

management),

6.11.1.2 Identity data control functions (metadata, identity

content),

6.11.1.3 Access (authenticate requests, confidentiality),

6.11.1.4 Lifecycle management (configuration, patches, disaster

recovery), and

6.11.1.5 Backup, audit, logging, and reporting functions.

6.11.2 IdM shall provide a secure access mechanism for the

request and delivery of identity information, typically using

mutual authentication. Access to the IdM can be viewed as a

service accessible throughout an enterprise. Organizationally,

the IdM subsystem can be deployed in various ways:

6.11.2.1 Authoritative source integral to PMI security

framework,

6.11.2.2 An administrative function available to the PMI as

needed, and

6.11.2.3 Integral to a special purpose IdM product solution.

6.11.3 Having an IdM as a service provides several advantages

over a local special-purpose IdM. By their nature, IdM

services provide a network interface using standard protocols

that provide flexibility in changes to enterprise architecture. An

IdM service can be centrally managed, allowing consistent

enforcement of security and business policies.

6.12 Audit:

6.12.1 The major purpose of the audit subsystem is to

provide accountability of actions taken by agents on the

network. Audit is not instrumental in the use of privileges to

allow or disallow access to protected resources. However, the

audit subsystem should interface with the PMI so that its

correct operation can be verified. For a discussion of the use of

audit in healthcare applications, see RFC 3881.

6.12.2 Accountability is the concept that individual persons

or entities can be held responsible for specified actions, such as

obtaining informed consent or breaching confidentiality (18).

Accountability is achieved through the implementation of a

pervasive technical audit service. Audit provides a record of

E 2595 – 07

27

potential insecurities irrefutably traceable back to the originator

of the action. Security audit provides not only accountability,

but a means to assess damage done to a system by

malicious action or accident. Security audit generated by the

actions of other security services provides a check on their

proper operation. In a distributed system, centralized audit

collection and processing also provides a method to obtain

near-real-time misuse detection and alerts.

6.12.3 A security audit trail provides a journal of security

related events collected for potential use in intrusion detection

or security audits or both. Audit is a pervasive function of the

healthcare system providing essential accountability features.

Audit also provides assurance of the correct operation of the

system’s security features by monitoring user and system

access to data and resources. Audit is generated as a by-product

of the security controls in place: authentication, access, and

authorization (privileging) and upon occurrence of specific

security relevant events (for example, modifying a file). Audit

acts as a deterrent to (unauthorized) user activities, and as such,

users should know that their actions are being monitored

(usually part of a log-on banner). Audit also provides a means

to assess the degree of harm caused should a break-in occur.

6.12.4 In a distributed architecture involving diverse commercial

off-the-shelf (COTS) products, each product produces

audit trails in a proprietary format. Even the events recorded

may be different from product to product (for example, use of

“grant” option makes sense in a database but not in an

operating system). System audit trails may be character-based

or binary. COTS audit trails often require specialized audit

tools for review and processing. Audit trails may be stored in

the file system or in database tables and so forth. Auditanalyzing

systems shall be able to harmonize and account for

these differences.

6.12.5 In distributed systems, audit is produced at multiple

locations on multiple components, making review and analysis

difficult. Accordingly, in such a system, it is very desirable to

consolidate and forward low-level audit from various auditproducing

sources to a central audit server. There the audit can

be reformatted to a single-composite format and automatically

processed by a tool. Several such COTS tools are available,

providing for a distributed audit capability for collecting,

forwarding, processing, and reporting audit events originating

from diverse sources. Since the amount of audit produced may

be considerable, a single centralized audit server is a practical

way to manage workflow without affecting the response time

of operational systems. Audit processing may be both real time

and batch.

6.12.6 An automated audit tool provides the means of

identifying events at different levels of security, performing

automatic profiling, reporting and alerting, and a facility to

store, sort, and search for potential insecurities. Automated

tools manage audit collection across host- and network-based

audit systems. The placement of the audit tool, agents, and

components (including real-time network monitoring and intrusion

detection) is considered to maximize the effectiveness

of the audit system.

6.12.7 Audit records are reviewed by examination of the

audit trail. Consolidation of audit records when more than one

source is involved at a central “audit server” facilitates review

by providing an automated means to examine the (typically)

large amount of audit generated from these events. Continuous

monitoring of audit records should be a part of the operation

phase of the system development life cycle (19).

6.12.8 The security architecture should support the establishment

of auditing capabilities on an application, facility, or

national basis. To meet the requirement for a persistent

retention capability, the audit function will include long-term

archival and storage facilities. Archival and storage requirements

specify the minimum length of time for which the

archive shall be retained. Organizations should establish policies

and procedures for log management consistent with

accepted standards (20).

6.12.9 Patient consent can act as the trigger of this audit

record. Collection of disclosures made under this requirement

requires that the audit configuration for this event be “mandatory.”

The security architecture supports the centralized collection,

processing, and reporting of disclosures of patient information.

Storage of events recording certain disclosure under

the provisions of the privacy act may require a longer period of

storage than simple security audit.

6.12.10 Intrusion detection systems should be an integral

part of the distributed architecture. Commercially available

intrusion detection systems provide alarm capabilities to permit

rapid notification of specified intrusions. Intrusions can be

categorized into two main classes, misuse and anomaly intrusions.

Misuse intrusions are well-defined attacks on known

weak points of a system. They can be detected by watching for

certain actions being performed on certain objects. Anomaly

intrusions are based on observations of deviations from normal

system usage patterns. They are detected by building up a

profile of the system being monitored and detecting significant

deviations from this profile.

6.12.11 Adherence to industry standards facilitates a robust

audit subsystem. Industry standards groups, such as Integrating

the Healthcare Enterprise (IHE) publish profiles that describe

how to use established standards to share healthcare information

better in the clinical setting. IHE has published the Audit

Trail and Node Authentication (ATNA) Integration Profile that

describes security measures that, together with the security

policy and procedures, provide patient information confidentiality,

data integrity, and user accountability (21). The IHE

ATNA profile is consistent with Dicom Supplement 95: Audit

Trail Messages (22).

7. Example Applications

7.1 This section presents some example applications using

the mechanisms defined in Section 6. These are not presented

in great detail. Specific applications will be the topics of future

standards or proprietary specifications. These examples are

meant to illustrate the use of privilege management mechanisms

to support the types of applications discussed in Guide

E 1762, Guide E 1986, and Specification E 2084, as well as

current work in the area of certificate policies and extensions.

7.2 Credentials Application:

7.2.1 In this application, a physician is prescribing controlled

substances. The prescription is electronically signed and

sent to the pharmacy using secure/multipurpose internet mail

E 2595 – 07

28

extensions (S/MIME). The pharmacist shall ensure, since the

prescription is for a controlled substance, that the physician has

a valid DEA number. This would be provided with a credential

in either the physician’s identification (ID) certificate or

attribute certificate. The credential type would be “DEA

number” and the issuer would be the DEA.

7.2.2 Similar mechanisms can be used to prove that an

individual is a physician (credential type of “medical license”).

This can be restricted to a particular state by examining the

credential issuer. Note that, by using distinguished names,

conventions for issuers can be established at the state level,

federal (agency) level, and using Federal Information Processing

Standards (FIPS) PUB 66 at the county level.

7.3 Access Control:

7.3.1 This application allows a verifier to control access to

a target (in this case, some portion of the patient’s medical

record) based on the target’s attributes. In this example, the

claimant’s role and constraints are found in his attribute

certificate. The following constraints are used:

7.3.1.1 Plan registration, and

7.3.1.2 Department.

7.3.2 The attribute certificate for the claimant contains one

or more roles, as well as a list of plan registrations and

departments with which the claimant is associated. Separate

role certificates (with attributes specific to the role) are not used

in this application.

7.3.3 The target’s access control information is represented

using the ACI attribute defined in Specification E 2084.

7.3.4 For access to be allowed to the target for this claimant:

7.3.4.1 At least one of the claimant’s roles shall appear in

the target’s access control list,

7.3.4.2 At least one of the claimant’s plan registrations shall

appear in the target’s constraints, and

7.3.4.3 At least one of the claimant’s departments shall

appear in the target’s constraints.

7.4 Signature Requirements:

7.4.1 This application builds on the signature purpose

mechanism defined in Guide E 1762 and Specification E 2084.

For a document to be accepted as part of the medical record, it

shall have one or more signatures, as specified in the privilege

policy. For example, the policy might require a signature by the

author or by a transcriptionist and a reviewer.

7.4.2 Each signer has an attribute certificate indicating

which signature purposes he may exercise. When signing a

document, the signature purpose is included as a signed

attribute (see Specification E 2084). The policy is represented

using the SignatureRequirements syntax defined in 7.4.1.

7.4.3 The verifier will:

7.4.3.1 Check the attribute certificate of each signer to

ensure the signature purpose is allowed, and

7.4.3.2 Ensure that all necessary signatures are present, as

required by the privilege policy.

7.5 Document Authorization:

7.5.1 This application builds on the mechanisms and attributes

defined in ANSI X9.45 and Specification E 2084.

7.5.2 Claimant privileges are conveyed in authorization

certificates. Claimants may also exercise multiple roles (although

only one at a time) through the use of role certificates.

The claimant’s authorization certificate will contain an allowableRoles

attribute indicating the roles the user may exercise.

7.5.3 Target attributes may be extracted from the document

(for example, as XML elements), held in a local database, or

may be embedded in a SignedData structure (detached signature).

This structure is linked to the target object by the object’s

digest.

7.5.4 The privilege policy consists of signature requirements

and a general assertion policy as defined in 7.3.

7.5.5 The verifier will use the authorization certificate of the

claimant, along with associated role certificates, and the target

attributes, as input to the general assertion policy in 7.3. If this

policy is satisfied, signature requirements are checked. The

current signature structure (containing one or more signatures

on the document, as well as possibly countersignatures) is

matched against the signature requirements policy. If these are

also satisfied, the document is considered authorized.

7.5.6 Specific attributes to be included in the authorization

certificate include:

7.5.6.1 Restrictions on documents that may be signed (see

the document attribute list in 7.5.7),

7.5.6.2 Allowable roles, and

7.5.6.3 Allowable signature purposes.

7.5.7 Attributes associated with the document (mostly from

Specification E 2084) include:

7.5.7.1 Document type,

7.5.7.2 Location,

7.5.7.3 Patient ID,

7.5.7.4 Event ID,

7.5.7.5 Amendment information (pointer to document being

amended),

7.5.7.6 Data type and format information,

7.5.7.7 Originating organization,

7.5.7.8 Event time,

7.5.7.9 Document creation, modification, and access times,

7.5.7.10 Monetary value,

7.5.7.11 Document identifier,

7.5.7.12 Category list, and

7.5.7.13 Owner and author information (which may also be

derived from the signatures on the document).

7.5.8 Signed attributes that may be attached to the document

include:

7.5.8.1 Signing time,

7.5.8.2 Signature purpose,

7.5.8.3 Role being exercised,

7.5.8.4 Signing certificate and policy ID,

7.5.8.5 Signature reason (textual description),

7.5.8.6 Annotations, and

7.5.8.7 Device identifier of signing cryptographic module.

7.5.9 A countersignature is conveyed as an unsigned attribute

that signs the signature value in the SignerInfo structure

that contains it.

8. Keywords

8.1 access control; delegation; healthcare environment;

PMI; privilege management infrastructure; security

E 2595 – 07

29

REFERENCES

(1) Chadwick, et al, “Role-Based Access Control with X.509 Attribute

Certificates,” IEEE Internet Computing, 2003, pp. 62-69.

(2) Fischer, A., “Electronic Document Authorization,” Proceedings of the

13th National Computer Security Conference, 1990.

(3) Person-Centered Health Records Toward HealthePeople, J. Demetriades,

G. Christopherson, and R. Kolodner, Eds., Spring 2005, pp.

147-168.

(4) Rust, G., “Metadata: The Right Approach—An Integrated Model for

Descriptive and Rights Metadata in E-Commerce,” D-Lib Magazine,

July/Aug. 1998.

(5) Arms, W., “Implementing Policies for Access Management,” D-Lib

Magazine, Feb. 1998.

(6) Welch, V., Foster, I., Kesselman, C., Mulmo, O., Pearlman, L., et al,

“X.509 Proxy Certificates for Dynamic Delegation,” 3rd Annual PKI

R&D Workshop, 2004.

(7) Castano, S., Fugini, M., Martella, G., and Samarati, P., Database

Security, Addison—Wesley Publishing Company, Wokingham, MA,

1995.

(8) Dawson, et al, “A New Design of Privilege Management Infrastructure

for Organizations Using Outsourced PKI,” ISC 2002, LNCS 2433,

2002, pp. 136-149.

(9) Sandhu, R. S., Coyne, E. J., Feinstein, H. L., and Youman, C. E.,

“Role-Based Access Control Models,” IEEE Computer, Vol 29, No 2,

1996, pp. 38-47.

(10) Buecher, et al, Understanding SOA Security Design and Implementation,

IBM Redbook Series, SG24-7310-00, 2007.

(11) “Assessment of Access Control Systems,” Interagency Report 7316

(NISTIR 7316), National Institute of Standards and Technology, Sept.

2006.

(12) Blobel, B., Analysis, Design and Implementation of Secure and

Interoperable Distributed Health Information Systems, IOS Press,

2002.

(13) Neumann, G. and Strembeck, M., “A Scenario-Driven Role Engineering

Process for Functional RBAC Roles,” June 2002.

(14) Juric, M. B., “Comparison of Performance of Web Services, WSSecurity,

RMI, and RMI-SSL,” Journal of Systems and Software 79,

May 2006, pp. 689-700.

(15) Bolie, et al, BPEL Cookbook: Best Practices for SOA-Based Integration

and Composite Applications Development, Pack Publishing,

2006.

(16) Kirschner, B. A., Hacker, T. J., Adamson, W. A., and Athey, B. D.,

“Walden: A Scalable Solution for Grid Account Management,” Fifth

IEEE/ACM International Workshop on Grid Computing (GRID’04),

2004, pp. 102-109.

(17) Stowe, G., “A Secure Network Node Approach to the Policy Decision

Point in Distributed Access Control,” Thesis, Tech Report TR2004-

502, Dartmouth College Department of Computer Science, 2004.

(18) National Research Council, Computers at Risk: Safe Computing in

the Information Age, National Academy Press, Washington, DC,

1991.

(19) Bowen, P., Hash, J., andWilson, M., Information Security Handbook:

A Guide for Managers, NIST Special Publication 800-100, NIST

Computer Security Division, Gaithersburg, MD, Oct. 2006.

(20) Kent, et al, Guide to Computer Security Log Management, NIST

Special Publication 800-92, NIST Computer Security Division,

Gaithersburg, MD, Sept. 2006.

(21) “IHE IT Infrastructure Technical Framework, Vol 1 (ITI TF-1)

Integration Profiles,” Revision 3.0, ACC/HIMSS/RSNA, 2006, p. 55.

(22) “Digital Imaging and Communications in Medicine (DICOM)

Supplement 95: Audit Trail Messages,” Trial Standard, 2004.

(23) Damianou, N., et al, “A Language for Specifying Security and

Management Policies for Distributed Systems,” The Language Specification,

Version 2.3, Imperial College Research Report DoC 2000/1,

2000.

BIBLIOGRAPHY

(1) Kearney, et al, “An Overview of Web Services Security,” BT

Technology Journal, Vol 22, No 1, 2004, pp. 27-42.

(2) Glossary of Key Information Security Terms, Kissel, Ed., April 25,

2006.

ASTM International takes no position respecting the validity of any patent rights asserted in connection with any item mentioned

in this standard. Users of this standard are expressly advised that determination of the validity of any such patent rights, and the risk

of infringement of such rights, are entirely their own responsibility.

This standard is subject to revision at any time by the responsible technical committee and must be reviewed every five years and

if not revised, either reapproved or withdrawn. Your comments are invited either for revision of this standard or for additional standards

and should be addressed to ASTM International Headquarters. Your comments will receive careful consideration at a meeting of the

responsible technical committee, which you may attend. If you feel that your comments have not received a fair hearing you should

make your views known to the ASTM Committee on Standards, at the address shown below.

This standard is copyrighted by ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959,

United States. Individual reprints (single or multiple copies) of this standard may be obtained by contacting ASTM at the above

address or at 610-832-9585 (phone), 610-832-9555 (fax), or service@astm.org (e-mail); or through the ASTM website

(www.astm.org).

6.1.5 Contextual ACI:

(1) Time periods,

(2) Route (an access may be granted only if the route being

used to specific characteristics),

(3) Location (and access may be granted only two initiators

as specific in-systems, workstations are terminals, or only two

initiators any specific physical location),

(4) System status (and access may be granted only for a

particular ACI when the system has a particular status, for

example during a disaster recovery),

(5) Strength of authentication (an access may only be

granted when authentication mechanisms of at least a given

strength are used), and

(6) Other access currently active for this or other initiators.

6.3.7.3 On the right half of the figure, users granted structural

roles are permitted to participate in work profiles that

contextually allow access to specific enterprise applications/

databases. In a client-server context, this amounts to an

authorization to establish a session. In a distributed security

service scenario, this access control decision is made at the

network level.

  • No labels