Blog

Keys to a Successful Privilege Management Implementation

Posted by sbrown on Feb 7, 2012 in Blog | Comments Off

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.

MMC and the Standard User

Posted by mmurphy on Jan 31, 2012 in Blog | Comments Off

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.

Microsoft Privilege Exploitation in 2011

Posted by sbrown on Jan 13, 2012 in Blog | Comments Off

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.

Privilege Management is Data Security

Posted by sbrown on Dec 13, 2011 in Blog | Comments Off

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?

Better Administrator Password Security

Posted by sbrown on Dec 1, 2011 in Blog | Comments Off

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.

What GPO security?

Posted by sbrown on Nov 17, 2011 in Blog | Comments Off

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.

Windows Service Account Management

Posted by sbrown on Nov 10, 2011 in Blog | Comments Off

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.

Application Control and Web Browsers

Posted by sbrown on Oct 19, 2011 in Blog | Comments Off

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.

Portable Application Protection

Posted by sbrown on Oct 10, 2011 in Blog | Comments Off

Recently, we have seen a lot of inquiries from organizations about controlling portable applications. Portable applications have been around for many years, but are becoming more prevalent and represent a new level of risk to customers that want to maintain the integrity of their operating environment. The good news is that there are methods to contain these applications – let’s take a look.

Portable applications are simply applications that are a self-contained executable that can be run from a USB drive, a network drive or a cloud drive (see Wikipedia: Portable Applications for more details). In the past, most Windows applications would install the main executable as well as a number of DLLs and resource files. In addition to file changes, most applications would use the registry to store settings. Portable applications have grown with the increased prevalence of USB drives and the desire to be access data and the applications that use that data from any computer. There are websites such as www.portableapps.com, www.pendriveapps.com, and www.portablefreeware.com that provide many of these applications for download.

The risk with portable applications is twofold: security and system integrity. The security concern is clear in that these applications don’t require any installation so they can run as a traditionally installed application and have the ability to modify the system and more importantly access data that an organization may not want to be portable or accessible by unapproved software. Secondly, organizations may not want to have their operating environment impacted by portable software. While they aren’t on the hard drive, they still access memory, have the potential to change the operating environment and present supportability costs.

There is a clear answer to the question around portable applications as many of these are legitimate, productivity boosting applications. Arellia sees a few best practices and considerations around portable applications and how to control them using our Application Control Solution:

• Determine If Portable Applications Are Allowed: Some organizations may not like the risk and simple ban them altogether. Whether allowed or not, users should be educated to prevent the introduction of malware and the loss of sensitive data.
• Standard Users Are Good, But Not Enough: Many organizations are moving their end users from an administrator account to the standard user to limit the software that is installed on their desktops. This is a good practice, but the standard user can run software from USB, network, or cloud drives just the same.
• Enforce Policies for Removable Drives: If you don’t want portable applications in your environment, deny execution from any removable or remote source such as a cloud drive. Be aware that these applications can simply be copied or e-mailed so see the next recommendation.
• Intelligent Whitelisting: Policies could be created to block removable storage drives altogether, but there is still the issue around e-mail or web applications. A solid approach to controlling portable applications would be to whitelist known-good applications and apply a restrictive policy on anything else.
• Orangelisting Unknown Software: Arellia Application Control Solution’s Orangelist polices could apply to anything not in a whitelist and restrict file access, reduce privileges, isolate in a virtual layer, or simply report usage. Of course blocking is always an option, but better to limit impact than outright deny a potentially productive application.

As with many things in IT security, there is no right answer to how to deal with portable applications. As a simple framework: determine the risk, educate end users, and enforce policies to protect the organization. With ever-increasing mobility, portable applications are just another consideration IT organizations need to consider.

Insider Abuse is Real and Expensive

Posted by sbrown on Sep 1, 2011 in Blog | Comments Off

In the past few weeks, there has been a lot of discussion in the media about Jason Cornish, an IT administrator who had worked for drug-maker Shionogi, who did over $800,000 in damages by simply accessing resources using his logon credentials to wreck havoc after being laid off. Insider abuse makes up as much as half of all attacks as discussed in an early blog article. Unfortunately in the landscape of hacktivist groups who publicize their works, insider threat is seldom mentioned or discussed – one has to wonder why this is the case.

Hactivist groups are often trying to make a point by defacing a website or stealing data only be to disclosed in an embarrassing fashion. In the case of an insider attack, they do not want their works to be known as they have a more difficult time hiding their identity. They want to make a statement or exact revenge for wrongs perceived or real. In either case, the attacked organization will be reluctant to publicly disclose an attack so it is often left up to the attacker to make their work public.

With so much attention on the exploits of hacktivists, it is easy to continue to focus on the perimeter services (webservers, databases, firewalls, etc.) and continue to ignore the much easier to exploit internal services. In the case of Jason Cornish, he did not need zero-day exploits or sophisticated rootkits, he simply used his administrative credentials. Too often organizations fail to control administrator credentials through regular cycling of passwords, changing of passwords upon an employee leaving, and audits of credentials that are used. IT administrators are the most powerful individuals in an information organization in that they can often access more computers and data than the executive staff. Who is watching the gatekeepers?

Most IT professionals will agree that passwords need to be cycled, privileged access needs to be audited, and credentials revoked when an employee leaves a company. Unfortunately these practices are inconsistently practiced for lack of process, tools, or discipline. How many systems have the same local administrator account password for years? How do you know your “trusted” IT administrator isn’t logging into his HR specialist’s laptop using that same account to see salary information of his peers and boss?

Arellia has seen many organizations with similar stories to that of Shionogi. We have heard stories of administrators gone stray and abusing their privileges. We have heard stories of computers that have had the same local administrator password for 10 years. This is a real problem, which is why we built Local Security Solution. Insider threat is real and it costs real money.