Cloud security policy configuration in AWS, Azure and GCP

Explore cloud security policy configurations in AWS, Azure and GCP using native security tools in this excerpt of 'Multi-Cloud Architecture and Governance' by Jeroen Mulder.

Modern security strategies should take an inside-out approach, not outside-in.

"Understanding how to protect assets inside the security perimeter is far more important than focusing on preventing attackers from getting in," said Jeroen Mulder, author of Multi-Cloud Architecture and Governance.

The book, published by Packt Publishing, advocates for an approach to multi-cloud based on the enterprise architecture framework. Mulder, a certified enterprise and security architect, emphasized that security should abandon its technology-first approach in favor of a business-first philosophy.

In the following excerpt of Chapter 14 of Multi-Cloud Architecture and Governance, Mulder, head of applications and multi-cloud services for Fujitsu in the Netherlands, compares AWS vs. Azure vs. Google Cloud Platform (GCP) security policies using native tools. The book's cloud security policy configuration tutorials also address settings to help organizations meet Center for Internet Security (CIS) benchmarks for compliance.

Be sure to check out a Q&A with Mulder to learn how his background as an enterprise architect influenced his book. Also, download a PDF of Chapter 14 to read the entire chapter for actionable guidance on cloud security policy implementation in AWS, Azure and GCP.

Multi-Cloud Architecture and Governance cover imageClick to learn more about
Multi-Cloud Architecture and
Governance by Jeroen Mulder.

Implementing security policies

We have studied the compliance and security frameworks and we've defined our security baseline. Now we need to implement it in our cloud environments. In this section, we will explore implementations in the major clouds, using the native security platforms. Since CIS is widely and globally adopted as the baseline for security policies, all sections will explore specific settings that CIS benchmarks recommend for the different platforms. Links to the benchmarks are provided in the Further reading section of this chapter. CIS provides recommendations, but also documents how policies should be implemented.

For example, in GCP there is a recommendation to "ensure Cloud Audit Logging is configured properly across all services and all users from a project." CIS benchmarks also guide users to find where the setting needs to be configured and how; in this example, by going to audit logs at https://console.cloud.google.com/iam-admin/audit or by configuring it from the command line:

gcloud organizations get-iam-policy ORGANIZATION_ID
gcloud resource-manager folders get-iam-policy FOLDER_ID
gcloud projects get-iam-policy PROJECT_ID

The format in the CIS benchmarks is always the same, for all cloud platforms.

Implementing security policies in Azure Security Center

Azure Security Center is a native service of Azure. In other words, you don't need to install or configure anything. From the Azure console, Security Center can be accessed immediately by simply enabling it. It then starts monitoring workloads that you have deployed in Azure: virtual machines, databases, storage accounts, networking components, and other Azure services.

However, policies will need to be configured in Security Center. CIS lists some recommendations specific to Azure Security Center. The most important one is to activate the standard pricing tier in Security Center: this enables threat detection for all networks and VMs in the Azure tenant. Every CIS recommendation to implement a policy comes with an explanation. In the case of enabling the standard pricing tier, the rationale is that it allows greater defense-in-depth, with threat detection provided by the Microsoft Security Response Center (MSRC).

Enabling the standard pricing tier and adjusting settings is done through the Security Center blade in the portal at https://portal.azure.com/#home, as shown in the following screenshot:

Overview of the Security Center blade in the Azure portal
Figure 14.1 -- Overview of the Security Center blade in the Azure portal

The next action is to enable the monitoring agent to actually collect the data and make sure that the default policy setting, Monitor system updates, is not set to Disabled. Enabling this setting retrieves a daily list of available security and critical updates from Microsoft, both for Windows systems and for systems that run Linux distributions. These are the basic configuration settings to get Security Center started.

The next step is to implement the security settings. In Security Center, enable settings for the following:

  • Scanning vulnerabilities in operating systems
  • Enforcing endpoint protection
  • Monitoring disk encryption
  • Monitoring network security groups
  • Monitoring web application firewalls
  • Monitoring next-generation firewalls
  • Vulnerability assessment
  • Monitoring blob storage encryption
  • Monitoring just-in-time (JIT) network access
  • Monitoring adaptive application whitelisting
  • Monitoring SQL auditing
  • Monitoring SQL encryption

Lastly, there are a few settings that enable communication in case of high-severity alerts, by sending email notifications or text messages.

Tip

Azure has something more than just Azure Security Center: Azure Sentinel, a native SIEM solution. Sentinel is an intelligent defense-in-depth solution, especially when activating the security framework of MITRE ATT&CK® in Sentinel. ATT&CK is a knowledge base that is constantly updated with the latest threats and known attack strategies. A group of developers under the name of BlueTeamLabs have published templates and code to implement ATT&CK in Sentinel. It's worthwhile taking a look at this at https://github.com/BlueTeamLabs/sentinel-attack.

Implementing security policies in AWS Security Hub

AWS offers a single security dashboard with AWS Security Hub. The solution aggregates monitoring alerts from various security solutions, such as CloudWatch and CloudTrail, but also collects findings from Amazon GuardDuty, Amazon Inspector, Amazon Macie, AWS Identity and Access Management (IAM) Access Analyzer, and AWS Firewall Manager. CloudTrail, however, is the key element in Security Hub. CloudTrail constantly monitors the compliance of accounts that are used in the AWS environment. It also performs operational auditing and risk auditing, meaning it keeps track of all activity that is started from the console in your environment, enables analysis of changes to resources, and detects unusual activity. It's fair to say that CloudTrail is the engine underneath Security Hub.

Security Hub makes it easy to start monitoring all activity in your AWS environment. It's accessible from the AWS console, as shown in the following screenshot:

Accessing Security Hub in the AWS console
Figure 14.2 -- Accessing Security Hub in the AWS console

There are a couple of things that need explaining in the preceding screenshot. The top part of the screen shows the security baselines that can be enrolled by default: Enable AWS Foundational Security Best Practices v1.0.0 and Enable CIS AWS Foundations Benchmark v1.2.0 have been ticked by default. The third one is the PCI DSS framework. PCI DSS stands for Payment Card Industry Data Security Standard and is specific to financial institutions.

In the lower part of the screen, we see all the integrations that Security Hub offers:

  • GuardDuty: Amazon's solution for threat detection.
  • Inspector: This tool assesses applications for exposure, vulnerabilities, and deviations from best practices valid for these applications.
  • Macie: This solution monitors the data security and data privacy of your data stored in Amazon S3 storage.
  • IAM Access Analyzer: This tool keeps track of accounts accessing environments in AWS and whether these accounts are still compliant with security policies.
  • Firewall Manager: This tool enables centralized management of all firewalls in the AWS environment.

By clicking the Enable Security Hub button, the mentioned baselines with the named integrations will be enrolled.

The CIS baseline should definitively be implemented as the worldwide accepted standard for securing online environments. Specific to AWS, CIS includes the following recommendations for settings to control security policies:

  • Ensure CloudTrail is enabled in all regions.
  • Ensure CloudTrail log file validation is enabled.
  • Ensure that an S3 (storage) bucket used to store CloudTrail logs is not publicly accessible.
  • Ensure CloudTrail logs are integrated with CloudWatch logs.
  • Ensure AWS Config is enabled in all regions.
  • Ensure S3 bucket access logging is enabled on CloudTrail S3 bucket.
  • Ensure CloudTrail logs are encrypted at rest using KMS CMKs (Key Management Services -- Customer Master Keys).
  • Ensure rotation for customer-created CMKs is enabled.
  • Ensure Virtual Private Cloud (VPC) flow logging in all VPCs.

Obviously, these are not all the settings: these are the most important settings for getting the logging and monitoring of security policies right. In the Further reading section, we include links to the various CIS benchmarks for the major clouds.

Implementing security policies in GCP Security Command Center

In GCP, we will have to work with Security Command Center. You can manage all security settings in Security Command Center and view the compliancy status from one dashboard. The concept is the same as AWS Security Hub -- Security Command Center in GCP comprises a lot of different tools to manage security in GCP environments. In the GCP cloud console, we'll see Security in the main menu. Hovering over the Security subheading will pop up the products and tools that are addressed in Security Command Center, as shown in the following screenshot:

Launching Security Command Center in the cloud console of GCP
Figure 14.3 -- Launching Security Command Center in the cloud console of GCP

Security Command Center does an inventory and discovery of all assets in the GCP environments and, next, starts monitoring them in terms of threat detection and prevention. One special feature that needs to be discussed here is Google Cloud Armor. Cloud Armor started as a defense layer to protect environments in GCP from Distributed Denial of Services (DDoS) and targeted web attacks. Cloud Armor has since been developed to a full security suite in GCP to protect applications using the functionality of Web Application Firewalls (WAFs).

Cloud Armor can be launched from the GCP console at https://console.cloud.google.com/. You won't find it under Security Command Center, but under Network Security, as shown in the following screenshot:

Menu of Cloud Armor in GCP
Figure 14.4 -- Menu of Cloud Armor in GCP

We can specify security policies in Cloud Armor, but GCP already included a list of policies that can be evaluated. These preconfigured policies are based on OWASP CRS -- the Open Web Application Security Project, a community that strives to find methodologies and practices to constantly improve the protection of online applications. CRS stands for Core Rule Set. Cloud Armor includes the top 10 OWASP threats in rule sets. The number one threat is the injection of hostile code in order to breach the application and get access to data. In Chapter 16, Defining Security Policies for Data, we will explore OWASP in more detail since this is all about securing applications and data.

However, OWASP does overlap with CIS, but OWASP merely identifies the threats, whereas CIS makes recommendations to avoid vulnerabilities and the chances of threats really being exploited. Misconfigured security, for example, is number 6 in the top 10 of OWASP. Insufficient logging and monitoring concludes the top 10. Both are heavily addressed in CIS.

The CIS 1.1.0 benchmark for GCP was released in March 2020. Specifically, for logging and monitoring, CIS recommends the following settings to audit security policies:

  • Ensure Cloud Audit Logging is configured properly across all services and users in a project.
  • Ensure sinks are configured for all log entries.

Note

A sink will export copies of all the log entries.

  • Retention policies on log buckets must be configured using Bucket Lock.
  • Ensure log metric filters and alerts exist for project ownership assignments and changes.
  • Ensure log metric filters and alerts exist for audit configuration changes.
  • Ensure log metric filters and alerts exist for custom role changes.
  • Ensure log metric filters and alerts exist for VPC Network Firewall rule changes.
  • Ensure log metric filters and alerts exist for VPC Network Route changes.
  • Ensure log metric filters and alerts exist for VPC Network changes.
  • Ensure log metric filters and alerts exist for cloud storage IAM permission changes.
  • Ensure log metric filters and alerts exist for SQL instance configuration changes.

As with Azure and AWS, these are the settings to audit the security policies against the CIS benchmark. In the Further reading section, we included links to the various CIS benchmarks for the major clouds.

Jeroen MulderJeroen Mulder

About the author

After studying journalism, Jeroen Mulder started his career as an editor for Dutch newspapers. In 2000, he joined the IT company Origin, later acquired by Atos, as a communication specialist in cross-media platforms. At Origin and Atos, he fulfilled a variety of roles, most recently as a principal architect. Since 2017, he has been working for Fujitsu, where he boarded as senior lead architect. In 2020, he was promoted to head of applications and multi-cloud services for Fujitsu in the Netherlands. Mulder is a certified enterprise and security architect, concentrating on cloud technology. This includes the architecture for cloud infrastructure, serverless and container technology, and application development, as well as digital transformation using various DevOps methodologies and tools.

Next Steps

Compare Azure Firewall vs. NSGs for network security

Why and how to create Azure service principals

How to implement principle of least privilege in Azure AD

Dig Deeper on Cloud security