The Best Practices for Cloud Security Configuration Management

Application security is the development and testing of features that protect users from threats like unauthorized access and modification. Often romanticized in popular media due to their apparent complexity and resistance to hackers, security measures can also attract an unfair share of the blame when things go wrong.

In reality, the most dangerous threats are mundane misconfigurations that allow attackers to bypass security controls. Security misconfiguration can easily result in system degradation and cascading, high-impact vulnerabilities.

It is, therefore, critical to have solid management processes and intuitive tools that help enforce your security posture. To this end, NIST has published a guide for the security-focused configuration management of information systems. The catchily titled SP 800-128 emphasizes the importance of implementing secure baseline configurations, carefully controlling changes, and identifying and remediating any inconsistencies with the expected outcome.

This article will highlight security configuration management practices that help you secure your cloud environment against potentially dangerous configuration inconsistencies, using Amazon Web Services (AWS) as an example whenever discussing the use of cloud native tools. For your convenience, we have summarized these practices below in an easy-to-reference table and will provide a deep-dive into each topic as we progress.

Summary of cloud security configuration management best practices

There is a common theme to best practices. Users should utilize tried and tested technology, make the most of shared responsibility models, and ensure visibility and transparency of all infrastructure configurations.

Cloud security configuration management best practices

Infrastructure as code, code reviews and version control

General software development principles have been established and refined over time and can be applied to configuration management when the correct processes are implemented.

The infrastructure and orchestration processes required to run and deploy applications can often be stored as code. Infrastructure as code (IaC), as it is known, is a game changer when it comes to security configuration management.

Image provides a visual representation of Infrastructure as Code (source)

Infrastructure as code can reduce the bias and human error associated with manual deployment and configuration. IaC also allows you to expose your deployment and associated settings for peer review by DevOps and security engineers.

Security and performance issues can now be identified and fixed before the system makes it to production. If there are any uncertainties amongst the reviewers, IaC allows them to quickly deploy the solution into a development environment for easier testing. As a bonus, infrastructure as code can also be validated programmatically as part of a CICD pipeline.

Finally, if an insecure configuration makes it to production, IaC drastically simplifies rolling back a broken or vulnerable deployment to a working state. Using version control tools (such as git combined with GitHub), developers can tag infrastructure as changes are made. Developers know precisely what code version is in production and can easily roll back to any given version should the need arise.

To this end, CloudFormation is an AWS Infrastructure as Code service that allows you to model, provision, and manage resources at scale.

Image shows that we can model, provision, and manage resources as code (source)

Security services

Unfortunately, peer review isn’t a silver bullet, and we can’t expect to catch every error. Good security management tooling can help. Leveraging security system rules and standards allows you to gain real-time visibility and insights into the configuration of your platform and identify misconfigurations, non-compliance, and performance issues. AWS provides two services that can assist.

AWS Config provides configuration assessment, auditing, and evaluation for AWS resources. AWS Config continuously monitors and automates the review of active configurations against an expected baseline.

AWS Config can run at regular intervals or in response to configuration changes. Evaluation rules are executed using AWS Lambda functions which return details of a resource’s compliance status. Any detected violation or misconfiguration marks the object as non-compliant. AWS Config can trigger automatic remediation logic or SNS notifications to correct the problem and notify interested parties.

The AWS Config Workflow (source)

AWS Security Hub is a security and compliance service that uses AWS Config as its source of truth to evaluate the configuration of AWS resources against security standards. It centralizes security alerts by incorporating services such as Amazon GuardDuty to gather intrusion detection findings, Amazon Inspector to gather vulnerability scans, and Amazon Macie to collect sensitive data findings such as personally identifiable information (PII).

Image shows a sample Security Hub findings dashboard created using Amazon QuickSight (source)

Choosing the right compute service

Thanks to the AWS Shared Responsibility Model, there are ways to reduce your organization’s security configuration responsibilities. Let’s look at some of AWS’s compute services as an example. Although there are services for virtually every use case, we’ll look at three of the most common: EC2, ECS, and Lambda.

EC2 gives you complete control over your compute environment and runs a full copy of your chosen OS. However, using and optimizing EC2 instances requires skill and time. Not only does EC2 put the onus on the user to keep the OS up to date, but manual configuration is also needed to scale and prevent performance deterioration when faced with heavy traffic or DDOS attacks.

On the other hand, Lambda uses a serverless architecture to provide stateless functions where the underlying infrastructure is monitored, patched, and maintained by AWS. These functions are short-lived sandboxed containers that scale automatically, making them almost impossible to misuse.

Image shows how Lambda functions can be invoked and run against a service (source)

Lambda is not the definitive answer to all compute questions. It has some drawbacks, particularly surrounding long-running jobs and tasks requiring interaction with OS libraries. While these problems are not impossible to overcome, Lambda is not always the correct solution.

ECS is a fully managed container orchestration service that allows developers to focus on application code rather than infrastructure. Like Lambda, the infrastructure is patched, monitored, and maintained by AWS but enables developers to run any docker image. ECS can scale to thousands of containers and use short-lived or long-running containers depending on requirements and budgets.

One critical aspect that these services share is their integration with IAM. By default, these AWS services have no access to other AWS services. IAM allows services to assume a role that has access to an allowlist of specific services and resources. For example, a lambda may only need read access to a single S3 bucket. IAM allows this fine-grained access control to be configured via IaC and analyzed or monitored as required. Please see the code snippet below as an example.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ExampleStmt",
      "Action": [
        "s3:GetObject"
      ],
     "Effect": "Allow",
     "Resource": [
     "arn:aws:s3:::AWSDOC-EXAMPLE-BUCKET/*"
     ]
   }
  ]
}

Regular audits

Knowing when and where to conduct a manual audit is critical to good configuration management. AWS has published guidelines advising you to audit your configuration at four intervals:

• during organizational lifecycle events, i.e., whenever someone joins, leaves, or changes role within the organization
• whenever services or software are activated or deactivated within your AWS account
• whenever an attack has been carried out against your infrastructure, or you suspect an unauthorized party may have accessed your account
• periodically, regardless of changes in your organization or account

By regularly auditing your system, you can ensure that you’re familiar with all rules and policies. Cleaning up unrequired resources is essential as it reduces the attack surface for potential attackers or malicious users. At a minimum, you should:

• delete inactive users and remove them from groups to which they are no longer a member. Similarly, delete any roles that are no longer required. Review who can assume that role and ensure all permissions within the policy are still needed. Check for new users and ensure all users with console access have MFA enabled
• remove or stop EC2 instances that are no longer needed. Delete any key pairs no longer used, and delete any unrequired security group rules. Not only will good EC2 maintenance keep security standards high, but it also has the added benefit of reducing costs
• review permissions for services that use resource-based policies such as KMS and S3. This is particularly important for S3 as S3 leaks are becoming more common
• ensure that logging and alerting are enabled for all relevant services. Infrastructure as code can be treated as a source of truth for the system’s initial state; however, some configurations can be changed manually. You can use CloudTrail to track these actions, but the regular manual checking of critical systems is recommended practice too

Limitations

Monitoring and reporting are important components of a successful solution. Although cloud providers like AWS provides the tools to gather and present data, configuration and coordination work is still required, even for out-of-the-box features. Custom rules and reports are possible, but the dashboards are still very basic, and it can be challenging to drill down to low-level issues. QuickSight can certainly help, but the data needs to be correctly processed and formatted, for which the end user is responsible. The tools are also priced in a way that seem inexpensive at first but climb in cost as soon as you expand coverage to your full environment.

Another issue when combining AWS services is that the DevOps team’s workload will continue to grow and the need for hybrid cloud management will eventually arise where native tools from a single cloud provider can’t help.

Thankfully, there are open source solutions built specifically to tackle these issues – Paladin Cloud’s Open Source Community Edition, for example, is free Cloud Security Posture Management (CSPM) tool that provides powerful visualization features that are flexible enough to switch between high-level overviews and low-level drill-downs. Paladin Cloud also uses a clever exception-based process to automatically remediate threats after a certain period unless an exception has been explicitly defined.

Image shows Paladin Cloud’s visualization features (source)

Conclusion

The principles of security configuration remain consistent, but the management and automation of an organization’s security configuration continues to evolve. The industry shift to cloud and shared responsibility models have abstracted away some of the complexities and monotony associated with secure server configuration. On the other hand, the sheer quantity and diversity of managed services can be overwhelming, with each having its benefits, nuances, and pitfalls. The optimal solution is to select a small, manageable number of monitoring and management tools that provide the maximum insight into your architecture.

We hope that you have enjoyed reading this article and that it has helped frame some of your security concerns.