Cyber Security

Shared Responsibility Model for PaaS - A Look at Pantheon

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.

Albert Heinle
Written by
Albert Heinle

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.

Why do people use PaaS services?

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. 

Image: CIS Shared Responsibility Model Characteristics by Cloud Environment

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

Step 1: Register for a Pantheon account

Create a Drupal site

Step 2: Create a Drupal Site

Choose Drupal Version - Drupal 10

Step 3: Select Drupal 10

Specify Configuration Details

Step 4: Specify Site Name & URL

Deploy Drupal Site

Step 5: Deploy the Drupal Site

Connect to the ‘Dev’ environment

Step 6: Access the Dev environment

Database » Connection Info - Copy Command Line access

Step 7: Copy the Database Connection string

Access MySQL Database from Command Line and ‘SHOW SETTINGS;’

Step 8: Access MySQL from command line

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. 

Step 10: Run CoGuard on the folder containing INI file

CoGuard Results

CoGuard (full report) detected 12 failed configuration and security checks. These include:

  • 9 High Priority
  • 1 Medium Priority
  • 2 Low Priority

There are a number of configuration settings that should be addressed to help ensure the security of the MySQL instance used. 

Old TLS versions are allowed to be used when connecting.

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.

The location where queries stored on the file system can be loaded from is `/tmp`.

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.

Password policies were kept at default

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.

Strict SQL interpretation

“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.

Database is accessible from the web, unless configured otherwise

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.

Next Steps

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. 

  • Sign up for a CoGuard account. 
  • Install the Command Line tools. 
  • Start scanning your configurations.

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.

Explore a test environment

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Check out and explore a test environment to run infra audits on sample repositories of web applications and view select reports on CoGuard's interative dashboard today.