Assistance: Revocation of Administrator Access Rights - ISO27001 Non-conformance

291 views
Skip to first unread message

Valentine Leamy

unread,
Feb 9, 2024, 9:59:36 AM2/9/24
to ntsys...@googlegroups.com

Questions are asked below:
1. How can we get this done in the shortest possible time
2. Work out a process for Software Installation control for those who are Power Users while introducing as little resource cost to the team
3. Introduce a process of periodic “Least Privilege” audits for users; ensuring access rights are appropriate and in compliance with the standard
4. Why should Programmers get admin privileges? 

Rick McClure

unread,
Feb 9, 2024, 10:34:02 AM2/9/24
to ntsys...@googlegroups.com

Just my 2 cents…..No one should have admin rights….especially programmers.  That way their programs have a higher chance of working in a non-admin user role.

 

Aren’t all the programmers in the same or similar groups?

 

Rick.

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAM04VpUncoewMccRAeG%2BuO0hj%2BmE72MuRYvEZV1NO-qtdW2CQw%40mail.gmail.com.

Valentine Leamy

unread,
Feb 9, 2024, 10:51:35 AM2/9/24
to ntsys...@googlegroups.com

Currently programmers have admin access 

Erik Goldoff

unread,
Feb 9, 2024, 10:59:29 AM2/9/24
to ntsys...@googlegroups.com
sorry, I'm going to skip to #4 since that jumped out at me.  I've fought that battle many times.  Programmers should ONLY get admin privileges in the DEV environment, NEVER in production.  And they should ALWAYS test in DEV with non-admin credentials before promoting to production.

Erik

--

Erik Goldoff

unread,
Feb 9, 2024, 11:00:07 AM2/9/24
to ntsys...@googlegroups.com

Michael B. Smith

unread,
Feb 9, 2024, 11:04:12 AM2/9/24
to ntsys...@googlegroups.com

Why?

 

They shouldn’t. Except in dev, maybe. Even that is questionable. Delegate installation rights and configuration right and that’s all.

Kurt Buff

unread,
Feb 9, 2024, 12:10:35 PM2/9/24
to ntsys...@googlegroups.com
I agree.

However, that requires separate workstations for programming and
standard user activities (web browsing, email, document creation,
etc.), and that's often a tough battle to win. Certainly, I have never
won that battle.

Kurt
> To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/2d154d912e4e46f6810e31f86f987ee6%40smithcons.com.

Matt Stork

unread,
Feb 9, 2024, 12:25:49 PM2/9/24
to ntsys...@googlegroups.com

Is this about what rights developers have on their workstation or on servers? Two completely different scenarios with often very different answers depending on role responsibilities.

 

In my mind, there is also a difference between having administrative rights and the “daily driver” user account having administrative rights. I try to keep it so that the account a person logs in with interactively to a workstation is a standard user account. If necessary, the individual has a separate account that has administrative rights that is only used to elevate a process when needed, almost never used to log in interactively with. This is all end user devices. Servers are different for me. You either log in interactively (RDP or SSH) with administrative rights or you can’t log in interactively at all. This is all a time/energy/value add for my little corner of the universe, others will be different.

-Matt

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Erik Goldoff
Sent: Friday, February 9, 2024 9:59 AM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] Assistance: Revocation of Administrator Access Rights - ISO27001 Non-conformance

 

sorry, I'm going to skip to #4 since that jumped out at me.  I've fought that battle many times.  Programmers should ONLY get admin privileges in the DEV environment, NEVER in production.  And they should ALWAYS test in DEV with non-admin credentials before promoting to production.

 

Erik

Erik Goldoff

unread,
Feb 9, 2024, 12:32:55 PM2/9/24
to ntsys...@googlegroups.com
still, why should a Programmer ever have administrative rights on any production system?

Matt Stork

unread,
Feb 9, 2024, 3:08:01 PM2/9/24
to ntsys...@googlegroups.com
Too small to have the delegation responsibilities?

-----Original Message-----
From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Erik Goldoff
Sent: Friday, February 9, 2024 11:32 AM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] Assistance: Revocation of Administrator Access Rights - ISO27001 Non-conformance

still, why should a Programmer ever have administrative rights on any production system?

On Fri, Feb 9, 2024 at 12:25 PM Matt Stork <mst...@northwestern.edu <mailto:mst...@northwestern.edu> > wrote:


Is this about what rights developers have on their workstation or on servers? Two completely different scenarios with often very different answers depending on role responsibilities.



In my mind, there is also a difference between having administrative rights and the “daily driver” user account having administrative rights. I try to keep it so that the account a person logs in with interactively to a workstation is a standard user account. If necessary, the individual has a separate account that has administrative rights that is only used to elevate a process when needed, almost never used to log in interactively with. This is all end user devices. Servers are different for me. You either log in interactively (RDP or SSH) with administrative rights or you can’t log in interactively at all. This is all a time/energy/value add for my little corner of the universe, others will be different.

-Matt



From: ntsys...@googlegroups.com <mailto:ntsys...@googlegroups.com> <ntsys...@googlegroups.com <mailto:ntsys...@googlegroups.com> > On Behalf Of Erik Goldoff
Sent: Friday, February 9, 2024 9:59 AM
To: ntsys...@googlegroups.com <mailto:ntsys...@googlegroups.com>
Subject: Re: [ntsysadmin] Assistance: Revocation of Administrator Access Rights - ISO27001 Non-conformance



sorry, I'm going to skip to #4 since that jumped out at me. I've fought that battle many times. Programmers should ONLY get admin privileges in the DEV environment, NEVER in production. And they should ALWAYS test in DEV with non-admin credentials before promoting to production.



Erik



On Fri, Feb 9, 2024 at 9:59 AM Valentine Leamy <valenti...@gmail.com <mailto:valenti...@gmail.com> > wrote:



Questions are asked below:

1. How can we get this done in the shortest possible time
2. Work out a process for Software Installation control for those who are Power Users while introducing as little resource cost to the team
3. Introduce a process of periodic “Least Privilege” audits for users; ensuring access rights are appropriate and in compliance with the standard

4. Why should Programmers get admin privileges?

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com <mailto:ntsysadmin+...@googlegroups.com> .
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAM04VpUncoewMccRAeG%2BuO0hj%2BmE72MuRYvEZV1NO-qtdW2CQw%40mail.gmail.com <https://urldefense.com/v3/__https:/groups.google.com/d/msgid/ntsysadmin/CAM04VpUncoewMccRAeG*2BuO0hj*2BmE72MuRYvEZV1NO-qtdW2CQw*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUl!!Dq0X2DkFhyF93HkjWTBQKhk!TCRrdYeq4aEa37srq-EwzUhBXRtfMVYzBxx-we4O1zekAITVbsay1C9bLv3LJM3Nyu8GDpIF_tapUO9_GpHUfQ$> .

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com <mailto:ntsysadmin+...@googlegroups.com> .
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAGMVfXTKzKoMLmpYUkfaAknXVnHdck3WMyHXXJMs0i7HJZkLEw%40mail.gmail.com <https://urldefense.com/v3/__https:/groups.google.com/d/msgid/ntsysadmin/CAGMVfXTKzKoMLmpYUkfaAknXVnHdck3WMyHXXJMs0i7HJZkLEw*40mail.gmail.com?utm_medium=email&utm_source=footer__;JQ!!Dq0X2DkFhyF93HkjWTBQKhk!TCRrdYeq4aEa37srq-EwzUhBXRtfMVYzBxx-we4O1zekAITVbsay1C9bLv3LJM3Nyu8GDpIF_tapUO_wWYavXA$> .



--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com <mailto:ntsysadmin+...@googlegroups.com> .
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/SN7PR05MB9985A1DE438359FFB78BB6C6BF4B2%40SN7PR05MB9985.namprd05.prod.outlook.com <https://urldefense.com/v3/__https://groups.google.com/d/msgid/ntsysadmin/SN7PR05MB9985A1DE438359FFB78BB6C6BF4B2*40SN7PR05MB9985.namprd05.prod.outlook.com?utm_medium=email&utm_source=footer__;JQ!!Dq0X2DkFhyF93HkjWTBQKhk!W5aio0KmnGZtqxS67L5vXwLwLTQMDRbfngkcXlZy0RRcQ2C9_v7sVaVM9TdlEsCRWM3bIbLT3StDzyRibNe_sg$> .


--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com <mailto:ntsysadmin+...@googlegroups.com> .
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAGMVfXSATk2NkhO9MWBCAVVkXjys3B6y0MMeBWtGLs76Vpnv0w%40mail.gmail.com <https://urldefense.com/v3/__https://groups.google.com/d/msgid/ntsysadmin/CAGMVfXSATk2NkhO9MWBCAVVkXjys3B6y0MMeBWtGLs76Vpnv0w*40mail.gmail.com?utm_medium=email&utm_source=footer__;JQ!!Dq0X2DkFhyF93HkjWTBQKhk!W5aio0KmnGZtqxS67L5vXwLwLTQMDRbfngkcXlZy0RRcQ2C9_v7sVaVM9TdlEsCRWM3bIbLT3StDzyQ-p8wRcw$> .

Erik Goldoff

unread,
Feb 9, 2024, 3:22:21 PM2/9/24
to ntsys...@googlegroups.com
BZZZZZ!   

Try again.  In production, programmers are just standard users, following best practice (concept of least privilege).  There should be nothing they need to do with administrative privilege in production.  'should' being the operative word.



To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/SN7PR05MB9985509DCA4D2009AA7533CFBF4B2%40SN7PR05MB9985.namprd05.prod.outlook.com.

Heaton, Joseph@Wildlife

unread,
Feb 13, 2024, 10:21:55 AM2/13/24
to ntsys...@googlegroups.com

Currently, we have a privilege management software that allows our developers to pretty much do anything on their local workstations. This allows auditing trails, etc.  The reasoning is that they are “constantly” installing/uninstalling different programming tools, etc. Our ISO office is working on breaking this tradition, as well as getting rid of the privilege management software.

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Erik Goldoff
Sent: Friday, February 9, 2024 9:32 AM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] Assistance: Revocation of Administrator Access Rights - ISO27001 Non-conformance

 

You don't often get email from egol...@gmail.com. Learn why this is important

WARNING: This message is from an external source. Verify the sender and exercise caution when clicking links or opening attachments.

 

Jim Kennedy

unread,
Feb 13, 2024, 2:21:32 PM2/13/24
to ntsys...@googlegroups.com

Y’all need separate dev environments. Be it another box, cloud, isolated network…..that is the only way to fully skin this cat. No offense to cats, I love them and have two.

 

Our devs do their ‘office’ stuff on a Mac. All dev work is done on System 76 Nix boxes on an isolated vlan. They sometimes have to jump through some hoops, but they get over it and IT adjusts when and where they can to accommodate them.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/SJ0PR09MB6686EDCA4EA6BD1738527A71AA4F2%40SJ0PR09MB6686.namprd09.prod.outlook.com.

CAUTION: This email originated from outside of the organization. Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Erik Goldoff

unread,
Feb 13, 2024, 2:30:00 PM2/13/24
to ntsys...@googlegroups.com
100% agree... application development should be done in a development environment, not on systems within the production environment.  It is a unique use-case and VDI and jump boxes can assist depending on the environment design

Kurt Buff

unread,
Feb 13, 2024, 2:42:40 PM2/13/24
to ntsys...@googlegroups.com
I agree, and just wish I could make that case effectively enough to convince the devs.

Kurt

Melvin Backus

unread,
Feb 13, 2024, 2:47:16 PM2/13/24
to ntsys...@googlegroups.com

The devs are not the people you need to convince. Upper management should be pushing that down to them so they’re your target audience. If they won’t reign them in then you’re wasting your time and effort.

 

--
There are 10 kinds of people in the world...
         those who understand binary and those who don't.

 

¯\_()_/¯

Kurt Buff

unread,
Feb 13, 2024, 3:07:37 PM2/13/24
to ntsys...@googlegroups.com
Agreed, but management said, in effect: "If he can't convince you, you don't have to do it."

Kurt

Melvin Backus

unread,
Feb 14, 2024, 7:49:46 AM2/14/24
to ntsys...@googlegroups.com

Then you’re basically SOL. Been there. Still there. It sucks but the best you can probably do at this point is make sure that they are restricted everywhere else except their machine. I do like the option that someone else mentioned about them having a separate account for admin access even to that machine. It keeps stupid things from happening and they have to actively make that level of access available.

Heaton, Joseph@Wildlife

unread,
Feb 14, 2024, 9:48:13 AM2/14/24
to ntsys...@googlegroups.com

I’m not arguing that point. Obviously on the server side, we have 3 tiers, but we’ve never done anything like that on the endpoint side. Why *nix systems? I won’t touch the Mac situation, to each their own. We’re a full blown .NET development side. Probably showing my ignorance, but can you do Visual Studio, and Microsoft tools on a *nix system? Was the OS decision a security based one? How do you do patching for these systems? Are they setup to go out themselves to check for updates/patches, or do you control that centrally?

 

From: 'Jim Kennedy' via ntsysadmin <ntsys...@googlegroups.com>
Sent: Tuesday, February 13, 2024 11:21 AM
To: ntsys...@googlegroups.com
Subject: RE: [External] [ntsysadmin] Assistance: Revocation of Administrator Access Rights - ISO27001 Non-conformance

 

WARNING: This message is from an external source. Verify the sender and exercise caution when clicking links or opening attachments.

 

Tony Burrows

unread,
Feb 14, 2024, 10:53:52 AM2/14/24
to ntsys...@googlegroups.com
Everyone is focusing on item #4 and I agree with most of what people are saying so I'll focus on the other 3 points.

The way I've typically handled the stripping / managing of local admin rights is with PowerShell scripts, GPOs, AD security groups, and LAPS.

I have a PowerShell script that creates a security group for each computer object and validates that each security group has a computer object. If there's a security group but no computer object, it removes the group and if there's a computer object but no security group, it creates the group. This keeps the groups up to date as computers are added/removed from the environment. I have separate scripts for member servers and member workstations with the only difference being the targeted OUs and initial Get-AdComputer filter.

This ties in with the respective GPOs (1 for member servers, 1 for member workstations) that are linked to their respective OUs. The only difference between the GPOs is the member workstations group strips out all the objects from the local admins group and rebuilds it whereas the servers GPO keeps these objects. I have another PowerShell script that regularly audits the servers so I can review the logs to see if/when something changed. The computer specific groups are added to the local admins group via the GPO using domain\WS-%computername%-Admins or domain\SVR-%computername%-Admins in the GPO in Preferences > Control Panel Settings >Local Users & Groups.

There's also a Workstations Admins group and a Server Admins group. These groups are added to the aforementioned respective GPOs so help desk and server admins can be granted access to all the workstations or servers in 1 group. 

This allows for a 4 tier least privilege setup where you have standard user, workstation admin, server admin, domain admin. It also allows for granular control over the departmental admins where another group is created (i.e., Finance admins or dev admins). This allows for the respective local talent to have access to the computers / servers their job requires but nothing more.

The default admin account is disabled on everything and LAPS is configured to change a failsafe workstation and server account every 6 days with a 20 character strong password. This account is only used in rare instances like when a system loses its domain trust relationship.

Do NOT tie anything mentioned so far to the Domain Controllers OU unless you want a really bad day trying to recover your domain.

For software deployment, I've moved all my environments over to Action1 (no affiliation, just really like the product). They offer 100 endpoints for free and only change for endpoints beyond this number. I gave them a try for a year and just renewed for 3 more years. I've used this tool to replace our WSUS and 3rd party patching solutions, and it is very easy to package custom installers. They don't currently have a way to have users request software to be installed on their own machines but it is on their roadmap. A1 also does some vulnerability scanning and they have a monthly vulnerability digest webinar where they cover the patch Tuesday patches from most vendors. As far as I'm aware, you only need an account with them (including their free accounts) to get access to these webinars. A1 isn't perfect but they do take feedback seriously and in the year I've been with them, they've grown a LOT.

For auditing, you probably guessed already but I use PowerShell scripts & scheduled tasks to email reports. This part needs some work since it does require manual review and I recognize this is only a stopgap solution until I have the time to tweak the emailed reports to programmatically compare the current report against the previous report and only email the differences. It's in the works, but time is currently limited. I have it on my list to implement a SIEM solution of some type later this year and will replace most of my auditing scripts. Specifically I have 5 scripts that run a few times a day. 1) List all security groups and their members. 2) List all user accounts and important attributes (this is for DR in case we ever need to recover without backups). 3) List all key event IDs from all DCs. This list consists of login failures, services installed/removed, MCAD's for user, group, and computer objects, user lockouts, etc..4) This one is a subset of #1 and only covers groups with the name "*admin*" in it and it filters out groups without members since most of the computer specific admin groups are empty. 5) List all the members of the local admins for all online member servers.

Regards,
Tony


Reply all
Reply to author
Forward
0 new messages