Securing the Future of RPA with Alan Radford

Welcome to the Test Guild Security Podcast where we all get together to learn more about security testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Security Podcast. Today we'll be talking with Alan Radford, all about securing the future of rpa. Alan is the Regional CTO at One Identity. He's a thought leader, strategist and subject matter expert for Privileged access management, assisting customers in realizing value from IAM maturity and investment. Alan also ensures that One Identity Products and Solutions strategy matches the needs of their global customers. So listen up and discover what RPA has to do with security. You don't want to miss this episode. Check it out.

It's no secret that the number and complexity of applications are growing, but what is alarming is that 90% of security incidents result from exploits against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify, you can start security applications in a single day, including custom code, open source or commercial components and scale as your needs grow with an on premise as a service or hybrid implementation. Check them out. Head on over to micro focus.com app security.

Hey Alan, welcome to the Guild.

Pleasure to be here. Thanks for having me.

Great to have you. Before we get into Alan, is anything I missed in your bio that you want the Guild to know more about now?

I think you covered it.

Very cool. So I guess before we jump in, just some high level things that I mentioned in the pre show. I am a newbie to security. I assume that a lot of listeners may be as well. So what is identity and access management?

Yeah, great question. That's a big topic. Been around for a long time. Identity access management has many facets to it. You think about an identity, think about a person, and you think about all the stuff a person does. A person has things, a person has a car, a person has a phone, person has a name, person has an email address. They have various attributes of things that are attached to their identity. Those things are not necessarily what makes that person them, but it's things that create an entity which is an identity. When we talk about access, it's how that identity then accesses things. In a real layman's principle, it could be how I access my car by getting into my car, unlocking the car, or it could be when I log into a laptop or a computer, actually using a username, password or a thumbprint or some other form of authentication to access things I'm authorized to access. Identity and access management is a challenge that individuals have. I myself, I've got no idea how many accounts I've got online. Amazon, Twitter, LinkedIn, God knows what else. Like they're everywhere. And then of course, when you take that concept from an individual and you go into a business, the business inherits a responsibility for that identity. So Alan works at One Identity. One Identity has a responsibility to go. How does Alan get his Active Directory account to log into his laptop? How does he get his email address? If Alan's role changes to a different role in business, which accounts are destroyed, which accounts created, which accounts change? In the most basic terms, that's identity and access management in a nutshell.

Now, so I assume, like back in the day, everything was on prem, and so now everything's moving to cloud. Does this add extra complications around security, around iam?

Oh, yeah. Well, not just in identity and access management, but in security in general and in society. When you think about physical machine, there's boundary there. If I create an account on that machine, that account exists on that machine. That's it. Linux, Unix, hi fi, that's how that works. But then when you virtualize it, suddenly that machine can be copied and pasted and recreated many, many times. And that technology's evolved to a point where we have containers where rather than having one machine spin up to do something specific or go and actually buy a server, physically plug it in, switch on, do some work to make it do something, we now click our fingers and thousands of VMs or tens of thousands of containers spin up in the blink of an eye in a cloud environment. Each of them have ways of authenticating, each of them have ways of using accounts, each of them have identities touching them. The virtualization is a removal of physical boundaries, and those boundaries dissolve even further when you look at the cloud. Because now I no longer just have an account on physical box or even on a virtual box. I've got accounts that exist all over the world in lots of different data centers that I don't even know where they are. So it is very much a removal of boundaries. And we're seeing society in general really starting to take notice of identity access management in particular governments, because these boundaries that were so traditionally physical just don't exist anymore.

So when you say government, I know there's a lot of compliance. Is it from a compliance perspective, especially in Europe, where GDPR and things like that with identity.

I think partly it's to do with compliance. I think it's also to do with struggling to keep up with technology. Technology is advancing at such a rate that I think society is actually struggling to keep up. Businesses have been struggling to keep up for many years now in the form of how they manage identities and how they govern them. But when you take that context out of a business and into the broader wider world, when you look at, say, the boundaries of country, for example, that's where things like GDPR come into their own. It's a recognition of, hey, look everyone, this is kind of new. We need to do something about this. Technology's being out of control. Do we know where anyone's data is being held? Do people have the right to be forgotten? If people. And it's a fundamental recognition that knowledge is power. Information can be used to do some very positive things, to do some very negative things. So a person's information about themselves is very, very important. And when there's no barriers to that information, that's a big problem. And that's where we see compliance frameworks and governments and businesses and even individuals all over the world struggling to keep up and working out how to manage this.

So what type of things are they managing? Are they struggling with then that are common that you see with your clients that they call you for, because they're struggling with something that they need help with?

So where we help is around, I would describe as three key areas. One of them is very active directory focus without being too technical. A lot of organizations, most of them by far, I'm aware of only 2 globally that don't use activity. That is an exercise in centralizing and simplifying. If I've got thousands of people working for me, even if I've got like 10 people working for me at once, if I've got a number of people working for me, it's easier for me to give them as few accounts as possible. That's where Active Directory helps. I can create an account, Active Directory, that one account allows them access to everything I need them to access. They don't need any more accounts, which means I'm only managing that one. So that's an exercise of simplification. We come along and we help with processes around how is the account created, how is it destroyed, how does the account change as the user evolves in the organization, and how does that account actually grant access and how is it secure? That's really an Active Directory pillar for us. And then there are two very Strong, more enterprise columns next to that one. Around identity governance, which is around how my roles are created and destroyed in organizations where it's not just about active directory, it's about, in some cases, literally hundreds of thousands of applications. Bear in mind that people are going to climb cloud now, right? So it's not just about what's on premise, it's about what's off premise. The world is literally the oyster. So when you look at an individual and organization, look at what they can access, it's really phenomenal. And so creating roles, managing roles, making sure that when accounts are created, they're not just what we call orphan. Where an account gets created, the person using the account needs the organization, the account gets forgotten about was still active, somebody found out what the password was for that account, they could still use it. I've spoken to a company in the past who had an account for an employee that had left seven years prior to the conversation and had discovered that the account was actually still being used. And it was news to them. So these things are very fundamentally important from a security perspective. And on the government side, it's around also testing regularly putting the business in control. Does this need to exist? Is it being used? How is it being used? Is it still relevant? Are we doing things correctly? That governance layer is very, very important to the lower level management.

One of my favorite examples of the difference between management and governance is when you think about a manager in a business. Typically a manager is there to measure metrics and work to make those metrics better than KPIs. And in the world of identity access management, the metrics we care about are who, what the where and when. When we govern that, we start answering the questions of how and why. And that's how we put the business in control. As a side note on the privileged access management pillar, I realize this is quite a long answer. The privileged access management pillar turns that on its head. So say for example, you've got a user who is performing a role in your organization, they are in and you've got another person in your organization and they're in accounts receivable. So those two people are doing separate jobs and separate roles as part of processes that facilitate each other, printing and signing checks. Now if one person was able to do both those jobs, they'd be able to take a lot of money out of something. And so it's a fundamental, what we call separation of duty. That's fine. But the systems they're using are running on a physical piece of hardware, on a virtual machine. In the cloud, who knows? Who knows where that data even is? That's often a question we're asked to answer. But the administrator of wherever that data is held also has access to that data because they're an administrator. So privileged access management is about taking the principles of access management for a user and adjusting them in a way that makes sense for a technically proficient individual to not compromise those rules and to be properly audited when they have back end access to these sensors. Those are three areas where we add value to our customers.

Great. So there's a lot there. I'm also thinking I could be wrong with things like COVID 19 and people working remotely. Does this put extra pressure on areas like access management for admins and companies?

Absolutely. It's a very interesting topic because on the one hand, the sharp adoption of cloud has made a number of organizations to shrug and suddenly realize that because they've gone into the cloud, it doesn't actually matter where the employee is anyway. So there's that side of it and then there's the other side of it, where companies who still rely on on premise systems are trying to work out how to get access to those on premise systems, particularly for privileged users of iPad, where traditionally, you know, it's very easy to think of a privileged user as somebody who would be like wearing a T shirt with a penguin on it, maybe a hotel, and they would go into the server room and they would do something in the server room that's not so easy anymore when we can't go into the office. So there's lots of conversations taking place around, okay, I've got these users who can still do what they need to do, that's fine. But what do I do about these other guys? What do I do about privileged users? What do I do about people accessing systems that I still have gated in my own center? Because now I've got an increased level of responsibility to facilitate that access, but also keep it secure, ultimately be able to answer all the questions of who, what, where, when, how, why. And so it is a big challenge. And one of the things that makes me chuckle to myself and you know, we touched on it just now about the idea of boundaries coming down between physical and virtual. We're seeing the same thing happen with people. People are becoming virtualized. And COVID 19 fundamentally, the users being virus, we think about the server and we think about the user. They've now got more in common than they've ever had before. They both get viruses and it affects how they both operate. At a Business level. They can both be virtual, refer you to product process automation. So you can have a virtual user as well now and they will live the cloud. So I think it's funny how over time we've now got more in common with technology than we've ever had before.

Absolutely. And talking like about technology and all the. I think you set up the stage really well on the areas that people need to focus in on is rpa. So before we dive into RPA as well, folks that don't know how would you explain what RPA is?

So I would describe RPA as an exercise in automation. So you've got, you've got different. And there's a gradient to it. Okay, so I'm going to run a disclaimer on this that I'm not from an RPA vendor, I'm from an identity access management vendor. So this is very much the identity access management view of it. And I know that the RPA vendors, and there's some great ones out there, they have their view on as well because they're looking at it from automation and a business facilitation perspective, whereas we're looking at it from a security and business facilitation perspective. So that's the overlap. I would describe RPA as. Say you've got basically two different modes of rpa. You've got a robot and you've got a digital worker. And I see them as two different things. A robot is very simple algorithm that doesn't necessarily learn and it would simply be there to do something like it might be as simple as a macro. I'll take the hit, I'll put my hand up and be the guy that says elements of RPA have stuff in common with macros. I think that's fair because if you create a macro in office and you save that macro and then you run that on a schedule, there are robots out there that basically do that. So it's a basic process and then you put it in part of the workflow and it becomes a slightly more intelligent process. And then you make that workflow branch out and you build on that workflow. So it becomes a much more intelligent and structured way of doing automation. And that's where robots have value. Digital workers, I think are a lot cooler. And a digital worker is much more autonomous and much more learning. A digital worker might be, might have more and more to do with a role. So when we talked about account payable and account receivable, maybe my accounts payable isn't an individual, maybe it's digital work. And so it would process documents. And as it processes a document, maybe there would be a user oversight as that additional worker learns. And if it makes mistakes, learns from those mistakes, it is taught over time. And so it increases in value over time. And the value that both of those bring is that because they're increasingly connected to each other and they can process vast amounts of data incredibly, incredibly quickly and make autonomous decisions based on rules that they're given. When you put a digital worker in a place of learning, very quickly comes turn these conversations, robots taking over, etc. And so on. And there's loads of weird and wonderful presentations out there about the topic. I think it's very, very interesting that there is huge traction in the market for RPA over the last several years. Something which in principle is quite simple. Is something exploding.

Absolutely. And I've heard it more and more as a buzzword, but the past few years it's mostly been in automation of, like you said, like business processes, not necessarily security. This is actually the first time I heard of RPA with security. So what is some, I don't know, security, AAM specific cases that you would use RPA for.

So I'll give you two, I'll give you a basic one, I'm going to give you a slightly more advanced one. So a basic one. So we've got several customers that use our technology for this particular case where say you stand up a number of robots or digital workers and they're doing their thing, they can do things very, very quickly and they use accounts to do these things. So that robot now has an identity because we've given it something, we've given it something from the business to do something with and what we do in it carries some risk. With a basic Active Directory account, I can read everything from Active Directory. So there's no such thing as an account. In an organization that doesn't carry risk. There's very, very low risk accounts. There's no such thing as a zero risk account. Add to that the fact that if you know what the username is, then you've got 50% of the credential, half the works done for you. Point is that the robots are using accounts that we give them to use. What we do is we provide technology to protect those accounts from being exposed so that only the robot knows what those accounts are. And every time the robot uses the account, the password. This prevents privileged users or the people who teach the robots, the people who own the robots, people who control the robots, people who tell the robots what to do in the first place prevents them from knowing what the credential is. And it creates that layer of security around it and allows an organization, when the auditors come along to say, how many people know this account to this system turn around, say zero and is proof. So this powerful sync to be automated. So it gives a lot of freedom and removes a lot of risk from an automation exercise. That's the basic one, slightly more advanced one, sticking with the idea of somebody owning the robot. Well, let's say I've got additional worker and let's say it's accounts receivable. I say another digital worker. That one's for account available. Great. I've just created and configured two robots, or digital workers, I should say. Apologies to the RPA vendor listeners out there mincing my terminology, but if I've got two digital workers doing those two different roles that could never ever meet because of the massive risk of representing the business, that's a problem because I'm still the puppeteer. I have control by proxy, accounts payable and accounts receivable. So although I've managed to significantly accelerate and automate and create agility from my account table accounts receivable processes, I've created a massive risk in doing so because now Alan has control of the robots doing both those processes. And I would put to any listener out there, would that be a problem for you? I would expect the answer to be yes. So you've therefore got an identity problem.

Great. So it sounds like, I think when people hear rpa, they think when using it for security, they also think of security risk and controls for the rpa. It sounds like those are the services you provide is pretty much Password protection seems to be one of the main ones when someone is utilizing RPA with their IAM solutions.

Yes, I would say password protection is usually the starting point. And I say that because robots are using accounts, digital workers are using accounts. There's a fundamental baseline there. But we've also had some very interesting conversations with customers about how they want to actually take that further. Some of the basic principles that apply to identity access management still present when it comes to managing the robot itself. How is the robot created? How is the robot destroyed? In addition to how the accounts themselves are created and destroyed? I find it quite interesting because if I want a workforce of 10,000 people, I've got to go and employ them. I've got to interview them, I've got them on a payroll. However, if I've got 10,000 robots, I don't need to pay them immediately. That's far more appealing to any business. But unlike a human employee, they can be created and destroyed immediately. They can process information immediately. They can learn very, very, very, very, very, very quickly. So when you put all of that stuff together, you've basically got a virtual identity that needs to be managed because of the speed at which it can operate. I'll give you an example. If I say that, let's say I create a robot in an organization to go and do something, maybe I'm a privileged user. And as a privileged user, if I log into a workstation, I might have. Oh, sorry, if I log into a workstation, then log into a sensitive server or database. Maybe the business is already very mature in prototypes. Maybe they've already got what we call a session proxy that will sit between me and the target system so that everything I do is being video recorded, everything I do is being keystroke logged, maybe even my mouse gestures are being tracked and so on. And a behavioral profile gets built about me so that if I stand up and walk away from my keyboard and Andrea sits down and starts working my keyboard, but it can tell the difference and lock Andrea out. You consider that baseline graph of behavioral profile of an individual one is very, very different. My type of patterns are different to yours. My mouse gestures are different to yours. But if I got 10,000 robots, all of theirs would be the same, wouldn't they? It's something that's causing a lot of interest in the business community, especially when you turn it on its head and you start using those robots for security use cases. Say, for example, you actually want the robots to facilitate the creation and destruction of accounts because of a particular process in a particular legacy system. The robot itself is performing those types of use cases. That has to be governed. How could you not? Because you'd never know what you'd never be able to prove what it is isn't doing unless you do that. So I do see a correlation between the uptake of realization, recognition and interest in the wider global community of, yeah, technology, data, security, boundaries. That's a big problem. It's getting bigger. And I do see a correlation between that and automation. Because in our struggle to be more agile and run faster, we're at greater risk of tripping. We're inheriting more risk of doing so.

Also, I would think I've been doing automation for 20 years, functional automation, and it's very hard to make them reliable. So in your experience with your customers, do you have any real case studies where people are actually really using rpa? Because this all sounds awesome. But like, in the real world, have you seen any success stories with RPA being utilized especially for security?

Yeah, absolutely. Well, I mean, my first answer to that point would be it's a very, very profitable, high growth rate business. So the interest is there already. But in terms of a case study, I would pick one of our customers who they adopted an RPA solution because they wanted to retask some of their workforce. So they recognized that they had a high run rate of tasks that could be automated, that didn't require a user to do them if they automated them. And the objective was not necessarily to automate those processes, but it was to free up the people who were doing it so that they could be retasked elsewhere. So that's what they did. When they did that, they realized that the process that the people were following to obtain credentials and do what they're doing was not a gap that was closed by adopting an RPA solution. So that's where we added value. And as a result of that customer putting those two technologies together, they were able to free up those individuals and, and they actually set up a new business unit off the back of it.

There's also a lot of RPA solutions out there. How does your solution work? Does it have to work with only certain vendors? Does it work with any type of rpa, type of vendor? Or what are the most common RPA vendors that you actually work with?

Yes. So in answer to your question, we are currently working with all three of the Gartner leaders in rpa, including Blue Prism.

Awesome. So Alan, what do you see as the feature, as more and more people go to RPA and they're using it for identity and virtual users? What do you see? Do you actually see this as a growing area that's going to get even more complex or an area that people need to be focusing on now before it gets really takes off?

Oh yeah, 100%. 100%. I think it's early days when we consider the rate of change in technology and then we consider all these different, weird, wonderful ways for us to accelerate what we're doing in business. The rate of change is inevitable. And I think when we look at concepts like virtual identities and we look at concepts like identity access, management and automation, for me, it always comes down to that balancing of that act of agility versus risk. One is more profitable but higher risk, and the other is less profitable but less risk. And that balancing act is always going to be a struggle for any organization. But that balancing act, the way I see it Today has two very firm contenders on that seesaw. On one of them it's the RPA vendors and on the other it's the identity access management vendors. And I think that's really where the sweet spot is when it comes to automation. I'm oversimplifying that dramatically, but to the point of RPA and identity access management, that's really where I believe it is in terms of where it's going. I think the removal of boundaries, the proliferation of looking currently RPA from customers I spoke to and bear in mind, I don't work in RPA vendor, I work for customers I've spoken to in that context. Look very inwardly, they're looking very much at their own systems and what they're doing. And in the world of identity access management, that's just a very small piece of the puzzle because I myself, I mentioned earlier, I've got an identity access management problem. I've got no idea how many accounts I have in the real world. Literally none. Well, I started counting once upon a time. I got to 63 when I stopped counting. That was years ago. I've created many, many since then. And when we look at how we automate things in our own personal lives, we've got Alexa, we've got Google Assistants, Siri, and that's something that's part of our normal lives. So when we look into the business and we look at the future of automation and security, I can't tell you what the future product and future state will look like because if I could, I couldn't start my own company, I go and sell it. But I do think that this is early stages and I think we're in for one hell of a ride.

Absolutely. Because it is in the early stages and you have a lot of clients and customers when they come to you, do you have to give them best practices around how they're creating the RPA or does it matter to you for your solution?

No, we're very API driven, so we rely on open standards. So when it comes to integrating, and this is something that I don't think is recognized well enough in the industry, not just in identity, but more generally, if I'm honest, by using open standards we provide a lot of flexibility, which means any RPA vendor could plug into our technology. But to make the point a bit firmer, there's a customer I spoke to recently who weren't actually purchasing an RPA solution. They decided to build their own. So they're building their own in house, RPA automation, and I asked them how they're managing the credentials of those robots. And they just said, well, we're hard coding them. Why wouldn't we? And I did very well, I think, to keep a straight face. And I said to them, well, you guys know what the credential is? Is that going to be a problem when you're audited? They said, we don't know as well. If you didn't have the credential in there and it was managed automatically, how would that help you? And they said, well, we wouldn't have to manually go and update that credential every so often to meet our internal compliance guidelines. And it means that we would be able to automatically very easily prove to the business that we've got compliant processes in place and show the results. How like. But the point I'm making is that they were just very casually, I might add, just building their own RPM and didn't really see any issue because they only had one objective. Their objective was to automate a particular process. And because their eye was on that all, they didn't really have any need to care. They weren't tasked to care about the security aspects of that. So there are some interesting traction taking place.

Okay, Alan, before we go, is there one piece of actual advice you can give to someone to help them with their security RPA efforts and what's the best way to find or contact you or learn more about One Identity?

Yeah, so the most easiest answer to that is one identity. Com. That's our website. You can find me on LinkedIn. Alan Radford, One Identity. So myself and my company, very easy. About to talk. I would summarize that we're the side of the seesaw that represents security. And wherever you look in the world, whether it's within your business, whether it's with your home life, or even if you literally look out the window, security is important. It's something that adds value to really every digital you do. So when we look at it in that context and we start to try and automate things, anybody, anywhere who's doing anything with robotic process automation has security questions to answer and has identity access management questions to answer. Who owns the robot? What is the robot going to do? Where is the robot going to sit? Is it going to be in the cloud? When is the robot going to run its schedules? Do you know? How would you prove it? How would you verify the robot's done what it's supposed to do and not deviated from its this task? How are they created? How are they destroyed? How are they using the accounts and most importantly, why are you doing it? Because today you might want to use robots for task A. But are those robots still going to be there when task A is completed? Or is task A ongoing? And if task A is completed and robots are still there, do you have a security problem? Potentially do so anybody looking at RPA needs to consider security assets would be my message.

Thank you Alan for your security testing awesomeness. For links to everything of value we covered in this episode, head on over to test guild.coms29. And while you're there, make sure to click on the Try Today link under the Exclusive Sponsor section to learn all about Micro Focus Fortify, which is the recognized market leader in application security. And if you haven't heard already, SecureGuild 2020 is coming October 19th to the 20th to check that out. Definitely get a ticket. Help your team learn more about security and a security mindset that you need in order to succeed in the coming years as digital transformation accelerates even more. And learn how it impacts security and the tools and techniques you're going to need to know in order to keep up with that. So just make sure to head on over to GuildConferences.com and click on the Register now link under the Upcoming Events section to learn more about Secure Guild 2020. So that's it for this episode of the Test Guild Security Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack security testing awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Security Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.