Why You Should Consider Separate IAM Administrators

AC.25 Refactoring IAM for centralized management to reduce the cost of a data breach

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Cloud Governance | IAM | AWS Security

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post, we examined the difference between trust policies, IAM policies and resource policies on AWS.

Before you can create credentials you need to have credentials

If you’ve been following along in this series you’ve seen me create some IAM resources. As I moved on to other posts I haven’t published yet, the complexity started to rear its ugly head. I’ve already mentioned that complexity can be the enemy of security.

One of the issues I as facing was the catch-22 of not being able to create my batch job user credentials without having any credentials. When you set up a cloud account of any kind, someone has to have the initial credentials that give everyone else credentials. Those all powerful credentials can grant people to do — anything — depending on how you architect your IAM permissions.

I was initially trying to keep it simple but simple turned out to be not-so-simple when I got to this point. I ended up setting up what I often recommend to IANS Research clients on calls. I created a central location for the IAM scripts that grant users and roles permissions. I created an IAM group, user, and role for management of IAM. Just as with KMS and batch jobs I can require MFA to allow the IAM user to assume the IAM role. I can limit IAM permissions to create new credentials and identities to the IAM role.

You can use this similar concept with AWS Control Tower and SSO (now AWS Identity Center) but I mentioned some reasons I’m not using that for this particular use case here:

You could set up your IAM group and users in AWS SSO (Identity Center) and the users that require MFA on the command line in AWS IAM which is what I’m kind of doing but it’s easier for me to demonstrate these concepts using IAM for now.

The risk of broad IAM permissions throughout your organization

I need a role with IAM Permissions because I need to allow creation of the batch admin user credentials I’ve been writing about. You could allow any number of people in your organization to do that with different types or responsibilities. The thing is that once a user has full IAM permissions and can create new identities, credentials, and permissions in your account, they can essentially take over the account, short of deleting it if you don’t give them root access.

This is akin to the role of domain administrator in a traditional on-premises Windows Active Directory environment. All my pentest readers out there know that the ultimate achievement in an on-premises environment is to obtain domain admin. In the cloud, obtaining credentials for the user that can assign any permissions is equivalent.

What is it worth to you to prevent a data breach or minimize the cost?

As you may have also noticed, and will even more as we proceed, creating IAM permissions is not a simple task (if you do it right with zero-trust IAM policies and segregation of duties). A great deal of thought goes into architecting users, roles, and permissions that work together without creating security gaps.

Assigning specific people to understand and architect these permissions will help you avoid security problems if they are good architects and engineers and understand the objective — to limit risk and the blast radius in the case of a security incident. I introduced those concepts in my book at the bottom of this post.

I worked at a company that did just that — at first. They made some mistakes, like missing the point of MFA to identify a single user and allowing others obtain the MFA device details. But overall, I know some really smart people worked on the IAM team and constructed and tested the best policies they could, under the circumstances.

So how did that company end up having a major data breach? I wasn’t working at the company anymore so I can only recount what someone told me. However, I actually predicted the cause of the breach through speculation in an earlier blog post about the root cause of this flaw. It seemed like an architectural mistake in the design of IAM policies.

People at the company did not like the restrictive and well thought out zero-trust policies related to a certain application configuration because they slowed things down. They wanted to open up the policies so they wouldn’t have to take the time to carefully construct zero-trust policies for each new application.

The result: An attacker breached a system and leveraged the wide open policy to access the data from all the applications that didn’t take further steps to secure it. A few of the applications had applied KMS keys with separate resource policies that prevented the attacker from accessing their data, thankfully. This reduced the scope a bit, but not enough to result in a massive data breach and cost to the company.

One of the people that worked on that IAM team told me he switched jobs to a different department with the company after that decision. He saw the impending doom that later came to fruition. People could see the blast radius and risk but others didn’t care in the interest of getting things done and moving fast.

Zero-trust policies and well-architected IAM constructs within your systems are your friend when it comes to reducing attacks and potential losses in the event of a data breach. People who understand the intricacies of creating these complex policies correctly — and how to test them — are worth whatever it is worth to you to prevent and minimize the damage that a data breach can cause.

Why a separate, or at least limited team?

Stolen, lost, and abused credentials are one of the biggest threats in your cloud environment. Trying to get everyone to create proper IAM permissions throughout the company is going to be like herding cats. Good luck, if you take that approach. Because IAM is complex, people will take short cuts to get things done when they don’t work. In fact, I took some myself while developing this code, but hopefully it will all be fixed by the time I’m done. I can do this, because I’m my own boss.

When a developer working in a large organization takes a short cut, later when the management team is on his or her case to deploy the project, they might not let the developer go back and fix that problem they left in the code. The executives want to get the system out the door. The old, “we’ll fix that later” comes into play.

Having an IAM team think through how permissions and policies will be deployed throughout your organization will take the weight off the developers when their managers don’t want to take the time to do something correctly. Hopefully an IAM team that focuses on IAM full time can implement things more quickly and correctly due to a singular focus.

The other thing an IAM team can do — given proper time and resources — is to construct automation to prevent the bottlenecks that were frustrating the organization I mentioned that had a data breach.

At that same company, I worked on the networking team where we were forced to manually create networking due to lack of time. I eventually spent some sleepless nights implementing as much automation as I could which helped us speed up and prevent errors in some of the deployments.

In addition, I later proposed a network architecture in an internal blog post after speaking with network experts at AWS. That architecture reduced the time and overhead to make network changes and deploy applications. Although I wasn’t in the meetings where the final decisions were made — that architecture is essentially what got implemented.

An IAM team who understands how to correctly implement policies can also try to create architectures and automation that help speed up the process of implementing IAM changes, while reducing the potential for human error. And they will hopefully understand how to do it correctly. Rebuilding the AWS console is not the correct approach. Leveraging automation to provide flexibility where you can while maintaining guardrails will allow you to leverage all the capabilities AWS provides while limiting access where necessary.

And, by the way, I recommend a team dedicated to networking as well, if you can. Networking is equally complex and can help you prevent data breaches, reduce the blast radius, and spot attackers in your network if implemented correctly. Those topics are also covered in my book which covers cloud security at an executive level.

Of course, at a startup company, you won’t have dedicated teams for each of these functions, but you can limit who has access to make these critical changes to a select group that you trust and who understands the security implications of their changes. As the company grows you can start to break up the duties into separate teams.

Permissions for Cloud Resources

When you’re operating in a cloud environment, you not only give people credentials, you give cloud resources credentials to do things in your cloud environment. The risk with allowing people to assign permissions to cloud resources is that a person may be able to give a resource more permission than the person has themself. This capability is know as privilege escalation.

The problem with not allowing developers to create their own permissions for their applications is that the developers know what their applications need to be able to do better than anyone else. Every organization will need to make a decision as to how much permission they want to give developers in regards to IAM, if at all.

If you can construct common patterns for applications then you can reduce the need for developers to create new policies. We are going to do exactly that with our batch jobs. I’m going to look for common patters that can be fully automated for new resources and projects.

However, you may have some developers you trust to create policies who are building very complex or unique applications that need special permissions. You can limit what they can do with permission boundaries on AWS and service control policies. That can set some bounds on the permissions they are allowed to create.

These two features of AWS again point to the need for a centralized IAM team that can set these overarching policies for the organization. They can also determine who is qualified to change IAM policies, and monitor the changes people make. When people make mistakes they can work with them to correct the problem. If they suspect someone is intentionally not following the organization’s policies and guidelines or not acting in the organization’s interest, they can alert the person’s manager, human resources, or executives to the issue.

Refactoring IAM for centralized management for batch jobs

I wrote about how refactoring can help security here:

What I’ve done in this latest round of changes is move all the IAM scripts to a centralized folder. The only think I didn’t move yet are the batch job specific policies I mentioned earlier. I’m still thinking about that. All identities will definitely be maintained in the iam directory.

I’ve created IAM admins. I now need to construct a way for these admins to assume roles for batch jobs that require IAM changes.

By the way, you can create policies that let users change their own credentials.

That’s a good idea in a lot of cases but for the batch job credentials I’m creating, I don’t plan to allow anyone to see the credentials used for automation if I can help it. I’m creating the credentials for automation, not necessarily for end users, but I want to require a user with MFA to approve the automation before it runs.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2022

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab