So you have decided to implement a least privilege model in your client-computing environment and now you ask yourself, “Where do I start?” One could pull the trigger on removing administrator rights and elevating applications as needed, but that would create a wave of helpdesk calls as users are no longer able to do many things that they were once able to do such as install any software they want, change system settings, or use applications that require administrator rights. There are some best practices that will help make this implementation go as smooth as possible:

1. Education
2. Discovery and Planning
3. Testing and Rollout

Education

Do not skip the important step of end-user education. Be aware that positioning this project as “desktop lockdown” or “application control” may come across negatively. Use something user-friendly as “enhanced security desktop” and emphasize the benefits of a more secure and stable environment. Help your end-users buy into the initiative and you will have less resistance.

Discovery and Planning

You will want to identify applications that need elevation. First look at three categories:

1. System Utilities – disk defragmenter, adding printers, etc. Which of these do users need to still access?
2. Software Installers – If an end user needs software, will it be delivered using a software delivery tool? Will the software be available via a centralized location(s)? Be aware that there are still many applications that can still be installed or run as a standard user: read Application Control and Web Browsers and Portable Application Protection.
3. Applications Requiring Administrative Rights – For Windows Vista and 7, this can be discovered by looking at applications that trigger UAC (consent.exe).

Once you have answered these questions and analyzed these results, application elevation policies can be created before removing administrator rights. Depending on your existing software installation approach, you may need to create new processes or locations to allow authorized software to be installed.

Many privilege management tools only deal with rights management, but don’t forget the actually removal of rights. Determine who currently has and doesn’t have administrator rights. There still may be users (most for political reasons) that will want to retain administrator rights. Create policies accordingly.

Testing and Rollout

Test your standard Windows image before implementing a standard user model in your environment. There may be adjustments needed that you didn’t catch in the discovery phase.

Before a widespread deployment, select a group of test users from different departments who can provide feedback. Pay close attention to any tickets from them and have them inform you of applications that need elevation.

Meanwhile, you can have the remaining users have messages informing them that certain applications will no longer be accessible at a certain date and provide a dedicated method to addressing their concerns.

Privilege management can be quickly achieved when done with the right process and tools. Arellia Local Security Solution helps find and remove administrator rights while Arellia Application Control Solution can elevate privileges. Both tools have many other capabilities including administrator user and group security and application whitelisting all of which contribute to a more secure desktop.

With desktop lockdown or application control, there are many decisions that must be made. One potential risk where end users could have more control than is necessary, is via the Microsoft Management Console (MMC). Standard users are able to view and configure several snap-ins, some of which can present a security risk.

Here are just a few of the plug-ins available in MMC in Windows XP and Windows 7 and what the standard user can do:

As you can see, the standard user has access to key system information through MMC despite not being able to change system settings. Some areas of potential exposure include the Event Viewer or Local Users and Groups where a user may want to have better insights about their system in order to access administrative settings.

Almost all of the MMC snap-ins above can also be accessed through the Control Panel or by running  a ‘.msc’ file found in the System32 folder. For most organizations, the standard user does not need access to all of the snap-ins available from the MMC; and therefore MMC can be blocked while allowing the Control Panel accessibility to relevant snap-ins. Arellia Application Control Solution makes it possible to enable just one or several of the MMC snap-ins, while blocking the rest. See this video on details of how this is accomplished.

2011 is quickly fading in the rear view mirror so here’s a brief analysis on Microsoft vulnerabilities\patches and privilege risk for the year. As mentioned in the Introduction on Privilege Exploitation, privilege exploitation is where the malicious software takes advantage of the rights of the logged in user to change the configuration of the local computer.

Here is a summary of privilege exploitation in 2011 and 2010 for comparison:

As you will observe, there was a general improvement in the number of bulletins, vulnerabilities, those with privilege exploitation.

Each bulletin has one or more vulnerabilities that apply to one or more operating systems or applications. Here is a listing of affecting software and the number vulnerabilities with privilege exploitation:

As you can see, Internet Explorer is the top for vulnerabilities with privilege exploitation. Exploits in this case are likely a malicious URL either on a website or in an e-mail that allow the malicious user or software to run commands and calls at the privilege of the running user. If the user is a member of the administrators group, game over.

Of the operating system vulnerabilities with privilege exploitation exposure, here are some of the most frequently affected components (there are many others):

• .NET
• Silverlight
• Windows Media Player \ Center
• OLE

Removing end user administrator rights is not a silver bullet, but it will reduce the risk to malicious software not to mention additional benefits around system stability and support costs. Here is another way to think about these statistics. If you could do one thing to reduce the impact of a car accident by 40%, would you do it? Start buckling those seat belts and start removing end user administrator rights. For more information on the latter, look at Arellia Application Control Solution.

Arellia Endpoint Security Remediation Suite 7.1 Service Pack 2 is now released for all Arellia products: Application Control Solution, Local Security Solution, and Security Analysis Solution.

Be aware that applying Symantec Management Platform (SMP) 7.1 SP2 will cause issues with Tasks in Arellia products. We recommend you install Arellia 7.1 SP2 before or immediately after installing SMP 7.1 SP2.

For additional details, refer to the release notes (requires an Arellia portal login to see the details).

• Application Control Solution 7.1 Service Pack 2 Release Notes
• Local Security Solution 7.1 Service Pack 2 Release Notes
• Security Analysis Solution 7.1 Service Pack 2 Release Notes

To receive access to the Arellia Support Portal, following the steps in How to Register with Arellia Support Portal. Note: you will need to have a Windows Live ID.

In a study by the Ponemon Institute, “The Insecurity of Privileged Users”, the prevalence of privilege abuse was noted. A very interesting point was that over 60 percent of the 5,000 IT operations and security managers accessed data out of curiosity and not because of the job function. The reason why administrators abuse their privileges: because they can.

The world of information security is obsessed by the threat of the malicious outsider: hackers, organized criminals, spammers, etc. Meanwhile, while all eyes focus on the threats outside, insider abuse whether deliberate, inadvertent, or accidental has limited attention.  Now don’t get me wrong, I’m not suggesting we treat all employees as criminals, but organizations need controls need to be in place to keep honest people honest and limiting bad folks from doing damage.

Insider threat is as big and complex as the malware and external threat that garners most of the attention and concern which is why there is no one-size-fits-all solution. At Arellia, we have focused on securing privileged accounts and application rights with our Endpoint Security Remediation Suite. Domain administrator accounts often have security policies to manage the cycling of passwords and password complexity. If an IT administrator leaves the company, disable their domain account and\or remove it from the Domain Administrators group and all is good, right? Unfortunately, we find that nothing is being done about local administrator accounts. Common accounts and passwords prevail and cycling just isn’t done due to lack of solutions. A disabled domain account won’t prevent an IT administrator from logging into a system with a well-known local administrator account.

The reasons to access unauthorized systems or abuse privileged access are simple: valuable data. What does my boss or co-workers earn? Just log into the HR application or file server. Wonder how the company is going to do on the next quarterly earnings report? Just log into the finance systems and take a peek at the revenue calculations for a little stock tip. Want to know what the VP is planning to do with the next layoff? Add a local administrator account with remote access on the next helpdesk call and login when curious. These are just small, but potent abuses compared something even more malicious such as corporate espionage or acts of vengeance.

Don’t think these things are happening at your organization? I have some beach front property in Himalayas to sell you. As the study noted, these abuses are happening. What’s your next step?

There has been a lot of press about simple passwords (see Forbes: Worst Passwords of 2011), but nobody ever talks about one of the most common practices in IT: shared, unchanged local administrator passwords. In an article on SecurityWeek today, Noa Bar-Yosef discusses techniques to keep passwords safe. She provided many good best practices around password security, but I would like to add two more: stop sharing local administrator passwords and start changing those passwords.

So what is a bigger threat: an average end user has their password cracked or the local administrator password which is on everyone’s desktop from the person working the front desk to the CEO? Worse yet, everyone in IT knows this password and there is a good chance that many end users do too. How many times does IT disclose the password to the end user who then tells his co-worker and before you know it everyone knows the password? With this credential in so many hands, how can you be sure it isn’t being used to circumvent other security controls or worse yet for unauthorized access to data on other systems.

For many years, I have seen the practice of a common local administrator account and password due to the benefit of imaging technologies such as Symantec’s Ghost or Deployment Solution. A standard image is created and used to deploy every desktop and it just so happens that the standard image has the same local administrator account and password. The reasons are simple, managing local accounts is a pain and they are seldom used except when needed most. So while a lot of effort goes into domain account security, this mostly dormant and powerful local administrator account goes unmanaged.

We at Arellia have seen some organizations try and take steps to secure these accounts. Many if not all organizations will rename the Administrator account using Active Directory or they will disable that account and create a separate administrator account. Some will use scripts to change the passwords, but the management of the password is insecure and you’re dependent of the guru script guy who could leave at any time.

Arellia believes password security should extend to all accounts for which we built Local Security Solution to assist in managing the password complexity and authorized use of local administrator account passwords.

Many organizations I speak with put a lot of faith in Active Directory and their GPO policies for security settings. GPO policies can be an excellent way to push security settings, but how do you know that all computers are receiving their updates or are even on the domain. Arellia supports organizations in their efforts to remove end users from the Administrators group, but there are many organizations that cannot do this for political reasons. As we all know, when end users have administrator rights anything goes including leaving the domain and avoiding GPO policies.

The average user may not know how to avoid GPO policies, but it is not difficult. Many GPO policies are targeted to users so the first step to avoid GPO policies is to not login with a domain account. This can be done with a few key steps when the user’s domain account is a member of the local Administrators group:

1. User creates a local administrator account
2. User uses their local administrator account to logon to the computer
3. User changes any local computer settings and avoids GPO changes
4. User uses their domain credentials for access to network resources such as Exchange, network folders, etc.

Now one may ask why an end user would care to take these steps when they have to repeatedly authenticate to resources with their domain account. The answer is simple: fewer restrictions on what they can do in their desktop environment. No software restriction policies, no control panel settings enforcement, and no limitations on the desktop environment.

Even when a user avoids logging in with their domain account, there are still the issues of computer targeted GPO policies. Again avoiding these policies is easy:

1. User removes their computer from the domain
2. User changes any local computer settings and avoids all GPO changes

Avoiding computer policies reaps even less restrictions: no need to change passwords, no complex passwords, and no limitations to security rights. All of these settings are elements of good security, but often hassles to the average user.

The average user may not have the knowledge to do these steps, but the people that do have the knowledge often need to be secured the most. Developers and engineers hate to be controlled and will often avoid being on the domain and yet they have source code, corporate data, and other proprietary information that needs to be protected. Knowledge workers (marketing, sales, accounting, finance, etc.) also have sensitive corporate data and while they may not have the technical sophistication of developers, they have the savvy to figure out the steps.

So your GPOs are key to your security configuration, ask yourself a few key questions:

• Are your clients on the domain?
• Are your users creating local administrator accounts to circumvent GPO controls?
• Is your security being compromised by end users changing their local system settings?

Don’t assume controls which are easy to circumvent are always in place. Arellia Endpoint Security Remediation Suite can be used to identify local administrator accounts, enforce administrator group membership, and measure and remediate local security configuration and keep those valuable security controls in place. Do you still think your GPOs are keeping you safe? Think again.

One of the biggest challenges in securing accounts is managing Windows service accounts. Service accounts allow key services (SQL Server, Exchange Server, etc.) access to network resources, but present a significant hurdle when passwords are changed.

Windows services have numerous options for log on configuration:

• Local System Account and its variants: The Local System account is what most services use and it gives services full access to the system, including the directory service on domain controllers. Refer to Microsoft Technet for more details on Local System Accounts and variants.
• Local User Account: A local service account would be local to the computer and give the service the same access and privileges of that account.
• Network User Account: Using a domain account, services can obtain access to other domain resources.

In most cases, the default settings of a service should remain unchanged, except where service accounts are needed to access other resources. For example, a SQL server may use linked server connections to other computers running SQL Server or a Blackberry Enterprise Server needing access to Active Directory and Exchange.

Managing service account passwords is much more complex than a domain or local administrator account. The need to cycle passwords is valid for all accounts, but timing is key with service accounts as they are often running critical applications.

1.    Changing the service account password without reconfiguring services may result in a denial of service

When a service account has it’s password changed, the next time a service attempts to authenticate (either due to Kerberos ticket expiration or accessing new resource) to resources it will be using an old password and therefore fail authentication.

2.    Service reconfiguration usually requires restarting the service

Normally a change in the service account configuration requires a service restart to take effect. If the password is changed, but the service isn’t updated, you may run into a denial of service. Some planning may need to be taken to ensure services can be restarted within the password change cycle.

3.    Domain password changes may have a lag between domain controllers

The lag may be only a few minutes in simple Active Directory configurations, but in complicated Site infrastructures these password changes may take hours.  If a service attempts to authenticate whilst the Active Directory infrastructure is replicating these changes, again there may be a denial of service.

As a best practice, Arellia recommends a few key steps:

• Leverage alternating service accounts
• Change the password of the inactive service account
• Give the password change some time to replicate throughout the domain
• Reconfigure services to use the inactive service account and restart the service
• In the next cycle, the service accounts can be swapped again for uninterrupted service

Along with local administrator password cycling and group membership enforcement, these steps for service account cycling can be automated and managed using Arellia Local Security Solution.

Arellia strongly recommends customers of Arellia 7.1 products apply this maintenance pack.

For additional details, refer to the release notes (requires an Arellia portal login to see the details).

• Application Control Solution 7.1 Service Pack 1 Maintenance Pack 1 Release Notes
• Local Security Solution 7.1 Service Pack 1 Maintenance Pack 1 Release Notes
• Security Analysis Solution 7.1 Service Pack 1 Maintenance Pack 1 Release Notes

To receive access to the Arellia Support Portal, following the steps in How to Register with Arellia Support Portal. Note: you will need to have a Windows Live ID.

With Windows 7 adoption in full force, many organizations are revisiting their desktop architecture and many are looking to move their end users out of the Administrators group and make them a standard users. There are many benefits to a standard user model that include limiting system modification, reducing the risk of web-based threats, and preventing the installation of unwanted software. Let’s focus on this third point and what it means in a typical environment.

Preventing the installation of unwanted software is achieved because Windows 7 does not allow software to install to Program Files or the Windows directory without administrator rights. Problem solved! Or is it? The little known caveat is that software that installs to the Users directory is still allowed. To illustrate what this means, let’s take a look at browsers and the standard user.

Looking at browser market share (Browser Market Share), the top five browsers are Internet Explorer, Firefox, Chrome, Safari, and Opera. In tests here at Arellia, we found interesting results when attempting to install web browsers when running as a standard user. Internet Explorer and Safari installations all required administrator credentials to proceed and failed when none were provided; Firefox prompted for administrator credentials and proceeded to install when none were provide; while Chrome and Opera installed without any prompt for administrator credentials. So 3 out of 5 browsers are installable without any administrator credentials and in all cases were found in a hidden directory C:\Users\stduser\AppData\Local.

Many organizations want to control browser installation for web application support, web security, and general application management. Google, Mozilla, and Opera clearly value user proliferation over enterprise manageability and security (are you really surprised). So now what?

Many of Arellia’s customers leverage Application Control Solution to add administrator privileges to an application (system utility, software installer, or other applications) so that it can run properly as a standard user. With browser infiltration into user directories there are many additional options to manage applications in this area:

• Monitor: See what applications are being run from this and any other part of the file system (don’t forget portable applications) and use this to educate end users of appropriate software usage and\or apply more restrictive policies.
• Orangelist: Arellia Application Control Solution’s Orangelist polices could apply reduce privileges, isolate software in a virtual layer, or restrict file access. Of course blocking is always an option, but better to limit impact than outright deny a potentially productive application. Be aware that many good applications will install components in the AppData directory as well.
• Blacklist: Don’t like the software, deny it and inform the end user that it violates policy.

Remember that application security is a journey and not a destination. The Users directory is one stop to review on the journey to better security and management.