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 tamperproof, 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. 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.

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. 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 "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 Trusted Solaris 8, Fedora SELinux, and Red Hat Enterprise Linux 6.

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 DBMS 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 DBMS 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.

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 DBMS application and not directly to the DBMS server itself) and DBMS users (i.e., full DBMS users that may instantiate a session with the DBMS server). Specific application users are only allowed to authenticate to the DBMS when a specific DBMS 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 autheticated 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 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 DBMS into another non-arbitrated domain of that DBMS? 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.

Traditional DBMS 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) Supports the ability to declare temporary tables which are used only to pass intermediate results from one portion of an application to another. Such tables are private to the application that uses them; there is no sharing of data with other applications.

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.