Listen to Identropy's Jim McDonald and Jeff Steadman on their podcast at "Identity at the Center".

PODCAST41
 
Both Jeff and Jim each have over 15 years of experience in the Identity & Access Management space and guide companies on their IAM Program journey through Identropy's Advisory Services arm.
 

In this episode, Jeff and Jim talk with Paul Volosen from Centrify about the IAM concepts used to secure server access.

Brought to you by identropy.com

Want to join the conversation? Leave us a message here: anchor.fm/identity-at-the-center/message or email us at questions@identityatthecenter.com .

We hope you enjoy this episode and please subscribe to our podcast for updates on new episodes!

LISTEN HERE or read the full transcript below.

 *Disclaimer from Identropy: These transcripts are produced using automated tools, so may not be an exact word-for-word transcription. (i.e. - if you read something that sounds wrong, it's the tool's fault!) As always, for a better experience, please listen to the actual podcast.

 Podcast #41 Full Transcript:

Identity At The Center #41 - Server Access Management 101 with Paul

Jeff: I'm Jeff and that's Jim. Hey, Jim.

Jim: Hey, Jeff, how's it going?

Jeff: Pretty good. I think we're gonna keep this one a little bit shorter because we're going to. Yeah, I know you actually had a conversation with Paul Volosen from Centrify about some of the concepts used to manage IAM for server access and want to make sure we give enough time for that. I found it pretty informative as you're recording it earlier this week in a really good intro to some of the terms and methods that are used for managing access to those types of resources. Before we get to that conversation, is there anything that you want to touch on?

Jim: No, I think it's kind of a one on one for managing server access. So people who are on a hard grizzled vets in that space, it's going to be a little basic.

But for a lot of people who are IAM practitioners who didn't come up through that angle of IT I think it could be informative, competent and basic, we talked about pay attention to the basics of how you manage server access when it's one server and then what are the challenges for managing it as you do the enterprise? You have hundreds or thousands of servers, so it's kind of a perspective we talk about from and as you pointed out, Paul was a very informative guest and somebody we'd like to add back in the future, if that's possible.

Jeff: Yeah. He's a former Identropy and now a Centrify. So good people, as we like to say. I particularly enjoyed your pseudo definition and I don't want I'll tease it at that, but I thought that was very informative. I think even, you know, grizzled vets, you may find kind of nuggets here and there, but definitely probably more geared for folks who maybe aren't SML with it. But I liked it. I thought was really informative and a good refresher in some cases for some of the concepts that are out there and hopefully will give people a good kind of platform to stand on as they start to talk more about privilege access management. From a IAM perspective.

 Jim: Well, you know what I was thinking, Jeff, was if we had a listenership of thousands or hundreds of thousands of people, I'm sure we'd have our haters saying we'd have a Twitter page full of people collecting every little nuance thing we said that was not correct or could be misconstrued, but we're not quite areas, So we have a little bit of leeway.

Jeff: I think so. I think it's just the nature of the game. There's always gonna be haters about something or something correct in. You know what? If it's something that's newsy, corrected, let us know, we're happy to take that. You know, for me personally and I'm sure for Jim as well, here's what we think or here's what we're doing. And if there's something that we can improve on or need to be corrected, that's fine. Great. Tell us. Educate us. So we're always happy to take that feedback and get smarter. It's OK to get smarter over time.

 Jim: Absolutely.

Jeff: OK. Well, I think we'll kind of wave it as a brief intro for this week. We'll get to that conversation here right after the kind of little bump that we'll do. And hope you enjoyed that conversation between Jim and Paul. And we'll talk with the guys in the next one.

Jim: Everyone, Jim McDonald  here today with identity at the center podcast. I've got a special guest with me, Paul Volosen he's turned. Lee Central Phi employee and Identropy alumni and part time trouble. Paul lives in Austin, Texas, and he's a security geek by day adventure seeker on the weekend. But he's currently second home and being productive during the current pandemic that we're all dealing with no matter where you're listening to this podcast. I'm sure it's affecting your life. So, Paul, first question, do I get the pronunciation of your last name? Right.

Paul: I actually kind of close. So though the official remained pronunciation is Paul Volosen. I think that a limit of an S-H in there. So you actually got pretty good. Thank you. And I'm very happy to be able to sit down and chat with you. I have good memories of Identropy and I really appreciate this opportunity.

Jim: Yeah, we certainly miss you, but so I figure we start to something fun and you help me out with that introduction, adventure seeker on the weekend. So give us an example of maybe your most impressive weekend adventure.

Paul: Oh, wow. That's a good question. So I do like a lot of adventure, especially traveling. I really like to go to many different places.

I've been probably to most major cities in the US than only couple of dozen countries, honestly, that the best adventures that I enjoy are being by the ocean on the coast, especially the Pacific Coast. But given that that coast at least 12 times in the last 10 or so years and absolutely enjoyed its sights, I was just there about a few weeks ago right before California got shut down and didn't air BMB drove from L.A. to San Francisco. It's very peaceful to enjoy it. And and I consider that one you don't want one of my favorite personal adventures.

Jim: I love that. I've done that myself in Big Sur, California, is it's a true Jim see nine states and say anyone is listening and you get an opportunity to do that stuff in Big Sur spelled as you are. And there's like some cool bed and breakfast there. It's like, what, rural wooded California on the coast, I mean, this one's the coolest place I've ever been. What do you think?

Paul: It's absolutely beautiful, and the tips I'll give you that you can get a convertible. You have a convertible take it or wrap one if you can. Actually. Beautiful.

And to I mean, there's a lot of cliffs and a lot of tight turns there. So you want to be careful not to go at night or if you do to be to be careful. The first time I went with a friend of mine, he was going kind of fast. And we are we almost had a very, very end result. But it's absolutely gorgeous. It's breathtaking. I love Big Sur and an entire coast. I agree with you.

Jim: So, Paul, one thing we always like to get into. How did you get into IAM. What's been your career journey since then?

Paul: Great question. So like I think with most people on IAM it's people kind of fell into it for me. I got very lucky. And I was able to start what now is basically 20 years ago at Microsoft. And I worked there for basically my first 10 years of my career and worked as a program manager with the security team and built kind of a foundation on the lower level security features like authentication modules and making changes to the operating system.

And so that I was able to use to basically get a job at SailPoint, which of course is one of the big players in an identity management.

When I move talked in Texas and for the last almost ten years from working with SailPoint and in the last couple of years with access management. So that's the story of how I got into identity access management.

Jim:  Like you said, most people fall into it. I fell into it. I was never an engineer at a big company and, wound up working my way into the project management side house and then ended up, kind of in a business project where we wanted to pull our portal share, there was our dealer portal, we would have one dealer for all across multiple brand channels and realize that while we had all these different identity silos, we had to pull together. And lo and behold, there was industry called identity and access management. And so I became an expert all of a sudden, I should say I became an expert. All of a sudden I was forced into becoming an expert. So but it's paid dividends. I love this industry. It's one of the reason we have the podcast to help people, who are new in this, getting into the industry, maybe they're on their first project. Do you have any advice that you'd give to folks like that or any kind of words of wisdom?

Paul: Well, Identity and access management great that never get boring. And it pulls in so many different types of technologies. And you have an opportunity to learn so much. So you can do, active governance, you could do policy things, you can do automation, you can do DevOps, you can do security. So for someone that get bored easily on technology, which is myself included, I think a lot of techies are like the threat we're in because we're intellectual and we're trying to maximize our use of our brain, identity access management is an opportunity to do that once, not working really, really well. There's not that much more you can really learn about IP and Wireshark points, cryptography really, really well. There's not that much more, that you can do. In my opinion. So identity active management bring all the technologies that you could possibly work with into play. And I think that's the opportunity for poor people. And that's made it most fun for me because I'm always learning and I'm I'll always love to learn. And so for anybody that's looking into it or starting into it, it can be overwhelming. But believe me, the ride is fun. And it never gets boring.

Jim: I love it. I love it. So, Paul, one of the things that we try to do with the podcast is focus on one topic during the session. So we picked, as are our big focus. What we want to talk about today was securing server access as a discipline within IAM. So I think what you're getting at is there's so many different things within IAM to explore. But so one of the sub disciplines is securing server access. And so, I know that you've been in this space for a while. Maybe you can share some of your perspective on managing server access.

Paul: Sure. So to me, securing server access within IAM really mean figuring out who has or should actually have access to what resource based on a specific business need. So, for example, if you have a contractor and full time employees that have different functions, you have a contract web administrator. They may only be able to have access to a small set of servers to perform a particular function like start and stop the web service. And they may not need to have access to other production servers or servers that are just designated for full time employees. And so figure out who needs access to what and what resource. Now, customers, try to do the best of this on their own and it worked fine when you have a few PPK, but it becomes a lot harder when you get into the hundreds or thousands. And it comes harder when you're managing Unix and Windows systems, when you're managing two different types of IT people, when you're managing different organizations. So you're doing merging of company. So it becomes increasingly more difficult as the company grows and as the environment grows. And that's our identity access management comes into play. Right. So there's different IAM solution and pan solutions to assist in that type of a larger problem.

Jim: Yeah. And so much of what you just said there could relate to the idea that somebody would have their entitlements or their bilges on server kind of restricted down to stop and start a web server. Well, as somebody who is kind of that level three support, I built the web servers and I would rate instruction sets for, the overnight support folks to maybe their level to where they, realize, okay, there's a problem, the web server and I wanted to have them be able to do X and Y troubleshooting such as not have full access to the server and be able to ratchet it down to just being able to do certain tasks.

And, you know, the more you're able to do that, it just someone want leave wide open access to folks that don't need it. That's kind of the whole idea around least privilege access.

Paul: And that I mean, and if you just have a small number of servers, you're doing that and you have just a few employees. That can be done, Windows and Unix has a pretty good management board for users on that. Still know maybe 50. But once you're getting into more and more users, it becomes increasingly more complex and it becomes increasingly more expensive and risky to rely on traditional management. Because if you make a mistake, that can be very costly for your organization as far as having been breached or having an attack. So I inclusions, in my view, come to really mitigate the security risks that are an  organization have.

Jim: Paul, I'd like to add to that, one of my perspectives is that IAM is special. When you have a larger organization, it becomes something that requires kind of checks and balances and oversight. And a lot of times that oversight is by people who aren't super techies. And so by having an IAM system there and requiring folks to work within the IAM system to manage security and to manage their privilege access, it creates a paper trail and then non-tech, all the audit type folks can look at that paper trail. And what you really need to do is to sign it so that there are not backdoors used, especially when you're talking about this type of access backdoors or the last thing you want, because really the people who are the ones who are managing servers are the ones who would have the back door. So, this is truly an oversight function or, meet them like you're saying that. Right. But it's the term must come into mind just kind of the fox guarding the henhouse.

When you have a situation where, the server administrators can set all of the security for themselves, does that is that really the level of security that you want or do you need to have it so that there are checks and balances? I think especially for large organizations, you need to have the checks and balances in place.

Paul: I totally agree. And maybe to restate that a little bit differently it provides the mechanism for the business to trust, but verify.

If I'm the Linux admin and you're upper management, you look at me and you say, are you applying the security principles? Yes, I am. Do you have access you providing for the people that need access? Yes, I do. Trust me. I'm doing that, right? Well, maybe I am and maybe I'm not.

maybe I've been attacked from the air or maybe just an accidental mistake or an oversight. So if you have that IAM solution, it provides you a window for you to validate essentially the policies that you think or fact or should be in the play. And, SailPoint and other tools provide that mechanism for identity access government. And, kind of I provide it on the productive management side.

Jim: I think one the point you're bringing up is like came to mind for me as well. And I explained to people what governance is all about. It's sure you can have the greatest automation for, managing and provisioning access. And you could do all that centrally. But if an administrator goes through the back door or directly into the application and creates an account or elevates privilege for an account, that if you don't have the loop coming back to say this, to compare what should be with what actually is, then you're missing something. And so that's what governance is all about, is verifying that what should be also is the same as what actually is. And when you have the difference between the two that is being acted on and that there's visibility to. So, Paul, I had an idea. So I'd like to play a little game because I feel like, within the IAM space, there's people who come in from a technical perspective. There's people who come in from a program or project management perspective. And I feel like obviously folks who specialize or maybe came from the server space are going to be a little basic for them. But for the other folks, I think this is an opportunity to have some learning about some of that base of some of the terms they may have been hearing throughout their career. They really don't know what they are. And so I'd like to play a little game, which is that I'm going to state a term that has to do with securing server access. And you describe what it means kind of within the context of identity and access management. So I'll start off with one that I remember hearing this and not knowing what it was Sudo or not.

Paul: So Sudo is, basically running a program with the contact of another user. Usually that group doesn't have to be it's somewhat loosely similar to run Azure or the elevating windows to be prompt on the on the window size. And you can configure who can do what and what contact in the future or another configuration file. UNiTAB is very familiar with it. A like I mentioned that earlier, when you got a couple of systems or under 10  under 50, not a 50 high. It is not. You can manage it OK, but once you've got many hundreds of servers managing that sudo file across hundreds of servers can become difficult. If you make a mistake and you put the wrong sudo files of the right people at the wrong people access and restrict the right people from having access. So tell a long winded answer, but sudo is basically being able to run an application when Unix application in the context to another user.

Jim: And so I'll add my little perspective as well, which is one of the things that I think really helps sudo is kind of an acronym super user do. And so the idea would be I can log in with my Jim McDonald account, which has very low power, but then I can use Sudo to say Sudo and I wouldn't use a backup account to run a backup job. Or I can, now, kind of do elevated privileges by running commands within the context of that of other accounts, because Jim McDonald has the ability to do those things that I can use some of those ideas. And then the management challenge becomes each of their services file that you reference. So how do you manage when you have hundreds or even thousands of Linux servers that you have to manage it a file full of accounts?

And so and that's kind of the true because to me the art and science of doing IAM when it comes to servers is that servers were designed. You don't need an IAM system, they weren't designed with the idea that, OK, there's going to be thousands of servers, you're going to have some kind of central administration tool.

You can run a clinic server by itself and have all the identity and access management capabilities within that server. It's then when you get a large number of them that you have a management challenge and then you have to extract. So in the IAM from those servers and put it into a central mechanism for managing the identity, managing the authentication, logging, etc.. So that's kind of just my two cents on that. 

Paul:  I agree. that's my experience and my view as well.

Jim: Excellent. So the next one, I'm going to just say both of them, because I think, it could get confusing otherwise. So that the term PAM, kind of an IAM nerd. So I think of privilege access manage. But within the context of servers, there is PAM pluggable access modules. So PAM's pluggable access module one you have at it.

Paul: So pluggable access or pluggable authentication modules is Eunice's implantation of different case mechanism providers with similar Phyllis's similar to what I'm more familiar with, which is security support provider or CI and windows. And really what PAM allows you to do is to have multiple different authentication modules on the Linux system and then you can configure them to perform different functions.

So you can have a Carbrook authentication module. You can have an interim authentication module. You can have different authentication modules for the different benefits methods that exist and they can trigger them to perform different functions. So to be more specific or to talk about the power of PAM really is, for example, you can have one module that can do a count authentication and then you have another module that'll do password validation and then you have another module that might do session management or making sure that a particular path toward me Pacific policy requirements and that's all configurable in the PAM out to be attractive depending on which PAM modules do you have, vendors that provide privilege access management will plugin and provide their own PAM module to take over the functions.

Jim: Right. Because I think, when I think of PAM module, I'm going back to my original example. Like a server can exist by itself. It has its own kind of default PAM modules, which would, look at files. That's one thing about Unix and Linux is that so-call is like everything kind of goes back to files. But if you wanted to, instead of using a file full of user names and passwords, you would need to use LDAP directory or some other or attractive directory or something. Or the example you used to send TLM, which is the what does that entail Log man?

That's like a protocol.

Paul: LAN Manager , It's a precursor of Kerberos and it's not considered very secure anymore, but it's what exists prior to the Kerberos.

Jim: And so that would give you the ability to what like authenticate to 94 domain or something, it's probably not a thing you'd want to do, but the idea is like if you want to externalize a function of authentication or authorization, you could do that with these PAM modules, right?

Paul: Yeah. NTIA And it's probably a bad example of what you should implement these days. They probably shouldn't use it. But yeah, I mean what you want to be using is, more recent and more secure or authentication modules either Kerberos or if you have a privilege access management solution, a vendor's solution, a vendor privilege access management solutions.

So that's where the other PAM comes into play, because now you can have better configuration via the application of about who has access to what. And then you can tie that to a bridging, for example, to use Active Directory as your similar source of truth for users rather than having hundreds of users across hundreds different servers.

So, what others had a PAM for executive management will take advantage of Pluggable authentication modules can build their own authentication module to take a priority over the build. Consistent one.

Jim: Yeah, we've been focusing a lot on Linux management on the Windows side. Privilege access management can be used for, servers account management. And I think that's one of the ultimate uses for privilege access management in my book. It's just an area where I see some declines. You can take companies where they don't have a good handle over service accounts. What's your perspective there?

Paul: So, service account becomes a little bit easier to manage with project management because you can lock down service accounts, you can bolt then potentially and then you can limit who has access to them by particular active directory user, optical active directory group or particular role, and you don't necessarily have to have everything run under a service account. But if you have a productive management solution and it's configured properly, you can get better control of servers account.

Jim: The next one they're willing to throw out to LDAP people who don't know what LDAP is. What is your primary for them to have a basic understand?

Paul: Sure LDAP or lightweight directory access Protocol, around think caught a few decades. Now there's a lot of versions of a 3.0 4.0. Microsoft's implementation of LDAP is Active Directory. There's also other adoption stations like OpenLDAP.

I think there was a Novell LDAP, but that one LDAP that everyone's familiar with this is Active Directory and Active Directory allows you provide to a format in a way to store information about objects especially identity objects. There can be other objects as well, like computer objects and specify security groups and specify containers. No use for where those users or the security groups are maintained. So when people felt in LDAP most people are thinking Microsoft active directory, but they can be other places as well.

Jim: Right. It's a combination, this one of the things I think is always tricky with LDAP is often will refer to a directory 80 or otherwise as LDAP,  LDAP also protocol, there's a structure for how to query or write to a directory using the LDAP protocol. And one of the things I think is, depending on your perspective, LDAP is becoming less and less important. I think when I first got into identity management, 15 years ago, it was one of the main disciplines of IAM like, you know, LDAP it's time to hit the books and learn it. Nowadays, it just seems like they're club directories are taking over. And with Active Directory, a lot of, you know, kind of core LDAP is not necessarily a discipline that you need to have. So that's kind of a maybe a controversial statement. I wonder if you agree with it.

Paul: So at least my most recent experience, just because of where I work, Active Directory is a key technology that all of our customers have. So in my mostly since then, that hasn't been my friend, but it might just be because of the customer set that we have. You're right. There are digital directory, Google directory, there's other directories that you can use. But for me, AD still is quite prevalent. I mean, what fortune 500 company doesn't have an active directory. I don't know.

Jim: I definitely agree with you from that standpoint. AD is definitely still has a foothold in the enterprise, especially when it comes to network operating system. I'm just kind of wondering if the LDAP protocol. So, yes, if we generically think of AD as LDAP, I guess I'm with you 100 percent, but if I take of, learning LDAP as a protocol, it seems to me like there's not many people have to manage Active Directory to run LDAP commands against AD, they've been wrong.

Paul: Knowing LDAP and how to build up queries and streams can definitely be helpful if you have really large implementation, if you've got thousands of low use and tens of thousands of groups and so forth.

For sure, I do remember kind of backing Windows and T Windows 2000 data learning the all that protocol was the big thing. But it's because there was new technology. It's like having to learn container's today or having to learn rest API and having to know how to do all the nitty gritty of those technologies because it's new and time goes on. You have utilities that get better to help you manage that. So I think today better active directory tools where you don't have to know everything about LDAP and how everything goes on the wire and the specific query you have to make.

Jim: Right. That's a great point as well. So Centfiy, really known as Noom for AD bridging technologies, and you mentioned AD bridging what described AD bridging what is use for.

Paul: So AD bridging is at its core using Microsoft active directory information to provide  privilege access to Linnet using the traditional access, as you know, is single users and Pather Thousand to file. And so the AD Bridging solution that Centrify other vendors may provide, provides that ability to do privilege active management at the active directory user level. So you can specify a user or secure group that has access to a system or a system or a computer or a set of computers and roles and you can implement the AD bridging our back.

And so because everyone has a AD log in or we make the presumption that everyone has an AD log in, we can tie that to do two-point provides active management.

Jim: Yeah, I think could identity governance and automation, Your AD is probably connected to your HR system. So people are having access provision maybe. They're doing getting some birthright access. Probably more importantly, when they separate from the organization, their account has been disabled or terminated somehow, maybe deleted. So you have good practices around managing your access and AD, then you can leverage those when it comes to server management on the Linux side. Now, my experience has been that I've run into a lot of resistance and, maybe that's softening some over the years. But I remain, too. I have run into a lot of Linux administrators where they don't want the management of their servers to be connected to AD. There's kind of a fear that, well, maybe, if I have to get in and fix something and there's AD bridge doesn't work, then I'm up the creek without a paddle. So do you run into resistance much and kind of what are your thoughts and how do you handle that now?

Paul: That's a good point. We certainly do have some resistance from some excitement at times.

One of the things that they mention, like you said, is if I implement this, it's going to break things and then I'm not going to be able to do the work that I was able to do before. And it's going to make my job harder.

You know, really the response there is that as the organization grows, your job is going to get harder. You're going to have to manage more SIDERIS file and more to administration at each server level. And it just becomes a lot harder.

But maybe bridging you centralize that and you tided with your active directory.

And an important thing to note, too, is that the AD bridging gets planted like we talked about a little bit earlier as the pluggable authentication module and it can work alongside your existing solution. So if you, as you transition from a traditional unit management to a PAM solution using a bridging, you might still have a few servers where you might still allow perhaps direct access. But as you test out, you'll be able to move into a model where you can just use your active vector account, you can just get them, will find out where you don't have to manage the SIDERIS file as much, where you don't have to manage individual access to the server, you manage the vendor privilege access management tool.

So if we say that equipment so that it's going to be equally easier in the long run and that gained to some headway into that.

Jim: Yeah, my perspective is that you run into objections a lot is not just with the AD bridging. So I think it's a framework for how to address. Sometimes these are five times. Sometimes they're based on real legitimate concerns. But I think the first thing you need to do is understand all the concerns, maybe start a document where you list off the concerns. Availability was one that I threw out there, like, well, if this isn't available, that could be true. It's true of single sign on systems. A lot of times people say, well, single sign on unavailable. None of our applications work. And so then what we're up creek without a paddle. So it's understanding all the objections and then addressing being able to address them in a way that makes sense. And then sometimes I find that, if you can convince the party that you thought through all the objections and you've made a logical case on how you go about solving them and you still meet resistance, I think at that point it's, we're doing things for the business. We might need to escalate it to a higher level of management, make our case.

But I think the best thing is to try to make a factual base case, because it's only going to sharpen your argument on why you need to move forward with the technology and why, to measures you're taking to make sure that this is the right decision to do organization, that you're meeting all these objectives or objections, I should say, are legitimate and I'm well-thought out ,etc.. Is I think if we just kind of, if we just let some but let people make objections and kind of stop us from moving forward on. You would still be using mainframes everywhere. I mean, we gotta keep moving forward and we take on objections and we come up with ways that we can make things work better.

Paul: I actually want to add a couple of things. Because I'm actually thinking back specifically to a conversation that I had with one of our living customers. And so the particular solution or I get them to hold this, one, If you take a project management solution that's been around for a while, that's solid, you want to look at that and look at the track history of the particular company and anything that's been around for a long time. It's just gonna have higher reliability. Also, the solution should have, for example, what's called rescue. Right, for the ability to log into the system. If the authentication of the PAM module, the vendors PAM module isn't working so good, a good vendor solution is still going to provide that. Now, of course, you want to limit that to be a very small subset of users, but it still provides that that failsafe break glass. If you absolutely need to. So once I explain those two things to the particular customer, that and the particular excitement, he felt more at ease at that point.

Jim: Right. Yeah, I think that's very important, because a lot of time servers lose network connectivity. Let's just say it's up to the network card when bad in the server and they can't reach to PAM server. How can you authenticate? Well, you know, if there's a fire call account that can be checked out or, what is PAM system goes down, you have to kind of think through all these scenarios and through legitimate questions. Right. They should be answerable.

So I think there's a combination of, thinking ahead and knowing what the objections are likely to be, but then also taking on the objections and being able, if you can't answer them in a logical way, you shouldn't get uptight or angry that people are asking the questions. You should be able to logically defend your position.

Paul: Certainly. And what I try to do is I try to think to show how the solution can make the person's life easier and how it can make management easier. Management of account management of access requests. You know, I use the case, for example, when you have a new employee come in. They're going to send your email to have access to all the Web servers you no longer have, if you're in a unique Sadanand you magic 10 servers that are Web servers, you have to give them access and make sure you do it right. But if you use a good solution, you just have to give it to one computer role and to one security group for the web admin server, for example. And it's done and it's instantaneously and it takes 30 seconds or less for that all to be implemented. When the unique sidemen see that, they're like, well, this is cool. This makes my job so much easier. So if we can what I know is oceans like if I can show that it makes the person life easier. Then I get a lot better acceptance from the customer.

Jim: Absolutely. So let's call it good job on that game there. I do hit you with one more question before we wrap things up. And it's a big one. You know, we're a lot of what we talked about today was server management is kind of traditional. It's been the same since we all had all of our data centers in-house. And most companies do their chips in or all in on infrastructures servers using Azure interview as group cloud. So my question is, are these concepts still relevant? Are these things still important or are we still doing privilege access management in the cloud infrastructure?

Paul: That's a great question. So the answer really is yes, yes and more yes.

And they become even more important because you're now responsible not just for your on PAM servers, they're now responsible for servers that for Linux servers that are hosted somewhere out in the cloud. And so if you have a breach or you have an account or access that the compromise that person now is using AWS servers to spam out to launch attacks on other computers, and it looks like you're actually doing it, for example, in addition to extracting whatever valuable data exists on that. So everything and that all the traditional problems with IAM and PAM come into play and it just becomes a little bit more complex because specifically you have to manage the safety, for example. But and then all the other operating systems to fix that, it's up to forensics ends up match on korsicans as well.

Jim: Yeah, I think that's a great point, one of the thoughts, one of my points of view is that, by using a cloud servers. You don't really give up the accountability. The buck still stops in your desk if there is a breach. No one's going to care that you hired some third party and the third party fell apart and didn't do their job. It still comes back to you. Whether it's the infrastructures in your data center or in the cloud, ultimately it comes back to you and the reputation of your organization to protect your data. And so I still think privilege access management is as important as ever. And I think, when I think about privilege access management, my biggest concern is the inside thread is the administrator who knows 50 different passwords because they're in scripts, they're in service accounts, maybe as that person has accounts on individual instances of servers or multiple active directory accounts. And how do you make sure that, all those things get turned off when the person leaves? And quite often it's not possible, right. Maybe 10 different people know a service account or, a lot of times you don't even know where the service account is being used across all the applications. So that the real key is that, the guidepost as humans don't need to know passwords, at least for most accounts. And so that's where I like to drive people to think about this.

Paul: I don't know if they disagree with that. But the way I think at least personally for me that I kind of try to sell it and sell myself really is,  I mean, well, not in a compromise, but just compromise because someone may make a mistake. They'll put the wrong email. They opened the press on the wrong link. They went to a forum and they had some sort of attack using an old browser or whatever, not even the insider threat. But if your detail may not have been you, the CEO and your target area, the CFO and your targeted and now your account compromised and your data that call traded, that's very different, then that the insider threat. Anybody can become can fall victim to something like that. So for me, at least when I sell myself on my own personal security measures and then when I travel and I think about personal security, I authorities do they think  the unintentional compromised and becoming a victim to sell me on the security solution or posture that I particularly take the day they think that it's really the insider threat that people should be most worried about.

Jim: I think it's all of the above. But I mean, I can't ignore phishing. I mean, it's probably the most obvious attack vectors to trick people into giving up their credentials. And then right on for people to take that and then try to, there's different types of phishing. There's that concept of, phishing in general. But then they're spear phishing. So we know somebody is a powerful user and we're going to have a very targeted email at that individual. And, people make mistakes, I feel like I've kind of become an expert at spotting phishing attempts because they've gotten so good. They've gotten so good in so many cases where, you get the emails over and over again of your Apple I.D. or, hey, we just write your PayPal transaction or something like that yearsley way. I didn't spend $45 on PayPal to that vendor. I need to go I need to go check that out. And you know, really what they want you to do is click on the link and put it in your PayPal I.D. and then suck money out of your bank account.

Paul: Right. Or the CEO, you get a phishing e-mail where the CEO says, I sent you a $50 Amazon gift card. Thanks for being a great employee, click on this link. Oh, that's so cool. My CEO loves me. I'm going to go click on it. You know, those sort of things are successful at them now with an organization. Then, that's not the insider threat that. Somebody becoming a victim, to an attack, and then because of the access that they have, because the data that their user it's privy to are now all of that get compromised. And, you can do potentially lateral movement if you have a high enough privileges and cause a lot more damage.

Jim: Right. Yeah, there's a lot of differences, Paul, you're doing such a great job. I'd love to have feedback. And we can dive into some more of these topics, things like, you know, the phishing and where those conversations might lead us around. Multi-factor and things like that. But  I'd say for sure, we're kind of running out of time, but we would love to have you back and kind of X-Force, more of these topics.

One thing I want to ask you, so people want to reach out, get in contact with you or, follow you on Twitter or where are you active? Where can people get you on LinkedIn or what do you have for that?

Paul: So if you want to talk tech and sofrito, just reach out to me on LinkedIn. It's  Paul Volosen , I'm happy to connect in and chat security. That's the best way to have a more personal connection. You can look up on Facebook if you want, but they're going to get to my personal views. But if you just want to talk corporate stuff and security stuff, you can reach up LinkedIn.

Jim: sounds fantastic. And we'll add that to the show made. And we'll try to have Paul back before too long and maybe hear more about something this weekend. I hope we can get into some weekend adventure outside by the time we have it back and maybe we can hear about some of those.

Paul: It's been really hard on the with lockdown, everything. It's difficult to get out. So the good news is I've just been really productive. Bad news. I'm not really enjoying life, but hopefully that'll change. That'll change eventually. I mean, we'll get out of that. We'll get out of this eventually. And we just kind of hunker down and go down. But I'd love to be back. And I would say the conversation that we had today.

Jim: Yeah, I think you're making a great point. We're all in this together. It feels like we're moving toward hopefully the end of all this and get back to normal life. And again, appreciate you joining this. We all hope to have you back again soon.

 

 

 

Jim McDonald & Jeff Steadman

Jim McDonald & Jeff Steadman

Jim McDonald is a professional with over 15 years leading teams through business-critical technology initiatives. Technical Strategist, Leader and Champion of Change with history of crossing organizational boundaries, cultivating strategic alliances and building consensus and alignment among diverse constituents to leverage IT as strategic asset and deliver solutions that rejuvenate and advance global business’ financial performance. Also as part of our advisory practice and with over fifteen years in the identity and access management space behind him, Jeff Steadman helps develop realistic IAM strategies and provide vendor agnostic recommendations to move the needle on IAM maturity for organizations large and small.