Diagnóstico de contenido escrito 1 Información que ofrece el sitio:

RAD (Resource Access Decision) is a mechanism of access control, i.e. limiting resource access to a group of authorized users. It has been implemented with the idea of protecting medical resources provided by a portal application and accessed via a Web browser. RAD is based on the Resource Access Decision Facility developed by the Object Management Group [18]. The goal of the Resource Access Decision Facility is to separate authorization logic from application-specific business logic and make the authorization service independent of the specific security models and policies. RAD is able to support, among other models, user-based access control, role-based access control, context-based access control and rules-based access control. The architecture and features of RAD make it a valuable addition to our Medical Portal.

The following case study illustrates how RAD is used to authorize access to patient examination results and how it can be used to authorize access to other medical resources. It refers to the scenario in which a patient comes to a

hospital for an examination. Following examination, the results are stored in the hospital’s IT system. Only the patient and authorized personnel are allowed to access these results. The case study focuses on providing examination results through the portal. We describe the authorization mechanism that was used in our solution. The authentication process is omitted, because RAD only addresses authorization.

RAD architecture: RAD architecture is derived from the Resource Access Decision Facility. The main difference between the original specification and our implementation is that the middleware which constitutes the basis of the solution is Java RMI, EJB and Web Services, whereas in the original specification it was CORBA. We have also made some additional minor changes in order to improve service performance. Nevertheless, the general architecture, presented in Figure 4-5, remained unchanged.

RAD Secured, security- aware application Authorization database RDBS LDAP

..

Combinator Evaluator ACL-s

Figure 4-5 RAD architecture.

The main steps of the authorization process are [26]:

1. Whenever required, the secured, security-aware application checks if the user has been granted access to the requested resource. The application invokes the access_allowed method of the RAD interface, passing three arguments: resource name, operation to be executed on the resource and user’s credentials.

2. RAD selects evaluators and a combinator based on the resource name. Evaluators are responsible for interpreting authorization policies that control access to the requested resource. In order to evaluate an access request, the evaluators refer to the authorization database. The combinator is responsible for combining results from evaluators according to the authorization policy. The result of the combinator, a Boolean value granting or denying access to the resource, is returned to the application.

3. The application grants or denies access to the resource on the basis of the result received from RAD.

RAD makes an access decision based on the user’s credentials (user name, certificate, etc.), the operation to be performed on the resource and the resource name. User credentials, which are coeval with patient identity, are one of the results of the authentication process. The resource name identifies the patient’s examination result. The operation is understood as the action associated with the resource (e.g. READ, WRITE).

RAD consists of two parts: an access control service and an access control administration module. The access control service provides its interface to secure-aware applications that require authorization. The interfaces are low-level and require adaptation of secured applications. In the case of the Medical Portal, such adaptation took place during the design phase of the application. The administration module is intended to be a tool for managing Medical Portal security.

RAD in Medical Portal: One of the essential security mechanisms for enforcing security policies is access control to resources. In our system, RAD was used to provide an authorization service. The Medical Portal was implemented as a J2EE (JSP/Servlets/EJB) application running on the JBoss application server. Communication between the Medical Portal and RAD was through Java RMI. Patient information, as well as the authorization database, were stored in a relational database management system (Oracle).

In order to combine RAD and the Medical Portal, some steps had to be taken: an authorization database had to be created (with defined users, groups, resources and permissions), a specific evaluator had to be implemented and calls to RAD had to be added in the code of the Medical Portal.

Figure 4-6 shows how RAD is used to authorize access to patient examination results provided by the Medical Portal.

Resource Access Decision (RAD) Client Application/ Web Browser Authorization Database RDBS 2. access_allowed( Resource name, Operation, Caller’s credentials) Medical Portal 1. request: access to an examination’s result 3. authorization evaluation 4. result: the examination’s result

Figure 4-6 RAD in Medical Portal.

Access to examination result consists of the following steps:

1. Following authentication in the Medical Portal, the user requests an examination result.

2. The Medical Portal intercepts the request and extracts the user identifier (caller’s credentials), the identifier of the examination result (resource name) and the operation to be performed on the examination result (READ). Next, the information is sent to RAD as parameters of the authorization method.

3. RAD chooses appropriate evaluators and combinators basing on the resource name. For the examination result, only one evaluator is required. RAD delegates the authorization request to the evaluator and after having received the result, makes an authorization decision using the combinator. In this step RAD accesses the authorization database which stores authorization information. The model of authorization is user-based access control extended with context-based rules.

4. If the authorization decision is positive, the examination result is provided to the user; otherwise an “unauthorized request” page is displayed.

Usage of RAD in the described manner ensures authorization of access to Medical Portal resources. In our case, access control is based on a very simple security policy; however, RAD can support much more sophisticated security policies without changes to the architecture of the whole system. It is only necessary to implement specific plug-ins called evaluators and to reconfigure

RAD. In this way, we can include support for time-dependent permissions, as well as context-based or role-based access control.

A comfortable GUI interface for RAD administration and management of the authorization database makes Medical Portal administration an easy task.

7 Summary

Telemedical systems contain and provide information that is extremely sensitive. Disclosing or damaging that information in an unauthorized way may be catastrophic both for organizations and patients. In order to assure the security of telemedical systems, suitable security policies, security architectures and security mechanisms must be applied. Additionally, a secure and safe working environment must be guaranteed. The rules for setting up such an environment are described (for example) in HIPPA.

Best-practice telemedical systems should satisfy such evaluation criteria as TCSEC or ITSEC. Conformity with these standards helps achieve a well- protected and secure system.

8 Bibliography

[1] P. B. Checkland, Systems Thinking, Systems Practice, John Wiley & Sons, Inc., New York (1981).

[2] W. R. Cheswick and S. M. Bellovin, Firewalls and Internet Security: Repelling

the Wily Hacker, Addison-Wesley Publishing Co., Reading, MA (1994). [3] Committee on Information Systems Trustworthiness, National Research

Council, Trust in Cyberspace, National Academy Press, Washington, DC (1999).

[4] D. Ferraiolo, Proposed NIST Standard for Role-Based Access Control, ACM Transactions on Information and System Security, Vol. 4, No. 3 (August 2001), pp. 224–274.

[5] D. Ferraiolo, D. Kuhn, and R. Chandramouli, Role-Based Access Control, Artech House, Norwood, MA (2003).

[6] Digital Signature Guidelines, American Bar Association (1996), Section 1.35, available at http://www.abanet.org/scitech/ec/isc/dsgfree.html. [7] Guide for Development of Protection Profiles and Security Targets, ISO/IEC

PDTR 15446, available at http://csrc.nist.gov/cc/t4/wg3/27n2449.pdf, pp. 69–74.

[8] Information Technology—Security Techniques—Evaluation Criteria for IT

Security—Part 1: Introduction and General Model, ISO/IEC 15408-1 (1999); available at

http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/lttf_Home/ PubliclyAvailableStandards.htm.

[9] Information Technology—Security Techniques—Evaluation Criteria for IT

Security—Part 2: Security Functional Requirements, ISO/IEC 15408-2 (1999). [10]Information Technology—Security Techniques—Evaluation Criteria for IT

Security—Part 3: Security Assurance Requirements, ISO/IEC 15408-3 (1999). [11] H. Johner, S. Fujiwara, A. S. Yeung, A. Stephanou, and J. Whitmore,

Deploying a Public Key Infrastructure, Redbook SG24-5512-00, IBM Corporation, http://www.redbooks.ibm.co.

[12] N. Kall, Service-Oriented Security Architecture: Part 1, Metagroup, ZDNet (2003).

[13] A. Kumar, N. Karnik, and G. Chafle, Context Sensitivity in Role Based

Access Control, ACM SIGOPS Operating Systems Review (July 2002), pp. 53-66.

[14] P. T. L. Lloyd and G. M. Galambos, Technical Reference Architectures, IBM Systems Journal 38, No. 1, 51–75 (1999); available at

http://researchweb.watson.ibm.com/journal/sj/381/lloyd.html.

[15] S. McClure, J. Scambray, and G. Kurtz, Hacking Exposed: Network Security

Secrets & Solutions, McGraw-Hill Publishing Company, Maidenhead, Berkshire (1999).

[16] M. Moyer and M. Ahamad, Generalized Role-Based Access Control, International Conference on Distributed Computing Systems (April 2001), pp. 391-398.

[17] NEMA -Privacy and Security Committee, Security and Privacy: An Introduction to HIPAA (April 10, 2001).

[18] OMG, Resource Access Decision, Version 1.0. (2001); available at

http://www.omg.org/technology/documents/formal/resource_access_ decision.htm.

[19] A. Patel and S. O. Ciardhuain, The Impact of Forensic Computing on

Telecommunications, IEEE Communications Magazine 38, No. 11, 64–67 (November 2000).

[20] E. Rechtin, Systems Architecting: Creating and Building Complex Systems, Prentice Hall, New York (1991).

[21] RFC 1825, Security Architecture for the Internet Protocol (August 1995); available at http://www.ietf.org/rfc.html.

[22] RFC 2316, Report of the IAB Security Architecture Workshop (April 1998); available at http://www.ietf.org/rfc.html.

[23] F. B. Schneider, Enforceable Security Policies, ACM Transactions on Information and System Security 3, No. 1, 30–50 (February 2000). [24]Security Architecture, e-Government Strategy, Version 2.0 (September 2002). [25]Security Architecture for Open Systems Interconnection for CCITT Applications,

ITU-T Recommendation X.800/ISO 7498-2 (1991); available at http://www.itu.int/itudoc/itu-t/rec/x/x500up/x800.html.

[26] P. Slowikowski and M. Jarzab, Security aspect of medical portals, Proceedings, the International Conference on E-he@lth in Common Europe,

Krakow, Poland (2003).

[27] D. Verton, Common Ground Sought for IT Security Requirements,

Computerworld35, No. 11, 8 (March 12, 2001).

[28] J. J. Whitmore, Security and e-business: Is There a Prescription? Proceedings, 21st National Information Systems Security Conference, Arlington, VA (October 6–9, 1998); available at

http://csrc.nist.gov/nissc/1998/proceedings/paperD13.pdf. [29] http://www.commoncriteria.org/protection_profiles/pp.html.

5 Wireless Systems in e-Health