|
Applicability of CORBA Security to Healthcare Problem Domain
AcknowledgmentsWe want to thank Object Technology Group at Baptist Health Systems of South Florida for their input on this paper as well as all those SecSIG and CORBAmed mail lists participants who discussed questions related to security in the healthcare domain. IntroductionCORBA Security specification (CORBASEC) allows an application to exercise security service provided by ORB environment (called "system security" here) to this application, or to exercise its own security (called "application security" here). CORBASEC does not prevent someone from re-implementing security inside of an application and from avoiding the use of system security. If a system designer wants to deliver one more stovepipe system, it does not matter what (system or application) security will be employed. If a system is supposed to be extensible and interoperable, and especially if the system is going to act as a component in enterprise infrastructure, a designer will want to use system security as much as possible and use application security only when the system cannot provide the required level of granularity, or flexibility. In the former case, for the system (or application) to be pluggable into enterprise computing environment, application security should still be exercised via horizontal interfaces and metadata provided by an infrastructure in which the component is going to perform.
In this paper, we discuss our vision of how CORBA-based components provided by different vendors can exercise sophisticated security policies in a consistent and uniform way in healthcare enterprises. We state questions that should be addressed by healthcare domain and security task forces. We believe that this paper can serve as a starting point for CORBAmed's track towards a set of specifications on a uniform way of exercising security in CORBA-complient healthcare computing environments. The paper structure is as follows: First, we give minimal background on the main functionalities security services are supposed to provide in distributed environment. Second, we show why extensive use of horizontal interfaces and metadata is essential to achieve consistency in exercising security across components from different vendors, as well as to achieve independence from enterprise security policies. Third, we show why CORBA-complient components have to exercise application security in order to satisfy security requirements of today's healthcare business. Fourth, we discuss why CORBA-complient components of healthcare providing enterprises should exercise application security in a uniform way. Fifth, we raise questions that, we believe, CORBAmed wants to address in its security related specifications. Then, we mention issues, OMG security community is planning to address, that are essential for deploying CORBA-complient systems in healthcare. We conclude the paper with summarizing its main results. The very last section contains references and explains some terminology. BackgroundHere, a principal is a human or system entity that is registered in and authenticatable to a system [CORBASEC]. Comprehensive information security of distributed systems is supposed to implement the following several main functionalities:
For a very good and brief introduction into CORBA security framework see "Guidelines for Security and CORBA implementation of the PIDS Access Policy Model" written by Polar Humenn (polar@blackwatch.com) and posted to PIDS mail list on September 14, 1997. Horizontal Interfaces, Metadata and CORBASECIn the case of security environment, an enterprise architecture defines metadata, which describe security policies, and horizontal interfaces, which provide a means to exercise those policies across an enterprise. When there are heterogeneous systems in one enterprise (does anybody have homogenous systems only?) all those systems want to use the same horizontal interfaces in order to exercise consistent security policies. To achieve it, a company wants to require all its vendors to use those interfaces and metadata. We believe that the healthcare problem domain can be analyzed and a set of horizontal interfaces can be defined for the whole healthcare market. Specification of Patient Identification Service (PIDS), which will occur soon, and other activities of CORBAmed are good proof for such belief. CORBASEC is a very good base for building such horizontal interfaces in the security area of healthcare. Indeed, CORBASEC service can even be used directly when security policies are simple and flat. But it is not the case with the healthcare problem domain where, as the experience of CPR analysis and design shows, policies have to be of finer granularity than interface (note, not object) methods invocation and to involve such criteria as principal location, access time, information confidentiality level, etc.. The Need To Exercise Application Security In Healthcare Business DomainIn the healthcare business domain:
The list above leads to the conclusion that a healthcare application might want to exercise its own security (particularly access control) constraints on top of security services provided by ORB. Ideology of CORBASEC agrees with the fact that some vertical domains will require it:
There has to be finer-grained security control than just interface.method one for the content (this is what CORBASEC provides in its current specification). And, this problem is for any specification issued by CORBAmed. The Need To Exercise Application Security in Uniform WayAccording to our vision, the logic of security policy decision should be separated from an application system because:
This is why we believe that a set of enterprise security policies is the first candidate for metadata in the computing infrastructure of a healthcare provider. Such security metadata can be encapsulated and accessed via interfaces that are external to the application system. If the interfaces are specified, system vendors do not have to worry about idiosyncrasies of security policies and policy changes at their customer enterprises. CORBASEC specifies such interfaces to access enterprise security policies in a uniform way wherever security policies are simple and can be enforced on system level. In other words, wherever system security suffices. When it is not sufficient to express complexity of a given vertical domain, application security should also be uniform. Interfaces for accessing security policy decision logic have to be uniform across all components in CORBA-based infrastructure of healthcare providers. If an application is going to exercise its own security on top of CORBASEC, the way it does should be the same as for any other CORBA-based application/system in the enterprise so that:
Here is one of the possible solutions. There can be, so to say, "decision objects" on the application security level that an application wants to "consult" to enforce a particular type of security. Such objects, again, have to be the same for any other applications and systems in CORBAmed. Another approach , as Polar Humenn correctlry mentioned in the one of mail threads on OMG's SecSIG and CORBAmed's PIDS mail lists, is interceptor mechanisms. We believe this is what CORBAmed security specification wants to deal with. Once such an interface is specified, previously adopted specifications, like PIDS, will be amended to reflect it. Issues To Be Addressed By CORBAmedWe see two types of issues CORBAmed needs to address in regard to security in CORBA-complient systems deployed on the healthcare market. They are:
Issues To Be Addressed By Security Task ForceIn this section, we describe few items from larger list of issues that we found very important to address in OMG standardization process in order for CORBASEC to be used in the computing environment of healthcare organizations. These issues are known to OMG security community. By listing them in this paper, we want to make stress on the fact that these issues are essential for deploying CORBA security in healthcare.
ConclusionsComplexity of the healthcare security problem domain requires exercising a more sophisticated security model than the general one used in CORBA Security service. This leads system developers to application level security on top of security provided by ORB systems. At the same time, commonality of security requirements across healthcare computing environments allows exercising security at the application level in a uniform way. Both healthcare market vendors of computing systems based on CORBA technology and healthcare enterprise security designers and administrators will benefit from having standard interfaces to access enterprise security metadata and exercise security at the application level. We believe that such interfaces can be specified by CORBAmed with the help of OMG security-aware community. After the CORBAmed security interfaces are specified, ambiguity in requirements for an ORB to be CORBA Security compliant can be eliminated by underwriting a specification profile. The profile will clearly state what optional functionality has to be provided by an ORB in order to use it in healthcare computing environments. It will allow application system vendors as well enterprise designers to select adequate ORB environments. References and TermsAC -- Access Control Authentication -- a process of verifying the claimed identity of a principal. Authentication results in authenticity, meaning that the verifying principal (verifier) can be sure that the verified principal (claimant) is the one he or she claims to be Authentication techniques are based on one or a combination of the following: proof by knowledge, proof by possession, proof by property.[Oppliger 1996] "Common Secure Interoperability", 1996 OMG Document Number: orbos/96-06-20 CA -- Certificate Authority. A trusted third-party that issues and manages (validates, revokes, publishes) digital certificates. CAC -- Content Access Control. It is control over access to passive resources like plain pages (without active components) over WWW services. Some times, access to active components can be controlled in the same way as CAC. For example, a Web server administrator can restrict access to Java classes accessible from the server. Such AC considered as CAC even though Java classes can be active resources. "CORBA Core" volume 1, OMG, version 2.0, July 1996 Available in electronic form from. "CORBA Services" volume 1, OMG, version 1.0, November 1996 Available in electronic form from. Chapter 15 is Security service specification. CPR -- Computerized/Computer-based Patient Record. Domain "(as specified in the ORB Interoperability Architecture) is a distinct scope, within which certain common characteristics are exibited and common rules observed."(p.15-33) Horizontal interfaces are those interfaces that apply to an entire category of subsystems. Horizontal interfaces are described and discussed in [Mowbray 1997]. KISS -- Keep It Simple, Stupid LDAP -- Lightweight Directory Protocol. It is a specification for a client-server protocol to retrieve and manage directory information. It was originally intended as a means for clients on PCs to access X.500 directories, but can also be used with any other directory system which follows the X.500 data models. There is a LDAP World page at Critical Angle that gives a good list of references regarding LDAP. Metadata is self-descriptive information that defines the dynamic structure of the system. Metadata is described and discussed in [Mowbray 1997]. [Mowbray 1997] Mowbray, Thomas J., Malveau, Raphael C. "CORBA Design Patterns", 1997 Jon Wiley & Sons, Inc. [Mowbray 1995] Mowbray, Thomas J, Zahavi Ron "The Essential CORBA: Systems Integration Using Distributed Objects", 1995 Jon Wiley & Sons, Inc. [Oppliger 1996] Rolf Oppliger, "Authentication Systems for Secure Networks", 1996 Artech House, Inc. Public Key Cryptosystem is a cryptosystem in which a user has a pair of mathimatically related keys. The pair consists of a public key that can be published without doing any harm to the systems's security, and a private key that is assumed to never leave the posession of its owner.[Oppliger 1996] PID -- Patient ID PKCS stands for Public Key Cryptography Standard and is a series of cryptographic standards published by RSA Laboratories. See also public key cryptosystem. Principal -- a human or system entity that is registered in and authenticatable to a system. QoP -- Quality of Protection Stovepipe system is a set of legacy applications that resists adaptation to user and organizational needs. Mowbray and Zahavi describe the following characteristics of stovepipe systems in [Mowbray 1995, p.9]:
Secure Sockets Layer (SSL) -- a security protocol, which provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. Netscape site has dedicated pages about SSL. SESAME -- a Secure European System for Applications in a Multi-vendor Environment. SESAME is a European research and development project, part funded by the European Commission under its RACE program. It is also the name of the technology that came out of that project. The SESAME technology offers sophisticated single sign-on with added distributed access control features and cryptographic protection of interchanged data. More information on SESAME can found on its page. X.500 -- X.500 is an Internet standard for directory service and mailb routing. X.509 -- ISO/IEC 9594-8, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT/ITU Recommendation X.509, 1993. More details on this standard can be found at Gateway to Information Security site. |
|