Learn about the shared responsibility model for Platform as a Service (PaaS) using Pantheon as an example. A CoGuard scan of a Pantheon MySQL instance revealed various security concerns, highlighting the need for proactive configuration checks when using PaaS providers.
PaaS systems reduce the amount of work for DevOps teams. But when it comes to security benchmarks, it remains your responsibility to double check the work/configurations of the PaaS provider. There are no guarantees that a PaaS provider has configured their defaults to meet your risk expectations or to pass security benchmarks. We look at using CoGuard to help identify configurations of PaaS providers and evaluate the configurations according to security benchmarks and best practices.
DevOps is hard. Configuring and hardening infrastructure is time consuming and difficult, especially for new projects on tight timelines.
One way around it is to start using a Platform as a Service (PaaS). Choosing a third party provider, who has expertise in the setup and configuration of specialized technologies. The PaaS provider offers speed, convenience and security. They manage the setup, maintenance and monitoring of the infrastructure required. The PaaS provider may also have passed compliance audits and help ensure adherence to compliance frameworks. This allows development teams to work on building and shipping features faster.
It is easy to assume, perhaps even believe, that if you choose the ‘right provider’, then they have you covered.
We decided to evaluate the default application configurations of a PaaS provider for Wordpress & Drupal CMSs. Let’s look at the default configuration of MySQL on Pantheon.
Sidebar: These configuration settings for application level controls are a shared responsibility between the PaaS vendor and you the application developer. Our goal is to show how to access and evaluate the configuration of PaaS applications, analyze the configuration as related to best practices and benchmarks.
We set up a free account on Pantheon, and created a Drupal 10 project. Connected to the Dev MySQL instance from the command line. Export the MySQL configuration parameters using SHOW VARIABLES; and copying the result to a text editor. And format to INI format and save in my.cnf format. We then scanned the INI file using CoGuard.
Register for Pantheon account
Create a Drupal site
Choose Drupal Version - Drupal 10
Specify Configuration Details
Deploy Drupal Site
Connect to the ‘Dev’ environment
Database » Connection Info - Copy Command Line access
Access MySQL Database from Command Line and ‘SHOW SETTINGS;’
Copy the terminal output and grep the results into INI format. (This is step 9 we just didn't have a great image of grep).
Run CoGuard CLI (version 0.2.14) in the folder containing the INI file.
CoGuard (full report) detected 12 failed configuration and security checks. These include:
There are a number of configuration settings that should be addressed to help ensure the security of the MySQL instance used.
The setting TLS_VERSION was kept at its default, namely TLSv1.1,TLSv1.2,TLSv1.3. This is generally not recommended, since TLSv1.1 has the potential to cause an exploit.
To choose tmp as the location where local queries can be loaded as files from (secure_file_priv) comes with the danger that this is a location where other applications generally also write files into, and it is the least protected one. Hence, an attacker who can successfully compromise one application on the server may be able to inject his own queries this way.
MySQL has many ways to define password policies for the users that are stored inside. The default ones are okay, but have a length of 8, which is considered the absolute bare minimum length. Furthermore, in the configuration on the server, the set passwords never expire, which is also a violation of many best practices and security benchmarks.
“Fail early, fail often” - John Maxwell
While allowing certain inconsistencies with your queries may be okay for your application, it may cause data corruption down the road. Hence, the enabling of the SQL_MODE of STRICT_ALL_TABLES ensures that you get errors as early as possible and it forces you to only send well-written queries to the engine. Pantheon has this not enabled by default.
When we created the test instance of the Drupal page, we were able to access the MySQL database directly from the internet. While there was some obfuscation done (different port, cryptic database name and subdomain, etc,), this is putting the databases directly at risk. There are instructions on how to tunnel connections to the server, but this requires an aware user.
In some paid plans, this is the default.
PaaS offers so many benefits. It can help teams go to market faster by enabling faster development, increased efficiency and scalability to handle traffic and changing demand, and help reduce infrastructure cost, license fees and the talent required to support and maintain the infrastructure. The disadvantages include unknown security and configuration risks that might not match your expectations or requirements, integration challenges with expanding toolsets, and third-party vendor lock-in.
It is possible to evaluate the configuration and security of many PaaS vendors. Sometimes it requires jumping through a few hoops like our my.cnf INI example above. At CoGuard, we provide static analysis for configuration files. And we’re truly interested in how systems are configured (or misconfigured) and the security risks that are present.
We can work with your IaC tools, IaaS provider, and applications in a variety of deployment models. Let CoGuardcan find configuration files in your infrastructure code repository. Or You can also connect your cloud provider to discover configurations and settings against known security frameworks and best practices.
If you have questions about static analysis for configuration files, or about the configuration settings for other PaaS providers, schedule a time to talk with our team.
