IAM Power Editor was created to alleviate some of the pains associated with Identity and Access Management (IAM) policy creation.

IAM Power Editor - Initial Release

<a href="https://editor.iamzero.dev/">IAM Power Editor</a> was created to alleviate some of the pains associated with Identity and Access Management (IAM) policy creation.
Here are some of the pain points we identified
<ul>
<li>Wasted time looking up ARNs or Privilege descriptions</li>
<li>Time spent fighting syntax and spelling errors</li>
<li>Unknowingly introducing vulnerabilities</li>
</ul>
Welcome to <a href="https://editor.iamzero.dev/">Power Editor</a>. Sift through 9000+ privileges in just a few key presses, ARN's are instantly recommended, their input/validation is streamlined. Additional statements can be added via hotkey, and your policy will be checked in real time for syntax errors or other bugs (thanks <a href="https://github.com/duo-labs/parliament">Parliament</a>!).
We'll be incrementally making improvements to Power Builder over coming months and we would love to hear your feedback.
Common Fate is creating novel solutions to the inherent problems facing Identity and Access Management in the Cloud.


Today I have an important update to share: Common Fate is winding down operations.

Throughout our journey building Common Fate, we've been dedicated to creating Identity & Access Management tooling with a top-notch developer experience. Our access management platform has helped organizations effectively manage privileged access across integrations like AWS, Google Cloud, Okta, and more.

This journey wouldn't have been possible without the incredible support we've received along the way. I'm deeply grateful to our team members who helped build Common Fate, our customers who trusted us to manage their access, our investors who believed in our vision, and our community who provided invaluable feedback and support.

## Granted is being donated to fwd:cloudsec

We're pleased to announce that we are donating our open source project [Granted](https://granted.dev) to [fwd:cloudsec](http://fwdcloudsec.org) so that it can continue serving the cloud practitioner community. fwd:cloudsec will provide vendor-neutral governance for the project.

Chris Farris, Cloud Security Consultant and fwd:cloudsec association board member, shares:

> I work with a large number of cloud accounts across multiple clients and use Granted in my day-to-day work. With fwd:cloudsec, we're excited the independent cloud security community can help continue to shepherd the project, ensuring that everyone who needs a secure and easy-to-use way of accessing AWS can continue to rely and build on it for years to come."
Granted has become an essential tool for many cloud engineers, providing a seamless way to access and switch between AWS accounts and roles. We're confident that under fwd:cloudsec's stewardship, Granted will continue to thrive and serve the needs of the community.
We encourage all current users and contributors to continue engaging with the Granted project in its new home. Your ongoing support will be crucial to its future success.

Thank you to everyone who has been part of the Common Fate story. While this chapter is closing, we're proud of the impact we've made and grateful for all the connections we've built along the way.


Today I have an important update to share: Common Fate is winding down operations.

Common Fate is winding down


Today we're releasing a new browser extension for Granted which makes authenticating to AWS IAM Identity Center faster and more secure. The extension protects users from being phished for AWS credentials.

When users authenticate to IAM Identity Center using a CLI, a browser window like the below is opened. Clicking "Confirm and continue" begins a login flow where users are prompted to authenticate using their single-sign on credentials, including entering MFA.

![IAM Identity Center login screen](/blog_posts/granted-mitigates-device-phishing/sso_confirm.png)

The problem with this process though is that an attacker who knows your IAM Identity Center URL can craft a malicious login URL and send it to you. If you're unlucky enough to open it, this is what you'll see:

![Malicious IAM Identity Center login screen](/blog_posts/granted-mitigates-device-phishing/malicious_sso_confirm.png)

Looks similar to the first screenshot, right? And what's worse, if you click "Confirm and continue" here and enter your SSO credentials, the attacker will gain access to all of the AWS roles available to you in IAM Identity Center.

![Phishing for AWS credentials via AWS SSO device code authentication](/blog_posts/granted-mitigates-device-phishing/attack_flow.png)

Sebastian Mora has created a [proof-of-concept](https://github.com/seb1055/obfuscated-openssh/tree/main/aws-sso) for the attack here.

## How Granted helps

The Granted browser extension reads the code on the IAM Identity Center confirmation page and confirms that it matches the Granted CLI. If the code matches, the extension clicks the "Confirm and continue" button on your behalf. This makes the login process faster.

![Granted extension auto-confirm](/blog_posts/granted-mitigates-device-phishing/auto_code_confirm.png)

If you're ever sent a malicious login URL by an attacker, Granted disables the confirmation button to prevent your credentials being stolen.

![Granted extension preventing phishing](/blog_posts/granted-mitigates-device-phishing/protect_bad_code.png)

Under the hood, the browser extension uses the native messaging API to communicate with the Granted CLI. Using native messaging means that other browser extensions or applications can't read the user code from Granted.

The extension works in all Chromium-based browsers and requires Granted version 0.35 or later.

A big thanks to Rami McCarthy - this feature originated from a discussion I had with Rami at fwd:cloudsec EU last month where he suggested we build this into Granted.


Today we're releasing a new browser extension for Granted which makes authenticating to AWS IAM Identity Center faster and more secure.

Granted now mitigates device auth phishing in AWS IAM Identity Center

In [part 1 of our Cloud Access Maturity Model](/blog/cloud-access-maturity-model-part-1), we outlined four stages of access management maturity in the cloud: Administrator-centric, Role-Based Access Control (RBAC), Just-in-Time (JIT), and finally Adaptive.

In this follow-up piece we provide more detail about what each level looks like, how to measure maturity with metrics, and ultimately how to progress to the next stage.

![Overview of stages, showing 'Administrator-centric', followed by 'Role Based Access Control', followed by 'Just-in-time Access', followed by 'Adaptive Access'](/blog_posts/cloud_access_maturity_model_part_2_stages.png)

## **Stage 1: Administrator-centric**

In the Administrator-centric stage, access management is at its most basic level. This stage is characterized by over-provisioned access, where most - and often all - users have administrator privileges. This stage prioritizes functionality and ease of use over security, which poses significant business risks.

## Pains

This stage of maturity is like running on a legacy system, since it’s missing the security advances of the last 10 years. This stage also goes hand-in-hand with long-term credentials (for example, IAM user access keys) that are one of the main sources of compromise.

The main mitigation available in this stage is to limit the number of people that have access to the system. Adding additional layers of authentication, like multi-factor authentication (MFA), at least adds additional verification that the user is who they claim to be, but still doesn’t address the excess permission granted.

Obtaining compliance certifications at this stage is very difficult due to such a low level of maturity. Any business that requires or prioritizes official compliance recognition needs to make changes immediately.

### Metrics

![Stage 1 metrics](/blog_posts/cloud_access_maturity-metrics-stage-1.png)

**The number of entities with administrator access**, which should be as low as possible. If administrator access can’t be avoided, it should at least be tracked and measured, so that it can be improved over time.

**The number human users without MFA enabled**, which should be zero. Ideally, MFA should be enforced by the identity provider.

**The age of long-term credentials**, which should be lower than an agreed threshold, for example 30 days. This can and should be enforced by the identity provider, for example password rotation. Additionally, any user-controlled credential should meet minimum complexity requirements, for example password strength, and it should be enforced.

### Advancement

The key to success at this level of maturity is to spend as little time as possible at it! By tracking the metrics and reviewing them periodically will help push them in the right direction. It’s not hard to mature beyond this stage, which makes it even less forgivable to spend excessive time at it.

Adding a centralized identity provider (IdP) for human users will de-couple identity from access, help reduce duplication, and push activities towards using roles and short-term credentials.

Identifying and tracking machine users with administrator access gives a focus point for access to remove or reduce over time, and regularly reviewing this list will encourage people to do the right thing on a day-to-day basis.

## **Stage 2: Role-Based Access Control (RBAC)**

The RBAC stage represents a significant step forward in access management maturity. At this stage, organizations move away from universal administrator access approach to more focused, business-aware roles. This stage requires upfront thinking about access requirements and defining roles that meet these needs appropriately, which represents a move towards deliberate, context-aware security.

### Pains

Even though this approach greatly improves on the previous stage of maturity, there’s still lessons to be learned. Working out what each role should have access to, and how many roles is appropriate is a process that takes time, feedback, and practice - You don’t know you’ve got too many roles until you’ve got too many roles! A lack of ownership or agreement roles’ scope is almost guaranteed to happen at this stage. In addition to roles still being too permissive, another potential source of pain at this stage is roles not being permissive enough, or not accurately scoped to the task requirements. This leads to users falling back to administrator-level (or similarly over-permissive) roles to get their job done on a day-to-day basis.

### Metrics

![Stage 2 metrics](/blog_posts/cloud_access_maturity-metrics-stage-2.png)

**Number of permissions granted to individuals**, which should go down to as close to zero as possible. When this metric is high, it suggests roles are poorly defined.

**The number of roles available**, which should go up, and eventually reach a stable number. The exact number will depend on things like the team structure and business requirements, but regardless should eventually stabilize.

### Advancement

Reviewing the approach towards resource containment can be a valuable exercise at this stage, since it will directly impact the scoping of roles. This means accounts in AWS, projects in GCP, and subscriptions in Azure.

Automation can be used to help generate roles based on historical activities. The increased resource management that comes with RBAC means that automation in general becomes more valuable, since it helps address the associated management overhead. More specifically, automation can also be used to help generate roles based on historical activity, giving higher levels of confidence.

## **Stage 3: Just-in-time (JIT) Access**

In the Just-in-time Access stage, organizations add a temporal dimension to their access management, so that access is not only role-based but also time-limited. This represents an additional dimension of access management that is still tied to specific business requirements. Adding a time limit to access significantly reduces the “standing access” available to entities, and aligns permissions more closely with actual needs.

### Pains

Introducing a time-based approval step to access undoubtedly increases security, but that comes at the cost of convenience. If approvals take too long, users may try to revert back to using standing or long-term access to avoid being blocked. This highlights the need for automation to streamline the approval process as much as possible.

A common trap to fall into at this stage is to require manual/human approvals for all access, even if it’s a non-critical level of access. As much as possible, the additional friction of approvals should be used for higher, more business-critical levels of access, to reduce productivity bottlenecks.

### Metrics

![Stage 3 metrics](/blog_posts/cloud_access_maturity-metrics-stage-3.png)

**Standing hours of access**, which should go down to as low as possible.

**Access request approval rate**, which should be as high as possible. If this number is low, it suggests that the policies around access are not fit for purpose i.e. users are requesting access they shouldn’t have been able to request.

**Percentage of approvals that are auto-approved**, which should be high but stable. This should be as high as possible for entitlements that are not critical.

**Time to approval response**, which should be as low as possible, to a reasonable expectation. This means that requests are approved or denied in a reasonable and consistent timeframe.

### Advancement

This stage requires extensive automation, and advancing beyond it requires even more! This level of security becomes prohibitively limiting to productivity if not entirely automated.

Counter intuitively, this stage is not focused on limiting the permissions granted, only they are granted for an appropriate reason and time period. This means that you might be granting more privileges, but for less time - In this stage, less really is more!

Roles and levels of access should be well understood and defined, and only change periodically, for example when new teams or projects are spun-up. As part of the automation process, activity and audit actions need to be extensively and consistently logged, so that they can be used in the next stage of maturity.

<aside>
 [CommonFate.io](http://CommonFate.io) is self-hosted JIT access to your AWS
 accounts, GCP projects, and more.
</aside>

<div className="mb-8">
 <WaitlistCta />
</div>

## **Stage 4: Adaptive Access**

The Adaptive Access stage represents the pinnacle of access management maturity. At this level, access is dynamically adjusted based on historical usage patterns, and real-time context. Permissions are automatically scoped to the least privileges required for specific tasks, making the principle of least privilege the default rather than the exception.

Additional pieces of context are included, such as on-call rotation status, and other variable information that would otherwise need to be manually managed by a user.

## Pains

Even this level of maturity is not without its pains and challenges. The baseline automation required at this stage is extensive, and represents significant commitment and investment of time and effort to achieve. No organization “accidentally” achieves this level of access management. This level of maturity will also require a significant learning curve for new engineers and developers, as they are unlikely to have experienced much or at all at previous organizations, almost all of whom are operating at a lower level of maturity.

### Metrics

![Stage 4 metrics](/blog_posts/cloud_access_maturity-metrics-stage-4.png)

**Privilege access usage**, which should be approaching zero. If there is access, there should be an associated incident or justification for unusual/break-glass access.

**Permissions denied errors**, which should be very low. If this metric is too high, it means that the generated access is not sufficient.

### Advancement

At this level, there is no advancement steps because least privilege and limited time access is built-in. What is required is consistent, pro-active review to ensure that the system is continually performing as expected, while still supporting users to do their job and meet business needs and requirements.

## Conclusion

Cloud access management maturity is a critical journey for organizations seeking to balance security, compliance, and productivity. As we've explored, this journey progresses through four key stages: Administrator-centric, Role-Based Access Control (RBAC), Just-in-Time (JIT), and finally Adaptive.

Each stage brings its own challenges and benefits, requiring organizations to continuously evolve their practices, metrics, and technologies to address pains and challenges. The goal is to achieve a state of Adaptive Access, where permissions are dynamically adjusted based on context and need, practicing the principle of least privilege.

By understanding these stages and actively working to advance through them, organizations can enhance their security posture, streamline operations, and better meet compliance requirements.

Metrics to manage and improve to raise maturity

A Cloud Access Management Maturity Model: Part 2


Today we have released [Common Fate CLI v1.15](https://github.com/common-fate/cli/releases/tag/v1.15.1). This release adds support for running [Access Tests](https://docs.commonfate.io/authz/testing).

Access Tests allow you to verify the behaviour of authorization policies and confirm that Common Fate resource syncing is working as expected. You can write tests to check for invariants, such as "an external contractor should never have auto-approved production access", or "a security team member should have auto-approved access to an account in the Security Organization Unit in AWS".

Access Tests are specified using a YAML file, similar to the following:

```yaml
# group-tests test whether a user is a member of a group or not.
group-tests:
- user: alice@example.com
  group: 2df6c5c4-0e09-477a-b796-9ad9bd756d83
  is-member: true

# access-tests test whether a user is allowed to access a particular entitlement or not.
access-tests:
- user: alice@example.com
  target: development-aws-account
  role: AWSReadOnlyAccess
  expected-result: auto-approved

- user: alice@example.com
  # you can also use Cedar entity IDs here for the target or role
  target: AWS::Account::"123456789012"
  role: AWS::IDC::PermissionSet::"3d06e8e5-93d3-4bfd-ae4f-e5caf43c99ad"
  expected-result: requires-approval

- user: alice@example.com
  target: very-sensitive-aws-account
  role: AWSReadOnlyAccess
  expected-result: no-access
```

You can run tests by using `cf tests run -f tests.yml`. You'll see an output similar to the below:

```
retrieving users for email address lookups...
retrieved 126 users
-------------- ACCESS TESTS --------------
running 2 access tests...

[PASS] chris@commonfate.io requires-approval to Sandbox-1 with role ViewOnlyAccess

[FAIL] chris@commonfate.io auto-approved to Sandbox-2 with role ViewOnlyAccess: got requires-approval
	policies contributing to requesting access: [basic.policy0]
	policies contributing to activating access: []

-------------- GROUP MEMBERSHIP TESTS --------------
running 2 group membership tests...

[PASS] chris@commonfate.io is member of c9bed4d8-d091-7057-4ed7-6d60bcf1e8bf

[PASS] chris@commonfate.io is not member of 790e94a8-2071-7016-a43c-86e66212a43d

1 Access Tests failed
All Group Membership Tests passed
```

You can also [run tests in Continuous Integration providers like GitHub Actions](https://docs.commonfate.io/authz/ci#access-testing-in-ci). Here's an example GitHub Actions workflow:

```yaml
name: Test

on:
  push:

jobs:
  access:
    name: Access Testing
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install Common Fate CLI
        uses: common-fate/install-cli-action@v1
        with:
          oidc-client-id: abcdefGHIJKL12345678 # replace this with your Client ID
          oidc-client-secret: ${{ secrets.CF_OIDC_CLIENT_SECRET }}
          oidc-issuer: https://cognito-idp.us-east-1.amazonaws.com/us-east-1_abcdeFGH # replace this with your Issuer
          api-url: https://commonfate.example.com # replace this with your Common Fate API URL

      - name: Run Access Tests
        run: cf tests run -f tests.yml
```

To learn more about this feature, [read our documentation on access testing](https://docs.commonfate.io/authz/testing).
