Today we will see InstaSecure, a proactive cloud security platform. InstaSecure provides 50+ AWS-native preventive guardrails for AI, data, identity, and cloud infrastructure to prevent misconfigurations and access issues across the entire AWS platform.

Show transcript

Hi, I'm Rupesh Musha. Today we will see Insta Secure, a proactive cloud security platform. Insta Secure provides 50 plus AWS native preventive guardrails for AI, data, identity, and cloud infrastructure to prevent misconfigurations and access issues across the entire AWS platform. Today we'll be focused on building an air gapping environment called data parameters that will tackle the issue of credential theft. More than 60% of cloud breaches are attributed to credential issues. Credentials on the cloud are present everywhere in your software packages, network shares, GitHub repos, uh access from your cloud infrastructure, your AI genetic framework, anything that is deployed on the cloud or is accessing the cloud is via some of these credentials and the source of credentials could be related to some sort of human access or your workforce access whether directly through IM configurations federated uh access or through long-term session keys, credentials, access keys or there are like lot of various formats for providing third party web identity and other sort of access. As you quickly realized cloud is complex and understanding the security posture of this credentials usage is very difficult. Let's see how do we tackle this issue of credential theft and building some preventive protection inside the cloud. To demo the problem, let's just assume there's a company called ECM which has deployed an application inside a VPC which has an cloud credential an IM role associated with it and accessing an S3 bucket with data in the same cloud account. In this case, we got a trusted identity accessing a trusted resource through an expected or trusted network. This access should be allowed. The problem happens when this trusted identity gets stolen and then used by the attacker from somewhere random location to access cloud infrastructure. In this case, sensitive data stored in that S3 bucket. This is a very common pattern of credential abuse in the cloud. A very well-known case regarding this issue was a Capital One breach of 2019. Capital One built a solution around it called data parimeter as we discussed. They have spoken about it at various cloud conferences. Uh let's dive a little bit deeper and see how we can recognize this problem and solve it. This problem is not just for the application. In this case, I'm just trying to show how your workforce access is also impacted by this credential portability issue. In this case, the workforce users get authenticated through an octa and the authenticated access then can go through an authorization check from your AWS and the access is granted. But what happens when that authenticated sess uh session gets stolen and the access again gets launched from an internet location the access number five that should be blocked but it just goes through because post authentication that it's a valid session token let's look into insta secure and how we solve it in this case the demo starts with two terminals an application terminal there's an EC2 instance running inside of of the AWS and the attacker ter we have named it as Paige Thompson the attacker behind the capital one breach in this case the attacker is able to exfiltrate the session token associated with that IM role on that EC2 instance and then copy it to uh their own personal terminal running on the internet and as you see now they have copied over the credentials now let's see what happens once Once the credentials are copied over in this case the will show the access from that EC2 and then uh access from that attacker terminal. In this case you can clearly see the access from that EC2 instance is able to list all the S3 buckets in that cloud account. Now from the attacker terminal the same credentials which were copied now enables the access to the same S3 buckets. Essentially proving out the credentials are portable and once the credentials are in the hand of the attackers there is nothing stopping them from the access. Let's see how do we tackle it inside the insta secure. In insta secure I've copied this uh snapshot of this dashboard where we identify all the credentials which are at risk of this particular problem. In this case we have 17 IM users, 17 IM roles or instance profiles and two third party principles which are at risk of being abused by credential portability issue. Here the dashboard identifies the problem and suggests a remediation control. In this case the service control policy is to create a network parameter. In this case let's see once we click the network parameter what happens here. When you click the network parameter it takes to the actual control in the library of the controls that we maintain here. It's recommending to implement this trusted network access for cloud credentials and the control clearly identifies what's the objective say uh to limit the network access what frameworks applies what is the behavior this control is a preventive control will be implemented through a service control policy on AWS which can impact the IM roles and users defined inside and as you see it also tells highle goal around what these credentials are used for like a data parameter, credential theft, digital sovereignity. So we come here, we'll click the control and it takes us through a process of create the control. When you start to end, it takes no more than 5 minutes to go go end to end. And once the control is created and deployed to the cloud, let's see what happens in this case. Again we access the same S3 storage in that cloud account and everything is accessible. And now again page option she's trying to access from her personal terminal and as you realized the access is denied and this is what essentially a data parameter enforces. Trusted identity can only access trusted resource only from expected network. Again this is with this I finished this demo. We are available on AWS marketplace and if you would like to see actual control creation or more demos please reach out to us. Thank you.

Today, we will focus on building an air-gapped environment called data perimeters that tackle the issue of credential theft.

More than 60 percent of cloud breaches are attributed to credential issues. Credentials in the cloud are present everywhere—in your software packages, network shares, GitHub repos, access from your cloud infrastructure, agentic frameworks, or anything deployed on or accessing the cloud.

The source of credentials can be tied to human or workforce access, whether directly through IAM configurations for data access or through long-term session keys, credentials, and access keys. There are many ways credentials appear.

There are also various formats for providing third-party web identity and other forms of access. As you quickly realize, the cloud is complex, and understanding the security posture of credential usage is very difficult.

Let’s see how we tackle the issue of credential theft and build preventive protection inside the cloud. To demo the problem, let’s assume there’s a company called Equi, which has deployed an application inside a VPC. It has a cloud credential—an IAM role—associated with it, and it is accessing an S3 bucket with data in the same cloud account. In this case, that identity is accessing a trusted resource through an expected network, so this access should be allowed.

The problem arises when this trusted identity gets stolen and is then used by an attacker from a random location to access cloud infrastructure—for example, sensitive data stored in that S3 bucket. This is a very common pattern of credential abuse in the cloud. A well-known case was the Capital One breach of 2019.

Capital One built a solution around this called Data Perimeter, which they have discussed at various cloud conferences.

Let’s dive a little deeper and see how we can recognize this problem and solve it. This problem isn’t just for applications—it also impacts workforce access. Workforce users are authenticated through Okta, and that authenticated access then goes through an AWS authorization check before access is granted.

But what happens when that authenticated session is stolen and launched from an internet location? That access should be blocked, but it passes through because post-authentication it is still seen as a valid session token.

Now, let’s look into InstaSecure and how we solve this. In this demo, we start with two terminals: an application terminal with an EC2 instance running, and an attacker terminal we’ve named Page Thompson (after the attacker behind the Capital One breach). In this case, the attacker is able to exfiltrate the session token associated with the IAM role on that EC2 instance and copy it to their own terminal running on the internet.

Once the credentials are copied over, they can be used to access from that attacker terminal. From the EC2 instance, the session token lists all the S3 buckets in that cloud account. From the attacker terminal, the copied credentials enable access to the same S3 buckets—proving that credentials are portable. Once credentials are in an attacker’s hands, there is nothing stopping them from accessing resources.

Now, let’s tackle this with InstaSecure. In InstaSecure, I’ve copied a snapshot of the dashboard where we identify credentials at risk of this problem. In this case, we have 17 IAM users, 17 IAM roles or instance profiles, and two third-party principals at risk of being abused through credential portability.

Here, the dashboard identifies the problem and suggests a remediation control. For example, a service control policy to create a network perimeter. Clicking into the Network Perimeter takes you to the control in our library of controls.

It recommends implementing Trusted Network Access for Cloud Credentials. The control clearly identifies the objective (limit network access), the applicable frameworks, and the expected behavior. This control is a primitive control implemented through an AWS service control policy, impacting IAM roles and users.

It also describes the high-level goals of these credentials, such as data perimeter enforcement, credential theft prevention, and digital sovereignty.

Clicking the control takes you through the process of creating it. End to end, it takes no more than five minutes. Once the control is created and deployed to the cloud, let’s see what happens.

Accessing the same S3 storage in that cloud account from the application terminal still works. But when the attacker attempts access from their personal terminal, the access is denied.

This is essentially what a data perimeter enforces: a trusted identity can only access a trusted resource from an expected network. With this, I conclude the demo.

We are available on AWS Marketplace. If you’d like to see the actual control creation or more demos, please reach out to us.

Proactive Cloud Security: Tackling Credential Theft with InstaSecure

Want to see this in your AWS environment?