Is protecting a desktop different than a laptop? Yes.

Is protecting a server different than a desktop or laptop? Yes

However, does this mean that we need a different vendor, product and console for each of these? Or, is it better to use a consistent set (palette) of controls to pick and choose from and just choose a different mix to protect different types of endpoints based on their needs? For example:

• All desktops and laptops need AV. Some servers need AV (general purpose file servers) and most organizations require AV on all Windows servers by policy.
• Application Control is more easily applied to servers which tend to be more static. However, some fixed desktop scenarios are well-suited to application control (e.g. call centers) and leading application control vendors are innovating in how they manage trusted change in desktop scenarios.
• Host firewalling is important to both, but tends to be more valued on laptops that move out from behind perimeter protection. Servers in the data center behind fixed firewalls may not need this at all.
• Deep packet inspection based host-based intrusion prevention (HIPS) is of value to both desktops and servers, but the ‘virtual patching’ capabilities of this style of protection tends to be more valued on servers that can’t be patched as frequently.
• Rules-based HIPS tends to be used more on servers where rules about normal application behavior are more easily defined
• Behavioral HIPS tends to be used more on laptops and desktops to augment traditional signature-based AV and protect from zero-day attacks because these devices routinely deal with arbitrary code. This isn’t as important on servers as they don’t routinely deal with arbitrary code and organizations don’t want to risk an occasional false positive.
• Servers are great candidates for file integrity monitoring. Few desktops will use file integrity monitoring, but I’ve had clients with desktops that fell in scope of PCI where they used file integrity monitoring on their desktops.
• Laptops are great candidates for full drive encryption, but some fixed desktop and server scenarios make sense for full drive encryption as well.

The set (palette) of controls is the same – AV, firewall, HIPS, FIM, application control, encryption, etc etc working together as a system. You pick and choose which controls are used and which policies are enforced based on the endpoint (desktop, laptop, server and increasingly mobile devices) and its usage scenarios. Think of the information security professional as an artist with a palette of colors/controls.

Do we need a different product/vendor/console for server security versus desktop security? Or a single product/vendor/console with the ability to pick and choose the appropriate controls and policies?

How does your organization handle this?

I’ve talked about this several times before – including here, here and here.

While it may not be feasible to remove administrator rights from all users, it is an absolutely achievable goal to continue to improve the percentage of Windows users running without administrator rights year over year for the foreseeable future. Make this your goal for 2012.

Case in point – I talked with a client today that had removed administrator rights from 90% of their users. This is a noteworthy achievement as they are only in the planning process of migrating to Windows 7. They had achieved this on Windows XP and for large numbers of XP-based laptop users. Impressive.

Better yet, I worked with this client on a strategy to move this to 95-97% using the migration to Windows 7 as a catalyst for further improvements – some coming from improvements in the Windows OS (like a new printer driver model) and some coming from the selective use of a third party tool for Windows privilege management.

If you are struggling with malware infestations and are considering switching out vendors, take a look first at removing administrator rights. For Gartner clients, I’ve outlined the best practices for achieving this in this research document.

Remember, if done correctly, removal of administrator rights does not have to equate to “lockdown”.

Full drive encryption should be considered mandatory for laptops and most organizations have implemented this – either with Windows 7 and BitLocker, by adding encryption into their endpoint protection platform contract or by purchasing a point solution.

However, there are several use cases where the use of FDE makes sense for fixed desktops:

1) For areas where physical security is lacking and there is a risk that the hard drive and/or physical machine may be stolen

2) For defense in depth as machines are retired to ensure that data is wiped completely. By ensuring that the key is destroyed, access to the data is impossible. Without the keys, they don’t have your data. This would supplement (and potentially replace) any manual wiping that is performed as machines are returned/retired/recycled/destroyed.

3) For protection of images in transit being shipped to remote locations – for example to remote offices.

With advances in hardware processing making the overhead of FDE nearly negligible and with the significant downward pricing pressure in the market (in the case of BitLocker. “free” if you are purchasing Software Assurance on the Windows OS), FDE may make sense for many of your fixed desktops as well.

If you are licensed under Microsoft’s Core Client Access License program, it now includes CALs for Forefront Endpoint Protection. For many organizations that are already licensed under Core CAL, this means that FEP is essentially “free”.

I’ve been getting dozens of inquires from large and small organizations in the last 6 weeks on whether or not Forefront makes sense for them. However, “free” doesn’t mean no cost. First, you have to be licensed under Core CAL. Second, you have to consider the cost of deployment and testing as well as the cost of removing whatever you have in place. Also, Microsoft has no solution for non-Windows platforms (as you might expect) and many organizations will be forced to use another type of solution to protect these systems.

There are many other pros and cons which I go into detail for clients in this research note that I just published:

Microsoft’s Forefront Endpoint Protection: Good but not Great

For some organizations, FEP will be a good solution. For others, it will be a not be a good fit. Which are you?

We’ve updated our advice to clients using SecurID tokens in this First Take.

For current customers, RSA has published guidance that focuses on putting in place better protection of the systems that maintain the userid-to-token mappings and of the token seed values.

However, the risk here is higher than it first might appear. Two thoughts:

1) Protection strategies absolutely must include better protection of endpoints where reportedly the hackers were able to obtain the user-to-token mappings using a keystroke-logger or Zues-like Trojan. It is typically much easier to target end-users as a weak link rather then enterprise servers. This problem is compounded when contractors, home users and other non-enterprise managed assets use SecurID for strong authentication. On these systems, the enterprise may or may not have a security stack present (like an endpoint protection platform), the users may run as administrators and the patching discipline is unknown. End-users are the weakest link and end-users coming from unmanaged devices make this even weaker.

2) The attack on RSA was an organized attack, likely a state-sponsored Advanced Persistent Threat. The assumption that the hackers would obtain the seed key values from RSA and then go target enterprises may be far too optimistic. It is quite possible that the hackers obtained at least some of the user-to-token mappings before the attack on RSA occurred, knowing that once the breach at RSA became public, enterprises would place stronger controls on the systems that contained the user-to-token mappings. In other words, we might be trying to close the barn door after the horse is already out.

Does this mean that IT Operations and Security are converging?

I believe “convergence” is too strong of a word to describe what it going on. Convergence implies that one or the other goes away. That isn’t the case here. IT Operations and Information Security are like Ying and Yang. A healthy but necessary tension exists between the two.

While there may be convergence of the infrastructure underneath that carries bits out to the endpoints (in this case, the SCCM servers and agent), this shouldn’t be confused with convergence of policy administration. In other words, while the operational infrastructure might be used to deploy and update the policy enforcement mechanism (the Forefront agent in this case), this doesn’t mean that the need for separation of duties of policy administration has gone away. Leveraging operational infrastructure for security policy enforcement makes sense as long as separation of duties is maintained.

“Integration”, Interoperability” and “Reducing redundant infrastructure” are much better ways to describe what is happening – and it’s not just with the security and management of endpoints that this integration and leveraging of common infrastructure is happening.

• Standard users can install and execute well-written software on XP and Windows 7. For example Google’s Chrome and Firefox install just fine when users don’t have administrator rights.
• With Windows 7, standard users can install printer drivers.
• With Windows 7 and AXIS (Microsoft’s ActiveX Installer Service), standard users can install ActiveX controls that conform to policy within Internet Explorer.
• With Windows 7, standard users can now perform most of the standard day-to-day Windows functions that they couldn’t do on Windows XP including such things as changing time zones, changing monitor resolution, looking at (but not changing) firewall configuration, renewing a DHCP address and so on.

Net/Net – removing administrator rights from Windows users is not “lockdown”. This leads to two pieces of advice:

1) If you are removing administrator rights during the migration to Windows 7, don’t call this “lockdown”. For some reason, the term “lockdown” rubs users the wrong way.    As an alternative, how about telling users they are receiving a “security-enhanced desktop”? Seriously, they aren’t administrators on their iPads or iPhones and you don’t hear too many complaints. We can achieve a similar outcome on Windows. For some situations, a third party tool for privilege management may be needed, but it can be done.

2) If you truly want a “locked down” environment where users cannot extend their workspace, you’ll need additional policies and controls to implement this such as Application Control / Whitelisiting technology.

I discuss how to successfully remove administrator rights from Windows users in detail in this research note for clients complete with a list of the top 14 or 15 best practices for this initiative.

1) The power of whitelisting. Call it what you may, but having Apple act as the steward of all applications via its App Store is a form of whitelisting (where the list of approved applications [whitelist] is defined by those that Apple approves to be posted). Whitelisting is an extremely powerful security concept that hasn’t been widely used by enterprise IT – yet. Could Apple do more in terms of security testing? Absolutely, but there hasn’t been a major malware outbreak or market demand (yet) to change the current level of application certification.

2) The benefit of users running without administrative rights. You don’t have “root” rights on your iPhone/iPad unless you’ve jailbroken the device. The vast majority of users won’t be compelled to do this because they can do everything they need as a “standard user”. They extend the device, customize their environment, download and install applications, and so on without knowing that they don’t have “root” access.

Think about it.  Even with the removal of administrative rights and with implicit whitelisting, the users don’t complain about being “locked down”. 

Imagine what we could do for enterprise Windows users with a similar model…

From my perspective the announcement that will affect the most enterprises from a security perspective was a change in licensing related to Forefront. Some history — in 2010, Microsoft reorganized the Server and Tools Business Unit placing the Forefront Endpoint team with the System Center Configuration Manager team. In December 2010, Microsoft shipped the version of Forefront (Forefront Endpoint Protection) that uses System Center Configuration Manager as the backbone for the distribution and update of Forefront’s antimalware engine and signature updates.

Now to the significant licensing change. Previously, Microsoft customers licensed under its Enterprise Client Access License Program (ECAL) had rights to Forefront EndPoint Protection. Microsoft has lowered the bar and included rights to FEP with its Core CAL. These changes are detailed on Microsoft’s web site. This will change the competitive dynamics in the endpoint protection platform market.

Other observations from the event:

1) Brad Anderson was clear that Cloud is a computing model, not a location and that the attributes of Cloud computing are what really matter – scalability and elasticity, self service, shared, automated, etc. Organizations want this in their own data centers, thus a large part of his keynote talked about how Microsoft enables private clouds with “Concero” – a new web-based portal for self-service by application owners.

3) It was interesting that in the keynote demo of Concero, the presenter commented on the usability of the UI stating “working within a web browser doesn’t have to be clunky” which received applause from the audience. However, all of this was built on Silverlight, but no explicit mention of Silverlight  (see observation #7 in this post) was made on Monday or Tuesday.

4) Microsoft’s AVIcode acquisition provides Microsoft application performance visibility, including potential security-related issues (in addition to things like performance and connectivity).

5) In competing with VMware, Microsoft made the following points multiple times in the keynotes to reinforce the areas which it believes are significant differentiators:

• Microsoft has in-depth knowledge and context (Brad Anderson used the word “wisdom”) of the OS
• With AVIcode instrumentation, Microsoft’s tools will have in depth knowledge and context of .NET applications (it’s all about the applications – they can’t be treated as black boxes)
• Microsoft’s management tools span Hyper-V, XenServer and VMware hypervisor based environments

Tomorrow’s keynotes are all about the client side manageability and the impact of consumerization. I won’t be there, but there will be security implications to many of these announcements as well.

This is incorrect.

Software that writes to the user’s data directory, and that doesn’t write to protected portions of the registry, can install correctly as a standard user, and an increasing number of enterprise software vendors are doing exactly this (e.g., Google Chrome and Mozilla Firefox).

If the good guys can do this, so can the bad guys. Indeed, malware writers can use the same techniques to install software targeted at stealing end-user-accessible data and personal information, even when users don’t have administrator rights.

If you really want to control what applications a user is allowed to install and execute, you will need to do more than just run them as standard users. For example, Application Control (aka whitelisting) is one approach that I frequently discuss with clients.

I talk about the ability of standard users to install software and other issues in this research note for clients that just published. In this research, my colleague, Mike Silver, and I provide a comprehensive set of best practices for removing administrator rights from end-users on Windows. In terms of “security bang for the buck” you can’t do much better than this and most organizations have specific projects underway to do exactly this using Windows 7 as the catalyst for the removal of administrator rights from end users.