Just like fresh bed linen, there’s something reassuring about a nice clean PC, assuming it’s configured correctly - you know it works, what applications it can access, that there’s no nasty malware hiding and that it’s therefore secure. With the popularity of Windows 7 finally superseding XP, a migration presents the perfect window of opportunity to figuratively wipe the estate ‘slate’ clean. However, all too often that sanitary condition doesn’t last very long. This article examines how to ensure the perfect roll out that empowers users, ensures costs don’t spiral and maintains security.
Moving to a new operating system presents the perfect opportunity to give your estate an overhaul. Every desktop in the environment can be built to a shiny new standard that optimizes your infrastructure. However, to make sure it remains that way is another thing!
Users with admin rights are the bane of many an IT Team as each has the ability to ‘mess’ with your build and introduce vulnerabilities. And, it’s not just users. Ssome applications need admin rights to run. The problem is, as privilege creep occurs over time, it’s impossible to determine exactly where these dangerous accounts are hidden in the network, waiting to wreak havoc.
There are many articles written discussing the risks associated with admin (privileged) accounts so I won’t regurgitate that here. However, I do think it’s worth just outlining the two key drivers for why they need to be removed:
- Compliance. Various regulations, such as CoCo, Sarbanes Oxley, PCI DSS, HIPAA to name just a few, now stipulate that admin rights within an organization must be properly managed and controlled, or better removed all together.
- Security. A windows desktop with full admin rights is a gift to malware writers; and users are able to introduce incompatibilities, etc.
- Costs. Both malware and incompatibilities will result in frustration, expensive calls to the help desk or even cause network downtime.
Whichever driver is foremost will depend on your organization but, regardless, removing admin rights from an organization’s estate is the single most important thing that you can do to secure and protect against the insider threat.
Window of Opportunity
A migration is the perfect time to remove admin rights. For users, they’ll be experiencing change anyway while getting used to the new operating system, so are unlikely to even notice that they’ve had their admin rights removed.
As an organization, you need to clearly define and prioritize the objectives of the roll out. Here are seven tips to help as you prepare to migrate to a new operating system without admin accounts, and keep it that way:
1. Communication and Education
Before anything else, how you inform users will make all the difference. You’ll be providing end-user training on the new OS, and any other programs deployed, so use the opportunity to explain that admin rights have been removed, and why. However, tell them it’s about locking workstations down and preventing them performing certain tasks and many will feel restrained. Package it as a business enabler, protected against accidental misconfigurations, that’s more secure and will maximise performance, presents a very different scenario. I know which one I’d rather support.
Next, if you’re serious about removing admin accounts and keeping them out, you need to understand how and where these privilege accounts are being granted in the first place:
- Automatically - through the build process, through active directory or even via a third party application. If you don’t determine all of these occurrences, you could deploy your shiny new operating system, thinking everyone will be a standard user, only to discover that an automated build sequence puts users into an admin group. Having understood how they are granted, you will also need to understand what’s involved in changing this process. There are also technologies available that enable IT staff to perform audits of who is logged on with admin rights.
- Manually - where someone approves each request and adds them to an admin group. Decide how you will handle these requests moving forwards
3. Understand the Landscape
Of course, there will be some functions within the organization that will need to be granted privileged accounts. However, just because a user currently has them doesn’t mean the needs them when you migrate.
Another point to consider is the control of applications that can be installed as a standard user. Not only does this de-standardize the build but it could also introduce a support overhead. For example, Google Earth and many other apps can be installed as a standard user and are free for personal use but require a costly corporate licence. It is important to put measures in place to control this, such as whitelisting; otherwise you could be facing costly licensing bill.
Carrying out an admin rights audit will prove to be invaluable. This will not only help you understand the threat landscape within your environment it will also help formulate requirements and objectives.
4. Role-Based Policy
Everyone’s environment’s is unique, but not everyone within the organization will be. Look at the different work styles and categories in your organization and align policies to that. The theory is that if a developer needs access to certain applications to complete tasks, then it can be assumed that all developers may need to do the same. From this position, elevate individual applications based on these policies as defined by the IT department, and not determined by the user or the operating system. This approach provides greater flexibility and scalability over the "one size fits all" approach often seen in the corporate environment.
5. Compatibility Testing
You’ll need to complete application compatibility testing for a migration anyway so use this opportunity to identify which line of business applications require admin rights to run. Any that do will need to be re-engineered. This may require intervention from the original vendor or remediation with a shim, which is a way of changing the behaviour of an application so that it is ‘tricked’ not to require admin rights. Of course, this can’t be used to ‘fix’ all applications and some may actually require privileged access.
Considered by many as the alternative to removing admin rights in a Windows environment is UAC, or User Account Control. In Windows 7 (and 8 incidentally), it has a sliding scale that can be set to allow certain activities to take place without being prompted. However, it is still far from ideal in a corporate environment as it doesn’t follow a centralised policy driven framework.
When a standard user tries to perform an action that needs admin rights, they’re presented with a UAC dialogue box requesting an admin password, which many users struggle to understand. Of course, they’re unlikely to know the password resulting in a call to the help desk anyway. For admin users, Windows will present a message stating ‘Windows needs permission to continue’, users will blindly consent, installing unlicensed software, malware, incompatible applications, the list is endless, and they won’t understand the implications of doing so. It’s akin to leaving your front door wide open and asking everyone who walks through to sign a disclaimer saying they’re not going to break or steal anything!
7. Reporting and Auditing
Once you move to a least privilege environment, you will also need to consider the level of auditing and reporting of your end points to ensure it remains that way. A report that’s not being looked at is pointless, so make sure you collect relevant information. Things to consider are whether you need to know every time someone has escalated privileges, a line of business app has executed with admin rights, an application requires admin rights or an unauthorised application has been blocked from running. Collecting the right auditing data for your needs means the data captured can be used to help drive and refine policy definition. This means organizations can be proactive and use privilege management as a business enabler.
For anyone thinking removing admin rights is easier said than done, privilege management solutions exist that can help. For example, instead of elevating users, individual applications can be elevated, eradicating the expense of re-engineering existing applications identified as requiring admin rights to run. UAC messaging can be replaced with branded messages, written in simple English, that explains what’s happening, so users understand what they’re doing, why they’ve been stopped and what they can do about it. User requirements can be capture by running a discovery mode to establish their needs, the data captured here can be used to automate policy creation, which significantly reduces the deployment and engineering lifecycle.
Don’t miss your window of opportunity to get a grip of your privilege accounts, eradicate them, and don’t let any creep back in.