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

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.

If you operate a hotdesk or other shared workstation environment then there’s a good chance your users are regularly experiencing this problem, and historically there were three solutions:

1. Call IT Support and ask them to ‘unlock’ the desktop for you (local administrators are the only users who can force the logged-on session to logoff).
2. Hard reset the desktop (which can lead to data corruption, data loss, etc).
3. Grant computer users local admin rights.

None of these solutions were ideal, as they all came at a cost – either through increased helpdesk calls, or the hidden costs of users possessing excessive rights.

A new feature added to Privilege Guard 3.0, Shared Workstation Unlock, allows you to set policy on which end users are able to unlock a shared workstation or who is not allowed to unlock a workstation. So as well as empowering standard users, you can also restrict local administrators.

Shared Workstation Unlock is driven by Privilege Guard Policies, and leverages the flexible filtering rules that define when and where policy is applied. So granting or revoking Shared Workstation Unlock privileges can be based on any combination of:

• User name and user group membership
• Computer name or IP Address
• Date and time range
• Time expiry date

Configuring Shared Workstation Unlock is easy, and anyone accustomed with Group Policy settings should find the logic familiar. For any Privilege Guard Policy, open the Policy Options dialog and you will find a tri-state option under Workstation:

• Not Configured – Privilege Guard will ignore this policy and move on to the next policy.
• User can unlock a shared workstation – Privilege Guard will allow the user to unlock the shared workstation.
• User cannot unlock a shared workstation – Privilege Guard will prevent the user from unlocking the shared workstation.

Shared Workstation Unlock significantly reduces support costs by allowing standard users to unlock desktops in shared workstation environments without having to grant local admin rights.

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.

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.

Security is often viewed like an insurance policy – an expense that’s hard to quantify in terms of return on investment. But skimping on well secured endpoints or assuming that antivirus is enough to keep end users out of trouble is a false economy. Even if your company isn’t subject to regulatory compliance, properly secured systems still bring important advantages that shouldn’t be overlooked.

Anyone who’s run Windows Vista or 7 as a standard user will know that these PCs perform consistently, more reliably, are less prone to malware infection and rarely require support from an IT professional if compared to an equivalent system running with administrative privileges. Application whitelisting can further improve this record, significantly reducing problems caused by malware or application conflicts.

In an ideal world, users would be able to install any application in an isolated container without having to worry about the impact on system performance, malware infection or compatibility problems. And while the technology does exist to virtualize applications, it’s not yet mature enough that users can be left to choose what to install without some assistance from IT.

Striking a balance between a curated least privilege desktop, productivity and the ability to install approved applications on demand is the best way to provision fast, responsive and secure systems that enable users to be as productive as possible. Privilege Guard can help IT departments manage the balance between security and flexibility that is crucial in any least privilege deployment, and improvements in Privilege Guard 2.8 make it even easier for IT to manage privileges across multiple desktops.

But user productivity can be difficult to measure and proving that it provides a competitive advantage or positively impacts a company’s end of year results is not always easy. To get management buy-in, analyse the organization’s helpdesk logs, and give users who generate the most support tickets a fresh build of Windows with least privilege enabled from the outset. Once they’ve run with it for a couple of months and any initial problems have been ironed out, make a before and after snapshot of helpdesk calls to show the reduction in IT support costs. Extra uptime for end users can be translated into additional sales or improved customer service. The results will be significant enough to convince management that a secure desktop is less expensive to support and has added productivity benefits for users in exchange for minimal IT administrative effort and cost.

While these programmes may benefit tech-orientated employees in large companies like Google, for most organizations, passing responsibility for IT purchasing decisions to users, which in turn determines business policy, isn’t likely to be the best way forward.

When friends or colleagues ask for advice about purchasing a new notebook, what criteria do they usually give as a priority? Looks, style and other desirable ‘must-haves’ often outweigh technical considerations, such as whether the device has the necessary capabilities to run line-of-business software, if it can be supported by IT or whether the build quality is likely to make it durable enough for business travel.

Similar factors often come into play when users make decisions about what software to install on their work devices, with little understanding of the complex problems that may arise if software is downloaded from untrusted sources, left unpatched or causes a conflict with a line-of-business application.

Consider the current malware situation on Windows. Most infections result from poor decisions taken by users on what constitutes a genuine security update, an application that’s trusted and required for business purposes or being duped into clicking links that redirect to sites with drive-by downloads.

Now, with changes to the security model in Vista and Windows 7 that make the OS easier to use without administrative privileges, and with some help from third-party utilities such as Avecto Privilege Guard, IT departments can ensure that only qualified technical personnel are able to make changes to core system configuration. Standard user accounts reduce the number of security incidents, malware infections, calls to the helpdesk and the frequency at which operating systems have to be reinstalled.

While also limiting flexibility from users’ perspectives, the advantages of least privilege security can often be justified by lower total cost of ownership and the necessity to comply with regulatory codes. If required, flexibility can be handed back to users by deploying applications stores (app stores) and virtual machines (VMs), taking much of the risk out of installing software by protecting key system configuration.

Most users don’t know what’s best for the business, and neither should they be expected to. Complex security decisions or determining the best solutions for business problems must be taken in consultation with all the stakeholders. In the past, IT often dictated what devices and software would be supported, but this should always be a two-way process, involving users and conducted with a thorough understanding of business needs.

Windows 7 includes a number of security enhancements to help secure the desktop, including User Account Control (UAC) and AppLocker. I have posted about both of these technologies in the past, and although both are welcome additions to Windows 7, they can fall short when striving to deploy the least risk Windows 7 desktop.

If you are seriously considering UAC then you should change the default configuration to always prompt. The downside is that users will always be prompted when an application requires elevation, but the security risks associated with leaving UAC at its default setting in Windows 7 have been well documented. Regardless of the configuration setting of UAC, you will still be surrendering control of the desktop to the end user, because UAC requires the user to either log on with local admin rights or to have access to an account with local admin rights.

In order to create the least risk Windows 7 desktop users should log on with a standard user account and not have access to an account with local admin rights. If a user requires access to applications that require local admin rights then a solution like Privilege Guard will provide you with the granularity to assign these rights directly to the applications that require them, avoiding the need to give up complete control of the desktop to the user.

In addition to ensuring users log on to their desktop with a standard user account there are still more steps that should be taken to create the least risk Windows 7 desktop. Many of these steps may be obvious, but are still worth a mention, such as anti-virus protection at the endpoint and the use of Group Policy to harden many elements of the desktop configuration. For more information on Implementing Windows Security with Group Policy you will find a white paper by Derek Melber, Group Policy MVP, in the resources section of the Avecto website.

For those that are truly serious about locking down the desktop there is one last step that can be taken, which is application whitelisting. Many organizations are hesitant to adopt this approach, as there is a fear that the amount of time to configure and maintain such a solution outweighs its benefits. This is not necessarily the case and depends on the approach you take to application whitelisting. If you take a purist approach and build up a database of hashes for every application then there is no doubting that the solution can become time consuming and costly to maintain, but there are more pragmatic approaches to application whitelisting that can provide the same security benefits with far less ongoing maintenance.

AppLocker is available with Windows 7 (assuming you are using the Ultimate or Enterprise editions), which provides a Group Policy based application whitelisting solution. I have written about the pros and cons of this solution in a previous post, but I strongly recommend that you assess its capabilities, as it may be adequate for your environment, and it’s a big improvement over its predecessor, Software Restriction Policies.

If, however, you feel that AppLocker lacks the flexibility and control that you require then Privilege Guard’s application control capabilities provide a number of benefits over and above AppLocker, including the option of being either user or computer centric, whereas AppLocker is computer centric. The ability to block an application or simply warn and audit, enables Privilege Guard to handle more demanding scenarios. With broader application support, corporate end user messaging, a more flexible rules base, and the ability to deal with privileged applications, including software installers, Privilege Guard is the ideal solution if you are looking to implement the least risk Windows 7 desktop.

For more information, refer to The Least Risk Windows 7 Desktop.

AppLocker can ensure that users are only allowed to run authorized executables, installer packages and scripts. It provides a good selection of rules, including filename, publisher and file hash. In addition, it is possible to identify applications based on their file properties, such as product name and version, although this capability is restricted to signed applications.

The lack of support for management consoles and control panel applets, introduces a slight security concern, as unauthorized snap-ins and applets may be launched by the user. Other areas of Group Policy can be configured to hide control panel applets, but this does not stop a rogue control panel applet from actually running. Management console snap-ins can also be controlled through Group Policy settings, and although this does go further than superficial hiding of snap-ins, the whitelisting of third party snap-ins could prove challenging, so it’s a shame that AppLocker can’t control snap-ins through the restriction of msc files.

Although AppLocker can handle software installation packages, a high proportion of software installers will require local admin rights to install. Granting local admin rights to a user will make any attempt to control application execution a futile undertaking, as the user will effectively have complete control over their desktop, and so the white listing of software packages with AppLocker is severely limited.

Where AppLocker really disappoints is in its end user experience. The end user message that is displayed when an application is blocked can’t be configured, and so the IT department are not able to convey a meaningful message to their user base when an application is blocked. This is further compounded by the lack of any method for a user to request access to an unauthorized application. It’s highly unlikely that the IT department will get application control policies configured correctly first time, and so the lack of informative messaging and a user feedback mechanism will make the ongoing fine tuning and maintenance of policies more challenging.

The application of AppLocker to more advanced users, such as technical users or laptop users, could prove problematic, as applications can only be blocked, which may prove too restrictive and lead to productivity issues. The ability to warn and audit, as opposed to blocking, would have made it possible to apply AppLocker policies to a much broader range of users, but this capability is sadly lacking.

As with most of Microsoft’s built-in system management tools, AppLocker provides no reporting capabilities, which could make it difficult to fully assess the impact of the applied policies.

There is no doubting that AppLocker is a big improvement over Software Restriction Policies, but it still falls short in a number of areas, which may restrict its adoption to smaller implementations of task based workers, where users require little flexibility in their job role. As a user’s requirements become more complex, AppLocker could prove difficult to apply without severely compromising an end user’s productivity and creating a burden on the IT department to constantly update policies.