Paul Simmonds: Why Your Business Needs a Strategic Approach to PAM

Hi, good afternoon. My name's Paul Simmonds. I'm a fellow Analyst at Cub Cole and yes, we're gonna talk this afternoon about why your business needs a strategic approach to Pam.

So I, I really like the title of Philippe's talk earlier, which was, is it a culture, project mindset or platform? Well, I'm gonna argue probably that it's a management imperative. So here's what we're to look at in, in the next sort of 15, 20 minutes, the approach you should take, does it really affect your business, the infrastructure change do you need and why you possibly need an HSM and then have a quick look without, without trying to steal too much of Marcus's thunder later on why Pam and DevSecOps should be considered in all of this.

So without further ado, so here's the start of the argument. So when you look at the approach, you should take to privilege access management, and I'm gonna argue with you this afternoon, that actually we should ber rearranging this and actually rearrange this sentence as the approach management should take to Pam, because my belief very strongly as an ex global chief security officer is Pam is a man, a senior management issue. And the problem with Pam is that it's sort of lost in the weeds in most large businesses.

So, you know, it says, well, that's just identity and access management. Isn't it? Security goes, well, it it's an I am. And therefore it's an operational security issue and management just go what's Pam. And therefore Pam tends to get lost. And people just don't appreciate the scale of actually what Pam looks like in a large organization. So here here's a quick eye test and I don't expect you to read this.

The slides I I'm told are going to be available, but you know, here's an example of some of the privileged access accounts used by humans from, you know, a super user and admin account domain admin, which is, you know, sort of what people refer to as the keys to the it kingdom. If you are a window shop and most people tend to be local admin accounts, SSH, secure socket keys, the emergency accounts, all those backdoor accounts. What happens if our existing method of accessing our systems fail, guess what?

We probably have a back door password sitting in a far safe, hopefully sitting in a far safe somewhere within our business for all our key systems. And finally the, the privileged business user. And here it's people like, you know, SAP, there are audit companies out there who make their living out of auditing the segregation of duties and the privileged user accounts and what people can do if they have the wrong set of privileges within SAP. So it's all those privileged business user accounts.

And I've seen some figures out there that say actually in a large organization, up to 39% of all your staff have some kind of elevated privileges, whether it's on a system they manage or a system they use or something within that system to do a particular privileged role within that system, 39% potentially. And you know, the last large organization I worked for had 88,000 staff globally, 39% of that is a big, big number. And then of course we forget at our about all these accounts. So this is, you know, non-human privilege.

So, you know, it's the application account, and we're gonna talk about obviously DevSecOps in a second, the service accounts, again, sh SSH keys are used by systems heavily and automated processes. And then of course, we've got all those secret API keys and other credentials that are used in automated systems and in apps and in DevSecOps.

So, you know, it is, it is a nightmare. And I said, people forget about all of these at their peril. So why my business can it really affect your business?

Well, the answer absolutely is yes. So, you know, in most organizations manual or ad hoc, Pam, which is what a high percentage of organizations do is really difficult. Multiple administrators, disparate geographical requirements. In the nineties, I worked as an information security manager for Motorola, and we had our check sales operation didn't warrant a full-time it person. So we had an it person, a local guy two days a week, really nice guy, two days a week who came in and did our system administration, obviously with admin access, but guess what?

He went to work for Nokia, the local check office for Nokia for the other two days of the week. And then for someone else on an ad hoc basis on the final day of the week.

So where you have disparate geographical requirements, it is really, really important that actually centrally, you have some idea of what that admin access entitles them to what those people are doing with those admin access and ultimately administrators in whatever form they come in have, you know, as people say the keys to the kingdom, but the key thing here from a risk point of view is to limit as the military, say the blast radius, if something goes wrong and to be fair, most of the times things go wrong through to human error rather than malicious, but you have to limit the blast radius.

But of course there are the guys out there, the bad guys out there who want admin access and they want it for a whole bunch of, of reasons. One is you have the, the insider who's gone bad. The malicious insider, you have the people who, you know, deliberately get jobs inside your organization. We know we have had, you know, when I worked as a global CSO, we had foreign agents working inside our business, trying to steal our proprietary information. What do they want? Ultimately they want to get into certain systems and the way they easily do that is they get admin access.

And then once you're inside an organization, you can jump systems within an organization. Cuz a lot of admin is interconnected, especially in the windows world.

So, you know, is it a management issue? If it isn't a management issue within your business, then it certainly should be. And you know, okay, so this is, this is poor with scare tactics. It's not it's, you know, look at the look at the reality.

You know, here are some examples. This guy called Darius Kruger, who two years in prison after crashing his employer's network, ultimately, you know, he got fed up. He was a disgruntled employee. Christopher grew sabotaged Canadian Pacific railways. Yeah. And basically locked everybody out. Why? No one quite knows. And of course the famous one, everyone will quote at you, which is the Edward Snowden leaks. Yeah.

Again, you know, for whatever reason, for whatever, you know, he felt it was, it was morally right to do what he was doing. So, you know, for whatever reason and that's, you know, none of these people were, you know, external, they were all internal inside your organization. So how do you go about this?

Well, you know, the first thing is don't boil the ocean. The biggest mistake we can make when we are trying to develop a, a Pam access plan is not to boil the ocean.

You know, we had said we within AstraZeneca, when I was global CISO there, we had 137,000 devices connected to our network. And those were, you know, permanent connections to our network. Those weren't the kind of mobile, temporary, personal mobile devices you get today. So don't try to ball the ocean, identify your critical systems, those systems that are gonna be share price affecting. If they get, if they go wrong, define and classify the privileged accounts within those systems and then develop your it policies.

If you don't already have them, probably you do, but you are not implementing them specifically for those systems. As you start discover the privilege account. And then ultimately you are going to want to look at what your critical set of systems are and go out to the market, ultimately, and look at piece of, you know, software or whatever that is gonna help you do this because in a large organization, trust me, you will not do it manually. We'll talk about HSM in a minute, but considering implementing an HSM, if you don't already have one, it's a high security module.

For those of you who don't know the acronym and of course, least privilege is the absolute role here. And then of course, to discover all these people who are either trying to do something bad or are just making horrible mistakes, then actually monitor 'em record or privileged account activity if nothing else. So when they do it wrong, you can replay what they did wrong, smack them on the wrists and retrain them. So Pam's, and HSMs, I said, I'd talk about high security modules.

So when I, when I did some audit a long time ago, now, if I wanted to come in and audit your, your Pam strategy, probably the first question as an auditor I would ask you is where is, and what is the coverage of your high security module? And I suspect 50% of the people you asked that to would go, what's an HSM and an HSM. If nothing else shows you are serious about doing privileged access because your business has this whole bunch of disparate keys, absolutely everywhere.

Your, the industry, the computer industry relies. If nothing else on PKI, public key infrastructure to actually function. It's the little green padlock on your browser. So the storage of all of those keys and your certificate authority behind it is absolutely critical to your entire infrastructure. So if you are not running an HSM and it doesn't cover all your key systems, then I'm gonna immediately argue with you that you just aren't serious about doing Pam. If you're doing PCI DSS. In other words, you take credit cards, then here it's a recommended best practice.

So again, if you get a DS, a PCI DSS audit, and you don't have a, a, an HSM, probably they're gonna write you up for it. And ultimately it's about keeping your keys in one place. Storing a key in software can end up virtually anywhere. The HSM keeps the key keys in this case, make it easier to track and safeguard. Ultimately, if implemented properly, that key does not leave your high security module and you have one module centrally within your organization to actually look after and protect as if it was the crown jewels.

So Pam and HSM as a business strategy, ultimately what should be going into your Pam and your HSM, the administration of your network components bring your own key, especially for cloud. Again, you shouldn't be storing your keys for your cloud services in the cloud service. You are starting it cuz guess who owns it? The provider not you. So if someone wants to put a subpoena against you, they go to your cloud provider and say, we would like your organization's data plea, by the way, don't tell them because we'll send you to prison if you tell them.

So again, you having the master keys means that yeah, they might go and subpoena your data, but ultimately it's protected with a key that you own. Therefore they have to come to you to your legal team and say, we want to legally look at your data and then you know about it. And if necessary your legal time team and your management can go and fight it. Endpoint management, absolutely lots of keys on your endpoints. Software defined, networking, getting very popular at the moment and, and the whole zero trust thing.

And again, software defined networking and zero trust are all about identity and PKI. So really important that those keys go into your HSM. And then of course, a whole new subject IOT, you know, we are going to have hundreds and thousands of IOT devices around us that we are connected to in some shape or form as businesses.

So again, the keys for those IOT devices is really, really important. So I said, I'd say something about DevSecOps. So the best example of, of why this is important. Someone once explained to me, she was female, by the way, is, is explained development, software development in terms of dating for girls. So here's the problem. If you're a girl. Yeah. What you're looking for in a guy assuming you're attracted to guys is that he has a lot of money.

He's rich, he's good looking and handsome and he can keep your interest. He's intelligent. And the compromise that girls face I am told is that actually you could only really ever perm two out of the three. You can never get to the holy grail in the middle software development is exactly the same. Ultimately what you are faced with is a choice. You can either have your software secure, delivered fast or feature rich, but it's always, you can have two outta the three. It is very difficult to get to all three.

And with my ex CISO hat on, I'm gonna argue with you that it's usually security that gets dumped. The business, wants it fast and feature rich and security tends to take a back seat. And of course, how do we do this in this sort of rapid application development world?

Well, again, I'm gonna argue with you that the whole privileged access management really helps. I mean, first of all, you know, we talk about dev sec ops, in other words, embedding security in the middle of this, but actually Pam helps you enormously. First of all, because developers need admin access. There's no getting away from it. They have to have it because they have to develop features. They have to develop them at the system level. They have to do install and test.

And quite often they have to develop lower level system code, which means having the keys to the lower level system and applications themselves need SSH. And of course those pesky API keys. So having a Pam strategy that involves the sec in DevSecOps means that you have a much, much better handle on what is going on with your Def SecOps process and where where's the add value.

So, first of all, if you have a process flow that says, well, yes, you might have privileged access as a developer, but actually you don't have the privilege to push it into the operational environment. Only security can sign that off. It means that actually sec has to be involved from the ground up. And therefore all those architectural security assumptions are considered. It's what people call shift left. It's F find it early, fix it early, get sick involved early yet. It means that sec becomes a gatekeeper and Pam assists them in doing that.

So in conclusion, why Pam should be a management issue. I hope I've convinced you. The first reason is it helps achieve. And more importantly, prove compliance. If you can turn around to your orders and say, we have this Pam strategy and we can prove it, and here are the logs. It helps you enormously. It helps you enforce and prove segregation of duties. This person can do this. They can develop code, but they can't push it into the operational environment. So we end up with this, this wonderful triumph of quality compliance and security on everything we do within inside your organization.

Yeah. In a world where humans are your weakest link. And of course, in the dig in, you know, in everyone's digital business out there privileges are absolutely everywhere. So if implemented properly, ultimately it allows people to do their jobs. It hopefully makes it more frictionless for people to do their jobs, but allows them to do it better and faster.

And, and in my case, you know, my hat on more securely, it limits lateral movement. So when the bad guys get in and, and don't kid yourself, the bad guys will get into your organization, whether they're the disgruntled employee or whether they're the hacker from outside, they will get into your systems.

So again, the Pam strategy says, we are going to have least privileged enforced by operationalizing it. And therefore we limit the lateral movement and limit the blast radius with inside your organization. And of course, remember whatever you implement. It needs to be extensible to all key services. And particularly today, because everyone is doing cloud in some shape or form, that must include cloud. And with that, thank you very much.