Windows Service Account Management
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
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
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
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.
A Better Security Remediation
Compliance standards have been around for over a decade and come in alphabet soup acronyms such as PCI-DSS, HIPAA, SOX, FISMA, FDCC, GLBA and based on standards such as ISO 17799, COBIT, or NIST. It is enough to make a person’s head spin. Once audits occur, the dizziness only continues with the overwhelming volume of results that are summarily passed from the IT security team to the operations team for remediation. Often compliance issues remain in place because the operations team does not have an easy way to automate the remediation. Both teams want to have a secure operating environment, but while IT security is focused just on security, operations also has the demands of availability which often times trumps compliance demands and results in exceptions and extended waivers.
Many compliance tools focus on identifying the problems and reporting them in a nice format in either HTML, PDF, or a nice database reporting front end. Some of these same tools have even attempted to automate the remediation, but there is one big problem here: the IT security team owns compliance tools and IT security does not have the rights to make configuration changes. These tools also don’t take into account change management processes, which the operations teams are required to follow. What is needed is a way to communicate security configuration issues between the IT security and operations teams.
Over the past few years, numerous standards have emerged which enable products to identify platforms, configurations, vulnerabilities, and security checks. Here is a brief list of these standards and what they do:
- OVAL (Open Vulnerability and Assessment Language) – XML specification on how to check systems for security flaws, configuration issues, and patches
- XCCDF (eXtensible Configuration Checklist Description Format) – XML specification for security configuration rules.
- CPE (Common Platform Enumeration) – Naming convention for hardware, operating system, and application products.
- CVE (Common Vulnerabilities and Exposures) – Dictionary of security flaws.
- CCE (Common Configuration Enumeration) – Dictionary of software security configuration issues.
- CVSS (Common Vulnerability Scoring System) – A methodology for classifying and score software vulnerabilities.
This list represents a mouthful of standards, but the evolution of these standards has been wrapped up into the Security Content Automation Protocol (SCAP) enabling communication of security issues between different products and most importantly a framework to communicate between IT security and operations.
Arellia set out many years ago to address issues related to security configuration by first securing privileged users using our Local Security Solution. Then we looked at applications and the implications to security with our Application Control Security which enables privilege management, application white, black and orange listing. We realized there is yet another area for proactive system security around compliance remediation or to put it frankly the software and system security configuration. With that in mind, we created the Security Analysis Solution which combined with our other products forms the Endpoint Security Remediation Suite (ESRS). Rather than be another assessment focused tool, we have set out to drive automated remediation using SCAP and the underlying open standards. ESRS is a product for the operations team enabling them to identify or import issues from an assessment product and automate the remediation tasks that can be implemented upon change management approval. There is a better way to automated remediation with Arellia.
Application Control: Privilege Elevation
Most Windows desktop lockdown or application control projects target the removal of administrator rights for the end users and having them run as a standard user. This one simple step can reduce the impact of end users misconfiguring their computers as well as a lower security impact. Inevitably, there are certain applications or system utilities that are inaccessible resulting in the need for administrator privileges again. To prevent going back to running with an administrator account, there is a technique of privilege elevation.
Privilege elevation of applications is usually needed for one of few different reasons. First off, there are certain restrictions of operating system utilities when running as a standard user that may be appropriate for end users. In Windows 7, some of the restricted functionality includes:
- Backup and restore computer data
- Change the system date and\or time
- Configuring Windows Update
- Defragment a disk
- Install a device driver
- Install or remove display languages
Secondly, older applications may be programmed to require elevated privileges. Sometimes these are internally developed applications or commercial applications that have not been updated to run as a standard user. While lack of certain operating system utilities may be annoying, the inability to run a potentially business critical application can quickly end a desktop lockdown project.
Finally, there is the need to be able to install certain software such as ActiveX plugins, Adobe reader, Adobe flash player, and a myriad of other software. Such installation could be managed centrally, but often times IT does not have good insights into every piece of software that is required at the department or individual level.
The technique of privilege elevation applies one or more administrative privileges at runtime to the application thereby enabling it to execute when running as standard user. Since Windows Vista, this has been accomplished with User Account Control where a user must have an administrator account password to permit an application to execute. With Arellia Application Control Solution, policies can be applied to enable specific applications or system options automatically thereby enabling end users to run as the standard user and still use these options. Considering privilege elevation is a must in any application control\desktop lockdown project and is key to success.
Patching Pitfalls and Privileges
Today, Secunia, released an excellent report analyzing patching and vulnerabilities for the first half of 2011. In the report, they identified some valuable statistics around patching:
- Third-party programs are responsible for 69% of the vulnerabilities on a typical end-point.
- There is no patch for available 26% of all advisories released during the past 24 months.
- 30% of vulnerabilities provide system access.
Secunia’s data on third-party programs is bolstered by a report from Avast, that nearly half of their antivirus users were running vulnerable versions of Adobe Reader. Patching has been laser focused on the operating system for many years with Adobe and Java having additional emphasis, but as we see from Avast’s report there is still a great lag. Unfortunately, malicious software and users will leverage any vulnerability to gain access to a system and there are many free tools that make it easy to pick a vulnerability to exploit a system.
Secunia’s finding about advisories without patches supports the fact that zero-day vulnerabilities continue to pose a threat. Even when patches are available, they often take a long time to deploy which continues to expose an organization to risk.
From Arellia’s perspective, the 30% of vulnerabilities providing system access is of most interest. Arellia’s analysis has found that 58% of Microsoft vulnerabilities for the first half of 2011 exploit privileges of the logged in user and preliminary research on Adobe finds this number to be much higher. Privilege exploitation is often the key to system access.
Secunia’s reports breaks down the attack vector into three types:
- Local system (8%) – often times these would include privilege escalation attacks which give the logged on user additional rights. Then again so many users run with administrator privileges that this is more likely on servers or hardened systems.
- Local network (12%) – this would include the attacks on services that are generally available within a network. This could include a local coffee shop, home, or other network for laptops.
- Remote attack (80%) – this would include attacks on web facing services or tricking the user into performing an action such as download a file, go to web page, etc.
Combine the most common vector (remote attack) and the most frequent impact (system access) and we see what is commonly understood: social engineering combined with the right vulnerability always wins. Take the newsworthy event of the week and get someone to go to a website or trick someone into opening a file either of which exploit a vulnerability. These tactics have been around for years and won’t go away.
Arellia doesn’t have a silver bullet, but we believe that in addition to antivirus, firewalls, patching, and intrusion prevention, organizations should arm themselves by locking down the privileges for their desktop environments and ensure that systems are configured securely. We know one simple fact: system access is often denied if applications aren’t running with administrative privileges. You can’t patch fast enough and you can’t stop human behavior, but you can reduce the impact of these two exposures.
Desktop Lockdown: Blacklisting
In my previous article Desktop Lockdown: Choose Orange, I gave a brief overview on Arellia’s view to Black, White, and Orange (or gray) listing as they apply to desktop lockdown. In this article, let’s take a look at black listing and where it makes sense and the basics to implementing it.
Black listing is often misused to solve complex application control problems. Some paradigms would have you create a gigantic black list to which application execution is blocked. This could include malicious or known risky applications (such as peer to peer software) and whatever else an organization deems unacceptable. Now the challenge with this approach is the manageability of maintaining massive lists of applications as well as the unknown inappropriate application. There is a better paradigm, which we call “Orange Listing”, that I’ll blog about in a future article, but let’s look at where black listing makes sense.
Most organizations have acceptable use policies around the Internet and software which define what websites and software are not acceptable for use. For blocking websites, many organizations use web filtering software and for blocking software there is black listing. Black listing of unacceptable software makes sense when dealing with known software. For example, an organization may state that BitTorrent is an inappropriate application and should not be used. In this case a black list policy that identifies BitTorrent, blocks execution, and notifies the end user of the policy is a good approach.
One could debate the approach to blocking an application. The most reliable approach would be to block an application based on the hash, as every file would have a unique hash value. The challenge with this approach is that every version of a file, whether a patch, service pack, or upgrade, will have a unique hash and will need to be added to the blacklist when changed. The other approach would be to use file attributes such as the internal file name or company name and block based on that attribute. Someone could change these values with the right tools and deep knowledge, but there are bigger problems if a person is that ambitious about circumventing a blacklist policy. I’ll talk about how “Orange Listing” can be used for these extremely rare circumstances in a future article.
Application control and desktop lockdown is as much an education and political issue as it is a technical issue. Failure to notify the end user when an application execution has been blocked is likely to generate helpdesk calls and become an organizational nightmare. End users should be aware when a policy has been violated, informed of the policy and\or location of the policy, and directed to the proper manager or human resources contact for more information. While IT may influence the creation of such application control policies, they need organizational support for long-term success.
Insider Breaches: The Silent Threat
Earlier this week, the Ponemon Institute, sponsored by Juniper Networks, released a report on Perceptions about Network Security, which surveyed IT and IT security practitioners about their organization’s response to threats against network security. Highlights of the report that have been discussed in IT media include 9 out of 10 organizations having been breached in the past year and the costs of such breaches were over $500,000 for 41 percent of respondents. An interesting statistic deeper into the report was that 52% of breaches came from insider abuse. With the wave of breaches that have occurred by infamous hacking groups, this silent killer continues to take a back seat in the information security conversation.
Data and information, like water, will flow to the path of least resistance. A determined insider can breach a network if they desire. Too often the conversation focuses on preventative technologies that block malicious software or intrusions or monitor and stop extrusion of sensitive information. Unfortunately, too little focus is placed on proactive measures around endpoints such as securing privileged accounts, managing the applications that can run on systems, and secure configuration. Data centers often apply these techniques to protect the valuable data that resides therein, but most desktops and laptops are left as an afterthought.
The number one endpoint where breaches occurred in the study was employee laptops. Laptops go in and out of the controlled corporate environment to home and public networks with questionable security. The also act as a gateway to valuable databases, file shares, and other information repositories within a corporate network.
Much has been said about the consumerization of IT and the need to enable users to do their business with any device, anywhere, at any time. Organizations need to balance this demand for accessibility with a secure operating environment on all devices and apply the same techniques of system hardening on client devices as have been done on servers.
Microsoft and Privilege Exploitation
With this past Tuesday’s release of Microsoft security bulletins, let’s look at Microsoft security patches and vulnerabilities in context of privilege exploitation for the first half of 2011 and all of 2010. 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.
In 2010, 56% of Microsoft Security Bulletins and 58% of associated vulnerabilities had exposure to privilege exploitation. So far in 2011, 46% of security bulletins and 46% of associated vulnerabilities had exposure to privilege exploitation. Now to reiterate the earlier blog entry on privilege exploitation, running a Windows computer with reduced user privileges would not stop the exploitation of a vulnerability, but it would contain the impact of such exploit to the privileges of the running user. Many times these vulnerabilities involve buffer overflows where a malformed webpage, file, or script is crafted to overflow the buffer and execute malicious commands.
Most vulnerabilities are reported months before there is a patch available. Add to that the time in which many vulnerabilities are secretly identified and sold on the hacker underground. Then add to that the time between a patch’s availability and when an organization actually applies the patch. Combine all of these timelines and the exposure for most computers to a particular vulnerability can range from months to well over a year.
Reducing the privileges of standard user is not a silver bullet, but this one step can assist in reducing the exposure to a large amount of malicious software techniques. In an upcoming blog entry, I’ll provide some examples of malware that leveraged privilege exploitation.