UPDATE: We have a new podcast host - Jim Mandelbaum! We will certainly miss Mike V as Jim takes over the reins and we know he will do a bang-up job. Just listen to his fist episode here! - Jon
Now ... about this episode ....
Ensuring that the right person, has the right access, to the right application(s), at the right time is essential to any organization's security and operational efficiency. And - when you move to the Cloud, your identity footprint expands and becomes even more complex to manage.
In the episode, Jim speaks with Diana Volere, a Senior Security Partner at Netflix. Diana walks us through best practices for identity automation, building authoritative sources, privileged access management, why LDAP and Active Directory are not enough and discusses the new reality of how identity changes when you're in the Cloud.
Listen to other Navigating the Cloud Journey episodes here.
Ep8 – Identity In The Cloud, Diana Volere, Netflix
Jim: Hi everybody. Jim Mandelbaum here welcoming you to my very first navigating the cloud journey podcast.
A little bit about me. I am Field CTO at Gigamon and prior to that, I was a Field CTO at RSA. So, I have a pure security background. And I'm a standing member of the High-Tech Criminal Investigation Association. So, this is all in my wheelhouse.
And today as my very first guest on the journey, I have Diana Volere from Netflix. And Diana, would you like to introduce yourself and maybe a little bit about your background?
Diana: Why thank you so much, Jim. My name is, as you've been told, is Diana Volere. I worked at Netflix now for about nine months, focused upon bringing identity governance to the Netflix broader ecosystem.
And prior to that, I've spent about 20 years, obviously I started when I was five, in the identity space with a number of different vendors and working in the services organization, really helping large businesses understand as they're doing some sort of digital transformation, how they can actually do so safely, which I believe everything around that is cybersecurity through the lens of identity. So, I'm very excited to be here today. Thank you for the invite.
Jim: Let's let's be a little transparent. You and I have known each other for quite some time as I have a background in identity as well. So, we're going to have a little fun here today, folks. These are friends, bantering, back and forth.
You brought up a comment and I want to make sure. What the heck is that identity governance administration that you touched upon? What in the world is that?
Diana: Fair enough. You hear identity access management was sort of a preterm where we talked about making sure the right identity got the right access to the right resource, at the right time, for the right reason. And identity governance is really about putting in place the processes and policies around that to help ensure oftentimes we tie it to automation. I want to be able to automatically know that based upon policies and principles, I'm giving that right access to the right person at the right time and not giving excess access to somebody who doesn't need it.
Jim: From a security perspective, how does that differ on prem and in the cloud?
Diana: Oh, so if we start with identity on premises and we think about identity governance, historically, this used to be a lot about, hey, how do I make sure that my employees have access to what they need? It was employees, it was contractors, maybe citizens. As you start doing this digital transformation, moving to the cloud. There's two things that really impact us in this. The first one is the very definition of identity has kind of changed. It used to be a person, but now pretty much any sort of discreet entity that I can say fits a certain type, like a person, a contractor, a vendor, and has a certain set of principles around it about how we give it access to other things is an identity. So,, it's not just people anymore especially as you move to the cloud. It can be service accounts, but it can be serverless functions. It can be anything that we are trying to apply policy to and automate access. So, as we go to the cloud, the volume of identity just explodes. It's no longer my 200 employees. It's my 200 employees, my 500 service functions, the workloads I'm spinning up and down. The number of things you're trying to get your arms around and secure expands exponentially. And with that comes the ephemeral nature of it. If I'm spinning up a workload and back down a workload for a peak season for two hours, how do I know that the right people have the right access to that server at the right time when it was here and gone so fast? So, governance in this has to be a little bit smarter in terms of addressing that ephemeral nature. It has to be faster. It needs sort of the compute power that you can bring from the cloud to be able to deal with it. And there's a lot of other aspects to it, but I'd say those are probably some of the key differences as you're trying to talk about cloud identity, as opposed to on prem.
Jim: So, you're, you're talking about virtual machines and we know that one of the secrets to getting value out of the cloud is automation. Is this what we talk about when we talk about non-human entities?
Diana: Yes, absolutely. When we start spinning up new applications in the cloud and application that needs access and application is a non-human identity in this sense. It needs to be able to access certain data on the backend. So, you have to be able to authorize applications appropriately or the person using it. But you also have to be able to authorize everything from what is my server that's spinning up right now, or my database who needs access to my cloud database. All of these are non-human entities that we have to able to put that policy around as well.
Jim: I want to dive into that a little bit. So, when we talk about that, let's use when you've got a database that you've spun up. How do we associate that to a role or a person? What would be the best practices on how do you associate that because you need to have that accountability.
Diana: Absolutely. There's a couple of different types of accounts that I'd want to look at when we're talking about a database. If we're talking about the normal user who just needs to be able to read data from it, perhaps do some actions on that data sometimes right that data in a standard user account. In the cloud as you are spinning up new instances, you already want to have in place automation and policies to secure that. You have to be able to detect that it's spinning up. If you are in AWS, you can plug into event services, et cetera. So, you need, first of all, that detection so that nothing can be spun up and just fall through the cracks because we weren't really watching for it, it's so fast.
So, you have to have the appropriate detection and appropriate automated response to that, that a cloud database spun up in this region with this sort of characteristics, by this person, automatically gets this set of principles applied to it out of the box. I mean, that's one of the big things we see as the risk right now. People do not inherently have all the skills to spin up the right security around a database that they're bringing up in the cloud. And that's where we see a lot of those loopholes with something getting hacked. They don't turn off the wrong ports that they want to not have clear text, details like that. So, really that automation of detection and immediate application of policies, is very critical.
Jim: You talked about the people. Who are the people that manage the identities? Is there a different group that would normally be responsible for identities versus people that are doing the architecture? How do you bridge that? I'd love you to take a stab at that.
Diana: So, in all truth, it kind of depends on the size and maturity of an organization. When you have a smaller organization that does not have a wide variety of employees in the architecture side, or doesn't, especially if it's privately held and simple out of compliance requirements, et cetera, then you'll often find then, that just kind of falls into the normal security administration.
As you start seeing organizations grow in size or grow in their volume of transactions or customers, you usually do see identity within the organization becoming its own particular vertical group that focuses upon it holistically for the org. I can talk about it. Netflix. We have a team that's particularly around identity and access, but at most organizations you'll find once they cross a certain threshold, that becomes a key part of the discipline of the org. Being able to have that digital hygiene relies upon people who are focused specifically on understanding who is active in the ecosystem, understanding what, not just who cause digital identity, as I said, could be something other than a human. Understanding what is active in the ecosystem and truly thinking about and putting in place as policies and automations.
You won't always see it just be a broad InfoSec thing with one person. You'll often see it as a true discipline, a team that has a number of people as a part of it. Because they have to interface across your organization across the entire, from HR to payroll, to finance, to physical security, to logistics. It really does require someone truly with all attention and eyes on it.
[00:08:23] What triggers the need for an identity effort and how to avoid it.
Jim: I'm going to kind of follow that thread a little bit. You brought up a dedicated group. In an organization, what usually triggers the concept of, we really got to get a handle on our identities, especially as you look at, you laugh because we all know those of us with an identity background, we know what typically triggers, and I'm gonna let you answer it. But the roads' paved with failed identity projects. So, I'm going to ask you; number one, what triggers the need for an identity effort? And then, what roadblocks are there to actually having it succeed?
Diana: Regrettably, but in all honesty, most often organizations decide they need to get everything together around identity once there's an audit finding. So, it's either going to be an audit finding or they ended up in the front pages for a breach.
Jim: Oh, that's never good. No, no, but those, there is such a thing as bad press.
Diana: We wish that this was something that organizations looked at proactively. And, if an organization is doing a lot of mergers and acquisitions or is in a space where they have a highly volatile population, they're more likely to have addressed it. But in general, it is more reactive than proactive regrettably. And especially when you're coming at it from that angle, a lot of times you see failed projects because they are reactionary. They are either a very single tactical thing of, oh, we had this one big finding, we've got to fix one problem. Or they're this sort of ephemeral like castle in the cloud scope of, we want to make identity better for everyone in the org. and we're going to do this eight-year program that's going to do it, that doesn't deliver anything immediately. So, getting that fine balance of, we want to have a project that needs to have a strategic view, but tactical delivery of value, is essential in this because it is a long program and it's the sort of thing that can easily just get, we're not seeing any value of this, we're going to shut it down if we don't have that.
Jim: So, if I'm hearing this, I'm going to shut it down. What do I need to do? How do I get over the roadblocks? What do I do to make it successful?
Diana: One of the first things that you've seen and, you can find this backed up by Gartner Forrester, or any of the research of an effective identity project and program. And I'm going to use the word program because if you view it as a project to one hit and done, then it will start becoming legacy and lose value immediately.
It needs to have that appropriate perspective that this is essential to an organization's future security and agility. This is not just security. This is operational efficiency. This is saving money as well. And with that, you need to have a sponsor high enough up who has the motivation and the capability to drive it a bit.
Jim: The Juice.
Diana: Yeah. Need to be able to have the juice somewhere in that because otherwise it's not, if it's just coming up from a grassroots sort of perspective, it usually involves one department and then it fails, or then it dies.
Jim: So, in a cloud concept though, when should I engage? Should this be something that's engaged as part of development? Should this be part of something that's part of infrastructure? What group, where should this be engaged and what group do I engage it with?
Diana: I was going to say yes to every single thing you named probably there.
If you start with the developer side of the community. You have so many developers that are now putting in place key pieces of infrastructure as code, something that could be highly vulnerable if somebody gets access to it, that they shouldn’t. So, you want to start even right there from the developer side, ensuring that you have the right governance and policies around it. Don't let somebody QA their own code. Don't let somebody promote their own code through the cycle, for example. So, from that side of the spectrum, at the developer side, all the way to, as you're talking about, infrastructure, there's almost every area.
The foundation of security comes from knowing who has access and knowing what they're doing with it. So, it. I know holistic is like one of those overly, over endowed with meaning words, but it absolutely applies to this case. All security as you go forward should be based on identity and understanding.
So, almost any group you name, should we be thinking about it there? The answer is yes. Now, is that the question you were asking, or did I take that the wrong way?
Jim: No, no, that's a perfect answer, but I guess the question I have now is, if I've already started the journey into the cloud. Is it too late?
Diana: Well, it's never too late, but you may find that it's a little bit harder, because when you start making that transformation of the cloud, it's like that instant expansion of your landscape, expansion of your footprint. And it's very fast, very quick to start realizing that you don't have your arms around everything that you own. The development is happening without your eyes on it. You're deploying new servers in regions you didn't know this was happening. You would have expanded to the point where you don't really have the visibility into what's going on.
So, if you're already in the cloud, yes. One of the first things you want to do is start looking at identity and start doing that inventory of what's out there and start implementing things to get your eyes on what your footprint actually is. Is it easier if you come in proactively with it? Yup. Yup. Do organizations do that? Uh, few and far between.
Jim: Usually it's an after the fact. So, let me ask you another question. I love this response. We talk about identity. "Well, I use LDAP or I have Azure Active Directory. Isn't that my identity practice? Haven't I got identity solved?"
Diana: It used to be that when you had the little, tiny LDAP directory that was giving access to five apps, maybe it may be in that environment it works. But as we expand the number of applications and the types of access people have, so it's not just, can somebody get in the front door, like federated identity. I've authenticated. I have access. It becomes more focused upon granularity. Just using AD or LDAP, which there's a whole conversation around the distinction between active directory and LDAP, and LDAP is a protocol, I'll table that. As you start trying to look at that as an identity platform. There's not really tracking on when did somebody get that access? Should they have that access? There's not automatic automation in it. There's no automatic review of, hey, who is in this group that has this critical access, and should they be there? There's no understanding inherently of the risk associated with it. All of these aspects of governance that help you start reducing your risk require more than just having a place to drop somebody, a group to drop them in, and say, okay, everything's solved. They're in the HR group they can see the HR app.
Jim: Let's talk about authoritative sources. We're really talking identity. What is authoritative source?
Diana: So, an authoritative source would be the place that you can trust to have the truth about the identity you're dealing with. Almost always be about is HR. Human resources really knows when I was hired, what my start date was, what my name and location and title are. That usually comes from something like your HR system.
Sometimes payroll, sometimes you have a vendor database, depending on the type of identity. But you need to establish where those sources of truth are, those authorities over identity data. And it almost always is not exclusively one app. And I talk about human resources as the authority of most of my data. Oh, they know my title and my position. Do they know my email address? The email system is going to be authoritative. It owns that data. You could say whatever you want in HR, but that doesn't necessarily reflect the truth in my email application. So, you may have what you would call a hybrid authority for a person. You're kind of stitched together with data from different things, different apps, different locations, but you have to know where any information about an identity is coming from. What is the authority for that information in order for it to be reliable, as opposed to saying it's AD and LDAP.
Jim: So, so let me tie together a couple of concepts that you've talked about. So, we've got the authoritative source. We've got a reason that active directory LDAP exists because it has data that HR may not have. And we've also talked about the idea of federated identities. Let's kind of tie that together into the cloud aspect because we have so many people that just have separate identities in the cloud than they do on prem. How do we assure, and you touched upon it, this compliance problem? How do we deal with that?
Diana: This is really truthfully one of the more complex places organizations are wrestling with right now. I have so many accounts out there that somebody has their own login to. And I want to ensure that they lose that access when they leave the org, for example, or that they have the right access in it.
This is really the heart of identity governance. I want to know that from the authoritative source, which says that Diana is an employee. Once I leave and become the Grand Poobah of something else, I need to know that in the authoritative source, it says she no longer works here and there needs to be automation that ties that to my other accounts. I need to have a central place where I know what all of those accounts are. Or even if it's federation as my identity provider, I need to have that link between the two. So, that Diana leaves, the identity provider says we're not going to provide her identity anymore and turns off. Or any accounts that are actively provisioned because some systems don't deal with federation as well. That those also look at disabled at that time.
Jim: So, you're bringing up the concept of two things. Number one, leaving an organization. And what happens to those accounts when you leave an organization, that's one problem. And two, when you move within roles in an organization. So, today you are running identity in your world, and all of a sudden now you move into a different group within Netflix. How do we deal with those two different things? Because they are two different things.
Diana: They are. Making sure that somebody's access is current. That I, when I ascend to the CIO role, at some point there.
When I moved locations, making sure that that change this recognized in HR, a title change, is mapped to some sort of access change automatically is, again, part of that putting in place the policies and procedures. You have to know what title or role, because we'll call them roles effectively, should have what access and how I automatically put somebody in that role or remove them from that role.
Now, moving from sales to somewhere in development. I certainly don't need to see sales numbers anymore, do I? So, I should be removed from that role. But there's always this overlap for a while. Has anybody worked for an org that has enough people to do everything it needs? Does that even exist?
Jim: I don't think it does. So, you're going to continue to do your old role for the next three months till we backfill and train that person. So, that has to be a consideration.
Diana: Yeah, that's why automation of moving roles within an org. Gaining new access is easy but losing access to the new organization is something that we all have to be a little careful of because people end up doing the same work for a while. This is unfortunately what leads to people having "excess access". Can you say that five times fast access, access, access within an organization, because as somebody moves to new role, they're still doing old duties for a while and then even once they've stopped, you just want to be careful about removing that access. So, sometimes you see people who've been in an organization for a while and moved around, who can do everything under the sun practically within that org.
Jim: Yeah. And my favorite though is, is when you move on to another spot, and oh, Jim is going to come over and take over for Diana. Let's just give Jim Diana's rights because Jim of course, hasn't been in the job for 10 years and you have now all of a sudden, I get these crazy grandfathered, rights.
Diana: So, yeah. Make Jim like Diana is a little bit of a risk.
Jim: Oh no, I don't want to be like Diana. I love you, but not gonna happen!
Diana: You wish.
[00:20:59] Automating succession management
Jim: So, we've kind of talked about, we understand that as somebody moves roles, we need to make sure that we revoke for things they don't need any more in the new role, but there may be a temporary where we leave some rights there and give them new rights. But what about when Diana leaves and all of a sudden there was stuff that Diana was doing then now, what do we do with that stuff?
Diana: So, that's a slightly different ball of wax. Me moving around within the org, you can do that sort of periodic review and say, does she still need this access? No, let's prune it and she's moved on. But once I've left the org, how many times have you heard of an entire application that stops working? Because the person who owned it left the org and it either wasn't paid for, if it's a SaaS application, or the rights to it. Their account got disabled by somebody manually and then the entire app just fell apart. So, when you were looking at putting in place identity governance, one of the things to be certain of is this succession management. A certain automation of, if somebody is leaving the org, you have to know what rights, what access, what responsibilities are tied to them, and automatically move that to either their manager or a designated one, or send out a request of who is going to be the inheritor for this.
Most often, it just rolls up to somebody's manager. Joe worked for us, joe has moved on, Joe's manager immediately gets everything. But it could also be that you do a review and just reassign all of that. But in order to do that, you have to come back to that foundational thing of knowing what access somebody has, what responsibilities they have, and having policy to automate a response to that.
The classic one is when a manager leaves and he's supposed to be approving people's requests, but because he left, there was no automation to make a managers' manager the responsible party. So, people are making requests that go off into the bitbucket.
Jim: And in the cloud, this even becomes more of an issue because we have additional rights, additional privileges, and probably a little more movement than we do in the on-prem space because of the dynamic nature of the cloud.
Diana: Sure. With so many things like serverless, I'm going to pick on serverless functions because when you want to talk about powerful tools. I want to use this serverless function to clear out my test data every night or something like that. When you start looking at the access that's often granted to them, it's usually high, very powerful access, like administrative access or to do very powerful tasks.
Jim: What we refer to as privilege access.
Diana: Yes. There's the buzzword for it.
Jim: You know what, since we're on that, well, maybe you can address the concept of PAM, privileged access management. You touched upon it. Maybe you can kind of dive into it a little bit.
Diana: Well sure, cause you're kind of getting into that when I talk about serverless functions, or people who have excess access. When you have these privileged accounts, things that could create significant damage to your organization, for example, or have a lot of power. Letting somebody just log into root dir SA or the admin account, is highly risky for your org because it enables an individual to have a lot of power all the time. We call it standing privileges. The ideal would be to have a zero standing privileges model. I don't want this account to necessarily have access to do everything under the sun. I want there to be a point at which if I need to do an administrative task, I can request it, get an account elevation, or check out an account that normally can do that, get the password temporarily, and do this through a process that is audited. That request involves the policy of these people can do this, but we want to keep an eye on it. Timebox it, they're only allowed to do it for one request for example. There's a whole number of aspects that go into privileged access management to ensure that you are reducing the blast radius. If somebody gets access for reducing the risk to your organization by making sure those accounts that have the most power are the most secured, are the most watched when somebody needs to do something with them.
Jim: One of the things that I love is there's a statistic out there that says that when a cloud account is compromised, that crypto mining is deployed into that cloud instance in under 30 seconds.
And so when I look at that statistic and it goes along with what you just said, if I have an account that has the ability to spin up an instance, whether we're talking serverless, your target, or we're talking even an S3 bucket, a storage facility to dump data that I'm going to have pay for. That's where identity governance in the cloud becomes so critical. No one, even if it was compromised, being able to answer the question, what can they do with that privilege?
Diana: Sure. A lot of times people think, oh, they're just after my data. And that while that is true, and there are people who are seeking that data. A lot of times they're seeking your resources. And you can abruptly find that your bills have gone through the roof, and somebody has spun up instances. This is one of the lovely things about AWS or GCP is I can spin up a thousand instances very quickly. And by the time that somebody notices it's happened, if you're not plugged into an appropriate event, service and putting in place that governance and visibility of it, they've already been in, done what they wanted to do and left. They've kept your password so later they can come in into it again when they need to mind you. But there's a certain reality to the fact that there are extraordinarily skilled people out there who it used to be just wanted your money or your data, now want your resources.
Jim: Especially with the unlimited power of the cloud. That's really good. I want to, before we end this, I want to talk about some low hanging fruit. And one that I'm going to throw out there is a study that was released by one of the leading cloud vendors that said that less than 20% of the privileged accounts have multifactor auth enabled. Yeah, I know it's just mind blowing.
So, for the low hanging fruit for my listeners, right now, please go turn on multifactor, it comes with your service.
Jim: With another one, where do you think from a low hanging fruit, where should people start?
Diana: I would say that first automation of saying, I want to be able to onboard an offboard. It's such a simple thing. I want to be able to take an automated onboarding from when somebody is hired in HR to a few key applications. Particularly the ones that almost everyone uses. That is an easy thing to implement it, removes latency, it makes things more efficient. That's one side you can focus on if you are a very employee driven and that's an efficiency thing.
The other one. It would say, if you are somebody who is on multi-cloud. And isn't everybody? I mean, I don't even, even my own organization.
Jim: Yeah. It's a multi-cloud, hybrid cloud. Yeah. You hear that a lot. I think, although the majority, we're on prem and we're delving into one of the clouds typically, but that hybrid cloud is the majority of the world today.
Diana: I would say one of the key things to do, regardless of which cloud vendor you're going with or all cloud vendors at any point, is to, uh, each of them have individual capabilities to get visibility to what you have there, but there are a number of vendors out there that can give you that true visibility into what's going on in your cloud and across clouds in that sort of hybrid platform, including on prem. I'm not speaking for any particular vendor in this space, but I am saying that having a tool that can give you that visibility that can query and understand what is in your ecosystem. Is it bigger than a breadbox? Is it bigger than a semi? How big is it? This is the sort of thing that we often see people the first time that they start trying to do an exhaustive analysis of their environment and running an automated tool to say what's out there, pause and go holy crud, I had no idea. Low hanging fruit is automation of employees, but as you were moving to the cloud, one of the key things is gaining that visibility, pick some tool and start getting that visibility early on.
Jim: Alright. So, one last thing I want to throw at you. For nerds like us that love identity. And I don't mean that in a bad way. Is there a document, one document overall that would really dive into everything we've been talking about?
Diana: Okay. So, there's a couple of things actually, you can look at. Probably one of the biggest ones, the NIST standards, National Institute of Standards and Technology, 800-63, talks about digital identity. Talks about the things that are necessary for that.
Now, let's be fair, there's a lot of tedious language in it. This may, this must, I don't know many people who enjoy reading that, but if you start there, that is, well, most people don't enjoy reading it Jim!
Jim: I'm not most people, we know that
Diana: Oh boy, do we! Also looking at like the Identity Defined Security Alliance, they've done a lot of much more human readable views into how I can use identity to have an appropriate security infrastructure for my organization.
Or (ISC 2) has a certification as a Certified Cloud Security Provider that focuses upon a lot of other aspects but a portion of it really is about identity, and they have a lot of materials on that. So, those are a few places that people can look to find more information, detailed information. Of course, there's number of vendors in this space who all talk about their tool as the greatest tool but any of that information is useful, but I would go for something more agnostic like one of those mentioned if you're trying to get your arms around, what am I going to do with this? How do I get better about this?
Jim: Well, I want to thank you for your time. And if anybody has any questions for me, feel free to reach out to me on LinkedIn as well as to Diana on LinkedIn. If you have any other questions around identity or cloud identity, we'd both be glad to answer your questions and interact with you.
So, with that, I want to say thank you for being my first guest on taking over the podcast. And I look forward to speaking with you more afterwards.
Diana: Very much a pleasure Jim. Thank you so much for your time and good luck to everybody out there. This is an exciting and transformative space at the moment. So, best wishes!
Jim: Thanks everybody.