Trusted RUBIX Features

Advanced Security Features

1) The claim that has been adopted by NSA is that a reference validation mechanism that satisfies the reference monitor concept will correctly enforce a system's access control policy, as it must be invoked to mediate security-sensitive operations, must be tamper-proof, and be small enough to be subject to analysis and testing to verify correctness.

2) An internal design that focuses on the modularity and layering principles which are critical in high assurance systems. Trusted RUBIX (TR) has been validated at the EAL 4 Conformance Level on Trusted Solaris 8. For more information on the Common Criteria evaluation of Trusted RUBIX see http://www.niap-ccevs.org/cc-scheme/st/vid1015/.

3) The Trusted RUBIX Mandatory Access Control (MAC) policy is implemented as a minimized reference monitor within the database kernel and not at the application level. No query modification or SQL engine "hooks" are used.

4) The Trusted RUBIX Muliti-Level Security (MLS) policy restricts access to data objects based on the sensitivity of the information contained in the objects and the "clearance" of users to access such information. It is an inflexible policy. If used, it must be used across the entire system.

5) Full integration of the trusted host operating system's OS-MAC policy with the Trusted RUBIX MAC policy. This integration provides a unified and coherent security behavior across all database and operating system objects, simplifying security administration. It also permits Trusted RUBIX to connect to several networks at different sensitivity levels. Most importantly, it prevents security violations when information moves between the database (e.g., table) and the operating system (e.g., file).

6) Trusted RUBIX MAC automatically eliminates most or many "overt" and "covert" channels by enforcing MAC on the data dictionary (which contains database objects) and still allows their use in real, internal operations.

7) Supported trusted operating systems include Red Hat 6, CentOS 6, Scientific Linux 6, and Solaris 10 TX.

8) Trusted RUBIX supported security policies include Muliti-Level Security (MLS), Type Enforcement (TE), Role Based Access Control (RBAC), Attribute Based Access Control (ABAC), and Discretionary Access Control (DAC).

9) Central to the MLS policy is the MLS label assigned to a Trusted RUBIX subject (e.g., a database session open on behalf of a user) and object (e.g., a row in a table). Trusted RUBIX labels its RDBMS objects with the same MLS labels used by the underlying trusted operating system. Trusted RUBIX provides this capability to reclassify the row label through the SQL UPDATE command.

10) Type Enforcement (TE) : User sessions are assigned domains and RDBMS objects are assigned types. A scripting language is used to define which type is assigned to an object and which domain is assigned to a user session. The scripting language is also used to define if a user session may perform an operation on an object. Type Enforcement (TE) policy provides custom and flexible rules for labeling and releasability requirements in cross domain environments. If users choose TE as their primary MAC policy for TR objects, they can most likely fulfill all of their MAC needs using only TE rather than MLS.

11) Role Based Access Control (RBAC) allows highly granular administrative authorizations to be assigned to a named role. That role may then be assigned to any number of users, giving that user all of the authorizations assigned to that role. Trusted RUBIX fully integrates its RBAC mechanism with that of the trusted host operating system.

12) Attribute Based Access Control (ABAC) security policies are enforced using the Security Policy Manager (SPM). It allows highly customized, complex, and hierarchical security policies to be created using a OASIS XACML 2.0 based XML language. The SPM policies and policy sets may be configured to further refine the underlying OS-MAC security policy or to allow highly controlled data releases across OS-MAC security domains.

13) A two-tiered user structure consisting of application users (i.e., internet users that connect to a RDBMS application and not directly to the RDBMS server itself) and RDBMS users (i.e., full RDBMS users that may instantiate a session with the RDBMS server). Specific application users are only allowed to authenticate to the RDBMS when a specific RDBMS user is already authenticated.

14) The SPM may be configured to limit the SQL operations an application user may perform, including restricting access to specific rows of the database, if the application user is authenticated and it is permitted by the SPM policy. This configuration virtually eliminates threats from SQL injection and application hijacking.

15) Discretionary Access Control (DAC) specifies who can do what to the data - who can read, who can insert, who can change, etc. The controls are discretionary in the sense that a user with a certain privilege is capable of passing that privilege to other users.

16) Trusted RUBIX's unique multi-version timestamping concurrency control technique enables the system to securely manage all changes taking place within the database, even with multiple applications running. This technique removes most covert channels between transactions of different security domains as they access common database objects, thereby ensuring secure transaction processing.

17) Polyinstantiation occurs when duplicate records with different label's are inserted into a common table. If no special action is taken, data may be covertly transmitted to unauthorized users. Polyinstantiation may also be used to provide a "cover story" - where the actual data may be highly classified, but where there must be some other value visible to lower level users.

18) There are many environments where the data must be controlled during its entire life. Many commercial applications are mistakenly concerned with the security of data only until it is placed into the control of the end user. TR prevents or seriously hampers a TOP SECRET user from passing TOP SECRET data to an UNCLASSIFIED user.

19) What happens when data moves from the labeled security arbitrated domain of a RDBMS into another non-arbitrated domain of that RDBMS? The data ceases to be labeled and no access checks may be performed. In Trusted RUBIX no subset of data in the database is unlabeled and all operations on that data are arbitrated by the MAC policy.

20) Trusted RUBIX has been successfully demonstrated as the MLS RDBMS component hosted on a secure operating system in a network centric Services Oriented Architecture (SOA).

Traditional RDBMS Features

1) A client-server architecture which allows untrusted clients to access either a single or multiple trusted servers running Trusted RUBIX.

2) An SQL interface which conforms to the ANSI SQL 92 standard and includes functions of the SQL 3 standard.

3) Users can write to standard Application Programming Interfaces (API's) such as Open Database Connectivity (ODBC).

4) A complete set of bit string, binary large object (BLOB), character string, character large object (CLOB), numeric, date/time, interval, and security data types gives Trusted RUBIX total control over input/output formatting and sophisticated data operations.

5) Sophisticated techniques for cost-based query optimization.

6) A complete audit trail for all database operations that enables both the legitimate (but accidental) errors by users and unauthorized requests to be tracked.

7) Tools for database back-up, database recovery, table import, table export, and audit management.

8) Full Atomicity, Consistency, Isolation, and Durability (ACID) compliant transactional support.

9) A savepoint mechanism which allows transactions to be partially rolled back (on user request). Thus, a user can undue all updates performed since the specified savepoint, while at the same time preserve updates performed prior to that point.

10) Temporary tables which are automatically dropped upon session termination. Optionally, all rows may be deleted upon transaction commit.

11) All of the features of Trusted RUBIX are available 24 hours a day. The system need not be shut down to fix a table if the system crashes. Trusted RUBIX enables the user to back-up and recover data, add a new table, or make other changes to the database while users continue to access the database.