Re-evaluating Local Administrative User Rights
-
@nadnerB said in Re-evaluating Local Administrative User Rights:
A/V isn't 100%, just as removing admin rights isn't a 100% effective security measure but together they make a really good combo.
But if I had to pick one or the other, I'd trust a machine with no admin privs and no AV over one with AV and local admin rights.
Local admin rights being removed, to me, is critical. AV is just "nice to have". And AV without local admin rights removed is pretty useless as it depends on that.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
I'd say that most malware wants to write something to the local PC.
Right, but there are a lot of places on the PC you can write to that does not require local administrative privileges.
True, but those spaces aren't ones that will automatically execute.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
Having removed admin rights, you have defeated something that the A/V vendor doesn't yet have a signature for.
Not necessarily, with UAC, programs ran as users in the local Administrators group still runs as a standard user and requires elevation.
This is partially true, but only sometimes. There are ways around it. Lots of applications get installed with admin rights and once there, UAC is disabled. Look at any IT management toolsets, for example.
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
As for software/viruii that don't require local admin rights, uhuhm - CHROME, rights levels don't matter.
Huh? Chrome isn't a thread because of this.... no admin access whatsoever.
-
@nadnerB said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
If it's about users doing something to work around company device management and security software, well then at that point it becomes a matter of company policy, management, and not an IT issue.
An ounce of prevention is better than a pound of cure.
Policies are only good if they followed, HR & management are only good if they have the balls to do something.
Chances are that a rogue actor won't care about policies or HR.More importantly, normal end users are not trained to understand what they are doing in most cases. Ignore malicious actors, we are talking about good, well meaning people that HR has vetted. They still don't understand what "installing" means, they can't identify safe sources, they don't have the diligence to do package maintenance, they don't know overarching IT strategies, they don't control licensing or often even have awareness of it.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
What I'm getting at, is if the device is actually REALLY any bit safer without the user having local administrative access? I mean, if someone external wants in to a device, is the assigned user not having local administrative access making the device any more secure?
The concern isn't necessarily about downloading a piece of malware.
Those two things are one and the same. If someone wants remote access, then getting the end user to accidentally download malware is the number one way to achieve it. You can't separate the two concepts.
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
What I'm getting at, is if the device is actually REALLY any bit safer without the user having local administrative access? I mean, if someone external wants in to a device, is the assigned user not having local administrative access making the device any more secure?
I would answer this and say - yes it is still more secure. If you're a target, then next to nothing is going to protect you. But come on, how many people are actually targets? 0.1% maybe? probably not even that many.
I agree, dramatically more secure. Almost all of your risk comes from the end user, not the computer. And not having admin rights is the most significant protection against the end user.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
I'd say that most malware wants to write something to the local PC.
Right, but there are a lot of places on the PC you can write to that does not require local administrative privileges.
This is true, but that leaves very few places to write to. Chiefly, the users profile. Things executing from there should be heavily scrutinised by the A/V. Whilst not solving the issue, it does provide better protection.
I read that over 90% of ransomware, for example, does not require local admin rights...
Yes, RANSOMWARE. That's very different from normal malware. Ransomware is super scary and a major topic causing us to change a lot of how we behave. But here are some key thoughts...
-
Ransomware is an additional threat over what we had traditionally, it is not a replacement threat. Nothing about ransomware should change this conversation. All of your normal risks are what are addressed by what we are discussing. Ransomware is in no way the majority of threats, nor have other threats decreased because of it.
-
Ransomware does not REQUIRE admin rights to work, it just becomes more powerful when it gets them. By getting admin rights it can move from "trivial to stop" to "extremely hard to stop", it moves from "easy to identify" to "medium to identify". It changes from "encrypts one user's stuff on the machine" to "encrypts every user's stuff on the machine plus the machine itself." And with admin rights it can hide itself, make itself start without a user, and control its priority. It's like your car doesn't require tires to drive, but it sure works better when it has them.
-
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
A/V isn't 100%, just as removing admin rights isn't a 100% effective security measure but together they make a really good combo.
But if I had to pick one or the other, I'd trust a machine with no admin privs and no AV over one with AV and local admin rights.
Local admin rights being removed, to me, is critical. AV is just "nice to have". And AV without local admin rights removed is pretty useless as it depends on that.
This is actually my stance. I'm trying to rationalize the opposite via this discussion. If it can't be, then my position stays. Sometimes it really helps to look at things from opposite angles to get a better understanding. So don't take my points the wrong way.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
I'd say that most malware wants to write something to the local PC.
Right, but there are a lot of places on the PC you can write to that does not require local administrative privileges.
This is true, but that leaves very few places to write to. Chiefly, the users profile. Things executing from there should be heavily scrutinised by the A/V. Whilst not solving the issue, it does provide better protection.
I read that over 90% of ransomware, for example, does not require local admin rights...
Right why would it? Assuming it can just run in user space - so many people/companies just allow full access to everything to their users so the crap just runs and gets what it can...
I mean, the worst things that could happen, don't seem to matter if the user has local admin rights anyways.
I don't agree that that is true. But let's assume that it is. (and by the way, for most of my clients, this isn't true.)
- This is similar to saying we should no longer worry about terrorists or conventional wars (which are the majority of military threats) because there are now nuclear weapons and while less likely to be used, are far worse. Don't let a new, worse, but less likely, threat make you get distracted from the real world, still every bit as dangerous legacy threats. The old threats haven't gone away, they just don't make the news as much.
- You are focused on a single kind of threat, not security in general.
- Ransomware is not generally considered a security matter. Yes, security is what stops it. But once ransomware happens it's not about theft of data, it's about inability to operate. On the security radar, ransomware is low.
- For companies with good backups and modern system design, ransomware is of little to no concern... unless you start giving out admin rights (and even then, often isn't.) It's annoying, for sure, but currently not threatening.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
Having removed admin rights, you have defeated something that the A/V vendor doesn't yet have a signature for.
Not necessarily, with UAC, programs ran as users in the local Administrators group still runs as a standard user and requires elevation.
This is partially true, but only sometimes. There are ways around it. Lots of applications get installed with admin rights and once there, UAC is disabled. Look at any IT management toolsets, for example.
This example requires admin rights or UAC in the first place. That's not the issue.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
If it's about users doing something to work around company device management and security software, well then at that point it becomes a matter of company policy, management, and not an IT issue.
An ounce of prevention is better than a pound of cure.
Policies are only good if they followed, HR & management are only good if they have the balls to do something.
Chances are that a rogue actor won't care about policies or HR.More importantly, normal end users are not trained to understand what they are doing in most cases. Ignore malicious actors, we are talking about good, well meaning people that HR has vetted. They still don't understand what "installing" means, they can't identify safe sources, they don't have the diligence to do package maintenance, they don't know overarching IT strategies, they don't control licensing or often even have awareness of it.
I like to remind people of this:
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
What I'm getting at, is if the device is actually REALLY any bit safer without the user having local administrative access? I mean, if someone external wants in to a device, is the assigned user not having local administrative access making the device any more secure?
The concern isn't necessarily about downloading a piece of malware.
Those two things are one and the same. If someone wants remote access, then getting the end user to accidentally download malware is the number one way to achieve it. You can't separate the two concepts.
And in those cases that's what the AV is designed for, especially Trojans. But that's not my point here, my point is in those cases it's about trickery via social engineering and/or web links to steal credentials to services. Not particularly about the users device.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
I'd say that most malware wants to write something to the local PC.
Right, but there are a lot of places on the PC you can write to that does not require local administrative privileges.
True, but those spaces aren't ones that will automatically execute.
what? there is a an auto start area for the local user space.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
Ransomware does not REQUIRE admin rights to work, it just becomes more powerful when it gets them. By getting admin rights it can move from "trivial to stop" to "extremely hard to stop", it moves from "easy to identify" to "medium to identify". It changes from "encrypts one user's stuff on the machine" to "encrypts every user's stuff on the machine plus the machine itself." And with admin rights it can hide itself, make itself start without a user, and control its priority. It's like your car doesn't require tires to drive, but it sure works better when it has them.
Devices in this scenario are strictly single user devices. Not MS AD domain joined.
Software in Win10 doesn't just get admin rights, that requires a very specific set of events or oversights that don't exist in this case. If a random program wants to execute from downloads folder or somewhere similar, it will do so as standard user. So it can't just get admin rights and hide itself.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
As for software/viruii that don't require local admin rights, uhuhm - CHROME, rights levels don't matter.
Huh? Chrome isn't a thread because of this.... no admin access whatsoever.
This was an example of software that could be run in user space with zero local admin rights - nothing more. The remainder of that post (or a followup one) pointed out that I don't want to see users able able to execute an executable that wasn't installed by an admin - but I'm not sure that's possible, or really reasonable.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
You are focused on a single kind of threat, not security in general.
My concern is all of it but I don't have time to give an example for every single security issue. If you have more and better ones, please list them. I'm looking for as much as possible here.
-
@scottalanmiller again, my focus is not ransom ware, I used that as a single example for some point i don't remember now.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
If it's about users doing something to work around company device management and security software, well then at that point it becomes a matter of company policy, management, and not an IT issue.
An ounce of prevention is better than a pound of cure.
Policies are only good if they followed, HR & management are only good if they have the balls to do something.
Chances are that a rogue actor won't care about policies or HR.More importantly, normal end users are not trained to understand what they are doing in most cases. Ignore malicious actors, we are talking about good, well meaning people that HR has vetted. They still don't understand what "installing" means, they can't identify safe sources, they don't have the diligence to do package maintenance, they don't know overarching IT strategies, they don't control licensing or often even have awareness of it.
I think this is key here. These things are the difference between them and us.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
What I'm getting at, is if the device is actually REALLY any bit safer without the user having local administrative access? I mean, if someone external wants in to a device, is the assigned user not having local administrative access making the device any more secure?
The concern isn't necessarily about downloading a piece of malware.
Those two things are one and the same. If someone wants remote access, then getting the end user to accidentally download malware is the number one way to achieve it. You can't separate the two concepts.
And in those cases that's what the AV is designed for, especially Trojans. But that's not my point here, my point is in those cases it's about trickery via social engineering and/or web links to steal credentials to services. Not particularly about the users device.
credential stealing/online trickery aren't what local admin right (or rather lack there of) are there to protect.
