One of the biggest steps that can be taken to mitigate malware threats is to implement a least privilege approach. The most dangerous and persistent threats often look to bury themselves deep inside the operating system, using root-kits and other kernel level techniques. Once malware operates at this level it can cloak itself from security solutions, making subsequent detection and removal extremely difficult.

In order for malware to infect the kernel it must run in a privileged context or gain access to a privileged account, such as a local administrator or SYSTEM account. If a user logs on with a local administrator account then malware can gain access to a privileged context with ease, whereas if a user logs on with a standard user account it becomes much more difficult for the malware to gain privileged access to the system. It’s no surprise that over 90% of Microsoft’s critical vulnerabilities state that users who log on to systems with fewer privileges will be less impacted.

So if least privilege is such a good way to mitigate malware threats then why do so many users still log on with local administrator accounts?

The answer is the age-old problem of getting the right balance between security and usability. The more a system is locked down the more secure it becomes, but usability starts to suffer. Taking this to the extreme, if you were to remove the Internet connection and disallow removal storage devices then an endpoint would become extremely secure, but it would become unusable in the interconnected world we live in today. The removal of local administrator rights from a user may not seem quite so extreme, but many users will simply struggle to perform their role or at best will be faced with frequent over-the-shoulder administration, leading to frustration and a loss of productivity.

A privilege management solution is required to strike the balance between the two extremes of standard user and local administrator rights. Instead of assigning privileges to a user’s account, the necessary privileges are assigned directly to the applications that actually require them, based on centrally managed policies. This approach ensures that malware will find it extremely difficult to gain access to a privileged account, because all users log on with standard user accounts. More over only the applications that require elevated privileges are granted them, which significantly reduces the application attack surface.

In addition to increasing the risk of malware infection, users who log on with local administrator accounts will significantly reduce the effectiveness of many security solutions, as they are more likely to be compromised, although few vendors will point this out.

Embracing least privilege will not only increase the security posture of the endpoint, it will also lead to reduced desktop operating costs, as under-locked or over-locked desktops are more costly to support. So now you have two very good reasons to implement least privilege – reduced malware threats and reduced operating costs. Improved security doesn’t have to come at a price – with a well managed least privilege solution you can save money and improve user satisfaction too!

The steady adoption of cloud services over the last few years has allowed Symantec to collect information from its own Symantec.cloud platform to give some insight into the proportion of attacks targeted specifically at SMEs, and it may be surprising to know that 40 per cent of attacks are aimed at small businesses, compared to just 28 per cent at large corporations.

The days when malware was distributed in the hope of randomly gaining access to any organization’s systems are gradually passing in favour of targeted attacks. Hackers design malware to target a specific person, group, business or industry with the aim of phishing valuable data, sometimes known as spear phishing in the context of targeted attacks.

One of the most common types of targeted attack is to send a document in an email that looks as if it’s intended specifically for the recipient with some relevant content. The document exploits an unpatched operating system or application vulnerability on the recipient’s PC, so if the document is opened, a backdoor Trojan is dropped onto the PC to gain further access to the company’s systems.

SMEs provide hackers with a low-risk alternative to corporations, and tend to be easier to attack as they don’t have the same amount of resources available to protect their systems. Larger corporations and government agencies often have the additional advantage of forensic systems that collect data which can later be used as evidence should their systems be compromised. While many corporations are already hacked – or owned – but don’t know it, when it does eventually come to light that there’s been a security breach, there’s more likely to be some data available that can be used to identify the source of the hack.

However large corporations shouldn’t rest on their laurels, as Shawn Henry, outgoing chief cyber security official at the FBI, says:

“Too many companies, from major multinationals to small start-ups, fail to recognize the financial and legal risks they are taking – or the costs they may have already suffered unknowingly—by operating vulnerable networks.”

Companies can bolster security by protecting end points. In addition to installing and keeping antivirus software up-to-date, removing administrative privileges from users significantly reduces the attack surface and damage that malware can inflict should a PC be infected. Application whitelisting can further lower the risk by ensuring that employees are only allowed to run authorized programs. Patching the operating system and applications is equally important to stop malware leveraging known vulnerabilities.

Symantec’s SMB Threat Awareness Poll can be downloaded here: http://www.symantec.com/about/news/release/article.jsp?prid=20111116_01

Although you can authorize individual software packages with Privilege Guard, it may be more appropriate to allow a group of users to install software from a network share, as this is extremely simple to setup and maintain. The users should only be given read and execute access to this share, enabling them to launch any software packages that are made available by the IT department. A couple of simple rules can be added to Privilege Guard to automatically elevate any executables or installer packages that reside in the shared folder.

Approved Software Application Definition

You could easily extend this principle to be more granular, such as creating a set of folders within this share for different roles and then ensuring that the software installers are only elevated for the relevant groups of users.

Blocked Software Installation

This can be taken a stage further by blocking software installers for those users who should not have access to them. You can achieve this by adding a simple “catch all” policy to block all installations from the software share, which should be placed at the end of the policies and applied to all users (policy precedence will ensure that this policy will only match if a higher precedence policy has not matched first). A suitable message should be displayed to the user, with instructions on gaining access to the software, assuming they have a legitimate business purpose. You may optionally allow the user to email a request for an application or you can provide a
hyper-link in the message that directs the user to an appropriate web site, such as a help desk portal.

Software Publisher and Product Information

You may need to allow some users to install authorized software directly from the internet. The recommend way to define policies for this purpose is to make use of the publisher rule, as opposed to the filename rule, and then combine this with other product rules, as required. For instance, we could allow the user to install all software signed by a particular vendor.

You could extend this rule to make it specific to a particular product by using the product name or product description, and you can optionally include a check for specific versions of the product or a minimum version.

In addition to elevating installation packages you can also specify rules to block the installation of software that you do not want users installing, as some software packages do not require administrative rights to be installed, as they install within the user’s profile.

On Demand Software Installation

For users with more flexible requirements, you can create an “on demand” policy where users are trusted to make their own decisions on software installations. This should be configured with a custom message, to warn the user of their actions and ask them for a reason, which is then audited. You may optionally force a user to re-authenticate before installing the software to ensure that they self-approved the installation.

Even with an on demand policy you can still prevent these users from installing certain software packages, by creating a higher precedence policy that blocks the installation of any unauthorized software. Alternatively, you can delegate the on-demand installation of software to an appropriate group of staff, such as departmental heads, who would need to authorize the installation on the user’s behalf.

Blocked ActiveX Installation

Privilege Guard can also handle the installation of ActiveX controls. For ActiveX controls, the primary rule to match on is the URL of the codebase. The URL can point to a specific codebase or a more general URL can be used to match multiple ActiveX controls hosted on a site. It’s a good idea to insert a catch all rule for ActiveX controls that blocks access to any ActiveX controls that have not been defined in the policy. This will provide the user with a corporate message and instructions on how they should request access to the blocked ActiveX control if they have a legitimate business reason for installing it.

On Demand ActiveX Installation

As with “on demand” software installation, users with more flexible requirements can be authorized to install any ActiveX control. This should be configured with a custom message and audit trail, to ensure that the user is warned of their actions, and you may optionally force the user to re-authenticate. Remember that you can still block access to unauthorized ActiveX controls with a higher precedence policy.

The end user experience is a crucial element when allowing users to self-provision software, whether you are asking a user to justify their actions before proceeding, or blocking the installation of a software package and giving the user meaningful feedback and direction. Small touches, like strong corporate branding in end user messages, ensure that users pay more attention than when presented with a standard Windows message. You can define any number of end user messages in Privilege Guard, with corporate branding, multi-lingual configuration of all text elements and control over many other aspects, such as re-authentication and asking for justification before proceeding. It is always better to display a message that is relevant to a user’s actions, as opposed to a broad generic message, as this will lead to an improved end user experience and a reduction in help desk calls.

Coviello’s comments – citing the Bob Dylan track, `the times, they are a changin’ – are bang on the money, especially when he recommends that IT security now needs to be a board level discussion.

This coincides with our thoughts here at Avecto, as the involvement of a board level discussion on security will help IT security managers to determine the `sweet spot’ where the organization has invested in sufficient security to say it has carried out what any reasonable company would do to defend its digital assets.

And in today’s security governance-rich environment, the expensive cost of reaching that sweet spot can be lowered by adopting a multi-layered approach to IT security and so help to ensure that the advantages of one type of security can offset the disadvantage – namely the weak spots – of another system.

At the risk of sounding like an accountant, this all comes down to the risk/reward balancing game which Coviello hints at in his column, but with the additional factor of cost entering the equation.

The EMC/RSA chief is, of course, quite correct in his assertion that the security world is changing, but our belief is that it’s not just about balancing risk with security, it’s also about balancing the cost of the security against the reward in terms of the level of security assurance that the expenditure will generate for a typical company.

And whilst there is no such thing as absolute IT security in today’s multi-vectored threat landscape, it is clear that multiple layers of defence can often produce a better overall return on investment curve than if just one or two layers of security are involved.

Our experience suggests that treating the governance levels of, for example, the PCI Security Standards Council as a starting point in security terms and working upwards – depending on the risk/cost/reward stance your organisation is prepared to invest in – is the best way forward.

And when you factor in Coviello’s sound advice that you need to continue to evolve your organisation’s thinking about security – working on the premise that shared knowledge is a powerful advantage – you realise that adding extra layers of defenses – such as a Windows privileged account management system that lowers your security risk profile – can help tremendously in the risk/cost/reward stakes.

The ideal solution is to apply least privilege principles to as many users as possible, with specific members of staff having limited access to admin facilities and, even then, only on the specific applications they need access to on a regular basis.

Our approach with Windows privilege management is to give users only the access and privileges they need to complete the task at hand. In most cases this will be for specific applications, tasks or scripts, and by assigning specific rights to those applications, you no longer need to give them to users. As Windows security expert Russell Smith, explains in his book ‘Least Privilege Security for Windows7, Vista and XP’, taking away user privileges can be similar to taking a toy away from a small child. Bottom line is that user expectations have a real impact on the security of any organization, so empowering them to perform their role without compromising the integrity or security of their systems makes good financial sense.

As Coviello says in his column, as cyber threats escalate, we must invest in building a cybersecurity workforce with the requisite skills to defend enterprises, governments, and critical infrastructures.

And whilst – again as the EMC/RSA chief against observes – these individuals need a 360-degree view of security that combines computer science, risk assessment, analytics, digital forensics, and human behaviour – it should also be clear that the addition of multiple layers of security can only enhance the risk/cost/reward ratios.

Even if you’re not a board level professional, that should still make you smile.

For more on Art Coviello’s words of wisdom: http://onforb.es/yk5f32

Windows member servers – i.e. those joined to an Active Directory (AD) domain – and workstations depend on domain controllers (DCs) to manage certain aspects of their security. This is a necessary dependency where a less important device relies on a more critical system.

Unwanted security dependencies tend to appear on networks unexpectedly. For instance, a PC becomes infected with a virus because the user was tricked into running a malicious executable, and an unpatched vulnerability is exploited. As a result, the Exchange Server is also infected and subsequently shut down by the virus. Though we can argue both the PC and server should have been patched, in this situation the server was unlikely to have been infected if the PC had remained secure.

I was recently reminded about the DNS Changer trojan that first appeared in 2008 and mutated into various different forms. The virus attempts to change a PC’s DNS settings to redirect internet traffic, and failing that, scans the local network in an effort to discover the admin credentials and change the DNS configuration of gateway routers. This is an unfortunate example of where a critical network device becomes dependent on a PC for its security, in turn compromising the integrity of all devices connected to the router. Another variant of the trojan sets up a DHCP server on infected PCs and attempts to intercept DHCP requests on the local network and respond with bogus DNS settings to devices looking for valid DNS configuration.

To change DNS configuration on Windows, administrative rights are required; so a standard user account stops DNS Changer dead in its tracks. Secondly, with application whitelisting in place, DNS Changer wouldn’t be able to run at all, preventing it from scanning the network for vulnerable devices.

While SANS Internet Storm Center issued reactive advice at the time to block traffic to IP addresses known to host the malicious DNS servers, a proactive approach to prevent PCs being infected in the first place is always preferable. Antivirus should also be capable of stopping DNS Changer, but why rely solely on AV to protect your systems, especially with the speed at which malware mutates and sophisticated techniques used to evade detection.

Users often think that what happens on their network-connected PC or other device cannot affect the security of other systems, let alone critical servers and network hardware. But as you’ve read in this blog post, users and management should understand that once a device is connected to the network it does not exist in isolation, and least privilege security and application whitelisting technologies, such as those provided by Avecto Privilege Guard, are needed to protect the IT infrastructure at large.

A rather distraught software developer was accused of stealing data from his previous employers. The company claimed he circumvented the USB monitoring system when copying files to a flash drive because IT couldn’t find any evidence in the logs that the files had been transferred to the removable drive. As a software developer, he had admin rights on his PC and the company is now threatening legal action.

I don’t know whether the company has any legal basis on which to make such threats, but as has been said many times before, giving users administrative rights unleashes the potential to override Group Policy, Windows security and any other defensive measures you decide to put in place on your systems.

It’s in everyone’s interest to work with the minimum privileges required to carry out the job at hand, especially if users want to avoid being held responsible for a major security incident. The likelihood of inadvertently causing a devastating virus outbreak, installing unlicensed software or otherwise circumventing security policy is significantly greater if running with admin rights. As the risks are not usually taken seriously, it can help to illustrate what the consequences of a virus attack or other security incident might be, not only for the company but also the employee.

Someone who pressures the IT department to run with admin rights without good reason and then infects the network with a virus, not only causes downtime for themselves, but makes extra work for the IT department and frequently the consequences are felt by other employees, who see their own machines infected or network services become unavailable. You could compare it to calling the doctor when the symptoms are nothing more than a minor sniffle, wasting valuable resources and denying those who are really ill the vital help they need.

It’s important to communicate the effect that computer misadventures can have. Pose the question: Do you really want to be responsible for downtime that brings the organization to a standstill? Teach users to be good corporate citizens by giving real-life analogies of IT security problems and examples of the possible consequences should something go awry.

64-bit Windows 7 fares better than its 32-bit counterpart in part due to the inclusion of kernel patch protection, a technology only available in 64-bit Windows 7 that protects the kernel from unauthorized changes. Windows 7 is less likely to be infected overall because of User Account Control (UAC), an umbrella term for a set of technologies that make the OS easier to work with as a standard user or specially protected administrator account (Protected Administrator).

The results reported in SIR v10 for Windows 7 would have been even better if more home users didn’t disable UAC, which is likely what many tech-savvy home and business users do considering the number of articles on the Internet about the evils of UAC and how to turn it off; and hence goes the old adage that people don’t always know what’s good for them. If your users currently run as protected administrators on Windows 7, configure UAC in Group Policy to make it a little harder for them to disable UAC – though it’s worth bearing in mind that if a user has admin rights, Group Policy settings can be circumvented with enough will.

While UAC has some benefits in enterprise computing, it is a user-driven technology. UAC elevation prompts require users to give consent, or provide an admin username and password, to perform administrative tasks, resulting in decisions being made by unqualified staff that affect the integrity and security of the OS.

UAC Protected Administrator accounts provide a lot of flexibility, with a limited degree of security, that wasn’t possible in Windows XP. Once you move to standard user accounts in Windows 7, users can no longer elevate privileges; and all tasks, anticipated or otherwise, must be made to work as a standard user, or IT will have to intervene and provide administrator credentials.

Predicting users’ every move and requirement isn’t possible, so if it’s not acceptable to restrict the computing experience with a standard user account, you’ll either need to leave the default user-driven UAC experience in place or deploy Avecto’s enterprise rights management solution – Privilege Guard.

As well as the ability to assign privileges to individual applications and tasks, Avecto’s software can be configured to allow users to run any process with administrative privileges. UAC prompts can be replaced with custom corporate messages and users can be prompted to provide a valid reason before elevation. An audit trail of privilege elevation events allows administrators to keep track of how privileges are used. Privilege Guard helps companies strike the right balance between the flexibility of user-driven UAC and policy-based IT controls, making Windows 7 more secure and mitigating unnecessary risks.

Running up-to-date anti-virus software, and keeping Windows and other software updated with all of the latest security patches, should prevent infection from most known malware threats. However, the risk of a zero-day attack that includes a kernel-mode rootkit continues to pose the most serious security threat. The ability of a zero-day rootkit to hide itself from security software can make subsequent detection and removal extremely difficult, often resulting in re-imaging of the operating system, assuming that it is even possible to detect the malware infection. The fact that a kernel-mode rootkit could go undetected makes it difficult to fully assess the true scale of the problem.

One important step that can be taken in the fight against zero-day rootkits is to ensure that users log on to their computers with a standard user account. Most kernel-mode rootkits will simply fail to install when the user is logged on with a non-administrator account, as the successful installation of the rootkit will require write access to a secured area of the HKLM hive of the registry. To install under a standard user account the malware would need to discover and then exploit one or more vulnerabilities in the operating system, in order to gain higher privilege levels, making it much more difficult for the malware to infect or spread.

Avecto Privilege Guard enables organizations to implement least privilege, by ensuring users log on with standard user accounts and elevating the individual applications that require privileged access. Any zero-day attacks that are not detected by the anti-virus software will run with the user’s standard rights, making it difficult for the malware to compromise the kernel. Although least privilege can’t protect against all malware threats, it is an extremely effective line of defense against stealthy and persistent threats that attack deep inside the operating system.

On a final note, I would like to mention the innovative new technology that our partner McAfee launched at their Focus11 event in Las Vegas. McAfee DeepSAFE, which was jointly developed with Intel, enables McAfee to build hardware assisted security products. The DeepSAFE technology sits below the operating system, allowing it to detect hidden threats, such as stealth rootkits and Advanced Persistent Threats (APTs). McAfee Deep Defender is the first product to utilize the DeepSAFE technology and is managed with McAfee ePO software. McAfee Labs state that the stealthy malware threat is escalating and that they detect 110,000 new unique rootkits each quarter.

Here at Avecto we are delighted to be working closely with McAfee and we will soon be launching our ePO integrated version of Privilege Guard. I believe that the combination of least privilege with Privilege Guard and hardware-level protection with DeepSAFE, provides a major step forward in the fight against kernel-mode rootkits and other stealthy malware.

Technical personnel sometimes require access to domain controllers, maybe to perform maintenance connected to backup, patching or a one-off task. This leaves security administrators with something of a quandary, as most of the work likely to be carried out requires full administrative access to the DC, and in turn the crown jewels – Active Directory.

Let’s make it simple and start off by saying that it’s not possible to separate AD and administrator permissions on a regular DC. If you need to grant a user domain administrator permissions to complete some work on a DC, you must trust that person with full access to the AD domain. Read-only domain controllers (RODCs) do exactly what they say on the tin and host a read-only copy of the Active Directory database. Wherever possible you should deploy RODCs, as any domain user can be given permission to install and manage the server without privileged access to Active Directory.

Windows IT professionals often assume that the built-in Server Operators group in AD gives the equivalent of local administrator access to DCs without elevated rights to Active Directory. This is not strictly true and any kind of administrative permission on a DC can result in the user gaining privileges to AD. All built-in AD groups that end in ‘Operators’ are legacy groups and shouldn’t be populated unless you have an application that requires it. For example, if you need to grant permission to perform backup duties, create a new group and assign rights as necessary.

One approach you could adopt to grant admin privileges to DCs is to issue a unique username and password each time access is requested. The credentials are assigned to a technician for a given period of time and for an agreed piece of work. This information is recorded and permissions revoked at the end of the allotted session. Setting up the user account and recording the necessary logon session details is often done manually, although can be automated. The person requesting access is responsible for anything that happens during their logon session. Nevertheless, you still need to trust that person with Active Directory.

Depending on the type of work being carried out, a 3rd-party solution, such as Avecto Privilege Guard, could be deployed to allow a standard user to run only pre-approved applications with elevated privileges, greatly reducing the risk involved. Even if a technician must perform a task regularly on a DC, think twice before granting permanent permissions to sensitive production systems and always make sure that all actions are audited.

Microsoft provides a free utility which does just this – the Microsoft Baseline Security Analyzer, or MBSA for short.

Choose a type of scan or view previous scan results

The MBSA is designed to highlight potential security risks on endpoints and makes recommendations for remediation of these risks. Access to a local admin account is of course a high risk concern, and so this is one of the things it checks for.

Select your scanning options

It works by scanning each target endpoint for the number of entries in the Local Administrators group, which for any endpoint joined to a domain should only contain the Local Administrator user and the Domain Admins group. So if it detects more than two entries, it flags this in the graphical UI. From here you can drill into the report to display the actual group memberships.

Summary of all endpoint scan results

Summary of the scan results and details of the 'Administrators' test

In summary, you should have a good understanding of which users have admin rights before implementing least privilege. If you don’t already audit this, then MBSA can provide this information for you.

For more information and to download MBSA, visit the MBSA TechNet resource here.