AppCtrl BestPractices Guide

Application Control for Windows Desktop
Version 1.0
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
Application Control for Desktops Best Practices Guide 1.0
Page 2
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
Page 3
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
Page 4
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. Solomons 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.
Page 5
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 zeroday, 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 antimalware 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
Page 6
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
Page 7
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 endpoints 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 endpoints 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.
Page 8
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 McAfees comprehensive, real-time, cloudbased 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
Page 9
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 zeroday 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
noncode 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 nonexecutable 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.
Page 10
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:
Disabled
Mode
Observe Mode
Update Mode
Enabled 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
Page 11
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.
This task can be used either after
upgrading the installed version of
Application Control, or to disable an
escape hatch.
This task is typically used when
Application Control is being removed
from an endpoint.
SC: End
Update
Mode
SC:
Disable
This task has no configuration options.
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
Page 12
SC:
Enable
SC:
Observe
Mode
rebooted.
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 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 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.
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.
Page 13
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
Package
modification
prevented
Application Control prevented an attempt to modify an existing whitelisted

application by an unauthorized process.
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, (MS12037) 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
Process hijack
attempted
Process
terminated
VASR 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.
Application Control detected an attempt to exploit a process from a specified
memory address.
Application Control prevented an attempt to hijack a process by illegally
calling an API.
Application Control prevented an attempt to hijack a specified process by
executing code from a nonrelocatable 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
File deleted
File modified
File solidified
File unsolidified
Initial scan
completed
Inventory
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.
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).
An existing application has been modified, and the changes are reflected
within the inventory.
An application has been added to the inventory.
An application has been removed from the inventory.
The inventory creation process has completed.
The inventory has become corrupt. If the inventory does become corrupted,
Page 14
corrupted
Package
modification
allowed
ActiveX
installation
allowed
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.
Application Control allowed an application using an MSI-based installer
package to be installed, modified or removed using an authorized mechanism.
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 nonadministrative 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.
Page 15
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.
Start
6. Select and
customize policies
1. Define &
document
objectives
7. Install Application
Control
2. Establish success
criteria
8. Test and observe

behavior
9. Review results
3. Define the
approach
4. Identify resources
10. Success
criteria
achieved?
Yes
12. Switch to
protection mode
5. Understand &
document risks and
mitigations
End
No
11. Tune Policy
Figure 2: Pilot plan
Page 16
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.
Application Control for Desktops Best Practices Guide
Page 17
Table 6: Establish success criteria

Success criteria
A significant proportion of
endpoints are compatible with
Application Control
The product successfully installs
and operates across a range of
endpoints
No unexpected behavior or
obvious incompatibilities are
observed
Indicators
Evaluation of the desktop estate
indicates that 50% or more of
desktop endpoints are shown as
compatible.
No errors are indicated during the
installation process. The product
appears to load and function
correctly after installation
After installation the endpoint
operates correctly
How to measure
Number of endpoints
meeting hardware and
software requirements
Number of installation issues
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
Page 18
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 users 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
Determine the
proportion of potentially
compatible endpoints.
A significant
proportion of
endpoints are
compatible
with
Application
Control
Select a representative
sample of potentially
suitable endpoints and
determine how many
are compatible.
Select a random sample

of potentially compatible
endpoints and
determine how many
are compatible.
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 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 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
Page 19
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
32 bit
64 bit
Operating System
Windows XP with SP0 or later
Windows Vista with SP1
Windows 7 with SP0 or SP1
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
Memory
Single or multiple Intel Pentium or above CPUs

512 MB RAM (32-bit) or 2GB RAM (64-bit)
Page 20
Disk space
Network
100 MB free disk space for installation on system volume

100 MB free disk space on every volume that will be protected
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
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.
Potential
The endpoint being
protected is based on a
SOE or COE build, but has
a small number of welldefined 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.
Poor
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.
Endpoints having existing McAfee

products present, such as VirusScan
Enterprise and the McAfee Agent.
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
Page 21
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
Page 22
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.
Page 23
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;
McAfees 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 MP
VirusScan
Enterprise
BOP
Host
Intrusion
Prevention
System
GBOP
Application
Control
VirusScan
Enterprise
Host
Intrusion
Prevention
System
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
Page 24
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
Disabled
mode
Removal
Disabling in
Safe 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.
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.
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.
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.
Switch to observe
mode
Switch to disabled
mode
Remove Application
Control
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 disabled mode in

Windows Safe Mode
Remove Application Control
Page 25
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
Page 26
The sequence of commands required is shown below.

Table 13: Switching to observe mode using the command line interface
Command
sadmin status
Expected response
McAfee Solidifier: Enabled
McAfee Solidifier on reboot: Enabled
sadmin recover
ePO Password:
<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.
sadmin beginobserve
workflow-id
"Escape hatch
220413"
sadmin status
McAfee Solidifier is entering observation mode.
sadmin
lockdown
Local CLI has been successfully locked down.
McAfee Solidifier Observe

McAfee Solidifier on reboot: Observe
Purpose
To check the
operating mode of the
endpoint
To unlock the
interface
Enter the recovery
password configured
within the
Configuration (Client)
policy. The default is
solidcore.
To switch to observe
mode and tag all
changes using a
workflow ID.
To confirm the
endpoint has been
successfully switched
to observe mode
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.
Page 27
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
sadmin status
McAfee Solidifier: Enabled

McAfee Solidifier on reboot: Enabled
sadmin recover
ePO Password:
<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.
sadmin disable
McAfee Solidifier will be disabled on next reboot.
Purpose
To check the
operating mode of
the endpoint
To unlock the
interface
Enter the recovery
password configured
within the
policy. The default is
solidcore.
To switch to disabled
mode.
Reboot the endpoint manually.
sadmin status
McAfee Solidifier Enabled

McAfee Solidifier on reboot: Disabled
sadmin lockdown
Local CLI has been successfully locked down.
To confirm the
endpoint has been
successfully
configured after next
reboot
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 reinstall 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!
Page 28
Table 15: Changing the operating mode of Application Control

Configuration step
Boot in to Windows Safe Mode
Open Regedit and navigate to the
Change the value of RTEMode to 3
registry key
Change the value of RTEModeOnReboot to 3
HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\swin\Para Note that alternatively you can set both values to 0 to switch
meters.
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
Application Control Options
(Windows)
Solidcore
6.1.0:
Application
Control
Application Control Rules

(Windows)
Application Control Rules (Unix)

Solidcore
6.1.0:
Change
Control
Change Control Rules (Unix)
Solidcore
6.1.0:
Integrity
Monitor
Integrity Monitoring Rules (OS4690)
Solidcore
6.1.0:
General
Change Control Rules (Windows)
Integrity Monitoring Rules (Unix)

Integrity Monitoring Rules
(Windows)
Exception Rules (Windows)
Description
This policy is used to define self-approval, end
user notifications and in rare cases to enable or
disable specific features.
This policy defines authorised change
mechanisms, exceptions, event and
observation filters, and manual additions and
subtractions from the whitelist for Windows
endpoints.
This policy defines similar functionality for Unix
endpoints.
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.
This policy is used to specify the local
command line interface password. This
password should always be changed.
This policy is used to define rules to override or
bypass the applied memory-protection and
other techniques available within Application
Page 29
Exception Rules (Unix)
Control.
This same functionality is available under the
Exceptions tab within the Application Control
Rules (Windows) policy.
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 users 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;
Page 30
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.
Page 31
Overview
Installers
Publishers
Admin
App...X
......
Rule
Groups
My Rules
......
...
McAfee Applications
(McAfee Default)
My Rules
......
...
Rule
Groups
Organisation-specific
applications
Effective policy
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.
Page 32
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
Binary
Trusted Users
Publishers
Installers
Exceptions
Trusted Directories
Filters
Page 33
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 readonly.
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)

Effective policy
McAfee Default
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
Organisation-specific applications
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.
Page 34
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.
New App
Admin
McAfee Default
Effective policy
My Rules
COE Apps
......
...
Rule
Groups
......
...
Rule
Groups
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. Its 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.
Page 35
New App

McAfee Default
Admin
Effective policy
My Rules
......
HR Apps
COE Apps
......
HR Apps
Rule
Groups
Rule
Groups
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
Policy is assigned at this level and inherited to all

subgroups
This subgroup has a standard deployment task

assigned
This subgroup has a solidcore full features enable
task set to force reboot and switch to observe
mode
End observe group
This subgroup has an observe task set to end

observe mode assigned
Partial enable and

observe group
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
Page 36
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
Policy is assigned at the existing system tree desktop group
Install Task
This task is only assigned to endpoints that have

an AP-Install tag assigned
Full features
enable Task

an AP-FullEnable tag assigned
Partial features
enable task

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.
Page 37
Table 17: Selecting update methods

Method of
allowing
change
Updater
Publisher
When to use
When to avoid
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.
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.
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.
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.
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.
Installer
Trusted
directories
Additionally, if an organization deploys

applications created in-house, then if the
applications or application installers can
be signed, the publishers method can be
a great way to automatically authorize new
application releases.
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.
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.
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.
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.
Page 38
Update
mode
Trusted
Users
Manual
authorization
of
applications
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.
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.
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.
Self
Approval
Adding
directly to
the inventory
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.
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
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.
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 resourceintensive process to implement
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.
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.
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
Page 39
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
o
o
o
The application is managed using the standard endpoint management process, e.g.
Microsoft System Center Configuration Manager, (SCCM);
The application uses its own updating mechanism to periodically update itself, e.g. Firefox;
The application requires an application-specific process to be used to perform the update,
e.g. the admin upgrades the software periodically as required;
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
Page 40
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.
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.
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 should be configured as an updater
within the endpoint policy, (and is by default).
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.
A systems management agent is

used to deploy new software and
upgrade existing software.
An application uses its own updating
mechanism to periodically update
itself.
Windows update agent is used to

install operating system patches.
The application requires an
application-specific process to be
used to perform the update, e.g. the
admin upgrades the software
periodically as required.
Log-on scripts are used to configure
the endpoint and deploy updates.
Other scripts are used to configure

the endpoint and deploy updates.
An account or set of accounts is

used to manage change within the
environment.
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.
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.
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.
Page 41
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
Trusted
directories
Details
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.
Publishers
Specify the certificates used to

sign the applications present.
Optionally specify if the
publisher is an updater. Use
this option with extreme care.
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
endpoint, specify it as an
installer.
Considerations
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 subdirectories unless an exclusion is specified
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.
If the network location is not strongly protected with
both read-only access as standard, and an Antimalware 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
Page 42
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
Publishers
Details
Specify the certificates used
to sign the applications
present.
Optionally specify if the
publisher is an updater. Use
this option with extreme
care.
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
endpoint, as previously,
specify it as an installer.
Considerations
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.
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.
Figure 24: Configuration (Client) policy
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
Page 43
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
Figure 25: Exception rules
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
Activex
Default
setting
Enabled
Description
When disabled this prevents the installation of any ActiveX controls. When
enabled this allows installation of ActiveX controls where the web site
Page 44
certificate is configured within the Application Control policy.
checksum
Enabled
deny-read
deny-write
discoverupdaters
Disabled
Enabled
Enabled
endusernotification
Enabled
Integrity
Enabled
mp
Enabled
mp-nx
Enabled
mp-vasr
Enabled
mp-vasrforcedrelocation
Enabled
networktracking
Enabled
ob-logging
Enabled
pkg-ctrl
Enabled
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.
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 is not available to Application Control.
Deny-write is not available to Application Control.
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.
This feature controls whether
the user is alerted when a
violation occurs.
This typically happens when
running in enabled mode.
Figure 26: End user notification
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.
This feature enables or disables all memory protection features described in
the section entitled Memory protection features found earlier in this
document.
This feature enables or disables the No Execute memory protection feature
described in the section entitled Memory protection features found earlier
in this document.
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.
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.
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.
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.
Package control manages the installation and uninstallation of all
MSIbased 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.
Page 45
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.
Page 46
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
Features disable
enduser-notification
Status
Features list
Success
Output
Success
enduser-notification Disabled
Page 47
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
Figure 30: The self approval interface
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
Page 48
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
To add support for Perl
To add support for Ruby
scripts add .jar java.exe

scripts list
so <location of .jar files>
scripts add .pl perl.exe
scripts list
so <location of .pl files>
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
Page 49
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
scripts add .pl perl.exe
scripts list
Status
Success
Success
so c:\perl
Success
Output
...
.sys "ntvdm.exe"
.pl "perl.exe"
.vbe "cscript.exe" "wscript.exe"
...
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.
Page 50
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
Page 51
Full feature
activation
Yes
No
Restart
automatically
after 5 minutes
Create
Inventory
Create
Inventory
Manual restart
required
Figure 38: Full or limited feature activation
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.
Page 52
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 prerequisites, 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.
Page 53
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
Page 54
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
Page 55
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.
Page 56
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.
Define initial policy
Use in Observe
mode
Switch out of
Observe mode
Test policy
Yes
Minimal new
observations?
No
Refine policy
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
Page 57
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.
Page 58
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.
Page 59
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
Page 60
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.
Page 61
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
Page 62
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.
Page 63
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).
Page 64
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
Page 65
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-x86291086.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-MSWin32x86-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
Page 66
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.
Page 67
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
Page 68
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 McAfees 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 change environment

Higher probability of
unplanned changes
Availability prioritized
over security
High
High assurance
environment
Low change environment
Security prioritized over
availability
Figure 67: Selecting a protection state
Page 69
Implementing protection states

Table 26: Suggested protection states
High
Medium
Low
State
What and how

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.
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.
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.
Page 70
High
Medium
2nd Stage
protection
End state
protection
Low
1st Stage
protection
1st Stage
protection
Tuning
End state
protection
End state
protection
Tuning
HR
Production
Mobile
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.
Page 71
Table 27: Testing methods for Application Control

Protection
Mechanism
Execution
denied
ActiveX
installation
prevented
File write
denied
Package
modification
prevented
Description
Test procedure
An application that does not exist

within the whitelist has been
attempted to be executed, but this
has been prevented by Application
Control.
Application Control prevented an
attempt to install an unauthorized
ActiveX control.
attempt to modify an existing
inventoried application by an
unauthorized process.
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.

application using an MSI-based
installer package from installation,
modification or removal using an
unauthorized mechanism.
Attempt to install the ActiveX control found on

this site, http://www.pcpitstop.com/testax.asp
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.
Download and attempt to install an MSIbased 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.
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.
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.
Page 72
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 ondemand 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 organizationspecific 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
Page 73
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.
Page 74
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
Page 75
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
Page 76
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
Page 77
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 Bachelors degree in Computer
Modelling for Business and Masters degrees in both Operational Research and Finance. He is CISSP
certified and a Cisco Certified Network Professional.
About McAfee
McAfee, a wholly owned subsidiary of Intel Corporation (NASDAQ:INTC), is the worlds largest
dedicated security technology company. 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.
Page 78

AppCtrl BestPractices Guide

Uploaded by

AppCtrl BestPractices Guide

Uploaded by

Application Control for Windows Desktop

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

Application Control for Desktops Best Practices Guide 1.0

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

Application Control for Desktops Best Practices Guide 1.0

Understanding the problem

The speed of propagation

Application Control for Desktops Best Practices Guide 1.0

Zero-day attacks and targeted malware

The motivation behind malware

The impact of providing protection

Limitations of traditional anti-virus solutions

Application Control for Desktops Best Practices Guide 1.0

Application Control for Desktops Best Practices Guide 1.0

Application Control characteristics

Application Control for Desktops Best Practices Guide 1.0

Enabling a dynamic whitelist

The Inventory and Global Threat Intelligence

Application Control for Desktops Best Practices Guide 1.0

Memory protection features

Buffer overflow followed by direct code execution

Application Control provides four basic memory protection techniques:

Application Control for Desktops Best Practices Guide 1.0

Application Control cannot be uninstalled whilst running in enabled mode;

Modes, functionality and switching

Figure 1: Operational modes and switching

Application Control for Desktops Best Practices Guide 1.0

A workflow ID can be associated with all

This task can be used either prior to

This task has no configuration options.

This task can either be configured to force an

Application Control for Desktops Best Practices Guide 1.0

This task is typically run after installing

This task is often used to switch out of

Application Control in action

Application Control prevented an attempt to install an unauthorized ActiveX

Application Control for Desktops Best Practices Guide 1.0

Application Control prevented an attempt to modify an existing whitelisted

Application Control prevented an attempt to hijack a process by executing

Application Control for Desktops Best Practices Guide 1.0

Control and stability

Application Control for Desktops Best Practices Guide 1.0

Pilot or evaluation plan

8. Test and observe

11. Tune Policy

Figure 2: Pilot plan

Application Control for Desktops Best Practices Guide 1.0

1. Define and document objectives

Evaluate the suitability of the solution in your environment

2. Establish success criteria

Application Control for Desktops Best Practices Guide

Table 6: Establish success criteria

Number of errors attributable

3. Define the approach

Application Control for Desktops Best Practices Guide

Select a random sample

Create queries within ePO to determine potentially

Supported endpoint hardware and operating system requirements

Table 9: Minimum hardware requirements

Single or multiple Intel Pentium or above CPUs

Application Control for Desktops Best Practices Guide

100 MB free disk space for installation on system volume

Endpoints having existing McAfee

Application Control for Desktops Best Practices Guide

Identifying candidate endpoints with ePolicy Orchestrator

Figure 3: Identifying candidate endpoints with ePolicy Orchestrator

5. Understand and document risks and mitigations

Application Control for Desktops Best Practices Guide

The impact of Application Control on other McAfee applications

Impact of Application Control

Application Control for Desktops Best Practices Guide

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

Optimizing memory protection

Application Control for Desktops Best Practices Guide

Figure 5: Escape hatches for responsive endpoints

Switch to disabled mode in