The active following of CIS benchmarks is a great indicator if a system administrator has put in their due diligence to ensure that services on one’s infrastructure have been sealed as much as possible.

When using AWS, the RDS service allows for many different SQL engines, including Oracle’s MySQL. People often assume that they are being provided with something pre-vetted, i.e. having good default configurations. In this case, they would assume that, by default, if selecting a production database configuration in RDS, that the instance would be shipped with most benchmark recommendations.

As you can already guess from this lengthy introduction, this is not the case. Here are some of the things you need to consider and possibly fix before using the RDS instance as is:

The sql_mode

There are some safeguards in place that ensure the stability of the engine, as well as your data. These safeguards are specified in the system variable sql_mode, which is a space separated list of parameters. The MySQL default is

ONLY_FULL_GROUP_BY STRICT_TRANS_TABLES NO_ZERO_IN_DATE NO_ZERO_DATE ERROR_FOR_DIVISION_BY_ZERO NO_AUTO_CREATE_USER NO_ENGINE_SUBSTITUTION

(see documentation)

When spinning up an instance in AWS, you see that there is only one parameter set, namely NO_ENGINE_SUBSTITUTION.

CIS benchmarks recommend at least STRICT_ALL_TABLES and NO_AUTO_CREATE_USER. Additionally, we would also recommend ERROR_FOR_DIVISION_BY_ZERO, since otherwise, your data may contain unexpected null entries where a division by zero happened instead of failing. This leads to unclean data.

Passwords

It is important to have password policies in place. Retention and password strength are two of the most important fields. If the developers set passwords on the instances, there should be policies enforced. This is accomplished by the password validation plugin.

‍