Feedback: Implementation of a CSPM Solution on a large company

Introduction

As part of a mission, we had to find a solution capable of reducing risks in the cloud and enabling the client to have good management of their security posture, mainly in the public cloud. Several tools could address this issue, including CloudGuard by Checkpoint, CloudHealth by VMware, and Aqua Sec, to name a few. After a PoC where we were able to test and compare the capabilities of each tool in terms of security posture, CloudGuard was selected. The purpose of this article is not to compare the mentioned tools, as the choice depends essentially on the context, but to first present the reasons why CloudGuard was selected, and secondly, the steps for its implementation within the client's environment.

CloudGuard

About the tool

CloudGuard is a CSPM tool offered by Checkpoint in the form of a SaaS platform.

CloudGuard is a solution that offers multiple features:

• Inventory: Through dashboards, it provides visibility into statistics based on the results of the tool's analyses.
• Posture Management: It manages the compliance of cloud resources. The tool includes several well-defined sets of rules derived from standards (CIS benchmark, GDPR, etc.), to which the client can add custom rule sets. These rule sets, applied to the client's cloud accounts, highlight discrepancies between the declared security policy and the actual security state.
• Shiftleft: This feature allows for compliance checks on Infrastructure as Code (IaC) templates (Terraform and CloudFormation).
• Intelligence: Based on the analysis of account activity logs and network logs to detect flows from malicious sources.
• CloudBots: The tool provides an automated remediation process for configuration errors detected during its analyses.
• Workload Protection: CloudGuard protects serverless functions and Kubernetes containers.

CloudGuard arguments that convinced the client

The client based its choice of CloudGuard on the following key criteria:

• Cloud-agnostic tool: The client's environment, initially on-premise, now extends to the cloud. Therefore, the client needed a central tool that could interact with both internal and cloud environments. In this project, the cloud environment is provisioned from the internal CI/CD chain. Scans are also performed before deployment (using the Shiftleft functionality).
• Autonomy in writing compliance rules: The ease of writing rules was particularly convincing. The tool uses its own language (GSL). The client wanted to use a CSPM tool to harden its landing zone. CloudGuard demonstrated that it was possible to create rules that could target not only the landing zone but also resources deployed by project teams.
• Nearly native integration with other tools already present in the client's environment (ticketing tools, security management systems, etc.).
• Presence of a feature to ensure compliance of resources before deployment to the cloud: Shiftleft.

The following features were prioritized with the goal of having two levels of control with the tool:

• Shiftleft for compliance checks before deployment

• Posture management for compliance of resources deployed in the cloud.

  

Integration into the client's environment

The integration of CloudGuard has been done only with the AWS environment for now, as the client felt it was not mature enough in managing its cloud platforms provided by other providers.

A- Onboarding of accounts

This step involves granting CloudGuard the necessary permissions to analyze an account. Specifically, an IAM role must be created on the AWS account and will be assumed by another third-party account managed by CloudGuard.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<CloudGuard_ACCOUNT_ID>:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "123456789012345678901234567890"
                }
            }
        }
    ]
}

On the CloudGuard side, it is necessary to create an AWS environment by passing the role ARN and the external ID. The external ID is important as it helps mitigate the issue of the "confused deputy".

Attached to this role will be policies that allow CloudGuard to analyze the configuration of the account's resources.

To manage AWS accounts, CloudGuard has two modes of operation:

• Monitor mode, which involves attaching only read permissions to the previous role.
• Full protection mode, which includes the monitor mode and additional write permissions on certain cloud resources such as security groups and EC2 instances.

The client confirmed its deployment strategy based on the following considerations:

• Do I want to onboard all existing accounts or only a portion? In this case, the client chose to onboard all of them, and this was done automatically via Terraform.
• How to onboard future accounts? For this project, the client chose to proceed with automatic onboarding.
• How to verify that an account has been successfully onboarded in the solution? In this case as well, the client wanted to automate this verification.

Onboard all accounts of the organization (around 200).

For this requirement, two options seemed suitable:

• Automation script provided by Checkpoint. This script allowed onboarding the entire AWS organization of the client. It creates a CloudFormation stack that contains the role and policies on each AWS account.

  

  • Using the CloudGuard Terraform provider. This method involves onboarding each account via Terraform.

  The latter method was the most suitable. The Python script would have been difficult to maintain for the team without significant code adaptation. Whereas in the CI/CD pipeline, the primary Infrastructure as Code (IAC) tool is Terraform, managing CloudFormation stacks deployed by the Python script would have been effort-intensive. With this method, the management of Terraform states could be done at a single point.

Automatically onboard future AWS accounts.

Historically at the client's organization, the creation of a new AWS account is done through a subscription process. When a project team needs an account, they have to request it through a portal by filling out a form. Once the valid information is entered and the form is submitted, a Jenkins job retrieves it and proceeds to create the account with specific configurations that constitute the baseline of the account. To address this use case, two Terraform resources are added to the baseline applied to the account:

• The IAM role with the necessary policies that CloudGuard assumes to analyze an account.
• A resource that creates the associated CloudGuard environment with the AWS account.

Verification process

Every account in the organization must be onboarded on CloudGuard. To verify this, a system composed of AWS EventBridge and Lambda services has been set up. It will run in a cron job-like manner and search the organization for any account not onboarded on CloudGuard and alert accordingly.

B- Writing Rules Specific to the Client's Context

The tool includes predefined rule sets for conducting configuration analyses once the accounts are onboarded. Among these predefined rule sets, one set created by Checkpoint based on industry standards (CIS Benchmark, GDPR, etc.) gathers cloud best practice rules and concerns most AWS services (IaaS, PaaS, and SaaS). Several of these rules have been refined and will compose the customized rule set for the landing zone, touching on the following areas:

• Internet and/or public exposure of resources (VPC, S3 bucket)
• Data encryption strategy (EBS, S3)
• Identity management (IAM, any type of IAM policy)
• Network access management (security groups, EC2, VPC)

The client's project teams must be able to benefit from a hardened foundation where they can launch their projects. This is why the rules concerning the landing zone are mostly very strict.

For example, S3 buckets containing technical logs of the landing zone must be encrypted with a key managed by the client.

S3Bucket should have encryption.serverSideEncryptionRules contain-all [ ( serverSideEncryptionByDefault.serverSideEncryptionAlgorithm='aws:kms' ) and ( serverSideEncryptionKeyManagementServiceKeyId unlike '%alias/aws/s3' ) ]

The other S3 buckets owned by a project team are not necessarily subject to this requirement, especially if the level of data privacy they store is not high.

S3Bucket should have encryption.serverSideEncryptionRules

(Note: In this rule, the encryption key can be a key managed by AWS, which is prohibited by the previous rule.)

As mentioned a few lines above, the tool convinced with its ease of writing compliance rules. For example, to comply with GDPR, any company in Europe using AWS typically seeks to limit the deployment of its resources to European regions. A more concrete example: for compliant use of the Lambda service, writing the GSL rule (CloudGuard language) for rule writing would look like this:

Lambda should not have region in $UnauthorizedRegions

(Note: $UnauthorizedRegions is a list of unauthorized regions previously stored in the tool.)

The "where" clause in GSL allows for precisely targeting the relevant resources for a given rule.

Lambda where account=”123456789012” should not have region in $UnauthorizedRegions

This rule applied to an OU composed of multiple accounts, including 123456789012, will only produce results for the latter.

C- Implementation of Shiftleft

The Shiftleft feature allows for security controls to be implemented earliest in the CI/CD pipeline. It enables testing three types of resources, and we have begun using it to analyze Terraform templates deploying resources on AWS.

Integration into the pipeline

To use this CloudGuard feature, a binary is provided that is integrated into the deployment chain. Upon execution, this binary communicates with the CloudGuard backend to retrieve the rule set allowing it to analyze the Infrastructure as Code templates. The results of an analysis are sent to the SaaS platform. By default, a Shiftleft test stops the pipeline as soon as a raised alert is of LOW severity. Depending on the need, the severity level that stops the pipeline can be adjusted. As an example, here is the CLI command to execute for analyzing Terraform code:

shiftleft iac-assessment -p  {projectPath}  -r {ruleId} -e {environmentId} -s {Low|Medium|High|Critical}

Implementation of rules for Shiftleft

It was essential for the client to have the same compliance rules applied both before and after resource deployment.

The rule sets used for posture management do not apply to the IaC templates to be analyzed. An adaptation of these rules was necessary. Since no automatic translation of rules was offered with the tool, it had to be done rule by rule.

This limitation arises from the non-uniformity of field nomenclature in cloud resource configurations and Infrastructure as Code.

Let's take the example of a rule on encryption at rest of S3 buckets. For the posture management feature that concerns resources already running in the cloud, the GSL syntax is as follows:

S3Bucket  should have encryption.serverSideEncryptionRules

For Shiftleft, which handles compliance before deployment, the rule is written as follows:

aws_s3_bucket  should have server_side_encryption_configuration

C- Continuous Control Policies

Continuous control allows for immediate alerting whenever a new issue is detected by the various features of CloudGuard. For posture management, it involves applying a set of rules to an environment or organizational unit. Consequently, the tool will analyze the associated AWS account of the environment every hour.

Policy Creation Strategy

Because not all client accounts (landing zone and project team accounts) have the same requirements, applying a set of rules to all onboarded accounts is not suitable. Hence, the need arose to organize the accounts. Organizational units were created to group together environments with the same functional purpose.

A set of rules can be applied at each level in this hierarchy. A tagging strategy deployed in the AWS organization allows for more refined rules and therefore reduces false positives.

Lambda functions where tags contain [key='type' and value='dev'] should not have region='eu-west-1'.

Such a rule, as part of a set applied to the AWS root OU, verifies that development accounts do not have Lambda functions running in the Ireland region.

Notifications

To be quickly alerted to cloud non-compliance issues, it is possible to create continuous control policies. A continuous control policy allows CloudGuard to analyze an environment or organizational unit every hour. More concretely, one or more sets of rules will be applied to the environment (or OU). New alerts can be sent to multiple targets such as a security management system, a Slack channel, an email address, etc.

In the context of our client project, it was relevant to use SecurityHub, which already centralizes AWS cloud logs, to receive these notifications.

Conclusion

CloudGuard proved to be relevant to the client's needs. Checkpoint offers several means to integrate it into various types of environments, whether in the cloud or in a hybrid environment as was the case for our client. Its integration into the client's environment was more or less straightforward and allowed for multiple levels of control. The Shiftleft feature, although relatively new, nonetheless enables the identification of several configuration issues before deploying resources in the cloud.