The goal of this serie of 3 posts is to show how powershell can be used to help implement the least privilege model on Windows 7 workstations.
Let me first introduce what is the ‘least privilege’ model. It’s running under a standard user account and being able to achieve any administrative tasks like adding a (printer,…) driver, disabling the wireless adapter, etc. If we transpose this concept to the Linux world, it’s defining a standard user account as a member of the sudoers group, i.e. allowing them to use their own account credential to achieve highly privileged tasks instead of giving them the password of the root account.
Of course, the ‘least privilege’ model isn’t a new concept. On a larger perspective, it’s one of the answers to more than 10 years of bad habits in the Windows ecosystem where we all used to run as administrator and have (had actually) of course legitimate reasons to do so. It’s now a fully mature containment measure of the IT strategy that can be implemented. It is also quoted as an example by Scott Charney in his Keynote at RSA Conference 2012 and his new Trustworthy Computing Next white paper.
If you want more granularity like the sudo features provides in Linux, you can also achieve it under Windows with powershell constrained endpoints of Windows Remoting (WinRM). I diverge and here we will only focus on a scenario that involves the vast majority of users using exclusively mouse clicks…
As you may already know, all the commands or features in windows 7 have been designed by default so that the standard user session is hermetic in terms of privilege. Here are some of the various ways of sudoing in Windows by either impersonating or calling the runas verb:
- the built-in windows command c:\windows\system32\runas.exe,
- Win32_Process WMI class create method,
- start-process cmdlet in powershell or the .Net System.Diagnostics.Process,
- the execute method of the shell com object
- the built-in windows command c:\windows\system32\schtasks.exe
Let me be clear, if you find a way to gain access to administrators privilege while running as a standard user, it’s a security flaw called an EoP (escalation of privilege) that needs to be addressed as soon as possible by the MSRC before it’s used by malware authors. In other words, session tokens are isolated.
There are many ways to implement the least security privilege model and it depends on your environment, your needs and the process you’ve in your organisation, your IT strategy,…
To be more specific, here are the requirements I’ve tried to meet:
- trust my users, train them (or at least communicate about this security paradigm shift in my environment) and make anybody (especially security stakeholders) accept that I allow my users to mess up only with their own (single) computer. This security risk already existed beforehand and it’s now being mitigated or let’s say better contained.
- be able to achieve administrators tasks without giving an administator credential
- be able to achieve administrators tasks by using their own credential
- have it as a self service (whenever it’s required) even when the user’s laptop is at home totally disconnected from your corporate network
- it means that we cannot rely on Active Directory
- this also means that we cannot rely on a ‘helpdesk’ operator who moves the users to another OU or another AD group
- never run all the user processes under administrative privilege but only a specific task (disabling the wireless card) or a process (installing software).
- have it run any administrative task during an hour
- have a global whitelist of permanent administrators
- have an additional local whitelist of permanent administrators