Forum Stats

  • 3,836,737 Users
  • 2,262,175 Discussions



Russ Fleming
Russ Fleming Member Posts: 2 Blue Ribbon
edited Feb 25, 2020 1:33PM in Database Security - General

We are a red hat 7 shop running Oracle Database 12c Enterprise Edition Release - 64bit.

> uname -a

Linux ba-prod-db 3.10.0-1062.9.1.el7.x86_64 #1 SMP Mon Dec 2 08:31:54 EST 2019 x86_64 x86_64 x86_64 GNU/Linux

> cat /etc/redhat-release

Red Hat Enterprise Linux Server release 7.7 (Maipo)

> sysctl crypto.fips_enabled

crypto.fips_enabled = 1

Database STIGs require FIPS be on in the database. They basically say put SSLFIPS_140=TRUE in a fips.ora. But I cannot find any discussions on best practices.

What is the guidance on enabling FIPS in the database when it is enabled in the OS? Are they in conjunction with each other? Compatible? One or the other?

I'm looking for direction instead of blindly turning things on without understanding.


  • pmdba
    pmdba Member Posts: 103 Bronze Badge
    edited Feb 21, 2020 12:35AM

    FIPS used by Oracle is completely separate from FIPS used by the operating system - it is a separate set of crypto modules used for only for Oracle-related purposes. You will need to enable both if FIPS is actually required for your database (OS FIPS support should be enabled regardless).

    The key to the STIG control V-61747 is the phrase "If encryption is required but not configured". The requirement for encryption is based on your individual system specification, not the STIG itself. At a minimum this generally should apply to any network communication that crosses a network enclave boundary (like a firewall), but is often specifically not required between an application server and a database server that are sitting on the same network segment. The details and requirements will be specific to you, so if you don't have a design requirement for FIPS-level encryption driven by another DOD regulation or STIG then in my experience this control is just straight-up not applicable to your system. Also, even if you have a requirement just turning it on doesn't do anything unless your database and application are engineered to use FIPS-related features where it matters.

    For example, the DBFIPS_140 initialization parameter enables FIPS compliance for your data-at-rest encryption provided through the Transparent Database Encryption feature (TDE), and through use of the DBMS_CRYPTO package. If you haven't configured any tablespaces, tables, or columns using TDE or any stored procedures to use DBMS_CRYPTO, then turning it on won't have any effect for you. Whether you should use TDE is a whole other discussion, depending on what type of storage you're using and whether or not it provides its own encryption.

    Similarly, enabling SSLFIPS_140=TRUE in fips.ora won't do anything for you if you aren't using SSL communications (TCPS) over the network. This is not the default network protocol used by OracleNet - even basic encrypted OracleNet. SSL requires Public Key Encryption (PKE) certificates and wallets on both the client and the server. If you must also support the standard OracleNet it will require a non-standard port number (i.e. not 1521) as well. Here's a paper on basic implementation of TCPS in a DOD environment (which I infer from the STIG reference) for database authentication and encryption. If you wind up implementing SSL, be aware of the following:

    • If you have just a basic DB install, then the $ORACLE_HOME/ldap/admin/fips.ora file is easy to find. If you are running Oracle Grid Infrastructure, things get slightly more complicated. Network listener operations are handled by the GI home, so for inbound connections to the listener $ORACLE_HOME/ldap/admin/fips.ora is in the Grid Infrastructure home directory. Outbound connections, like database links to other servers, are all handled from the Database home directory.
    • If your connection crosses through a firewall be aware that many firewalls perform stateful packet inspection - confirming for instance that your OracleNet traffic really looks like OracleNet traffic. With encryption enabled, the firewall is unable to perform the packet inspection and may reject the connection out of hand, even though it allows a "tnsping" packet through without issue. This requires modification of the firewall exception/rule to turn off the packet inspection, which you would have to coordinate with the owners of the firewall.
    • Enabling SSL with FIPS will affect your system performance, per MOS Doc ID 2279002.1.
    • Over the years there have been a number of bugs regarding FIPS enforcement in both TDE and SSL - everything from auto-open wallets not opening to authentication failing to memory leaks in the listener. Keep up with all patches, not just security patches.

    If you haven't already found it, here's an Oracle Doc link to implementation and confirmation of each setting:…  Also pay attention to the valid cipher suites used by Oracle for FIPS compliance. The FIPS standard changes over time as new cipher suites are added or deprecated, and Oracle doesn't necessarily keep up within a particular database version the way that Red Hat does for the OS; they use a third-party crypto module, RSA BSAFE® Crypto-C Micro Edition, with its own FIPS-compliant certification. It may happen from time to time that the only way to stay FIPS compliant is to upgrade to a newer database version.

    Lastly, since you are concerned with STIG validation, you should also know that your database version is only 9 months away from end of support in November 2020. Since the Oracle DB STIG also requires that you run current, supported versions of the software (V-61535, V-61539) you should seriously consider an upgrade to 19c - the long-term supported version of the 12c family, which gets you all the way to March of 2023 - as soon as possible.

  • Russ Fleming
    Russ Fleming Member Posts: 2 Blue Ribbon
    edited Feb 19, 2020 2:23PM

    Thanks for the thorough reply. I have some questions but I quickly want to to check where you got the "end of support" information. The link is dead for me.

    What I'm seeing is patching end Nov-2020 and support goes through 2023. So what is your definition of end of support? I have plans to upgrade to v19 but time constraints are what they are. Just want to make sure I understand to ensure I attach a proper priority.

  • pmdba
    pmdba Member Posts: 103 Bronze Badge
    edited Feb 20, 2020 11:23PM

    The correct link is here:

    This document is current as of January 2020. Note the definitions of Premier, Extended, and Sustaining Support on pages 2 and 3, and the support lifetime schedule for Oracle Database on page 4.

    Only products under Premier or Extended Support receive security patches. Premier Support for 12.2 ends November 2020, 18c support ends in June 2021. Note that Extended Support is not available for either 12.2 or 18c. The STIG requires that all Oracle software versions in use must be actively receiving security patches, which 12.2 will not be after this October's patch release. When the next quarterly patchset is released in January 2021, 12.2 will no longer be STIG-compliant and must be turned off. Only 19c is scheduled to receive Premier Support through 2023 and Extended Support through 2026. After June 2021 it will be the only supported/patched member of the "12.2" family of database versions.

  • pmdba
    pmdba Member Posts: 103 Bronze Badge
    edited Feb 25, 2020 1:33PM

    This thread got me thinking, so I dug back into previous research and newer documentation again for a little more detail. The results of that research is now included in a blog post, "FIPS is a Four Letter Word".

    Also, you may want to check out this webinar on why to upgrade to Oracle 19c.

    "Upgrading to Oracle Database Release 19c is now essential. Why? Support is expiring soon for all previous releases of the database. Consider this about prior releases:

    • – Support costs extra money and all support ends in the middle of 2022.
    • –  All support ends in 2020. That’s it, it’s all over later this year!
    • 18c – All support ends in 2021. That’s it, no more support next year!"