Removing user admin rights increases security — and user uproar. "Make Me Admin" offers one solution.
"Any society that would give up a little liberty to gain a little security will deserve neither and lose both." — Benjamin Franklin, 1738
Giving administrator rights to computer end users was once a common practice, but it has all but disappeared in corporate America. As companies embrace the least-privilege model of information security, most employees interact with corporate computer systems with user-level access in tightly controlled software environments. In higher education, information security standards have historically been much looser. Universities, the birthplace of modern interconnected networks, were designed around the free flow of data to share knowledge with all willing parties. Ideals of information freedom and communities of trust continue to influence network security policies at many universities today. Unfortunately, the cybersecurity threats faced by higher education mandate a new approach to this issue.
Here, we discuss the results of a recent survey, which shows that many higher ed institutions still routinely grant admin rights to their users; it also demonstrates that IT staff are concerned that faculty and staff will push back against any strengthening of the policy. We describe a new solution that improves security while also respecting the needs of staff and faculty: Make Me Admin, an open-source software solution that offers users temporary admin rights and thereby reduces the security risks. We also examine a semester-long data gathering exercise to determine how often and why elevated rights are required in a higher ed environment.
Higher Education Under Fire
According to Symantec's 2017 Internet Security Threat Report, 2016 marked the first year that higher education has been among the top three targets by number of cybersecurity incidents. Higher education is an attractive target for several key reasons:
- It is a vast repository for research data that can be lucrative to criminal or government-sponsored attacks.
- It stores personally identifiable information (PII), health, and financial data on thousands of students and employees.
- Its large, connected networks are ideal launching points for distributed denial-of-service attacks.
- Campuses typically have lower institutional control of networks and a higher ratio of bring-your-own-device environments.
Still, many people in higher education fail to understand the gravity of the threat.
Why Would They Attack My Machine?
The idea that higher education users are unlikely targets because they have nothing of value is born of misperception. The unfortunate truth is that the principle of lateral movement makes every node on a network a potential avenue for attack.
Although many faculty members never interact with sensitive data, a compromise on any one of their machines allows cybercriminals to attack others on the same network. Thus, attackers can exploit a single lowly workstation to gain access to sensitive data stored on servers elsewhere in the environment.
Addressing the Issue
At the University of Virginia (UVA) McIntire School of Commerce, we studied this issue both internally and by surveying IT personnel from dozens of other institutions. What we found was a widespread culture of unnecessary rights elevation in higher education and a resistance to breaking these practices. To ensure campus information security, it is imperative to change this culture. Removing admin rights can prevent most attacks on both the technical and human elements of a computing system. If compromised credentials have no elevation potential, it is much more difficult for attackers to compromise a system or network.
One of the challenges we discovered in our research is that a few faculty and staff members have a very real need for admin rights. Unlike most corporate users, university researchers often run antiquated software packages and tools that require privilege elevation in order to function. In addition, higher education employees often travel extensively (for global programs and sabbaticals) and may be far from IT support when issues arise that must be addressed.
2017 Administrative Rights Survey
To gauge the magnitude of the admin rights issue, we conducted a survey of IT professionals in higher education over a three-week period in October 2017. The survey, conducted via Qualtrics, was distributed through the EDUCAUSE user support listserv, and a total of 107 IT staff members responded.
The survey results were similar to what was observed at UVA. For example, nearly 30 percent of respondents said that, at their institutions, all faculty and staff still receive local admin rights automatically, with no questions asked (see figure 1).
Another 10 percent of respondents said that faculty and staff had admin rights, but that they didn't log in with their admin account on a daily basis. One-quarter of respondents said that faculty and staff could apply for admin privileges by submitting a justification for those privileges. However, the strength of this policy may be suspect, as this quote from a survey participant illustrates:
"Faculty/staff have to apply for admin rights (any justification is allowed)."
Some institutions approach the problem from the opposite side, granting admin rights by default, but then removing those rights from individuals when necessary:
"So unless there is reason to take away admin rights, as a central help desk we allow them."
"Others have proven they abuse the admin rights privilege and we revoke them."
As these results show, more than 60 percent of responding institutions either allow faculty and staff to have an admin account (perhaps not using it as their "everyday" authentication) or allow them to apply for one, often with weak justification. This would seem somewhat problematic; indeed, the mix of permissions combined with user pushback can lead to a complicated permissions landscape:
"Now faculty have admin rights and others can get it, but there's a mix of people who have them and don't, and how they have access to them (separate account that provides password override vs. actual login has admin rights). Overall, the restriction of admin rights and the fallout has been a mess."
Yet correcting this issue doesn't seem to be a priority. Nearly 80 percent of respondents said their institution had no plans to change admin rights policies in the next year. (Amazingly, 2 percent of responses said their institution was going to get more lenient on admin policies in the next year!)
The remaining 18 percent of respondents said that their institution would enact a more stringent policy on admin rights over the next 12 months. These IT professionals indicated that, while they saw the need to reduce their risk profile by restricting admin rights, they felt most of their faculty and staff would disagree. In particular, they felt faculty would resist this change more than staff (see figure 2).
As the "Existing Solutions" sidebar describes, current approaches to solving the admin rights problem are cumbersome, if they address faculty concerns at all. We therefore sought an alternative solution.
Existing Solutions
Several existing approaches attempt to address the security risks related to access rights, ranging from simply removing all admin rights to offering separate admin accounts or whitelisting preapproved sites.
Remove All Admin Rights
The most straightforward answer — and the one most often used in a corporate environment — is to simply to remove all admin rights from end users, without exception. This takes away users right to install software or make any configuration changes. All such administrative operations must be performed by the help desk or other support personnel.
From a security perspective, this is the most effective solution. From a usability perspective, it leaves much to be desired for a few reasons. First, higher ed help desks may not have sufficient capacity to perform software installations in a reasonable time frame. If faculty members are sitting around waiting for an application to be installed or configured, their productivity suffers. Several respondents to our survey commented on the drawbacks of this approach from an IT staffing perspective:
"[We] give group admin rights because of staffing issues (three full-time techs for approximately 1,200 faculty and staff)."
"…we DO NOT have the resources to run around to each machine to install software for each person who might need it."
Second, faculty and staff may resist the loss of admin privileges if they've historically had them (even though, as our data shows, they may not need or use them). Some faculty members, in particular, might be accustomed to experimenting with applications and settings; they will not be pleased to lose those rights.
Ask for Justification
Another approach — potentially coupled with the approach above — is to ask faculty and staff to submit a justification for why they need admin rights. Because this approach requires an approval process, it raises the question of who makes the decision — IT staff, or administrative leaders such as department chairs, directors, or deans?
Further, if a faculty or staff member is granted local admin rights, are those permanent? Is there an annual review process to see if these rights are truly required? Can these rights be revoked in the future based on inappropriate use?
Offer a "Non-daily" Admin Account
Another approach that can be combined with either of the two above is to provide a separate admin account that people use only as needed in addition to their regular (user-level only) accounts. The admin account would be used only to install software or make configuration changes, and not for mundane tasks such as daily email or web use. Theoretically, this reduces the risk profile.
However, technical controls may be required to ensure that users don't — intentionally or otherwise — simply circumvent the requirement and start using the admin accounts on a regular basis. At UVA's Curry School of Education [https://curry.virginia.edu/], for example, some faculty have admin accounts, but the accounts are blocked from interactive logon via Windows group policies; if users attempt to log in with their admin account, they are immediately logged out. This approach would not work on Mac OS machines, where any account can be used for daily login. In such cases, user training and/or monitoring becomes critical.
This approach also requires people to remember a separate user name (and potentially a different password as well) and thus raises user support concerns, of course. One possible alternative for Windows is a tool similar to Microsoft's Local Administrator Password Solution. LAPS allows domain administrators to provide temporary administrative passwords to users as needed. These passwords expire on a regular basis, so users' administrative access is time-limited.
Using Whitelisting
If end users are only likely to install a few applications, the whitelisting approach can be a viable solution. Using a software management tool such as Carbon Black, KACE, or System Center Configuration Manager (SCCM), administrators can create a preapproved list of software that users can install without having full admin rights. These management systems support both Windows and Mac OS clients. Administrators working only with Macs can use the Munki open-source tool for application whitelisting.
In environments with a wide variety of potential applications, this approach can quickly become untenable. And, even in fairly homogenous environments, software versions and releases change quickly in the modern app landscape. If IT staff are not diligent in ensuring that the software whitelist remains updated, the whitelisting solution will quickly become useless. As one of our survey participants noted:
"The variety of software installs will make it too cumbersome to try and whitelist each title."
One Potential Solution: "Make Me Admin"
At the McIntire School of Commerce, a pilot project began in 2017 using the open-source Make Me Admin software. Make Me Admin does just what its name says — it temporarily grants administrator privileges to the logged in user. The app was developed by Patrick Seymour, manager of application delivery at Sinclair Community College (SCC) in Ohio. Seymour was motivated to develop the app during SCC's migration to Windows 7, taking advantage of new features in the OS to limit admin access privileges for most users. "We knew that Microsoft had made it more feasible to perform most tasks without administrator privileges, but we realized that some tasks could not be performed with standard user accounts," he says.
Make Me Admin can be configured via group policy to set a time limit for admin rights elevation, which defaults to a 10-minute period. After this interim has expired (or after a reboot), the admin privileges are automatically removed.
Generally, 10 minutes is sufficient time for an application to be removed, installed, or configured; and removing the admin rights doesn't require any further user interaction — it happens automatically. It also doesn't require the end user to remember an additional username or password, which is a positive factor.
In our 2017 pilot, our users were introduced to Make Me Admin as they received a new (or newly imaged) computer, beginning in September 2017. Make Me Admin creates unique log entries upon each use, providing insight into the frequency and user activities that required rights elevation in our environment. To determine the application's usage rate and effectiveness, we collected log data on a total of 126 PCs from September 1, 2017 through January 8, 2018.
As figure 3 shows, despite some initial pushback over losing their admin rights, our data indicates that most people never used Make Me Admin, most likely because our standard workstation deployment includes all the software applications they need. As of early January 2018, McIntire has 126 faculty/staff members using Windows 10 PCs with Make Me Admin installed and local admin rights removed. The software has been used by only 24 of those users, and 15 of those 24 have used it only once. No user has run the application more than five times.
Seymour's experience at SCC has been similar:
"… about 40 percent of our users never run Make Me Admin, even though they have access to it. Another 35 percent have only used it 1–3 times in the past year. It turns out, people need administrator rights much less often than we thought at the outset."
Changing the Security Culture
Our research shows that removing admin rights is not the IT support nightmare that many believe; indeed, the vast majority of users at McIntire never needed admin rights in a semester. Further, our experiences with the pilot study demonstrate that a simple and user-friendly solution like Make Me Admin can satisfy the edge cases where admin rights are actually required. As with any security solution, using this temporary elevation technique will require constant review and evaluation to ensure continuing effectiveness.
Currently, Make Me Admin is a Windows-only solution. Seymour points out that SCC (like McIntire) currently allows Mac users to maintain local admin rights. Although his institution has not requested a Mac OS version of the software, he said that, "I have considered it on my own. I would probably do one if there was enough interest."
Given current trends, the laissez faire practices that have been a hallmark of higher education IT security cannot continue without serious consequences. Criminal and state-sponsored cyberattackers are growing more sophisticated every day, and higher education is an increasingly attractive target.
Fortunately, as we have described here, multiple technical solutions exist to deal with the problems created by offering admin rights for end users. However, shifting to a more restrictive user rights model requires more than technology; a cultural change is needed as well. Addressing the need for this cultural shift offers a valuable opportunity to reinforce a key point: IT security is everyone's responsibility.
Bryan Lewis is the Assistant Dean for Technology & Operations and an IT Area Lecturer at the McIntire School of Commerce.
Eric Rzeszut is the Help Desk Manager at the McIntire School of Commerce, University of Virginia.
© 2018 Bryan Lewis and Eric Rzeszut. The text of this work is licensed under a Creative Commons BY-NC-ND 4.0 International License.