Sonrai cloud security platform, products and services are covered by U.S. Patent Nos. 10,728,307 and 11,134,085, together with other domestic and international patents pending. All rights reserved.
In this session
Speaker
Ashish Rajan
Kaizenteq Ltd CISO & Host of Cloud Security Podcast
Get insights into the future of identity security with Ashish Rajan's session, "Identity 101: From Human to Machine and Everything in Between." Ashish sheds light on the shifting landscape of identity security by covering the intricacies of cloud identities, from human users to dynamic machine identities like APIs and service principals, challenging traditional IAM tools.
Key Insights:
- Evolving Cloud Identities: In the cloud, identities are diverse and dynamic, from human users to ephemeral machine identities. Embrace Infrastructure-as-Code and microservices for a robust cloud identity strategy tailored to this complexity.
- Beyond Least Privilege: Least Privilege falls short in the cloud. With rapidly changing permissions and third-party privileges, enforcing minimal assignments isn't enough. The challenge lies in understanding indirect and third-party privileges, not just direct assignments.
- Rethinking Traditional Tools: Traditional IAM tools, including IGA and PAM, lack cloud adaptability. Ashish emphasizes the need for a modern, cross-cloud solution. For those in multicloud environments, a dedicated IAM team should leverage third-party SaaS cloud identity security solutions for comprehensive coverage.
- In 2023, cloud identity security demands agility, visibility, and a strategic shift from conventional methods. Embrace the complexities, empower your IAM team, and secure your cloud with a forward-thinking approach.
Karen (00:00):
All right, everyone. We're going to keep this content moving. And whether you're new to the cloud or you've been in it for a while, there's always an opportunity to learn more. Our next session is called Identity 101: From Human to Machine and Everything In Between. You may be familiar with our presenter Ashish, who's a CISO and a host of the well-known Cloud Security Podcast. Over to you, Ashish.
Ashish Rajan (00:26):
Thank you for the lovely intro, Karen. Really appreciate that. Welcome, everyone. Today's session with me is about Identity 101: From Human to Machine and Everything In Between.
(00:36):
First of all, who am I? I have been in the cybersecurity industry for 30-plus years. I started my career in the identity and access management space, so I've kind of seen that evolve from what it used to be back in the day, if I can still use that word, to what it is today. I was a CISO in my last role before I decided to go down the path of becoming a host for Cloud Security Podcast. And in terms of other things that I do outside of cybersecurity, I'm massively into men's fashion and coffee, specifically third-wave coffee. If people who know, they know, I guess. So, if you know third-wave coffee, definitely chat to me later as well.
(01:09):
By the way, chatting more later. If you have any questions, definitely drop them in the chat and I'll answer them towards the end of the session. But at least at the moment I'll try and focus on the conversation over here and I look forward to sharing some value on identity access management as it has evolved over the years.
(01:27):
The way I would start that, when I talk about identity access management, normally people are going to go, "Isn't that something that's already been solved? Why are we still talking about identity access management? I know what username, password is like and I just know exactly what needs to be happening." Now, these are for people who probably have not been initiated and I assume in the cloud there would be at least a young Ashish out there who probably has never heard of identity access management.
(01:48):
So, I'm going to try and give a quick, hopefully a really short information about what identity access management has been. Described as, it has the ability to create and manage individual identity lifecycle efficiently across all environments and applications. Now, all that really means is that if I am a user, which is a staff or an employee for a company, how do I make sure that the entire time that I have been an employee of the company, I'm able to effectively do my job through the permissions that I've been granted? I'm also effectively be able to be active across the system that I should be active across. I'm also someone who is informed about if I have to do any kind of approval for change of access because over the years that I've been in the company, I've also been given a promotion and I moved on as well. So, it's basically lifecycle management is that's what people talk about.
(02:41):
Now, traditionally this would have been very different in the on-premise context. It would involve a lot more things like you have your governance and policy, which is the idea that, hey, great that Ashish is an employee, but how do I make sure that he's an employee today? How do I make sure that he's an employee tomorrow and day after? How do I make sure he's not breaking any policy requirements? So, this is something called IGA or Identity Governance and Administration. What I spoke about earlier is primarily more around the user management part where you're making sure that the user Ashish or whoever staff that you have in your organization, you are able to manage those users effectively.
(03:20):
Now, another thing that comes often is the separation of whether you are a regular user that just can access, I don't know, Excel, PowerPoint and Salesforce or some of the common applications that everyone should have access to, like your HR system, your leave application system, and other systems like that as well. Specifically talking about cloud context, you may have the segregation to go, my users in this particular role should be able to access AWS, Azure, Google Cloud and the resources that are there hosted in that particular cloud space provider as well.
(03:51):
Now, the same can be extended on for privilege access as well. Usually, you would probably have a smaller set of privilege access management, which is preferred to be more of an ephemeral access. By ephemeral access, what that means is it's temporary. Back when we were still trying to figure out what privilege access management was as an industry, we came up with the dot-a or dot-admin account. For people who have been there would know this, that if Ashish had a regular account and Ashish also had an admin account, the admin account would be called a dot-a account or a dot-admin account, which is pretty obvious, but the idea was that I'm only using it when I'm required to use a privilege function. Now, that same has been transitioned over to the cloud environment as well because that is very much part of the identity lifecycle.
(04:39):
Another thing which has been part of the identity lifecycle, which usually comes down to the application side is entitlement management, where the simple understanding is just that, least privilege access for users. That's probably the simplest way to explain it. Now, that's the primer for people who don't know what identity lifecycle management is. This is how I would describe it, and you probably would notice also that the process earlier versus what is used today is... For people who have probably been in the waterfall era, you probably would realize the projects that we used to run for identity access management, there used to be a lot of thick applications that you have to install identity for, writing some kind of custom library, and because of that, most projects which were for identity access management would last for one year, two years, sometimes even longer.
(05:26):
I personally have been on projects which have been there for at least a year, and if I were to summarize what is, I guess, the purpose of that project, it was literally to make sure that the lifecycle management for an particular application was maintained and over that period of one year, it was such a big application, we only ended up doing one application for one entire year. So, the project length used to be quite long and we used to be operating more in the waterfall methodology. There were no swim lanes or Agile methodology. Access management definitely evolved quite a bit more from just being a local user. It evolved to more of a single sign-on which is a known standard for authenticating users across multiple applications. So, it definitely evolved and matured quite a bit. Onboarding process became a lot more about where it needs to be on approval base, where it doesn't need to be just-in-time provisioned.
(06:18):
But the reason for this also was because we were dealing with a lot of monolithic thick applications as I mentioned, and in case you don't know what monolithic thick application is, and if you're probably from... Actually I'm trying to think, I don't think many people install a lot of things these days because I think the install word has such a big taboo, but in traditional organizations like the banks and other places, if you are working for a financial institution, you probably wouldn't know this, that there are certain applications that you have to open. It's not on your browser. You have to literally open, like for example, if you are someone who uses Microsoft Word, you have to, if you don't use the Office 365 version, you're basically opening up an application. That is usually called a thick application. Back when the non-monolithic times, they were primarily application that were thick applications. Now, it kind of has evolved sometime as well.
(07:08):
I wanted to kind of set the primer so at least everyone that's over here is on the same page and no one's basically left behind. So, now that we have that clarified and we have the primer set for what identity lifecycle is and has been for a long time, I would probably say it's also around the fact that in public cloud, identity access management is fundamentally the same but logically different. This is not that different from how you would have traditionally done identity lifecycle management, but it's definitely logically different in the context that now you have an external set of users that you have to manage.
(07:45):
But that's what I mean is this is how we have been doing identity access management where we have an onboarding, there's a workflow, just-in-time provisioning. We have sometimes a semi-manual automated process for approval, but sometimes we may just go down the path of giving automatic access. Access management these days is primarily single sign-on, MFA is like the default for a lot of organizations unless there is a restriction on the application or the way it behaves. The project length these days, depending on how aggressive your Agile methodology is, you might be looking at at least two weeks of operation. No one's really waiting for one year for something to be delivered unless you're in a thick data center. Most identity access management projects are still probably down to about two weeks a year.
(08:30):
I think the last Agile project that I did back when Agile became a thing, we deployed about 400 applications in a year's time, so just to give you some context how quickly things have kind of evolved and changed in the way things work and all this was also probably accelerated by the fact that nowadays people are using more of microservices rather than using your thick application. That makes it a lot more API driven. More things are on the Webflow.
(08:58):
Now, I know this is a broad generalization, but the fact is still the same. That the type of identities have changed and there's more than one solution that most organizations require for IAM. And the reason for this is that now the kind of users that we have to deal with in 2023 are a lot more than just humans. Traditionally, human users have just been your personal laptop users, your privileged users, that the dot-admin account that I mentioned earlier or dot-a account that I mentioned. Off-boarding used to be a lot more simpler, that as long as the IT has off-boarded me from all the systems, we are all good and by that system what I mean is my laptop access is taken away. All the thick application access taken away. I didn't have to think about anything else.
(09:40):
Now, in 2023, humans have access to not just their endpoint laptops, they have access to IoT devices, they have access to cloud, they have access to resources inside the cloud. They have access token for cloud. The complexity of how much a human user either has a set of secret credentials versus the permission versus the type of access they have is a lot more complex these days when you through identity management these days.
(10:12):
The other complexity comes from the part that you have machine users. Now, machine users by themselves are not spoken about enough, so it's worthwhile calling out. These could be more from a perspective of, hey, I have a user which doesn't have a link to any existing employee. That's pretty much what a machine user would be, so a non-human user, for lack of, I guess, better term. The idea over here is that how do we make ourselves more efficient and the cloud answer to all of that was, hi, you can do this if you have non-human users, basically robots doing a job for you, and by robots in this context would be a virtual server that seems to have permission to run certain things without the involvement of a user. You have service principles in Azure, you have IAM users, IAM instance profile in AWS and a lot more that you can actually trigger even without the need for you to have me logging in with my own credential to make sure things are working. It just happens automatically. That's kind of where the machine users come in.
(11:16):
Now, the reason I call this out is because when most people think about identity and lifecycle management in a 2023 kind of era, most people are still thinking what I've spoken about just so far, which is the human user part. A lot of people have gone down the path of not understanding what that means from a machine user perspective, especially if you realize that there are marketplaces within the cloud service provider where I can have, I don't know, just some kind of a performance monitoring tool that I have integrated, which is using some kind of credential. How would you manage that? That's technically a machine user.
(11:50):
Also a third party user, which is also my third category over here. A third party user because the cloud service providers don't have all the capability of using a... What's the word for it? They don't have the capability for everything that you would expect from an identity access management solution, like they do the lifecycle management. They make sure that hey, does Ashish have access? Yes or no? Does Ashish have password management complexity? Yes or no? They also talk about the fact that am I provided the right level of access? How much do I have access to? And as you add more layers, they do work in the context of does Ashish have access to another tenancy?
(12:33):
But it does have a few gaps. A gap, for example, would be if I have access to AWS, doesn't necessarily mean that I would be informed of the fact that by the way, Ashish also has access to Azure or GCP, Oracle Cloud, IBM Cloud, add another cloud in there as well. So, I normally tend to go down the path of understanding that these three kinds of users are primarily what you're dealing with when you think about lifecycle management. And some of these examples may be different for different people, but in most organizations what you would find if your identity lifecycle management does not cater for the machine users or the third party users, you should definitely think about these two users as well in this context as well.
(13:17):
Let's also talk about the local cloud users. Something to be wary of, as much as enterprises would like to go down the path of having a single sign-on solution where there's federation involved in it, and as my dog goes in the background, as much as local cloud users exist in a Amazon context, they also exist in the context if you're multi-cloud and you may be using an Azure environment today, but you also happen to have Google Cloud. By that analogy, if you kind of dig a bit further, what you might realize, you also have a Google Workspace with Google accounts in there as well. So, you already have two sets of users that you're trying to work with at that particular point. You have the Azure user on one side and you also have the GCP users and then also have the IAM users on AWS as well.
(14:02):
So, something to be wary of, then if you can know the different kinds of cloud service provider services that are available, what I just gave an example of is just how the accounts are configured in a Amazon, Azure, Google Cloud context, but there are also privileged users. There are also users for, say, services like if you're using a platform as a service from your cloud provider. For example, if you're using a database which is being provided as a platform as service, that might have local users as well in there that you might have to think about. There might be encryption requirements that you might have think about.
(14:37):
What this also means is that when you're off-boarding, and unfortunately I've been part of this scenario in quite a few times, where even though I have left the organization, I still had access to the AWS account or I still had access to the Azure account, and it is very well-known that because the IT environments, or at least the automation in the IT environments are not designed for automation for your cloud context, unless you specifically call that out, it probably is not the right way to manage the users in there.
(15:08):
Then there is the unlikely scenario that hey, even though we have something called a shared responsibility model that's shared by a cloud service provider, which talks about the fact that by the way, we do not access anything in your account, we just manage the cloud service provider accounts that we have. On our end, we don't really do anything apart from measuring the fact that yes, Ashish has request for hardware and they get the hardware as well.
(15:31):
But if you have looked at the recent, well, maybe not so recent, but the Capital One hack that happened where it went to the court case, in that particular scenario, it was an Amazon employee who got the access keys for something which was in Capital One, and there's a whole walkthrough. If you search for it on YouTube, you'll probably find the walkthrough of how that was done, but essentially using SSRF, someone who's an Amazon employee was able to go into the resources that were hosted by Capital One. Most of us would not think of a scenario from an identity and access management perspective where, by the way, what happens or what do we do if a cloud service provider account decides to start take over on our side? There's no monitoring for that.
(16:13):
And then the third one is probably, which you already may be thinking about, which is everyday thing for most people, which is thinking about the external attackers or external threat attackers that people are maybe using at this point in time. That may or may not be systems you may be creating in the cloud. They may be the, I guess, the attackers on the internet who probably be creating profiles on your cloud environment. That's kind of how I would describe identity access management.
(16:39):
Now, I want to go through and kind of like if I just take a quick pause for a second. What I've spoken about so far is I have identity access management, how it used to be. What are some of the components you have to think about from a human all the way to a non-human, all the way to a third party and how shared responsibility sometimes, you can work off the risk. Now we're going to talk about the how do you actually do identity access management for specific lifecycle management use cases, as you go through the human, non-human and the third party users scenario.
(17:12):
Now, from an onboarding perspective, as I mentioned in the beginning, it has become primarily a standard, at least in enterprise, to use single sign-on with MFA. Now, if you are using a cloud service provider and you're not an enterprise, you can still use existing services from your cloud service provider to have single sign-on, which I'll highly recommend, but the one thing probably is, which is more important than that, is to have a single source of truth.
(17:36):
Now, the single source of truth basically means that if you have 10 employees or if you have 10,000 employees, all of them exist in one particular place, whether it's your HR system or whether it's a database or whether it's whatever the kind of resource that you have, that should always remain the source of truth for how do you identify that yes, this is Ashish. If I happen to have another Ashish in another account, that should technically not be something that is onboarded automatically, if that makes sense. There should be some kind of alerting for it. What you can do is you can also have alerting based on the fact that if there is a new admin user being created, how do you alert on that? You can also have the onboarding part fully automated if you like.
(18:18):
Now, automation in this context is more the whole CI/CD pipeline, but it only comes in much later, especially if you are trying to do some kind of a, say, local user creation. It's usually harder if you're trying to do single sign-on automation because there's a handshake required. So, if you are using single sign-on, then automation is a bit limited, but if you were to, say, be a small organization that is just using local users in the cloud, then you would be able to do at least a lot of identity provisioning quite automatically. But for others, they should also be considering something called just-in-time provisioning for anything new or being onboarded.
(18:56):
Now, I wrote this quote because I thought this is really interesting where we follow a least privilege principle and continuously automatically verify no one has ever done this before. So, the funny part over here is if you ask anyone, they always tell you that, "Yeah, yeah, sure, we do least privilege. We manage and make sure that everyone has least privilege and it's always monitored and it's automatically verified." No one said this ever, because at any given point in time, the complexity of the number of users, the complexity of the application, it just practically is not possible.
(19:32):
A great example for this has been from Okta and Uber, where even though they had, and I'm not saying they did anything wrong. In both the scenarios, at least in the Okta scenario, it was a third party that I guess got affected. They were hacked and because of that, Okta was infected, but I'm not saying that they are examples of companies that are not doing it. All I'm saying is that there are some scenarios which are out there, which clearly call out that if least privilege is maintained, that should have not happened. So, something to be wary of as you kind of think about least privilege.
(20:06):
Let's talk about lifecycle then. I spoke about onboarding. How about lifecycle overall? The provisioning and de-provisioning of users, the privilege access management, entitle management. Now, the one thing I'll call out over here is that the entitlement management probably is something that requires a lot more attention than, say, the other components. For example, user management, the IGA visibility, as well as the privilege access management. That has not evolved that dramatically, especially if you're already doing single sign-on MFA, you already have some kind of a privilege access management solution that you're using or without being the separation. You're at least being able to do that from a perspective of you have ephemeral privilege access. You are using temporary credentials, you're not giving everyone the access to cloud as well. So, the top three are probably fairly similar to what you would have seen.
(20:53):
What I want to focus our attention is on entitlement management and why there is a need to discuss that as well. For example, entitlement management has always been about least privilege, and as I called out, no one ever said this that they have done a perfect one. The reason for this is because traditional privilege access management, if you have one in your on-premise environment, you might find that it does not work well with cloud. It may not understand the context of cloud. It may not understand the fact that, oh, there are local users. They would encourage you to go down the path of single sign-on, but they may not have an alert for in cases a local cloud user being created, make sure it's deleted. Or the two concepts are kept separate for some reason in the privilege access management. And in saying that, they are trying to work towards to be more cloud native and cloud first.
(21:37):
But at the moment as it stands at the time of this conversation, you would find that most traditional privilege access management solution, which for people who remember, you have to log in, it records the entire thing as to what you're doing, all that is fairly limited in how you can do it in cloud context. It's more of a, I think sometimes some people call it bandaid fix, so maybe a more of that. Cloud native usually kind of works, and by cloud native, I mean that if you're using entitlements in, say, permission management in your cloud context and making sure that Ashish has the right privilege, you're trying to manually do that. They have tools, like I think AWS has something called IAM Access Analyzer. There's security control center. There's a lot more native features that are available in your individual cloud service providers. But if you're an organization that depends on multi-cloud, then these tend to fail at that point in time and they don't really work. So, keep an eye out for that.
(22:33):
The other thing I would call out from entitlement management is the non-human users. Whether the non-human users are ephemeral as well as for non-ephemeral services, you need to keep an eye out for that. The entitlement management I would call out is primarily driven by SaaS application these days, which require their own entitlement management category because if you think about it, the average number of SaaS applications which have identities in your organization. You probably have wondered, I think there was a stat that came out, 250-plus SaaS applications, that means 250-plus identities that are different to your employee identities. These are the ones that you probably would be aware of, but not the ones that you are not aware of, that people are signed up with their corporate email.
(23:16):
That said, and this is kind of what I wanted to leave you with as well, so in the last minute that I have, I just want to call out the feature that entitlement management is something that we probably want to focus a lot more attention on just because of nature, specifically, if you are in a multi-cloud space and SaaS applications, human users, non-human users. Keep an eye out for that in lifecycle management.
(23:37):
That's mostly what I wanted to talk about and the idea was to share what has been a pattern across the board. I would wait for Karen to come online and maybe ask some questions as well that have come through.
Karen (23:47):
Thank you, Ashish. That was great, and we have a bunch of questions and not much time, so I'm going to dive right in. Melissa is asking, are machine identities as risky as human identities?
Ashish Rajan (24:00):
It can be. Again, if there's too much privilege given to any users, they're all dangerous. So, I would say as long as you manage the least privilege principle, you should be fine, which is easier said than done, but as long as it's maintained, you should be able to manage them accurately and they should not be more dangerous.
Karen (24:16):
For sure. And another question from Sean. When do I need to make the switch from native tooling to third party tooling in order to secure these identities you're talking about?
Ashish Rajan (24:28):
If you are a small organization today with, say, less than 20 users, you probably don't have to think about getting some kind of external solution, cloud native solution to a great job. The moment you go into the multi-cloud space or if you have a dedicated identity access management team, you're definitely looking at getting a external solution. The chances are if you have a separate dedicated IAM team, most likely the identity you're dealing with are quite complex and quite large-scale. So, you definitely need a third party solution, especially in a multi-cloud context.
Karen (24:57):
That's great. And then I'm going to jump in with a question to wrap us up. Can you be really specific with tools and tips that people can take away to put into action, when they get back to work in the next couple of days? What are some just next steps for people to be able to get on this journey?
Ashish Rajan (25:14):
Discovery is probably the best recommendation I can give. Based on what you've heard today, if you know that you probably are only catering for human users and not for non-human users, I would definitely do a discovery exercise just to see what kind of users are there in the cloud context. Non-human users and third party users, nine out of 10 times, mostly people don't even cater for that. So, if you start there, the rest of the gap would at least help you show the light for where you need to go next.
Karen (25:43):
Wow. Is that what you just said? 10 times the number of human users are machine?
Ashish Rajan (25:48):
Yeah, well, I was saying more like it definitely is a lot more. In the context of human users, they're definitely always less than the non-human users. I think I spoke to someone as part of the podcast on Cloud Security Podcast and they said that they had 10,000 Lambda functions, between 10,000 IAM roles in AWS, so that's just important to scale as well.
Karen (26:09):
Wow. Yeah. I'm sure it varies by organization, but the takeaway is machine identities are really rampant in the environment, so discovery is a great takeaway. Thank you for that.
(26:18):
And thank you for the presentation. You've really given us a really solid foundation about understanding identities and cloud and how it relates to IAM and cloud security, and we didn't have time for all the questions. We're going to have to wrap up, but Ashish has agreed nicely to stay on and address additional questions, so if you asked a question and we didn't get to it, he's going to address that in the chat and if you still have some lingering questions, go ahead and continue to put that in the session chat, and Ashish will engage with you there. So, thanks again for that, Ashish.
(26:47):
And join us for the next session. It's called No More Cloudy Minds, and we're going to go through a guided meditation to give everybody a chance to relax and regroup before we move on to additional sessions. If you'd like to, alternatively, you can join the networking group for that break and then we'll see you back for more sessions later. Thanks, everyone.
Ashish Rajan (27:07):
Thanks, everyone.
What Sonrai Customers Are Saying
“Setup was quick. Intel came in a day. And before our next quarterly security review, we had removed thousands of paths to data and removed machine identities that IAM didn’t register as admins. Just finding this identity risk anywhere else would take months.”
Director, Cloud Security, Fortune 1000 company
“Sonrai offers full visibility into effective permissions and the identity chain – giving my team value insight to identify, root cause and remediate identity risks.”
Source: G2
“Sonrai is one of the leaders in this space, both from a product maturity perspective, and the thought leadership.”
Source: Gartner Peer Reviews
Free Cloud Identity Audit
Uncover your cloud identity risks in 24 hours, with recommendations on next steps to immediately reduce your risk. Completely free and it only takes 10 minutes to set up.
