You are hereTrusted RUBIX Features

Trusted RUBIX Features


 

Advanced Security Features

 

1) The NSA Reference Monitor concept uses a reference validation mechanism to correctly enforce trusted Operating System (OS) and Relational Data Base Management System (RDBMS) access control policies. This mechanism is characterized by encapsulating all database information within a protected domain and operations performed in those domains include security checks. These checks are made upon simple "read/write" based operations. Such policies must be invoked to mediate security-sensitive operations (must be non-bypassable), must be tamperproof, and small enough to be subject to analysis and testing to verify correctness. Trusted RUBIX (TR) has been constructed from its inception to use a Reference Monitor Architecture.

 

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 Common Criteria (CC) Conformance Level on Trusted Solaris 8. For more information see http://www.commoncriteriaportal.org/files/epfiles/st_vid1015-vr.pdf  Trusted RUBIX is supported on Red Hat 6, CentOS 6, and Scientific Linux 6 and can be ported to other SELinux- like kernels, e.g., Android OS.

 

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. It includes the row-level (row label) security capability. No other RDBMS implements its MAC policy at the kernel level. Other RDBMS enforce their MAC security behavior through a technique called query modification. This involves modifying the WHERE clause of the user's SQL query and then converting arbitrarily complex SQL commands into read/write operations on database tables. Thus, security implementation of traditional RDBMS is complex and error prone.

 

4)  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. For example, the Trusted RUBIX session label and the trusted OS session label are the same for every user. It also permits Trusted RUBIX  to connect to several networks at different sensitivity levels. More importantly, it prevents security violations when information moves between the database (e.g., table) and the operating system (e.g., file). Thus, the trusted OS enforces its MAC policy on its own objects (process, files, etc.), but TR relies on its MAC policy to enforce its own objects (i.e., database, catalog, schema, table, view, and row). 

 

5) Trusted RUBIX MAC automatically eliminates many "overt" and "covert" channels by enforcing MAC on its data dictionary (which contains database objects) and still allows their use in real, internal operations.  Trusted RUBIX supported security policies include Multi-Level Security (MLS), Type Enforcement (TE), Role Based Access Control (RBAC), and Attribute Based Access Control (ABAC).

 

6) The Trusted RUBIX Multilevel Security (MLS) policy restricts access to data objects based on the sensitivity of the information contained in its objects and the "clearance" of users to access such information.  MLS controls the flow of information across the entire system, guaranteeing that users with lower clearance know nothing about the existence or contents of data with higher sensitivities.   

 

7) Central to the MLS policy is the MLS label assigned to a 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 objects with the same MLS labels and security lattice as used by the underlying trusted OS. Trusted RUBIX provides the capability to reclassify the row label through the SQL UPDATE command.

 

8) Type Enforcement (TE) : User sessions are assigned domains and TR 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. For an example of TE policy in a cross domain environment see: http://rubix.com/cms/te_xdomain.

 

9) TR 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. The granular authorizations allow roles to be constructed that divide the administrative power between users. This "separation of duties" between the various administrators is critical to limit the potential damage a rogue administrator or a compromised administrative account may inflict. Trusted RUBIX fully integrates its RBAC mechanism with that of the trusted host operating system.This allows for the creation of roles with consistent authorizations across both the trusted OS and Trusted RUBIX.  

 

10) Attribute Based Access Control/SPM (ABAC) : The Trusted RUBIX ABAC security policy is based on the XACML 2.0 standard and uses the XML policy language to create highly customized, complex, and hierarchical security policies. Instead of policy decisions being based solely upon the identity of the user or an assigned security label, any database "attribute" may be used. Additionally, actions may be taken based upon the result of the policy decision, such as writing a highly customized audit record. Policies may be updated and applied in "real-time". Policies may also be configured to override the MAC policy. Policies may also be nested in that policy sets may be constructed in a modular fashion using other policies and policy sets.  

 

11) These ABAC security policies are enforced by the Trusted RUBIX Security Policy Manager (SPM). 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. Such a configuration virtually eliminates threats from SQL injection and application hijacking. The SPM allows the "finest" level of control in determining information flow between domains. For an example of a policy which releases information in a cross domain environment see: http://rubix.com/cms/abac_xdomain.

 

12) It is possible to extend the Trusted RUBIX ABAC security mechanism to cooperate with other XACML standard based security appliances. These standards aware applications could be controlled from a single administrative point. This ability to administer a wide range of applications from a single coherent source is attractive for Software as a Service (SaaS) and Cloud Computing architectures.

 

13) A two-tiered structure consisting of Application users (i.e., Internet users that connect to a Trusted RUBIX application, but not directly to the Trusted RUBIX server itself) and RDBMS users (i.e., full Trusted RUBIX users that may instantiate a session with the Trusted RUBIX server). Specific application users are only allowed to authenticate to Trusted RUBIX when a specific Trusted RUBIX user is already authenticated.  For an example of how the web-based Trusted RUBIX Application User Mechanism can be used to stop a SQL Injection attack (URL modification) see: http://rubix.com/cms/app_user_solution.

 

14) 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. This multiversion read model supports scalability as reading processes with no intention to re-write will not block a writing process.

 

15) 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.

 

16) 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.

 

17) 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.

 

18) Trusted RUBIX has been used as an integral component of a system that facilitates secure data sharing and collaboration among individuals, organizations, and networks operating in different security domains. The "cross-domain" capability of TR was demonstrated by a multi-domain Wiki/blog capability. Each of the 3 separate networks had a VM on which a wiki was run and each Wiki backend used Trusted RUBIX.  A Google Earth application was selected for the overall Services Oriented Architecture (SOA) to provide a graphical display of data which could be augmented with data overlays from selected domains to show the filtering required due to policy.

 

19) Trusted RUBIX provides a unique approach to building an untrusted RDBMS. Trusted RUBIX supports MLS objects and behaviors as an intrinsic part of TR out of the box. Other RDBMS can not and will not be "untrusted" with respect to an evaluation capability. The reason is that they use query modification for their basic policy enforcement. The only way to simulate TR MLS-MAC is to replicate installations and databases across security levels.

 

20) Thus, TR can provide an untrusted database with "limited" functionality of single level tables. It will be untrusted with respect to SELinux policy enforcement and untrusted components such as the client, server, and dispatcher, and possibly untrusted TR commands. The result is a TR with no Trusted Computing Base (TCB) and no requirement for continuing evaluations. This assumes that SQL DAC is not part of the evaluation process and that customer environments have no need for TR "polyinstantiation".

 

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

 

5) 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.

 

6) Sophisticated techniques for cost-based query optimization.

 

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

 

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

 

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

 

10) 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.

 

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

 

12) 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.