Application Control for Windows Desktop Best Practices ... · Application Control for Desktops Best Practices Guide 1.0 Page 7 technology), assist in reducing this window of vulnerability

Application Control for Windows Desktop

Best Practices Guide Version 1.0

Application Control for Desktops Best Practices Guide 1.0 Page 2

Contents

Contents ........................................................................................................................................................... 2

Summary .......................................................................................................................................................... 5

Understanding the problem ............................................................................................................................... 5

The number of new threats ............................................................................................................................ 5

The speed of propagation .............................................................................................................................. 5

Zero-day attacks and targeted malware.......................................................................................................... 6

The motivation behind malware ..................................................................................................................... 6

The impact of providing protection ................................................................................................................. 6

Limitations of traditional anti-virus solutions .................................................................................................... 6

Endpoint protection .................................................................................................................................... 6

Interpreting scan results ............................................................................................................................. 7

Control and stability.................................................................................................................................... 7

Users with administrative rights .................................................................................................................. 7

Visibility into enterprise applications ............................................................................................................ 7

Conclusion ................................................................................................................................................. 8

Application Control characteristics ..................................................................................................................... 8

The inventory and the whitelist ....................................................................................................................... 8

Enabling a dynamic whitelist .......................................................................................................................... 9

The Inventory and Global Threat Intelligence.................................................................................................. 9

Memory protection features ......................................................................................................................... 10

Expanding control........................................................................................................................................ 10

Solution integrity .......................................................................................................................................... 11

Conclusion .................................................................................................................................................. 11

Modes, functionality and switching................................................................................................................... 11

Disabled mode ............................................................................................................................................ 11

Enabled mode ............................................................................................................................................. 12

Enabled mode with self-approval .............................................................................................................. 12

Observe mode ............................................................................................................................................ 12

Update mode .............................................................................................................................................. 12

Switching mode ........................................................................................................................................... 12

Application Control in action ............................................................................................................................ 13

Protection ................................................................................................................................................... 13

File-based protection ................................................................................................................................ 13

Memory protection ................................................................................................................................... 14

Activity ........................................................................................................................................................ 14

Visibility....................................................................................................................................................... 15

Control and stability ..................................................................................................................................... 15

Users with administrative rights ................................................................................................................ 15

Pilot or evaluation plan .................................................................................................................................... 16

1. Define and document objectives............................................................................................................... 17


2. Establish success criteria ......................................................................................................................... 17

3. Define the approach ................................................................................................................................ 18

Roles and responsibilities ......................................................................................................................... 18

Administration .......................................................................................................................................... 18

Pilot schedule .......................................................................................................................................... 18

Types of testing ....................................................................................................................................... 18

4. Identify resources .................................................................................................................................... 19

Personnel ................................................................................................................................................ 19

Management system requirements ........................................................................................................... 20

Endpoint selection .................................................................................................................................... 20

Identifying candidate endpoints ................................................................................................................ 21

5. Understand and document risks and mitigations ....................................................................................... 22

Typical risks ............................................................................................................................................. 22

Mitigations ............................................................................................................................................... 24

6. Select and customize policies .................................................................................................................. 29

Overview of policy types ........................................................................................................................... 29

Application Control Options (Windows) policy ........................................................................................... 30

Understanding Application Control rules policy .......................................................................................... 31

Application Control Rules (Windows) policy .............................................................................................. 37

Configuration (Client) policy...................................................................................................................... 43

Exception Rules (Windows) policy ............................................................................................................ 43

Application Control features...................................................................................................................... 44

Self-approval ........................................................................................................................................... 48

Expanding control .................................................................................................................................... 49

7. Install Application Control......................................................................................................................... 50

Evaluation and licensed software .............................................................................................................. 50

Preparing ePolicy Orchestrator ................................................................................................................. 51

The installation process ............................................................................................................................ 51

Installation with ePolicy Orchestrator ........................................................................................................ 51

The enablement process .......................................................................................................................... 51

Enabling with ePolicy Orchestrator ........................................................................................................... 52

Uninstalling with ePolicy Orchestrator ....................................................................................................... 52

Uninstalling manually ............................................................................................................................... 53

Upgrading from an evaluation version ....................................................................................................... 53

8. Test and observe behavior ....................................................................................................................... 53

Endpoint testing ....................................................................................................................................... 53

Generation of observations....................................................................................................................... 53

Behavior monitoring ................................................................................................................................. 54

9. Review results ......................................................................................................................................... 54

No observations shown ............................................................................................................................ 55

Few or many observations shown ............................................................................................................. 56


Unexpected behavior or conflict observed at endpoint ............................................................................... 56

Gathering information to assist support ..................................................................................................... 56

10. Success criteria achieved ...................................................................................................................... 57

11. Tune policy ............................................................................................................................................ 57

Tuning process overview .......................................................................................................................... 57

Generic launcher processes ..................................................................................................................... 57

Reviewing observations ........................................................................................................................... 58

The observations interface ....................................................................................................................... 59

Example observations .............................................................................................................................. 66

Reviewing Inventory ................................................................................................................................. 68

12. Switch to protection mode ...................................................................................................................... 69

Selecting a protection state ...................................................................................................................... 69

Implementing protection states ................................................................................................................. 70

Delivering protection states ...................................................................................................................... 70

Periodic review and maintenance ............................................................................................................. 71

Testing Application Control.............................................................................................................................. 71

Testing protection mechanisms .................................................................................................................... 71

Best practice................................................................................................................................................... 72

Project planning .......................................................................................................................................... 72

Exception handling ...................................................................................................................................... 73

Deployment ................................................................................................................................................. 73

Upgrades .................................................................................................................................................... 73

Whitelisting and Enablement ........................................................................................................................ 73

Policy .......................................................................................................................................................... 73

Observations ............................................................................................................................................... 74

Reporting and GTI ....................................................................................................................................... 74

Administration ............................................................................................................................................. 74

User actions ................................................................................................................................................ 74

ePolicy Orchestrator queries ........................................................................................................................ 75

MAC-D: Candidate endpoints (32-bit) ....................................................................................................... 75

MAC-D: Candidate endpoints (64-bit) ....................................................................................................... 76

MAC-D: Observation count per endpoint. .................................................................................................. 76

Acknowledgements ......................................................................................................................................... 78

About the Author ............................................................................................................................................. 78

About McAfee ................................................................................................................................................. 78


Summary

McAfee Application Control for Desktops can be used to extend and enhance the protection provided by

McAfee VirusScan Enterprise and other endpoint protection technologies to desktops, notebooks and

the like. Rather than looking for the known bad, Application Control uses whitelisting techniques to

protect an endpoint, typically a corporate desktop or laptop, by allowing only the known good to run.

This approach reduces the need to constantly chase updates to keep up with the ever increasing tide of

malicious software. Application Control does not need to know, or even care about malicious software –

if an application is not on the whitelist for whatever reason, it is prevented from executing, and the

endpoint is safe.

However, in order to successfully deploy any whitelisting solution, the protected endpoint must be

allowed to make authorized change. For this to be implemented effectively, two challenges need to be

overcome. The whitelisting solution must support the necessary change mechanisms, and the change

mechanisms must be well understood and limited.

Technology can solve the first problem - McAfee Application Control offers a wide range of mechanism

for authorizing change. The second challenge - that of ensuring that the endpoint is suitable for a

whitelisting solution involves looking at the role of the endpoint.

If the endpoint being protected is created as a Consistent or Common Operating Environment (COE) or

Standard Operating Environment (SOE) build, running a standard set of applications, software updates

and service packs, then this type of endpoint is typically suitable. Whitelisting is an excellent choice for

fixed function desktops, whether physical or virtual. If the user is a standard user - they do not have

administrative rights, they use only standard software, and have well defined work styles, then again,

this environment is a good fit for a whitelisting solution. If you have an environment where the end user

requires some level of admin rights, whitelisting is not an appropriate alternative.

However, in cases where either the endpoint or user characteristics stray from COE/SOE or fixed

function environment, whitelisting may not be appropriate. Significant effort could be required to manage

those systems with any whitelisting solution. In those cases, it is recommended that they are not the first

systems to be whitelisted, but rather they are considered for whitelisting once the solution has been

deployed to more appropriate systems.

Note that for server end-points McAfee offers a separate product called McAfee Application Control for

Servers.

Understanding the problem

The number of new threats

Malware in one form or another has existed for the best part of thirty years. Just as technology has

evolved from bulky mainframes to pocket computers, malware has evolved from the viruses and Trojans

seen from 1982, to sophisticated malware designed to infect secure isolated networks, invisibly persist

over extended periods, and even cause physical damage to computer controlled hardware. However,

probably the most significant change has been the volume of malware released on a daily basis. From

1997, where approximately 50,000 unique samples existed in the Dr. Solomon’s malware zoo, to 2013,

where approximately 100,000 samples are seen each day, or approximately one new threat every

second.

The speed of propagation

As more devices are connected together through networks, intranets and the Internet, the power of

those devices increases. As more and more services are delivered through the cloud, reliance on

interconnectivity grows. One immediate side effect is the expansion of available bandwidth and the

speed of connectivity – more can travel faster. Malware authors have developed and adapted malware

to take advantage of these changes. Twenty years ago it frequently took malware a month to traverse

an office as floppy discs were exchanged to share data; today threats travel the globe in seconds.


Zero-day attacks and targeted malware

In contrast to the 100,000 new threats seen each day, there is a growing trend in targeted attacks –

attacks limited to a small number of specially selected recipients. These attacks are almost always zero-

day, i.e. the attack is new and unknown to anti-malware vendors. These attacks are typically highly

sophisticated, perhaps using multiple zero-day vulnerabilities, employing many techniques to infect or

compromise their targets, with a very specific agenda. The key characteristic of these attacks is that

since they are using new code, no signatures exists to identify the malware, and so they go

undetectable by the pattern recognition techniques used by anti-virus software.

The motivation behind malware

The motivation of malware authors has changed significantly in the last 5 or so years. The idea of a 17

year old with no girlfriend writing the next big threat has come and gone. Three key motivations found to

exist today are:

Financial gain, where the purpose of the attack may be to steal information that can be used directly

to obtain money, to steal the resources of a system that can later be sold on, or to place a system

into a state where the user is forced to part with money in order to ‘protect’ themselves, or recover

encrypted data;

Theft of data, which may be used to gain competitive advantage, or may be sold on;

Hactivism, where the attacker believes they are contributing to the common good, by taking action

against an organization.

The impact of providing protection

Anti-virus software is often blamed for system slowdown. However, when the role of anti-virus software

is examined, it is easy to understand why it can have a significant impact on some types of systems.

Anti-virus operates by examining each and every file it is configured to do so, and comparing these

against a signature set. This signature set is large and growing. At time of writing, McAfee detected

approximately 115 million unique samples of malware. Whilst optimization takes place, the impact of

examining each file for potentially millions of patterns, can be significant, and this is reflected in resource

consumption on the endpoint. In addition, the signature set needs to be updated ideally on a daily basis.

Due to its size, the act of integrating a delta file into the main signature set can again use considerable

resources. Finally, a full system on-demand scan can amalgamate the typical resource usage of a

background on-access scan but in a very compressed time interval, and again, have significant impact

on an endpoint. Where a virtual desktop environment exists, and hardware, especially disk hardware is

shared, the impact can increase by an order of magnitude.

Limitations of traditional anti-virus solutions

There are a number of limitations when using traditional anti-virus solutions to protect against todays

threats.

Endpoint protection

File protection

McAfee Labs see approximately 100,000 new threats per day. In order to provide protection against

these, either signatures or heuristic detection is required. Malware authors are aware of heuristic

detection, and often use sites such as VirusTotal (http://virustotal.com) to ensure that new variants of

malware cannot be detected using heuristic techniques. If detections do occur at this stage in malware

production, then steps can be taken to further refine it, to make it undetectable using existing anti-

malware products. Often this approach involves automation to make the creation of unique malware

painless for its authors, and this helps explain why so much malware can be produced each day.

Therefore detection often relies on signatures. Given the rate of malware production, the speed of

distribution, and the operational constraints of many organizations, the distribution of new signatures

may take some considerable time – and open a large window of vulnerability. Cloud-based protection in

the form of McAfee Global Threat Intelligence (GTI) File Reputation, (and other vendors equivalent

http://virustotal.com/


technology), assist in reducing this window of vulnerability to new threats, but this can only go so far. In

order to produce a signature, whether it is hosted on the endpoint or in the cloud, the malware needs to

be seen and analyzed by McAfee Labs. So, how to deal with zero-day malware, including targeted

attacks?

Memory protection

As malware authors adopt new techniques, non-file based attacks have increased in popularity. Where

no file is involved, traditional signatures are ineffective, since there is nothing to scan. Some memory

protection is provided by many traditional endpoint vendors, but this is often designed to supplement

signature-based protection, rather than provide protection in its own right. For this reason it often offers

only limited protection.

Interpreting scan results

Whilst it may be apparent to most readers, it is worth reinforcing the point that anti-virus software will

scan files for known or identifiable malware. The results of this scan will be one of:

Infected file – The AV product has scanned a file and found a positive match with a known piece of

malware;

Potentially infected file – The AV product has scanned a file and found a potential but not definitive

match with a known piece of malware;

No infection found – The AV product has scanned a file and found no match with any known piece

of malware.

No infection found is often misinterpreted as meaning the file is clean. This is most definitely not the

case! This result simply means that with current information no infection can be found, rather than no

infection actually exists. For example, a zero-day infection may be present. It is for this exact reason that

each and every time new signatures are loaded on to an endpoint, every file on that system is

rescanned, either on-demand or as it is accessed. This is a highly inefficient approach to providing

protection.

Control and stability

Traditional anti-virus acts as a one-time border guard. If an application is not found to contain an

infection, then it is allowed to execute, and perform any action that is allowed under its Windows

permissions and rights. These actions may not be in any way malicious, but may still be detrimental to

an endpoint. A poorly written non-malicious application can crash an endpoint; a program that replaces

a shared DLL may install an incompatible version that causes other applications to fail; a rogue software

install may contravene acceptable usage policy by introducing Bit Torrent traffic to the network, etc. In

all of these cases anti-virus software offers no control or visibility.

Users with administrative rights

Whilst it is always preferable to assign users the minimum permissions required to perform their

function, for older applications especially, local administrative rights may be required. However, when

this right is assigned to a user account, highly complex configuration is required to control how this right

is used, and for this reason, typically no controls are put in place. As administrator, the user can then

add and remove software at will. In this situation anti-virus software offers no control. This problem is

exacerbated by the fact that if a user does inadvertently encounter unrecognized malware, then when

executing, that malware can inherit administrative rights.

Visibility into enterprise applications

Traditional anti-virus software will alert when it encounters a detection. It has no knowledge, nor cares

about applications, executables, library files or other file types that are not recognized as being bad.

This is by design, and is not in any way a shortcoming from an anti-malware protection perspective.

However, this type of background information can be useful to many organizations. Consider a situation

where a new piece of malware is encountered, or a non-malicious but unwanted application was found


to exist on an endpoint. How useful would it be to know exactly which other endpoints within the

organization were infected with this malware or running this application?

Conclusion

Traditional anti-virus software is effective against know threats, but largely ineffective against zero-day

and targeted attacks. One challenge is keeping ahead of the ever expanding number of known threats,

especially given the speed at which they propagate, and the diverse and distributed nature of

organizations networks and endpoints. Anti-virus software is inefficient from the perspective of having to

consume ever greater resources as it is expected to check for ever increasing volumes of malware, and

then re-check each and every time an update occurs. Anti-virus software provides little if any protection

against undesired and ad hoc changes to an endpoint which can impact on operational stability. Where

administrative rights must be granted to non-administrative users, further loss of control occurs, and can

put endpoints at increased risk. In addition, despite the fact that anti-malware sees each and every file

on an endpoint, it does not offer up any extra information that may be useful in planning or dealing with

outbreak situations. Whilst anti-virus software was ‘the solution’ when viruses first appeared, its

effectiveness is diminishing. To retain the same level of security that was once offered by anti-virus

software, endpoint protection needs to be supplemented with more proactive technology.

Application Control characteristics

The inventory and the whitelist

The inventory comprises of a list of applications authorized to execute on a given endpoint, and those

files on the endpoint not authorized to execute. It contains the file name, the full file path, and the SHA1

checksum of each file. The whitelist is the portion of the inventory that is authorized to execute,

combined with those applications explicitly configured to execute using other methods, (such as

location, file characteristics, checksum or certificate). In this case, and throughout this document,

‘applications’ refers to all Portable Executable (PE) files, 16 bit executables, sys, and pif, and the

following script files: ps1, vbe, bat, cmd, and vbs. This default list can be expanded for instance to

include Java class files or any other interpreted language.

There are two approaches to creating the whitelist. The first and original method adopted by whitelisting

vendors was to attempt to create and manage a central whitelist that contained every possible

authorized application to be used on any protected system. Through painful experience this approach

was found to fail in almost all cases – it took a massive amount of time to collect and collate, and

inevitably uncommon applications or versions of applications were omitted from the list, which resulted

in failed deployments. The second approach is to derive each endpoint’s whitelist from the endpoint

itself. In this way the whitelist can be gathered in minutes not weeks, and is always able to capture those

uncommon applications or non-standard versions.

The individual endpoint inventory creation process is used by McAfee Application Control and involves

scanning of each fixed disk present on an endpoint. Removable storage, such as CDROMs DVDROMs,

or flash drives are not scanned, and neither are network drives. An inventory file is created for each

volume or drive letter, and contains each applications file fingerprint, the filename and the full file path.

This is then stored locally and protected by Application Control, and forms the basis of the whitelist. This

process is often referred to as solidification, and the files contained within the inventory as being

solidified. The implicit assumption here is that all files present on an endpoint are safe and should be

authorized. But what if this is not the case?

Part of the inventory creation process involves passing the details of each endpoint’s inventory contents

back to the ePolicy Orchestrator (ePO) server. Once available to ePO, McAfee GTI provides a cloud

trust score for each application and binary file. The trust level indicates if the file is a good, bad, or an

unknown file. The trust score ranges from a value of 1 or 2 representing known bad files, (such as a

trojan, virus, or potentially unwanted programs or PUPs, 3 indicating an unknown and hence

unclassified file, to a value of 4 or 5 representing known and trusted good files.


Enabling a dynamic whitelist

The whitelist contains a list of authorized applications. In most environments the applications, DLLs,

scripts and other files protected by Application Control will change periodically. This may be the result of

a Windows update, a new application being deployed, an existing application be upgraded, patched or

removed, or even because a particular process on the endpoint creates scripts dynamically to

implement changes to the endpoint. Aside from planned changes to the whitelist, there are occasions

when the whitelist may want to be changed manually. If an unwanted application is discovered on one or

more endpoints, the administrator may wish to prevent this file from being used, and so remove it from

the whitelist. Alternatively, if a new utility is being introduced to desktops, the admin may choose to allow

this application manually, and add it to the whitelist.

All of these cases require change to the whitelist. If all of these changes were to be made manually they

would incur significant administrative overhead, and in all but the most fixed environments, render the

solution impractical. Therefore a number of different techniques are available to allow the product to

automatically cater for changes made to the system, as long as these changes are made using an

approved method. These methods are described below.

Named processes that are part of the existing inventory and that are authorized to make changes to

the whitelist when executing are known as ‘Updaters’.

X.509 certificates that are trusted by the organization are known as ‘Publishers’. Applications

signed by these publishers that are not on the inventory are allowed to execute. Additionally,

applications signed by publishers designed as updaters, that are not on the inventory are allowed to

execute and are granted an additional right - they are allowed to make changes to the whitelist.

Applications that are used to install software on to an endpoint are known as ‘Installers’ and are

granted the right to both execute and to make changes to the inventory. One reason they are

explicitly authorized to execute, is that they may not have been present on the automatically

generated inventory of an endpoint, e.g. if they are located on a network drive or a CDROM.

Trusted directories are those local or UNC paths implicitly trusted. Anything placed in these

locations are permitted to execute. In a similar way to publishers, trusted directories identified as

updaters are granted the additional right to make changes to the whitelist.

Trusted users are local or domain users or groups of Active Directory users, authorized to make

changes to the whitelist. These users may, for example be members of the IT support team that are

tasked with fixing problems on desktops.

All of the above methods allow automatic changes to be made to enable a dynamically changing

whitelist, as long as the changes are performed according to pre-defined rules. In addition, changes may

be made in a more manual fashion through the use of explicit allow or ban rules that either allow

unlisted applications to execute, or override authorized applications and prevent them from executing,

respectively.

In addition, changes to the inventory may occur through the use of the ‘Observations’ interface, covered

later. This allows individual files to be added to the inventory of an endpoint. The ‘Inventory’ interface

within ePolicy Orchestrator allows files that reside in the inventory of an endpoint to be switched from an

allowed to a banned state, and vice-versa.

Finally, Application Control provides an option to allow self approval. If enabled, users can authorize

changes that would otherwise be blocked, by providing a justification, and so change the whitelist. This

approval is reported back to the management system, and can be either accepted and added to policy,

or overruled by the administrator.

The Inventory and Global Threat Intelligence

McAfee Global Threat Intelligence (GTI) file reputation is McAfee’s comprehensive, real-time, cloud-

based multi-vector reputation service that enables McAfee products to protect customers against both

known and emerging threats.

As a background process ePolicy Orchestrator will receive the inventory details from each endpoint

running Application Control. These will be looked up against the McAfee GTI cloud database, and the


results made available within ePolicy Orchestrator. GTI reputation can be viewed from Menu |

Application Control | Inventory, and this interface groups applications according to their status of good,

bad or unclassified. From this interface, in addition to viewing application and file reputation, the

administrator gets immediate visibility of the endpoints on which each file exists with either an allowed or

a banned status. Applications can be authorized and banned directly from this interface, so if a bad file

is identified on one endpoint, it can be banned throughout the network in a few clicks.

Memory protection features

Inventoried items are protected within the file system, but Application Control will also protect images

loaded in to memory. Application Control offers multiple memory protection techniques to prevent zero-

day attacks. These techniques enhance native Windows features or signature based buffer overflow

protection. They are available on Windows 32 and 64-bit operating systems. At a high-level, the

available memory-protection techniques stop two kinds of exploits:

Buffer overflow followed by direct code execution

Buffer overflow followed by indirect code execution using return-oriented programming

Application Control provides four basic memory protection techniques:

Critical Address Space Protection or CASP provides protection against code running from

non‑code areas of memory on 32-bit endpoints. This is an abnormal event that usually signifies a

buffer overflow attack is being attempted. CASP allows code to execute, but prevents it from

making any useful API calls, and so renders the attack ineffective

No Execute, or NX uses the Windows DEP technique, (which is available exclusively on 64-bit

systems), to prevent code from being run from non‑executable memory regions. In most cases, this

represents is an abnormal event that occurs when a buffer overflow happens and the exploit

attempts to execute code from such a memory region. NX provides granular bypass capability and

raises violation events when an attack is detected.

Virtual Address Space Randomization, or VASR, complements and enhances the native Windows

Address Space Layout Randomization (ASLR) technique available, and protects endpoints that do

not support ASLR. Many exploits expect useful functions or data to be located at fixed addresses.

VASR provides protection against such attacks, (including ROP-based attacks), by randomizing the

location of the stack or heap in each process and by randomizing the location of code in memory.

This in turn, prevents transfer of control to a static memory address which could be hardcoded in to

the exploit.

Forced DLL Relocation forces relocation of Dynamic Link Libraries (DLLs) that have opted out of

Windows' native ASLR feature and are deliberately not randomized by the operating system. This

opt-out characteristic is often utilized by attackers using modern exploitation techniques such as

return-oriented programming or ROP exploits and just-in-time compilation or JIT exploits. Forced

DLL Relocation provides protection in these cases.

The ‘Buffer overflow followed by direct code execution’ technique can be mitigated by Critical Address

Space Protection and No Execute protection. Attacks using a buffer overflow followed by indirect code

execution using return-oriented programming can be protected by Virtual Address Space Randomization

and Forced DLL Relocation.

Expanding control

Application Control provides control over a number of different types of files, referred to collectively as

applications. The default list is discussed in the earlier section entitled ‘The inventory and the whitelist’.

However, this list can be expanded to include other types of interpreted languages, such as Java, Perl

and Ruby. For details of how this is achieved see the sub-section entitled ‘Expanding control’ in the

section entitled ‘Select and customize policies’.


Solution integrity

Application Control provides a number of self-protection mechanisms:

Application Control cannot be uninstalled whilst running in enabled mode;

The ‘sadmin’ command line interface which can be used to switch operating mode locally requires

administrative rights to use, and is protected with a password that is configured within the Solidcore

6.1.0: General | Configuration (Client) policy. In addition, a separate optional password can be

specified to be used to confirm each actionable command, using the sadmin passwd command;

The ‘Integrity’ feature protects Application Control executables, log files and registry values from

modification or deletion when this feature is enabled, and the product is running in enabled mode. It

is strongly recommended that this feature is not disabled;

The inventory file is protected from modification by Application Control. This file is obfuscated, and if

modified outside of Application Control, then an ‘Inventory corrupted’ event is generated and

reported back to ePolicy Orchestrator.

Conclusion

Application Control is highly effective against zero-day and targeted attacks. Whilst anti-malware

solutions need to be constantly updated, Application Control has no concept of signatures and simply

needs to be made aware of any changes to the authorized change mechanisms. Since Application

Control maintains a relatively small list, (a few thousand entries within the whitelist versus many millions

of items within an anti-virus signature file), both memory and CPU overhead are insignificant compared

to anti-malware solutions. The additional stability and visibility of authorized change and blocked

attempts at unauthorized change, can provide useful in anticipating problems rather than simply reacting

to them when reported by the anti-malware solution. Overall, Application Control forms a valuable layer

of protection within a defense-in-depth strategy.

Modes, functionality and switching

Application Control operates in and can switch between one of four modes:

DisabledMode

Enabled Mode

Observe Mode Update Mode

Figure 1: Operational modes and switching

Disabled mode

The Application Control filter driver and kernel components are not loaded, no protection is active, and

Application Control should have no impact whatsoever on the endpoint. This mode is present upon

installation prior to any configuration having been applied. In order to enter and leave this mode, a

reboot is required. Hence typically the product is not placed in to this mode once it has been configured

and changed to another operating mode. One reason for not switching to disabled mode, (unless

Application Control is to be permanently removed), is that whilst the endpoint is running in this mode,

since the product is not active, any changes to applications on the endpoint will be permitted, yet the

inventory will not be maintained. A result of this is that the whitelist will not reflect the changes on the

endpoint, and so changed files will not be permitted to run once Application Control is re-enabled. If

moving to disabled mode is unavoidable, before returning to enabled mode, the endpoint should be


placed in observe mode, and the inventory should be refreshed, by running a ‘SC: Run Commands’ task

using the so command.

Enabled mode

Application Control is fully active, strictly enforcing change by allowing change only via authorized

methods, and has memory protection functioning as per policy. This mode is used once policy has been

developed, tested, and refined.

Enabled mode with self-approval

In an environment where an endpoint is locked down, self-approval allows users to authorize otherwise

blocked activity. Self-approval is granted and configured using the Application Control Options

(Windows) policy, which is discussed later. This capability can be used either as an intermediate step in

the path to full lockdown, or as a final endpoint protection state. The ‘warn but not block’ approach has

proved very effective in getting users to re-evaluate their requirements, across a number of McAfee

technologies. If a requirement is real, it allows it to occur with the minimum of hindrance to the user.

Otherwise, the user may reconsider performing the activity if it is not strictly required.

Observe mode

The purpose of observe mode is to allow change, (e.g. a change to the inventory), as specified by

policy, and at the same time assist in understanding changes that are not authorized within the current

policy. Rather than blocking changes and other activities that occur outside of authorized methods,

these activities are permitted, and additional information around them is captured. This information is

then sent back as an observation, (rather than as an event), undergoes processing at ePolicy

Orchestrator, and can result in a recommendation that can easily be implemented within a policy. The

purpose of this mode is twofold – firstly to help develop policy and thereby determine the rules required

to allow applications to function as desired once placed in enable mode; and secondly to test policy by

confirming that the rules in place do in fact allow for any authorized changes that happen on an

endpoint. Observations should be monitored on a regular basis and suggestions applied where

appropriate to ensure that the correct policies are in place. Failure to do this may result in a build-up of

observations that will become progressively harder to manage.

Update mode

Application Control is active, but allowing change to take place, whilst providing and enforcing memory

protection. This mode allows for product upgrade or removal to take place. It can also be used as an

escape hatch, and is covered later.

Switching mode

The following tasks are available within ePolicy Orchestrator to switch operating mode.

Table 1: Commands used to switch mode

Task type Task details When to use

SC: Begin Update Mode

A workflow ID can be associated with all changes made and reported whilst in update mode

This task can be used either prior to upgrading the installed version of Application Control, or to enable an escape hatch.

SC: End Update Mode

This task has no configuration options. This task can be used either after upgrading the installed version of Application Control, or to disable an escape hatch.

SC: Disable

This task can either be configured to force an endpoint in to disabled mode, (by forcing a reboot when the task is run), or simply to configure the endpoint to run Application Control in disabled mode the next time the endpoint is

This task is typically used when Application Control is being removed from an endpoint.


rebooted.

SC: Enable

This task can be configured to create the inventory at a preconfigured Windows priority. When enabling the endpoint one of two paths can be selected - a full feature activation or a limited feature activation. A full feature activation will initiate a shutdown giving a 5 minute warning, and following the reboot, create the endpoint inventory. A limited feature activation, (where memory protection is not enabled until after a reboot), will simply create the inventory, and fully enable the product following an independent reboot. The task can also switch from enabled mode to observe mode once complete, and instruct the endpoint to send its full inventory to ePO.

This task is typically run after installing Application Control. The option to switch to observe mode is usually used for pilot, evaluation and policy refinement, whereas enable mode is used to provide endpoint lockdown, or after policy refinement and testing has completed.

SC: Observe Mode

This task can be used to begin observe mode – in which case a workflow ID can be associated with all changes made and reported whilst in observe mode. Alternatively, it provides the capability to end observe mode and switch to either enabled or disabled mode. If selecting the latter option of exiting observe mode, then observations can be retained or rejected as part of the process. Typically observations should be retained - if a critical system component is updated during observe mode and the changes are rejected, the operating system might become unstable

This task is often used to switch out of observe mode into enable mode once policy refinement and testing has completed. It can also be used to start observe mode to construct or update policies if for example new software or major new versions of software are to be introduced to the environment.

Application Control in action

Protection

Endpoints gain protection from the presence of Application Control in two major areas:

File-based protection: Protection of and from file-based attacks, which is typical of viruses, Trojans

and worms. These attacks may attempt to execute new applications, or modify existing

applications.

Memory protection: Protection from memory-based attacks, which can occur from the Internet,

across the network or locally as a result of file execution.

File-based protection

Applications that are not part of the whitelist are neither authorized nor protected. Conversely whitelisted

items are both authorized and protected.

If an unauthorized item is introduced to an endpoint, (for example through a download, access over the

network, or locally via flash drive or CDROM), it may be copied to the endpoint, changed and moved

from folder to folder on the endpoint, but at no point can it be executed. Examples of these types of

events are shown below.

Table 2: Protection against unauthorized execution

Execution denied An application that does not exist within the whitelist has been attempted to be executed, but this has been prevented by Application Control.

ActiveX installation prevented

Application Control prevented an attempt to install an unauthorized ActiveX control.


If an unauthorized process, (e.g. originating from a malicious file executing on a remote endpoint), or an

unauthorized user, attempts to modify, rename, move or delete an existing whitelisted and hence

protected file, Application Control would block this change. Examples of these types of events are

shown below.

Table 3: Protection against unauthorized change

File write denied Application Control prevented an attempt to modify an existing whitelisted application by an unauthorized process.

Package modification prevented

Application Control prevented an application using an MSI-based installer package from installation, modification or removal using an unauthorized mechanism.

Memory protection

Whilst Application Control protects the whitelist of applications from unauthorized change on disk,

memory protection features provide protection whilst applications are executing.

Real-world examples of where this has protected customers from exploit include the Microsoft server

service relative path stack corruption vulnerability, (MS08-067) exploited so successfully by Conficker

being stopped with CASP by preventing payload execution; the VideoLAN VLC MKV Memory

Corruption vulnerability, a stack overflow exploit, (CVE-2011-0531) stopped using DEP by preventing

payload execution; and the Microsoft Internet Explorer Fixed Table Col Span heap Overflow, (MS12-

037) protected by Virtual Address Space Randomization by preventing payload execution.

Examples of these types of events are shown below.

Table 4: Memory protection

Nx violation detected

Application Control prevented an attempt to hijack a process by executing code from a writeable memory area such as the stack or heap.

Process hijack attempted

Application Control detected an attempt to exploit a process from a specified memory address.

Process terminated

Application Control prevented an attempt to hijack a process by illegally calling an API.

VASR violation detected

Application Control prevented an attempt to hijack a specified process by

executing code from a non‑relocatable DLL.

Activity

The following event types show behavior that occurs as part of the normal operation of the product. With

the exception of the inventory corrupt event, these events represented expected behavior and once

tuning has completed and the policy refined, these events can be safely ignored.

Table 5: Endpoint activity

File created

A new application has been added to the endpoint, (such as via a download). Depending on how this file has been added, it may have then been added to the inventory, (and if so a file solidified event will be generated), or may not have been solidified.

File deleted An existing inventoried application has been deleted from the endpoint. If it was part of the inventory, it will also have been removed from the inventory, (and a file unsolidified event generated).

File modified An existing application has been modified, and the changes are reflected within the inventory.

File solidified An application has been added to the inventory.

File unsolidified An application has been removed from the inventory.

Initial scan completed

The inventory creation process has completed.

Inventory The inventory has become corrupt. If the inventory does become corrupted,


corrupted then it should be recreated using an ‘SC: Run Commands’ task using the so command. In addition, GatherInfo should be used to collect endpoint information, and Technical Support contacted. For details on the use of GatherInfo see the section later in this guide entitled ‘Gathering information to assist support’.

Package modification allowed

Application Control allowed an application using an MSI-based installer package to be installed, modified or removed using an authorized mechanism.

ActiveX installation allowed

Application Control allowed an authorized ActiveX control to be installed.

Visibility

When Application Control-monitored activity occurs on an endpoint, this is reported back in to ePolicy

Orchestrator. This provides both visibility, (as to what happened), and context, (where and how it

happened). Event attributes include the time and date of the attempted change, the endpoint on which

the event occurred, the process attempting the change, the object attempting to be modified, the type of

change attempted, and user associated with the event. Similarly, if an inventoried item, not configured

as an updater, attempted to perform a change to the whitelist, Application Control would block and

report on this activity.

Control and stability

Application Control will protect an endpoint from unauthorized change regardless of the source of that

change. In most cases this might be envisaged as a malicious application attempting to compromise the

endpoint, whereas it may not actually be malicious. A user attempting to install an unauthorized

application, remove an existing protection product, or simply trying to upgrade an application to an

incompatible or untested version that may conflict with other applications can compromise stability. In all

cases where the change is unauthorized, it will be prevented and the change attempt reported. This

control brings stability to the endpoint, and provides the administrator with a view of the activity taking

place before it becomes a problem.

Users with administrative rights

Administrative users, (whether local, domain or enterprise administrators), will not be able to make

changes to applications on the endpoint unless changes are made using an approved mechanism. In

this respect, administrative users are subject to the exact same restrictions in place as for non-

administrative users. Whilst any, (administrative or non-administrative), user could be configured as a

trusted user, (one possible mechanism that can be used to authorize change), this mechanism is

unlikely to be recommended.


Pilot or evaluation plan

It is recommended that a pilot or evaluation should include the stages depicted below. These are each discussed in the proceeding pages.

1. Define & document objectives

3. Define the approach

2. Establish success criteria

4. Identify resources

6. Select and customize policies

7. Install Application Control

8. Test and observe behavior

9. Review results10. Success

criteria achieved?

Start

End

11. Tune Policy

5. Understand & document risks and

mitigations

No

Yes12. Switch to

protection mode

Figure 2: Pilot plan

Application Control for Desktops Best Practices Guide Page 17

1. Define and document objectives

A pilot allows Application Control to be evaluated at low cost, and provide indications as to its suitability

or otherwise within an organization. Conducting a highly visible pilot project will help you pre-sell the

solution, by assuring and demonstrating to staff that they will experience little or no impact or disruption

both whilst installation is occurring, and when installation has completed and the product is protecting

the endpoint. This will assist with organization-wide deployment of the product.

The pilot provides a tangible way of communicating the potential of Application Control to protect the

endpoint from a variety of threats, both known and unknown, existing, targeted and zero-day, without

the need to perform signature updates. It should enhance the stability of the endpoint, protecting it from

ad hoc changes, and provide an enterprise-wide view of the applications in use across the estate. A pilot

may indicate the presence of existing unwanted software and malware, and provide a simple

mechanism for its identification and removal. Therefore the results of the pilot are evidence of the

tangible value of adopting Application Control.

The objectives of the pilot are likely to be a combination of the following:

Evaluate the suitability of the solution in your environment

Determine the compatibility of the product with existing endpoints and applications

Assess the impact of the product on endpoints within your environment

Evaluate the capabilities of the product

Determine the ease of integration into existing change and break-fix processes

Test the application categorization capacity of the product

Verify the functionality of the product

Determine the deployment, management and reporting capabilities of the management system

Identify and address obstacles for a full scale implementation

Decide how many endpoints will be tested and over what time period

By conducting a pilot you are able to more easily identify technical risk, (e.g. compatibility problems with

existing endpoints and infrastructure, or suitability for Application Control across different endpoint

types); areas for policy and procedure changes, (workflow issues); and information for production

planning (e.g., providing information for developing a realistic implementation schedule). Information

gained as a result of the pilot will mitigate acquisition risks and prepare for deployment within the

production environment

2. Establish success criteria

The success criteria should be carefully defined to ensure that they will be the measure used to assess

whether the product is a good fit in the environment and that it has the required capabilities. It should be

used to illustrate the business value of the solution in addition to any technical merits.

The success criteria should follow from the pilot objectives. Using the objectives above, the test criteria

may be defined as below. The example below illustrates the success criteria obtained from interpreting

one objective, that of evaluating the suitability of the solution in your environment. Before commencing

the pilot it is important to interpret all objectives for success criteria. If you fail to do this, then the results

of testing will have little value in relation to the pilot, since they will not necessarily allow you to assess if

the objectives have been met. This is a common mistake seen numerous times by the author, and will

most likely lead to a failed pilot.


Table 6: Establish success criteria

Success criteria Indicators How to measure

A significant proportion of endpoints are compatible with Application Control

Evaluation of the desktop estate indicates that 50% or more of desktop endpoints are shown as compatible.

Number of endpoints meeting hardware and software requirements

The product successfully installs and operates across a range of endpoints

No errors are indicated during the installation process. The product appears to load and function correctly after installation

Number of installation issues

No unexpected behavior or obvious incompatibilities are observed

After installation the endpoint operates correctly

Number of errors attributable to Application Control identified

3. Define the approach

The approach will define how and when the pilot will occur.

Roles and responsibilities

It will define the roles and responsibilities - some of which be met internally by the organization, and

some met by McAfee. It will establish how the product will be implemented, and how this implementation

will be used to assess if the product meets the success criteria.

Administration

Whilst Application Control does not strictly require ePolicy Orchestrator, (ePO), to be used for

management purposes, for both a pilot and production environment, the presence of ePolicy

Orchestrator should be considered mandatory. To gain the maximum benefit from the pilot process it is

envisaged that the management system will be present and already used to manage existing products

on the pilot endpoints.

Pilot schedule

The approach will also document the time period over which the pilot will run. The pilot process should

be of sufficient duration to allow change mechanisms in use within the organization to be identified; to

conduct any testing required to demonstrate success criteria; perform any required tuning, and allow a

reasonable residual period for soak-testing; where protected endpoints are used in the normal way by

typical users to confirm compatibility or highlight any issues. The residual period, after testing and tuning

has completed should cover at least one work cycle. For example, specific activities may occur every

week, whilst others only at the end of each month. The residual soak test period should be of sufficient

duration to cover both of these cycles.

Types of testing

Testing should include the following general topics:

Functionality testing. The objective of this test set is to ensure that each element of the product

meets the functional requirements of the business. For example, the product must install, execute,

and protect the endpoint from unauthorised change, detect unauthorised change attempts and

report this, allow all authorized processes to complete successfully, allow administrative and user

interaction, allow for successful integration into existing endpoint management processes, report

effectively, and uninstall correctly.

Empirical performance testing. These tests ensure that the endpoint provides acceptable

response times and that general performance is not impacted. The product should impose no more

than an acceptable overhead on the endpoint it is protecting. It should not hamper user or

administrative interaction with the protected endpoint. It should not cause any existing application,

service or operation to fail or run in an unacceptable way. Endpoint and application start-up times


should not be increased beyond an acceptable level. Resume from standby and hibernation should

continue to function.

Measured performance testing. This test set can consider endpoint metrics, such as measured

start-up or reboot times, launch time for local and network applications, and standard benchmarking

of CPU, memory, and video and disk operations.

User acceptance testing. This test set, which is planned and executed by the user, ensures that

the endpoint continues to operate in the manner expected once the software has been installed.

This covers both the look and feel of the endpoint being maintained, as well as it functionality being

unimpaired. It will typically run over a longer period of time than other tests, and is more designed to

determine if the user’s normal tasks are influenced by the product being installed and active.

Manageability. The series of tests covered in this set includes all of the basic management

functions, including remote installation, product upgrade and removal, configuration, cloud look-up

and reporting.

Often two or more of these elements will be combined in a single test. The sample test below is

designed to assess the first success criteria – ‘A significant proportion of systems are compatible with

Application Control’. In doing so, it will look at both a functional aspect, (measuring the number of

compatible systems), and a manageability aspect (remote installation and reporting).

Table 7: Sample test plan

Success Criteria

Test Cases Tests

A significant proportion of endpoints are compatible with Application Control

Determine the proportion of potentially compatible endpoints.

Create queries within ePO to determine potentially compatible endpoints

Run these queries and record the number of potentially compatible endpoints

Determine the proportion of potentially compatible endpoints

Select a representative sample of potentially suitable endpoints and determine how many are compatible.

Select a proportion of endpoints from the set of potentially suitable endpoints designed to represent the population of all endpoints

Install the product, place in observation mode, and allow the user to perform standard operation. Record any error messages received during this process.

Determine the proportion of compatible endpoints

Select a random sample of potentially compatible endpoints and determine how many are compatible.

Select a proportion of endpoints from the set of potentially compatible endpoints designed to represent the population of all endpoints

Install the product, place in observation mode, and allow the user to perform standard operation. Record any error messages received during this process.

Determine the proportion of compatible endpoints

The sample test plan will greatly depend on a comprehensive set of evaluation criteria being

established. Once established, each criterion this can be broken down into one or more test cases used

to evaluate the criterion. Once the test cases have been determined, steps required to perform tests can

be created, and the tests executed and results recorded.

4. Identify resources

The resources to be identified include personnel, endpoints to be tested, and the management system.

Personnel

Personnel are likely to include a skilled and experienced McAfee administrator, but may also include

resources made available from McAfee, such as a Systems Engineer, Account Manager or Technical

Support contact. Identification of these people and agreement of roles and responsibilities throughout

the duration of the pilot will ensure everybody is aware of what is required. This stage will also ensure


that all parties are aware of what is happening, and when this will be happening, and should lessen the

chance of the unexpected occurring.

Management system requirements

When considering software requirements for management of Application Control across a desktop

estate the following factors should be considered:

Management agent. There are no specific McAfee Agent (MA) requirements. Any currently

supported version of the McAfee Agent is supported for use with Application Control;

Management server. Any currently supported version of ePolicy Orchestrator server version 4.5 and

4.6 is supported for use with Application Control. For ePolicy Orchestrator server version 5.0,

support is planned shortly - please see the Knowledge-Base article ‘ePO 5.0 supported products’

https://kc.mcafee.com/corporate/index?page=content&id=KB76736;

Database server requirements. The Solidcore extension used with Application Control requires SQL

Server 2005 or greater with DB compatibility level of 90 and above;

Database sizing requirements. To assist in estimating the amount of database storage required

when deploying Application Control see the KB article ‘ePO Database Sizing to manage Application

Control and Change Control 6.x hosts’ available at

https://kc.mcafee.com/corporate/index?page=content&id=KB72753.

Endpoint selection

This section describes how to identify and categorize compatible endpoints and how to use this

information during the pilot.

All types of endpoints can potentially benefit from the protection afforded by Application Control.

However, the critical configuration required to achieve a successful deployment depends on

understanding, anticipating and authorizing the changes that should be permitted to occur on an

endpoint, and preventing other change attempts. With this in mind, there are a number of aspects to be

considered when selecting candidate systems for Application Control.

There are a number of considerations to identifying compatible systems for testing:

Endpoints should support endpoint hardware and operating system requirements described below

Candidate endpoints should have good rather than poor characteristics as illustrated below.

Endpoints should not have known incompatibilities as outlined below.

Supported endpoint hardware and operating system requirements

The tables below list the supported desktop architecture, operating system and minimum hardware at

time of going to press.

Table 8: Supported architecture and operating systems

Architecture Operating System

32 bit Windows XP with SP0 or later Windows Vista with SP1 Windows 7 with SP0 or SP1

64 bit

Windows XP (x86-64/AMD64) with SP1 or SP2 Windows Vista (x86-64/AMD64) with SP1 Windows 7 (x86-64/AMD64) with SP0 or SP1 Windows 7 Embedded with SP0 or SP1 (x86-64/AMD64)

Table 9: Minimum hardware requirements

Hardware Minimum hardware

Processor Single or multiple Intel Pentium or above CPUs

Memory 512 MB RAM (32-bit) or 2GB RAM (64-bit)

https://kc.mcafee.com/corporate/index?page=content&id=KB76736



Disk space 100 MB free disk space for installation on system volume 100 MB free disk space on every volume that will be protected

Network TCP/IP Protocol should be installed on the system for endpoint management via ePolicy Orchestrator

For up-to-date information consult ‘System requirements for Application Control and Change Control

6.1’, https://kc.mcafee.com/corporate/index?page=content&id=KB76579.

Candidate endpoint characteristics

It is recommended to select endpoints from the available pool based on the good characteristics listed

below, and avoid selecting endpoints which exhibit the poor characteristics listed. Whilst endpoints with

poor characteristics can still be protected by Application Control, significantly more effort may be

required, and so for the purpose of a pilot it is not recommended to select these systems.

Table 10: Candidate endpoint characteristics

Good Potential Poor

The endpoint being protected is created as a Standard Operating Environment (SOE) build – also referred to as Consistent or Common Operating Environment or COE. A COE is typically implemented as a standard disk image that can be mass deployed within an organization. It typically includes the base operating system, custom configuration, a standard set of applications, software updates and service packs. The user is a standard user: they do not have administrative rights, use only standard software, have well defined work styles, may have fixed function desktops, and work in a similar fashion to a significant number of other workers in the organization. Users should have a higher than normal tolerance for testing Change to the endpoint is made in a controlled manner. Ad hoc changes are not permitted. Endpoints are physically close to the testing location and easily accessible. Endpoints having existing McAfee products present, such as VirusScan Enterprise and the McAfee Agent.

The endpoint being protected is based on a SOE or COE build, but has a small number of well-defined differences, such as having an additional or alternative application installed or a newer version deployed. The user is a power user but does not have administration rights, or is or software developer using a compiler. The majority of the tasks they perform are standard and repeated. Change to the endpoint is made in a controlled manner. Ad hoc changes are occasionally permitted.

The endpoint is either a non-standard build, or is used by the IT department. Alternatively the endpoint has many non-standard applications, or is not subject to any standards. The user has full administrative rights, and undertakes a large range of different task types. There is little or no commonality when compared with the tasks performed by many other users. Changes are unpredictable and frequently delivered in an ad hoc manner. Laptops are infrequently connected to the corporate LAN.

Known incompatibilities

There are a small number of endpoint characteristics that can result in an endpoint being incompatible

with the current version of Application Control. At the present time, endpoints with these characteristics

should be excluded from testing. Details can be found in the KB article ‘McAfee Application Control 6.1

Known Issues’ available at https://kc.mcafee.com/corporate/index?page=content&id=KB76457.

Identifying candidate endpoints

There are a number of approaches to this problem:

If you are familiar with the environment, and the different functional roles within the environment, or

have already selected or provided hardware to participate in the pilot you can manually select these




endpoints from within ePolicy Orchestrator. Grouping or tagging can be used to assign policies and

tasks to these endpoints;

Alternatively, if you have a group of users that are typically called upon to pilot new technologies,

then these may be the best choice. If not, it is worth considering creating such a group. Many

organizations leverage such a group and in exchange for their patience, reward them with early

adoption of new technologies, or new product versions;

Alternatively endpoints that meet the hardware and software requirements of Application Control

can be identified by running queries within ePolicy Orchestrator – see the section entitled Reporting

best practices for details;

Finally, you can combine approaches, using the queries above to tag endpoints, and then use

either knowledge of the environment or a pilot group selected from the results of these queries.

Identifying candidate endpoints with ePolicy Orchestrator

Candidate endpoints can be identified within ePolicy Orchestrator based on simple queries evaluating

hardware and software parameters - details are given in the section entitled ‘ePolicy Orchestrator

queries’. These can then be refined based on local knowledge. For example, if during assessment of

work styles Helpdesk workers are seen as likely candidates for Application Control, all Helpdesk PCs

could be tagged within ePO, or have values set within the McAfee Agent Custom Props registry keys to

identify these systems. The queries suggested could then be refined to include these values when

assessing likely candidates.

Figure 3: Identifying candidate endpoints with ePolicy Orchestrator

5. Understand and document risks and mitigations

Risks to the successful completion of the project should be identified and mitigations defined. This stage

is used to anticipate issues and provide a plan for dealing with these upfront, rather than ignore them

and panic when and if they happen. Risks are likely to focus on three key areas, but individual

organizations may identify other risks.

Typical risks

Availability of key personnel. A successful project will depend on the availability of the right

people at the right time. If people are likely to be involved in other projects, then there is scope for

conflicts and changes to availability, which will necessitate either changing the people assigned to

the project, or delaying the project. Personnel changes will tend to delay projects, as they are

bought up to speed.

Availability of endpoints. In order for the project to proceed, the correct management and

endpoints need to be available. Management and endpoint hardware needs to be identified, needs

to be prepared and may require change processes to be completed. This will require availability of

personnel and time to complete. Endpoints used for testing need to be identified, confirmed as

being suitable and where these are in everyday use may need to be physically located and recalled

to the office. Any users assisting with the pilot need to be informed, need to agree to help, and may

need to be briefed on what is happening, (and any procedures to be followed in the case of an

issue).

Software behavior. Software testing by users in a production environment is the most effective and

efficient way to determine if a solution is compatible and to understand the typical behavior of that


solution. However, it introduces risks that are not present in a test environment. These risks are

increased if the user population testing the solution is mobile; they may not be within easy reach,

and not always have network connectivity. A back-out plan should be identified that provides the

user with an escape hatch for fast mitigation of issues, especially with a mobile worker.

Application Control and McAfee technologies coexistence

When considering the co-existence of Application Control with other McAfee technologies there are two

areas of potential impact:

The impact of Application Control on other McAfee applications

The impact of other McAfee applications on Application Control

Impact of Application Control

The most common and likely impact of Application Control on any application is where that application

changes the endpoint whitelist.

For security products this typically happens when the security solution updates itself. A signature

update alone is unlikely to have a direct impact, since the signature is not classed as an application,

but the process for installing the signature may well impact on Application Control. However, the

rules contained within the McAfee Applications (McAfee Default) policy should allow any McAfee

application that needs to make a change to be allowed to do so.

In addition, where the security product changes the whitelist as part of its normal operation, again

this can be impacted by the presence of Application Control. The most common example of this is

likely to be where an on-access or an on-demand scan runs, detects malware and attempts to

make changes to an infected file in order to clean the malware. Again the McAfee Applications

(McAfee Default) policy should allow this to take place without issue.

In order to make changes to an inventoried file, the McAfee process responsible for making

changes must be assigned the updater attribute. This happens via the McAfee Applications

(McAfee Default) policy. Where an updater creates or modifies an application, that application is

automatically inventoried and so whitelisted. One side-effect of this process is that it is possible to

deliberately introduce an infected file to a system, have it cleaned, (which will then whitelist the file),

and allow it to execute. If this is of concern, then rather than clean, the action could be set to

quarantine. If the decision is made to clean the file, then as a side-effect of whitelisting the file, the

file will be reported back to ePO, and classified as good, bad or unknown in the same way all

inventoried files are categorized. This then gives visibility to the presence of the application on an

endpoint.

The second, and far less common type of impact can be where the application is poorly written, and

triggers memory protection events, which may cause the application to malfunction. This is unlikely to

happen where McAfee applications are concerned, but may happen for other types of applications.

Impact of McAfee applications

McAfee software should not typically impact on Application Control in any noticeable way. However, two

potential areas of impact have been seen in the field:

The process of creating the inventory of applications present on an endpoint, (previously known as

solidification), has been seen to be impacted where on-access scanning is enabled. The result of

this is that this process has taken significantly longer in some cases. This is a logical consequence

in some situations. The inventory process will ‘touch’ each application on an endpoint, and if the

application has not already been scanned and the results cached by the on-access scanner, then a

file scan will be triggered. This in itself will not take any great length of time to complete, but when

each and every application is touched the solidification process in effect becomes akin to running

an on-demand scan and the solidification process in parallel. This has been seen to increase the

inventory creation process by a factor of 3 or 4. This change in duration is likely to have no impact

whatsoever to the endpoint or the user, since the initial scan priority can and should be configured

to run as a low priority process. However, during an evaluation, where it may be desirable to quickly

complete the solidification process so further testing can be performed, there are two ways to avoid

this issue.


The first is to perform an on-demand scan – this should ensure that when Application Control

‘touches’ each file, no on-access scan will be triggered, (since the results of the on-demand scan

will be shared with the on-access scanner, so it will have no need to perform a scan itself).

The second method involves configuring the scsrvc.exe process as a low risk process within

VirusScan Enterprise, and configure low risk processes to only scan on write. When Application

Control ‘touches’ each file, no on-access scan will triggered, since the on-access scanner is

configured not to scan files accessed by scsrvc.exe for reading.

Figure 4: Scsrvc.exe configured as a low risk process

VirusScan buffer overflow protection potentially interfering with the solidification process. A single

isolated incident has been reported where the VirusScan Buffer Overflow Protection feature has

potentially been responsible for the inventory process stalling on a small number of systems. This

has not been proved to be the cause of the stall, but a later attempt at creating the inventory with

buffer overflow protection disabled was found to succeed. It is not recommended to disable buffer

overflow protection, but this information should be borne in mind if troubleshooting.

Optimizing memory protection

A number of McAfee products provide memory protection using different techniques.

VirusScan Enterprise offers Buffer Overflow Protection (BOP) to a pre-defined list of high-risk

processes;

McAfee’s Host Intrusion Prevention System provides Generic Buffer Overflow Protection (GBOP) to

potentially all processes, and will soon offer Kernel-mode protection against exploits;

Application Control provides memory protection (MP) techniques to potentially all processes.

Where multiple of these products are installed on the same endpoint, it is recommended that one

memory protection method is enabled as per the table below.

Table 11: Optimizing memory protection

Application Control

VirusScan Enterprise

Host Intrusion Prevention System

Application Control MP

VirusScan Enterprise BOP

Host Intrusion Prevention System GBOP

Installed - - - -

Installed Installed - -

Installed Installed Installed

Mitigations

Once risks are identified, mitigation should be determined for each risk. Scheduling should take into

account assessment of availability of personal and endpoints and the likelihood of changes to these


assignments. In addition, providing additional leeway for slippage is advisable. When users are selecting

for piloting the solution, preference should be given to local users, whilst remote users should be

thoroughly briefed on what action to take in the event of an issue that affects their productivity.

Define and test escape hatches

When an issue is encountered the first consideration should be, ‘can it be investigated and resolved?’

By doing so, policy can be tuned to ensure this issue does not reoccur. However, this is not always

practical, and so it is useful, (and often essential), to provide a means by which normal activity can be

resumed as quickly as possible.

The objective of an escape hatch is to both provide the means with which normal activity can be

resumed, but also to provide the confidence that such a capability exists. By communicating the purpose

of the product, the reasons for piloting, the schedule for testing and the escape hatches to affected

users, the perceived risk to end-user productivity will be reduced. This is especially important for users

who might be taking protected laptops on the road.

Table 12: Summary of escape hatches

Escape hatch

Description

Observe mode

When running in observe mode Application Control is active, and allowing change as per policy. Where it detects unauthorized change it permits this and generates an observation. Where memory protection events are detected, again these are permitted, and where possible an observation is generated to indicate that this has happened. Therefore, it would be very unusual for any issue seen in enable mode to still exist in observe mode. This escape hatch should be all that is required to allow a user to continue to work without hindrance.

Disabled mode

When running in disabled mode the Application Control filter driver is not loaded, and no protection is active. Therefore, it would be exceptional for any issue seen in enable mode to still exist in disabled mode. This escape hatch should be sufficient to allow a user to continue to work without hindrance. To enter disabled mode the endpoint must be rebooted. Also note that to leave disabled mode, the inventory scan should be re-run using an ‘SC: Run Commands’ task issuing the so command, and the endpoint rebooted.

Removal

Where problems are found to exist on an endpoint when the product is running in disabled mode, removal should be considered. It is extremely unlikely that Application Control will have any impact whatsoever when in disabled mode, so this step is useful in confirming the issue is present on the endpoint even when Application Control is not present.

Disabling in Safe Mode

When an endpoint is unresponsive due to product malfunction or misconfiguration Application Control can be disabled from operating by modification to its configuration. This configuration is protected from tampering when the product is active, but it can be modified when Windows is running in Safe Mode.

Assuming the endpoint is responding to commands, the recommended approach and order is shown

below. If the first escape hatch fails to resolve the issue, move to the second escape hatch. Again, if this

fails, move to the final option.

Figure 5: Escape hatches for responsive endpoints

If the endpoint is unresponsive, it may be necessary to adopt another approach. In this case the best

method is to use Windows Safe Mode to disable the product. Again, if the first escape hatch fails to

resolve the issue, move to the second option.

Switch to observe mode

Switch to disabled mode

Remove Application Control

Switch to disabled mode in Windows Safe Mode

Remove Application Control


Figure 6: Escape hatches for unresponsive endpoints

Switch to observe mode using ePolicy Orchestrator

Application Control can be switched to observe mode via ePolicy Orchestrator or through the local

command line interface. For endpoints that are connected and communicating successfully on the

network, ePolicy Orchestrator should be used. Where this is not possible, the local command line

interface can be used.

To switch to observe mode within ePolicy Orchestrator, create and deploy an ‘SC: Observe Mode’ task,

as below.

Figure 7: Creating a task to switch to observe mode

The task should be configured to start observe mode, and the Workflow ID should be configured to a

meaningful value, so that any changes made during observe mode are easily identifiable.

Figure 8: Configure the task with a meaningful workflow ID

Finally send a wake-up call to each endpoint configured to run this task.

Switch to observe mode using the command line interface

A user with administrative rights and the correct credentials can switch Application Control to observe

mode using the command line interface, or CLI. If the message ‘Access Denied. Administrator

permissions are needed to use the selected options. Use an administrator command prompt to

complete these tasks.’ is seen, the security context of the user account running the sadmin command is

not a member of the local administrators group, (either directly or through domain admin group

membership).

To open a command prompt as an administrative user, right-click on the Command Prompt icon, select

Run as administrator, (and provide suitable credentials if prompted). Be aware that if Windows User

Account Control, (UAC), is enabled, then even users that are designed as administrators will need to

use the ‘Run as administrator’ option to launch the command prompt with administrative rights.

Figure 9: Running a command prompt as admin


The sequence of commands required is shown below.

Table 13: Switching to observe mode using the command line interface

Command Expected response Purpose

sadmin status McAfee Solidifier: Enabled McAfee Solidifier on reboot: Enabled

To check the operating mode of the endpoint

sadmin recover ePO Password: To unlock the interface

<the recovery password>

Local CLI has been successfully recovered. Warning! Recovering local CLI will prevent Solidcore ePO policies from being applied to this host until it is locked down again.

Enter the recovery password configured within the Configuration (Client) policy. The default is solidcore.

sadmin begin-observe workflow-id "Escape hatch 220413"

McAfee Solidifier is entering observation mode. To switch to observe mode and tag all changes using a workflow ID.

sadmin status McAfee Solidifier Observe McAfee Solidifier on reboot: Observe

To confirm the endpoint has been successfully switched to observe mode

sadmin lockdown

Local CLI has been successfully locked down. To resume ePO management of the endpoint.

For most managed products the McAfee Agent will check and enforce policy periodically according to

the McAfee Agent ‘Policy Enforcement Interval’ setting, which defaults to 5 minutes. However, this is not

the case for Application Control. Once the sadmin command is used to recover the CLI, all Application

Control policy enforcement and tasks, (with the exception of a task running the sadmin lockdown

command), will cease to be enforced until the CLI is locked down. For this reason, configuration via the

CLI is strongly discouraged.

Switch to disabled mode using ePolicy Orchestrator

Application Control can be switched to disabled mode via ePolicy Orchestrator or through the local

command line interface. For endpoints that are connected and communicating successfully on the

network, ePolicy Orchestrator should be used. Where this is not possible, the local command line

interface can be used.

To switch to disabled mode within ePolicy Orchestrator, create and deploy an ‘SC: Disable’ task, as

below.

Figure 10: Creating a task to switch to disabled mode

The task can be configured to automatically reboot the endpoint. If this option is selected it will display a

message and force a reboot after a 5 minute warning is issued. Usually, it is not recommended to force

a reboot, but given the purpose of this task is to get a user working as soon as possible, the user should

be told to exit all applications in preparation, and the task configured to reboot.


Figure 11: Configure the task to force a reboot

Switch to disable mode using the command line interface

As with observe mode, a user with administrative rights and the correct credentials can switch

Application Control to disabled mode using the command line interface, or CLI.

The sequence of commands required is shown below.

Table 14: Switching to disabled mode using the command line interface

Command Expected response Purpose

sadmin status McAfee Solidifier: Enabled McAfee Solidifier on reboot: Enabled

To check the operating mode of the endpoint

sadmin recover ePO Password: To unlock the interface

<the recovery password>

Local CLI has been successfully recovered. Warning! Recovering local CLI will prevent Solidcore ePO policies from being applied to this host until it is locked down again.

Enter the recovery password configured within the Configuration (Client) policy. The default is solidcore.

sadmin disable McAfee Solidifier will be disabled on next reboot. To switch to disabled mode.

Reboot the endpoint manually.

sadmin status McAfee Solidifier Enabled McAfee Solidifier on reboot: Disabled

To confirm the endpoint has been successfully configured after next reboot

sadmin lockdown Local CLI has been successfully locked down. To resume ePO management of the endpoint.

As a reminder once the sadmin command is used to recover the CLI, all Application Control policy

enforcement and tasks, (with the exception of a task running the sadmin lockdown command), will

cease to be enforced until the CLI is locked down. For this reason, configuration via the CLI is strongly

discouraged.

Removing Application Control

The section entitled ‘Uninstalling with ePolicy Orchestrator’ and ‘Uninstalling manually’ later in this

document outlines the process by which the product can be uninstalled.

Disabling protection using Windows Safe Mode

In a rare case where the endpoint is unresponsive or not able to start correctly, then it is possible to

switch in to Windows Safe Mode and disable protection through registry modification. Note that using

the Registry Editor incorrectly can cause serious, system-wide problems that may require you to re-

install Windows to correct them. Microsoft cannot guarantee that any problems resulting from the use of

Registry Editor can be solved. Use this tool at your own risk!


Table 15: Changing the operating mode of Application Control

Configuration step

Boot in to Windows Safe Mode

Open Regedit and navigate to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\swin\Parameters.

Change the value of RTEMode to 3

Change the value of RTEModeOnReboot to 3 Note that alternatively you can set both values to 0 to switch to disabled mode, but this should not be required.

Reboot the endpoint and Application Control will now be running in observe mode.

6. Select and customize policies

The objective of this stage is to arrive at a configuration that is as close to the final configuration as

possible given the information available. The closer the configuration is to the final configuration, the

less time, effort, testing and additional configuration that will be required in the following stages. This

stage contains two steps. The first is selecting the initial policy and the second is customizing as far as

possible.

In order to define the initial policy that should be implemented on endpoints it is first important to

understand the general purpose of each policy. When the Application Control extension is first added in

to ePolicy Orchestrator a number of policies will appear. Only by adding the appropriate license key will

access then be granted to these policies. Application Control is one of three basic functions that

Solidcore provides – additional functionality will be visible but not accessible without the appropriate

license key. This document is focused exclusively on running Application Control on Windows desktops,

so a number of policies are not explored further here.

Overview of policy types

The table below highlights what policy options are available, how they impact on the product

functionality in broad terms. Later this document will explain in detail what these policies provide, and

how to select and set them, in order to deliver the optimal configuration for Application Control.

Table 16: Overview of policy types

Product Category Description

Solidcore 6.1.0: Application Control

Application Control Options (Windows)

This policy is used to define self-approval, end user notifications and in rare cases to enable or disable specific features.

Application Control Rules (Windows)

This policy defines authorised change mechanisms, exceptions, event and observation filters, and manual additions and subtractions from the whitelist for Windows endpoints.

Application Control Rules (Unix) This policy defines similar functionality for Unix endpoints.

Solidcore 6.1.0: Change Control

Change Control Rules (Unix) Change Control monitors change activity in server environments that can lead to security breaches, data loss, and outages. It assists with meeting regulatory compliance requirements. This guide is focussed exclusively on Application Control for Windows desktops, so these policies are not explored further here.

Change Control Rules (Windows)

Solidcore 6.1.0: Integrity Monitor

Integrity Monitoring Rules (OS4690)

Integrity Monitoring Rules (Unix)

Integrity Monitoring Rules (Windows)

Solidcore 6.1.0: General

Configuration (Client) This policy is used to specify the local command line interface password. This password should always be changed.

Exception Rules (Windows) This policy is used to define rules to override or bypass the applied memory-protection and other techniques available within Application


Control. This same functionality is available under the Exceptions tab within the Application Control Rules (Windows) policy.

Exception Rules (Unix) This policy defines similar functionality for Unix endpoints.

Application Control Options (Windows) policy

This policy is used to define self-approval, end user notifications and to enable or disable specific

features.

Self approval

Self-approval is the mechanism by which a user can themselves authorize the use of an application.

The expected use case for this feature is an environment where availability is more important than

security. The user approves the application, and at some later date the administrator either allows or

bans the application from the environment, based on the available information.

Figure 12: Self-approval tab

Configuration available within this policy includes:

The availability of self approval to the user - by default it is disabled;

The text to be displayed to the user during the self-approval process;

The time-out period for which the dialog is displayed and then automatically closed assuming no

user interaction. The recommenced value for this setting is 180 seconds;

The advance option specifies the action to take if the self-approval dialog cannot be displayed, such

as at boot time or if the McAfee agent icon is not visible. If enabled, all unauthorized applications

will be allowed. If disabled, they will be prevented from executing. The McAfee Default policy has

this setting deliberately disabled, so that only applications explicitly authorised by a user are added

to the approved list. However, best practice is to enable this setting, once the risk of doing so is

understood. The risk of enabling this setting is that applications that may not be desired may be

automatically authorized as the result of a time-out. However, these authorizations are made visible

within the ePolicy Orchestrator interface and can be overridden. The risk of not authorizing file

changes that occur during the boot process is that this may prevent the operating system from

starting correctly.

End user notifications

This section of policy allows configuration of the messages and activities exposed at the user’s desktop.

There is an option to show either a bubble message to the user, (which can then be clicked on to

display the Application Control Events interface), or to display the Application Control Events dialog

directly;


The text of the bubble message and that shown in the Application Control Events dialog can be

modified on a per-event type basis;

If the user attempts to ‘Request Approval’ from the Application Control Events dialog, the contents

of the email sent to the administrator, along with message parameters can be configured within this

policy.

Figure 13: End user notification tab

Features

The features tab allows control of some features available within Application Control. Whilst features can

be controlled using this policy, it is recommenced that this setting remains disabled and that if features

are to be enabled or disabled, that this is done using a client task. For more details around features, see

the section entitled ‘Application Control features’, later in this document.

Figure 14: Feature control tab

Understanding Application Control rules policy

Within ePolicy Orchestrator, typical the policy applied to endpoint protection products can either be

explicitly configured on a group or individual endpoint, or more frequently is configured on a higher-level

group and is inherited down the system tree. This exact same process is used with the Application

Control rules policy. However, the Application Control rules policy has a number of elements that are not

typically seen within other endpoint policies, and should be understood before being configured.


Overview

......

McAfee Applications (McAfee Default)

Organisation-specific applications

Effective policy

Installers Publishers

Rule Groups

...My Rules

.........My Rules

.........App X

Rule Groups

Admin

Figure 15: Determining effective policy

The figure above provides a high-level view of how policy is derived. Each of the components will be

broken down in the proceeding sections.

Installers and publishers

Installer and publishers define configuration that may be useful to many different types of endpoints:

Installers, (applications that are used to install software on to an endpoint), are used to specify

applications that are not necessarily contained within the inventory, but are non-the-less authorized

to execute and make changes to the whitelist;

Publishers are used to specify the certificates with which applications may be authorized to execute

or to execute and update the whitelist.

In order to facilitate sharing of configuration, both installers and publishers are configured outside of

conventional policies. Once configured these settings can then be added or removed from rule groups

as required. This approach allows installers and publishers to be added to multiple policies, yet

managed centrally.

Certificate expiry

Application Control does not assess the validity of a certificate. When a certificate is specified,

applications signed by this certificate will be trusted regardless of for example, if the certificate has

expired.

Repository scanning

To assist in the collection of information about Installers and Publishers, Application Control adds a

server task in to ePolicy Orchestrator – ‘Solidcore: Scan a Software Repository’. This task can scan

either a local or network path, using the supplied credentials, looking for applications. When it finds an

application it will extract both the details of the certificate used to sign the application if one is present,

and file information (including vendor, version and checksum). This information is added to the list of

known Installers and Publishers maintained within ePolicy Orchestrator, and can optionally be added to

a rule group.

Policy composition

An ‘Application Control Rules’ policy comprises of one or more rule groups. Every policy contains a ‘My

rules’ rule group, and in addition to this, existing rule groups can be added, or new rule groups can be

created, and then added to the policy. The figure below shows the layout of this type of policy. The rule

groups included within the policy are all listed on the left side of the figure, and the actual configuration

is shown on the right side. Below, the ‘.Net Framework’ rule group is selected, and so the right side of

the figure shows the updaters configured for this rule group.


Figure 16: Application Control Rules policy

Rule groups

A rule group is a collection of logically related rules required for specific applications or utilities to

successfully operate. In the figure above, the ‘.Net Framework’ rule group contains three applications

that are configured as updaters, in order to allow .Net to function correctly.

Rule groups are split into different types of rules.

Updaters is used to specify the name or checksum of processes that are permitted to change

applications contained within the whitelist;

Binary is used to allow or to ban execution of an application based on its file name or SHA1 hash;

Trusted Users is used to specify a local or domain user authorized to change the whitelist. Trusted

Active Directory groups can be added to a policy, but these must be added by creating a new rule

group, adding the trusted groups in to this rule group, and then adding this rule group to the policy;

Publishers is used to add previously configured publishers to the policy;

Installers is used to add previously configured installers to the policy;

Exceptions are used in rare cases where incompatibilities are found to exist between protected

applications and the protection mechanisms used by Application Control. It can be used to define

rules to override or bypass memory protection applied to applications;

Trusted directories specifies local or remote locations where applications that are not contained

within the inventory are permitted to execute, and optionally to be granted updater privilege;

Filters define a combination of conditions used to exclude observations and optionally events that

are not required to be reported back to ePolicy Orchestrator.

Application control ships with over 100 rule groups, to cover applications, (such as Adobe Acrobat, and

Microsoft Office) and Windows components, (such as the .Net Framework and Windows Update). Once

a rule group for a specific application has been created this can then be used within any policy. If a

change is required, for example, if a newer version of an application is deployed which requires different

configuration, then changes can be made to the rule group, and these changes are reflected within

every policy that contains this rule group. Rule groups can be added and removed from within a policy,

but cannot be directly edited from within that policy, since the rule group itself may impact multiple

policies. Rule groups are edited from Menu | Configuration | Solidcore Rules.

Additionally, where an Active Directory group of users’ needs to be added to policy, (generally a

configuration that should be avoided if possible), a rule group needs to be used to contain these trusted

user groups. This rule group can then be added to one or more Application Control rules policies, in the

same way that any other rule group is used.

The ‘My rules’ rule group

My rules is a special rule group that can be edited by the administrator directly from within a policy.

Unlike all other rule groups, it cannot be shared amongst policies – it is specific to the policy where it is

edited. It contains the same elements as all other rule groups:

My Rules

Updaters

Installers

Binary

Exceptions

Trusted Users

Trusted Directories

Publishers

Filters{


Figure 17: The composition of the 'My Rules' rule group

Default policies

The following Application Control Rules policies are provided by default:

The McAfee Applications (McAfee Default) policy is used to configure settings required to allow

other McAfee products to function correctly, when an endpoint is being protected by Application

Control. By retaining the McAfee Applications policy (McAfee Default) there is no chance of

accidentally changing configuration required by another McAfee product, since this policy is read-

only.

The McAfee Default policy comprises a set of rules to allow common applications to run. In addition,

it contains filter rules to filter out observations from known chatty applications.

Blank Template is a policy that contains a single empty rule group, ‘My rules’.

The Common ActiveX Rules policy contains the ActiveX rule group, which contains a set of

common publishers’ certificates, in addition to the mandatory ‘My rules’ rule group.

Multi-slot policies

Multi-slot policies allow more than one policy to be specified at a particular group within ePO. Whilst this

concept appears at first sight to complicate policy assignment, in any non-trivial environment it should

allow for both flexibility and simplicity to be used when assigning policies.

McAfee Applications (McAfee Default)

McAfee Default Effective policy

Figure 18: Combining multi-slot policies to establish effective policy

By default, the McAfee Applications (McAfee Default) and McAfee Default policies are assigned to the

top level of the ePolicy Orchestrator system tree.

McAfee default applications

McAfee Default


Effective policy

Figure 19: Combining multiple policies to establish effective policy

The use of multi-slot policies is particularly useful within Application Control since it allows the default,

(read-only), policies to be combined with an organization-specific policy. The organization-specific policy

is therefore designed to supplement the default policies, and contain all of the specific settings required

for endpoints within a given organization to function correctly when being protected by Application

Control.

However, where appropriate, it is possible to add additional policies. So, for example, in an environment

where different applications are being used within different functions or departments of an organization,

one way to address this situation is by adding a fourth policy, which contains the rules required for

function or department-specific applications to operate.


The policy development process

Policy is developed through observation of behaviour coupled with activity identified at the endpoint and

reported back to ePolicy Orchestrator. Once a policy change has been identified, it needs to be added to

the effective policy at the endpoint.

The general process for achieving this involves adding it to one of the multi-slot policies assigned to the

endpoint. This can be done in one of two ways, both of which are useful and appropriate at different

stages of the policy development process.

Initial development and testing

At this stage of the policy development process the objective is to assign the policy to the endpoint

quickly, and test and then perhaps tweak that policy. Convenient access to the policy page, visibility of

existing configuration, and the ability to easily modify existing rules are all relevant at this point, since it

may require several attempts to get the policy exactly right. In this case the easiest way to add and

change existing policy is to directly edit the ‘My Rules’ rule group present in one of the policies assigned

to the endpoint. The mechanism for this change is exactly the same as for editing any other standard

ePolicy Orchestrator endpoint product policy.


McAfee Default


Effective policy

......

Rule Groups

...My Rules

.........COE Apps

Rule Groups

New App

Admin

Figure 20: Policy development

Policy completion

During the policy development process, typically rules are created sequentially for one application or a

group of applications at a time. Once these rules are complete and tested, rules for the next application

or a group of applications are worked on and policy developed. At the end of the policy development

phase it may be that different sets of rules need to be applied to different systems. One reason for this

may be that the Finance desktops use one set of applications whereas Sales use an entirely different

set. It’s likely that even within these very different functions there are a shared set of common

applications that must be catered for.

Given the sequential nature of policy development, and the logical groupings of applications that occur

within organizations, it is recommended that rules are grouped using Application Control rule groups.

These groups can then be assigned, managed and maintained as required. To implement this, once a

rule has been finalized within the ‘My Rules’ rule group, the rules should be implemented within another

rule group, and removed from the ‘My Rules’ rule group.

For example, suppose a Performance Appraisal application is being used, and this application requires

2 updaters to be implemented to allow the application to function correctly. These updaters are initially

added to the ‘My Rules’ rule group, and the Performance Appraisal application tested. Once this is

found to successfully operate, a rule group called ‘HR Apps’ could be created to contain these two rules,

and the Performance Appraisal entries in the ‘My Rules’ rule group removed.

Unfortunately, there is no easy way to cut and paste rules, so they must be manually moved. To achieve

this, ensure the ‘HR Apps’ rule group is already included with the policy applied to the endpoint, (the

Organization-specific applications policy shown below for example), add the new rule to the ‘HR Apps’

rule group, and then removed the configuration from the ‘My Rules’ rule group.



McAfee Default


Effective policy

...

Rule Groups

...My Rules

......COE Apps

Rule Groups

Admin

New App

HR Apps

HR Apps

Figure 21: Policy completion

The effective policy assigned at the endpoint will be identical, the only difference being that the rules will

be applied as a result of being part of the HR Apps rule group rather than the ‘My Rules’ rule group. This

is a trivial benefit when only one or two rules are in place, but as more rules are created, the benefits of

logically grouping them - ease of understanding, management and maintenance, will become more

apparent.

Applying configuration through tasks

Whilst the majority of configuration is applied though policy in line with other endpoint technologies

managed through ePolicy Orchestrator, a number of significant operations are managed through tasks.

Assigning tasks during piloting

Through experience, it has been found that during piloting, the easiest way to implement tasks within

ePolicy Orchestrator, is first to group pilot endpoints. Note that this group is likely to be a subgroup of an

existing group. So for example, there may be a large existing group of desktop users at a particular

location. From this desktop group, suppose 5% of desktops are selected for piloting purposes. The first

step would therefore be to create a pilot group as a subgroup of the desktop group. Next select the 5%

of endpoints and move these to the pilot subgroup. All existing policies that are applied or inherited at

the desktop group, will be inherited by the pilot group. Now, Application Control policy can be assigned

to the pilot group, (labelled ‘Policy assignment group’ in the figure below). To perform configuration that

requires tasks to implement it, (such as deploying Application Control, enabling it, and switching the

operating mode), create subgroups and assign tasks to these. If a task now needs to be run on that

endpoint, then simply moving it to the appropriate subgroup and sending a wakeup call is enough to

have that task executed. Additionally the benefit of this approach is that the state of an endpoint should

be obvious as the result of its location within a particular subgroup.

Policy assignment group

Install group

Full enable and observe group

End observe group

Partial enable and observe group

Policy is assigned at this level and inherited to all subgroups

This subgroup has a standard deployment task assigned

This subgroup has an observe task set to end observe mode assigned

This subgroup has a solidcore full features enable task set to force reboot and switch to observe mode

This subgroup has a solidcore partial features enable task assigned

Figure 22: Applying configuration through tasks during piloting

Assigning tasks during production deployment

The section above describes how endpoints can quickly and easily have their configuration changed – a

very useful if not essential capability for use during piloting and policy development. However, once

policy has been developed, tested and finalized, another approach should be adopted when deploying


to large number of systems within production. The reason for this is that there is much less need to

frequently switch configuration after piloting has competed - the deployment process will therefore

typically consist of two or three well defined steps. It is also likely that endpoints undergoing deployment

may be split across multiple existing groups within the system tree. Creating the directory structure

shown in the figure above in multiple system tree locations, (to cater for endpoints scattered across the

system tree), is likely to be far too complex.

So, to cater for mass deployment, consider the use of tag-dependant tasks. In this scenario, tasks are

assigned at the system tree desktop group, but are only assigned to endpoints that have specific tags

assigned. In this case, to deploy Application Control assign the AP-install tag to selected endpoints.

Desktop group

Install Task

Full features enable Task

Partial features enable task

Policy is assigned at the existing system tree desktop group

This task is only assigned to endpoints that have an AP-Install tag assigned

This task is only assigned to endpoints that have an AP-FullEnable tag assigned

This task is only assigned to endpoints that have an AP-PartEnable tag assigned

Figure 23: Applying configuration through tasks during deployment

Application Control Rules (Windows) policy

This policy defines authorised change mechanisms, exceptions, event and observation filters, and

manual additions and subtractions from the whitelist for Windows endpoints. By default, there are four

policies:

Blank Template - contains no rule groups other than My Rules;

Common ActiveX Rule - contains a number of common publishers of ActiveX applications;

McAfee Applications (McAfee Default) - contains settings required to allow other McAfee products

to function correctly;

McAfee Default – contains all of the default rule groups.

As stated above, this policy defines authorised change mechanisms for an endpoint. The next section

outlines situations when each type of authorization technique should be used, and when it should be

avoided.

Selecting update methods

There are a number of methods that can be used to allow changes to be made to an endpoint.

Depending on the change to be made to the endpoint, and how the change is orchestrated, there may

be multiple different ways of allowing it to take place. This section provides some guidance on why and

where some methods should be used, and indeed why some should be avoided. However, before

considering which methods to select, it is important to understand the processes to implement change

already in place within the organization. The methods listed below should then be used to enable the

existing change methods to work with little or no change being required. If significant change is required

to existing methods, deploying Application Control could be seen as a disruptive process, and could fail

before it has started. In this situation consider that the best method may not have been selected, and

revisit the options.


Table 17: Selecting update methods

Method of allowing change

When to use When to avoid

Updater The method is often the most natural method of allowing existing update processes to continue to function. For example, if the Microsoft SCCM agent is used to manage software deployment on the desktop, then this process can be configured as an updater. Note that many such agents are included within the default policy to ease deployment. Normally this approach should be the first choice in selecting update methods.

Care should be taken at the choice of updaters selected. In particular a generic launcher process, (a process that can be used to launch multiple other processes), should be avoided at all costs. For example, if explorer.exe is made an updater, anything launched by Windows Explorer will then by default gain updater privileges, which renders the entire solution largely ineffective.

Publisher Publishers rely on software signed with a known configured certificate. This can be especially useful if multiple different products from the same vendor, or multiple versions of products are being used. Automation within ePO can be used to assist with this certificate collect process, but requires knowledge of the locations to be scanned, so it may be that trusted directories prove to be an easier method to use. Additionally, if an organization deploys applications created in-house, then if the applications or application installers can be signed, the publisher’s method can be a great way to automatically authorize new application releases.

Care should be taken in selecting certificates configured as publishers. For example, if you set the Microsoft certificate that signs Internet Explorer as an updater, any applications downloaded by Internet Explorer will be added to the whitelist and authorized to execute.

Installer An installer, (application that is used to install software on to an endpoint), is an application that has been both authorized to execute, and authorized to make changes to the system. Installers are configured by specifying such details as the installer name, the vendor and the SHA1 hash of the application. Automation within ePO can be used to assist with this assignment process, but requires knowledge of the locations to be scanned, so again it may be that trusted directories prove to be an easier method to use.

The key consideration as to whether to elect to use an installer, is how much administrative effort will be involved. An installer is precisely specified, so as long as you are authorizing the correct applications, there is no security risk associated with using installers.

Trusted directories

If new software is often installed from a central shared resource, this option can be useful. When implementing this method, ensure that users are only granted read and execute permissions to these directories.

If this method is being considered to allow installation from a shared resource but that shared resource is not protected by both strong permissions and monitored by Anti-virus software then this method should be avoided. If this method is considered for use where a local path is being used, (e.g. C:\myapps) then extreme care should be used, since this configuration would provide an opportunity to easily bypass Application Control. Again strong permissions must be applied to this folder, and this option should only be used if there are no safer alternatives.


Update mode

Update mode can be useful when an endpoint is being created from an image. The gold image should be build, and the inventory created with the system being left in update mode. When an endpoint is being built, after the gold image has been applied, any software or Windows updates can be installed without hindrance. Once fully configured, the endpoint can then be taken out of update mode. In addition, if a new version of Application Control is to be deployed, this process can be simplified by placing the endpoint in update mode during the installation.

Update mode is not a recommended approach to maintain existing endpoints. This mode essentially unlocks the endpoint and allows any change to take place. In any environment where there is likely to be interactive logons, such as a typical desktop environment, this option should be avoided at all costs.

Trusted Users

Trusted user accounts can be useful where a process is running under the context of a user account other than the logged on user. In this situation, and especially where scripts are concerned, this can provide a safe secure way to deliver updates.

The logged on user account should never be configured as a trusted user except if this is the only method of making changes to the system. Not only is configuring the logged on user as an updater opening a huge whole in the protection offered by Application Control, but administratively this is a resource-intensive process to implement

Manual authorization of applications

Applications can be authorized and hence effectively added to the whitelist of an endpoint by specifying the checksum, the file name, or the file name with path. Specifying an application by using a checksum is a safe but administratively resource-intensive approach.

Specifying an application by using either the file name or file name with path is an unsafe approach and should be avoided if at all possible. In addition it can be administratively resource-intensive. If configuration information is disclosed, a user may rename any application to the configured name, (and add it to the configured path if necessary) and effectively bypass much of the protection afforded by Application Control.

Self Approval

This technique is useful when first deploying a locked down policy. It allows the policy to be enforced, and so the endpoint protected, but also provides a facility to allow the users to suggest policy tweaks. If something is prevented from executing, this method allows the user to explicitly allow it, provides this visibility to the administrator, and allowed them to add the change to policy, or to reject it. Additionally, due to the highly complex or constantly changing nature of some endpoints, or the tasks performed by the users of these endpoints, a fully locked down policy may not be possible without a huge effort to maintain policy. In this situation, enabling Application Control and running with self approval enabled on a permanent basis may be the only realistic option for deployment. This however still provides the endpoint a significant amount of protection.

Once a policy is fully developed and tested, (and after a bedding in period has elapsed, and any final policy tweaks completed) the endpoint should be placed in enabled mode with self approval disabled. This option should not be used if other methods of allowing change are available.

Adding directly to the inventory

This technique is available from both the observations interface, (Menu | Application Control | Observations) and the Inventory interface, (Menu | Application Control | Inventory) In either case this is a convenient way to add individual items to the inventory and

The downside of this approach is that the list of changes made to an endpoint using this technique is not immediately accessible. Changes implemented in other ways are typically implemented by modifying a rule group, and including that rule group


hence to the whitelist. within a policy applied to an endpoint. The rule group and its contents are easily accessible and the list of changes clear.

Reviewing the endpoint

Before defining any policy it is worth considering what is known about the endpoint and the typical

processes used to manage the applications and patches deployed on that endpoint. This information is

likely to come from a number of sources. The questions below should provide a good starting point in

understanding how the endpoint is currently managed and subject to change.

How is the endpoint ‘managed’ at logon and logoff time? For example, are scripts or applications

executed, or are files on the endpoint updated, added or removed? Does anything happen during

the logon process that will impact upon applications already present on the endpoint, or is anything

executed during this process?

How are operating system patches deployed to the endpoint?

What applications are currently installed on the endpoint?

Do the installed applications require updating and how is this done? This is likely to fall in to one of

four cases:

o The application is managed using the standard endpoint management process, e.g.

Microsoft System Center Configuration Manager, (SCCM);

o The application uses its own updating mechanism to periodically update itself, e.g. Firefox;

o The application requires an application-specific process to be used to perform the update,

e.g. the admin upgrades the software periodically as required;

o The application does not require updating.

What other common applications not present on the specific endpoint being assessed are

frequently used within the environment?

In addition to the regular maintenance that takes place as above, it is also useful to consider other cases

that may occur:

How are corporate desktops deployed to new or re-provisioned endpoints?

How is support delivered when a desktop fails in the normal course of its function, i.e. what is the

typical break-fix mechanism deployed?

How are fixes deployed in a time-critical situation?

What software is planned to be deployed in the next 12 months and how will this be delivered?

Once this information is gathered, it should be possible to align the processes involved above with the

processes available within Application Control to authorize change, and to identify any areas where

problems might be anticipated.

Initial policy creation

There are two general approaches to selecting an initial policy and refining it. The first is to start with a

policy that is already pre-populated with existing rule groups. Choosing this option may result in many of

the rules that are required already being in place within the policy, as a result of the rule groups the

policy contains. The downside is that the final policy may also contain a number of rule groups for

applications not used within the organization, and so not required. The second approach is to start with

a blank rule group and build this up to include all the required rule groups. The benefit of this approach

is that the final policy will contain only those rule groups required. The downside is that it could take

considerably more time and effort to produce a final policy. The recommendation is the former

approach – use the Application Control Rules (Windows) McAfee Default policy, and supplement

this with another organization-specific policy, and add rule groups to this policy as required.

Policy customization

When creating and tuning policy it is recommended that any configuration is assigned directly to the ‘My

rules’ rule group within the assigned policy. This allows changes to be added quickly and those changes


to be deployed to endpoints rapidly. There they can then be tested and tuned until they achieve the

required outcome.

Once a set of configuration has been created and tested, it is recommended that it is moved out of the

‘My rules’ rule group, and either a new rule group created to represent this application, or it added to an

existing rule group that shares similar or logically grouped functionality.

The table below shows how existing mechanisms can be aligned to the processes available within

Application Control to authorize change. To implement any of these methods they should be added to a

rule group contained within a policy applied at the endpoint.

Table 18: Policy customization

Existing IT process Suggestions for integrating with Application Control

New endpoint delivered using disk imaging software combined with post-image configuration applied using scripts or automated process.

Deploy and enable Application Control to create the initial whitelist, and apply policy to the endpoint. Ensure Application Control is running in update mode until final configuration has been applied. Lock down endpoints as part of the finalization process.

A systems management agent is used to deploy new software and upgrade existing software.

The systems management agent should be configured as an updater within the endpoint policy. For example, if SCCM is being used, configure the full path and file name of the agent as an updater.

An application uses its own updating mechanism to periodically update itself.

Identify the name of the process used for updating. This can be assisted by for example viewing the Windows Task Manager or Microsoft Process Monitor during an application update. However, the easiest way to identify this type of application is usually to use observe mode and review observations. Add the full path and file name of the process as an updater.

Windows update agent is used to install operating system patches.

Windows update agent should be configured as an updater within the endpoint policy, (and is by default).

The application requires an application-specific process to be used to perform the update, e.g. the admin upgrades the software periodically as required.

Understand the process in detail and determine which authorized mechanism is most appropriate. Again observe mode may help in understanding the process that takes place on the endpoint.

Log-on scripts are used to configure the endpoint and deploy updates.

The domain SYSVOL folder should be configured as a Trusted Directory. For example, if running the mfedemo.net domain, \\mfedemo.net\SYSVOL\mfedemo.net should be added as a trusted directory.

Other scripts are used to configure the endpoint and deploy updates.

Specify the script path and name is specified as an updater. Ensure the script is called using either ‘cmd /k script.bat’ or ‘cmd /c script.bat’ where script.bat is the full path and file name of the script.

An account or set of accounts is used to manage change within the environment.

If it is determined that the only way to authorize specific activity is through the use of a trusted user, wherever possible group all such trusted users in to an Active Directory group. Create an Application Control rule group to house trusted users contained within the Active Directory group. Synchronize only this Active Directory group with the Application Control rule group. Trusted users will then be imported from an Active Directory server in to the rule group, and this rule group can be added to appropriate policies. Once this is configured even very frequent changes in Active Directory group membership will be catered for, with the changes automatically added to policy as a result. This minimizes the administrative overhead associated with Active Directory group synchronization.


Cater for specific use cases

Logon scripts

To authorize logon scripts the domain SYSVOL folder should be configured as a Trusted Directory. For

example, if running the mfedemo.net domain, \\mfedemo.net\SYSVOL\mfedemo.net should be added as

a trusted directory.

Accessing applications from shares and mapped drives

Whilst shares and mapped drives are often used for sharing data between users, if applications are

made available using these devices, then this situation should be catered for within policy.

Some factors to consider when creating policy:

Examine logon and logoff scripts to determine common drive mappings, or use of other shares

during the logon process;

Investigate these locations to understand their purpose. Do these locations contain applications or

scripts?

Where network locations contain applications, consider how often these change, and how the

network location is secured, both in terms of file permissions and anti-malware solutions;

Consider how these applications function. Do they simply need to execute, or will they attempt to

make changes to the files on an endpoint running the application? The first is common, the second

less so;

Consider the presence of subdirectories in these network locations – do they exist, do they too

contain applications, are they used by applications?

Consider how best to allow these applications.

Table 19:. Methods of providing access to network-based files

Method Details Considerations

Trusted directories

Specify the UNC path of the network location and configure as include within the policy. Optionally specify if the location is an updater. Use this option with extreme care. If applications should not execute from subdirectories of this path, specify the UNC path of subdirectories and set to exclude.

It is recommended to use this option if the network location is strongly protected. However, this method should not be used if the network location is not strongly protected with both users restricted to only read and execute permissions, and an anti-malware solution monitoring and protecting the contents. Always specify a trusted directory using a UNC path not a mapped drive, since drive mapping will be evaluated on the ePO Server, and may not match the mapping on the endpoint. Note that specified directories includes sub-directories unless an exclusion is specified

Publishers Specify the certificates used to sign the applications present. Optionally specify if the publisher is an updater. Use this option with extreme care.

This is a good way to provide access to applications created internally within the organization. When using this method be aware that any application accessed from anywhere that is signed by this certificate will be authorized. So again, signing with the certificate used to sign any generic launcher processes, and configuring the publisher as an updater would leave a gaping hole in security.

Binary or Installers

If the application is just required to execute, (and does not make changes to files on the endpoint), specify it, (preferably by hash), as a binary set to allow. If the application does make changes to files on the endpoint, specify it as an installer.

If the network location is not strongly protected with both read-only access as standard, and an Anti-malware solution monitoring and protecting the contents then this option should be used, with the application configured by hash. This method requires the most administrative effort but is the most secure when the application is specified as allowed by hash


Accessing applications from external devices

Where external devices containing applications are permitted within the organization, such as encrypted

thumb drives implementing a decryption application as software, (rather than hardware), or U3 smart

drives, then this situation should be catered for within policy.

Some factors to consider when creating policy:

Consider what applications are present and how these might differ across external drives, for

example, by version;

Consider how often the applications on these external devices change;

Consider how these applications function. Do they simply need to execute, or will they attempt to

make changes to the files on an endpoint running the application?

Determine the presence of subdirectories on these external devices – do they exist, do they too

contain applications, are they used by applications?

Determine how best to allow these applications.

Table 20: Accessing applications from external devices

Method Details Considerations

Publishers Specify the certificates used to sign the applications present. Optionally specify if the publisher is an updater. Use this option with extreme care.

This is a good way to provide access to applications created internally within the organization. When using this method be aware that any application accessed from anywhere that is signed by this certificate will be authorized. So for example, signing with the certificate used to sign Windows Explorer, Internet Explorer or any other generic launcher processes, and configuring the publisher as an updater would leave a gaping hole in security.

Binary or Installers

If the application is just required to execute, (and does not make changes to files on the endpoint), specify it, (preferably by hash), as a binary set to allow. If the application does make changes to files on the endpoint, as previously, specify it as an installer.

This is the recommended approach with the application configured by hash. This method requires the most administrative effort but is the most secure when the application is specified as allowed by hash.

Configuration (Client) policy

The Configuration (Client) policy is used only to specify the local, (sadmin), command line interface

(CLI) password. This defaults to solidcore if the McAfee Default policy is applied to the endpoint. Always

ensure that a password other than the default password of solidcore is specified. In normal operation

there should never be a need to access the

local CLI, but this can form a useful escape

hatch for the user where an endpoint is off

of the corporate network or otherwise

unreachable. In order to use the CLI the

user must be a local administrator.

Exception Rules (Windows) policy

The exception rules are used to specify attributes that override or bypass the applied memory-protection

and other techniques applied to endpoints.

For example, if an application in its normal course of operation triggers a memory protection

mechanism, this application may need to be bypassed from that particular technique. This usually

Figure 24: Configuration (Client) policy


occurs in applications that are poorly written, and generally resolved by the vendor supplying an

updated version. In the meantime, in order for the application to continue to function, and the endpoint to

continue to benefit from all other applications receiving memory protection, this single application can be

bypassed from protection for this particular memory protection technique. In this case specify the file

name and the memory technique to be bypassed.

If the memory

protection technique in

question is the VASR

Forced-Relocation

bypass protection

mechanism, (which

forces relocation of

DLLs that have opted

out of Windows' native

ASLR feature), in

addition to specifying

the application

involved, it is necessary

to specify the name of

the DLL.

The Installer Detection

bypass option is used

to bypass the selected

file from the Package

Control feature,

discussed in the section

entitled ‘Application Control features’.

The Process Context

File Operations bypass

option defines a bypass rule for an application. In rare situations, Application Control can prevent

legitimate applications from running. This setting therefore bypasses control of the specified application,

and in doing so reduces the security of the overall solution. Modifications made to applications will not

be monitored and the applications will not be added to or changed within the inventory. To help minimize

this lowering of security, the parent process, (the process that calls the bypassed process), can

optionally be defined.

The Add to VASR Rebase DLL option adds the selected file to be rebased. By default, Application

Control only rebases three DLLs, (kernel32.dll, NT.dll and user.dll), except in the case of Windows XP,

where a number of additional DLLs including userenv.dll, wininet.dll, shell32.dll, netapi32.dll and

mscrvt.dll are rebased. Rebasing increases to the overall security of the solution, and may reduce the

memory footprint.

The deprecated memory protection techniques are usually not relevant and are not covered here, but for

reference are planned to be included in a soon to be published KB article.

Application Control features

Application Control features control areas of functionality within the product that can be enabled or

disabled. Policy defined previously is then applied to the enabled features to provide and control product

behavior and protection capabilities.

Table 21: Application Control features

Feature Default setting

Description

Activex Enabled When disabled this prevents the installation of any ActiveX controls. When enabled this allows installation of ActiveX controls where the web site

Figure 25: Exception rules


certificate is configured within the Application Control policy. Only the 32-bit version of Internet Explorer is supported for ActiveX control installations. Simultaneous installation of ActiveX controls using multiple tabs of Internet Explorer is not supported.

checksum Enabled If enabled Application Control calculates and matches the checksum of the file to be executed with the checksum stored in the inventory, and uses this along with the file name and file path to determine if a file is contained within the inventory. If disabled, Application Control simply matches the file name and file path to determine if a file is contained within the inventory.

deny-read Disabled Deny-read is not available to Application Control.

deny-write Enabled Deny-write is not available to Application Control.

discover-updaters

Enabled Retrieves a list of potential updaters that may be relevant to the current endpoint. This feature has largely been surpassed by the use of observe mode.

enduser-notification

Enabled This feature controls whether the user is alerted when a violation occurs. This typically happens when running in enabled mode.

Integrity Enabled This protects the files and registry keys of Application Control from unauthorized tampering. It allows the product code to run even when the components of Application Control are not in the inventory. This ensures that all components of the product are whitelisted. Accidental or malicious removal of the components from the whitelist is prevented to ensure that the product does not become unusable. When the product is in update mode, this feature is disabled to facilitate product upgrades. Other than during a product upgrade via update mode, it is strongly recommended that this feature is not disabled.

mp Enabled This feature enables or disables all memory protection features described in the section entitled ‘Memory protection features’ found earlier in this document.

mp-nx Enabled This feature enables or disables the No Execute memory protection feature described in the section entitled ‘Memory protection features’ found earlier in this document.

mp-vasr Enabled This feature enables or disables the Virtual Address Space Randomization memory protection feature described in the section entitled ‘Memory protection features’ found earlier in this document. Note that Virtual Address Space Randomization and Forced DLL Relocation are disabled on 32-bit versions of Windows Server 2003 and Windows XP to limit memory consumption. These features can be enabled, but before doing so it is recommended that a baseline of memory consumption is established, so the impact of enabling the feature can be measured.

mp-vasr-forced-relocation

Enabled This feature enables or disables the Forced DLL Relocation memory protection feature described in the section entitled ‘Memory protection features’ found earlier in this document. See note above about 32-bit versions of Windows Server 2003 and Windows XP.

network-tracking

Enabled This tracks files over network directories and prevents the execution of scripts located there. When this feature is disabled, execution of scripts on network directories is allowed.

ob-logging Enabled Observation logging is the process of gathering data at the endpoint and sending this back to the ePolicy Orchestrator server so that observations may be displayed and suggestions given within the ePolicy Orchestrator interface, under Menu | Application Control | Observations.

pkg-ctrl Enabled Package control manages the installation and uninstallation of all

MSI‑based installers on a protected Windows endpoint. If package control

is enabled applications that use msiexec will be allowed to install and be removed, (if they are both authorized to execute and assigned updater privilege). If disabled, msiexec.exe is blocked if it is launched by any process other than services.exe. In this situation if any other process including a user attempts to install or remove an application that uses msiexec, the application will be denied from executing.

Figure 26: End user notification


script-auth Enabled Prevents the execution of supported script files that are not contained within the whitelist, (for example .bat, .cmd, .vbs). If disabled all scripts are allowed to execute regardless of their state within the whitelist.

Feature management

Features can be managed through policy, or through a ‘SC: Run Commands’ task. To configure

Application Control to control features through an ePolicy Orchestrator task these steps are

recommended:

The first command configures the feature.

features <enable or disable> <name of feature>

For example:

Table 22: Feature management

To disable end user notification popups features disable enduser-notification

To enable package control features enable pkg-ctrl

The second command is optional and used to confirm that the command has successfully modified the

feature to the desired value. To achieve this, the following command should be used.

features list

Finally, it should be confirmed that the commands executed correctly by ensuring that the task that runs

the commands above is configured with the Require Response flag checked. Once the commands have

executed, the success or otherwise of the tasks can be confirmed by sending a wake-up call to each

endpoint and accessing Menu | Automation | Solidcore Client Task Log. The log should report the status

of the task. Note that features list does not display the status of observation logging, (ob-logging

discussed earlier). To display this feature the features list –d command must be used.

To configure this process within ePolicy Orchestrator, configure a task of type ‘SC: Run Commands’.

Figure 27: Solidcore Run Commands task

Configure this task as shown below, ensuring that ‘Requires Response’ checkbox is checked. If this is

not checked, the task will execute but provide no feedback back to ePolicy Orchestrator.


Figure 28: Feature management task

Once the task has completed in ePolicy Orchestrator check under Menu | Reporting | Solidcore| Client

Task Log for details of the commands executed.

Figure 29: Client Task Log

Each of these results can be drilled down into, to show the results of the task, with the results shown

below.

Table 23: Client response

Command Status Output

Features disable enduser-notification

Success

Features list Success … enduser-notification Disabled …


Self-approval

Self-approval is

enabled from within

the Application

Control Options

(Windows) policy.

Once enabled it will

prompt the user to

allow or deny an

otherwise blocked

activity. In this

example the user is

attempting to install

the Citrix

GoToMeeting

application.

To allow this activity

the user simply

enters the justification

in the text box, and

clicks ‘Allow’. If this

is not done within the

dialog time out the

activity will be blocked automatically. If the activity has been approved it is reported back to ePolicy

Orchestrator and is available for review from Menu | Application Control | Self Approval.

Where self approval is allowed, users should be instructed to ensure that any tasks they launch that

require self approval should be completed before the user moves away from their desktop. For example,

if a new application is being installed, the installation should be completed. Failure to do so could result

in some self-approval requests associated with the task being missed, (with the dialog timing-out and

denying the activity). This in turn could result in the changes required for the application to function

correctly being only partially approved, which may cause the application to fail.

Figure 31: Self-approval list

Each self-approval can be drilled in to and the full details exposed. Below this summary is a list of other

similar requests that have been collated within this request.

Figure 32: Self approval details

Figure 30: The self approval interface


At review time the following actions are available to the administrator:

Allow Binary Globally. This adds a rule to the Global Self Approval Rules rule group, to allow the

application to execute based on its checksum. The Global Self Approval Rules rule group is

included within the McAfee Default policy. The application will be allowed to execute on all

endpoints where this policy is applied.

Allow by Publisher Globally. This adds a certificate associated with the selected request as a

publisher with or without updater privileges. This will allow all the applications signed by the

selected publisher to make changes to executable files or launch any new application. The Global

Self Approval Rules rule group is included within the McAfee Default policy. All applicable

applications will be allowed to execute on all endpoints where this policy is applied.

Ban Binary Globally. This adds a rule to the Global Self Approval Rules rule group, to ban the

application from executing based on its checksum. The Global Self Approval Rules rule group is

included within the McAfee Default policy. The application will be banned on all endpoints where

this policy is applied.

Create Custom Policy. This opens the Self Approval: Custom Rules page and can be used to define

custom rules to allow, ban, or allow by publisher an application or binary file.

Delete Requests. This will remove the selected requests from the Self Approval page and

database.

Expanding control

Application Control can be extended to provide support for other types of interpreted languages. If doing

so, ensure that script naming conventions are consistent. For example ensure that all Perl scripts are

given the .pl extension. To configure Application Control to control other types of interpreters, four steps

are recommended.

The first command associates the extension with the interpreter, and adds this for control as a script.

scripts add <extension> <file name of interpreter>

For example:

Table 24: Adding interpreters

To add support for Java scripts add .jar java.exe scripts list so <location of .jar files>

To add support for Perl scripts add .pl perl.exe scripts list so <location of .pl files>

To add support for Ruby scripts add .rb ruby.exe scripts list so <location of .rb files>

The second command is optional and used to confirm that the command has successfully added

support for the specified interpreter. To achieve this, the following command should be used.

scripts list

Thirdly in order for the newly protected application scripts to be allowed to run, the folders

containing these scripts should be solidified, (so for short in the command below), to add them to

the inventory. If the first step was carried out prior to the inventory being created, when it is created

it will automatically include the additional script types within the inventory. If however the endpoint

has already had its inventory created, to add these new file types to the inventory, a task needs to

run the command:

so <location of script files>

Finally, it should be confirmed that the commands executed correctly.

To configure this task within ePolicy Orchestrator, create a Solidcore 6.1.0 task, of type ‘SC: Run

Commands’. Configure this task as shown below, ensuring that ‘Requires Response’ checkbox is


checked. (If this is not checked, the task will execute but provide no feedback in to ePolicy

Orchestrator).

Figure 33: Expanding control task

Once the task has completed in ePolicy Orchestrator check under Menu | Reporting | Solidcore| Client

Task Log for details of the commands executed.

Figure 34: Client Task Log

Each of these results can be drilled down into, to show the results of the task, with the results shown

below.

Table 25: Client response

Command Status Output

scripts add .pl perl.exe Success

scripts list Success ... .sys "ntvdm.exe" .pl "perl.exe" .vbe "cscript.exe" "wscript.exe" ...

so c:\perl Success 00:00:02: Total files scanned 5, solidified 5

7. Install Application Control

Evaluation and licensed software

Where licensed, Application Control is available for download from the standard location,

(https://secure.mcafee.com/apps/downloads/my-products/login.aspx) by entering a grant number. Unlike

most other McAfee products, to enable Application Control functionality, a license key must be entered

within ePO under Menu | Configuration | Server Settings | Solidcore.

https://secure.mcafee.com/apps/downloads/my-products/login.aspx


Application Control is available for evaluation from the standard location,

(http://www.mcafee.com/apps/downloads/free-evaluations/default.aspx) after registration. An evaluation

key must be entered within ePO under Menu | Configuration | Server Settings | Solidcore. The

evaluation period is 30 days, and this may be extended once by contacting Technical Support.

Figure 35: Evaluation download

Preparing ePolicy Orchestrator

In order to manage Application Control from within ePolicy Orchestrator, four steps are necessary:

Install the Solidcore extension, Solidcore_6.1.0.zip

Install the Solidcore help extension, help_solidcore_610.zip

Check in the Solidcore package for Windows, SOLIDCOR610-xxx_WIN.zip

Add the license or evaluation key for Application Control under Menu | Configuration | Server

Settings | Solidcore

The installation process

Application Control can be installed using an ePolicy Orchestrator (ePO) deployment task. This guide

will focus solely on an ePolicy Orchestrator managed installation, except within the section entitled

‘Define and test escape hatches’, found under ‘Mitigations’, where it might be necessary to invoke other

methods.

Application Control will install and remain in a disabled state until it is enabled. Again, this enablement

can be performed using an ePO (Solidcore | SC: Enable) task or by using another process, manually,

using a management tool or script. For the purpose of this guide, and in the context of providing desktop

protection, it will be assumed and is strongly recommended that ePolicy Orchestrator is used to deploy

and manage the solution.

Installation with ePolicy Orchestrator

Application Control can be installed using a standard ePolicy Orchestrator product deployment task.

Figure 36: ePolicy Orchestrator deployment task

The enablement process

As part of the enablement step two processes must occur: the inventory must be created by scanning

all fixed disks for applications; to activate memory protection the kernel driver must be loaded, which

requires a reboot of the endpoint.

These two steps can be taken in either order, with the

ePO ‘SC:Enable’ task allowing the option of either limited

feature activation which will create the inventory without

forcing a reboot, or full activation by forcing a reboot

automatically after 5 minutes, and then creating the

inventory following the reboot. The inventory collection

scan can be configured to run at high, normal or low

Windows process priority. Figure 37: Reboot warning dialog

http://www.mcafee.com/apps/downloads/free-evaluations/default.aspx


Setting the scan priority of low will have minimal impact on

the endpoint and the user experience, with the process

yielding to higher priority processes. Setting this value to

high will create the inventory more quickly at the expense

of other processes, and so may be useful if setting up a

test environment.

Whilst the inventory is collected, the endpoint will be

placed in update mode, which allows changes to take

place and incorporates these changes within the

inventory.

As part of the inventory creation process, Application

Control will scan each existing fixed disk, create a folder

called solidcore at the root of each disk and store the

inventory within this folder.

Enabling with ePolicy Orchestrator

Application Control can be enabled using an ‘SC:Enable’ task. The task can be configured to:

Run the inventory scan at a selected Windows priority of Low, Normal or High;

Perform a full activation by forcing a reboot prior to running the inventory scan;

Perform a limitation activation without forcing a reboot, and enabling memory protection on the next

reboot;

At completion of the inventory scan, the endpoint can be placed in either observe mode or enabled

mode

At the completion of the inventory scan, the inventory can be sent back to ePolicy Orchestrator

server for analysis.

Figure 39: The SC: Enable task

Uninstalling with ePolicy Orchestrator

If an endpoint is present and responding on the network then Application Control can be uninstalled via

ePolicy Orchestrator, using a deployment task with action set to ‘Remove’. Note that if Application

Control is running in ‘Enabled’ mode, then this will cause the uninstall task to fail. In this situation it is

recommended to switch the product to update mode before running the uninstall task. Regardless of

how the Application Control uninstall process is initiated, a reboot will be required in order to fully unload

the product.

Manual restart required

Create Inventory

Restart automatically

after 5 minutes

Create Inventory

Yes

Full feature activation

No

Figure 38: Full or limited feature activation


Figure 40: Begin Update mode task to switch endpoint to update mode

Figure 41: Deployment task to remove Application Control

Uninstalling manually

If an affected system is not present or responding on the network then the product can be uninstalled via

the Windows Control Panel using the ‘Uninstall a Program’ command. This method has several pre-

requisites, including the account being used to uninstall having administrative rights, and Application

Control running in a mode other than enabled. Note that uninstalling from the Windows Control Panel

will remove Application Control, but residual components will remain. Therefore removal using this

approach is not recommended, except in cases where it is unavoidable. For full details of this approach

see ‘How to manually remove Solidcore Agent for Windows’, found here


Upgrading from an evaluation version

To switch from an evaluation to a fully licensed version simply swap the evaluation key configured within

ePolicy Orchestrator, (under Menu | Configuration | Server Settings | Solidcore), for the full license key.

No further configuration is required on either ePolicy Orchestrator or on the managed endpoints running

Application Control. Do not remove the Application Control extension from ePolicy Orchestrator,

otherwise you risk losing events, observations, policies, rule groups and queries.

8. Test and observe behavior

The purpose of this phase of the pilot process is to:

Recognize the endpoint test process;

Understand the purpose of observations;

Monitor behavior against an expected norm.

Endpoint testing

The pilot process should have been started by specific objectives being identified and from this the

corresponding success criteria established. The role of endpoint testing is to allow the objectives to be

tested, and from the results obtained measure how closely Application Control meets these objectives.

This may be an iterative process, where policy is tuned in order to change behavior so that results may

more closely meet objectives.

Generation of observations

The objective when selecting and customizing policy is to arrive at a configuration that is as close to the

final configuration as possible given the information available. However, it is unlikely that all possible

configuration has been completed prior to testing Application Control. During testing, when operating in

observe mode any activities that are not catered for by the applied policy should generate an

observation. An observation is similar to a standard ePolicy Orchestrator event except that along with

capturing event details, it is used by ePolicy Orchestrator to suggest configuration that may cater for this

activity within policy.



Behavior monitoring

Behavior monitoring should allow you to observe the behavior of the endpoint - the operating system

and any applications, user interaction with the endpoint, overall system responsiveness, unexpected

events or behaviors, and anything else that differs from the norm.

The purpose of this is to establish if any general incompatibilities exist between the endpoint being

tested and Application Control, and more specifically, if any policy changes are required in order to

prevent incompatibilities. For example, an application may fail to run correctly, or an update may not be

applied correctly. Once this behavior is identified, and a policy change has been made, further testing

can be used to determine if this issue has been resolved, and if any further issues can be identified.

This step is complementary to the generation of observations step. Most policy changes required should

be identified by both steps, but in some cases it may be that only one of these steps will identify a

required configuration change. Alternatively, it may be that the change required can be more easily

identified by both viewing the observation generated and the behavior exhibited.

9. Review results

This phase is designed to take the objectives, and the success criteria designed to measure attainment

of these objectives, and compare these to the results obtained in the previous phase to determine how

closely the objectives have been met.

Usually the most significant part of the review process will be to understand what observations have

been generated, and what aspects of endpoint behavior have changed as a result of installing and using

Application Control. These results specifically are then fed into the step entitled ‘Tune policy’ in order for

changes to be made in configuration to cater for behavioral changes.

The Application Control dashboard is a good starting place to get an understanding of the overall type

and count of activity. Separate monitors from top left show spikes of activity over time, the mode of

operation of each protected endpoint and the number of agents that are non-compliant either due to

mode not being set to enabled or the local CLI being unlocked. The middle row shows the top systems

with policy violations, the top users with policy violations and the predominant observations. The bottom

row shows the most prevalent observations in the last 24 hours.

Figure 42: The Application Control dashboard


Once deployed in a production environment blocked activity should only represent that activity that

should be prevented, but even so, it is likely that confirmation of this will be required initially to grow

confidence in the product. Selecting an initial policy is discussed in a previous section entitled ‘Select

and customize polices’. Once the initial policy is assigned and testing has begun the following may be

observed:

No observations

Few to many observations

Unexpected behaviour or conflict observed

For each of these situations, the following sections recommend follow-up actions. If policy changes have

been made as a result of these actions; it is recommended that the product is tested again to confirm

expected behavior.

No observations shown

If no observations are shown the first step is to ensure that the product is deployed correctly and is

active in the correct mode. The endpoint should be running in observe mode, and should be

successfully talking back to ePolicy Orchestrator periodically and on-demand. Retrieving the status of an

endpoints will show some important details for troubleshooting. In order to do this configure an ‘SC: Run

Commands’ task using the status command.

Figure 43: Running the status command using an SC: Run Commands task

Viewing the results of this task within ePolicy Orchestrator from Menu | Reporting | Solidcore| Client

Task Log, should show the following.

Figure 44: The results of running the status command

Status should be shown as ‘Observe’

ePO Managed should show as ‘Yes’

Local CLI access should show as ‘Lockdown’

The status of each fixed disk should show as Solidified’


If any of these settings do not match, troubleshooting efforts should be focussed here initially.

The local interface available from the McAfee icon | Quick Settings | Application Control Events should

show activity on the endpoint. If this shows activity, but this activity is not shown back at the ePolicy

Orchestrator server, then check communications between the two.

Figure 45: Viewing activity from the endpoint

Few or many observations shown

The number of observations will very much depend on the number of endpoints protected, and the

volume of unauthorised change occurring on each endpoint. If a few endpoints are exhibiting a very high

volume of change compared to most other endpoints, it may well be worth removing these endpoints

from the pilot at least on a temporary basis. Use the MAC-D: Observations per endpoint chart as defined

in the section entitled ‘ePolicy Orchestrator queries’ towards the end of this guide.

Unexpected behavior or conflict observed at endpoint

If an endpoint exhibits unexpected behaviour of any kind then the following is recommended:

Examine the observations or events reported back to ePolicy Orchestrator. Assess the observations

and determine if the behaviour change could be associated with the activity reported. If so, tuning

policy is likely to resolve the issue;

If running in enabled mode, switch to observe mode and retest. If this resolves the issue, the

behavior is almost certainly a result of the endpoint policy requiring to be tuned;

If the behavior is still present, switch to disabled mode and retest. If it persists, remove Application

Control and assuming behavior returns to normal, contact McAfee Technical Support;

If the endpoint is unresponsive follow the information contained in the section entitled ‘Define and

test escape hatches’ found under ‘Mitigations’.

Gathering information to assist support

To assist support, collect the following information:

Problem description, any error messages and steps to reproduce the issue. A detailed description

of the problem should be supplied, along with the necessary steps to replicate it. These steps

should be explicit so that anybody unaccustomed to the environment can easily reproduce the

steps and hopefully the effect.

The McAfee minimum escalation requirements. Collect this information using the MER tool. The

MER tool is available through this document, ‘How to use MER tools with supported McAfee

products’, https://kc.mcafee.com/corporate/index?page=content&id=KB59385.


Run the GatherInfo utility. GatherInfo collects information related to log files, inventory, version and

endpoint state to assist in troubleshooting issues. This tool is installed with the product in the

product installation directory, (C:\Program Files\McAfee\Solidcore\Tools\GatherInfo by default). To

run GatherInfo open a command prompt, navigate to the \GatherInfo directory, type GatherInfo and

press Enter. GatherInfo generates the gatherinfo.zip file in the current working directory.

In the case of system crash, collect full crash dump.

10. Success criteria achieved

If the success criteria have all been met then the pilot phase has completed successfully, and the pilot

can be terminated. Therefore during this stage of the process the test results and observed behavior are

collected and collated, and then compared against the success criteria. If all success criteria have been

met then the process has completed successfully. If issues have been encountered, or unexpected

behavior has been observed, this can be researched, and a proposed solution implemented. Once

complete, the product can be retested and behavior observed to determine if the changes have resolved

the issue or changed the behavior.

11. Tune policy

Tuning process overview

The recommending method for deriving policy is to use observe mode. Prior to this it is assumed that

the initial policy will be defined and customized as accurately as possible. Once in observe mode the

endpoint can be used and tested to determine if any additional changes are required. If policy changes

are required they can be implemented and the endpoint retested. Once the policy is complete

Application Control can be moved out of observe mode and placed in a protection mode.

Use in Observe mode

Refine policy

Define initial policy

Test policy

Switch out of Observe mode

Yes

Minimal new observations?

No

Figure 46: The tuning process

Observations should be monitored on a regular basis and suggestions applied where appropriate to

ensure that the correct policies are in place. Failure to do this may result in a build-up of observations

that will become progressively harder to manage. However, before making any changes, it is essential

to understand the information provided by observations, and before reviewing observations it is

essential to understand the concept of generic launcher processes, and the consequences of

inadvertently granting them updater privileges.

Generic launcher processes

Generic launcher processes are those processes that can be and are used to launch many other

processes. Some may be a vital part of the Windows operating system, such as lsass.exe or

userinit.exe. Some are useful generic programs that can be used for many purposes such as Windows


Explorer, Internet Explorer, cmd.exe or svchost.exe. Others may be useful utilities that are flexible

enough to be used for purposes other than which they were intended.

Because of the potential for abusing these processes, they should never be configured as updaters. For

example, if Windows Explorer were configured as an updater, then any process it was used to launch

would inherit these rights. This would allow an attacker, or even a user to circumvent most of the

protection offered by Application Control. For this reason although observations are generated for

generic launcher processes, no suggestions are provided. Similarly, when using the Self Approval

feature, no updater rules are generated for generic launcher processes seen at the endpoint.

Where an event or observation that should be authorized to run but includes a generic launcher process

is encountered, it is important to find a method to allow the activity to continue without specifying the

generic launcher process as an updater. Note that generic launcher processes are defined under Menu |

Server Settings | Solidcore.

Some good examples of how generic launcher processes can be configured as updates can be found in

the Windows Update rule set, (found under Menu | Configuration | Solidcore Rules).

Figure 47: Using generic launch processes safely as updaters

In the examples shown above:

‘iexplore.exe’ is granted update privileges if and only if it is using the wuweb.dll library. This allows

Windows updates to occur without issue, but does not grant Internet Explorer update privileges at

all other times

‘svchost.exe’ is granted update privileges if and only if it is calling the wuauclt.exe process. Again

this drastically limits the capability of the svchost process.

Reviewing observations

When viewing an observation the first fundamental question that needs to be answered is ‘Should the

activity represented by this observation be allowed to take place or should it be prevented?’ To help

answer this question you need to interpret the observation.

Based on knowledge of the environment the following questions should be considered:

Is this expected behaviour? If so, then it simply becomes an exercise in determining how to

authorise the process, rather than whether to authorize the process. Today many applications have

built-in update mechanisms. If the application is attempting to access the vendor web site, using a

process that originates from a file signed by the vendor then this is likely to be a safe process, and

in all likelihood should be permitted. If not it should be investigated further to determine what else is

known about it before permitting it.

McAfee GTI will analyse the file and provide a cloud trust score that can be used to judge the

nature of the file. Does the application have a cloud trust level? If 5 known clean, or 4 assumed

clean then the file is almost certainly safe. If 2 suspicious or 1 malicious then the file is almost

certainly unsafe. If a GTI setting of 3 unknown is present, it may be that the GTI lookup needs to be

refreshed. This will happen automatically and periodically, but to force a refresh go to Menu | Server

Settings | Solidcore, change the value of ‘GTI Cloud: Do fresh syncing of Cloud Details of all the

binaries in Inventory from Cloud’ to ‘Yes’ and save. This will refresh all hashes very quickly.

If not classified, ensure that the endpoint anti-virus software is up-to-date and consider carrying out

an on-demand scan of the file.

If GetClean is available consider submitting the file for analysis. GetClean is currently only available

to Platinum customers, but may be made available to all customers towards the end of 2013. For

details, see https://kc.mcafee.com/corporate/index?page=content&id=KB73044. Note this URL

requires a login with a Platinum support contract to view.


Is it present elsewhere in the environment? By accessing Menu | Application Control | Inventory,

and searching for the binary name, it will show a count of how many endpoints have this file allowed

or banned. Any endpoints where the application is allowed are likely to have had that file present at

the time that the inventory was collected. Any banned instances are likely to have resulted from file

downloads since the inventory was collected.

Do you have any local information about the application? Have you seen the file before or do you

have any knowledge of its use? Does its name or the owner of the digital signature if signed

suggest a purpose or legitimate use? Is it being used by a particular role of user, or in a specific

location?

Examining this activity, it will almost always represent one of four types of events:

An application that is trying to run but prevented. This may happen when a user has downloaded a

utility and is attempting to execute it, rather than for example going to an approved location to

execute it;

An application that is trying to change the whitelist. The update process for a particular application

may not be understood, or may not have been considered and so is not catered for within any

particular policy;

An application that is trying to be moved or deleted. This can happen when for example a user is

attempting to move application files;

An application that is triggering a memory protection event. This can happen when an application is

not well written. For example, No Execute, (NX), memory protection may cause a conflict with an

application if the application is not NX-compliant, or in limited cases when Application Control does

a check for NX compliance. In this situation it may be necessary to create an application bypass

rule for NX protection for this application.

The observations interface

The observations interface is accessed from Menu | Application Control | Observations. Two tabs are

present:

Predominant observations. This tab shows the top 10 observations after they have been collated

and grouped by either the process name or the application binary involved;

Observations. This shows individuals observations after the raw observations have been processes

and heuristics applied, (such as a single install process spawning multiple child processes), to

ensure only relevant observations are shown.


Predominant observations

The predominant observations interface is shown below, populated with observations generated by endpoints. Each item of data is explained following this figure.

Figure 48: Predominant observations


The process name is the name of the Windows process that was responsible for taking some

action. When a single path and process name is specified, this process was responsible for taking

actions across multiple application files. The names of these application files is available by drill

down on the multiple binaries link. For example svchost.exe is shown below, complete with a GTI

trust level of Good, and the list of application files that it was responsible for acting upon, their

checksum and GTI trust level and the count of each file.

Figure 49: Multiple binaries drill down

The binary name is the name of the application file on which some action was taken. Where a

single binary name is given this binary has been acted upon by multiple processes. The names of

these processes is available by drill down on the multiple processes link. For example

WatsonRC.dat is shown below, complete with a GTI trust level of Unclassified, and the list of

processes that have acted upon this application, their checksum and GTI trust level and the count

of each process.

Figure 50: Multiple processes drill down

Type shows the action that the process or processes performed on the application file or files.

Where multiple binaries are involved, it is likely that different actions may have been performed on

different files.

Count shows the overall count of grouped observations for each predominant observation.

Actions allow one of three possible actions:

‘Exclude’ adds a filter rule to prevent the generation of the selected observations. These rules are

added to the Global Observation Rules rule group. This rule group is present in the Application

Control Rules (Windows) McAfee policy, and as a result is applied to all the endpoints using this

policy and any other policy containing this rule group. After exclusion, the observations are removed

from the Predominant Observations page, and all similar observations purged from the ePolicy

Orchestrator database.

‘Approve’ adds rules to allow the binary files associated with the selected observations to run.

These rules are added to the Global Observation Rules rule group as mentioned above. After

approval, the observations are removed from the Predominant Observations page, and all similar

observations purged from the ePolicy Orchestrator database. Note that if a generic launcher

process is the process responsible for taking actions, (for example svchost.exe in the example

above), then due to the danger associated with configuring a generic launcher processes as an

updater, the ‘Approve’ option is not available. The ‘Show Suggestions’ option from the observations

tab will allow action to be taken on this suggestion.

‘Create Custom Rules’ is available from the Actions button if a single predominant observation is

selected. This allows the administrator to review and add the rule to a selected rule group to allow

the binary file associated with the selected observation.


Observations

The observations interface is shown below, populated with observations generated by endpoints. Each item of data is explained after the figure.

Figure 51: The observations interface


When accessing this interface note that the time filter defaults to showing observations for the last 1

hour, so ensure you select the relevant time period. The filter also selects Pending observations, and

allows searching based on process name (the object taking action), binary name, (the application file

being acted upon), and observation type, (the type of action). Note that when searching for either

processes or binaries, (application files), with this filter, ensure you select the ‘ends with’ operator, (e.g.

‘Process Name ends with svchost.exe’), or use the full path to the process or binary name, (e.g. ‘Binary

Name equals C:\MSI test\7z920-x64.msi’). Search for a blank field to return the interface to displaying all

observations.

Fields include:

Notification Time is the date and time at which the observation occurred at the endpoint;

Host Name is the name of the host on which the observation occurred;

User Name is the name of user associated with the process that caused the observation;

Binary name is the full path to the application file on which some action was taken;

Trust Level is the enterprise trust level of the application file on which some action was taken;

Process name is the name of the process that performed some action;

Observation Type describes the action taken by the process on the binary;

Actions provides access to the ‘Suggestions’ interface;

Approval Status shows the status of the observation as either Approved, (implemented), Dismissed,

(ignored), or Pending, (awaiting action);

Group Name is the location of the endpoint within the system tree;

Publisher is the name taken from the certificate used to sign the application involved.

Suggestions

The suggestions interface is used to turn observations in to policy. It shows details for the observation,

and provides options that can be selected to allow the activity in future.

Figure 52: The suggestions interface

The left side of the interface shows the process tree – in this case explorer.exe launched setup.exe.

Windows Explorer started a process and attempted to run an executable, and this execution was or

would have been denied depending on the mode the endpoint was running in. In enabled mode,

execution would have been blocked, in observe mode, execution would have been allowed. In either

case, the activity did not match an authorised mechanism, and so an observation was generated.

Note that the actions visible on the right will be dependent on the level of the process tree selected. In

the above figure setup.exe is selected. If explorer.exe had been selected, (a generic launch process),

then no actions would have been available, since generic launch processes should not be explicitly

trusted.

In enabled mode, where this activity should have been allowed, the observation can easily be added to

an existing policy to allow the activity in future. If in observe mode, the activity would have been allowed

on the endpoint on which the observation was generated, but can be added to policy to allow other

endpoints that need to perform the same activity in future to do so using an authorised mechanism.


The binary has been subject to GTI lookup and has a cloud trust score of 5, and so has it been assigned

an enterprise trust level of good. The checksum has been derived for this file. Given the name, path and

checksum, and the fact that execution was denied, it can be concluded that the file is not contained

within the whitelist of the endpoint attempting to run this application.

If the decision is made that the file should be permitted to run, there are a number of actions available to

allow this to happen. In most of the cases below, (the exception being ‘Add to whitelist’), some

configuration is applied to a selected rule group:

Add to whitelist. This action will add the individual file to the inventory of an individual endpoint.

When adding the file, the interface provides an option to add the application to the inventory of

other endpoints encountering the same file name.

This method adds the file to the inventory by creating a Solidcore task to run the solidification (so)

command on the full file path of the file to be added. This task and its success can be viewed by

accessing Menu | Automation | Solidcore Client Task Log. The figure below shows the command

used to add the free-hex-editor to an endpoint inventory.

Figure 53: The 'Add to whitelist' task

Add as updater. The objective is to add this configuration to a policy assigned to an endpoint. The

interface allows it to be added to a specified rule group. If this rule group is not already assigned to

a policy, (that has been applied to the endpoint), it should be added to a policy, and that policy then

assigned to the endpoint. However, in order to execute, (and take advantage of its updater

privileges), an application needs to be authorised to do so. Adding as updater will not automatically

authorise the file.

Figure 54: Add as updater

Add Parent as Updater. This action assigns the file associated with the parent process, (the

process that launched this process), file updater privileges by adding it as an updater to a rule

group. This option may prove useful if the child process is a generic launch process that cannot be

assigned updater privileges. Again, the rule group that this configuration is added to should be

applied to a policy applied to the endpoint. However, as before, in order to execute, (and take

advantage of its updater privileges), the application needs to be authorised to do so. Adding the

parent process as an updater will not automatically authorise the file.

Add by checksum. This authorises the file to execute by adding its checksum in to a rule group,

(which should be applied to a policy assigned to the endpoint).


Figure 55: Add by checksum

Add publisher. This adds the certificate used to sign the file in to a rule group. In doing so, the

certificate can be trusted for file execution only, or can be trusted for both execution and to grant

updater privileges to applications signed with this certificate. The rule group should then be applied

to a policy assigned to the endpoint.

Figure 56: Add as publisher

Add as Installer. This authorises the file to execute and to gain updater privileges by adding a

number of file attributes including its checksum in to a rule group, which should be applied to a

policy assigned to an endpoint.

Figure 57: Add as installer

Add as Exception. This configures some sort of exception on a file within a selected rule group,

which should then be applied to a policy assigned to an endpoint. Extreme care should be taken

when adding exceptions, since it is very difficult to distinguish between a genuine application

conflict, and an actual attack. By defining an exception in the wrong circumstances, (for example

adding an exception for iexplore.exe), the endpoint can be rendered vulnerable to attack. If in

doubt, it is recommended that assistance be sought from Technical Support.

Figure 58: Add as exception

Add as Trusted Directory. This authorises the location from which the file executed to be trusted by

configuring this within a rule group, (which should be applied to a policy assigned to an endpoint). In


doing so, the location can be trusted for file execution only, or can be trusted for both execution and

to grant updater privileges to applications within the location.

Example observations

Self-updater observation

During normal usage of the endpoint the Foxit Reader.exe application spawned a process Foxit

Updater.exe which in turn attempted to write to a number of files. This activity was blocked by

Application Control and it generated the following event, ‘McAfee Application Control prevented an

attempt to modify file C:\Users\Jay\AppData\Local\Temp\Foxit Updater.exe by process C:\Program Files

(x86)\Foxit Software\Foxit Reader\Foxit Reader.exe (Process Id: 6324, User: W7-15\Jay)’.

The Foxit Reader application has cloud trust level of 4, and so is assumed clean. In order to allow the

Foxit Reader application to update itself, it can be granted the updater privilege within a rule group, and

the rule group applied to the endpoint, (as a result of this rule group being included within the

Application Control Rules (Windows) policy which is already applied to the endpoint).

Figure 59: Self-updater observation

Package control observation.

When installing ActivePerl using the installation program ActivePerl-5.10.1.1006-MSWin32-x86-

291086.msi, the installation was blocked, and generated an event at the endpoint ‘McAfee Application

Control prevented package modification by E:\Software\ActivePerl\ActivePerl-5.10.1.1006-MSWin32-

x86-291086.msi by user W7-15\Jay’.

In order to install an application using msiexec, the application must be authorised to execute and have

the updater privilege assigned to it. In this case, the installation program can be added to a rule group

as an installer, and the rule group applied to the endpoint.

Figure 60: Package control observation


Office 2013 installation observation

During installation, the setup.exe application was blocked by Application Control and generated the

following event, ‘D:\SETUP.EXE is not on the corporate whitelist and will not be allowed to run. If you'd

like your administrator to allow this, please click on Request Approval button’.

Setup.exe is assigned a cloud trust level of 5 - clean. In order to permit the installation, the setup

program needs to be permitted to run, but since this will be responsible for adding other applications,

(e.g. other executables, DLLs etc.), then the setup program must also be granted updater privilege.

To achieve this, the setup.exe program can be added by checksum, and also added as an updater. This

configuration can be added to a rule group, and the rule group applied to the endpoint.

Figure 61: Adding setup as a binary

Figure 62: Adding setup as an updater

ActiveX observation

During normal usage of the endpoint the user attempts to install an ActiveX control. Application Control

prevents the installation and generates the following event, ‘McAfee Application Control prevented

installation of ActiveX Component of P.C. Pitstop LLC by MFEDEMO\User2’ followed by

‘C:\Windows\Downloaded Program Files\mhLbl.dll is not on the corporate whitelist and will not be

allowed to run. If you'd like your administrator to allow this, please click on Request Approval button’.

In order to allow the installation of this ActiveX control, the certificate used to sign the control must be

trusted by being added to the rule group, and the rule group applied to the endpoint.


Figure 63: Adding a publisher to allow ActiveX installation

Application generating memory violation

During normal usage of the endpoint the wlanext.exe application generated a No Execute memory

protection violation, which was blocked by Application Control and which generated the following event,

‘McAfee Application Control prevented an attempt to hijack the process

C:\Windows\System32\wlanext.exe (Process Id: 7634, User: NT AUTHORITY\SYSTEM), by executing

code from an address outside of code pages region. Faulting address 0. The process was terminated’.

Wlanext.exe is assigned a cloud trust level of 5 – clean. In order to allow the wlanext.exe application to

function, an exception for this application can be created and added to the rule group, and the rule

group applied to the endpoint.

Figure 64: Memory violation observation

Reviewing Inventory

An overview of the reputation of files contained across protected endpoints can be obtained from the

Inventory dashboard. This shows the proportion of good, bad and unclassified files contained within the

inventory of endpoints. It also shows the top bad applications and on which endpoints they are located,

and the age of the inventory across all protected endpoints.

Figure 65: The inventory dashboard

GTI reputation can be viewed for all inventoried items under Menu | Application Control | Inventory

where it clearly differentiates between the good, the bad and the unknown. This view can be filtered and


searched, and allows files to be authorised or banned across the entire estate. To authorize or ban an

application, its checksum is added to the binary section of a selected rule, and this rule group should

already be applied to endpoints that require this configuration. In addition, the enterprise trust level

associated with this file can be set independent of the GTI cloud score. Whereas the cloud trust score

obtained from GTI will show McAfee’s assessment of the risk posed by a particular file, the enterprise

trust level allows this to be overridden to take in to consideration local factors.

Figure 66: GTI reputation for inventory

12. Switch to protection mode

Selecting a protection state

The following can be used to determine the recommended protection level for the production

environment. For most environments medium is a good starting point. Where the environment is subject

to significant or uncontrolled levels of change, (for example a user has administrative rights), then a fully

locked down implementation of Application Control is likely to impact that user significantly unless a

disproportionate level of planning has taken place before implementation. Conversely, where very little

change happens, and it does so in a very controlled manner, then a fully locked down implementation is

likely to be appropriate. For high assurance environments when higher levels of protection are the

overriding factor, then a locked down environment can be appropriate.

Low Medium High

High change environment Higher probability of

unplanned changes Availability prioritized

over security

High assurance environment

Low change environment Security prioritized over

availability

Figure 67: Selecting a protection state


Implementing protection states

Table 26: Suggested protection states

State What and how L

ow

Application Control is run in update mode. This allows for all changes to take place without impacting the user, and provides memory protection. It provides the administrator with visibility of which applications are being used where within the environment, and determines the cloud trust score for each application. This allows bad applications to be easily identified, and then banned.

Med

ium

Application Control is run in enable mode with self-approval enabled. This prevents change and provides memory protection, but allows the user to self-authorize applications. These self-authorized applications can be review and later approved or banned. It provides the administrator with visibility of which applications are being used where within the environment, and determines the cloud trust score for each application. This allows bad applications to be easily identified, and then banned.

Hig

h

Application Control is run in enable mode. This is a fully locked down mode, with the user able to run only those applications that have been authorized, and for change to be applied using only those methods configured within policy. Whilst the user cannot self-approve new applications, they are able to request approval for new applications. This can be granted as and when reviewed by the administrator. This prevents any unauthorized change to applications and provides memory protection. It provides the administrator with visibility of which applications are being used where within the environment, and determines the cloud trust score for each application. This allows bad applications to be easily identified, and then banned.

Delivering protection states

Once a final endpoint protection state has been established, it is recommended that this is delivered in

stages. Each new state will offer an enhanced level of protection, and will allow any last-minute

exceptions to be dealt with as efficiently as possible.

In the example below:

The HR department are found to use a small set of well-defined applications. Any change is very

tightly controlled and happens infrequently. Given these characteristics they have been assigned

the high protection state. This is delivered incrementally, by moving from observe mode to update

mode, to enable mode with self-approval and finally to enable mode with no self-approval. At each

stage, the users are informed of what is being implemented, why it is being implemented, and how

they should react to any unexpected behavior on their desktops. Note that in this example, when

switching from observe mode to update mode, the actual process is to go from observe mode

through enable mode to update mode, (although this can occur sequentially within a single task).

The production department needs a level of flexibility and so has been assigned the medium

protection state. Again this is delivered incrementally, by moving from observation mode to update

mode, to enable mode with self-approval. As with HR, at each stage, the users are informed of what

is being implemented, why it is being implemented, and how they should react to any unexpected

behavior on their desktops.

The mobile workforce in this example needs a lot of flexibility but requires the additional protection

that visibility can afford. They have been assigned the low security group, and are informed of what

is being implemented, why it is being implemented, and how they should react to any unexpected

behavior on their laptops.


HR Production Mobile

Low

Med

ium

Hig

h End state protection

End state protection

End state protection

Tun

ing

1st Stage protection

1st Stage protection

2nd Stage protection

Tuning

Figure 68: Delivering protection in stages

Periodic review and maintenance

It is recommended that once the project has completed, the groups and users assigned to these groups

are reviewed to determine if the optimum level of protection is being applied. If too stringent security is

applied this will become immediately obvious due to increased help desk calls, but is could be that a

higher level of security can be applied. In the example above it may be found that in fact production

workers do require flexibility, but that this flexibility can be delivered using an approved update

mechanism, and so self-approval is not required. Therefore the events, and specifically the self-approval

requests when reviewed to determine if they are acceptable, can also be viewed with the intent to

determine if the approval can be authorized automatically, to both reduce administrative overhead, but

also assist in moving users to a higher protection state.

In addition to this, it is recommended that a set of dashboard monitors be created that report on file and

memory-based detection events from different perspectives – e.g. by user, by endpoint, by process, by

object and by event type. Creating monitors that report across these different aspects of events will

enable visibility to the cause of disproportionality high volumes of any events to be more easily

identified. These events will either signify activity that has genuinely been blocked, or will indicate where

policy tuning is required. In the former case, it is worth investigating the cause of these events so that

they can be prevented or filtered.

Testing Application Control

Testing protection mechanisms

The following approaches can be adopted to testing various protection mechanisms provides by

Application Control. When performing testing ensures Application Control is running in Enabled mode,

otherwise whilst the event may register, they may be automatically allowed.


Table 27: Testing methods for Application Control

Protection Mechanism

Description Test procedure

Execution denied

An application that does not exist within the whitelist has been attempted to be executed, but this has been prevented by Application Control.

Copy a protected file to the desktop and attempt to execute that file. Whilst the file and checksum will match, the path will be different from that stored in the whitelist and execution will be denied.

ActiveX installation prevented

Application Control prevented an attempt to install an unauthorized ActiveX control.

Attempt to install the ActiveX control found on this site, http://www.pcpitstop.com/testax.asp

File write denied

Application Control prevented an attempt to modify an existing inventoried application by an unauthorized process.

Attempt to move a protected file to another folder. Since neither the process attempting the change, nor the user is assigned updater rights, the file write will be denied.

Package modification prevented

Application Control prevented an application using an MSI-based installer package from installation, modification or removal using an unauthorized mechanism.

Download and attempt to install an MSI-based application. Since the file will not be authorized, and the install process is attempting to invoke msiexec, it will be prevented from installing and trigger a package control event.

Best practice

Project planning

Understand the non-technical factors within the organization that may impact on the adoption of

whitelisting technology. If users are used to having full and uncontrolled access to their local

desktops, then the impact of imposing any controls that restrict this freedom should not be

underestimated. Controls should only ever be introduced in context. To assist with cultural or politic

changes of this nature it is essential to get users on-board, and illustrate clearly to them what is

planned and why it is planned, and to outline the benefits both to the business and to the user.

Where flexibility is necessary today it is important to understand what exactly is required, to ensure

that this will still be available after implementation, and to assure users that this will be the case.

Ensure you understand and convey the justification for deploying application whitelisting. This

justification is likely to include both an expectation of reducing total cost of ownership and a

reduction in the risk accepted by the organization. If this is clearly understood it should assist with

executive buy-in which is essential, if the project is to succeed.

o Prior to any form of deployment it is recommended that the desktop environment is

analyzed as a whole at a high level and users classified into work groups according to their

work styles and the level of flexibility that must be allowed within that type of work group.

During this exercise it would be useful to bring together representative workers,

management and IT to discuss and confirm the groups and their characteristics accurately

reflect the requirements of members of these groups.

o Initially target users whose work environment are well defined and wherever possible static

in nature. Not only will this result in a faster more successful initial deployment, but it will

build confidence in the solution within the user community and within management. The

rules gathered for this group will form a subset of the rules required for workers with less

static roles, and the experience of developing the internal process for building, testing and

implementing the solution will prove invaluable – start small and build up.

o Understand the possible protection states, and based on an understanding of the

environment, and the established work groups set realistic expectation for how much

control can be delivered. This may range from no lockdown but gaining visibility to the

applications in use, to a lockdown state that includes self-approved and followed by

review, to an entirely locked down environment. It is likely that different work groups will

result in different protection states being adopted. This understanding will help with

establishing goals, estimation of project duration, and help avoid project creep.

http://www.pcpitstop.com/testax.asp


Exception handling

It is essential to develop an efficient and reliable process for handling exceptions, and to make this

process simple, transparent and painless to users. The number of exceptions at the start of the

project will likely to be few, if a small number of simple endpoints are selected. This is a good

opportunity to refine the process for dealing with exceptions. As this number of endpoints being

controlled increases, and the variety of work styles included increases, a corresponding increase in

number of exceptions is to be expected. This stage will test the exception handling process, and if it

is not robust and efficient, productivity could be impacted - hence the need to get it right early on.

As policy is refined, and most exceptions are catered for, the number of exceptions will decrease

steadily, and this is a good indication that policy refinement is nearing completion.

Where significant change is planned for the organization, such as the adoption of a new major

application, then ensure that testing and piloting of the application involves Application Control in

the early stages of the project rather than close to the end - where expectations for fast completion

and tolerance for problems will be much lower.

Deployment

Installation using an ePolicy Orchestrator deployment task is the recommended approach.

If installing using other tools such as System Center Configuration Manager then reference ‘How to

manage a manually deployed Solidifier installation with ePolicy Orchestrator’ available here,


If VirusScan Enterprise is installed, then ensure Access Protection is configured to use ‘Standard

Protection’ rather than ‘Maximum Protection’.

When deploying to Virtual Desktop Infrastructure, (or VDI), the VDI template should have

Application Control deployed and configured, and be protected in the same way as for any

endpoint. This protected image should then be used as the VDI template to spawn virtual

machines.

Upgrades

Upgrades to existing installations should only be performed through ePolicy Orchestrator.

To perform a product version upgrade it is recommended to run Application Control in update

mode.

Whitelisting and Enablement

It is recommended to perform an on-demand scan of each endpoint before creating the inventory.

By running an on-demand scan any existing malware can be identified and clean or deleted as

appropriate. Once the inventory process commences, it should proceed more quickly if an on-

demand scan has occurred, since file access by the Application Control inventory process will not

trigger an on-access scan.

The enable task allows a scan priority to be specified. When enabling production systems consider

using a low priority to minimize the impact on the user.

The ‘SC: Enable’ task is designed to be used to enable endpoints. Whilst it is possible to use the

‘SC: Run Commands’ task to achieve a similar effect, the ‘SC: Enable’ task provides other

capabilities to ease the enablement process, so should always be used for this purpose.

Policy

The McAfee Default Application Control (Rules) policy and the McAfee Applications (McAfee

Default) policy should be used as the basis for endpoint configuration, and a separate organization-

specific policy added to the assigned policies within the system tree, (using the multi-slot

capabilities of Application Control policies). After making significant changes to the Application Control (Rules) policy use the ‘Solidcore: Rule

Group Sanity Check’ server task to check for policy conflicts. This task will update and correct rule



group that contain errors with installers or publishers, and issue warnings for trusted groups’ related

issues.

When developing policy it is good practice to use rule groups to group related configuration rather

than simply adding configuration directly in to the ‘My rules’ section of policy. The use of rule groups

allows configuration to then be shared amongst different policies as required, yet centrally

managed.

When defining applications, (for example as updaters), rules should be defined using the complete

path to an application wherever possible. If a file name alone is used to define an updater, then any

file on the system with that name will gain updater rights. By specifying a full path, only the desired

file will gain these rights. It is not recommended to allow any binary by its name – wherever possible specify a file checksum.

Observations

During the initial phase of deployment or when introducing new applications or updates in to the

enterprise, observation mode should be used. When in this mode, it is recommended that

observations are processed quickly and delivered as policies to protected endpoints, so that the

endpoints can be placed back in to enable mode. Failure to do this will result in a high volume of

observations which will both make policy creation more difficult, and may impact the ePolicy

Orchestrator event channel.

Reporting and GTI

When the Application Control extension is added in to ePolicy Orchestrator, it adds an automatic

response ‘Bad Binary has been detected in Enterprise’. The purpose of this automatic response is

to send an alert to an administrator when an application with a low trust score, (which is likely to

represent malware), has been found by Application Control GTI lookup. This is disabled by default

but should be enabled and configured.

It is recommend that all copies of all commonly used clean files found within the organization are

submitted to McAfee for inclusion within the GTI cloud. This could include master COE images, and

internal software repositories amongst others. This will then reflect within the Inventory view, (found

in ePolicy Orchestrator under Menu | Application Control | Inventory) as a reduced number of

‘Unclassified Apps’. Currently GetClean is only available to Platinum customers, but may be made

available to all customers towards the end of 2013. For details, see

https://kc.mcafee.com/corporate/index?page=content&id=KB73044. Note this URL requires a login

with a Platinum support contract to view.

Administration

Members of the IT staff that manage desktops should be granted access to the ePolicy

Orchestrator server, in order to be able to review self approvals that have been generated by users,

and then take appropriate actions to either allow or reject these, and to manage and refine policies

as required.

The administrator should always change the CLI lockdown password from the default.

User actions

Where self approval is allowed, users should be instructed to ensure that any tasks they launch that

require self approval should be completed before the user moves away from their desktop. For

example, if a new application is being installed, the installation should be completed. Failure to do

so could result in some self-approval requests associated with the task being missed. This in turn

could result in the changes required for the application to function correctly being only partially

approved, which may cause the application to fail.



ePolicy Orchestrator queries

The following additional queries are recommended to assist in the identification of pilot systems.

MAC-D: Candidate endpoints (32-bit)

This report will show 32-bit endpoints that have a compatible operating systems, sufficient free memory

and disk space that are not laptops. It will indicate which of these endpoints do and do not have

Application Control installed.

Figure 69: MAC-D: Candidate endpoints (32-bit)

Table 28: MAC-D: Candidate endpoints (32-bit) query configuration

Description Value

Result Type Managed Systems

Display results as Boolean Pie Chart

Configure Chart

Criteria to match Solidcore Properties | Product Version (Solidcore) greater than or equals 6.1 Label for matching slice Installed for non-matching slice Not installed Pie slice values are number of managed systems

Columns System Name, Last Communication

Filter

Computer Properties | Is 64 bit OS equals No Computer Properties | OS Platform equals workstation Computer Properties | OS Type contains 7 or contains Vista or contains XP Computer Properties | Total Physical Memory greater than or equals 512 MB Computer Properties | Free Systems Drive Space greater than 100 MB Computer Properties | Is Laptop equals No


MAC-D: Candidate endpoints (64-bit)

This report will show 64-bit endpoints that have a compatible operating systems, sufficient free memory

and disk space that are not laptops. It will indicate which of these endpoints do and do not have

Application Control installed.

Figure 70: MAC-D: Candidate endpoints (64-bit)

Table 29: Candidate endpoints (64-bit) query configuration

Description Value

Result Type Managed Systems

Display results as Boolean Pie Chart

Configure Chart

Criteria to match Solidcore Properties | Product Version (Solidcore) greater than or equals 6.1 Label for matching slice Installed for non-matching slice Not installed Pie slice values are number of managed systems

Columns System Name, Last Communication

Filter

Computer Properties | Is 64 bit OS equals Yes Computer Properties | OS Platform equals workstation Computer Properties | OS Type contains 7 or contains Vista or contains XP Computer Properties | Total Physical Memory greater than or equals 2 GB Computer Properties | Free Systems Drive Space greater than 100 MB Computer Properties | Is Laptop equals No

MAC-D: Observation count per endpoint.

This report will show the relative number of observations experience on each protected endpoint. The

purpose of this chart is to indicate if any endpoints are generating either no observations, (which might


indicate set up problems), or a huge number of observations, (which may indicate the endpoint is not a

good candidate for Application Control).

Description Value

Result Type Solidcore Observations

Display results as Bar Chart

Configure Chart Bar values are: Number of Solidcore Observations Bar labels are: System Name

Columns Detected Time, System Name, User Name

Filter None


Acknowledgements

The author would like to express his sincere thanks to the many people from Engineering, Product

Management, Support and Presales who contributed to this guide.

About the Author

Jason Brown is an Enterprise Solutions Architect specializing in Endpoint and working within EMEA. He

is responsible for ensuring that optimal solutions are provided to customers within the enterprise market

segment. Previously, as Principal Sales Engineer, he has assisted in delivering solutions in both a

presales and post-sales capacity to many of the FTSE 100 companies and authored best practice white

papers. He has created and executed partner training across EMEA, and reviewed and delivered many

customer training courses. He has worked within the security industry for the last 16 years. Prior to

joining McAfee, Jason worked at a defence contractor after completing a Bachelor’s degree in Computer

Modelling for Business and Master’s degrees in both Operational Research and Finance. He is CISSP

certified and a Cisco Certified Network Professional.

About McAfee

McAfee delivers proactive and proven solutions and services that help secure systems, networks, and

mobile devices around the world, allowing users to safely connect to the Internet, browse, and shop the

web more securely. Backed by its unrivalled global threat intelligence, McAfee creates innovative

products that empower home users, businesses, the public sector, and service providers by enabling

them to prove compliance with regulations, protect data, prevent disruptions, identify vulnerabilities,

and continuously monitor and improve their security. McAfee is relentlessly focused on constantly

finding new ways to keep our customers safe.

Documents

Application Control for Windows Desktop Best Practices ... · Application Control for Desktops Best Practices Guide 1.0 Page 7 technology), assist in reducing this window of vulnerability