CA:Sec specifies foundational components that are focused on the security aspect of an overall security system. These are:

  • Node Authentication
  • Secure Communications

Node authentication enables communications participants to:

  • Confirm that the server is indeed the authorized server system.
  • Confirm that the client application is indeed an authorized client.

This enables the use of system or machine-level access controls that limit access to only authorized and authenticated machines. The local governance policies will determine whether machine level access control rules are used.

Secure Communications are provided using TLS. TLS provides mutual authentication, reliable message transport and private communication through data encryption. Different forms of encryption can be negotiated to protect the data in transit. CA:Sec permits payload encryption for those sites that wish to implement an additional layer of protection.

CA:Sec does not restrict implementations and deployments to only use the CA:Sec specified methods. For interoperability reasons, TLS must be implemented and available to be configured. The RFC7525 “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)” covers many configuration options. Deployments often follow these recommendations and make them part of their security policies. A deployment’s security analysis may lead to different choices. Therefore, it is important that implementations allow configuring different protocol versions, algorithms, etc.

Concepts

Cybersecurity activities include a variety of operational, technical, and administrative activities. These are specified in some areas by law or regulation. All of the laws and regulations are consistent in requiring an overall governance model, various technical tools, and operational behaviors. The technical tool requirements always include system authentication, user authentication, event logging (audit), and telecommunications encryption. They also include many other technical features regarding access control, confidentiality, user administration, backups, etc. There are typically also significant operational and administrative requirements.

CA:Sec specifies node authentication and telecommunications encryption. It assumes that the CA:Sec actors will be installed into an environment that complies with all the other governance requirements. Compliance with CA:Sec alone, without also performing the other cybersecurity activities, is not sufficient to provide adequate cybersecurity.

Governance

The specific requirements for cybersecurity vary for different locations and purposes. The overall goals always include protecting confidentiality of data, integrity of data and systems, and availability of data and systems. The requirements affect:

  • administrative policies, such as the policies to be used when authenticating and provisioning a new user,
  • technical capabilities, such as performing real time access control, and
  • operational activities, such as maintaining backup facilities and having continuity of service plans.

It is not practical or reasonable for CA:Sec to profile those requirements. They are too varied and cover much more than just interoperability of systems.

CA:Sec assumes that governance is established that is similar to the recommendations found in the NIST and ISO Frameworks:

Authentication

User Authentication

The remote Secure Application validates that the user who requests access has been (locally or remotely) authenticated and is authorized to use the service requested.

For locally authenticated users, authentication must take place prior to the creation of a secure tunnel – resources should not be used prior to local user authentication.

CA:Sec does not specify the specific method for user authentication. IHE has profiles that specify particular kinds of user authentication. These can be used, as can other non-IHE methods for user authentication. For details, see Security Considerations.

Machine to Machine Authentication

CA:Sec specifies that connections between machines be authenticated and use TLS. The TLS machine authentication is based upon the use of public and private certificates. This is the method used to authenticate many sensitive transactions on the Internet.

Unlike the typical Internet browser setup, within a healthcare setting:

  • Individual direct comparison for validation of certificates can be practical and appropriate. For example, it can be reasonable to use direct comparison and provide the public certificate between two secure applications.
  • Chain of trust signed certificates can be practical and appropriate. It can be reasonable to have a hospital security system provide the trusted root authority for authenticating that a particular machine is an authenticated member of the hospital network.
  • The commonly used root certificate authorities for browsers are much less likely to be appropriate for a chain of trust method. Their certificate policies are designed for financial risk reduction, not healthcare system authentication.

A means must be provided to install the required certificates to any CA:Sec implementation so that the systems can be configured to match the local governance. The common browser root certificate list is not sufficient. The particular implementation will ultimately make final ruling regarding the detailed requirements for certificates that are needed for a specific system.

  • No labels