Identity at the Center is a weekly podcast all about identity security in the context of identity and access management (IAM). With a combined 30+ years of IAM experience, hosts Jim McDonald and Jeff Steadman bring you conversations with news, topics, and guests from the identity management industry.
Do you know who has access to what?
You’re listening to the Identity at the Center podcast. This is a show that talks about identity and access management and making sure that you know who has access to what. Let’s get started.
Welcome to the Identity at the Center podcast. I’m Jeff, and that’s Jim. Maybe you want to talk about some of the upcoming guests we’ve got coming up, Jim, and tease some of our future episodes?
Sure. We’ve got Julie Smith, from IDSA, making her third appearance, which will make her the current record holder.
The reigning champ.
She’ll be the reigning champ. IDSA’s publishing some new research. We’re bringing Victor Barris onto the show. He was cofounder of Identropy, which is the company that employed you and me for many, many years. The other cofounder, Ashraf Motiwala— we’ll have Victor on. We’ll have Gerry Gebel on from Strata.io, talking about identity orchestration, and Rod Simmons on from Omada.
Why don’t we get into our main topic for today, which is identity-first security. We’re going to talk about that and a few other things, and we’ve invited Gal Diskin. He’s the chief technology officer and a cofounder at Authomize, which you can find on the web at Authomize.com. Welcome to the show, Gal.
Thanks. It’s a pleasure to be here.
You’ve been in the identity and security space for quite a while, and one of the things, as the listeners probably know by this point, is, we’d like to find out the origin story for the folks that we have on the show and learn, how did they get into this? How did you get into the security and identity space? Is it something that you chose, or did it choose you?
That’s a hard question. Probably, security chose me, starting from a very young age. I was what you would probably call a hacker, even involved with some hacking groups as a kid. Then, at 13, I started studying in the open university, computer science, and I’ve been working in security since then. I also spoke in various conferences, like Black Hat and DEF CON and Chaos Communication Congress, about my research.
It’s always been, for me, about securing organizations. I worked for Intel on trusted execution environments and securing the interface of the software with the processor. Then I worked for Palo Alto Networks and the Cyvera startup in developing endpoint security and preventing ransomware and so on. Then I worked on the cloud with Palo Alto Networks, and that put me into blockchain and Authomize, which we do today. Authorization is always the Holy Grail for me, and IAM is the cause of it.
So, you could say identity is at the center. Zing. You’ve also helped cofound two companies, HeXponent and Authomize. What’s it like to start an identity or security company? Are there things that you learned from starting previous companies that have helped inform how you might want to operate future companies like Authomize that you helped cofound as well?
Yes, definitely. I tried to found a company when I was in my early twenties, and this didn’t work well, but it was the best learning experience I had because it taught me about the importance of not just technology but also business and product management, and these lessons brought me to learn a lot more about this, and it affected how I founded the future companies. I also joined a company as a junior partner, initially, to gain more experience, say, in being a founder. Yes, it’s a process, and being a founder is a profession.
One thing that I’ve noticed, that you guys just got put into Gartner’s Cool Vendor analysis for identity-first security, and that’s what we’re calling this episode — “Identity-First Security.” That document was just published this month, and so if you have a Gartner subscription, you can go out there and read it and see Authomize and other vendors that were put in that space. I was wondering if you could describe what identity-first security is, and explain to us what it was like going through the process with Gartner in terms of being considered, and then, how did it feel to be selected?
First, it’s a real honor to be selected. I think this is a very necessary milestone for startups to get to when you start any new area — the recognition from a prominent analyst like Gartner. The process is very interesting, because you go out and you start working on your company, and you start talking to analysts in Gartner. You get 30 minutes talking to different analysts and telling them about your company. They hear about your company, and they hear about a hundred other companies every week, and they talk to the big players and the big players tell them, “We’re doing everything. These small players are not needed.” It’s always about, how do you explain to the analysts why you are special and why you are actually able to do what you’re doing. Because there’s also a certain level of doubt, initially, when you talk to a startup.
We’ve gone through this process multiple times in terms of briefings to go to analysts, and at some point, when they start to be interested and they start hearing about you from other Gartner customers, they start getting more interested and more into it. Then, you start letting them talk to your customers, and you need to convince your customers to be willing to talk to Gartner. That’s the point where Gartner is sort of doing a due diligence about everything you said and comparing what your customer is telling about you to what you told them about your company. If everything works out and Gartner thinks that what you’re doing is going to be useful and cool and has traction, they might select you as a Cool Vendor. I really recommend other founders take the time and put in an effort into briefing the analysts, because they know a lot about the industry, and they can help you.
So, when they put together this grouping called identity-first security, it sounds a lot to me like zero trust, being that identity is the first vector — in other words, identity at the center. That’s the second zing at the show. What is identity-first security?
The way I understand it, it is similar to what you’ve said. In principle, identity-first security is about applying the principles of zero trust to the IAM plane of defense, right? Doing zero trust in IAM. I think it breaks down as most of IAM into the two classic components of authentication and authorization, and you also see this in the identity-first security Cool Vendors: Two of them are more focused on the authentication side of things, and two of them, including Authomize, are more focused on the authorization side of things.
The authorization companies in identity-first security — and this is something we’ve been talking to analysts about — is around the IDSM, or identity security management, and this is something that is starting to build up, and a category that I think will exist. I think it’s more interesting to talk about what defines it, because in a sense, even if we all go to that vacation on the beach and have fun, I think this category will exist eventually.
It’s terrifying that Gartner is an arbiter of cool. I don’t know if that makes sense, but it is cool to be part of it, right? What is the kind of impact that being on that kind of list gives you? There’s a certain cache to be part of a major analyst firm and saying you’ve won this award. Were you sitting by the phone at night waiting for the Cool Award nomination to come through? How do you celebrate that kind of thing?
I think it begins with, you’re just trying to brief Gartner, and you don’t even know that they’re going to define this category of identity-first security and decide that you’re a part of it, or that you’re even in the running. But at some point, Gartner told us that “we are going to probably publish a report that will include you as a Cool Vendor, and this is awesome. We’re not going to tell you exactly when, but it’s going to be soon,” and this is where we are.
So, it just comes out of the blue, and then, the next thing you know, you’re reaching into that cooler behind you — grabbing your favorite Scotch or whiskey to celebrate. You’re with Authomize now, obviously, and we don’t normally do commercials for vendors or anything like that, but I think it’s interesting to talk about what Authomize is. I look at the website, and I see the tagline “The first automated authorization management solution.” In simple terms, what does Authomize do?
The simplest is, Authomize helps you get the right people the right access at the right time, which is sort of saying “IAM authorization.” It deserves going a bit deeper. It also defines what IDSM is, which is, regardless of Authomize, what’s going to happen in the market.
Having this spider web of entitlements and permission is always something that a lot of companies struggle with, especially if they are multicloud or multiple on-prem apps and things like that. At a high level, how does the product work? Is it looking for entitlements and authorizations within each of those environments and then stitching it together somehow to come up with who has access to what — and then, where does it go from there?
Pretty much like that. We connect our products to different products that your organization buys — for example, SaaS solutions, IaaS solutions like AWS and so on — and we bring in the information about the entitlements, the assets, the identities and even the activities: how other people are using those permissions that they have. We normalize this into one representation of all the different authorization systems — and God knows there are too many, seriously — and what AWS did with their authorizations and information system, this should be listed as a crime against humanity, in my opinion.
We bring in everything — we normalize it into one representation that includes the usage, so we can make that map of activity to the entitlement that enabled it, and this means you have to be really granular. You have to understand the smallest assets that’s a user can act on so you can create this context. Then, we continuously monitor the changes and the activities to provide you with an ongoing map and controls around the changes in your authorization, and we automate the processes around getting this under control — and this, of course, applies to all identities, whether they are robotic or human.
So, where would a product like this fit into an IAM program and the other technologies or capabilities it might have, like privileged access management or identity governance or access management? Let’s say I’m an organization. I already have CyberArk, I already have SailPoint and I already have Okta. Where do you see Authomize in this type of collation of identity and entitlement data coming in and either enriching or augmenting or working in conjunction with some of these other tools, or does it replace some of the functionality of those other tools?
I think Authomize is solving the problem somewhat differently, but we are offering you capabilities that can, in some cases, replace your IGA or PAM solution. We’re not aiming to replace your SSL or authentication. We believe that this is part of the authentication layer, where we’re focusing on the authorization layer. This is part of our capabilities, as well as natural identity analytics and providing you with very powerful tools to manage your SaaS applications and cloud applications in general, which the traditional platforms tend to be less efficient for.
You mentioned the provisioning of robotic identities or robot accounts, and that, I believe, is the topic you’re going to speak about at Identiverse the week that this episode will be airing. Can you educate us a little bit on what that’s all about?
Respondent: This is research that I’ve been working on together with Avi, who leads the data science at Authomize. We’ve been looking at the usage of robotic identities initially. When I say “robotic identity,” it’s a general term for nonhuman identities, and it breaks down roughly into three types: We have the classic service accounts, we have user accounts used as a service account for robotic process automation-type purposes, and we have applications that are connected into our platform and acting within it.
Those are replicative identities. All of those are acting within your environment — touching your data, making changes, reading data, moving data and so on. As we’ve started looking at what they do and how they do it, we found several interesting things. We’ve been having controls around these type of accounts in Authomize from the get-go, and then the SolarWinds attack was published. It highlighted the things that we’ve been looking at. These accounts provide you as an attacker — and I’m speaking here and now from my hacker background. They are persistent. It means that if you ever hack this type of account, it’s unlikely that anyone will change a password or change an access key, revoke your access in any way. They are usually privileged.
For example, we’ve been monitoring accounts of all of our customers and their companies that have worked with us in the past, and 30% of these accounts have administrative privileges. This is even before we start talking about business privilege-type accounts. They are unmonitored. Nobody is monitoring them, which is one of the biggest attractions for an attacker. Last, you can hide the actual access they have via what we call chaining. This is the really cool part, I think.
It seems to me that with all the attention on ransomware right now, what you’re talking about is the anatomy of the attack, right? However you get in? It could be through a very nonpowerful human account. And then, if you can gain access to a privileged account, which may be very powerful, but probably has been excluded from some of the security controls in the organization, like frequent password changing — perhaps the account was even created when the password policy was extremely weak, but everybody’s too afraid to change the password on the service account because we don’t even know how it’s been used.
So, they become weak points within the organization. Smarter organizations start a program to manage service accounts with the technology like Jeff mentioned, CyberArk, but even for organizations, at some point, you’re employing this technology, but you have a boatload of service accounts that are already in use, so it takes a lot of time to pull them all in and manage passwords. Definitely, you could see how they can become a weak point, and we’ll definitely be interested to check out your talk about that.
I would say nobody is managing the life cycle of these accounts very well, so you end up in a company, and nobody knows who owns the service account. Is it actually in use, and can I delete it? Or even change the password — forget deleting.
Gal, you mentioned SolarWinds, and that’s the way that I found out about your company. You guys maintain a really good blog — and when I say it’s really good, it’s that I see a lot of technology vendors, I read a lot of blog articles, and a lot of them are just, “Here’s a big, five-page advertisement about our company,” and I’d say two-thirds of your blog article is independent, and it’s meant more to educate the reader, and so I enjoyed that. But you had a blog article on the supply chain hack specific to SolarWinds where you gave a little historical perspective of supply chain. That was one that I would direct our readers to go out and check out: Read the SolarWinds blog. There’s another one that I wanted to talk about: CIEM, cloud infrastructure entitlement management. Can you talk to us a little bit about that? I think this is a space that you’re focused on solving or providing a product solution for, but what is cloud infrastructure entitlement management? Why should we care about it?
When Gartner coined the term, they put it into the hype cycle of IAM and security technologies, and they made an interesting claim there: Their claim is that this is going to be obsolete before it reaches full maturity. The area that cloud infrastructure entitlement management focuses on is around managing the entitlements in cloud infrastructure vendors like AWS, Azure and GCP. CIEM can be summarized in one sentence: “You don’t use it, you lose it.” That comes down to if you are not using a certain entitlement in your cloud infrastructure, it should be taken away.
This is good for extremely high-security environments because it allows you to apply the principle of least privilege, but when you go to a lesser security environment — for my production environment, “You don’t use, it you lose it” makes tons of sense. But for my development environment in AWS, my developer needs to try and change the permission, so I can’t actually take away everything because he won’t be able to do his work. CIEM is a good approach for high-security environments, but when you go to a lower-security environment that you don’t need to apply “You don’t use it, you lose it,” it’s not enough.
Another way that I am disappointed with the pure CIEM approach, and we are trying to take a different mode of thinking in Authomize, is that it doesn’t look across different applications. It’s not enough to look at AWS because the code goes from GitHub to Jenkins to AWS. This is something that I feel — CIEM is very cool about getting the cloud infrastructure entitlements. But the thought needs to be far broader.
Yes, from reading the blog, I educated myself with that information, but I want to point out some of the identity-related security risks that CIEM looks to solve for — excessive permissions, misconfigured environments, which we know been a favorite attack vector for hackers in terms of how they actually treat data for some of the larger data breaches, limited visibility and external data sharing. Can you talk a little bit about how CIEM tackles those rounds? Is it that it identifies the problems and bubbles them to the surface, giving a dashboard to the security architect to know these were the areas where I have — excessive permissions, or I have a misconfigured S3 bucket, things like that. Can you talk to us a little bit about how CIEM works in the real world?
CIEM begins with getting the information about the entitlements from the product that you are connecting to — AWS, Azure or GCP — and the identities involved there. This is done by fetching the policies and publishing them, and, usually, using a graphlike presentation, which is also very popular in a CIEM product that you can get: This person gets access to these assets or this policy and that membership in that group, and so on. This is how CIEM begins.
And then, CIEM looks at the actual access logs to understand the usage and, based on the understanding of the usage, CIEM goes and starts making recommendations: Understand the privileges that people have, all the entitlements that they’re assigned to, and understand the usage of those entitlements, and then they go and they say, “If a machine is exposed to the internet, it probably shouldn’t be privileged.” This is one of the tenets of CIEM. Another way of thinking of that is, if this person is not using that entitlement, then he should be excluded from that entitlement. This is “You don’t use it, you lose it.” CIEM is taking these types of principles, and it’s generally creating a stream of events that you, as a security architect or a DevSecOps leader, are expected to look at, and take decisions and modify your environment.
Does this type of scenario allow for firefighter-type access? Can you flag an entitlement and say, “Yes, nobody’s using this, nor should they”? Either keep it active, or keep it part of a profile for access when it’s needed in break-glass scenarios? Does that model and that framework account for that type of scenario?
Yes, I think it does, because the way it works is, CIEM will recommend that you remove this entitlement if it’s not in use. As you get this recommendation, you can, of course, decide that “I don’t want to take this recommendation, because it’s just a recommendation.” This is part of the thing that is worrying, in a sense, because you get tons of recommendations a day. If you can’t get to a certain level of automation, this becomes just asking you to hire another person, or several people, depending on the size of your environment. But there’s definitely the ability to say, “This is for break-glass” and so on.
So, you rely on that institutional knowledge or platform or app knowledge to say, “OK, we know why this exists.” At least you have an inventory of it out there, which is part of the first battle that you want to fight. You’ve got to know what you have to be able to protect it. I think that’s really interesting.
Gal, thank you so much for joining us. But before we let you go and let our audience go, any final words of wisdom that folks listening can take away and be part of this journey as part of either cloud identity or identity for security?
The wisest thing I have to say is, you have to architect your security from the inside out. Things from the assets, outside. This begins with getting the authorization right, getting the identity right and only afterward looking at the network.
Yes, don’t assume that the environment is safe. That’s really where the mantra is, is zero trust, and then this model that Gartner has been putting out there. Jim, how about yourself? Words of wisdom?
Words of wisdom, and I think it’s a little unrelated to what we’ve talked about today, but I think it’s about having a great inventory to start — really knowing what are the assets that you have to protect. It’s so impossible when you’re starting at a point where it’s like if you don’t really have a list of your applications, it makes it really hard to be thinking about something like zero trust. So, I think if you don’t have that already, if your organization doesn’t have that, I don’t think it’s the IAM department’s responsibility to put together a CMDB, but darn it, if nobody else is going to do it, get it done.
Sheer will and effort. Heroics, as always, on the IAM side of things, as I like to say. Well, that’s a pretty good spot that we’ll probably leave it for this week. We’ll have some show notes and links that people can check out Authomize at. Again, it’s Authomize.com, and you can also connect with Gal on LinkedIn. We’ll have a link to his LinkedIn profile, and I’m sure he’s always happy to introduce and meet new faces. As well as Jim and me — we’re always happy to connect with folks online and learn more about what people are doing out in the world and take notes for future shows and things like that.
With that, we’ll go ahead and call it for this week. You can visit the show at Identityatthecenter.com on the web, and you can also follow us on Twitter @IDACPodcast, and we’ll talk with you all in the next one. Thanks for listening.
Thanks for listening to the Identity at the Center podcast. If you like what you heard, don’t forget to subscribe, and visit us on the web at Identityatthecenter.com.