Authomize Blog

In case you missed the news, Authomize is now live on the AWS Marketplace. 

While Authomize has long provided connectors and coverage for AWS, this is big news for us as it will help more organizations to benefit from Authomize’s Cloud Identity and Access Security Platform. 

According to Tackle.io’s State of Cloud Marketplaces report for 2021, the AWS Marketplace accounted for 63% of the cloud marketplace sales. Coming just a handful of months after our listing on the Azure Marketplace, we are excited to mark yet another step forward in bringing Authomize to an ever-expanding community of cloud and Identity and Access Management (IAM) security professionals.

Now certified by the AWS Marketplace, we are now available to organizations for purchase with their committed spend, making it even faster and easier than ever to get started with Authomize.

You can read our full press release here and then go to our AWS Marketplace page to check out the listing for yourself.

In honor of our big announcement, we wanted to take the opportunity to take another look at AWS from an identity and access security point of view and dive into one of the most common challenges facing security teams when it comes to AWS and their development pipeline.

Let’s dig in. 

Challenges in Securing AWS IAM

AWS is the biggest player when it comes to cloud infrastructure, taking a larger piece of the pie than competing cloud service providers Azure and GCP. But with size does not necessarily come simplicity.

Securely handling all of the users, roles, groups, policies, privileges, and all of the other elements that come with the AWS IAM ecosystem can be a handful. Especially as organizations shift their operations over to the cloud, storing more of their resources and running their development pipeline through AWS.

Controlling and monitoring access and the associated privileges securely is critical to restricting what an identity is able to do within your cloud environment — whether it be your AWS infrastructure (IaaS), or a SaaS product like Salesforce or GitHub. Those privileges, often defined as policies, can determine if an identity can read, write, edit, or perform other actions. Handling it well requires striking the right balance between efficiency and security, keeping to the Principle of Least Privilege that treats every bit of access as potential exposure. 

So if we want to limit our exposure, then we have to restrict identities to only the access privileges that they absolutely need to do their jobs. No more, no less. 

The challenge to getting the proper balance and detecting identity and access threats is having sufficient visibility to understand what your current posture is and when changes occur. 

For starters, your security team has to be able to answer who has access to what, and how they are using their access. This can be tricky when it comes to AWS for structural reasons of their IAM.

Breaking Down AWS IAM and Exploring Best Practices for Secure Use

There are basically four identity categories, each with their own privilege considerations, that we have to contend with here.

Root account user – The prime account that owns the AWS account. 

IAM users – These are the users that are created inside of AWS. They can be given specific privileges that they retain indefinitely.

Groups – These are the groups of IAM users that retain sets of permissions, often according to a given need. A good example would be that if you are in the Dev group, then you will have certain privileges to resources like repos or other tools.  

Roles – These are not users, but an identity with a specific privilege set that they are able to use for the duration of their session. A role does not belong to any given user, but a user can assume the role. 

There are of course best practices around all of these identity types: 

• Be exceedingly careful with how you use the root user because of its wide-reaching privileges.
• Avoid using IAM users because of the rigidity of their privilege possession. Once granted those privileges, the IAM user can hold onto them and create a privilege drift situation that leads them to become over-privileged. These IAM users (aka local users) can be hard to manage on their own, so most organizations take the preferred route of using an identity provider (IdP) like Okta, Ping, or Azure AD that grants them more centralized control.
• Groups and roles are ideal because they solve the problem of any specific user retaining privileges long term. In these cases, the groups or roles are granted privileges, and then the focus turns to managing who can assume those roles or be members of the group. Visibility over who has access to what via which access paths, i.e. is a member of groups or can assume roles, can be difficult to achieve. Access privileges can be hidden, again leading to unwanted exposure.

In the modern cloud development stack, gaining and maintaining the necessary visibility is hampered by three main blindspots, creating hard to manage risk.

Visibility Challenges and Risks in the Cloud Development Pipeline  

Most organizations building software rely on a combination of services for running their operations in the cloud. Each has its own IAM structure for controlling identities’ access to resources, which is essential as a malicious actor can tamper with the code, its production, or cause other supply chain issues. 

The three services that we will touch on here are the:

• Identity Providers – Okta, Ping, Azure AD
• Cloud Service Providers (CSP)/Infrastructure as a Service (IaaS) – AWS, Azure, GCP
• Code Repositories – GitHub, GitLab

Taken together, these combined services allow organizations to manage their identities’ access to resources like S3 buckets, Lambdas, and EC2s in AWS, and repos in GitHub or GitLab.

The difficulty is in the blindspots for tracking identities across all of these environments as they move from IdPs to IaaS to SaaS, and everywhere in between.

Let’s see where our challenges lie:

1. IdP to AWS
   If we are following our best practices and using an IdP to manage our identities, then we lose our visibility once they assume their role.
2. Bring Your Own Identity in GitHub
   The next issue is that GitHub works on a “Bring Your Own Identity” format that allows users to easily connect to an organization’s repos using their personal GitHub account. While this is very convenient and makes it easy for users as they move to different projects or organizations, it can be difficult to track because the identity being used for GitHub may not be the one that is in the organization’s IdP.
3. Monitoring for Threats End-2-End Across the Entire Access Path
   As we noted before, identities will move between a variety of environments (IdPs to IaaS to SaaS, etc), groups, roles, and more in order to get work done.
   
   The problem is that most solutions are only monitoring one environment, and likely only providing surface level visibility.This means that if a solution is only showing data from the IdP, IaaS, or SaaS silos, then the security team will lose visibility when the identity jumps to the next spot on their access path chain, leaving the security folks with only part of the total picture.  If we want to ensure security at every stage of the developers’ pipeline, then we need to monitor in every cloud and correlate the data into something actionable.

   Authomize Provide Granular Visibility Across Every Cloud Environment

   Using a combination of native, SCIM, and REST API connectors for IdPs, AWS, and GitHub, Authomize’s Cloud Identity and Access Security Platform offers continuous monitoring in all of the environments to provide the necessary visibility for strong access controls and threat detection.

   We can achieve this because we pull data from the access privilege layer across multiple sources to paint the fullest picture of who has access to what and how those privileges are being used. 

   In practice this means understanding who the identity is in the IdP, which roles they can assume, and then drawing information on access privilege use in AWS to connect between the identity and the assumed role. 

   Similarly, we can merge identities between the one managed in the IdP and associate it with the user’s GitHub account. Then, because we have the cross cloud connectivity, we know which identity is using which privileges. We can track and monitor privilege usage, following the paths as they move from a specified identity to their roles, groups, local privileges, apps, services, and reach their final destination at the target asset.

   Because the monitoring is continuous, we can detect suspicious changes or usage in near real-time, issuing alerts in accordance with security policies.

   Looking at an example: 

   • We would be able to see Susy’s identity assumed a privileged role in AWS that allows her to write in an S3 bucket that she also has access to from her membership in her dev team’s group. 
   • Authomize can then associate susy.kim@gmail[dot]com from her GitHub account and tie it to her susy.kim@herorganizationsemail[dot]com that is in her Okta. 
   • Every step of her journey to reach that S3 is monitored.
     • If she accesses a sensitive asset that she should not be, then an alert can be sent.
     • In another case, if Susy does not use her privileges to access a different repo with source code or an EC2 for say 60 days, then an email can be sent to her admins recommending that her access be revoked, thus limiting privileges and reducing exposure.
     • If all of a sudden her privileges change to give her more privileged access, then an alert can be sent to the admin to warn of a potential privilege escalation risk.

   There are multiple use cases for operationalizing this comprehensive visibility. 

   To learn more about how Authomize can enable your organization to eliminate the blindspots in your development pipeline, securing your AWS and everything else you own and build in the cloud, please contact us for a free assessment and demo.