The raise of SIAM
As part of my daily job as a cloud security architect, I’m looking at SIAM security domain.
Most of my cloud designs are AWS related and some Azure recently and IAM is sensitive from my perspective as its the access gate to resources.
The key is to understand identity access management inside out and in particular, policies. And understanding how IAM policies relate to S3 Bucket policies and how they also relate to S3 Object ACLs and then when you have a conflict between all three, how you resolve that. BTW there will be many, many, many questions on that on this topic in the AWS security specialty exam if you are planning to get certified. And it’s actually really fun to do because in the exam, you’ll get a whole bunch of different JSON policy templates and you’ll have to go through and resolve them. You’ll have to figure out what you have access to based on different templates and it’s kind of like doing some kind of puzzle. You will have all the pieces in front of you and you have to come up with a solution.
Let’s get a recap of what IAM is. IAM basically allows you to manage users and their levels of access to the AWS Console. It’s important to understand IAM and how it works, both for the exam and also administrating a company’s cloud in real life. IAM, what does it give you?
It gives you centralized control of your cloud account. It gives you shared access to your cloud account. It gives you granular permissions. It gives you identify federation, including an active directory, Facebook, and LinkedIn. A very important topic in the AWS certified security specialty exam is understanding how to integrate an active directory with IAM. It also gives you multifactor authentication. And it allows you to have temporary access for users and devices and services where necessary and that’s generally using Cognito. It allows you to set up your own users, your own passwords, and your own rotation policy, and it integrates with many, many different AWS services. It supports PCI DSS compliance. In some critical terms in IAM, you have users, which are just your end users, so think people. We then have groups which are basically a collection of users under one set of permissions,you apply a policy to a group, and everyone within that group will then inherit that policy. Some policies obviously may conflict, especially if somebody is in a different group, so they might be in the HR group, they might also be in the system administrator group. For the security specialty exam, you will need to understand how to basically troubleshoot conflicting IAM policies. We then have roles. You create roles and you can then assign them to AWS resources. If you have done the SA certification you probably remember you would typically assign a role to an EC2 instance so it could access S3, for example. The policy is a document that defines one or more permissions. It’s always done in JSON.
However, as a cloud manager/architect/CISO as your cloud deployment grows and as a multi-cloud is becoming a de facto approach by many firms (that is a topic for another post) some SIAM solutions are starting to show up in the industry that simplifies and minimize the risks of misconfiguration, and management of over-privileged permission, risk assessments, and even (as you can see in my example) the ability to make changes, log a ticket, edit the Terraform file or edit the policy with an indication of the misconfigured line in the policy itself. Not going to name any one of the vendors here you can search yourself, what I did as part of my research consulting work is design a flow for the CISO persona (I’m still a product manager) the flow that can help him get a full picture on his IAM state and the ability to mitigate it.
The opening dashboard:
This is where the CISO would log in to the main dashboard so that he can see the full picture of his cloud security status. If you are a security architect (cloud or not) you will see some failure terms that are aggregated under a specific domain (my own idea).
The SIAM main page
When entering the SIAM main page you will have the option to filter any entity that is part of IAM and view its origin (who created it), risk level, the resource it affects, and option for remediation. The risk level should be defined based on the effect of resources, level of permissions, and the assignment to groups, for example, a member of the accounting group with full permission for the EC2FullAccess policy is an anomaly and should trigger a red risk indication. Start to get the idea?
Drill down to an entity
On the entity level, you may find critical information for it such as password policy, its complexity, MFA Yes/NO,permisstion, and the access effect and what remediation or simply keep it as a task.
What I like the most, how do you actually solve the problem and eliminate the risk, but before that where is the risk as shown in the JSON marked in red.
My goal in this blog post is to demonstrate a flow that clearly shows how to handle and mitigate IAM risks with fewer words and more images. If you think the flow needs improvement please let me know if you think it’s good and well define teh process and the problem is solved please mention it as well.
One last thing, I have seen some security vendors that do their first steps into this domain stating that they solve the problem using an agent-less architecture, diving into their solution I see that most of them are scanning the cloud using a “full dump” of the cloud environment and starts the scan offline using permissions the customer provides.
The problem with systems-based agenda is in production as agents may interfere with the operation of the workload, AWS, for example, suffer to deploy EC2 instances that already include cloudwatch agents (make sense). However, an offline operation does not affect any operation and its results do not have any effect unless you as an architect handle them. So what is the point of stating agent-less when it does not have any real impact? I also believe that SIAM solutions are excellent for multi-cloud, but if your deployment is a single cloud for example only AWS why would you need it? with all the internal AWS security tools it provides?