Anna Delaney: Hi, I'm Anna Delaney with ISMG. Welcome to part two of a three-part video series, which focuses on identities as assets, and how to create an identity strategy within the broader context of zero trust. And joining me to share insight on how to do so are CyberEdBoard members - Andrew Abel, cybersecurity and zero trust consultant based in Australia, and Chase Cunningham, CSO at Ericom Software. Good to see you both again. We'll be expanding on defining and securing human and non-human identities within the zero trust model. But first, how or where is identity often misunderstood when implementing a zero trust strategy?
Andrew Abel: I think that identity is often misunderstood in terms of the importance and the risk that they carry. I think a lot of organizations just create identity after identity that they never clean up. A good example in that traditional senses is service accounts for applications that get created in an Active Directory, and then they just stay there forever because the applications long gone, the people who sponsored getting it onboarded are long gone, but the service account remains and they're often badly configured and open to abuse and carry a risk that shouldn't be there.
Chase Cunningham: The market has been driving hard at telling people to start with identity as almost like a biblical reference. I don't necessarily disagree with that, because identity is super important. But the point is, we say that humans are a key piece in this whole place. We use identities. I guess you'd call it kind of the gear that the mechanism of cyber revolves around, it's going to be identity. So you should have a plan in place to take care of that critical piece of this machinery.
Delaney: Andrew, in our last video, we explored what we defined human and non-human identities, but I was wondering if you could dig a bit deeper as to maybe share examples of what you exactly mean?
Abel: I've got a couple of images that might help people understand where we're going with it. Basically, when I think about identities, I've sort of come up with six human types of identities and five non-human types. It just goes to show that when you are trying to define identities and look at them in the context of assigning controls, putting roll boundaries and wrappers around them, and segmentation, there is quite a fair bit to consider. When we look at the different types of identities, I'll just move ahead to give people an idea of what I'm thinking in the human space. You've got your general user accounts. You've got shared accounts, which you may have to use in certain organizations on shift or rotation; they have a limited number of accounts that are shared for various reasons. Then there's information - information people might have access to, information resources in an organization such as financial data of customers or various other highly valuable or sensitive information. Then we've got the local admin accounts; they might be server admins, or someone who's in the support team, or the service desk, who can log on locally to a bunch of domain controllers or application servers. Then they have local admin privileges. The last two are the high risk ones in my experiences that are around the application administrators. When you buy an enterprise application that comes with built-in high level or privileged access, or administrator access that you assign to people or processes or non-human identities to run processes. They're the ones you need to be worried about, because they can make fundamental changes to the enterprise application. And then the traditional privilege distributed user, which is you talking about your IDs, the domain admin, your scheme admin and your enterprise admin. That's how I've split it up. It gives people an idea, and these are just ideas that I've had. It gives you a flavor of how much service to consider when defining the different types of human identities. You can see this some that are high risk that need a lot more control and thought and boundaries put around them.
Delaney: How about the non-human identities?
Abel: For the non-human identities, there's five. I've come up with some. The function one, which I've sort of basically called IoT, or hardware accounts, where they're just sending telemetry to back to a central source for processing, the orchestrating non-human accounts, which are like bot accounts, which may run and do some data crunching or run up a VM or something and do some work and then shut down the traditional service accounts that we touched on to run applications. The other ones are the assumed, like an AWS or some cloud environment where machine or non-human identity will assume a role to carry out a process, and then release the role again once the process is completed, and then your traditional machine identities as well for all of your servers and workstations around the network.
Delaney: Very useful and very clear. Chase, bearing in mind what Andrew just said, what does the zero trust roadmap look like? And where should organizations start?
Cunningham: I think the thing to start with is the most powerful identities, the most powerful accounts that are inside a systems, anything that is above basic privilege level. Take care of those first - admins, application administrators, the privileged local, even those are valuable to take care of. I did a study on this that validated the point that. Folks weren't even necessarily concerned about whether or not a compromise would happen, that was a given. Everyone was concerned about lateral movement after they got in and where they went. The way you solve that is by getting rid of these excessive privileges. It's okay if there's one administrator that you might have missed an account, and that's got control somewhere else. But what you don't want and what we typically see in large enterprises, hundreds, if not thousands, of those privileged administrator accounts with excess of controls on different systems.
Abel: Chase is spot on there. Part of the idea around the split here is that you can look at, X number of enterprise applications, so each of those are run by a certain application owner or a business group or whatever. Then through understanding that you can work out well, how many high-level admins do we need to operate this platform? What's our process? How do we add and remove people from that privileged group, and again, a lot of the problem with identities is the offboarding. There's never a problem with creating identities with privilege, but it's the offboarding as well. It's a real-time, constant process. That's why even in the IAM space, I prefer the IGA - the identity governance - because creating an identity and assigning it access is fine and great and part of the process, but knowing what that identity is doing, and when it executes privilege, and what risk it carries in real time is where the future of zero trust and identity operation is to me because if you just create an identity, assign them access, and then manage them in terms of moving them in and out of groups or whatever, that's a bit cumbersome and the horses already down the road and around the corner, by the time you've got an issue. It's that governance and that real time alerting and telemetry around privilege execution and identity usage that to me will be the future of where zero trust will hit in the identity space.
Delaney: How does this potentially change the zero trust journeys organizations have begun, Andrew?
Abel: I think a big part of doing zero trust well, and even more broadly than that is limiting your cyber risk, it's understanding your environment. As Chase said before, the identities are where it's at. Your resources are your assets or your crown jewels, at the end of the day, you need to have identities accessing them to do stuff to just drive the business and, and complete our processes and drive growth. By understanding the different buckets, or the different roles, and putting the right level of controls and least privilege around these different identity types, at least gives you a plan and a strategy that you can use for your unique organization as well.
Delaney: Chase, would welcome your perspective too.
Cunningham: I like to deal with numbers and data. I think that the folks that think that you can solve this by one off approach, you can't. It's too big. This is good validation of the fact that you need some solution. I don't care what solution it is. But you need some scalability, you need some leverage of automation or orchestration to be able to do this. These are four single-ended entities. You're talking big, big numbers. I think that folks, when they're talking or when thinking about putting the strategy in place, understand that you're going to have to take a bite of the apple and leverage some capability, whether it's open source or vendor provided, to do this at the right scale. You cannot Take care of identities on a spreadsheet.
Abel: One of the misconceptions with zero trust is you need to go out and buy all these big enterprise things that can do network segmentation, or IAM or some other thing, but that's not the case. What I advise people to do is to understand this stuff first, and then go to market for your IAM platform, and then roll in your device, your endpoint control, your EDR stuff, look at your network segmentation, but ultimately, you've got to pick a solution and a product and a platform that matches how you want to operate within your organization - not trying to morph your organization to fit the limitations or capabilities of any specific platform.
Delaney: This has been thoroughly informative and useful. Thank you very much for your time, and I look forward to the next in the series.
