appctrl bestpractices guide

8/10/2019 AppCtrl BestPractices Guide

1/78

Application Control for Windows Desktop

Version 1.0


2/78

Application Control for Desktops Best Practices Guide 1.0 Page 2

Contents

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Expanding control........................................................................................................................................ 10 Solution integrity .......................................................................................................................................... 11

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

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

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

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

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

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

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

Switching mode ........................................................................................................................................... 12 Application Control in action ...... ...... ...... ...... ..... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ..... ...... ...... ...... 13

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

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

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

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

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

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

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

Pilot or evaluation plan .................................................................................................................................... 16 1. Define and document objectives............................................................................................................... 17


3/78


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


4/78


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


5/78


Summary

McAfee Application Control for Desktops can be used to extend and enhance the protection provided byMcAfee VirusScan Enterprise and other endpoint protection technologies to desktops, notebooks andthe like. Rather than looking for the known bad, Application Control uses whitelisting techniques toprotect 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 ofmalicious 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 theendpoint is safe.

However, in order to successfully deploy any whitelisting solution, the protected endpoint must beallowed to make authorized change. For this to be implemented effectively, two challenges need to beovercome. The whitelisting solution must support the necessary change mechanisms, and the changemechanisms must be well understood and limited.

Technology can solve the first problem - McAfee Application Control offers a wide range of mechanismfor authorizing change. The second challenge - that of ensuring that the endpoint is suitable for awhitelisting solution involves looking at the role of the endpoint.

If the endpoint being protected is created as a Consistent or Common Operating Environment (COE) orStandard Operating Environment (SOE) build, running a standard set of applications, software updatesand service packs, then this type of endpoint is typically suitable. Whitelisting is an excellent choice forfixed function desktops, whether physical or virtual. If the user is a standard user - they do not haveadministrative 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 userrequires 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 fixedfunction environment, whitelisting may not be appropriate. Significant effort could be required to managethose systems with any whitelisting solution. In those cases, it is recommended that they are not the f irstsystems to be whitelisted, but rather they are considered for whitelisting once the solution has beendeployed to more appropriate systems.

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

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 hasevolved 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 persistover 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. From1997, where approximately 50,000 unique samples existed in t he Dr. Solomons malware zoo, to 2013,where approximately 100,000 samples are seen each day, or approximately one new threat everysecond.

The speed of propagation

As more devices are connected together through networks, intranets and the Internet, the power ofthose devices increases. As more and more services are delivered through the cloud, reliance oninterconnectivity grows. One immediate side effect is the expansion of available bandwidth and thespeed of connectivity more can travel faster. Malware authors have developed and adapted malwareto take advantage of these changes. Twenty years ago it frequently took malware a month to traversean office as floppy discs were exchanged to share data; today threats travel the globe in seconds.


6/78


Zero-day attacks and targeted malware

In contrast to the 100,000 new threats seen each day, there is a growing trend in targeted attacks attacks limited to a small number of specially selected recipients. These attacks are almost always zero-day, i.e. the attack is new and unknown to anti-malware vendors. These attacks are typically highlysophisticated, 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 thatsince they are using new code, no signatures exists to identify the malware, and so they goundetectable 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 17year old with no girlfriend writing the next big threat has come and gone. Three key motivations found toexist today are:

Financial gain, where the purpose of the attack may be to steal information that can be used directlyto obtain money, to steal the resources of a system that can later be sold on, or to place a systeminto a state where the user is forced to part with money in order to protect themselves, or recoverencrypted 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 softwareis 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 theseagainst a signature set. This signature set is large and growing. At time of writing, McAfee detectedapproximately 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 resourceconsumption 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 considerableresources. Finally, a full system on-demand scan can amalgamate the typical resource usage of abackground on-access scan but in a very compressed time interval, and again, have significant impacton an endpoint. Where a virtual desktop environment exists, and hardware, especially disk hardware isshared, 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 todaysthreats.

Endpoint protection

File protection

McAfee Labs see approximately 100,000 new threats per day. In order to provide protection againstthese, either signatures or heuristic detection is required. Malware authors are aware of heuristicdetection, and often use sites such as VirusTotal (http://virustotal.com ) to ensure that new variants ofmalware cannot be detected using heuristic techniques. If detections do occur at this stage in malwareproduction, then steps can be taken to further refine it, to make it undetectable using existing anti-malware products. Often this approach involves automation to make the creation of unique malwarepainless 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 ofdistribution, and the operational constraints of many organizations, the distribution of new signaturesmay take some considerable time and open a large window of vulnerability. Cloud-based protection inthe form of McAfee Global Threat Intelligence (GTI) File Reputation, (and other vendors equivalent
http://virustotal.com/http://virustotal.com/http://virustotal.com/http://virustotal.com/


7/78


8/78


to exist on an endpoint. How useful would it be to know exactly which other endpoints within theorganization 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 oforganizations networks and endpoints. Anti-virus software is inefficient from the perspective of having toconsume ever greater resources as it is expected to check for ever increasing volumes of malware, andthen re-check each and every time an update occurs. Anti-virus software provides little if any protectionagainst undesired and ad hoc changes to an endpoint which can impact on operational stability. Whereadministrative rights must be granted to non-administrative users, further loss of control occurs, and canput endpoints at increased risk. In addition, despite the fact that anti-malware sees each and every fileon an endpoint, it does not offer up any extra information that may be useful in planning or dealing withoutbreak situations. Whilst anti-virus software was the solution when viruses first appeared, itseffectiveness is diminishing. To retain the same level of security that was once offered by anti-virussoftware, 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 thosefiles on the endpoint not authorized to execute. It contains the file name, the full file path, and the SHA1checksum 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 aslocation, 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 thefollowing script files: ps1, vbe, bat, cmd, and vbs. This default list can be expanded for instance toinclude Java class files or any other interpreted language.

There are two approaches to creating the whitelist. The first and original method adopted by whitelistingvendors was to attempt to create and manage a central whitelist that contained every possibleauthorized application to be used on any protected system. Through painful experience this approachwas found to fail in almost all cases it took a massive amount of time to collect and collate, andinevitably uncommon applications or versions of applications were omitted from the list, which resultedin failed deployments. The second approach i s to derive each endpoints whitelist from the endpointitself. In this way the whitelist can be gathered in minutes not weeks, and is always able to capture thoseuncommon applications or non-standard versions.

The individual endpoint inventory creation process is used by McAfee Application Control and involvesscanning 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. Thisprocess is often referred to as solidification, and the files contained within the inventory as beingsolidified. The implicit assumption here is that all files present on an endpoint are safe and should beauthorized. But what if this is not the case?

Part of the inventory creation process involves passing the details of each endpoints inventory contentsback to the ePolicy Orchestrator (ePO) server. Once available to ePO, McAfee GTI provides a cloudtrust score for each application and binary file. The trust level indicates if the file is a good, bad, or anunknown file. The trust score ranges from a value of 1 or 2 representing known bad files, (such as atrojan, virus, or potentially unwanted programs or PUPs, 3 indicating an unknown and henceunclassified file, to a value of 4 or 5 representing known and trusted good files.


9/78


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 ofa Windows update, a new application being deployed, an existing application be upgraded, patched orremoved, 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 occasionswhen the whitelist may want to be changed manually. If an unwanted application is discovered on one ormore endpoints, the administrator may wish to prevent this file from being used, and so remove it fromthe whitelist. Alternatively, if a new utility is being introduced to desktops, the admin may choose to allowthis 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 theywould incur significant administrative overhead, and in all but the most fixed environments, render thesolution impractical. Therefore a number of different techniques are available to allow the product toautomatically cater for changes made to the system, as long as these changes are made using anapproved method. These methods are described below.

Named processes that are part of the existing inventory and that are authorized to make changes tothe whitelist when executing are known as Updaters .

X.509 certificates that are trusted by the organization ar e known as Publishers. Applicationssigned 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 toexecute 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 I nstallers and aregranted the right to both execute and to make changes to the inventory. One reason they areexplicitly authorized to execute, is that they may not have been present on the automaticallygenerated 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 theselocations are permitted to execute. In a similar way to publishers, trusted directories identified asupdaters 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 makechanges to the whitelist. These users may, for example be members of the IT support team that aretasked with fixing problems on desktops.

All of the above methods allow automatic changes to be made to enable a dynamically changingwhitelist, as long as the changes are performed according to pre-defined rules. In addition, changes maybe made in a more manual fashion through the use of explicit allow or ban rules that either allowunlisted 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 interfacewithin ePolicy Orchestrator allows files that reside in the inventory of an endpoint to be switched from anallowed to a banned state, and vice-versa.

Finally, Application Control provides an option to allow self approval. I f enabled, users can authorizechanges that would otherwise be blocked, by providing a justification, and so change the whitelist. Thisapproval 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, cloud-based multi-vector reputation service that enables McAfee products to protect customers against bothknown and emerging threats.

As a background process ePolicy Orchestrator will receive the inventory details from each endpointrunning Application Control. These will be looked up against the McAfee GTI cloud database, and the


10/78


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, theadministrator gets immediate visibility of the endpoints on which each file exists with either an allowed ora banned status. Applications can be authorized and banned directly from this interface, so if a bad fileis 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 imagesloaded in to memory. Application Control offers multiple memory protection techniques to prevent zero-day attacks. These techniques enhance native Windows features or signature based buffer overflowprotection. They are available on Windows 32 and 64-bit operating systems. At a high-level, theavailable 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 fromnon code areas of memory on 32-bit endpoints. This i s an abnormal event that usually signifies abuffer overflow attack is being attempted. CASP allows code to execute, but prevents it frommaking 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-bitsystems), to prevent code from being run from non executable memory regions. In most cases, thisrepresents is an abnormal event that occurs when a buffer overflow happens and the exploitattempts to execute code from such a memory region. NX provides granular bypass capability andraises 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 thelocation 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 tothe exploit.

Forced DLL Relocation forces relocation of Dynamic Link Libraries (DLLs) that have opted out ofWindows' native ASLR feature and are deliberately not randomized by the operating system. Thisopt-out characteristic is often utilized by attackers using modern exploitation techniques such asreturn-oriented programming or ROP exploits and just-in-time compilation or JIT exploits. ForcedDLL Relocation provides protection in these cases.

The Buffer overflow followed by direct code execution technique can be mitigated by Critical AddressSpace Protection and No Execute protection. Attacks using a buffer overflow followed by indirect codeexecution using return-oriented programming can be protected by Virtual Address Space Randomizationand Forced DLL Relocation.

Expanding control

Application Control provides control over a number of different types of files, referred to collectively asapplications. 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, Perland Ruby. For details of how this is achieved see the sub- section entitled Expanding control in thesection entitled Select and customize policies .


11/78


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 Solidcore6.1.0: General | Configuration (Client) policy. In addition, a separate optional password can bespecified 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 frommodification or deletion when this feature is enabled, and the product is running in enabled mode. Itis strongly recommended that this feature is not disabled;

The inventory file is protected from modification by Application Control. This file is obfuscated, and ifmodified outside of Application Control, then an Inventory corrupted event is generated andreported back to ePolicy Orchestrator.

Conclusion

Application Control is highly effective against zero-day and targeted attacks. Whilst anti-malwaresolutions need to be constantly updated, Application Control has no concept of signatures and simplyneeds to be made aware of any changes to the authorized change mechanisms. Since ApplicationControl maintains a relatively small list, (a few thousand entries within the whitelist versus many millionsof items within an anti-virus signature file), both memory and CPU overhead are insignificant comparedto anti-malware solutions. The additional stability and visibility of authorized change and blockedattempts at unauthorized change, can provide useful in anticipating problems rather than simply reactingto them when reported by the anti-malware solution. Overall, Application Control forms a valuable layerof protection within a defense-in-depth strategy.

Modes, functionality and switching

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

DisabledMode

Enabled Mode

Observe Mode Update Mode

Figure 1: Operational modes and switching

Disabled mode

The Application Control filter driver and kernel components are not loaded, no protection is active, and Application Control should have no impact whatsoever on the endpoint. This mode is present uponinstallation prior to any configuration having been applied. In order to enter and leave this mode, areboot is required. Hence typically the product is not placed in to this mode once it has been configuredand 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 theinventory 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. Ifmoving to disabled mode is unavoidable, before returning to enabled mode, the endpoint should be


12/78


placed in observe mode, and the inventory should be refreshed, by running a SC: Run Commands taskusing 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 beendeveloped, tested, and refined.

Enabled mode with self-approval

In an environment where an endpoint is locked down, self-approval allows users to authorize otherwiseblocked 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 inthe path to full lockdown, or as a final endpoint protection state. The warn but not block approach hasproved very effective in getting users to re-evaluate their requirements, across a number of McAfeetechnologies. 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 bypolicy, and at the same time assist in understanding changes that are not authorized within the currentpolicy. 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 isthen sent back as an observation, (rather than as an event), undergoes processing at ePolicyOrchestrator, and can result in a recommendation that can easily be implemented within a policy. Thepurpose of this mode is twofold firstly to help develop policy and thereby determine the rules requiredto allow applications to function as desired once placed in enable mode; and secondly to test policy byconfirming that the rules in place do in fact allow for any authorized changes that happen on anendpoint. Observations should be monitored on a regular basis and suggestions applied whereappropriate to ensure that the correct policies are in place. Failure to do this may result in a build-up ofobservations that will become progressively harder to manage.

Update mode

Application Control is active, but allowing change to take place, whilst providing and enforcing memoryprotection. This mode allows for product upgrade or removal to take place. It can also be used as anescape 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:BeginUpdateMode

A workflow ID can be associated with allchanges made and reported whilst in updatemode

This task can be used either prior toupgrading the installed version of

Application Control, or to enable anescape hatch.

SC: EndUpdateMode

This task has no configuration options. This task can be used either afterupgrading the installed version of

Application Control, or to disable anescape hatch.

SC:

Disable

This task can either be configured to force anendpoint in to disabled mode, (by forcing areboot when the task is run), or simply toconfigure the endpoint to run Application Controlin disabled mode the next time the endpoint is

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


13/78


14/78


If an unauthorized process, (e.g. originating from a malicious file executing on a remote endpoint), or anunauthorized user, attempts to modify, rename, move or delete an existing whitelisted and henceprotected file, Application Control would block this change. Examples of these types of events areshown below.

Table 3: Protection against unauthorized change

File write denied Application Control prevented an attempt to modify an existing whitelistedapplication by an unauthorized process.Packagemodificationprevented

Application Control prevented an application using an MSI-based installerpackage from installation, modification or removal using an unauthorizedmechanism.

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 Confickerbeing stopped with CASP by preventing payload execution; the VideoLAN VLC MKV MemoryCorruption vulnerability, a stack overflow exploit, (CVE-2011-0531) stopped using DEP by preventingpayload execution; and the Microsoft Internet Explorer Fixed Table Col Span heap Overflow, (MS12-037) protected by Virtual Address Space Randomization by preventing payload execution.

Examples of these types of events are shown below.

Table 4: Memory protection

Nx violationdetected

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

Process hijack

attempted

Application Control detected an attempt to exploit a process from a specified

memory address.Processterminated

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

VASR violationdetected

Application Control prevented an attempt to hijack a specified process byexecuting code from a non relocatable DLL.

Activity

The following event types show behavior that occurs as part of the normal operation of the product. Withthe exception of the inventory corrupt event, these events represented expected behavior and oncetuning has completed and the policy refined, these events can be safely ignored.

Table 5: Endpoint activity

File created

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

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

File modified An existing application has been modified, and the changes are reflectedwithin the inventory.File solidified An application has been added to the inventory.

File unsolidified An application has been removed from the inventory.

Initial scancompleted The inventory creation process has completed.Inventory The inventory has become corrupt. If the inventory does become corrupted,


15/78


corrupted then it should be recreated using an SC: Run Commands task using the socommand. In addition, GatherInfo should be used to collect endpointinformation, and Technical Support contacted. For details on the use ofGatherInfo see the section later in this guide entitled Gathering information toassist support.

Packagemodificationallowed

Application Control allowed an application using an MSI-based installer

package to be installed, modified or removed using an authorized mechanism. ActiveXinstallationallowed

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 ePolicyOrchestrator. This provides both visibility, (as to what happened), and context, (where and how ithappened). Event attributes include the time and date of the attempted change, the endpoint on whichthe event occurred, the process attempting the change, the object attempting to be modified, the type ofchange attempted, and user associated with the event. Similarly, if an inventoried item, not configuredas an updater, attempted to perform a change to the whitelist, Application Control would block andreport on this activity.

Control and stability

Application Control will protect an endpoint from unauthorized change regardless of the source of thatchange. In most cases this might be envisaged as a malicious application attempting to compromise theendpoint, whereas it may not actually be malicious. A user attempting to install an unauthorizedapplication, remove an existing protection product, or simply trying to upgrade an application to anincompatible or untested version that may conflict with other applications can compromise stability. In allcases where the change is unauthorized, it will be prevented and the change attempt reported. Thiscontrol brings stability to the endpoint, and provides the administrator with a view of the activity takingplace before it becomes a problem.

Users with administrative rights

Administrative users, (whether local, domain or enterprise administrators), will not be able to makechanges to applications on the endpoint unless changes are made using an approved mechanism. Inthis respect, administrative users are subject to the exact same restrictions in place as for non-administrative users. Whilst any, (administrative or non-administrative), user could be configured as atrusted user, (one possible mechanism that can be used to authorize change), this mechanism isunlikely to be recommended.


16/78


Pilot or evaluation plan

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

1. Define &documentobjectives

3. Define theapproach

2. Establish successcriteria

4. Identify resources

6. Select andcustomize policies

7. Install ApplicationControl

8. Test and observebehavior

9. Review results10. Success

criteriaachieved?

Start

End

11. Tune Policy

5. Understand &document risks and

mitigations

No

Yes12. Switch to

protection mode

Figure 2: Pilot plan


17/78

Application Control for Desktops Best Practices Guide Page 17

1. Define and document objectives

A pilot allows Application Control to be evaluated at low cost, and provide indications as to its suitabilityor otherwise within an organization. Conducting a highly visible pilot project will help you pre-sell thesolution, by assuring and demonstrating to staff that they will experience little or no impact or disruptionboth 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 theendpoint from a variety of threats, both known and unknown, existing, targeted and zero-day, withoutthe need to perform signature updates. It should enhance the stability of the endpoint, protecting it fromad hoc changes, and provide an enterprise-wide view of the applications in use across the estate. A pilotmay indicate the presence of existing unwanted software and malware, and provide a simplemechanism for its identification and removal. Therefore the results of the pilot are evidence of thetangible 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 withexisting endpoints and infrastructure, or suitability for Application Control across different endpoint

types); areas for policy and procedure changes, (workflow issues); and information for productionplanning (e.g., providing information for developing a realistic implementation schedule). Informationgained as a result of the pilot will mitigate acquisition risks and prepare for deployment within theproduction environment

2. Establish success criteria

The success criteria should be carefully defined to ensure that they will be the measure used to assesswhether the product is a good fit in the environment and that it has the required capabilities. It should beused 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 criteriamay be defined as below. The example below illustrates the success criteria obtained from interpretingone objective, that of evaluating the suitability of the solution in your environment. Before commencingthe pilot it is important to interpret all objectives for success criteria. If you fail to do this, then the resultsof testing will have little value in relation to the pilot, since they will not necessarily allow you to assess ifthe objectives have been met. This is a common mistake seen numerous times by the author, and willmost likely lead to a failed pilot.


18/78


Table 6: Establish success criteria

Success criteria Indicators How to measure A significant proportion ofendpoints are compatible with

Application Control

Evaluation of the desktop estateindicates that 50% or more ofdesktop endpoints are shown ascompatible.

Number of endpointsmeeting hardware andsoftware requirements

The product successfully installsand operates across a range ofendpoints

No errors are indicated during theinstallation process. The productappears to load and functioncorrectly after installation

Number of installation issues

No unexpected behavior orobvious incompatibilities areobserved

After installation the endpointoperates correctly

Number of errors attributableto Application Controlidentified

3. Define the approach

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

Roles and responsibilitiesIt will define the roles and responsibilities - some of which be met internally by the organization, andsome met by McAfee. It will establish how the product will be implemented, and how this implementationwill 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 formanagement purposes, for both a pilot and production environment, the presence of ePolicyOrchestrator should be considered mandatory . To gain the maximum benefit from the pilot process it isenvisaged that the management system will be present and already used to manage existing productson the pilot endpoints.

Pilot schedule

The approach will also document the time period over which the pilot will run. The pilot process shouldbe of sufficient duration to allow change mechanisms in use within the organization to be identified; toconduct any testing required to demonstrate success criteria; perform any required tuning, and allow areasonable residual period for soak-testing; where protected endpoints are used in the normal way bytypical users to confirm compatibility or highlight any issues. The residual period, after testing and tuninghas completed should cover at least one work cycle. For example, specific activities may occur everyweek, whilst others only at the end of each month. The residual soak test period should be of sufficientduration 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 productmeets the functional requirements of the business. For example, the product must install, execute,and protect the endpoint from unauthorised change, detect unauthorised change attempts andreport this, allow all authorized processes to complete successfully, allow administrative and userinteraction, allow for successful integration into existing endpoint management processes, reporteffectively, and uninstall correctly.

Empirical performance testing . These tests ensure that the endpoint provides acceptableresponse times and that general performance is not impacted. The product should impose no morethan an acceptable overhead on the endpoint it is protecting. It should not hamper user oradministrative 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


19/78


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

Measured performance testing. This test set can consider endpoint metrics, such as measuredstart-up or reboot times, launch time for local and network applications, and standard benchmarkingof 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 beingunimpaired. It will typically run over a longer period of time than other tests, and is more designed todetermine if the users normal tasks are influenced by t he product being installed and active.

Manageability . The series of tests covered in this set includes all of the basic managementfunctions, including remote installation, product upgrade and removal, configuration, cloud look-upand reporting.

Often two or more of these elements will be combined in a single test. The sample test below isdesigned 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 ofcompatible systems), and a manageability aspect (remote installation and reporting).

Table 7: Sample test plan

SuccessCriteria

Test Cases Tests

A significantproportion of

endpoints arecompatiblewith

ApplicationControl

Determine theproportion of potentiallycompatible endpoints.

Create queries within ePO to determine potentiallycompatible endpoints

Run these queries and record the number ofpotentially compatible endpoints

Determine the proportion of potentially compatibleendpoints

Select a representativesample of potentially

suitable endpoints anddetermine how manyare compatible.

Select a proportion of endpoints from the set ofpotentially suitable endpoints designed to representthe population of all endpoints

Install the product, place in observation mode, andallow the user to perform standard operation.Record any error messages received during thisprocess.

Determine the proportion of compatible endpoints

Select a random sampleof potentially compatibleendpoints anddetermine how manyare compatible.

Select a proportion of endpoints from the set ofpotentially compatible endpoints designed torepresent the population of all endpoints

Install the product, place in observation mode, andallow the user to perform standard operation.Record any error messages received during thisprocess.

Determine the proportion of compatible endpoints

The sample test plan will greatly depend on a comprehensive set of evaluation criteria beingestablished. Once established, each criterion this can be broken down into one or more test cases usedto evaluate the criterion. Once the test cases have been determined, steps required to perform tests canbe 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 TechnicalSupport contact. Identification of these people and agreement of roles and responsibilities throughoutthe duration of the pilot will ensure everybody is aware of what is required. This stage will also ensure


20/78


that all parties are aware of what is happening, and when this will be happening, and should lessen thechance 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 currentlysupported version of the McAfee Agent is supported f or use with Application Control;

Management server. Any currently supported version of ePolicy Orchestrator server version 4.5 and4.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 SQLServer 2005 or greater with DB compatibility level of 90 and above;

Database sizing requirements. To assist in estimating the amount of database storage requiredwhen deploying Application Control see the KB article ePO Database Sizing to manage ApplicationControl and Change Control 6.x hosts available athttps://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 thisinformation 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 onunderstanding, anticipating and authorizing the changes that should be permitted to occur on anendpoint, and preventing other change attempts. With this in mind, there are a number of aspects to beconsidered 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 attime of going to press.

Table 8: Supported architecture and operating systems

Architecture Operating System

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

64 bit

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

Table 9: Minimum hardware requirements

Hardware Minimum hardware

Processor Single or multiple Intel Pentium or above CPUs Memory 512 MB RAM (32-bit) or 2GB RAM (64-bit)
https://kc.mcafee.com/corporate/index?page=content&id=KB76736https://kc.mcafee.com/corporate/index?page=content&id=KB76736https://kc.mcafee.com/corporate/index?page=content&id=KB72753https://kc.mcafee.com/corporate/index?page=content&id=KB72753https://kc.mcafee.com/corporate/index?page=content&id=KB72753https://kc.mcafee.com/corporate/index?page=content&id=KB76736


21/78


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

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

For up-to-date information consult System requirements for Application Control and Change Control6.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 listedbelow, and avoid selecting endpoints which exhibit the poor characteristics listed. Whilst endpoints withpoor characteristics can still be protected by Application Control, significantly more effort may berequired, and so for the purpose of a pilot it is not recommended to select these systems.

Table 10: Candidate endpoint characteristics

Good Potential PoorThe endpoint being protected is created

as a Standard Operating Environment(SOE) build also referred to asConsistent or Common OperatingEnvironment or COE.

A COE is typically implemented as astandard disk image that can be massdeployed within an organization. Ittypically includes the base operatingsystem, custom configuration, a standardset of applications, software updates andservice packs.The user is a standard user: they do nothave administrative rights, use only

standard software, have well definedwork styles, may have fixed functiondesktops, and work in a similar fashion toa significant number of other workers inthe organization. Users should have ahigher than normal tolerance for testingChange to the endpoint is made in acontrolled manner. Ad hoc changes arenot permitted.Endpoints are physically close to thetesting location and easily accessible.

Endpoints having existing McAfeeproducts present, such as VirusScanEnterprise and the McAfee Agent.

The endpoint being

protected is based on aSOE or COE build, but hasa small number of well-defined differences, such ashaving an additional oralternative applicationinstalled or a newer versiondeployed.The user is a power user butdoes not haveadministration rights, or is orsoftware developer using acompiler. The majority of thetasks they perform are

standard and repeated.Change to the endpoint ismade in a controlledmanner. Ad hoc changesare occasionally permitted.

The endpoint is either a

non-standard build, or isused by the IT department.

Alternatively the endpointhas many non-standardapplications, or is notsubject to any standards.

The user has fulladministrative rights, andundertakes a large rangeof different task types.There is little or nocommonality whencompared with the tasks

performed by many otherusers.Changes are unpredictableand frequently delivered inan ad hoc manner.Laptops are infrequentlyconnected to the corporateLAN.

Known incompatibilities

There are a small number of endpoint characteristics that can result in an endpoint being incompatiblewith the current version of Application Control. At the present time, endpoints with these characteristicsshould be excluded from testing. Details can be found in the KB article McAfee Application Control 6.1Known 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
https://kc.mcafee.com/corporate/index?page=content&id=KB76579https://kc.mcafee.com/corporate/index?page=content&id=KB76579https://kc.mcafee.com/corporate/index?page=content&id=KB76579https://kc.mcafee.com/corporate/index?page=content&id=KB76457https://kc.mcafee.com/corporate/index?page=content&id=KB76457https://kc.mcafee.com/corporate/index?page=content&id=KB76457https://kc.mcafee.com/corporate/index?page=content&id=KB76457https://kc.mcafee.com/corporate/index?page=content&id=KB76579


22/78


endpoints from within ePolicy Orchestrator. Grouping or tagging can be used to assign policies andtasks 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. Manyorganizations leverage such a group and in exchange for their patience, reward them with earlyadoption of new technologies, or new product versions;

Alternatively endpoints that meet the hardware and software requirements of Application Controlcan be identified by running queries within ePolicy Orchestrator see the section entitled Reportingbest practices for details;

Finally, you can combine approaches, using the queries above to tag endpoints, and then useeither 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 evaluatinghardware and software parameters - details are given in the section entitled ePolicy Orchestratorqueries . These can then be refined based on local knowledge. For example, if during assessment ofwork styles Helpdesk workers are seen as likely candidates for Application Control, all Helpdesk PCscould be tagged within ePO, or have values set within the McAfee Agent Custom Props registry keys toidentify these systems. The queries suggested could then be refined to include these values whenassessing 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 stageis used to anticipate issues and provide a plan for dealing with these upfront, rather than ignore themand panic when and if they happen. Risks are likely to focus on three key areas, but individualorganizations may identify other risks.

Typical risks

Availability of key personnel . A successful project will depend on the availability of the rightpeople at the right time. If people are likely to be i nvolved in other projects, then there is scope forconflicts and changes to availability, which will necessitate either changing the people assigned tothe project, or delaying the project. Personnel changes will tend to delay projects, as they arebought up to speed.

Availability of endpoints . In order for the project to proceed, the correct management andendpoints need to be available. Management and endpoint hardware needs to be identified, needsto be prepared and may require change processes to be completed. This will require availability ofpersonnel and time to complete. Endpoints used for testing need to be identified, confirmed asbeing suitable and where these are in everyday use may need to be physically located and recalledto the office. Any users assisting with the pilot need to be informed, need to agree to help, and mayneed to be briefed on what is happening, (and any procedures to be followed in the case of anissue).

Software behavior . Software testing by users in a production environment is the most effective andefficient way to determine if a solution is compatible and to understand the typical behavior of that


23/78


solution. However, it introduces risks that are not present in a test environment. These risks areincreased 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 theuser 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 twoareas of potential impact:

The impact of Application Control on other McAfee applications The impact of other McAfee applications on Application Control

Impact of Application ControlThe most common and likely impact of Application Control on any application is where that applicationchanges the endpoint whitelist.

For security products this typically happens when the security solution updates itself. A signatureupdate 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, therules contained within the McAfee Applications (McAfee Default) policy should allow any McAfeeapplication 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, againthis can be impacted by the presence of Application Control. The most common example of this islikely to be where an on-access or an on-demand scan runs, detects malware and attempts tomake 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 makingchanges 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 isautomatically inventoried and so whitelisted. One side-effect of this process is that it is possible todeliberately 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 toquarantine. If the decision is made to clean the file, then as a side-effect of whitelisting the file, thefile will be reported back to ePO, and classified as good, bad or unknown in the same way allinventoried files are categorized. This then gives visibility to the presence of the application on anendpoint.

The second, and far less common type of impact can be where the application is poorly written, andtriggers memory protection events, which may cause the application to malfunction. This is unlikely tohappen where McAfee applications are concerned, but may happen for other types of applications.

Impact of McAfee applicationsMcAfee 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 assolidification), has been seen to be impacted where on-access scanning is enabled. The result ofthis is that this process has taken significantly longer in some cases. This is a logical consequencein some situations. The inventory process wi ll touch each application on an endpoint , and if theapplication has not already been scanned and the results cached by the on-access scanner, then afile scan will be triggered. This in itself will not take any great length of time to complete, but wheneach and every application is touched the solidification process in effect becomes akin to runningan on-demand scan and the solidification process in parallel. This has been seen to increase theinventory creation process by a factor of 3 or 4. This change in duration is likely to have no impactwhatsoever to the endpoint or the user, since the initial scan priority can and should be configuredto 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 avoidthis issue.


24/78


The first is to perform an on-demand scan this should ensure that when Application Controltouches each file, no on -access scan will be triggered, (since the results of the on-demand scanwill 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 withinVirusScan 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 isconfigured 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 singleisolated incident has been reported where the VirusScan Buffer Overflow Protection feature haspotentially been responsible for the inventory process stalling on a small number of systems. Thishas not been proved to be the cause of the stall, but a later attempt at creating the inventory withbuffer overflow protection disabled was found to succeed. It is not recommended to disable bufferoverflow 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-riskprocesses;

McAfees Host Intrusion Prevention System provides Generic Buffer Overflow Protection (GBOP) topotentially 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 onememory protection method is enabled as per the table below.

Table 11: Optimizing memory protection

ApplicationControl

VirusScanEnterprise

HostIntrusionPreventionSystem

ApplicationControl MP

VirusScanEnterpriseBOP

HostIntrusionPreventionSystemGBOP

Installed - - - -

Installed Installed - -

Installed Installed Installed

Mitigations

Once risks are identified, mitigation should be determined for each risk. Scheduling should take intoaccount assessment of availability of personal and endpoints and the likelihood of changes to these


25/78


assignments. In addition, providing additional leeway for slippage is advisable. When users are selectingfor piloting the solution, preference should be given to local users, whilst remote users should bethoroughly 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 alwayspractical, and so it is useful, (and often essential), to provide a means by which normal activity can beresumed as quickly as possible.

The objective of an escape hatch is to both provide the means with which normal activity can beresumed, but also to provide the confidence that such a capability exists. By communicating the purposeof the product, the reasons for piloting, the schedule for testing and the escape hatches to affectedusers, the perceived risk to end-user productivity will be reduced. This is especially important for userswho might be taking protected laptops on the road.

Table 12: Summary of escape hatches

Escapehatch Description

Observemode

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

Disabledmode

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 inenable mode to still exist in disabled mode. This escape hatch should be sufficientto allow a user to continue to work without hindrance. To enter disabled mode theendpoint must be rebooted. Also note that to leave disabled mode, the inventory

scan should be re-run using an SC: Run Commands task issuing the so command,and the endpoint rebooted.

Removal

Where problems are found to exist on an endpoint when the product is running indisabled mode, removal should be considered. It is extremely unlikely that

Application Control will have any impact whatsoever when in disabled mode, so thisstep is useful in confirming the issue is present on the endpoint even when

Application Control is not present.

Disabling inSafe Mode

When an endpoint is unresponsive due to product malfunction or misconfiguration Application Control can be disabled from operating by modification to itsconfiguration. This configuration is protected from tampering when the product isactive, 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 i ssue, move to the second escape hatch. Again, if thisfails, move to the final option.

Figure 5: Escape hatches for responsive endpoints

If the endpoint is unresponsive, it may be necessary to adopt another approach. In this case the bestmethod is to use Windows Safe Mode to disable the product. Again, if the first escape hatch fails toresolve the issue, move to the second option.

Switch to observemode

Switch to disabledmode

Remove ApplicationControl

Switch to disabled mode inWindows Safe Mode Remove Application Control


26/78


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 localcommand line interface. For en

appctrl bestpractices guide

Documents