CORBA (Common Object Request Broker Architecture) is a highly representative standard of an object-based distributed architecture, defined by the Object Management Group, OMG. It enables the joint operation of software components written in different computer languages and running on different systems. Although the CORBA model simplifies the implementation of distributed systems, initially it did not provide reliable and secure support. Given this shortcoming, security measures began to be implemented in the tools offered by CORBA middleware.
The CORBA standard is a middleware that uses Object Management Architecture, OMA, also developed by OMG. A middleware is defined as a software layer that connects two or more separate heterogeneous applications, providing consistency between the underlying networks, operating systems and programming languages.
To add security in this protocol, an extra layer with new security measures is added, all of which is defined in the document , in version 1.8 of the standard CORBA. This document specifies a security model along with an architecture, collectively establishing the CORBA security limits.
Variations introduced by CORBAsec
The CORBAsec security architecture centralizes the security functionalities in a trusted core, responsible for enforcing security policies, including:
- Ensuring that client invocations to objects, in order to obtain information or perform functions, are protected, as required by the security policy.
- Requiring that access control and auditing be carried out when an object is invoked.
- Preventing object applications from interfering among themselves or obtaining unauthorized accesses.
There are a number of functionality packages that are used to structure the security specification and define compliance requirements. These packages indicate, for example, where and how a system's security policies are to be applied and the conditions under which an institution can access an object. One of the most important packages is the one known as the Main Security Functionality Packages, which has two levels of security:
- Level 1: provides initial level security to applications that do not have security mechanisms and to those that have to enforce their access control and audit related security measures.
- Level 2: allows applications to control the security provided in the object's invocations and to manage the security policy.
The CORBAsec version states that any user accessing an object must be a primary, in other words, a previously registered and authenticated system user or entity, or a client acting on behalf of a primary. The primary has a series of privileges attributes that are known by the system and determine what it can access.
When a primary invokes an object, the aforementioned security functionalities for that object apply to it. These could be:
- Establish a secure partnership between the client and the object in order to confirm that each one is who they say they are.
- Decide if the primary or the client is authorized to make the request through the access control policy.
- Audit this request if required.
- Protect the in-transit modification requests and responses by implementing protection measures.
When an object is invoked, CORBAsec uses a structural model-based architecture that is made up of four main levels:
- Application-level components.
- Components that implement the security services regardless of any underlying security technology, such as security services or object policies defined in the security policy.
- Components that implement specific security technology.
- Basic protection and communication, generally provided by the combination of hardware and operating system mechanisms.
Structural model. Source: CORBAsec Security Specifications -
Security in CORBAsec
The proposed security measures to improve CORBA focus on ensuring the aspects of transparency, scalability, reusability of existing security infrastructures, flexibility and interoperability. This specification seeks to achieve these objectives by offering the following security functionalities:
- Identification and authentication: proves the identity of users or processes in the system, remembers and securely transports identity information and makes this identity information available when necessary.
- Message protection: using SSL and symmetric encryption keys to protect message privacy. This prevents attackers from reproducing previously stored communications.
- Authorization: access to objects and operations can be controlled via identification and other information.
- Log auditing: to collect, store and distribute information about call requests and their results. Audit mechanisms are able to identify who the user is, even after a chain of calls through numerous objects.
- Non-repudiation: provides irrefutable evidence of the actions, such as the veracity of the data source to the recipient or data reception to the sender.
- Delegation: occurs when a user authorizes another to use their identity or privileges with some restrictions on use. This requires the identities involved in the execution of a CORBA request to be logged and monitored.
These new CORBAsec security functionalities include some aspects that have some room for improvement:
- Authentication and authorization: Before a client and server can securely exchange messages, each must know the identity and other security attributes of the other. CORBAsec's predefined attributes are limited and do not describe all the properties of a user.
- Log auditing: Audit functionality is incomplete. There is a lack of security for audit logs and effective filtering media or interfaces for proper analysis. Furthermore, there is no standardized audit log format, making centralized audit processing impossible.
- Non-repudiation: The specification of the non-repudiation service at CORBAsec is also incomplete, lacking components such as delivery authority and secure storage.
Instead of implementing all these functionalities, CORBAsec acts as an API that invokes underlying security mechanisms, such as SSL. Therefore, CORBAsec’s effectiveness is limited by the functionalities offered by said underlying mechanisms.
The CORBAsec specification attempts to make a trade-off between two very relevant aspects such as flexibility and interoperability. Flexibility refers to the support from several security policies, while interoperability refers to the simultaneous operation of different SCADA systems. Interoperability is achieved by standardizing security policies and mechanisms as much as possible, so that products from different providers offer the same functionalities, regardless of internal implementation.
CORBAsec in ICS
The use of CORBAsec in control systems is focused on its integration into all systems that are already currently using CORBA, characterized by having distributed architectures and covering a large area.
Hospitals are an example of CORBAsec implementation in a control system. Patient information, which is considered critical, is segmented among hospitals, community health information networks and healthcare organizations, each with its respective management software. Thanks to the application of CORBAsec, a patient's medical history can be organized in a single report securely and almost instantly, reducing bureaucratic costs.
Given the lack of compatibility in some cases between industrial control systems from different suppliers, organizations are unable to take advantage of the existing wide range of unique products that is on the market. CORBA allows different systems to interoperate in order to make the most out of the market and therefore not have to depend on the same provider from the first acquisition.
The first versions of CORBA in the 1990s did not consider any security aspect, but with the evolution of industrial security, it became necessary to implement measures that would protect the standard from new emerging threats. CORBAsec introduces such security measures with a balance between flexibility and interoperability, allowing the union of different software securely and efficiently.