Enhancing your cloud security: A beginner's guide to Hashicorp Sentinel.

In recent years, an increasing majority of S&P 500 companies have come to rely on public cloud infrastructure, a trend significantly accelerated by the COVID-19 pandemic in 2020.

Migrating assets (data, workflows, etc.) to the public cloud presents a new challenge, requiring specific skills and experience to ensure a smooth, economic, and secure transition.

According to a 2019 Gartner report, human errors are predicted to account for a majority of security risks attributable to customer actions by 2025. A notable example underscoring this prediction is the Verizon data leak, caused by a misconfiguration of an AWS S3 bucket, which led to the exposure of millions of customers data on the web.

The vulnerability auto remediation paradigm

To mitigate security risks caused by human error, major cloud providers have unveiled new tools designed to identify and fix common vulnerabilities, such as publicly accessible S3 buckets.

AWS customers can use AWS Config, a service designed to track infrastructure changes:

"AWS Config is a fully managed service that provides you with resource inventory, configuration history, and configuration change notifications to use security and governance. With AWS Config, you can discover existing AWS resources, record configurations for third-party resources, export a complete inventory of your resources with all configuration details, and determine how a resource was configured at any point in time. These capabilities use compliance auditing, security analysis, resource change tracking, and troubleshooting."
Amazon Inspector - How it Works
Amazon Inspector - How it Works

Paired with AWS Detective, AWS Config can assess and ensure compliance of resources through predefined or custom rules. Furthermore, it can automatically correct certain security or compliance issues immediately after they are deployed, enhancing overall system security (1).

Mitigate security / compliance issues with this strategy will have an impact on the following topics:

  • 💰 Billing: depending on multiples factors such as team size or resource deployment workflow, teams can deploy hundred of resources per day, in a development account for example. AWS Config rules will check compliance of every new resources deployed, which can cost a lot.
  • 🔮 Source of truth: most companies deploy resources on the cloud using infrastructure as code tools - such as Hashicorp Terraform. Modifying resources managed by such tools will generate configuration drift. On the next deployment, changes will be automatically rollbacked to match code, and then automatically patched via Detective, which introduce an infinite loop.
  • 🔒 Shirk responsibility for security topics: teams that deploy and operate systems must be accountable for the security of these systems, a principle central to the 'you build it, you run it' mindset introduced by DevOps a few years ago. Collaborating with security teams through practices like audits and pair programming is not only compatible with this approach but also essential in enhancing a team's maturity regarding security matters.
  • 🧑🏾‍✈️ Resource ownership: When security teams alter an infrastructure managed by others, it often leads to disputes over who owns the resources. I strongly recommend establishing a shared responsibility model among all stakeholders, including feature teams, the 'System Team', the security team, and others.
    Amazon Web Services also advises a practical solution to this problem: create a Jira ticket or send an SNS notification, which conveniently allows for SMS or email communication (capture bellow).

In conclusion, while adopting a resource auto-remediation strategy may seem beneficial, it often leads to more complications than solutions and fails to mitigate the risk of less experienced users making critical errors that can significantly affect business operations.

🤝
Special thanks to Maxime LENORMAND for his advices on AWS Config and AWS Detective.

Automatically enforce compliance and governance policies before making infrastructure changes with Hashicorp Sentinel

Hashicorp Sentinel introduces the innovative concept of 'Policy as Code', empowering users with a language and framework to ensure infrastructure changes comply with business and regulatory requirements. A policy describes under what circumstances certain behaviours are allowed.

With the Policy as Code concept, you can treat policy like an application — version control, pull review, and automate tests. Multiple enforcement levels are available - Advisory, soft-mandatory, and hard-mandatory levels - allowing policy writers to warn on or reject offending behaviour.

Sentinel is an enterprise-only feature of HashiCorp Consul, Nomad, Terraform, and Vault and is fully integrated to all of this products.

Policy as Code in Terraform Enterprise

Policies are enforced in Terraform Enterprise between the plan and apply, and validate information in the Terraform plan, state, and configuration.

The following code demonstrate how can Sentinel prevent to deploy a ressource with a non secure security group, allowing egress traffic from 0.0.0.0/0:

import "tfplan/v2" as tfplan
 
security_groups = filter tfplan.resource_changes as _, rc {
	rc.mode is "managed" and
		rc.type is "aws_security_group" and
		rc.change.actions is not ["delete"]
}
 
main = rule {
	all security_groups as _, sg {
		all sg.change.after.egress as egress {
			egress.cidr_blocks not contains "0.0.0.0/0"
		}
	}
}

The following code demonstrate how can Sentinel prevent resources (such as EC2 instance) to be provisioned without tags:

import "tfplan/v2" as tfplan
 
aws_instances = filter tfplan.resource_changes as _, rc {
	rc.mode is "managed" and
		rc.type is "aws_instance" and
		rc.change.actions is not "delete"
}
 
main = rule {
	all aws_instances as _, instance {
		(instance.change.after.tags else {}) is not empty
	}
}

Policy as Code in Vault Enterprise

Policies are enforced in front of all Vault APIs, and extends Vault's ACL system with fine-grained logic.

The following code demonstrate how can Sentinel will prevent any token generated more than four hours ago cannot be used in response to a breach (applied to all endpoints):

import "time"
 
main = rule {
  time.now.sub(time.load(token.creation_time)) < 4 * time.hour
}

The following code demonstrate how can Sentinel ensure that modification of critical data can only be performed by authorized sysops with valid MFA only:

import "strings"

pathcheck = rule {
    strings.has_prefix(request.path, "secret/dangerous/") and
        request.operation in ["create", "update", "delete"]
}

// Ensure that for this dangerous operation we've passed an Okta MFA check
oktacheck = rule {
    mfa.okta.is_valid
}

// Make sure the caller is a member of the sysops group
idcheck = rule {
    "sysops" in identity.groups
}

main = rule when pathcheck {
    oktacheck and idcheck
}

Lenstra helps companies leverage Computer Science to enhance their Economic Performance

Contact us for a free consultancy to explore how we can work together.

Contact us

Links

HashiCorp Sentinel framework
Policy as code framework for HashiCorp Enterprise Products.

Notes

  • (1) : AWS Config "Proactive mode" is also able to prevent resource deployment, but can be used only with AWS Cloudformation.

Read more