Introduction
Over the last few years, I’ve had several conversations with clients and their IT personnel about how different technical solutions, architecture designs, and decisions would impact them were they to go through an assessment (JSVA up to this point) with such an approach. A recurring theme from many of these conversations is that clients and their staff are wondering about how much of their current convenience can be retained while also still being able to pass muster for the assessment – very reminiscent of the ole’ Jef Raskin quote “What users want is convenience and results”.
By no means is convenience a bad thing. Of course, we don’t set out in our careers to make other people’s lives harder, especially when it comes to implementing the NIST SP 800-171 requirements for an organization’s upcoming CMMC and DFARS obligations. We know the pain of implementors, staff, and leadership to get this done and we certainly don’t want to increase their level of effort to take on this huge feat. However, we do also live in a real-world, with objective truth and with cybersecurity requirements that set pretty firm precedence which can impact the convenient workflows of users, and we want to inform organizations as best as possible.
So, for your convenience, I’d like to address one of the frequently asked questions from organizations in the Defense Industrial Base trying to figure out how to address a particularly common scenario. This concept is one that, for many organizations, is deeply embedded in their culture so I shall do my best to be as nuanced and helpful as possible. The scenario I’m referring to (as you’ve probably guessed from the title) is the implications of granting local administration to non-privileged users as a standard privilege across the board.
My goal is to provide some experience-based reasoning as to why we at IntelliGRC advise against such a practice, if possible, but also to provide some guidance and points of consideration if such a practice is an absolute must for your organization. I think it’d be prudent to provide my concerns regarding Local Administrators for each relevant CMMC/NIST 800-171 requirement that I think is affected by standard user local administrator assignment; but first, some background.
Background
Local administrator group membership on end user workstations (Administrators group in Computer management on Windows 10/11, the “Allow user to administer this computer” checkbox for macOS, Sudo rights in Linux, etc.) is a topic that has had great amounts of discussion already so I’m not going to rehash the high-level talking points that many have already been harping on (rightfully so). I’m also going to acknowledge here and now that the DoD has partially already addressed this concern in a limited sort of sense in the DoD Procurement Toolbox Cybersecurity FAQ found here: DoD Procurement Toolbox. In the FAQ the following question is asked:
“Q73: Security Requirement 3.1.7 and 3.5.3 – If regular users’ computer accounts are “administrator accounts” or have ‘limited administrative rights” only on their computers, are they considered a “privileged account” requiring audit for privileged functions (3.1.7) or requiring multifactor authentication (3.5.3) at the “local access level”?”
To which the DoD responds with the following:
“A73: No. NIST SP 800-171 defines a “privileged user” as “a user that is authorized (and therefore, trusted) to perform security-relevant functions that ordinary users are not authorized to perform.” Since, in this case, the ‘ordinary users’ are authorized to perform the function, they are not considered privileged users.”
Well, that was easy. We’ve got all the answers we need, right? Wrong. There’s a major problem with dropping the discussion about local administrator access/privilege based on this response as it is only addressing two requirements: 3.1.7 and 3.5.3. There are still many other requirements that must be considered to address this common architectural design decision.
NOTE: Many organizations, especially ones, whose IT shops utilize Microsoft Entra ID-join and Intune for Access Control and Authorization on the endpoints will have a technical struggle since the user who joins a Windows workstation to the tenant is, by default, made the local administrator on the device. Therefore, this scenario may be much more widespread than you might think. Fortunately, there are some configurations within Microsoft Entra ID and Intune to help mitigate this default behavior (Intune Autopilot OOBE, Device Enrollment Managers, etc.).
A Drove and a Half
There are a lot of security requirements from NIST SP 800-171 that could be secondarily or tertiarily affected by the implementation of standard access to local administration. I think it would be much more valuable to go over the controls that, I believe, are directly impacted and provide my concern as well as a suggested remedy for that particular control where possible. There are quite a few, so buckle up for a bit of a ride!
NOTE: Part of my concerns are more pragmatic in the sense that I think that, while it’s not a direct violation of any particular control, standard user access to local administration does have implications that could cause an assessor to ask MORE questions and not LESS. We at IntelliGRC are of the approach that, when implementing a governance strategy and program, we want to do things that will bolster confidence in the assessor and not introduce unnecessary complexities that the assessors will have to wade through to feel comfortable considering a requirement as “MET” since that inevitably causes reluctancy for more than just the particular requirement at hand. So, please keep that in mind as you peruse through my reasoning here.
3.1.2 – Transaction & Function Control
When defining the types of transactions and functions users are authorized to perform in your governance documentation to satisfy this requirement, a crucial element of that is being thorough. You would need to defend workstation-based administrator privileges being defined as standard user transactions and functions and it would depend on the implementation of limitations of privileges such as software installation and viewing/editing security relevant information (i.e., event logs) by local admins. Additionally, you would have to do this in a way that allows actual defined “privileged users”, such as IT administrators, to do things that standard users with local admin privileges are not able to do. This is challenging since local administrators, by default, practically have free rain. They can edit registry key values, NTFS permissions on the local storage, change local security policy settings, uninstall or manipulate essential software, add or edit Windows firewall rules, and so much more. Policies and procedures for end user behavior and sanctions would need to be stringent and responsible staff would need to be extremely diligent to review and report violations of such policies.
3.1.4 – Separation Of Duties / 3.3.8 – Audit Protection / 3.3.9 – Audit Management
This scenario would make it challenging to enforce and improve separation of duties regarding the management of audit logging information and mechanisms on the endpoints themselves. By default, local administrators have unfettered access to edit, delete, view, etc. the local logging events within Windows Event Viewer and the respective repository. One way this could be mitigated is if the SIEM solution and agent software being used is configured to immediately forward all logs to the central repo for the SIEM to ensure those logs are protected if a local admin wanted to delete them. You would also need to ensure that your policies allow for the local admin to interact with logs within the Event Viewer as a means to satisfy the “unauthorized access, modification, and deletion” portion of the 3.3.8 requirement. Local admins are also able to edit the local configurations regarding what types of events are captured. Therefore, you would need procedures to monitor for changes there as well. Don’t get me started on what could happen to logs while the device isn’t on the internet where such monitoring and log forwarding would be on standby.
3.1.5 – Least Privilege
To ensure that there is no confusion with the assessor and violation of this requirement, local admins could not show up anywhere as a privileged account type and local administration of a workstation could not be identified as a security function. This could be tricky seeing that the installation of software and other local admin capabilities are some of the many functions that are generally understood to be a security function in the wild.
3.1.6 – Non-Privileged Account Use
In light the “non-privileged account use” requirement, local administration privileges (with the exception of what would be limited to comply with other controls) of user assigned workstations would probably need to clearly be spelled out as “non-security functions” and to perform those functions, users could not use their admin accounts (if applicable). This could be weird to document since there are times where an SA account may need to be used to do something that could then be considered to be a “non-security function”. If local administration capabilities are considered “non-security functions” (which could work) then SA accounts would not be allowed to do that per policy on the user’s machines. It could open the door to regular violations of policy and the subsequent ramifications (i.e., incident response, user sanctions, etc.) Good user training refreshers and monitoring is the main mitigation for this concern.
3.1.7 – Privileged Functions
Organizational policies and procedures would have to ensure that the definition of “privileged functions” doesn’t include any reference to the applicable local admin capabilities on a user’s assigned workstation. You’d also have to explicitly define “non-privileged users” (per objective [b]) partly as users that have local administrator permissions on their assigned workstation.
3.1.15 – Privileged Remote Access
There could be a conflict about the definition of “privileged commands” here if you are saying that local administrator functionality is not considered “privileged”. Many of the types of commands an assessor would expect to see would fall under the capabilities a local admin would have, just performed remotely. This could raise more questions for the assessor (remember, this is what we don’t want to have happen; we want them to ask less questions because they’re confident in what you’ve implemented). Just be careful about how you define the privileged commands and security-relevant information that are authorized to be executed or accessed remotely, in keeping with the previously mentioned requirements.
3.2.2 – Role-Based Training
Another thing to keep track of is the definition of “information-security related duties, roles, and responsibilities”. You’d need to make sure it is consistent with all the documentation for the other controls mentioned. It may be a pretty simple concept but with the vast array of documentation that often comes into play, consolidation and synthesis of documentation that references these topics is a must.
3.4.5 – Access Restrictions for Change
You’d have to be careful about what physical and logical access restrictions you define for changes to the system, and you would have to have a way to restrict or at least prohibit standard users from making changes to their workstations and rigorously monitor actions by the user that would violate the configuration baselines for workstations (i.e., local security policy changes, removing the EDR/Antivirus, changing the NTP configurations, etc.)
3.4.6 – Least Functionality / 3.4.7 – Nonessential Functionality
You would have to ensure all such standard users, via acceptable usage policy documentation, were made aware of all capabilities, programs, functions, ports, protocols, and services that are considered “essential” and what the definition of “the use of nonessential programs, functions, ports, protocols, and services” would be. Then, the policy(s) would need to instruct those users on the prohibitions and restrictions of installing, enabling, or executing any capability, program, function, port, protocol, and/or service that are not considered to be essential aspects of their user workstation. It would also be wise to set up SIEM monitoring rules to look out for those types of activities since local admins would have the privilege to execute such items unless otherwise restricted. Don’t forget that technical restrictions to limit local administrators could also limit your actual IT department from being able to do their job!
3.4.8 – Application Execution Policy / 3.4.9 – User-Installed Software
You would either have to implement a solution that binds local admins from installing unauthorized applications (applications not on the whitelist or on the blacklist) OR an explicit policy the prohibits the installation and execution of unauthorized software accordingly with rigorous monitoring for violations.
NOTE: as stated before, technical limitations on local admins could cause issues for actual privileged users (i.e., system administrators remotely troubleshooting end-user issues) who do need to perform such actions. This is something very important to keep in mind if you take the approach of trying to technically limit local admins.
3.7.2 – System Maintenance Control
Unless you prohibit the standard user from performing certain activities that could be considered “Maintenance-related” via policy and monitor it, you would need to ensure your organization’s maintenance policies and/or procedures identify standard users as one of the means of maintenance for user assigned workstations since local admins may be able to install patches or troubleshoot issues locally. Maintenance activities must be logically controlled so it’s imperative this is documented accurately.
3.9.2 – Personnel Actions
Regarding the period around a user’s termination, I could see an assessor having concerns about the system being protected if standard users are local administrators with cached credentials and work remotely. A user with local administrator rights could hypothetically disconnect their device from the internet to prevent any synchronization and subsequent account locking/restrictions to access the local storage of the machine and exfiltrate data. Termination policies, procedures, and legal sanctions are the main mitigations for this concern.
3.13.2 – Security Engineering
Some assessors may not approve of the idea of all standard users being given local admin and may believe it’s a violation of certain best practices when engineering and architecting a system. Now of course, per NIST SP 800-171, you get to define these principles and best practices for yourself [a-c] and the DoD FAQ that I previously mentioned gives us some precedence, but, again, we want to do things that are going to make the assessor ask less questions; not more.
3.13.3 – Role Separation
You would have to clearly define user functionality and system management functionality in light of standard users having local admin privileged on their workstations. Then you would have to be ready to defend your definitions with an assessor who might think that certain local administrator privileges should be considered “system management functionality” when you’re defining it as “user functionality”. Just be clear and thorough when documenting your organization’s position on these things in policy and in your System Security Plan.
3.13.4 – Shared Resource Control
With standard users being given local admin privileges, you would have to ensure that media sanitization procedures were strictly enforced requiring workstation storage to be wiped/scrubbed every time the workstation would change hands due to something like a termination or equipment upgrade since local admins can grant themselves NTFS permissions to user profiles other than their own. If there are residual user profiles under the C: drive on their assigned workstation, this could lead to a user having unauthorized access to data. Fortunately, if you’ve already implemented procedures for media sanitization before media reuse in the system, then you’ve hopefully accounted for user workstations before being given to another employee. Just double-check for me, OK?
3.13.6 – Network Communication by Exception
You would have to ensure that local admins are prohibited from changing the local firewall rules/configurations that would be used to implement this requirement. It’d probably be best to have an alert sent to the IT/InfoSec team if a user changed a windows firewall rule which would initiate an incident response. Keep in mind that, depending on the scenario, this could be a headache if you’re in a situation that calls for them to make this type of change (i.e., a developer that needs to make a quick change to test something on their machine.) It may be necessary to create a separate VLAN for such testing and the scenario would probably need to be documented. The risk would also need to be addressed in your risk assessment. The user would also probably need to be instructed via training and policy on the explicit allowances for such a use case and that they would need to revert it back to the proper configuration immediately when testing is done. I do NOT recommend this be allowed. I’m simply providing a possible route to address the control while also understanding that some circumstances may necessitate an alternative approach.
3.13.13 – Mobile Code
You will need to ensure that standard users with local admin would still be restricted to only using programming languages or executing certain approved scripts and mobile code. This would probably need to be yet another explicit policy prohibition with rigorous monitoring. Thankfully, tools like Microsoft Defender for Endpoint and other EDR/XDR solutions can monitor and provide protections for these situations a lot of the time.
3.14.7 – Identify Unauthorized Use
In the proper policy, you would need to make sure that “authorized use of the system” is defined to clearly outline what even local admins can and cannot do. You would also want to make sure your security technology stack has alerts setup when unauthorized actions are taken by users and notify the IT department/security team accordingly. This would include unauthorized actions performed as a local admin.
Conclusion
Local administration can be a huge convenience for the workflow of software development shops and other similar organizations the depend on everyday users being able to perform some of those more integral tasks on the operating system. I, by no means, am disparaging organizations for seeing this as a crucial element of their business. My goal here was to outline, at least to best of my ability, the governance cost that is accrued when taking this approach. We at IntelliGRC do not generally recommend that organizations allow standard users to have local administration privileges due to the inflated level of effort it takes to truly implement the necessary security measures against them. However, we also acknowledge that this is doable. Just because something is tough doesn’t mean that it can’t be done. We’re always excited to collaborate and hit the whiteboard to come up with solutions to complex problems and scenarios.
If you ever need help working through situations like this one, please don’t hesitate to reach out to me or my team. We always will do our best to assist our clients reach their goals in an efficient, cost effective, and informed way. Until next time!
