Re-evaluating Local Administrative User Rights
-
@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.
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
@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.
Right. I wasn't implying that it was in that statement.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@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.
Sure, but you just said this is basically in a home user situation - what home user won't just click allow when they see those prompts? Nearly zero will actually consider what is being asked... instead most will just click OK to get rid of the damned box with no comprehension on what was asked or what is happening.
By not having local admin rights, and requiring an actual password be entered for a different account, these home users will be forced to think .1% more than they did before - and some might actually stop before getting themselves infected.
But that's still not the norm for Windows - Windows still builds the first, and generally only, account with local admin rights, so they aren't getting that benefit anyway.
So what situation are you envisioning where this would ever be a real problem for non domain joined machines (domain being either AAD or AD?)
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
@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.
It is possible. I uncovered a few people doing it here at work. It came from some of the Office 365 installs where they were installing various apps on their own like Teams and such. In any other case they are not allowed to install anything on their own and no one except myself and 1 other has local admin rights to anything. So now I worry about some hacker who realizes this about Office365 and tries to phish our users using links that look like O365.
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
Sure, but you just said this is basically in a home user situation
Entirely enterprise, not home use-like at all.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
Sure, but you just said this is basically in a home user situation
Entirely enterprise, not home use-like at all.
You said not MS AD joined at all - so what are they joined to? What's forcing them to have a local admin account? nevermind - that's not really part of this conversation - you're simply stating as a starting point, machines either have or don't have a local admin account, and the user either does or doesn't have local admin access themselves.
got it. -
@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:
@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.
Yes, but only once. And that's all that it takes. Once it gets the rights, it can do unlimited things, for forever. Including installing other things, like ransomware.
-
@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.
No, AV is designed for viruses. Trojans bypass AV by their nature.
My point is that trickery IS what not having local admin rights is all about.
-
@Dashrender 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:
@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.
Yes, and it doesn't auto-start with the computer. Nor does it start as an admin. It's just "the end user starting it when they log in". Not the same at all.
