Strata of CORBA Security Deborah J. Bodeau Joshua D. Guttman F. Javier Thayer It is desirable to be able to analyze and compare ORBs and security domains, for instance to describe the security policies each claims to support; to identify security-relevant capabilities; and to determine the extent of feasible interoperability. However, conceptual difficulties arise because both the CORBA security services themselves and specific ORBs are characterized using inconsistent levels of abstraction. High-level goals are presented next to descriptions of specific mechanisms. We have identified three levels of abstraction or "strata" that facilitate analysis and comparison. The highest stratum defines the security goals of the architecture, and introduces only the entities needed to describe it. Notions relevant at this stratum include: * principals (individuals, organizations, roles, keys), * * threads, * * resource objects (files, databases, online services), * * authentication, and * * policy objectives. * Our goal is that this stratum be sufficiently abstract to support comparison not only of ORBs and CORBA-compliant domains, but also of object mediators and domains that comply with other distributed object computing models (e.g., COM/DCOM). The middle stratum defines the CORBA-specific mechanisms that achieve the goals of the highest stratum, and implement the objects visible at the highest stratum. Kinds of objects that must be introduced at the middle stratum include Interceptors, Current Objects, and Authentication Objects. One goal of this stratum is to restate the top stratum policy objectives in terms of security services and enforcement mechanisms. The security capabilities of ORBs may be appraised against the role these mechanisms must play. Analysis at this level thus could determine whether and how well an ORB or domain can meet a policy objective. Another goal of the middle stratum is to identify the capabilities required of the objects residing within a security domain. Intrusion detection is a specific example of a policy objective for which analysis of these capabilities is needed. Distributed object-oriented computing systems face a the risk that patterns of malicious activity spread across multiple objects will go undetected, just as networked systems face a risk that patterns of malicious activity spread across multiple hosts will go undetected. Objects, like network nodes, are largely autonomous and mutually unaware. The responsibility for auditing is local. To detect intrusions, audit trails must be correlated. The CORBA Security Specification explicitly excludes audit reduction, consolidation, and analysis. However, a security domain must provide such services for the audit mechanisms to be usable. The capability to correlate audit trails maintained by different ORBs is an important aspect of interoperability. The challenges of consolidating audit data from different vendors' ORBs and from different network host OSs are similar. Thus, strategies and mechanisms developed for network intrusion detection may be useful. At the lowest stratum, implementations not specific to CORBA commonly provide the capabilities identified at the middle level. These implementations are based on security architectures for distributed systems. For example, several ORBs depend on variants of Kerberos. ORBs based on X.509-based PKIs are likely to be available soon. Distinguishing between the middle and lowest strata raise questions such as whether CORBA services require richer mechanisms than those currently available. Position Statement for the Second Workshop on Distributed Object Computing Security Petra Hoepner GMD FOKUS email: hoepner@fokus.gmd.de Security in distributed environments (e.g. electronic commerce) is pervasive, i.e. a security infrastructure is needed. The security problem domain may be structured into * System Security: securing the system and networking hardware and operation systems resources * * Application/Service Security: securing service control, e.g. subscription and accounting of users, management, application-specific components * * Middleware Security: prevention of illegal access to objects and resources, auditing security relevant events, security of basic middleware services * * Communication Security: transmission security * * Information Security: authenticity, integrity and confidentiality of all types of information * A generic security infrastructure standard covering all types of risks and the related security building blocks does not exist. Current DOC Security standards provide subsets of these building blocks, mainly in the area of middleware security, i.e. enabling application/services security to a certain extend. Java/RMI: Java's security model is based on the "sandbox" concept. A Java program executes only inside its sandbox. By making it impossible for downloaded code to perform certain actions (e.g. reading or writing to the local disk, making a network connection to any host, except the host from which the applet came,..), the user is protected from the threat of hostile code. RMI allows a Java client to instantiate objects that may be located on a remote server. The drawback is, that RMI is running only in a Java environment. Security features are based on the Java "sandbox" and a security manager that controls the access to remote downloadable objects. Sun publicly stated its long-term goal to allow RMI objects to communicate via IIOP. Java/RMI do not (yet) provide for policy definitions, access control , delegation etc.) ActiveX/DCOM: Microsoft's ActiveX uses the COM/DCOM/OLE technologies. DCOM is based on the RPC mechanism developed for the Distributed Computing Environment (DCE), but it does not include the DCE security mechanisms. Simple options can be set, that automatically use the Microsoft Security Support Provider interface (SSPI) authentication and message encryption. Security on the one hand is based on the ActiveX on the other hand on native IE and WindowsNT security features (NT5.0 will integrate Kerberos). Lacking the software control known from JavaVM, the ActiveX approach relies on code-signing by digital signatures. CORBA: CORBA security service provides a comprehensive architecture identifying and describing different security building blocks as well as programmer APIs, which allow applications to check access to objects, write to audit trails, verify digital signatures etc. Two levels of conformance are specified: Level 1 for programs that are security unaware and Level 2 for programs that can be security aware. This allows the secure integration of legacy code as well as the support for newly required services and applications with high security requirements. Some companies have classified the SSL integration as Level 0, supporting the public key based authentication and encryption services provided by SSL. The CORBA security service is a mechanism-independent specification, to provide for different underlying mechanisms (private or public key technologies) and products (such as Sesame, DCE etc.). This advantage leads to interoperability problems of CORBA conformant security service implementations. Interworking is specified at a very high level, with some possible solutions given in CSI. Looking at the implementation currently only one product announces to be compatible to Level 2 (ICL-DAIS). Other providers have or intent to implement Level 1. An interesting but not yet released approach combines Java, ORB and Security Service (implemented by Concept Five) in Visibroker (Visigenic). The idea is to provide an ORB independent security service in the future. The main problem not covered in CORBA itself is the interworking of the security mechanisms used to provide the service (e.g. Orbix is based on DCE and DAIS on Sesame - interworking currently impossible). Furthermore inter-domain security, e.g. global authentication is not covered in CORBA security. Conclusion: Still missing are security quality specification concepts that map on certain DOC components and building blocks as well as on specific mechanisms with a defined interworking.