Patric Schmitz - Managing User Risk: How to Constrain, Control and Empower

Yeah, as set. So I've, I've took over this talk. So I had quite, yeah, not too much time to basically prepare this. My name is Patrick Schmitz. I'm speaking on behalf of Brian chapel. Basically our topic today is about managing user risk, how to constrain control and empower news flash. Right? So users are a risk, but I'm sure you already know that. I, I want to talk a little bit into what Jackson just said when he connected via VPN into his company network. Well, he didn't do that on purpose, so, but still it can be a risk. Now the question is why are users a risk? And so I would ask you to throw in just a few ideas, why a user could be a risk.
Excellent. No one, well, I've prepared some points. So for the first thing, users just tend to make mistakes. We are all human and yeah, we just make mistakes. It's a wrong click. It's a wrong file that gets deleted. Some, some links and email clicked, whatever it's about data laws. People tend to send out stuff via mail to the private mail account, just so they can work at, at home or something like that. Like I said before, deleting wrong file might be a stupid thing. Malicious activity, basically. So not every user is happy with his company and some users might need some money and get offered money to steal data, to, to basically do harmful things to your network
Last but not least users are vulnerability. So it's kind of equivalent to a vulnerability because they might visit the wrong website, click on the wrong link. They might visit the right website, but there's maybe some ware installed or malicious ads popping up pressing the wrong links. They tend to open email attachments from people they might know, might not know whatever last but not least the whole story about the USB sticks found in the car park. So this is actually something hackers tend to do. Leave USB sticks somewhere, hoping somebody will use them. And chances are this happens.
So as long as the user is, is not a privileged user, the risk is fairly low because I mean, what could possibly ha happen? The hacker gets into your network and he sits there with plain user user, right? And he won't be able to jump around in your network, trying to find some elevation that he can do, trying to, to get onto service where he shouldn't be. So if the user has privileges, that's the highest risk you can have because this is what the hackers are up to. They want to get to the privileged user accounts.
So what, what, sorry. So, like I said, in the beginning, we are going to talk about what are the options we have to try to minimize the risk that the user might present to your network, the best we can. So, one thing is we try to constrain, which is basically restrict the user, remove all the privileges. He has restrict privilege user activity. This is most likely going to end in the user, not being really motivated anymore. It's gonna end up in help desk calls because the user cannot install what he wants to install or what he needs to do, his daily job. So taking away all the privileges without doing anything else is just gonna lower your productivity and the motivation of your users.
The other thing we have is control. So trying, okay, you can have the access, but we're gonna control what you do all the time. Not a very good idea because I mean, how much do we know about our environment? Let's just picture an office building. And I hand out a general master key for all the doors in the building to my clinic crew. For example, I will never be able to follow where they go, what they do, they could open any locker. They could open any draw. They could can have access to anything they want. The problem here is it's, it's most likely that I don't know all of my environment. I might not know unknown back doors or unknown outside stairs or something they can use to get in. And this, this map is like an uncomplete map of the United States when they discovered the coast.
And you can see a lot of white space on the left hand side. So that's what they didn't know, representing what we might not know in our environment. So like I said, we can try to control what they are doing, basically having this, this guy, following them around, looking at what they are doing and stuff. Yeah. That, that might be ways out of that. He might not pay attention like in this picture. And if we get that into an it world, it's trying to control what somebody is doing is most likely being done through an agent. And yeah, but as soon as I have admin privileges, I might be able to just shut down the agent. Sometimes they have like agent, agent based solutions where they are both trying to start each other when one gets killed. Yeah. Killed both at the same time and it's gone again.
So what we might wanna do is really empower the user to do stuff. And I'm talking about normal user account and empower the user account, the user to do more with this account, but we should define, define what the user should actually be able to do in a privileged context or in another user user's context. And this is basically the privilege of the least, the principle of least privilege, sorry. And principle of least privilege is actually around for quite a long time. It's 42 years now. I think Salter wrote a book about that principle of Lee's privilege gives the user just as many rights as he needs to do his job, not less and not more. So basically what it comes down to is we just have a standard user and then we just give him the specific targeted privileges. And Brian has a nice way of explaining that. So let's just imagine the thump of the left hand is really dangerous. And the only way I can restrict usage of the left thump is cutting off the whole arm. So if now somebody needs to use the pinky Hmm. Bad thing, put, put the arm back on and then you can use the pinky, but you can as well use the thump again. So we need to have targeted privileges, which just empower the user to do what he needs to do.
So like I said, in the beginning, privileges are a high risk going down. The root of least privilege means it's the least risk we can have. So this is the way we might want to try to minimize risk. If we minimize our risk, doesn't mean it's gone. So we actually want to ensure we still keep track of what is happening in our environment. Looking at unusual behavior, like the administrator, Brian usually locks on to file server one, two, and three. And all of a sudden in the middle of the night, he locks on to file server five and print server six, whatever. This is something we should pay attention to right away. Not like two days later, but right away. And it's, it's not that we should lock down that excess, that excess might be valid. We might just wanna take a look at it closer.
And before we get one of those unusual behaviors, we might wanna analyze how unusual it is and how much of a risk risk it is. And last but not least, we of course want to try to fit in a measurement to our, to what we do in it. So being in it, security is not a nice job because if we do our job, right, nothing happens. And well, if you stand in front of your management, trying to tell them, okay, next year I need the same budget because I need to do a good job. They will ask you for measures and having a back end, which displays and can actually show you differences between this year and next year of this year. And in six months, how high your risk level is, this is something that will support you in getting your budget and making your infrastructure more secure.
So this is the last slide marketing made me put it in there. Of course I'm a, I'm a vendor. And, but as well, we are techies and geeks, but that's basically what beyond trust does. We have our privileged account management solution suite, which will cover stuff like privileged password management, session management, ad bridging and delegation tools, as well as auditing. Then we have our vulnerability management solution, which will scan your network and your devices for known vulnerabilities. It will calculate and show a risk basically of those vulnerabilities by yeah, analyzing if a vulnerability, for example, a high, severe vulnerability might be high, severe, but doesn't have any exploits. So it, it's not really a threat in the first place. Vulnerabilities with exploits is what you want to focus on. And even if it's a medium vulnerability, well, if it got exploits, you want to fix that first. So, and the whole solution reports back into, beyond inside a back end, which offers you dynamic rules to react right away to any threats and activities that happen in your network. Thank you.
Thank you very much, Patrick, in view of the time and the surprising activity that you had to take over for your boss. I think just believe you. Thank you very much for
Thank you.