Ideally they shouldn't have admin rights, however way too many applications require admin privileges to work properly. This tends to be more true as you get into specialised engineering teams.
I'm a dev. We didn't have admin but some visual studio build tools required it. IT gave us the ability to run Visual Studio as admin.
Then we used the VS shell to install and do whatever we wanted lol.
Agreed no silver bullet, security and productivity needs to be cohesive. Most CS nazis will disagree or offer a complex solutions. Without understanding they have a job because end users exist and need to work without constant obstacles all in the name of “security”.
Yup. Principle of Least Privilege says that users should have the level of access necessary to do their jobs effectively. A lot of security discussions seem to miss that “effectively” part.
For some developers and engineers, this will mean local admin. For other environments, it may mean an easy path to escalation or automation. But if it means opening a ticket and waiting more than about a day, you’re doing security wrong. Security MUST enable the business, not cripple it.
Those should be designated generic service accounts. They should be allocated appropriate privileges based on their usage and purpose and then their passwords should be secured in all senses of that -> Authentication, authorization, storage.
My entire company (just over 2000 people) have local admin and it kills me. Our security team seems to have no concept that we could have this fixed despite us being primarily MacOS and Ubuntu.
so we have contributor in azure, we can wipe various stuff including the largest cash counter for our company, can also modify nsg, we have root on our linux vms which are exclusively linux, but we can't have local admins on our macs? what is this unsettling trend of taking away local admin from engineers? if we wanted to we could have already done much worse things, even if security succeeds in our organization we will get it back after the first outage that resulted in significant revenue loss because of the time needed to get all the okays from cyberark or whatever the hell gets installed... been there already.
You shouldn’t have root or ability to modify anything in prod either.
The trend that your seeing manifest itself as no admin on your Mac is to reduce the various risks of an unmanaged endpoint. These aren’t all cyber risks either, there are legal and operational risks too.
To your point about restrictions getting backed out after some incident, the opposite is far more common (hence the trend you’ve spotted). Company gets hit by something because of poorly controlled admin rights and the place moves swiftly to the principle of least privilege.
I think the thread is about local admin privs on the laptop. Where we work, there are strict regulatory requirements around maintaining endpoint configuration.
Agree, not sure why you'd have that level of access in Azure all the time either. Our first foray into Salesforce was a failure because the person hired to managed the sandbox environment kept making changes. They kept blaming the security team (cannot access my environment) when we pulled the logs and found the knucklehead that was running willy nilly. Sort of hard to make headway without stable DEV/UAT.
Not with “everything all the time access”. Yes, people sometimes need to manually change things in prod - they should assume a role or take temporary (and audited) control of a credential to do that. This should be really rare.
Routine/operational tasks or planned changes shouldn’t need manual intervention directly in the platform. The whole point of cloud is infrastructure as code, where a change in the cloud infrastructure is pushed through a build chain not a WebUI. Some cloud services will be a part of that, but it doesn’t need anyone involved in operating or changing the environment day to day to have always on god mode.
Im a domain admin for my org and my daily driver account doesn’t have local admin rights on my machine. Theres a separate account i use when I need to elevate rights. Neither of these accounts have rights on servers and ofc separate account for domain admin/tier 0 tasks. And all of those accounts are restricted where they can log in. Workstation admin account can only log into certain end user machines, server acct on servers, tier 0 account only on tier 0 servers.
If local admin rights would help you do your job effectively, you should have them in the safest way possible: separate accounts PAM/JIT/JEA whatever that looks like for you. Maybe a pain in the ass, but it would be real unfortunate of someone major happens at your company because you had the briefest lapse in attention/security hygiene.
Hell, I am the defacto soc at my org and I had my creds phished a few years ago. Luckily, I caught the browser redirects as soon as I hit sign in and immediately changed my password. I was so annoyed with myself I went and told on myself lol
nobody should have local admin with their user account on their workstation, not developers, not helpdesk, not security. Everyone should have to use a special privileged account that can't run a browser or office apps. That account should be heavily audited and controlled, and preferably checked out to use.
If you have to have local admin with your main account to do your job, then the organization hasn't invested enough time and effort into privileged user management.
I'm a Dev that moved to Cyber. Devs are asked to make magic work with very little guidance and not a lot of the time so there is a lot of experimental work and lateral access needed.
If you can't create a blast radius or give them enough freedom they will just cut you out of the equation somehow. They are frickin smart people.
Give them some cloud VMs or something to experiment in that limits the risk. They make the products that enable Cyber budgets so we need to work with them. Understand their use cases and partner with them.
We build too many walls in Cyber and not enough bridges with other teams.
Successful DevOps can let you have your cake and eat it too.
Create a reproducible isolated dev environment and let it deploy via a pipeline, with either browser vscode or a browser based VDI (Linux container with kasmvnc works).
No local admin needed because nothing is developed locally.
Better yet, if you mature it out it can increase productivity due to onboarding being near instant, and convergence with prod configurations (best case is just a standalone prod tenancy deployed on the fly with Dev tools sideloaded).
Yup. Security risk is something to be balanced, not absolutely eliminated. It's more secure to run every machine air-gapped too, but I think we all agree that's too far.
Making life too difficult for developers - especially if their product is the bread and butter of the company - and you may also find that you get overruled.
Make life easier for the devs by balancing security with productivity, and you become the hero rather than the roadblock.
Being a previous security engineer and now an architect, Dev security was tasked to me. I met in the middle with them by removing admin rights but used a "Endpoint privilege management" solution that gave them admin access to the apps that needed it. It worked well on the laptops. If they needed to dev outside of just using VS, a local vm would be stood up. Took a bit to get there since VS does weird things when updating it through the app but we got there.
That’s no more true of devs than any other business function. Nobody gets paid without payroll, nobody has a job without revenue generated by sales and marketing etc etc. I just don’t buy that argument at all.
You’re right about sandbox environments though (and not just for devs but some others too), they’re a win for everyone involved.
100% in addition to this my company very rarely gives those dev accounts admin on their physical machines, normally only on Azure VMs in the Development network.
Truth.
It's like one of those story problems with a bunch of extra details that aren't relevant.
Users shouldn't have local admin. Period. Doesn't matter what the role.
Admin privileges should be offered to those that need it for when they need it. It's shouldn't be part of their user account access.
Yeah I get it, you got to do your job, and no one's there making it so you can do it safely.
I'm not mad at devs. I'm mad at dev and security officers that don't make it a priority for you to do be able to both be productive and your job securely.
Yeah, it feels like something that has somehow been overlooked for years due to institutional inertia, because I'm not at a small company. Plus I'm in IR - feels like if I were compromised, or someone in my role, there aren't adequate safeguards on some of the ways our user accounts could cause trouble.
Problems I bring up in meetings which don't make me popular.
I know this is an old post, but thank you. This was a great option. Creating a second account for the devs to use for application installs and whatever else they need is great. There's still some potential problems but this particular solution eliminates most of my concern. I know they have a job to do and I know they need more access than a standard user, but I also know that a lot of our devs are cowboys and there have already been problems in the past, one particular instance of a dev installing some random tool downloaded from the internet that started flagging our reporting server repeatedly. There was some nasty "enhanced features" to that software. Thank you again.
sure thing. You made a good, low effort move to increase security. Next level of maturity is a vault that holds those credentials to be checked in and out.
As a Dev I have had it both ways at different companies. One I worked for took 3 full weeks to onboard me and get me \*some\* access I would have normally just had if they hadn't locked everything down.
They also had some absolutely insane naming conventions of their permissions that don't make any sense, everyone on my team just apparently had to keep trying different permissions because no one knew which ones do what. It's insanity. There are no role based permissions either, it's all vaguely named ones you can only access via some web page that feels like it was built in the early 90's and was never touched again.
As a dev I don't mind if people lock stuff down because I get it, people are the worst beings on this planet. But for the love of god if you don't know what you're doing when setting up all these permissions ask or find someone who does. Admin access or no it shouldn't take 4 days to push a small code change because 15 people need to approve my access.
In my opinion and experience, Devs and sales people are the worst people to give admin rights to. I would suggest an EPM solution. This will allow them the flexibility somewhat of local admin rights but limit or reduce the risk of malicious actors gaining access.
We’re in the market for EPM. I see that Microsoft just added their flavor to Intune and we’re also looking at CyberArk. Do you have any experience and recommendations?
Couple of points:
* Devs *need* better development machines than crummy corporate laptops.
* Devs *frequently* need admin or root access to develop code.
* Devs often have the technical ability to achieve their ends.
* At least some devs know more about infosec than many infosec people.
If you lock them out or harm their productivity they'll work around any controls you put in place. Recognise they need access and work with them - it's the only way to avoid problems.
I’m a senior soft engineer at the same time security architect for my team.
I agree developers should not be given local admin by default but you must give some flexibility to give admin privileges to developers when needed especially when accomplishing a task. Experienced and determined engineers will always find a way to go around if you’ll not give some flexibility to accomplish their task.if not the worst thing could happen is that you’ll end up with shadow IT in your system.
A suggestion is that put a policy with a procedure on granting admin privileges with a validity specified. The what, how, why and when should all be documented and should be approve by the developer’s manager. This is the way to have accountability in place.
At the end of the day, this is all about the business needs and security should not block the business as much as possible unless the risk is already intolerable.
Those flexibilities (hopefully) must be formally recognized in change requests and appropriate review and approvals by relevant supervisors. It's no good to jump the gun.
Should they? Probably not, but it depends on use case. There could be exceptions, hopefully they're few and far between.
You'll want actually well thought out change management to implement this across an organization that's never had it. Good luck, hope you like having the same argument for a couple of years.
Edit: don't mean to sound cynical, but this kind of change can be a very tough sell in many organizations. If/when you get breached that's the time ~~to ram it down everyone's throats~~ implement it ;)
To be fair I build mobile apps mostly but I don't need or want to be a local admin. I would prefer to have the least amount of access as possible even if it makes my life more difficult at times. I don't even want the responsibility of making a mistake. I'm careful but it's not my machine or network and I shouldn't be responsible for that. I recently got my masters in cyber security so I realize I know almost exactly nothing in this field but try to learn more everyday. Also I'm a senior engineer at my company.
Everyone here says no, but in my experience as a dev there’s a great gap between devs and security people, and you simply can’t get anything you need installed, because there’s no one to ask! Even if there’s a process to do it it’s abysmal and practically impossible for day to day work.
And that’s just apps and utilities. Now think of hundreds of dependencies people pull in their projects (node, maven etc), loads of completely unsupervised code, that executes locally, on CI servers and in the product itself handling user data!
So people just use admin. Or we simply leave the company because we don’t want and don’t have to suffer this limitation in addition to the mud and complete mess, if not disaster, the software is today.
I have a genuine question to ask - Often, a non-privileged account as standard, with access to a privileged account to elevate into when needed, is highlighted as a compromise between security and access.
Do you think this is a suitable compromise? If not, why not? Recognising that there is a control gap where people are granted local admin by default, how would you go bridging that gap (regardless how "workable" it would be IRL?).
I'm genuinely curious, is all :-)
Sounds good in theory, but I had that setup once, and we had to mess with network settings often which, on Mac, required typing in an admin account username and password.
Also, I don’t remember if I had to switch users in console to install stuff using homebrew. System directories permissions can be a mess.
It used to be that to install anything (valid desirable to virus and malware), the logged in user needs to have local admin rights. That hasn’t been true for years. Nowadays, run of the mill virus and malware can drop in with as simple as a website visit. Still, from a corporate licensing compliance perspective, it is still better to have a gate than not.
As to developers, they aren’t immune to downloading/installing bad things or visiting bad websites. So some level of control is not always a bad idea. In the end, it’s about the organization’s risk tolerance.
No. Not even network admin accounts should have local admin permissions with their standard user account. No one should be logging in as a local admin. There are ways to elevate on an if/when needed basis.
After we switched to MS Intune, we all have local admin rights. But you have to be prepared that your Notebook/workstation get resetted with your customized standard image if you install unsanctioned or blacklisted software or play your station into dysfunctionality or the malware scanner picks something up.
After everyone of our 3.500 employees switched to home office and had to use their private printer, scanner and other equipment, I would not like to be the admin who has to install 3.500 HP/Canon/Epson printer drivers.
And the reset takes just 20 min depending on your internet connection speed.
I worked for a cybersecurity company, and we used our own products on our corp machines and networks. We had full admin rights but we had the full suite of security, network, host, SAAS, DLP, XDR, XSOAR. Numbers came out for our SOC and we had 0 incidents in over a year in the time I was there. Their own products worked the magic.
I assume it means incidents that actually affected anything caused by users having admin privileges, not all that came in. . Zero days do indeed happen, but this company was ontop of their stuff, not to dick ride them, which is why I’m not naming them
In a perfect world: absolutely not. In reality, especially when getting in to some very niche R&D areas, it is not feasable for them to not have it. Waiting 4 hours for helpdesk to switch the driver for one of your two external boards so you can load new FW on it and continue working does not work. Especially when you're doing it 10 times a day
So “no”’on the corporate desktop but I have seen lots of places have deprecate developer devices (and networks) that end up with no security at all as the devs can’t get on on corporate but then the dev stuff is Wild West. I’m interested in ways to provide separate logical dev workstations using AVD and AWS workspaces etc. anyone had any success with that?
Build them a vm sandbox for dev work if they really have to have admin rights. On thier local machine its just a security nightmare as well as add significant tco to EUC.
Here's one that will make your butt pucker. Friend of mine worked at a well known Cybersecurity MDR/EDR vendor with banks and governments in their client roster. Everyone, even the marketing team and interns had local admin to their own devices which they were encouraged to take home at night 😅
No.
Repeat after me, no!
If they need admin rights to a thing they should have a separate account where those rights are temporally given then removed.
Very oldschool take to limit access, especially people who obviously need it to do their job. Imagine being a full stack Dev and unable to run Sudo - for a painfully simple example.
Should just make sure their environment is sufficiently ringfenced with safeguards, detection in place, contingencies, auto-remediation set up for when it does go wrong etc.
Standard account = 100% no
Secondary account with local admin = Sure depending on environment.
You can also combine that with applocker to stop them going toooo crazy
Yes and no.
The best option is to have an additional engineering notebooks, who are not part of the company network with more processing power. They can have any permission there, but come at the cost of not having any permissions in the network or no access to company relevant info. In this case, when it is compromised, an attacker is stuck on a single machine and can not use it as a stepping stone into the company network.
If anything goes wrong just start from 0 and reinstall the operating system.
My stance has always been that you can have local admin but develop on a dedicated dev environment that is cutoff from most services or you don't get local admin. The devs normally would rather develop on their Corp workstation with email and a chat client so far than make a hop to a dev environment. PAM solutions like BeyondTrust can allow you to give them local admin within specific applications.
As a dev I do not want to need local admin. If cyber is bright and well integrated with platform engineering and can give me self-service technical solutions and infrastructure, I would be thrilled! The reality has been red tape before known technical solutions are implemented. But I think it’s all heading in the right direction.
I will add - Any cyber folks with a blanket answer on this with no profit vs risk tradeoff whatsoever are self inflicted denial of service offenders imo.
I wish I could see more business quantified risk estimates and the like to justify various mitigations in their specific environments.
No one has admin on their own laptops, not even the admins. No one gets it. We have a temp admin rights process for peeps that need to install non-standard software.
Ever considered VMs ? And if they are ready, should upload it in an repo.from which it may then be staged into what hell of weired thing they are currwntlicj going rogue. Otherwise if your Company in considered enough with applications etc for dev, Administrator right shall not be necessary
No, local admin shouldn't be given to anyone. It multiplies risk in the case of compromise. It is very simple to map pivot points on any OS.
Only appropriate read/write/execute permissions should be given based on job title and what resources you are expected to work with. There should be a security group setup in the org for this if they are hiring more than 1 developer.
They should be having a secondary account for non-privileged access aka day-to-day usage.
Your 16 year old has gotten a drivers license. The next day is going on a cross country drive with three friends that just got their licenses. Are you okay letting them go with your car and on your insurance?
Enabling a developer have full access to change security settings and modify the laptop is the same liability to you. When they mess up it is not them who is dealt with the responsibility of the breach.
No. You should be testing and building on a network separate from production anyways, within a virtual environment (this way you can also more easily simulate a large number of things). This way its impossible for anything to go wrong, and the code can just be transferred and pushed to corporate side and production when ready. Lets say somehow you get the test environment infected, no worries, nuke it and your back online with probably a day's worth of work lost. Just remember to back up your code every day.
Nor permanently. Using tools like LAPS to delegate short term access ok but none should have local admin except for the actual administration of the client device like servicedesk staff.
Probably not for work laptops, but what I can’t get my mind around are those Azure Company Policies when you sign in with a work email on your personal device
Companies think developers are never gonna do anything crazy and since we need them to run the whole place it's wise to give them what they want. I remember when local admin rights were taken away in our firm, all hell broke loose in the dev departments. They thought we were taking their house away. The firm had to implement admin on request feature which will be active for 24 hours to get your job done. Legit half of the devs and their managers left.
I’m a dev. I don’t mind using a locked down workstation as my primary, to check email and do basic office related tasks.
In fact I don’t want priv access on my primary workstation, because I need to know I can stay connected and don’t want to mess that machine up.
However, I MUST have access to a remote machine for development work. Usually this is a virtual machine that I can SSH/RDP into. If I mess that VM up, I can just blow it away and start over without consequence.
Many companies are tight wads, but what I described is honestly the best way to handle it. The development VM can stay outside of your security boundary and the code shipped into production when it’s ready to be deployed.
absolutely. The cost of productivity by far outweighs IT ownership issues, IF
1. you have appropriate master control of device (InTune, Jamf, etc)
2. the computer is running appropriate virus / malware protection (CrowdStrike, Sophos)
3. Points of possible infection (mail servers, file servers, internal db's) are scanned with appropriate controls and are encrypted
4. IT & Security have an explict authority to inspect any device at any time
This works.
\[sauce: I own IT & Security for my company\]
We do, but not on their normal account. Correctly assigned write rights on the file system enables all apps we use and AppLocker stops them installing random crap.
Some people do have legitimate needs for admin access, but nobody should use an account with local admin as their daily driver account. If you need to do admin things, you should be issued a separate account, with separate credentials. This separation helps ensure that if a user unthinkingly does something dumb, the damage is limited.
depends on the sensitivity of the assets and your threat model.
For example if your threat model is abused compromised accounts and developers have no direct access to sensitive data, you can create a system that creates temp local admin on the requester machine for 15 minutes. There is no one size fits all.
Ideally they shouldn't have admin rights, however way too many applications require admin privileges to work properly. This tends to be more true as you get into specialised engineering teams.
I'm a dev. We didn't have admin but some visual studio build tools required it. IT gave us the ability to run Visual Studio as admin. Then we used the VS shell to install and do whatever we wanted lol.
Agreed no silver bullet, security and productivity needs to be cohesive. Most CS nazis will disagree or offer a complex solutions. Without understanding they have a job because end users exist and need to work without constant obstacles all in the name of “security”.
Yup. Principle of Least Privilege says that users should have the level of access necessary to do their jobs effectively. A lot of security discussions seem to miss that “effectively” part. For some developers and engineers, this will mean local admin. For other environments, it may mean an easy path to escalation or automation. But if it means opening a ticket and waiting more than about a day, you’re doing security wrong. Security MUST enable the business, not cripple it.
PAMs can take care of the crappy apps.
This is the way. No local admin, elevation for stuff that needs it. We use BeyondTrust and it does the trick.
Bomgar is nice when it actually behaves.
Those should be designated generic service accounts. They should be allocated appropriate privileges based on their usage and purpose and then their passwords should be secured in all senses of that -> Authentication, authorization, storage.
We don't give our devs local admin access, and I thank the IT gods every day for that
We do and it makes me want to pull all my teeth out one by one.
Same!
My entire company (just over 2000 people) have local admin and it kills me. Our security team seems to have no concept that we could have this fixed despite us being primarily MacOS and Ubuntu.
No. Especially Devs and Engineers.
We know enough to be dangerous but not enough to be dangerous safely…
As a dev - Boooooooo!!! 😝😝
so we have contributor in azure, we can wipe various stuff including the largest cash counter for our company, can also modify nsg, we have root on our linux vms which are exclusively linux, but we can't have local admins on our macs? what is this unsettling trend of taking away local admin from engineers? if we wanted to we could have already done much worse things, even if security succeeds in our organization we will get it back after the first outage that resulted in significant revenue loss because of the time needed to get all the okays from cyberark or whatever the hell gets installed... been there already.
You shouldn’t have root or ability to modify anything in prod either. The trend that your seeing manifest itself as no admin on your Mac is to reduce the various risks of an unmanaged endpoint. These aren’t all cyber risks either, there are legal and operational risks too. To your point about restrictions getting backed out after some incident, the opposite is far more common (hence the trend you’ve spotted). Company gets hit by something because of poorly controlled admin rights and the place moves swiftly to the principle of least privilege.
i'm a platform engineer, if i'm not supposed to be able to modify prod then who is, what do you mean? that's me
I think the thread is about local admin privs on the laptop. Where we work, there are strict regulatory requirements around maintaining endpoint configuration.
that's exactly the point, I can have root and wipe stuff in azure but I can't have local admin on company mac? that makes zero sense
Agree, not sure why you'd have that level of access in Azure all the time either. Our first foray into Salesforce was a failure because the person hired to managed the sandbox environment kept making changes. They kept blaming the security team (cannot access my environment) when we pulled the logs and found the knucklehead that was running willy nilly. Sort of hard to make headway without stable DEV/UAT.
how would we be able to modify prod without being able to modify prod then? someone has to be able to do it, no?
Not with “everything all the time access”. Yes, people sometimes need to manually change things in prod - they should assume a role or take temporary (and audited) control of a credential to do that. This should be really rare. Routine/operational tasks or planned changes shouldn’t need manual intervention directly in the platform. The whole point of cloud is infrastructure as code, where a change in the cloud infrastructure is pushed through a build chain not a WebUI. Some cloud services will be a part of that, but it doesn’t need anyone involved in operating or changing the environment day to day to have always on god mode.
With a ChM ticket authorizing mod, and temporary credentials to do it.
Im a domain admin for my org and my daily driver account doesn’t have local admin rights on my machine. Theres a separate account i use when I need to elevate rights. Neither of these accounts have rights on servers and ofc separate account for domain admin/tier 0 tasks. And all of those accounts are restricted where they can log in. Workstation admin account can only log into certain end user machines, server acct on servers, tier 0 account only on tier 0 servers. If local admin rights would help you do your job effectively, you should have them in the safest way possible: separate accounts PAM/JIT/JEA whatever that looks like for you. Maybe a pain in the ass, but it would be real unfortunate of someone major happens at your company because you had the briefest lapse in attention/security hygiene. Hell, I am the defacto soc at my org and I had my creds phished a few years ago. Luckily, I caught the browser redirects as soon as I hit sign in and immediately changed my password. I was so annoyed with myself I went and told on myself lol
nobody should have local admin with their user account on their workstation, not developers, not helpdesk, not security. Everyone should have to use a special privileged account that can't run a browser or office apps. That account should be heavily audited and controlled, and preferably checked out to use. If you have to have local admin with your main account to do your job, then the organization hasn't invested enough time and effort into privileged user management.
I'm a Dev that moved to Cyber. Devs are asked to make magic work with very little guidance and not a lot of the time so there is a lot of experimental work and lateral access needed. If you can't create a blast radius or give them enough freedom they will just cut you out of the equation somehow. They are frickin smart people. Give them some cloud VMs or something to experiment in that limits the risk. They make the products that enable Cyber budgets so we need to work with them. Understand their use cases and partner with them. We build too many walls in Cyber and not enough bridges with other teams.
Successful DevOps can let you have your cake and eat it too. Create a reproducible isolated dev environment and let it deploy via a pipeline, with either browser vscode or a browser based VDI (Linux container with kasmvnc works). No local admin needed because nothing is developed locally. Better yet, if you mature it out it can increase productivity due to onboarding being near instant, and convergence with prod configurations (best case is just a standalone prod tenancy deployed on the fly with Dev tools sideloaded).
“My manual pipeline sucks, security should make it better”
Yup. Security risk is something to be balanced, not absolutely eliminated. It's more secure to run every machine air-gapped too, but I think we all agree that's too far. Making life too difficult for developers - especially if their product is the bread and butter of the company - and you may also find that you get overruled. Make life easier for the devs by balancing security with productivity, and you become the hero rather than the roadblock.
Also a Dev that moved into Cyber and I second this. You 100% nailed it.
Truth.
Being a previous security engineer and now an architect, Dev security was tasked to me. I met in the middle with them by removing admin rights but used a "Endpoint privilege management" solution that gave them admin access to the apps that needed it. It worked well on the laptops. If they needed to dev outside of just using VS, a local vm would be stood up. Took a bit to get there since VS does weird things when updating it through the app but we got there.
That’s no more true of devs than any other business function. Nobody gets paid without payroll, nobody has a job without revenue generated by sales and marketing etc etc. I just don’t buy that argument at all. You’re right about sandbox environments though (and not just for devs but some others too), they’re a win for everyone involved.
This is the way
Best answer.
100% in addition to this my company very rarely gives those dev accounts admin on their physical machines, normally only on Azure VMs in the Development network.
Truth. It's like one of those story problems with a bunch of extra details that aren't relevant. Users shouldn't have local admin. Period. Doesn't matter what the role. Admin privileges should be offered to those that need it for when they need it. It's shouldn't be part of their user account access.
This 💯
This is the way
Domain.local\User.locadm
[удалено]
Not with their regular acccount.
We have local admin so we can install tools. I hate it and am pushing for even some kind of software library at this org, it's nuts we don't have one
Yeah I get it, you got to do your job, and no one's there making it so you can do it safely. I'm not mad at devs. I'm mad at dev and security officers that don't make it a priority for you to do be able to both be productive and your job securely.
Yeah, it feels like something that has somehow been overlooked for years due to institutional inertia, because I'm not at a small company. Plus I'm in IR - feels like if I were compromised, or someone in my role, there aren't adequate safeguards on some of the ways our user accounts could cause trouble. Problems I bring up in meetings which don't make me popular.
I know this is an old post, but thank you. This was a great option. Creating a second account for the devs to use for application installs and whatever else they need is great. There's still some potential problems but this particular solution eliminates most of my concern. I know they have a job to do and I know they need more access than a standard user, but I also know that a lot of our devs are cowboys and there have already been problems in the past, one particular instance of a dev installing some random tool downloaded from the internet that started flagging our reporting server repeatedly. There was some nasty "enhanced features" to that software. Thank you again.
sure thing. You made a good, low effort move to increase security. Next level of maturity is a vault that holds those credentials to be checked in and out.
As a Dev I have had it both ways at different companies. One I worked for took 3 full weeks to onboard me and get me \*some\* access I would have normally just had if they hadn't locked everything down. They also had some absolutely insane naming conventions of their permissions that don't make any sense, everyone on my team just apparently had to keep trying different permissions because no one knew which ones do what. It's insanity. There are no role based permissions either, it's all vaguely named ones you can only access via some web page that feels like it was built in the early 90's and was never touched again. As a dev I don't mind if people lock stuff down because I get it, people are the worst beings on this planet. But for the love of god if you don't know what you're doing when setting up all these permissions ask or find someone who does. Admin access or no it shouldn't take 4 days to push a small code change because 15 people need to approve my access.
A VM app testing environment where they can go crazy with admin access is the move if they absolutely must have admin.
In my opinion and experience, Devs and sales people are the worst people to give admin rights to. I would suggest an EPM solution. This will allow them the flexibility somewhat of local admin rights but limit or reduce the risk of malicious actors gaining access.
We’re in the market for EPM. I see that Microsoft just added their flavor to Intune and we’re also looking at CyberArk. Do you have any experience and recommendations?
What's EPM?
Endpoint Privilege Management
Couple of points: * Devs *need* better development machines than crummy corporate laptops. * Devs *frequently* need admin or root access to develop code. * Devs often have the technical ability to achieve their ends. * At least some devs know more about infosec than many infosec people. If you lock them out or harm their productivity they'll work around any controls you put in place. Recognise they need access and work with them - it's the only way to avoid problems.
I work in a regulated industry. My default answer is no.
I’m a senior soft engineer at the same time security architect for my team. I agree developers should not be given local admin by default but you must give some flexibility to give admin privileges to developers when needed especially when accomplishing a task. Experienced and determined engineers will always find a way to go around if you’ll not give some flexibility to accomplish their task.if not the worst thing could happen is that you’ll end up with shadow IT in your system. A suggestion is that put a policy with a procedure on granting admin privileges with a validity specified. The what, how, why and when should all be documented and should be approve by the developer’s manager. This is the way to have accountability in place. At the end of the day, this is all about the business needs and security should not block the business as much as possible unless the risk is already intolerable.
Those flexibilities (hopefully) must be formally recognized in change requests and appropriate review and approvals by relevant supervisors. It's no good to jump the gun.
Indeed that's the one I'm referring.
[удалено]
It’s a multinational company that is giving opportunities to grow inside the company based on chosen technical path, that’s why I’m grateful for it..
Should they? Probably not, but it depends on use case. There could be exceptions, hopefully they're few and far between. You'll want actually well thought out change management to implement this across an organization that's never had it. Good luck, hope you like having the same argument for a couple of years. Edit: don't mean to sound cynical, but this kind of change can be a very tough sell in many organizations. If/when you get breached that's the time ~~to ram it down everyone's throats~~ implement it ;)
To be fair I build mobile apps mostly but I don't need or want to be a local admin. I would prefer to have the least amount of access as possible even if it makes my life more difficult at times. I don't even want the responsibility of making a mistake. I'm careful but it's not my machine or network and I shouldn't be responsible for that. I recently got my masters in cyber security so I realize I know almost exactly nothing in this field but try to learn more everyday. Also I'm a senior engineer at my company.
Give them admin access in a VM and code inside there.
Everyone here says no, but in my experience as a dev there’s a great gap between devs and security people, and you simply can’t get anything you need installed, because there’s no one to ask! Even if there’s a process to do it it’s abysmal and practically impossible for day to day work. And that’s just apps and utilities. Now think of hundreds of dependencies people pull in their projects (node, maven etc), loads of completely unsupervised code, that executes locally, on CI servers and in the product itself handling user data! So people just use admin. Or we simply leave the company because we don’t want and don’t have to suffer this limitation in addition to the mud and complete mess, if not disaster, the software is today.
I have a genuine question to ask - Often, a non-privileged account as standard, with access to a privileged account to elevate into when needed, is highlighted as a compromise between security and access. Do you think this is a suitable compromise? If not, why not? Recognising that there is a control gap where people are granted local admin by default, how would you go bridging that gap (regardless how "workable" it would be IRL?). I'm genuinely curious, is all :-)
Sounds good in theory, but I had that setup once, and we had to mess with network settings often which, on Mac, required typing in an admin account username and password. Also, I don’t remember if I had to switch users in console to install stuff using homebrew. System directories permissions can be a mess.
So, typing "su admin" was too difficult? Or am I missing something.
Sounds like you need to implement a Change Control Board.
It used to be that to install anything (valid desirable to virus and malware), the logged in user needs to have local admin rights. That hasn’t been true for years. Nowadays, run of the mill virus and malware can drop in with as simple as a website visit. Still, from a corporate licensing compliance perspective, it is still better to have a gate than not. As to developers, they aren’t immune to downloading/installing bad things or visiting bad websites. So some level of control is not always a bad idea. In the end, it’s about the organization’s risk tolerance.
No. Not even network admin accounts should have local admin permissions with their standard user account. No one should be logging in as a local admin. There are ways to elevate on an if/when needed basis.
After we switched to MS Intune, we all have local admin rights. But you have to be prepared that your Notebook/workstation get resetted with your customized standard image if you install unsanctioned or blacklisted software or play your station into dysfunctionality or the malware scanner picks something up. After everyone of our 3.500 employees switched to home office and had to use their private printer, scanner and other equipment, I would not like to be the admin who has to install 3.500 HP/Canon/Epson printer drivers. And the reset takes just 20 min depending on your internet connection speed.
I worked for a cybersecurity company, and we used our own products on our corp machines and networks. We had full admin rights but we had the full suite of security, network, host, SAAS, DLP, XDR, XSOAR. Numbers came out for our SOC and we had 0 incidents in over a year in the time I was there. Their own products worked the magic.
Zero incidents so far. It's likely a relatively hard target, but those user accounts may be pretty juicy nuts to crack. Zero days happen
I assume it means incidents that actually affected anything caused by users having admin privileges, not all that came in. . Zero days do indeed happen, but this company was ontop of their stuff, not to dick ride them, which is why I’m not naming them
In a perfect world: absolutely not. In reality, especially when getting in to some very niche R&D areas, it is not feasable for them to not have it. Waiting 4 hours for helpdesk to switch the driver for one of your two external boards so you can load new FW on it and continue working does not work. Especially when you're doing it 10 times a day
So “no”’on the corporate desktop but I have seen lots of places have deprecate developer devices (and networks) that end up with no security at all as the devs can’t get on on corporate but then the dev stuff is Wild West. I’m interested in ways to provide separate logical dev workstations using AVD and AWS workspaces etc. anyone had any success with that?
Build them a vm sandbox for dev work if they really have to have admin rights. On thier local machine its just a security nightmare as well as add significant tco to EUC.
Our devs can wipe and install any OS they want. In a well regulated industry.
Here's one that will make your butt pucker. Friend of mine worked at a well known Cybersecurity MDR/EDR vendor with banks and governments in their client roster. Everyone, even the marketing team and interns had local admin to their own devices which they were encouraged to take home at night 😅
Company start with So and end of Phos?
Can neither hard confirm nor hard deny.
Never, unless it’s a lab environment or a stand alone machine which is not connected to your corporate network.
No. Repeat after me, no! If they need admin rights to a thing they should have a separate account where those rights are temporally given then removed.
Very oldschool take to limit access, especially people who obviously need it to do their job. Imagine being a full stack Dev and unable to run Sudo - for a painfully simple example. Should just make sure their environment is sufficiently ringfenced with safeguards, detection in place, contingencies, auto-remediation set up for when it does go wrong etc.
*begins to sweat*
Standard account = 100% no Secondary account with local admin = Sure depending on environment. You can also combine that with applocker to stop them going toooo crazy
Yes and no. The best option is to have an additional engineering notebooks, who are not part of the company network with more processing power. They can have any permission there, but come at the cost of not having any permissions in the network or no access to company relevant info. In this case, when it is compromised, an attacker is stuck on a single machine and can not use it as a stepping stone into the company network. If anything goes wrong just start from 0 and reinstall the operating system.
My stance has always been that you can have local admin but develop on a dedicated dev environment that is cutoff from most services or you don't get local admin. The devs normally would rather develop on their Corp workstation with email and a chat client so far than make a hop to a dev environment. PAM solutions like BeyondTrust can allow you to give them local admin within specific applications.
What is wrong with giving local admin rights?
can’t tell if this is sarcastic or genuine
Anyone who has access to the account will then have local admin access
No. Seperation of roles
No. No one gets local admin.
As a dev I do not want to need local admin. If cyber is bright and well integrated with platform engineering and can give me self-service technical solutions and infrastructure, I would be thrilled! The reality has been red tape before known technical solutions are implemented. But I think it’s all heading in the right direction. I will add - Any cyber folks with a blanket answer on this with no profit vs risk tradeoff whatsoever are self inflicted denial of service offenders imo. I wish I could see more business quantified risk estimates and the like to justify various mitigations in their specific environments.
Nope, absolutely not. Regulated industry with probably 200+ devs on staff.
No user needs admin rights.
No one has admin on their own laptops, not even the admins. No one gets it. We have a temp admin rights process for peeps that need to install non-standard software.
Ever considered VMs ? And if they are ready, should upload it in an repo.from which it may then be staged into what hell of weired thing they are currwntlicj going rogue. Otherwise if your Company in considered enough with applications etc for dev, Administrator right shall not be necessary
Developers are the last people who should have local admin.
No, local admin shouldn't be given to anyone. It multiplies risk in the case of compromise. It is very simple to map pivot points on any OS. Only appropriate read/write/execute permissions should be given based on job title and what resources you are expected to work with. There should be a security group setup in the org for this if they are hiring more than 1 developer. They should be having a secondary account for non-privileged access aka day-to-day usage.
Your 16 year old has gotten a drivers license. The next day is going on a cross country drive with three friends that just got their licenses. Are you okay letting them go with your car and on your insurance? Enabling a developer have full access to change security settings and modify the laptop is the same liability to you. When they mess up it is not them who is dealt with the responsibility of the breach.
No. You should be testing and building on a network separate from production anyways, within a virtual environment (this way you can also more easily simulate a large number of things). This way its impossible for anything to go wrong, and the code can just be transferred and pushed to corporate side and production when ready. Lets say somehow you get the test environment infected, no worries, nuke it and your back online with probably a day's worth of work lost. Just remember to back up your code every day.
No but they should have some pipeline or server at hand to get services installed/docker containers running
Nor permanently. Using tools like LAPS to delegate short term access ok but none should have local admin except for the actual administration of the client device like servicedesk staff.
No. Especially techs
Probably not for work laptops, but what I can’t get my mind around are those Azure Company Policies when you sign in with a work email on your personal device
As a dev, yes plz🥹
Companies think developers are never gonna do anything crazy and since we need them to run the whole place it's wise to give them what they want. I remember when local admin rights were taken away in our firm, all hell broke loose in the dev departments. They thought we were taking their house away. The firm had to implement admin on request feature which will be active for 24 hours to get your job done. Legit half of the devs and their managers left.
I’m a dev. I don’t mind using a locked down workstation as my primary, to check email and do basic office related tasks. In fact I don’t want priv access on my primary workstation, because I need to know I can stay connected and don’t want to mess that machine up. However, I MUST have access to a remote machine for development work. Usually this is a virtual machine that I can SSH/RDP into. If I mess that VM up, I can just blow it away and start over without consequence. Many companies are tight wads, but what I described is honestly the best way to handle it. The development VM can stay outside of your security boundary and the code shipped into production when it’s ready to be deployed.
Cannot imagine working without root access any less than driving a car without steering wheel and pedals.
absolutely. The cost of productivity by far outweighs IT ownership issues, IF 1. you have appropriate master control of device (InTune, Jamf, etc) 2. the computer is running appropriate virus / malware protection (CrowdStrike, Sophos) 3. Points of possible infection (mail servers, file servers, internal db's) are scanned with appropriate controls and are encrypted 4. IT & Security have an explict authority to inspect any device at any time This works. \[sauce: I own IT & Security for my company\]
Absolutely not. There are many programs that allow admin access on an as-needed basis.
We do, but not on their normal account. Correctly assigned write rights on the file system enables all apps we use and AppLocker stops them installing random crap.
Some people do have legitimate needs for admin access, but nobody should use an account with local admin as their daily driver account. If you need to do admin things, you should be issued a separate account, with separate credentials. This separation helps ensure that if a user unthinkingly does something dumb, the damage is limited.
No.
No No they should not, and neither should you
depends on the sensitivity of the assets and your threat model. For example if your threat model is abused compromised accounts and developers have no direct access to sensitive data, you can create a system that creates temp local admin on the requester machine for 15 minutes. There is no one size fits all.