Google Cloud Platform has passed annual audits for some of the most important security standards, including SOC 1, 2, and 3, ISO 27001, and PCI DSS. It also complies with HIPAA, CSA STAR, the EU-US Privacy Shield Framework, and MPAA controls, none of which require annual audits.

So if your organization is required to comply with any of these standards, then you know that Google has done its part. But this is a shared responsibility because your security processes and applications running on top of Google’s infrastructure also need to comply.

You’ll notice that Network is listed for both Google and the customer. That’s because Google takes care of some parts of networking and the customer takes care of the rest. One of the most interesting areas of shared responsibility for network security is protecting against distributed denial of service (or DDoS) attacks.

Google provides many features to help deal with DDoS attacks, but it’s up to the customer to use them properly. Here are some of the techniques.

Reduce the attack surface by

• Isolating and securing your deployment with firewall rules
• Google also provides anti-spoofing protection by default

Isolate your internal traffic from the external world by

• Deploying instances without public IPs unless necessary

Use Load Balancing

• Because a load balancer acts as a proxy that hides your internal instances

Use Cloud Armor

• This service is specifically designed to provide DDoS defense
• And it works with Load Balancing
• It protects against layer 3 and layer 4 DDoS attacks

Google Cloud also enforces API rate limits and resource quotas to prevent a spike in one customer’s activity from affecting other Cloud Platform customers.

Now it’s time to get back to the PCI DSS standard and how to comply with it. If your organization accepts credit card payments, then you need to comply with this standard or you could be fined. More importantly, if you have security flaws that allow hackers to steal credit card information from your systems, then it would be very damaging to both your customers and your reputation.

In the case study, GreatInside provides an interface for collecting credit card information, but it passes the validation and processing of the information to a Certified Payment Processor. This makes the company an SAQ A-EP merchant in PCI lingo. I’ll go over Google’s recommendations for how this type of merchant could comply with PCI DSS.

First, you have to check that the other parties involved (that is, Google Cloud and the payment processor) are certified for your volume of transactions (since there are different PCI DSS merchant levels based on the number of transactions). Google Cloud Platform has the highest level of PCI DSS certification, so that’s not a concern, but you’ll have to check your payment processor’s certification level because your volume might exceed their certification level.

Here’s a suggested architecture to handle the company’s credit card processing. Here’s how it works. A customer enters their credit card information in a form on your website. Then your payment-processing application sends the information to the external payment processor. Now the payment processor tells your application whether the card was accepted or declined. After that your payment processing application sends some or all of the response data to your core application, so it knows how to proceed with this customer.

You also need to log and monitor all of these interactions. Every instance involved in payment processing sends its logs to Stackdriver Logging and its alerts to Stackdriver Monitoring.

Now let’s move on to how you would set this up. To reduce the number of systems that need to be PCI-compliant, you have to fully isolate your payment-processing environment from the rest of your production environment. The best way to do this is to use a separate Google Cloud account, rather than just a separate project within your main account.

Then use IAM to grant access only to people who absolutely need to work on the payment-processing environment, such as people who will be deploying new versions of the application or managing the systems. These people must also pass a background check first.

To create the instances, you should first create your own Linux image that’s based on one of the preconfigured boot disk images and that contains the bare minimum of additional software needed to run your application. Then use this custom image when creating all of your VM instances.

To secure the network, create firewall rules that only allow three types of inbound traffic:

• HTTPS traffic from the load balancer to the payment form servers, so that customers can reach your payments page
• Credit card authorization responses from the external payment processor to your internal payment authorization servers, and
• VPN traffic from your internal office network to the VPN Gateway, so your authorized people can manage and audit the application and systems.

Then create firewall rules for outbound traffic. There’s only one type of outbound traffic you need to allow -- HTTPS traffic from the payment form servers to the external payment processor, so they can send credit card authorization requests.

Now all of the traffic in and out of the network is locked down, but you’ll also have to open up internal traffic, such as:

• From all of the instances to Google’s NTP servers for time synchronization, and
• SSH traffic from the VPN Gateway to all of the instances, so authorized people can access the systems for maintenance

OK, let’s move on to deploying your application. To be compliant, you have to make sure you're deploying the correct application every time, that it’s deployed securely, and that no other software packages are installed during the deployment. If you don’t already have an automated deployment tool, then you might want to use Cloud Deployment Manager, which could automate the creation of everything in your payment-processing environment, even the firewall rules. It could also help you create an audit trail of deployments.

Since you’ve used the same custom Linux image for all of your instances, you’ll need to install additional software on each instance. For example, some instances may need a web server, while others don’t, and each instance should only have the software it needs, which will reduce your security risks. To make this process consistent and reliable, it should be automated as well. The easiest way to automate software installation and configuration is to use a configuration management tool such as Chef, Puppet, or Ansible. Cloud Academy has courses on all three of these tools, so check one out if you’re not familiar with how to use any of them. 

There are a few packages that you’ll want to install on all instances. First there’s iptables. You can set it up to log all network activity to and from each instance. This data is required for PCI DSS compliance audits.

Second, each instance needs the Stackdriver Monitoring and Logging agents so it can send logs and alerts.

Third, each instance should run an Intrusion Detection System (or IDS) to alert you to suspicious activity.

Finally, your configuration management tool needs to securely retrieve and launch the latest version of your application. 

Even with an automated deployment, you’d still need to verify the integrity of the software being deployed. You could do this by running an automated checksum comparison against each package as it’s installed. You could also run an automated code analysis tool to check for security flaws.

Now let’s move on to logging. To be compliant, every step in the payment-processing environment has to be monitored and recorded. All instance activity and all user activity must be logged. Stackdriver Logging is a great service for collecting logs. You can record network traffic to and from your instances by enabling VPC Flow Logs on each subnet in your VPC.

By the way, you might think that we need to assign a service account to the instances so they can write logs to Stackdriver, but the default service account for VM instances already grants write access to Stackdriver, so you don’t need to configure that yourself.

I mentioned that user activity needs to be logged, but you also need to log the activity of people who have administrative access to the environment. The easiest way is to log all shell commands.

The amount of log information generated by all of this is likely to be very large, so you might want to export your Stackdriver logs to BigQuery if you need to do some complex analysis.

In addition to logging, you also need to set up real-time monitoring alerts, such as when your IDS detects any intrusion attempts.

After your environment is implemented, but before any production traffic flows through it, you have to validate the environment, either by contracting a Qualified Security Assessor if you’re a Level 1 merchant or by filling out the Self Assessment Questionnaire if you’re not a Level 1 Merchant.

Wow, that was a lot of work, wasn’t it? Well, if you’re going to be handling credit card information, you’ll be happy when your rigorous security design prevents damaging incidents.