Zero Trust in Cloud Security: Never Trust, Always Verify

by Edward Viaene

Identity and Access Management (IAM) is crucial to cloud security, ensuring limited access and preventing attackers from exploiting internal weaknesses.

Identity and access management is the cornerstone of cloud security. It’s also the most complex product to understand. It often leads to a failure to assign the least number of privileges necessary. When a breach occurs, attackers can access other parts of an organization if a too-broad set of privileges has been assigned to applications and services. Significant awareness and knowledge within the infrastructure team of companies can be required to ensure they can put effective controls in place, especially around identity management and how to restrict access to certain employees.

Often, in-house security teams don’t have sufficient knowledge of the public cloud. They know their own controls and policies at an organizational level but do not necessarily know how to translate them to the technologies used in the Cloud. We can show them what AWS Controls make sense to implement and how to monitor the infrastructure for security compliance.

As infrastructure experts, we often find ourselves talking directly to developers and a lead or infrastructure team within an organization to help them make changes necessary to improve Cloud security. In the public cloud, this can be quite complicated, and, from a developer’s point of view, if they are a startup or a company that doesn’t have such controls in place, they risk being open to a free-for-all.

Protecting the network layer is essential to reducing the attack surface. To protect your deployed applications and services, use a layered security approach with multiple security controls on a network level. Use zero trust: never trust; always verify. Public cloud providers have various tools to implement authentication, authorization, and private, isolated networks within their catalogs.

Without realizing it, companies can make all their services publicly available by default because this is the standard way to get something running in the cloud. Controls are available if you want to use object storage in the cloud. You can say nobody can access this or that file, yet the service is still publicly accessible. So when you go on the public cloud, there’s an effort needed to restrict access and to build these layered controls to make sure that, for example, only the developers or employees connected to a VPN can access services, even services that are by default public on a public cloud.

It’s important to identify all services that are exposed publicly. If you make a mistake in access control or have a bug in your application, then it’s possible that someone could steal information. It’s happened — most notably in 2019, when a hacker gained access to 100 million Capital One credit card applications and accounts.

So, activate cloud security features. Public Cloud Providers have controls you can optionally activate to enhance security. Some were even introduced after major breaches of cloud customers (for example, the Capital One Breach led to the AWS IMDSv2 feature). Cloud API Security Monitoring and best practice checklists are also available.

Encrypt everything. Public cloud providers have Key Management Systems to make encryption easy. Controls can be set to allow encrypted traffic only to data stores. The ideal goal is to encrypt all traffic at rest and on the wire. An extra security layer can be introduced by setting Identity & Access Management permissions on the encryption/decryption key. This separates access to a system (which is needed by the team working on an app) and access to the data (which is not always required by software engineers or the infrastructure team).

Continuously monitor security compliance. If someone within the team deploys an unsecured app or creates a non-compliant configuration option, someone needs to be notified, and action needs to be taken. Once the team is comfortable with the current security baseline, automated actions can be configured so no manual intervention is necessary anymore. When users deploy non-compliant infrastructure, it’ll be automatically removed or disabled.

With many cloud markets — and AWS is the leading cloud player — you can generate access keys, which can then go to the developers’ laptops. But then, there are a lot of breaches that happen because of forgotten or lost access keys. Give a developer access to production data but forget that you have this access key, and then the key gets somewhere else in an application or gets lost. You will suddenly have a data breach caused by forgotten credentials. This occurs when companies don’t have controls in place, not because it’s often an unknown risk for them.

It’s essential to monitor security and compliance continuously. Cloud providers have tools to monitor and get more insight into what could be misconfigured. We recommend using these products to identify and alert when new services or a new code is created that is not compliant with your set standards. For example, you say all data should be encrypted, but you can receive an alert if someone creates a data store and the data is not encrypted. You can then investigate and make the employee responsible aware that your policy says everything needs to be encrypted, which is a manual intervention.

The landscape has grown in complexity over the years. Having all the knowledge in-house is challenging, yet data security is so fundamental to everything a company may be doing as a business that to risk this, they risk everything else. There’s more regulation than ever, and the risk of fines, especially in Europe with GDPR or for American companies who need to be GDPR compliant if they have European services, risks a big hit to your revenue, let alone reputational damage. It’s just not worth the risk.