Endpoint security is about ensuring that PCs and laptops are secure at all times – so what better way to do it than by ensuring that everything running on them is completely trusted?

Effective security policies aren’t only about detecting and stopping malware from running on PCs, or blocking spam from email servers. They’re also about finding an effective way of managing risk by controlling the traffic on networks and the applications on PCs. By whitelisting applications you’re gaining zero-day protection from unknown threats.

Use the file tools built into Lumension’s desktop management package to see what executables and DLLs have been found on a target machine, and which application groups they’re part of. You can see the secure hash Lumension uses to identify the application in order to let it run.

Application whitelisting is very different from blacklisting; the underlying philosophy is one of least-privilege operation, where ‘everything that isn’t explicitly permitted is denied’. It’s certainly harder work than running a blacklist, but what it does do is ensure that you know exactly what’s running in a network, and on which machines and by whom. There are also unexpected benefits. Deploying whitelists as part of the IT management policies you set up for customers can help with regulatory compliance, ensuring that the right individuals get the right applications for the right task. That’s why it’s now a mandatory requirement for some government organisations.

Whitelisting also helps reduce over-licencing. Instead of buying enough licences to cover an entire business irrespec-tive of who uses the apps, your customers will be able to purchase the exact number they need, adding additional licences only when they’re needed.

Lumension lets you group applications and their associated executable files, showing quickly what is and isn’t allowed for a user. You might want to give a power user access to all their machine’s administrative tools, while blocking iTunes.

While most security implementations look at locking down networks, application whitelisting is a re-perimeterisation technique. If a PC is locked down and using secure networks to connect to a server, then the main threats are things that the user does, or things that software does. You can use management policies to control users, and application whitelisting to handle software. It’s not only about managing software to reduce the risk of malware; by locking down the software your users can run you can also reduce the risk of your clients’ legal exposure – for example, preventing servers being used to run iTunes and storing terabytes of MP3s from unknown sources.

Many security tools look at how applications behave, monitoring how they use memory or looking at their network traffic. If you haven’t locked down applications, you’re at risk of some malware (or even just untested code) affecting data. By using application whitelisting tools, you’re preventing the unknowns from running and stopping unforeseen behaviours affecting your clients’ desktops, servers, networks and information.

Lumension application control

A future update to Application Control (due later in 2010) will add a new set of tools for viewing application data, in-cluding clear and concise views of the audit log for a PC. This will show what has been allowed, what was denied – and when.

Lumension’s Application Control is part of a suite of endpoint and patch manage-ment tools, which also include tools for managing data on connected devices like USB sticks and MP3 players. They share a single dashboard, and the features you see depend on the licence you’ve purchased. This is a powerful tool that works with one of the widest ranges of Windows operating systems possible – starting with desktop and server versions of Windows 2000 SP4 and supporting everything in between there and Windows 7 on the desktop and Win-dows Server 2008 R2, for both 32- and 64-bit versions. Platform support goes beyond the traditional, and there’s also support for applications running through Citrix or Terminal Server, as well as virtual servers and desktops.

Like most security and management tools, Application Control is a three-part product. There’s a management dash-board running on an application server where you can create and deploy policies, as well as getting reports on the current state of deployed applications. A database stores details of allowed applications, along with their digital signatures. Finally, an agent is deployed to desktops to monitor operations, and to manage a secure hash of the signatures of allowed applications (supporting offline operation).

Application Control has relatively little impact on PC performance. The client-side agent is a kernel driver, so it’s al-ways running. As soon as an application is launched, its digital signature is calculated and compared with the current policy for the device and for the user, and then allowed to run or blocked, depending on the current rule. If it’s com-pletely unknown, then it will be stopped automatically, which prevents users from downloading and running random applications from the Internet. If you’ve licensed Lumension’s other endpoint tools, the same agent will also handle any device controls you’ve defined.

There’s tight integration with Active Directory, so you can link Application Control policies to existing Active Directory group. This approach simplifies deploying policies to users, as once you’ve defined your groups and the application controls that go with them, all you need to do is add a user to an appropriate group to automatically apply Application Control rules, with no additional configuration needed. Lumension suggests creating application specific groups in Active Directory to simplify mappings. For example, you could create a Microsoft Office group for users who then would be given permission to run Office by Application Control. When a user needs to use Office you can add them to the group, and the appropriate Application Policies will immediately apply to them. Nesting child groups can give you fine control of the applications users can run, while minimising the management load.

Running the system is relatively simple, but getting started will take time. That’s because you’ll have to create all the application definitions and application groups for every executable that’s going to run on your clients’ machines. That initial setup time is one of the reasons why many security professionals prefer blacklisting techniques, as there’s no setup overhead. Lumension aims to reduce this overhead by providing templates for all supported operating systems with an OS-specific knowledge base ready to run. This approach gives you a clean starting point, where you can quickly tie OS-level and bundled applications to groups, so that, for example, only administrators get access to REGEDIT.

Building a whitelist for deployed software will still take time. We’d recommend starting with a clean-build PC, with a stock image and any core applications already installed. You can then use Application Control’s Scan Explorer to scan the target, and build an initial list of approved applications. If you’re using a software management tool to control distribution to client PCs, like Microsoft’s System Center, or Lumension’s own package and patch management tools, then you can use Application Control’s Authorisation Wizard to scan MSI packages, so you can add applications and updates to a whitelist before they’re deployed. Application Control integrates with WSUS, so once you’ve approved a package or a patch for deployment, it’s automatically added to the whitelist and users will be upgraded without any interruption to their work.

Once your initial whitelist is in place you’re ready to start deploying agents to your clients’ PCs, using Application Control’s built-in agent deployment tools. These give you a no-touch deployment option, so users don’t need to interact with the agent installer. It’s not a good idea to block everything from the start, as you’ll have probably missed critical business applications out when creating your initial whitelist. Application Control lets you start by running in a non-blocking audit-only learning mode, which lets you learn what’s running on the endpoints. Reports from this can then be used to add applications that are being used to the whitelist, as well as revealing what else is in use – from unauthorised IM tools, to demo software, to unlicensed copies of business productivity tools. Policies can be confi-gured during learning mode, before applying and locking down systems. New policies open things up, so there’s no real need for a test mode; the opposite approach from a traditional security model.

Black, white and grey areas

Even once you’ve turned on Application Control’s blocking tools, you can still operate flexibly. Trusted users are able to locally authorise applications, letting them install applications that aren’t the corpo-rate whitelist. Before they run an application for the first time, they’re presented with a dialog box informing them that the application is not approved, and asking whether they want to run it. Administrators can determine later if the ap-plication should be approved, and if not, it can be locked down. Alternatively, it can be added to a whitelist, and the user will be able to continue using it. This approach that tends to make users more responsible about what they install, as there is an element of trust in the process. It also works well in smaller organisations where there aren’t software deployment tools and patch approval processes – and where you want to quickly upgrade users to a new version of software to avoid a zero-day threat. Another option is to use Application Control’s path rules, which can be used to allow applications that run in known locations to run, even if their digital signature has changed. This approach works well for applications with automatic updaters, like Adobe Reader.

Application Control offers very extensive audit facilities, delivering detailed reports to the management console. You can use these as part of a helpdesk service; if a user reports being unable to run an application, helpdesk staff can examine reports and decide if the user should have access to that application. Approving an application or a user is as simple as right clicking and adding to an appropriate whitelist or group. You can define different levels of control for Application Control users. Some may be able to modify whitelists, while others can only create and view reports.

Where Application Control really excels is in its reporting tools. These take scan data from the database and application data from the knowledge base, and let you see differences between different machine scans. You can also quickly sort reports to see what applications and executables aren’t authorised, and what belongs to what application groups. Again, right click adds executables to the whitelist, and lets you pick the group you want to use. Adding an application to the knowledge base doesn’t make it automatically available to users; this is a way of understanding what’s currently deployed and what’s currently available for users – you’ll still be able to choose who is allowed to run the apps. If you need to examine the contents of Application Control’s knowledge base, use the Database Explorer. This lets you examine the files that make up an application, or an application group. Application groups can inherit access rights, once you’ve set up child groups.

Application Control’s Log Explorer is where you’ll do most of your whitelist configuration. There are templates for the most common reports, and you can use them to see what users do, with filters to help find the information you need quickly – and to help you make the appropriate policy decisions. Similarly the User Explorer shows which application groups which user has access to, and you can quickly create new groups and add users from a site’s Active Directory. There’s an application-centric view too. You can automate and schedule reports to give you daily or weekly updates on what applications are in use, and what users are trying to use. Reports can be generated as HTML, or in other formats including CSV, for use in other applications.

Lumension’s platform is highly scalable. In the largest deployments a central database server manages a farm of ap-plication servers. That’s not necessary for SMB deployments, where a single server hosting both a database and an application server is will handle most needs. If you want to make the system more resilient, you can add a second application server. This is a very powerful tool with a lot of excellent features, but customers will need to make the move to a more formal way of approaching what apps are in use.

Setting up AppLocker

Edit AppLocker rules (for executables, scripts, and installers) using Windows’ Group Policy Editor. GPEDIT stores rules as part of the Computer Configuration, and gives you simple wizards to help get started.

Publisher rules use digital signatures, which you can then tune to allow everything from a publisher, or just a specific application. Pick an application and use the slider to set the level of control you want.

AppLocker lets you choose what versions of an application can run. You can force an exact match, or allow newer or older versions. You can also use Exceptions to block specific versions of an application that are known security risks (or are the cause of lots of helpdesk calls!).

You can speed up getting started by using the default profiles that ship with AppLocker. They’re not particularly complex or secure – allowing everything in Program Files to run, for example – but they do give you a basic set of rules that can be tuned and deployed as required.

Microsoft AppLocker

Microsoft includes a basic application control service as part of Windows 7 (but only in the Enterprise and Ultimate editions) and in Windows Server 2008 R2. AppLocker is designed to only allow selected applications to run (beyond the OS and OS-bundled software). It’s probably best thought of as an extension of the existing software restriction capabilities in earlier versions of Windows, but now with better policy management tools and a simplified user interface, built on top of Windows Application Identity Service. Once AppLocker is enabled on a PC, you won’t be able to manage it with the older system.

You can set up AppLocker using GPEDIT locally, or from a Windows Server 2008 R2 system using Group Policy Management. It’s accessible under Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker.

AppLocker takes a rules-based approach to policy enforcement, with three sets of rules: one set for executables, one for installers, and another for scripts. It’s certainly easier to use AppLocker to build an application blacklist, but you can also use it to create and manage whitelists by making the default action to block anything that’s not been explicitly allowed by AppLocker. AppLocker’s default rules simplify things, giving you a known (if quite permissive) state to start from.

Executable Rules are used to block applications from running. Microsoft provides three ways of managing applications: by a manufacturer’s digital signature, by a hash of the applications’ binary, or by the path where it’s installed. You’ll need to have the applications you want to allow installed on a test machine, where you build the rules. In the Create Executable Rules wizard, start by defining the basic permissions for the application you’re writing rules for – whether it’s a rule allowing the application to run, or blocking it.

Set the basic conditions for the rule. Choose from the three options, depending on the application you’re writing a rule for. If you’re setting up a publisher rule you’ll need to first look for the original application, to find the application publisher’s digital signature. Once you’ve found the signature, you can choose the level of protection you want to apply. Set the slider to allow (or block) anything from that publisher, or for a specific product, or for a specific filename, or even a specific version. If you’re using version numbers in rules you can also determine if users can run older or newer versions of the application – or that specific version. There’s also the option to set exceptions, so if you want to allow every version of an application apart from version 1.1.8, then you can set up an exception to prevent that version from being run.

Path rules work by blocking specific files or folder paths. If you know that all Adobe applications go into Program Files/Adobe and you want to block Adobe tools from running, you can quickly set up a path rule for that specific folder, stopping everything there or in a sub-folder from being run. Alternatively you can set up a file hash to prevent a known application that isn’t signed from being run, no matter where it’s been installed. Using file hashes is a good way of stopping application from being run from USB drives, and it’s worth keeping a library of popular portable applications to hand to make it easier to quickly block them from your clients’ networks.

If you’re using AppLocker to whitelist applications, then you’re also going to need to manage installers. Once you’ve approved an application, update or patch for use, add a rule allowing its installer to run, and then distribute it to all the network users. You’ll also need to do the same for scripts, with AppLocker able to work with PowerShell, JavaScript, Visual Basic Scripts, and command line batch files. This last option may not seem that important, but as PowerShell becomes more prevalent, it’s going to become very important to manage what scripts run where, as they are now very powerful tools indeed.

Once you’ve created rules, you can publish them using Active Directory as Group Policy Objects. This lets you build rule sets for different groups and roles, and to merge and combine rules based on what tools a specific user needs to do their job. To make sure that you’ve got everything right, you’re able to run in an audit-only mode to ensure that everything works as you expect, before turning on AppLocker enforcement.