Part 4 of this series on top STIG controls takes a look at the encryption of data in motion and the use of Public Key Infrastructure (PKI). These are some of the most technical STIG controls, and some of the hardest to get right, as there are several secondary controls that will influence how we do things.
V-61545: The DBMS must employ cryptographic mechanisms preventing the unauthorized disclosure of information during transmission unless the transmitted data is otherwise protected by alternative physical measures.
Preventing the disclosure of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to protect the information during transmission. This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel.
Information in transmission is particularly vulnerable to attack. If the DBMS does not employ cryptographic mechanisms preventing unauthorized disclosure of information during transit, the information may be compromised.
SHA-1 is in the process of being removed from service within the DoD and it’s use is to be limited during the transition to SHA-2. Use of SHA-1 for digital signature generation is prohibited. Allowable uses during the transition include CHECKSUM usage and verification of legacy certificate signatures. SHA-1 is considered a temporary solution during legacy application transitionary periods and should not be engineered into new applications. SHA-2 is the path forward for DoD.Oracle Database 12c Security Technical Implementation Guide :: Release: 16 Benchmark Date: 24 Jan 2020
There are a couple of things to unpack here, before taking a look at how to implement proper encryption. The first is that of the methods of transmission listed, Oracle supports Transport Layer Security (TLS) – more on that in a moment. The second is that “alternative physical protection measures” won’t apply to the vast majority of cases where this STIG control is being evaluated, since most systems aren’t classified, and those that are will have additional requirements beyond STIG compliance. Lastly, note the required use of SHA-2 over SHA-1, as this will also be important.
The STIG then goes on to say the following:
Check DBMS settings to determine whether cryptographic mechanisms are used to prevent the unauthorized disclosure of information during transmission. Determine whether physical measures are being used instead of cryptographic mechanisms. If neither cryptographic nor physical measures are being utilized, this is a finding.
To check that network encryption is enabled and using site-specified encryption procedures, look in SQLNET.ORA located at $ORACLE_HOME/network/admin/sqlnet.ora. (Note: This assumes that a single sqlnet.ora file, in the default location, is in use. Please see the supplemental file “Non-default sqlnet.ora configurations.pdf” for how to find multiple and/or differently located sqlnet.ora files.) If encryption is set, entries like the following will be present:
SQLNET.CRYPTO_CHECKSUM_CLIENT = requested
SQLNET.CRYPTO_CHECKSUM_SERVER = required
(The values assigned to the parameters may be different, the combination of parameters may be different, and not all of the example parameters will necessarily exist in the file.)Oracle Database 12c Security Technical Implementation Guide :: Release: 16 Benchmark Date: 24 Jan 2020
This seems pretty straight forward, except for one thing: The paramaters shown in the example from the STIG support Oracle’s native encryption algorithms, not TLS encryption using PKI. Why does that matter, you ask? This is where those additional STIG controls I mentioned come into play.
STIG control V-61747 is a CAT II control that requires that any encryption of data in motion be performed using approved FIPS 140-2 encryption modules. It states, “Applications utilizing encryption are required to use approved encryption modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. FIPS 140-2 is the current standard for validating cryptographic modules…”
I wrote about FIPS compliance and the Database STIG in a previous post, entitled “FIPS is a Four Letter Word“. As it turns out, because of the requirement to use SHA-2 we noted earlier, there is only a single supported, FIPS-compliant cipher suite available for use in Oracle’s encryption suite for the 12c family of databases, which includes 12cR1, 12cR2, 18c, and 19c: SSL_RSA_WITH_AES_256_GCM_SHA384.
It also turns out that FIPS compliance in turn requires the use of PKI, which I have described in this paper, “Configuring SSL for Oracle Client Authentication and Encryption with DoD Common Access Cards Using Microsoft Certificate Store”. PKI involves the use of public and private keys for encryption and authentication.
So while the example configuration given in the control does encrypt data in motion, it is not the right kind of encryption to satisfy all STIG controls. aChecking off the box for this control just because you happen to find parameters like SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER in your sqlnet.ora file does not mean that you have truly STIG-compliant encryption in place.
Only by implementing proper FIPS-compliant cipher suites with TLS/PKI can you satisfy all of the required encryption controls. This need for PKI leads us to our next CAT I STIG control, which requires the proper securing of private keys on the database server.
V-61543: The DBMS, when using PKI-based authentication, must enforce authorized access to the corresponding private key.
The cornerstone of the PKI is the private key used to encrypt or digitally sign information.
If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and can pretend to be the authorized user.
Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.
All access to the private key of the DBMS must be restricted to authorized and authenticated users. If unauthorized users have access to the DBMS’s private key, an attacker could gain access to the primary key and use it to impersonate the database on the network.
Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including ‘SSL’, such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.Oracle Database 12c Security Technical Implementation Guide :: Release: 16 Benchmark Date: 24 Jan 2020
If your database is using public key-based authentication, then that private key is stored in the server’s Oracle Wallet, which must be protected from unauthorized access or alteration.
To confirm PKI authentication, check the server’s sqlnet.ora file for any of the following entries:
SSL_CIPHER_SUITES=(SSL_cipher_suiteExample) SSL_VERSION = 1.2 SSL_CLIENT_AUTHENTICATION=FALSE/TRUE
If these entries exist, then confirm the the location of the wallet and make sure that it’s location and files are only readable to authorized users.
WALLET_LOCATION = (SOURCE= (METHOD = FILE) (METHOD_DATA = DIRECTORY=/wallet)
In most cases, the wallet directory should be owned by and only readable by the OS user which runs the network listener. In the case of an Oracle RAC configuration, or stand-alone Oracle Grid Infrastructure, this may not be the same user that owns the Oracle database software.
You may also want to set the “immutable” flag on the wallet files, to prevent unauthorized changes to them. Once set, this flag will prevent all users, including root, from making any changes to the file. In the above example, the wallet was located in the “/wallet” directory. To lock down wallet files in /wallet, you would execute the following commands:
# cd /wallet # chattr +i *.*
To unset the immutable flag, use the “-i” option instead of “+i”.