Identity management around the Hash Table.

Rick Howard: Hey, everybody. Rick here. If you've been following along with both seasons of this podcast, you know that I've been laying out the case for cyber security first-principle thinking. In other words, instead of continuing to incrementally improve our security posture year after year with the latest shiny objects from the security vendor portfolios, we identify the atomic thing that we are trying to accomplish - not a list of things, but the thing - and then build our infosec program from there.

Rick Howard: I have made the case in this series that the atomic thing for all network defenders is this, reducing the probability of a material impact to our organization due to a cyber event. If that is the case, then the immediate next thing we need is an ability to greatly reduce the attack surface to our organization. Now, there are a lot of tasks you can perform to accomplish that. But you can generally lump them all under a strategy umbrella called zero trust. I have written an essay on the topic and published a podcast about it, too. If you haven't consumed those materials yet, you should probably stop this podcast right here until you do. Go ahead. I'll wait. 

Rick Howard: Back so soon? Fantastic. The reason I put you through that exercise is to understand the through line of this podcast series and why we are talking about identity management now. If you are buying everything I have said about first-principle thinking and zero trust and you know that we want to restrict access to your organization's material data islands to only those employees, contractors and partners who absolutely need them to do their jobs, by extension, the only way to do that is to have some sort of identity management program. You can't do zero trust without identity management. And that is why we are talking about identity management in this show. 

Rick Howard: But much to my surprise, what I learned by bringing several CISO experts to the hash table this week is that many identity management programs are not tied to zero-trust strategies. They are mostly run out of IT organizations trying to support HR policies about onboarding and separation. I didn't see that coming. 

Rick Howard: My name is Rick Howard. You are listening to "CSO Perspectives," my podcast about the ideas, strategies and technologies that senior security executives wrestle with on a daily basis. Today, we are talking to three cybersecurity thought leaders about their identity management experiences in the real world. 

Rick Howard: If you listened to the last podcast on the history of identity management, you will recall that our current state of identity management tools - like active directory, SAML and the OpenID/OAuth pair - became stable to use starting in the early 2000s, but really by 2014. On the other hand, zero trust as an idea started to form in the early 2000s, too, but didn't become substantial until John Kindervag wrote the original white paper in 2010. 

Rick Howard: But even now, 10 years after publication, most network defenders struggle with implementing a robust zero trust program. Now, there are lots of reasons for this. And I highlighted some of them from the zero-trust podcast episode. My point is that network defenders and IT teams started implementing identity management programs long before zero trust became a thing. For network defenders, we were using these systems for telemetry intelligence collection during incident response operations, like who was victim zero in the breach attempt? - or for rudimentary data loss prevention programs, like who is exfiltrating large volumes of PowerPoint slides? But identity management in the early days wasn't part of the security function. We were and are consumers of the intelligence it provides. But we didn't run it. 

Rick Howard: The question I had for our CISO experts at the hash table this week was, is it time for identity management to be a formal part of the security function? All of them said they own the policy but that the actual implementation and day-to-day wrench turning were done by other groups. Rick Doten is the CISO for Carolina Complete Health. He has been on the hash table with me before. And he agreed with my assessment of the work assignment today, but also that he had to evolve to that concept. 

Rick Doten: When I was a consultant here, it was in security function. And I kind of questioned that, you know, because this is a foundational thing of people's identity. Now, the rules by which identity is accessed and, you know, password strength and role - permissions for roles and logging and auditing and monitoring is a security thing. But the - you know, the provisioning and deprovisioning of credentials is - would certainly, I think, be an IT fundamental thing, as well as, you know, issuing a hardware device or, you know, even access - and the access to certain things would be an IT function. 

Rick Doten: Very similar on security operations - right? - where, you know, IT would be responsible for standing up the security sensors - the Palo Altos, you know - and the care and feeding of keeping a patch to manage it. But, you know, the rule set would be defined by security monitoring, and response to it would be, you know, handled by the security team. 

Rick Howard: Suzie Smibert is the CISO of Finning, a Canadian company that is the world's largest Caterpillar dealer - you know, the big tractors, among many other things. This is her first appearance on the hash table, but she's an old friend of mine and wicked smart. And if you want the unvarnished truth, ask Suzie. She manages identity management at Finning in a similar way as Rick Doten. 

Suzie Smibert: I'm in charge of it, though we - every cybersecurity person will tell you they get work done through others and other teams. So while the overall accountability and responsibility for it falls under my portfolio, we do partner and leverage other teams across our technology group to help move the needle forward, help maintain processes, train users and do support. It's managed outside of the SOC, though we do have an individual for the purpose of operating the platform - the blinking light, the logging, the upkeeping of it that resides in our security operation centers. But it's a separate team. 

Rick Howard: Helen Patton is the CISO for Ohio State University and, by the way, the new chairman of the Cybersecurity Canon project, one of my favorite committees to belong to. She had this to say about identity management as part of the security function. 

Helen Patton: So at Ohio State, right from the beginning, actually - so identity has always been part of the security function. And even before I was at Ohio State, when I was at JP Morgan, I also managed the identity management teams there as well. So - well, some of them. So yeah, it's a core piece of the function, and we've been growing it for the last seven years. 

Rick Howard: Before identity management started to become part of the formal security function, what did we use the analytics coming off those systems for? Here's Rick Doten again, the CISO of Carolina Complete Health. 

Rick Doten: Well, certainly, you know, timing, you know, where did it come from? What device does it come from? You know, how long were they? I mean, anything that you're - you know, if you're doing investigation, you know, these things are kind of there. There are other things about - you know, that you might be able to correlate across multiple things, like how many things were they logged into at once? Or did they log into something, you know, within a time frame that you - they couldn't - you know, they logged in in New York, and then five minutes later, they log in from Paris. You know, those kinds of things to help identify, if you're doing some threat hunting and looking at data that way. Some people use it from a behavior monitoring standpoint, where - you know, are users attempting to go to things that they don't have access to? 

Rick Howard: Helen Patton, the OSU CISO, also agrees. 

Helen Patton: There's a whole bunch of things. So, again, especially since I'm in a system where students and everything are all in one identity system, authentication logs tell me a lot. They tell me where, physically, someone is. They tell me what time of day they like to work. They tell me what systems they like to access and for how often and how frequently. There's a whole bunch of user behavior analytics that come out of just Helen logged in, Helen logged out, Helen tried to log in, Helen failed to log in. Those kinds of things paint a really nice digital picture of what people do, typically, which then allows you to make alerts and automation based on the nontypical, which is really useful. There isn't another kind of system for me that gives that same depth of nuance around the context of what people are doing and why. 

Rick Howard: As I said at the top of the show, I think that zero trust is the main reason to have an identity management program. When I asked the CISOs at the hash table this week if zero trust had become important enough to subsume the identity management program for their organizations, all of them said not yet. Here's Suzie again, the Finning CISO. 

Suzie Smibert: At this point, it's more a parallel effort. We're going to - they're going to merge as we grow through the journey over zero trust initiative. But it's not something that is all-encompassing at this time. It's a spectrum of maturity for the organization. There are things you ought to do before you go into your higher level. And they will all contribute to making us in a very solid position for a zero trust across the board, if we want to say that. I don't know that we'll ever get there because there's so many connected device or processes and activities. But today, they are parallel initiative. Depending on the size of your organization - one of our small branch, we might not be able to have the same segregation of duty or zero trust in place as we would in a major head office because one staff might be doing multiple roles. So you have to be having a business context as you go through that. Otherwise, you can create more pain than good. 

Rick Howard: Interestingly, Helen at OSU ran into a political problem with her zero-trust program. Her professors and administrators didn't like the idea that she didn't trust them. (Laughter) I love that. She had to avoid the name zero trust altogether. Instead, she called it context aware authentication and leveraged her identity management program to accomplish some of her zero trust goals. 

Helen Patton: Oh for me, its core. One, I'm biased because I've been in the identity space for so long. But, two, I know the origins of zero trust were really around networking and network segmentation and things like that. In higher ed, networks have never been architected the way they have been in private sector, which means networks are particularly porous. And they're big. And lots of data flow through them. So the way we've managed security just generally pre-zero trust was using identity and access control. 

Helen Patton: So when I started thinking about zero trust here at Ohio State, one, I couldn't use the term zero trust because that made people immediately go, what? You don't trust me? Secondly, I called it context-aware authentication, which was a really big mouthful. And then I'd have to explain what context aware meant. And I had to then explain what authentication meant. But it was zero trust in terms of knowing when to give someone access to something. It wasn't about segmentation when we first started talking about it here. So I've always sort of led with my identity chain in that regard. 

Rick Howard: All identity management systems should have some basic capabilities like federation, extra authentication, privileged access management and the ability to manage your employee's identity throughout its lifecycle. Let's start with federation. Here's Helen again. 

Helen Patton: One of the things I really like about being in higher ed, there's always been a need for researchers from different institutions to be able to collaborate. So we've always had federated identity - well, not always. We've worked early on having federated identity management options. So for example, if I'm visiting my friends at the University of Michigan, I can go up there and log in with my OSU credentials and get access to the things that those credentials allow me to have on the U of M campus. The service providers have agreements between one another to trust each other. Whether or not you're authorized to get into an application still happens at the local level. But the identification of who you are is federated. 

Rick Howard: In a federated model, you get this kind of transitive property of trust. If the University of Michigan trusts Ohio State University and Ohio State University trusts Helen, then the University of Michigan trusts Helen, too. As Helen says, though, U of M trusts Helen's identity. In other words, they believe it is her. But they still authorize her access to U of M's resources locally. She doesn't get carte blanche access just because she is Helen. U of M decides what she gets access to. 

Rick Howard: For extra authentication, what we are talking about is the ability to require additional and, perhaps, higher-order authentication if certain conditions are met. For example, if the CEO is trying to access the mergers and acquisitions database, we might want to require not only her user ID and password that she uses to hit the internal website, but also maybe some form of two-factor authentication, too, because the M&A database is sensitive. And we want to make sure that the CEO is who she really says she is. Here's Rick Doten again, the Carolina Complete Health CISO. 

Rick Doten: So what you're describing is risk - we call it risk-based authentication - meaning, like, if you're coming from a different machine than before or you're accessing something that's especially sensitive or something that you haven't accessed in a while, they may prompt something else. And there are applications, you know, mobile apps that were very popular about, you know, six or seven years ago that would then be able to enhance that by either saying, all right, well, here's a - you know, here's a - you know, put in your fingerprint. Now I want you to speak a phrase. And now I want you to, you know, look in the camera and take your picture - or that kind of thing. 

Rick Doten: It's not something that I don't believe we do in my organization, you know? But it's certainly something that is - you know, there are cases where it certainly is prudent to do, particularly when you're dealing with, you know, somebody - you know, you're doing more sensitive things, either as a customer or a user. 

Rick Howard: For privileged access management, it is analogous to the sudo command from the greybeard, Unix wizard system admins that are listening out there. You don't run in administrator mode all day long while you work on your Unix machine - in my case, back in the day, the old Sun Solaris machines. No. What you did was you ran as a normal user until you needed to change something with administrator privileges. You typed in sudo - spelled S-U-D-O - which meant switch user and do something temporarily. Once you were done, you went back to being just a normal user again. That is what privileged access management is on a much smaller scale. Here's Helen again. 

Helen Patton: Privileged account management is simply the management of accounts that provide someone with elevated access within a system. So typically, for example, a network administrator has privileged levels of access to the network. It's not just that they can log onto the network with their device like any old end user, they can make changes to the configuration of the network - that kind of thing, right? 

Helen Patton: So the accounts that a network administrator would use to do those privileged activities are often different than the accounts they would use as a general, Joe Schmo user to access the network. And you need to make sure that the management of those privileged accounts receives a higher level of oversight to ensure, one, certainly, that they don't get hacked, but, two, things like - that they don't make changes that bring down the whole network system, that their use of those - they're not using those accounts for daily use when they don't really need to, that they're only using those accounts based on an approved change, for example. 

Helen Patton: So there are systems out there that are designed like a password vault - well, they are a password vault - specifically for these privileged accounts. And the thing that's unique about privileged accounts is, often, they're shared by multiple people. So the privileged account systems will also allow for users to use a privileged account without having to know the password and having the password automatically change after every instance of use - super helpful. 

Rick Howard: The last feature that is essential to the identity management system is the ability to manage your identities through the lifecycle of their need from onboarding to lateral job movement, to promotions, to leaving the company. Suzie has a term for this that is just perfect. She calls it entitlement accumulation. 

Suzie Smibert: You have someone that starts, say, front desk. And then they move into a support role and then in accounting, in HR. And they move around. But they retain and accumulate entitlement as they move through your organization with their tenure. And that is especially prevalent with senior leaders, because to develop senior leaders, generally, they get moved around organization. So you have senior leaders with access across a slew of business function just because they've been, you know, developed and grown through the organization. And that's a high risk if that identity was to be compromised. So there is entitlement accumulation where we don't want to see it happen at times if employee move roles. But we do regular certification of entitlement. And then we remove a lot of access every single time we go through those exercise. 

Suzie Smibert: What we've been doing is integrating our ID platform or other tools that manage identity with the system of records for HR. So as a role or anything is change in our HRI systems, there's automated workflow that trigger entitlement review or a change of entitlement in a suite of systems - not the entirety of our organization. But there's a lot of automation to help us not have hands on keyboard because we're a large organization. That could consume an FTE full time. Then it's commoditized work. It's not cool work. It's not glamour. It's boring. So why would we want to hire a security professional to do something tedious like this? So we want to automate it. 

Rick Howard: The last thing to consider, and probably the strongest reason that identity management is not part of the security function in most organizations, is governance and regulation. 

Suzie Smibert: For us, there's a heavy reliance on our identity governance administration for the purpose of meeting of regulatory requirements as a public company. If you had internal audit or external audits identifying potential for improvements with the findings pertaining to identity, our identity governance administration processes and platform help us eliminate all of those recurring findings. We have many regulation we must meet. So if we think of our U.K., we have GDPR. We are public, so we have Sarbanes-Oxley. We have some PCI footprint. We have a lot of regulatory requirements across the globe. And every single regulatory requirement has needs surrounding identity management. 

Rick Howard: And there you have it. Your identity management system, however you do it, should have some way to federate with your partners. Automatically ask your employees for extra authentication when the situation is necessary. Have a means for regular users to switch to privileged user status to do some work and to keep track of everybody that is doing that. And finally, have a way to manage all of your identities across the entire lifecycle of work. If you have all of that, then you will do better meeting your compliance obligations and have telemetry for your incident response teams. 

Rick Howard: But as you are thinking about all of this, consider that if you are ever to get your zero-trust program off the ground, you need to install a robust identity management system or you will never start rolling down the runway at all. Perhaps it is time to move the identity management program under the security function in order to support this major strategy play of your infosec program called zero trust. If zero trust is a first-principle component to your infosec program, like I believe it is, maybe it is best to have security own the identity management responsibility. 

Rick Howard: And that's a wrap. Next week, we will be talking about red team and blue team operations. You don't want to miss that. In the meantime, if you agreed or disagreed with anything I have said in the last two episodes about identity management, hit me up on LinkedIn and we can continue the conversation there. 

Rick Howard: The CyberWire's "CSO Perspectives" is edited by John Petrik and executive produced by Peter Kilpe. Our theme song is by Blue Dot Sessions. And the mix of the episode and the remix of the theme song was done by the insanely talented Elliott Peltzman. And I am Rick Howard. Thanks for listening.