Ensuring Trust and Compliance: How Stacklet Enforces End-to-End Cloud Encryption

Overview

Encryption is a key technology used to secure your data, customer data, and intellectual property in the cloud. End-to-end cloud encryption is necessary for robust security, compliance, and customer trust.

There are two main forms of encryption technology: encryption in transit and encryption at rest. Both are critical for achieving end-to-end security.

Encryption in transit protects your data as it is transmitted into, out of, and within your cloud environment. Encryption at rest secures data when it is stored in a filesystem, database, backup, or other storage mediums.

Stacklet provides a baseline set of policies out of the box, designed to scan and enforce end-to-end encryption across all major cloud providers. Additionally, Stacklet’s highly expressive, human-readable language and open source DNA enable customers to customize these policies with granular checks and remediation workflows. The power of the community further empowers customers to stay ahead of the rapid pace of innovation as cloud providers evolve their network and data services.

Importance of Encryption

Without cloud encryption, your data is vulnerable to network sniffing or accidental exposure on the internet. Encryption adds an essential layer of protection that prevents unauthorized access to your data, whether during transmission (encryption in transit) or while stored (encryption at rest) within your cloud environment.

Maintaining end-to-end encryption requires continuous scanning, alerting, and remediation of any unencrypted network traffic or data stores. For a typical cloud account, this involves monitoring tens of thousands, if not millions, of network interfaces, storage objects, snapshots, and other resources.

Automated tools are essential to implementing a robust encryption strategy. Stacklet systematically scans all your resources to identify and remediate unencrypted (or poorly encrypted) resources.

Encryption in Transit

Many people categorize network traffic into two types: traffic going into and out of your cloud environment from the internet, and network traffic within the cloud environment. Typically, companies place more focus on internet traffic, often overlooking traffic within their cloud infrastructure.

However, from a security compliance perspective, both types of network traffic are sensitive and must be encrypted. Internet traffic is vulnerable to external threats such as hackers or bots, while internal cloud traffic can be at risk from internal threat actors and malware. A compromise in either type of network traffic can expose your company’s intellectual property and erode customer trust.

Encryption in transit requires scanning all network endpoints such as your web servers, APIs, and other resource for appropriate levels of encryption. Additionally, it’s essential to ensure that the network endpoints for services from your cloud provider are also configured for encryption in transit.

Here is an example of a Stacklet policy to make sure the load balancer for internet traffic has encrypted network traffic:

Here is a second example, where we make sure the network traffic within the cloud environment is encrypted when leveraging the Kinesis Service and alert on any unencrypted traffic:

The above examples are for a load balancer and a cloud service. However, there are hundreds of cloud services across all cloud providers. To ensure network data security, every component involved in handling network traffic must be checked for proper encryption.

Encryption at Rest

Data stored in cloud backups, databases, and filesystems is an obvious target for both external and internal threat actors. Anyone who has worked in software development has likely read many blogs on this topic so we won’t rehash the basics here.

However, there are a few important considerations when reviewing data security:

When using cloud provider services, always adhere to their best practices for encryption at rest.

• Various forms of encryption are used at rest. Based on the sensitivity of the data being stored, choose the appropriate level of encryption.
• It’s crucial to account for all forms of data storage, including snapshots, backups, and copies of data for disaster recovery. This comprehensive approach secures all your data. Enforcing encryption on existing data stores can be challenging, mainly when the data is actively used.
• Applying the correct encryption settings when creating a new data store is more efficient.

There are often thousands, if not millions, of data stores in commercial environments. These data stores span multiple cloud services (e.g., S3, RDS, etc.) and even different cloud providers.

Stacklet provides a systematic way to scan and potentially remediate encryption-related issues. As with network traffic, it is critical to constantly monitor your cloud environment for changes over time.

Here is an example policy of S3 encryption detection and remediation:

Below is a slightly different twist on encryption enforcement: delete any new RDS database instance that does not have encryption enabled!

It’s the responsibility of the development team to implement the appropriate encryption strategy for new RDS databases. This proactive approach prevents the use of unencrypted RDS databases before any data is stored.

The Stacklet Advantage: Multi-Cloud and Extensibility

As noted above, Stacklet has policies for all major cloud providers and services. With proprietary Cloud tools, customers are locked into the cloud providers and cloud services supported by the vendor. Given the scope of cloud providers and the rate of innovation of network and data services, it is virtually impossible for vendors to maintain coverage.

Given Stacklet’s open source DNA and powerful policy language, customers can collaborate, build, and customize policies. Stacklet policies are written in a Domain-Specific Language (DSL) that abstracts the cloud-specific syntax and enables developers to focus on the cloud services that need to be monitored.

For a practical demonstration of the power of the DSL and the level of abstraction it offers, let’s compare two Stacklet policies. Both of these policies are designed to handle unencrypted disks, showcasing how the DSL abstracts the cloud provider as much as possible.

AWS example:

Azure example:

The ability to customize, and expand Stacklet policies is unique in the marketplace. It allows customers to innovate at their own pace and do not need to be concerned with vendor lock-in or roadmaps!

Conclusion
A comprehensive cloud encryption strategy is critical to protecting customer data and intellectual property and maintaining customer trust. Unfortunately, network and data encryption takes many forms and implementations across cloud providers.

End-to-end encryption across your software stack is the gold standard. In a moderate-sized environment, this requires monitoring tens of thousands of resources (larger environments can have millions of resources!) and ensuring your cloud services are correctly configured. Without tools that can automatically remediate issues, maintaining end-to-end encryption is virtually impossible.

Stacklet provides the tooling to monitor and remediate encryption deficiencies across multiple cloud providers, such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud, etc.

Finally, Stacklet’s open source DNA empowers you to customize, collaborate, and create new policies, putting you in control to match the rapid pace of cloud service innovation.

If you are interested, please sign up for a demo here.