New way to secure your Oracle database with Puppet
For a long time, already Enterprise Modules provided the ora_secured module. A Puppet module that allowed you to ensure that your database is compliant with the Center for Internet Security (CIS) benchmark. But this module was original designed for use with Oracle 12c in in the mean time we have Oracle 19c. We now have multiple versions of Oracle and numerous versions of the CIS benchmarks for Oracle. Thus, time to review our current design and provide you with a new and enhanced module.
Why Puppet is a perfect match for CIS compliance
We think Puppet is e perfect fit for ensuring CIS compliance. Every half hour (or different interval when you have another Puppet schedule) Puppet comes by and ensures that all of the security controls you think are essential are assured. Not only reported about but also immediately fixed. The Puppet reporting, especially in Puppet Enterprise, allows you to show your auditors that your database has been compliant. It also reports any fixes Puppet had done when it somehow came into a non-compliant state.
The new way to manage Oracle CIS compliance with Puppet
The ora_secured module is the Puppet implementation of the Center for Internet Security (CIS) benchmark for Oracle database. At this point in time it supports the following versions:
See here for a way to get started with the ora_secured module.
Design goals for the new version
The design goals for the new ora_secured module where: Easy to apply Easy to skip controls that you don’t want or need Easy to change values that are variable within the CIS benchmark Easy to exclude some objects from the control Correlate between the changes Puppet applies and the CIS document. Easy to upgrade to an new CIS version Easy to upgrade to a new Oracle version Let’s go over these design goals.
Easy to apply
Securing your database with the ` ora_secured module is as easy as adding one line of puppet code to your manifest. In its most basic form:
ora_secured::ensure_cis{'MYDB':}
is enough.
Easy to skip controls
The CIS benchmark is very extensive. Applying ALL controls can make your database too secure for your application. The ora_secured module allows you to specify what controls you want to skip. You can for example use the parameter skip_list
ora_secured::ensure_cis {'MYDB':
skip_list => [
'audit_sys_operations_is_set_to_true',
'audit_trail_is_set_to_db_xml_os_dbextended_or_xmlextended',
'os_roles_is_set_to_false',
'remote_listener_is_empty',
You can also use hiera to skip certain controls. Here is an example of that:
ora_secured::controls::audit_sys_operations_is_set_to_true::mydb: skip
ora_secured::controls::audit_trail_is_set_to_db_xml_os_dbextended_or_xmlextended::mydb: skip
ora_secured::controls::os_roles_is_set_to_false::mydb: skip
ora_secured::controls::remote_listener_is_empty::mydb: skip
Easy to customize values
For specific controls, the CIS benchmark allows you to specify a value. To be compiant with the CIS benchmark, the specified value must be within a specific range. The ora_secured module supports this. Let’s look at an example. The control failed_login_attempts_is_less_than_or_equal_to_5 guards that the number of failed login attempts is 5 or less (as the name states). The default value the ora_secured module enforces is 5. But you can make it less. You can use the value 3.
ora_secured::controls::failed_login_attempts_is_less_than_or_equal_to_5::preferred_value: 3
Is a way to do this. To ensure you stay compliant, the ora_secured module enforces that the values stay within the bounds of CIS range. When you specify a value that is outside of the range, Puppet will not accept it. Here is an example when we specify 6:
Error: Evaluation Error: Error while evaluating a Resource Statement, ora_secured::Controls::Failed_login_attempts_is_less_than_or_equal_to_5[TEST]: parameter 'preferred_value' expects an Integer[0, 5] value, got Integer[6, 6] (file: /root/examples/apply_one_control.pp, line: 5) on node ora_secured
Easy to exclude some objects
Many CIS controls layout settings that must apply to all objects in the database. Some organizations battle with this. Most of the time, there are just a few objects that have to deviate from a control to keep the application working. The ora_secured module supports this. You can specify exclusion rules. Let’s look at an example and take the failed_login_attempts_is_less_than_or_equal_to_5 control again. You have one Oracle profile MY_APP_PROFILE for your application that explicitly needs a value of 6. You can do this by putting the MY_APP_PROFILE on the exclusion list in hiera. Here is how to do that:
ora_secured::controls::failed_login_attempts_is_less_than_or_equal_to_5::exclude: MY_APP_PROFILE
Correlate Puppet changes to CIS
Although it is excellent that Puppet guards the compliance of your database, it is good to know that when Puppet changes something, WHY it changed something. What was the control that caused this? And preferably, what paragraph in what version of the CIS benchmark states this.
The ora_secured module helps you with this. Here is some example output:
Notice: /Stage[main]/Db19c::V1_0_0::P5_1_1_1::Test/ora_secured::Controls::Execute_is_revoked_from_public_on_network_packages[TEST]/ora_secured::Internal::Revoke_public_grants[DBMS_LDAP@TEST]/Ora_object_grant[PUBLIC->SYS.DBMS_LDAP@TEST]/permissions: revoked the EXECUTE right(s)
Notice: /Stage[main]/Db19c::V1_0_0::P6_1_1::Test/ora_secured::Controls::User_audit_option_is_enabled[TEST]/ora_secured::Internal::Audit_option[USER@TEST]/Ora_statement_audit[USER@TEST]/ensure: created
Notice: /Stage[main]/Db19c::V1_0_0::P6_1_2::Test/ora_secured::Controls::Role_audit_option_is_enabled[TEST]/ora_secured::Internal::Audit_option[ROLE@TEST]/Ora_statement_audit[ROLE@TEST]/ensure: created
Notice: /Stage[main]/Db19c::V1_0_0::P3_1::Test/ora_secured::Controls::Failed_login_attempts_is_less_than_or_equal_to_5[TEST]/ora_secured::Internal::Profile_setting[failed_login_attempts@TEST]/Ora_profile[DEFAULT@TEST]/failed_login_attempts: failed_login_attempts changed 10 to 5
Notice: /Stage[main]/Db19c::V1_0_0::P6_2_1::Test/ora_secured::Controls::Create_user_action_audit_is_enabled[TEST]/ora_secured::Internal::Audit_policy[actions@TEST@create_user]/Ora_audit_
As you can see all of the messages contain: The database version of the CIS benchmark (e.g. /Db19c) The document version of the CIS benchmark (e.g. ::V1_0_0) The paragraph in the CIS benchmark (e.g. ::P6_2_1) The database that is changed (e.g. ``::Test) The name of the control (e.g. create_user_action_audit_is_enabled`) This way, you can always see what the reason is for a change.
Upgrade to a new CIS or Oracle version
Because the exclusion lists, preferred values, and skip lists, are bound to the name of the control, your customizations will most of the times be compatible with newer versions of a CIS benchmark. So when a newer version comes. You only have to change the doc_version property. Let’s see an example. Let’s say a V1.1.0 for the db19c is available.
ora_secured::ensure_cis {'MYDB':
product_version => 'db19c',
doc_version => 'V1.1.0'
}
This is enough to start using the new CIS version. Sometimes CIS. Of course you will still have to look if new controls are available that you want to skip or customize. Also, sometimes the value of a configuration item changes. This will cause a new control in the ora_secured module. Let’s look at this in a contrived example.
Let’s say that in the CIS document, the setting for the number of failed login attempts has been changed from a value of 5 or less to a value of 3 or less. The original control was named: failed_login_attempts_is_less_than_or_equal_to_5. It will still be available. But a new control is also available. It is now called failed_login_attempts_is_less_than_or_equal_to_3. Just change these values in your skip_lists, excludes and preferred value settings is enough.
Conclusion
In this blog post we have shown you easy it is to secure your Oracle database with Puppet. If you would like to know more, contact us at info@enterprisemodules.com or by phone: +31 (0)653 847 326
About us
Enterprise modules is the leading developer of enterprise-ready puppet modules for Oracle databases and Oracle WebLogic. Our puppet modules help sysadmins and DBAs to automate the installation, configuration, and management of their databases and application server systems. These modules allow them to make managed, consistent, repeatable, and fast changes to their infrastructure and automatically enforce the consistency.
