Appendix K: XDS Security Environment

This Appendix expands on the summary provided in the XDS Profile ( ITI TF-1: 10.8 ).

The XDS operations assume that a suitable security and privacy environment has been established. Almost all of the relevant threats will be managed by agreements, policies, and technologies that are external to the XDS transactions. The few that affect the XDS transactions will be managed by generic security mechanisms that are not unique to XDS. The threats and security objectives that must be addressed are described in Sections K.1 and K.2 below. Only a few of these have issues that are unique to the XDS application.

Section K.3 discusses these few threats and objectives in terms of the agreements and policies that need to be established to create a suitable environment for XDS. Establishing these agreements often involves business agreement discussions that are part of establishing the XDS Affinity Domain. These agreements are necessary because the exchange of documents implies agreeing to the delegation of responsibility for maintaining the security of these documents and for providing the necessary audit and record keeping facilities.

K.1 Security Environment

K.1.1 Threats

Specific threats to the overall XDS system are listed below. These threats are identified using the Common Criteria nomenclature defined by ISO 17799. Most of these are mitigated by policies, procedures, and technologies that are not unique to XDS and do not require any special XDS considerations. Many of these mitigations do require that the parties within the XDS Affinity Domain have agreement on details of how they will work together.

T.ADMIN_ERROR Improper administration may result in defeat of specific security features.

T.ADMIN_ROGUE Authorized administrator’s intentions may become malicious resulting in TSF data to be compromised.

T.AUDIT_CORRUPT A malicious process or user may cause audit records to be lost or modified, or prevent future records from being recorded by taking actions to exhaust audit storage capacity, thus masking an attacker’s actions.

T.CONFIG_CORRUPT A malicious process or user may cause configuration data or other trusted data to be lost or modified.

T.DISASTER System or network may failure due to disaster (e.g., fire, earthquake).

T.DOS A malicious process or user may block others from system resources via a resource exhaustion denial of service attack.

T.EAVESDROP A malicious process or user may intercept transmitted data inside or outside of the enclave. Some of the XDS environments are not concerned with eavesdrop exposure. They may employ external protective mechanisms such as physical network security or VPNs to protect against eavesdropping.

T.HARDWARE Hardware may malfunction.

T.IMPROPER_INSTALLATION XDS components may be delivered, installed, or configured in a manner that undermines security.

T.INSECURE_START Reboot may result in insecure state of the operating system.

T.INTRUSION Malicious software (e.g., virus) may be introduced into the system.

T.MASQUERADE A malicious process or user on one machine on the network may masquerade as an entity on another machine on the same network.

T.OBJECTS_NOT_CLEAN Systems may not adequately remove the data from objects between usage by different users, thereby releasing information to a user unauthorized for the data. This also includes swapping hard disk with PHI during service and repair.

T.POOR_DESIGN Unintentional or intentional errors in requirement specification, design or development of the TOE components may occur.

T.POOR_IMPLEMENTATION Unintentional or intentional errors in implementing the design of the XDS environment may occur.

T.POOR_TEST Incorrect system behavior may result from inability to demonstrate that all functions and interactions within the XDS operation are correct.

T.REPLAY A malicious process or user may gain access by replaying authentication (or other) information.

T.SPOOFING A hostile entity may masquerade itself as part of the XDS Affinity Domain and communicate with authorized users who incorrectly believe they are communicating with authorized members.

T.SYSACC A malicious process or user may gain unauthorized access to the administrator account, or that of other trusted personnel.

T.UNATTENDED_SESSION A malicious process or user may gain unauthorized access to an unattended session.

T.UNAUTH_ACCESS Unauthorized access to data by a user may occur. This includes access via direct user interaction with the device, access via network transactions, and access via removable electronic and printed media.

T.UNAUTH_MODIFICATION Unauthorized modification or use of XDS attributes and resources may occur.

T.UNDETECTED_ACTIONS Failure of the XDS components to detect and record unauthorized actions may occur.

T.UNIDENTIFIED_ACTIONS Failure of the administrator to identify and act upon unauthorized actions may occur.

T.UNKNOWN_STATE Upon failure of XDS components, the security of the XDS environment may be unknown.

T.USER_CORRUPT User data may be lost or tampered with by other users.

K.1.2 Security and Privacy Policy

There are a wide variety of security and privacy regulations established by law and regulation. These are interpreted and extended to create individual enterprise policies. This equipment will be installed into a variety of enterprises that are subject to a variety of laws and regulations. The XDS environment will provide support for the common aspects of these enterprise policies. The policy statements whose enforcement must be provided by the XDS security mechanisms are:

P.ACCOUNT The users of the system shall be held accountable for their actions within the system.

P.AUTHORIZATION The system must limit the extent of each user’s abilities in accordance with the TSPP. (See P.PATIENT_CARE.)

P.AUTHORIZED_USERS Only those users who have been authorized to access the information within the system may access the system. (See P.PATIENT_CARE.)

P.CRYPTOGRAPHY The system shall use standard approved cryptography (methods and implementations) for key management (i.e., generation, access, distribution, destruction, handling, and storage of keys) and cryptographic services (i.e., encryption, decryption, signature, hashing, key exchange, and random number generation services).

P.DECLARATIVE_SECURITY The system shall allow the administrator to define security related rules. Examples include defining access control policies and password expiration restriction.

P.I_AND_A All users must be identified and authenticated prior to accessing any controlled resources with the exception of public objects.

P.OBJECTAUTHORIZATION The XDS components must enforce the policy regarding how authorization is established for protected objects. The policy determines how access control and other policies are enforced. (This is often considered part of P.Authorization, but in the XDS context it may make sense to consider this as a separate policy.)

P.PATIENT_CARE The security and privacy measures should not prevent patient care. In particular, there should be emergency bypass mechanisms to override security when necessary to provide patient care.

P.SYSTEM_INTEGRITY The system must have the ability to periodically validate its correct operation and, with the help of Administrators, Backup and Restore Operators, and Service Personnel, it must be able to recover from any errors that are detected.

P.TRACE The primary method for enforcing the security and privacy policy is the use of auditing. The XDS components must have the ability to review the actions of individuals. The XDS environment must provide sufficient audit information to external audit and monitoring systems to permit the review of actions of individuals by that other system.

P.TRUSTED_RECOVERY Procedures and/or mechanisms shall be provided to assure that, after a system failure or other discontinuity, recovery without a protection compromise is obtained

P.VULNERABILITY_SEARCH The XDS environment must undergo an analysis for vulnerabilities beyond those that are obvious.

K.1.3 Security Usage Assumptions

Assumptions of the use of the XDS environment:

A.PHYSICAL It is assumed that appropriate physical security is provided within the domain for the value of the IT assets and the value of the stored, processed, and transmitted information.

A. AUDIT_REVIEW It is assumed that there will be audit repository and review services provided that can accept audit information from the XDS components in real time.

A.OPERATION It is assumed that networks, firewalls, etc. are deployed and maintained to meet appropriate network security levels.

A.PERSONNEL It is assumed that the organization can assure IT user & other workforce personal integrity/trustworthiness.

A.PKI It is assumed that there will be a facility to provide signed certificates as needed for node and user authentication. The key management maybe done manually or automatically depending on the availability of appropriate technology.

K.2 Security Objectives

This section defines the security objectives for the XDS environment. These objectives are suitable to counter all identified threats and cover all identified organizational security policies and assumptions. Common Criteria nomenclature is used. The XDS component security objectives are identified with “O.” appended to at the beginning of the name and the environment objectives are identified with “OE.” appended to the beginning of the name.

K.2.1 XDS Component Security Objectives

O.ACCESS The XDS components will ensure that users gain only authorized access to it and to the resources that it controls. (See O.EMERGENCY_BYPASS.)

O.ACCESS_HISTORY The XDS components will display information (to authorized users) related to previous attempts to establish a session.

O.ADMIN_ROLE The XDS components will provide separate administrator roles to isolate administrative actions. These include a General Administrator role, a Backup and Restore Operator role, a Cryptographic Administrator role, and a Service Personnel role. Additional roles can be defined. These roles are collectively called Administrators.

O.ADMIN_TRAINED The XDS components will provide authorized Administrators with the necessary information for secure management and operation.

O.AUDIT_GENERATION The XDS components will provide the capability to detect and create records of security and privacy relevant events associated with users. The XDS components will reliably transmit this information to the central audit repository, and provide reliable local storage of events until the central audit repository has confirmed receipt. (See OE.AUDIT_REVIEW.)

O.AUDIT_PROTECTION Each XDS component will provide the capability to protect audit information within its scope of control.

O.AUDIT_REVIEW If an external central audit repository is not part of the environment, the components will be configured to provide limited capability to analyze and selectively view audit information. (See OE.AUDIT_REVIEW)

O.CONFIG_MGMT All changes to the components and its development evidence will be tracked and controlled.

O.DECLARATIVE_SECURITY The components will allow security functions and access control to be defined by the authorized administrator.

O.DISASTER_RECOVERY The components should allow the authorized Administrators to perform backup and restore of electronic data, and rapid configuration and reconfiguration of device operation. In addition, the TOE should support administrative procedures to restore operation after disasters that may have substantially destroyed portions of the hospital operation and where substitute temporary systems are in place.

O.DISCRETIONARY_ACCESS The components will control accesses to resources based upon the identity of users and the role of users. (See O.EMERGENCY_BYPASS.)

O.DISCRETIONARY_USER_CONTROL The components will allow authorized users to specify which resources may be accessed by which users and groups of users. (See O.EMERGENCY_BYPASS.)

O.EMERGENCY_BYPASS The XDS components should allow access to any secured data during a declared medical emergency.

O.ENCRYPTED_CHANNEL Based on the environmental policies, encryption may be used to provide confidentiality of protected data in transit over public network.

O.INSTALL The XDS components will be delivered with the appropriate installation guidance in the form of installation manuals and training to establish and maintain component security.

O.INTRUSION_DETECTION The XDS components will ensure intrusion of malicious software (e.g., virus) is detected.

O.MANAGE The XDS components will provide all the functions and facilities necessary to support the authorized Administrators in their management of the security of the TOE.

O.PROTECT The XDS components will provide means to protect user data and resources.

O.RECOVERY Procedures and/or mechanisms will be provided to assure that recovery is obtained without a protection compromise, such as from system failure or discontinuity.

O.REMOTE_SERVICE The XDS components will provide the means for remote service without sacrificing security or privacy policy.

O.RESIDUAL_INFORMATION The XDS components will ensure that any information contained in a protected resource is not released when the resource is reallocated. Information on permanent media such as hard disk shall be secured during service and repair.

O.RESOURCE_SHARING No user will block others from accessing resources.

O.SELF_PROTECTION Each XDS component will maintain a domain for its own execution that protects itself and its resources from external interference, tampering, or unauthorized disclosure.

O.TRAINED_USERS The XDS environment will provide authorized users with the necessary guidance for secure operation.

O.TRUSTED_PATH The TOE will provide a means to ensure users are not communicating with some other entity pretending to be the TOE. This covers entity authentication. (See O.USER_AUTHENTICATION.)

O.TRUSTED_SYSTEM_OPERATION The XDS components will function in a manner that maintains security.

O.USER_AUTHENTICATION The XDS components will verify the claimed identity of the interactive user. (See O.ENTITY_AUTHENTICATION.)

O.USER_IDENTIFICATION The XDS components will uniquely identify the interactive users.

K.2.2 Environment Security Objectives

OE.PHYSICAL Physical security will be provided within the domain for the value of the IT assets protected by the XDS environment and the value of the stored, processed, and transmitted information.

OE.AUDIT_REVIEW There may be an audit repository and review service provided that can accept audit information from the XDS environment in real time. This facility will provide review and analysis functions. (See O.AUDIT_GENERATION, O.AUDIT_REVIEW.)

OE.OPERATION Networks, firewalls, etc. are deployed and maintained to meet appropriate network security levels.

OE.PERSONNEL Assure IT user & other workforce personal integrity/trustworthiness.

OE.PKI There will be a facility to provide signed certificates as needed for node and user authentication.

K.3 Functional Environment

The XDS environment can be modeled as having four different organizations that have a delegated responsibility relationship where each organization has a different functional responsibility. In some configurations a single organization is responsible for two or more of these functions, which makes delegation much easier. This section discusses the major areas that must be solved.

The four functions are:

Creator – This functional organization has created the PHI and is legally responsible to the patient and others for providing healthcare and for protecting this data.

Repository – This functional organization is responsible for providing access to persistent documents to readers. The creator has delegated responsibility to the repository to provide adequate protection for a subset of the PHI. This subset is called the document.

Registry - This functional organization is responsible for providing query services to readers. The creator has delegated responsibility to the registry to provide adequate protection for a subset of the PHI. This subset is called the metadata.

Reader – This functional organization is providing healthcare services that make use of data that is contained in the metadata and the documents.

There are three levels of difficulty in delegation.

“ Trivial ” delegation is that where it is not necessary to delegate the responsibility for implementing the threat mitigation. In those cases it does not matter whether the organizations have the same policy or mitigations. For example, if the registry provides adequate mitigation against the threat of disaster, it need not be concerned with the disaster related policies of the reader.

“ Easy ” delegation is that where the two organizations have the equivalent policies. In those cases there is an initial difficult phase of discovering that the policies are the same and evaluating that the mitigation strategies are acceptable. This results in a simple binary decision to approve or disapprove a business relationship permitting the exchange of data. With the exception of the three policy classes described as “hard” below, the details of policies are likely to differ, but the goals are sufficiently uniform that a simple business decision can be made.

For the “easy” delegation, the IHE transactions must provide adequate mitigations for the threats so that the business decision to exchange data can be made based simply on review of the partners policies and mitigations. This means that some IHE transactions will have additional security requirements attached. For example, encryption to avoid the threat of eavesdropping may be required. These requirements are not unique to XDS and will be able to use standardized security features like TLS and VPN tools. These requirements may be significantly different from the usual practice within an enterprise, because of the differences in the environment.

“ Hard ” delegation is that where the two organizations have different policies or inconsistent/incompatible mitigation strategies. These are likely to occur for the following policies, where organizations often disagree on the details of the policy goals, and where policies often change:

P.Authorization – The authorized access policies and authorized modification policies often differ, and are often subject to change. The changes that occur are often at a detailed level, e.g., access rights to a particular patient information may change. This means that either there is an agreed mechanism to propagate changes, or an acceptance that policy changes may not be enforced, or there will be restrictions on the data exchange to avoid delegating responsibility for data that is subject to change.

P.Account and P.Trace – The policies for accountability and traceability often differ. These are much less subject to change, but it is often difficult to reconcile delegation when these policies differ. This will be an especially difficult issue for repository and registry functions that support multiple different creator organizations.

P.ObjectAuthorization – The policies regarding creation and modification of access rights often differ. In addition, any of the policy and threat mitigations may be determined to be unacceptable by creator, registry, or repository. In the simple situation where there are only four real world participants this simply means that there is no business relationship. In the more complex world where the registry or repository are in many relationships with many creators and readers it introduces a serious problem. Either the registry and repository must limit its relationship to that small set of creators and readers that mutually accept all the policies and mitigations of all the other organizations, or there must be a mitigation strategy so that creators can restrict delegations by the registry and repository to only those readers that have policies and mitigations that are acceptable to the creator.

Mitigations for differences include the following:

Limit the data exchange to that data where the differences are not significant. For example, highly sensitive data like psychiatric notes might not be shared, while relatively insignificant data like allergy information is shared.

Provide a revocation mechanism to deal with policy changes, so that future delegations can be prohibited. It is often impractical to revoke past delegations because the PHI has already been disclosed. But the revocation mechanism can stop further delegation from taking place. This revocation mechanism must be part of the P.Authorization and P.ObjectAuthorization policies and must be mutually acceptable for this mitigation to be effective.

Trusted third party inspections and audits can sometimes deal with reconciliation of differences in P.Account and P.Trace.

An “approved delegation” list identifying acceptable and unacceptable creator/reader pairs can mitigate the repository and registry issues when the reader has incompatible policies with the creator. This does require the creator to accept the approved delegation policy and implementation of the repository and registry, but it reduces the combinatorial explosion of policy combinations between creators, repositories, registries, and readers into a linear growth in complexity.

The “approved delegation” may go further into identification of persons, but this is only a viable path when all parties have policies the easily support delegation of personal responsibility. Persons are usually required to comply with organizational policies, and organizations generally use roles rather than persons to establish policies. The often viable exception is the special case of the “deny access to person X”. This can be a viable means of dealing with situations involving a conflict of interest. This kind of access denial may be applicable to just a particular subset of the PHI exchanged, (e.g., denying access to an ex-spouse).

These mitigations do not directly change the technical requirements for the XDS transactions. They are policy decisions that may affect how particular actors are configured. The implementation of XDS actors will need to be aware that this kind of site-specific configuration management and policy control will be routinely required.