Administrator Privileges Adjustments

Changes to Software Installation Processes

In balancing ease-of-use with security concerns and compliance with government regulations, the processes by which software downloads are handled and executed have some changes that must be expressed. Firstly, adjustments have been made to comply with new government regulations such as the National Institute of Standards and Technology (NIST) 800-171 Rev. 2. It is also understood that latency from the BPM 12004 process is frustrating, but the legal and fiscal protection that it offers is designed to help you avoid more frustrating issues like software being unusable before purchases have been made. To bring more awareness to the issue of software installation, there is a list of the ways that software installation can be performed detailed below. 

AppsAnywhere allows campus IT to provide self-service delivery and maintain large numbers of software to large numbers of campus managed computers and, when the license allows, to personal computers. Recent changes to the AppsAnywhere application have made it a viable software delivery platform. Starting on January 1, 2024, we will be making changes to the way software is deployed through AppsAnywhere to make it usable offline to accommodate the pivot to laptops use which are frequently impacted by poor network connectivity. If the software does not work as expected or is out of date, reach out to the help desk at it.mst.edu/help-desk. Software is not intended to be offered in a broken state. In some cases, unrealized interactions with other programs or additional features may impact the functionality of the software and will not be discovered until a skilled user encounters it. For much of the software on campus, IT staff does not have the resources to independently discover these advanced issues and require the reporter's knowledge and assistance to find and address them. Please reach out when issues are discovered.

In many cases, software installed only for individuals, and not for everyone on the computer, will not require administrator privileges. As the industry becomes more cybersecurity conscious and realizes the impact cybersecurity has on the customers of their software, more software will provide options like this. Please make sure the software you install in this fashion has been approved by the BPM 12004 process to protect you from litigation from software vendors without the protection of the university or university system.

If you are unsure whether your software has been approved, feel free to contact the IT Software Support team for licensing questions at software@mst.edu and we can help you. Software installed in this fashion will limit IT’s ability to update your software. You may be contacted by IT staff asking you to update software installed in this fashion or to offer help if a known vulnerability is discovered that puts you and the campus at risk for cyber-attack. Some software installed in this fashion may not allow you to uninstall or update the software after installation because of the way it is registered with the operating system, so assistance from IT may be necessary.

IT will address your software installation as promptly as the help queue depth permits, protecting you from exposure to litigation. Allow as much time as possible as the software may have difficult configurations that may require vendor support. In some cases, where the need is a short-term request that is well defined and the software to be installed has been through the BPM 12004 process, IT staff may share an administrator password, which is valid for a limited time, to allow self-installation.

Microsoft provides Local Administrator Password Solution (LAPS) as a means of automatically rotating local administrator passwords to help with pass-the-hash attacks, impede lateral (from computer to computer across the campus network) movement, and to assist with recovering access to a device that is otherwise inaccessible.

S&T implemented LAPS in a way that allows end-users to gain administrator privileges for a limited time as a means of decommissioning the prior practice of granting administrator privileges directly to user accounts and to meet UM System requirements. This method was preferable to a software allow list, which would have a greater negative impact on the campus community, though the tradeoff places the burden of requesting software approvals through the BPM 12004 process on the members of the campus community who have unique software needs. As such, LAPS is not the perfect solution. The automatic rotation of passwords via LAPS helps keep cybersecurity exposure down but this is not really an intended use-case for LAPS and presents various challenges, including the fact that it does not scale well, making it less usable for users needing administrator privileges over more than a couple of systems. We have begun to reduce the use of LAPS in favor of increased IT support for software installation and the other options listed.

In response to the need to have campus community members in research labs perform administrator tasks in the normal course of research and the recognition that LAPS is not the best solution to provide this access, IT will be releasing a new Administrator Delegate Program for campus-managed Windows computers on January 1, 2024. This program's purpose is to partner with a faculty or staff member, usually a member of the research lab, who will function as an IT delegate. As a partner of IT, the delegate will have the same administrator privileges that IT has within their group of computers.

If a user will be delegated as managing a group of computers where the increase in risk is warranted and approved by the responsible parties (usually the Chief Information Officer (CIO) or Information Security Officer (ISO), and the person responsible for the lab), then a special purpose a2 account can be provisioned and administrator privileges granted to that account. This approach allows the systems being managed to be identified as a group rather than as individuals and avoids granting administrator privileges directly to the user’s account.  The a2 accounts must not be used to work around the BPM 12004 procurement process. They must also not be used when accessing email or browsing the internet. Only perform those tasks with accounts that do not have administrator privileges.

This program normally requires a vetting process of users before conferring the grant and the ability to rescind grants when an issue becomes visible. Please be judicious with whom you select to administer your computer.

Use Cases for Administrator Privileges

The only time that a user should have administrator privileges is when there is a business need that is part of their job function. Experience using the LAPS system over the last several years has exposed the following use cases:

  1. “It’s my computer” is an assertion of ownership and not a business use case. As per the UM System Acceptable Use Policy regarding the University Inspection of Personal Electronic Information, all information technology resources, including computer networks, equipment, and connected resources, provided by the University of Missouri are the property of the University. As such, it would be inappropriate to grant administrator privileges based on this justification.
  2. “Installing software” is not normally a part of a job function outside of Information Technology (IT) and not all software installs or updates require administrator privileges. There have certainly been cases where you may have not felt that Information Technology (IT) was meeting this need in a timely fashion and the justification becomes “installing software in accordance with my time schedule.” Granting administrator privileges on this basis makes the user vulnerable to attacks that make use of compromised installers. For example, attackers are known to use search engine poisoning to elevate their compromised installer in search results over the software vendor's site. To mitigate timeliness concerns, please contact IT as soon as possible to give them enough time to install software or work with you and vendors to address issues.
  3. “Updating software” is also not normally a part of a job function outside of Information Technology (IT). Granting administrator privileges on this basis also makes the user vulnerable to attacks that use a malicious updater. Just as internet scams pretending to be for support of victims in the wake of disasters are more common during and after publicized events, so do attacks posing to be updates to address critical update. IT will be updating software in those events from trusted sources while non-IT normally resort to searching for the updater.
  4. “Software requires admin rights” is occasionally encountered. This is usually due to poor programming practices of the vendor which can be addressed by either vendor cooperation or configuration changes, but there are cases where these are unsolvable. Some software requires that the user have administrator privileges. These will need to be addressed on a one-on-one basis and in some cases will require a secure virtual desktop to run the software on that reduces the exposure of the software user to cybersecurity risk. Please reach out to IT to help address these issues.

Most use cases put the campus personnel and system at risk and hinder IT’s ability to protect the campus community and manage campus computer and software. There are cases, however, where a non-IT member of campus has responsibility for systems that are still managed by IT. For example, some software installations are difficult enough that only a practiced user of the software can perform them. IT will need to partner with these non-IT community members to perform the installation and test the software to ensure it is functioning properly (see Administrator Delegate Program above).

Other Notes

It is critical to recognize that there are many Advanced Persistent Threat (APT) groups actively trying to gain control of campus resources, steal intellectual property, and extort money from members of the campus community. It also must be recognized that there has been a rise in successful, damaging ransomware attacks in academic and corporate settings worldwide. Most people assume that by not clicking on a link or attachment in an email will protect them, but your computer is actually vulnerable every time you browse the web. The cross-campus UM System Security Operations Center notes up to two security events daily for every student, staff, and faculty in UM System. Some of them are sophisticated coordinated attacks that have on occasion found some initial success before they were discovered and addressed.

NIST 800-171 will impact all campus computer equipment, the campus network, applications, and services, not just research funded by grants. Failure of the campus to comply within the next two years will result in the loss of Federal money including, but not limited to, grant-funded research and student loan funding. Initially this was managed on a need-to-know basis with faculty who had grants with Controlled Unclassified Information (CUI) requirements, but changes in the Federal funding landscape have made it important to be open about its impact.

The prior practice of granting administrator privileges directly to any user account on request does not align with the best practices of cybersecurity, UM System Information Security Officers' guides, and NIST 800-171 compliance requirements, so it has been discontinued. This practice allowed members of the campus community to have their accounts always have elevated privileges. The danger of this practice becomes evident when phishing attempts are successful and when compromised pirated software is used.

Adjustments are necessary to allow campus community members to still have administrator privileges, but only when necessary. This use of a separate monitored account for administrator activities is the only way to address these concerns. Cybersecurity best practices, NIST 800-171 compliance requirements, and UM System-driven changes to account and system access now require the use of separate logins for administrative privileges for the following reasons:

  • Privilege Separation: Using distinct administrative accounts reduces the risk of unauthorized access and limits the scope of potential breaches.
  • Accountability: Separate logins provide a clear audit trail, making it easier to track actions performed by different administrators, improving accountability and traceability.
  • Password Hygiene: Maintaining separate logins helps to ensure that password policies, such as complexity and rotation, are rigorously followed.
  • Least Privilege Principle: Separate logins allow IT to assign the least privilege necessary to perform specific tasks, reducing the risk of accidental or intentional misuse of privileges.

All licensed software to be installed must be approved by the Office of General Counsel (even if it is free) for use on campus managed systems. The Office of General Counsel is the only entity on campus that can enter into legally binding agreements on behalf of the University of Missouri System. Therefore, installation of any software that has a license agreement without the review and approval of the Office of General Counsel results in the installer personally accepting the legal and fiscal accountability of the software with no protection from Missouri S&T or the University of Missouri System. This exposes you, the installer, to personal litigation from software licensors who practice predatory licensing and actively fish for license violations to litigate.