Implementation of Least User Privileges (LUP)

1. Implementation of Least User Privileges (LUP) Doug Smelcer

2. Implementation of Least User Privileges (LUP) • Definition of LUP, user impact, & user benefits • History of LUP at ORNL • Drivers for change to a non-admin model for all of ORNL • Plan for conversion to non-admin • Path Forward • Lessons Learned • Q&A

3. IT Definition of LUP & user impact • What is it? • The term sounds negative. The principle of least user privilege (LUP) is widely-recognized as an important principle in enhancing the protection of data and functionality from faults and malicious behavior. In computer security, LUP refers to the concept that all users should run their computers with as few privileges as possible, which means they will also launch applications with as few privileges as possible. Removing Administrator (or Power User) rights from end-users means that the average user can not install applications, but it also means that unwanted malware cannot be installed by malicious code. The application of LUP limits the damage that can result from accidents, errors, or unauthorized use on your computer. However, instituting such a policy throughout the Lab is not the easiest thing in the world because many applications still require administrative rights to run correctly and some exceptions are needed for power users to do more things to their computers than the average user.

4. Define benefits of LUP for our staff • Less to do. Systems that are LUP’ed will be maintained by the IT department. Over time you will see the pop-ups to install software such as Adobe, Microsoft and other products go away because IT now has the sole responsibility to push the patches to your computer. • Better system security. With limited access rights, malicious code will not have access to perform operations that could crash a machine, or adversely affect other systems. • Better system stability. Running LUP gives users increased protection against inadvertent system-level damage. Based on results from the LUP pilot with our Human Resources department, a decrease in overall call volume to the ORNL IT helpline was noted. • Ease of application deployment. The fewer privileges an application requires the easier it is to deploy.

5. History of LUP at ORNL • One organization implemented a non-admin (LUP) model for ~90% of their staff as the org was established • As staff were added and as the org grew, systems were configured or converted to operate without admin privileges • Organization grew to 400+ systems • Very desirable model from a support standpoint • Support staff to computer ratio was higher than the rest of ORNL

6. History of LUP at ORNL (cont.) • In FY 2008, ORNL’s HR organization volunteered to adopt a LUP model • Planned conversion for 100+ systems • Implementation occurred over several months • 100% assessment of hardware and unique software prior to any change • Validated software would function properly w/o user admin privileges • Standardized on the Operating System and Office configurations and hardware • Implemented without any major issues by converting small groups rather than the entire org at once • Applied lessons learned from each conversion before proceeding with another group • Users embraced the change with almost no complaints

7. Drivers for Change to a non-admin model for all of ORNL • DOE Office of Cyber Security Evaluations (HS-62) conducted “unannounced cyber penetration attack” against  DOE-SC national laboratories.   • Infection from “Green Week” CD’ led to a compromise of an ORNL desktop computer.

8. Drivers for Change to a non-admin model for all of ORNL (cont.) • User’s account on infected computer held local administrative privileges which allowed for a foothold to be established inside the ORNL network • From this one computer, other ORNL desktop computers and email servers were compromised   • Very sophisticated techniques were used to slowly export data from some of our desktops

9. Plan for Converting to LUP • Based on analysis of the attack, it was decided that removing computer administrative privileges from ORNL systems was necessary • IT was tasked to development a plan to remove admin privileges 8000+ Windows Systems • Based on past experiences IT recommended a 6 month implementation • Drivers for this approach includes a diverse configuration for the 8000+ systems (3 Oss and ~28K different version/packages of software) • With 100% support from ORNL’s Leadership Team – request to IT was to remove admin from all 1 day • IT/Management compromise allowed ~ 6 weeks for the task

10. Plan for Converting to LUP • Plan specifics - Phase 1 • Remove admin privileges from all user accounts on systems • Allow user to retain password for local admin account (temporary) • Due to the pace of the deployment, this was to allow users to self help • Remove Domain Admins group from all systems • Overall - manage to remove admin access unless user obtains an exception

11. Plan for Converting to LUP • Plan specifics - Phase 1 (cont.) • Deploy and test LUP with IT and the CIO organization first • Allowed staff one week to identify need for admin • Remove local admin for all not reporting • Communicate, Communicate, Communicate • Web, newsletters, Division Computer Security Officers (DCSOs), special meetings, and IT Project Managers • IT PMs performed a vital role with communication of schedule and information to management and organizations they supported • Developed a FAQ site to provide users with info

12. Plan for Converting to LUP • Plan specifics - Phase 1 (cont.) • Convert approximately an equal number of systems each week during a 6 week period • Allow staff to retain the local admin account and password so configuration changes could be made if necessary (temporary solution) • Add additional subcontract staff to assist with any increased workload • Establish a LUP exception process • Schedule mobile users as the last group • Report on conversion progress and issues daily

13. Plan for Converting to LUP • Plan specifics - Phase 1 (cont.) • Deploy through Run Advertised Programs two IT support groups • Users can run these programs to add IT support as admins • Available until a reboot or for a specific period of time • Require support staff to use a secondary UID for privileged accounts

14. Plan for Converting to LUP • Plan specifics - Phase 1 (cont.) • Made changes to the computing standards offered through the Managed Hardware Program (MHP) • Vista as the only Operating System (OS) offered to the end user • Allows IT to focus mainly on the development of the Vista software images • XP is allowed and staff needing this OS can contact IT for assistance to install • Provide staff with the option to volunteer for LUP 

15. Plan for Converting to LUP • Plan specifics - Phase 2 – Remove local admin and deploy admin elevation tool for the user • Local Admin removed from all systems except those with LUP exceptions • Deploy a locally developed tool that allows users to contact IT to request admin privileges • Requires RSA token and allowed privs to be elevated when on/off ORNL network • Laptop user’s were the last group scheduled • Admin elevation tool was deployed to all these systems in conjunction with LUP move • Troubleshoot reported issues for specific systems • Allow admin to be retained if necessary until issues were resolved • Assign specific staff very capable of Tier 3 troubleshooting

16. Path Forward • After deployment of LUP for ORNL • Test a new admin tool that provides user with ability to self elevate • Tool usage is tracked and reports made available to ORNL Cyber for review • Requires system to be on ORNL network • Utilizes RSA token • Limits time that admin is available • Being considered for deployment to staff with LUP exceptions and will allow removal of the local admin account from these systems

17. Path Forward – Tool Examples

18. Path Forward Path Forward • Phase 3 – After completion of LUP for ORNL • Expand the IT admin support groups advertized through Run Advertized Programs with the groups being more specific and a smaller number of staff assigned to each group

19. Lessons Learned • IT assumed additional responsibilities when user’s admin privileges was removed • Additional IT staff needed to accomplish tasks • Vulnerability resolution • Patching 3rd party software (e.g. Adobe, Firefox, Java, etc.) • And many more of the 28K products • Exception processes are needed at program implementation • Staff may not fully understand but may request anyway

20. Lessons Learned (cont.) Lessons Learned (cont.) • Databases permissions were common problems • Certain staff were assigned to troubleshoot and resolve these issues • Several products like to automatically update or inform user an update is available • Users were unable to install these without admin • Address systems operating as instrument controllers or data collection devices separately

21. Lessons Learned (cont.) Lessons Learned (cont.) • Vista was much preferred over XP • User Access Controls (UAC) • Vista virtual store (allows modification of files typically stored in locations unprivileged users can’t modify globally) • Some troubleshooting tasks could no longer be performed as before • IPCONFIG /Release-Renew • Had to define a solution

22. Lessons Learned (cont.) • Remote Desktop issues under LUP • Only admins were in the group to allow RD • Solution based on analysis of use and determining the primary user. Then adding this user back to the group • LUP exceptions are needed for a small percentage of users • >90% of systems are operating without admin • Validate users with LUP exceptions operate correctly • Cyber conducts internal email phishing as a test for users w/ exceptions

23. Least User Privileges (LUP)

24. Other ORNL Presentations of Interest SharePoint • Monday, 11:45-Using SharePoint UI to Deliver General Use Applications, Connie Begovich • Tuesday, 11:45-SharePoint at ORNL, Brett Ellis Cyber Security • Monday, 1:30-Development of a Process for Phishing Awareness Activities, Philip Arwood & John Gerber • Monday, 2:15-How I Learned to Embrace the Chaos, Mark Lorenc • Monday, 4:15-TOTEM:The ORNL Threat Evaluation Method, John Gerber & Mark Floyd Desktop Management • Monday 4:15-On the Fly Management of UNIX Hosts using CFEngine, Ryan Adamson • Tuesday, 11:00-Implementation of Least User Privileges, Doug Smelcer • Wednesday, 11:45, Microsoft Deployment Using MDT and SCCM, Chad Deguira Incident Management • Wednesday, 11:00-Helpdesk Operations for Clients Without Admin Privileges, Bob Beane & Tim Guilliams IT Modernization • Monday, 2:15-12 Months of Technology, Lara James