Endpoint Security 10.1 Migration Planning Document

Endpoint Security 10.1

Migration Planning Document

Author

Jason Brown

Enterprise Technology Specialist

Intel Security

[email protected]

February 2016

Version 1.0

Endpoint Security 10.1 Migration Planning Document Page 2

Summary

Intel Security recently released McAfee Endpoint Security 10.1 to Corporate and Enterprise

customers. The architecture on which McAfee Endpoint Security 10.1 is build delivers a new

generation of integrated endpoint security, resulting in enhancements to protection and

performance, and simplified management and reporting.

The Threat Prevention module replaces VirusScan Enterprise, (VSE) - the cornerstone of anti-

malware protection within many organizations today, the Firewall module replaces the Host IPS,

(HIPS), Firewall component and the Web Control module replaces Site Advisor Enterprise, (SAE). To

optimize endpoint protection, customers should migrate from legacy technology to Endpoint

Security 10.1. Finally the Endpoint Security Platform is a module used by the three protection

modules listed above to provide common capabilities, (such as a GUI, logging and self-protection).

Any new software upgrade or deployment requires careful consideration and planning. This

document sets out to highlight those factors to be considered when planning a migration from an

environment protected by VirusScan Enterprise, to that using McAfee Endpoint Security 10.1.

It suggests a general model for migration, consisting of assessment, design, build, test & pilot and

implement phases, and recommends steps to be carried out during each of those phases.

This document can be used as a starting point when creating a detailed project plan of action for a

specific environment, or simply to illustrate the general process, with Professional Services used to

create the actual migration plan.

Threat Intelligence Exchange, (TIE) is compatible with Endpoint Security 10.1, delivered as a module

compatible with the Endpoint Security Platform but is not covered within this document - although

an approach similar to that used for the other modules, (Threat Prevention, Firewall and Web

Control) can be utilized for this module.

Whilst Endpoint Security 10.1 supports Windows, McAfee Endpoint Protection for Mac supports OS

X, (Snow Leopard and later versions), and shares many ePolicy Orchestrator policies with Endpoint

Security 10.1, a step designed to simplify the overall management process. McAfee Endpoint

Protection for Mac is not covered within this document.

I hope this document will prove useful, and please feel free to provide any feedback or suggestions

direct to the author, [email protected].


Contents

Summary ................................................................................................................................................. 2

Contents .................................................................................................................................................. 3

Figures and Tables .................................................................................................................................. 6

Background ............................................................................................................................................. 7

Objectives ............................................................................................................................................... 8

Migration process overview ................................................................................................................... 9

Assessment Phase ................................................................................................................................. 10

Identify products and modules in scope ........................................................................................... 10

Assess compatibility of endpoints .................................................................................................... 11

Hardware ...................................................................................................................................... 11

Operating System .......................................................................................................................... 12

Resources ...................................................................................................................................... 13

Assess support for managing Endpoint Security 10.1....................................................................... 13

Management software ................................................................................................................. 13

Management scalability ................................................................................................................ 14

Resources ...................................................................................................................................... 14

Gain familiarity with Endpoint Security 10.1 .................................................................................... 14

Product to module mappings ....................................................................................................... 14

VirusScan Enterprise 8.8 policy mapping ...................................................................................... 15

Host IPS 8.0 Firewall policy mapping ............................................................................................ 15

Site Advisor Enterprise 3.5 policy mapping .................................................................................. 16

Installation with legacy products installed ................................................................................... 16

Resources ...................................................................................................................................... 17

Assess policies, tasks and assignments methods .............................................................................. 18

Identify current management personnel.......................................................................................... 18

Identify any integration processes .................................................................................................... 18

Internal integrations ..................................................................................................................... 19

External integrations ..................................................................................................................... 19

Check known issues for relevance .................................................................................................... 19

Resources ...................................................................................................................................... 19

Identify personnel involved in migration process ............................................................................ 19

Identify suitable pilot users and endpoints ...................................................................................... 19

Document findings and decisions ..................................................................................................... 20


Design Phase ......................................................................................................................................... 21

Design a test plan .............................................................................................................................. 21

Design test cases ............................................................................................................................... 21

Functional testing.......................................................................................................................... 22

Integration testing ........................................................................................................................ 22

Product migration testing ............................................................................................................. 22

Management migration testing .................................................................................................... 23

Soak testing ................................................................................................................................... 23

Sample test cases .......................................................................................................................... 23

Sample functional test cases ......................................................................................................... 24

Sample integration test cases ....................................................................................................... 26

Sample product migration test cases............................................................................................ 27

Sample management migration test cases ................................................................................... 28

Resources ...................................................................................................................................... 28

Design pilot plan ............................................................................................................................... 29

Pilot plan considerations ............................................................................................................... 29

Soak testing ................................................................................................................................... 31

Design test & pilot environment ....................................................................................................... 31

Design user information plan ............................................................................................................ 33

Design production management architecture .................................................................................. 33

Design production rollout plan ......................................................................................................... 34

Design handover plan for operations ............................................................................................... 34

Build Phase ............................................................................................................................................ 35

Build test environment ..................................................................................................................... 35

Replicate policy and task assignments.............................................................................................. 35

Replicate integrations ....................................................................................................................... 35

Policy and task pre-migration review ............................................................................................... 35

Policy and task migration .................................................................................................................. 36

The Endpoint Migration Assistant..................................................................................................... 36

Overview ....................................................................................................................................... 36

Requirements ................................................................................................................................ 36

Legacy products ............................................................................................................................ 36

Resources ...................................................................................................................................... 37

Consolidating policies and tasks from multiple ePO servers ............................................................ 37

Migration progress reporting ............................................................................................................ 38

Test & Pilot Phase ................................................................................................................................. 40


Train administrators and helpdesk ................................................................................................... 40

Piloting in the lab .............................................................................................................................. 40

Piloting on production systems ........................................................................................................ 40

Determine migration rate ................................................................................................................. 40

Review and / or refine production rollout plan ................................................................................ 40

Document endpoint transition ......................................................................................................... 40

Prepare users .................................................................................................................................... 41

Implement Phase .................................................................................................................................. 42

Update production rollout plan ........................................................................................................ 42

Create production management environment ................................................................................. 42

Use existing hardware and infrastructure .................................................................................... 42

Build new hardware and infrastructure ........................................................................................ 42

Commence deployment .................................................................................................................... 43

Monitor success of deployment ....................................................................................................... 43

Monitor impact and issues ............................................................................................................... 43

Hand over management to operations team ................................................................................... 43

Post-migration optimization ............................................................................................................. 44

Conclusions ........................................................................................................................................... 44

Glossary ................................................................................................................................................. 45


Figures and Tables

Figure 1. Endpoint Security 10.1 architecture. ....................................................................................... 7

Figure 2. Migration process overview. .................................................................................................... 9

Figure 3. Query showing systems per product. .................................................................................... 10

Figure 4. Query showing specific VirusScan versions. .......................................................................... 11

Figure 5. Query filter criteria. ............................................................................................................... 12

Figure 6. Tag-dependent task configuration. ........................................................................................ 12

Figure 7. Query showing operating system version.............................................................................. 13

Figure 8. Current product and policy to Endpoint Security module and policy mappings. .................. 14

Figure 9. VirusScan Enterprise 8.8 policy mapping. .............................................................................. 15

Figure 10. Host IPS 8.0 Firewall policy mapping. .................................................................................. 15

Figure 11. Site Advisor Enterprise 3.5 policy mapping. ........................................................................ 16

Figure 12. Query showing broken Inheritance. .................................................................................... 18

Figure 13. Decreasing functional testing times. ................................................................................... 30

Figure 14. Soak test duration. ............................................................................................................... 31

Figure 15. Management and endpoint protection states. .................................................................... 32

Figure 16. Migration tracking query. .................................................................................................... 38

Figure 17. Query showing failed deployments. .................................................................................... 39

Figure 18. Query showing successful deployments. ............................................................................. 39

Figure 19. Creation of the production environment. ........................................................................... 42

Table 1. Installation with legacy products installed. ............................................................................. 16

Table 2. Sample functional test cases. .................................................................................................. 24

Table 3. Sample internal integration test case. .................................................................................... 26

Table 4. Sample external integration test cases. .................................................................................. 26

Table 5. Sample product migration test cases. ..................................................................................... 27

Table 6. Sample management migration test cases. ............................................................................ 28

Table 7. Pilot ePolicy Orchestrator server selection considerations. ................................................... 29

Table 8. Increasing-size group deployment. ......................................................................................... 30

Table 9. Equal-size group deployment. ................................................................................................. 30

Table 10. Single group deployment. ..................................................................................................... 30

Table 11. Products and patch versions supported for policy migration. .............................................. 37

Table 12. Optimization suggestions. ..................................................................................................... 44


Background

McAfee Endpoint Security redefines the way in which Intel Security (formerly McAfee) deliver threat

protection on the endpoint. This new technology delivers improvements in protection and

performance, whilst simplifying the installation, management, maintenance and response processes

associated with implementing an endpoint solution. These improvements are driven by significant

architectural changes that provide an integrated security framework at the endpoint, rather than

simply an anti-malware solution.

The foundation of Intel Security’s new endpoint security strategy, McAfee Endpoint Security 10.1,

(ENS 10.1), helps protect against known threats, detect new threats faster, and enables automated

workflows with actionable threat forensics to rapidly correct and respond. With its extensible

framework open the 3rd party solutions, McAfee Endpoint Security 10.1 improves productivity by

removing redundant security technologies and providing a framework to connect future

investments.

Where previously VirusScan Enterprise, the Host IPS Firewall, and Site Advisor web filtering have

been centrally deployed as individual products, McAfee Endpoint Security 10.1 communicates with

multiple endpoint defense technologies in real time, to analyze and collaborate against new and

advanced threats by blocking and quickly halting them before systems and users are impacted.

Defenses are collaborative and share insights across threat prevention, web security, firewall, (and

optionally Threat Intelligences Exchange (TIE)), modules. This results in more intelligent defenses

that operate together rather than in silos, for stronger detection and advanced threat response.

Figure 1. Endpoint Security 10.1 architecture.

Note that whilst any customer with an entitlement to VirusScan Enterprise will be licensed to use the

Threat Prevention, Firewall and Web Control modules shown above, the Threat Intelligences

Exchange (TIE) module, (and any subsequently released modules) may require a separate license.

No new versions of VirusScan Enterprise, Host Firewall or Site Advisor will be released, (although

patches for the existing versions of these products may be released), as Endpoint Security 10.1 will

replace these products.

McAfee Endpoint Security 10.0 was released to Small and Medium Business (SMB) customers in

November 2014. Since its release a number of changes and enhancements have been made to the


product to ensure it meets the requirements of corporate and enterprise customers. In December

2015, McAfee Endpoint Security 10.1 was released to all corporate and enterprise customers,

(accessible via grant number or through the Software Manager within ePolicy Orchestrator).

More information on McAfee Endpoint Security 10.1 is available here,

http://www.mcafee.com/us/products/endpoint-protection/endpoint-security.aspx

Objectives Any new software upgrade or deployment requires careful consideration and planning, so to simplify

the adoption of Endpoint Security 10.1, this document aims to highlight the factors that should be

considered prior to migration, and suggests an approach that can be utilized within larger

environments. The aim is to provide a migration strategy and methodology that can be used to

simply and quickly move from existing endpoint protection technology to Endpoint Security 10.1.

This document is designed to provide a high-level approach to migrating an environment, to both

Intel Security customers and partners. The focus of this document is on the approach - what should

be done rather than exactly how this should be done. Individual environments may execute different

steps in different ways, and the exact method selected will depend as much on any business

requirements or other factors within that environment as the capabilities of the technology.


Migration process overview The five phase migration approach is described below.

Assess Design BuildTest and

PilotImplement

Figure 2. Migration process overview.

Assessment Phase

This stage involves assessing the existing environment to ensure that all assumptions made have

been proved and that all of the requirements and dependencies for a successful outcome are

documented. In addition it should provide a snapshot of the existing state of the environment, and

help gain a realistic understanding of the effort, (time, personnel, hardware, etc.) required to

implement the migration.

Design Phase

This stage involves creating and documenting plans that will be used for testing within a lab

environment, piloting using production systems, and also during production rollout. It encompasses

test planning to ensure that the new solution delivers according to expectations and operates in an

acceptable manner, planning the final management architecture required to support Endpoint

Security 10.1, and identifying the resources required during testing and piloting. It plans for user

adoption of the new technology, as well as planning the handover process from the migration team

to the operations team if different groups.

Build Phase

The build phase involves building and configuring the test and pilot environment to match the

production environment; and the migration of endpoint configuration and creation of any existing

integrations, so that existing capabilities can be retained and tested to ensure they work in

conjunction with the new technology. Finally it involves establishing a process to report on the

progress of testing, which can be later reused during production rollout.

Test & Pilot Phase

This phase includes two distinct but complementary aspects of the process. The first is testing within

a lab environment, using the test plan designed in the previous phase to understand how well

features of the software operate within a lab test environment, followed by any modifications

required based on test results, resolving issues and retesting if necessary. Secondly, piloting involves

using live users from the production environment, understanding how migration occurs and how

features work within a production environment, and additionally, how it impacts on users. Finally it

includes delivering training to operators and administrators of the new solution, and reviewing and

updating of the production rollout plan based on lessons learned during this phase.

Implement Phase

This phase involves performing and managing the rollout of the new solution across the production

environment, and the monitoring of its successful implementation. If new management

infrastructure is to be created or repurposed, this phase also includes this step. Handover from the

migration team to the operations team happens during this stage, and finally, any post-migration

optimizations occur here.


Assessment Phase

Identify products and modules in scope It is essential to understand which products are in use today, and on which and on how many

endpoints. Queries can be created within ePO to report on overall product deployment within the

enterprise – for example a query could be created based on the ‘Others | Systems Per Product’

query type. This query will show how many endpoints have relevant products, and which versions

are deployed.

Figure 3. Query showing systems per product.

Alternatively a query could be created for each of the technologies to be replaced, VirusScan

Enterprise, Host IPS and Site Advisor Enterprise, based on product, patch or hotfix version. Note that

when viewing this query, since Endpoint Security 10.1 does not actually remove and replace Host

IPS, the number of systems having this product installed will remain constant.

Filters can be added to these queries to show how this total count is split between different groups,

departments or locations if useful in planning.


Figure 4. Query showing specific VirusScan versions.

Where there is a lack of consistency, (for example, some groups of systems have just VirusScan

Enterprise installed, whereas others have VirusScan Enterprise, Host IPS and Site Advisor Enterprise

installed), it is important to determine why this is the case. The intention of the migration should be

to bring all systems to a unified level of protection. Inconsistency may have occurred accidentally,

but where a decision has been made to selectively deploy technology, this decision should be

understood and noted. For example, it may be some systems may previously have been adversely

affected by a legacy product. If so, during the Design Phase, testing of this type of system with the

corresponding Endpoint Security 10.1 module should be included within the test plan, to determine

if the issue persists, so that production rollout plans may be adjusted accordingly.

Assess compatibility of endpoints To ensure minimal user impact and most effective operation of Endpoint Security 10.1, it is

important that system requirements should be met. These are summarized below for reference, but

the KB article mentioned below should be checked for full current requirements information.

Hardware The recommended hardware requirements at time of write are shown below.

CPU 1 – 2 GHz depending on operating system, see KB below for full details

Memory 1 – 3 GB depending on operating system, see KB below for full details

Disk space 1 GB

ePolicy Orchestrator can be used to determine which endpoints meet these criteria. A custom query

could be created for example using a table or Boolean pie chart using filters of ‘CPU Speed (MHz)’,


‘Total Physical Memory’ and ‘Free Disk Space’ greater than the required values to determine which

systems have the recommended values.

Figure 5. Query filter criteria.

It is suggested that in order to identify these system at a later date an appropriate tag is applied. This

tag could be applied manually directly from the results of running the query, or these same criteria

could be used as tag criteria within the Tag Catalog. Any subsequent action performed on these

endpoints could be controlled by ensuring that tasks are configured to be tag-dependent.

Figure 6. Tag-dependent task configuration.

Operating System The supported operating systems at time of writing are shown below.

Client operating systems:

Windows 10, Windows 8.1, Windows 8, Windows 7, and Windows Vista.

Note that Endpoint Security 10.1 is not supported on Windows XP!

Server operating systems:

Windows Server 2012 R2, Windows Server 2012 , Windows Small Business Server 2011 &

2008, Windows 2008 Server R2 and Windows 2008 Server, Windows Storage Server 2008

and 2008 R2.

Embedded operating systems:

Windows Embedded for Point of Service, Windows Embedded 8, Windows Embedded

Standard 2009, and Windows Point of Service 1.1.

Again ePolicy Orchestrator can be used to determine which endpoints meet these criteria.


Figure 7. Query showing operating system version.

Resources Current system requirements information is maintained here,

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

Assess support for managing Endpoint Security 10.1 This section involves assessing the software environment, to understand what changes may be

necessary from a software perspective to manage Endpoint Security 10.1; it also considers whether

the existing production environment is suitable to be used for management of endpoints running

Endpoint Security 10.1 once migration is complete. The alternative to using the production

environment is to build a new management infrastructure, which would necessarily incur significant

additional time and effort.

Management software The purpose of this step is to understand which endpoints will comply with the minimum McAfee

Agent version required to support Endpoint Security 10.1, and check for ePolicy Orchestrator server

version compatibility. At time of writing the following versions were compatible:

McAfee Agent versions 5.0.2 or higher is required to be installed on an endpoint in order to

manage Endpoint Security 10.1. Note that in some specific circumstances McAfee Agent

version 5.0.x may cause issues - see the resources section below for details.

ePolicy Orchestrator server version 5.1.x or higher is required to be installed on the

management server in order to manage Endpoint Security 10.1. For new installations the

latest version should be deployed - this is either ePolicy Orchestrator 5.1.3 or ePolicy


Orchestrator 5.3.1. Both 5.1.x and 5.3.x are offer long term support – the 5.1.x path focusses

on stability, whereas the 5.3.x path focusses on enhancements to functionality.

For many environments, the most significant change required prior to implementing Endpoint

Security 10.1, will be to move from McAfee Agent 4.8 to a version supported by Endpoint Security

10.1.

Management scalability The existing environment should be assessed to determine if it is suitable, or could be made suitable

to manage endpoints once migration has completed. If the environment has spare capacity then this

may be a simple tick-box exercise. However, if the existing environment is struggling to manage the

existing environment, and the expectation within the new environment is that additional security

measures will be implemented, (such as the use of firewall and / or web control), which will increase

the load on the environment, then it may be that a new environment will be required.

Resources McAfee Agent compatibility information for Endpoint Security 10.1 is available here:


Blue screen error on startup on NUMA-based systems after installing VirusScan Enterprise 8.8 Patch

6 or McAfee Agent 5.0.x, here: https://kc.mcafee.com/corporate/index?page=content&id=KB85806

Gain familiarity with Endpoint Security 10.1 Before proceeding, it is recommended that basic familiarity is gained with Endpoint Security 10.1.

This should involving installing and configuring the product, to gain familiarity not only with the new

features, but also new user interface and policy pages within ePolicy Orchestrator. There are a

number of resources available, including the McAfee Endpoint Security Community, all given below.

Product to module mappings McAfee Endpoint Security delivers an integrated approach where functionality previously provided

by products are transformed into modules operating within a single framework. The diagram below

shows how these legacy products and policies map to Endpoint Security 10.1 module and policies.

Host IPS 8.0(Firewall only)

Threat Prevention

Firewall

Legacy product and policies

Endpoint Security module and policies

VirusScan Enterprise 8.8

Common

Site Advisor Enterprise 3.5

Web Control

Figure 8. Current product and policy to Endpoint Security module and policy mappings.


VirusScan Enterprise 8.8 policy mapping

Figure 9. VirusScan Enterprise 8.8 policy mapping.

Host IPS 8.0 Firewall policy mapping

Figure 10. Host IPS 8.0 Firewall policy mapping.


Site Advisor Enterprise 3.5 policy mapping

Figure 11. Site Advisor Enterprise 3.5 policy mapping.

Installation with legacy products installed During a migration, most endpoints will have at least some legacy products installed. The table

below describes what happens when Endpoint Security 10.1 is installed in this situation.

Table 1. Installation with legacy products installed.

Legacy product Endpoint Security module

Action

VirusScan Enterprise

Threat Prevention VirusScan Enterprise will always be removed. The Threat Prevention module will be installed if this is selected as part of the deployment task.

Host Intrusion Prevention – Firewall Module

Firewall The Endpoint Security Firewall is installed but if the Host IPS Firewall is enabled, the Endpoint Security Firewall will be inactive. The Host IPS Firewall component remains enabled. Once the Host Intrusion Prevention Firewall module is disabled, (e.g. via policy change), the Endpoint Security Firewall will become active.

Host Intrusion Prevention – IPS Module

Threat Prevention The Endpoint Security Threat Prevention is installed but if the Host Intrusion Prevention IPS module is enabled, the Threat Prevention Exploit Prevention functionality will be inactive. Once the Host Intrusion Prevention IPS module is disabled, (e.g. via policy change), the Threat Prevention Exploit Prevention functionality will become active. This is analogous to the Buffer Overflow module in VirusScan Enterprise becoming inactive when the Host Intrusion Prevention IPS module is enabled, and for the same reason – they provide the same type of protection.

Site Advisor Enterprise

Web Control Site Advisor Enterprise will always be removed. The Web Control module will be installed if this is selected as part of the deployment task.


Notes.

The Endpoint Security Platform module, (sometimes referred to as the Common module), will

always be installed, regardless of which of the other modules are installed.

Since Endpoint Security 10.1 is modular, it would be possible to select to install just the web control

module. Note that if VirusScan Enterprise is installed, despite the Threat Prevention module not

being installed, VirusScan Enterprise will still be removed.

Host IPS will not be removed, since this product also provides IPS functionality which can run

alongside Endpoint Security 10.1, (and will not be changed as a result of installing Endpoint Security

10.1 on the endpoint). Any time that the Host IPS Firewall is disabled, the Endpoint Security 10.1

Firewall module is enabled.

Resources The McAfee Endpoint Security Community on the Intel Security Expert Center site should be the first

place to check for the latest information about Endpoint Security 10.1 and other Intel Security

products, here: https://community.mcafee.com/community/business/expertcenter/products/ens.

A video, ‘Introduction to McAfee Endpoint Security 10.1’ can be found here:

https://www.youtube.com/watch?v=3nm0BIkrZSc.

The Endpoint Security 10.1 Release Notes can be found here:

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

The Endpoint Security 10.1 Installation Guide can be found here:

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

The Endpoint Security 10.1 Product Guide can be found here:

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

The whitepaper ‘Understanding the McAfee Endpoint Security 10.1 Threat Prevention Module’ is

available here: http://www.mcafee.com/us/resources/white-papers/wp-understanding-ep-security-

10-module.pdf.

Understanding McAfee Next Generation Performance Technology here:

https://community.mcafee.com/docs/DOC-8131.

‘How McAfee Endpoint Security 10.1’s Next Generation Technologies Protect and Perform’ can be

found here, http://www.mcafee.com/us/resources/misc/ms-endpoint-security-10-works.pdf


Assess policies, tasks and assignments methods By investigating ePolicy Orchestrator configuration it is possible to determine how many affected

policies and task are in use, and how these are assigned to endpoints. Policies may be assigned both

directly at a group level and via policy assignment rules. This information will help to establish how

much effort is required to migrate from the legacy configuration to configuration required to

support Endpoint Security 10.1. Queries run from within ePolicy Orchestrator can be used to provide

an overview of the policy assignments in place. For example a query could be created based on the

‘Policy Management Policy Assignment Broken Inheritance’ query type.

Figure 12. Query showing broken Inheritance.

A query showing the policy type, policy name, and number of policy assignments can also help

provide an overview of usage of different polices.

Identify current management personnel Identifying the processes in place within an organization can be more easily achieved by

understanding who manages what aspect of endpoint security, and ascertaining any other staff that

interact with ePolicy Orchestrator.

Identify any integration processes It is important to understand if any integrations with ePolicy Orchestrator exist. This may consist of

configuration entirely within ePolicy Orchestrator - internal integrations, or integration between

ePolicy Orchestrator and other systems - external integrations.


Internal integrations By examining ePolicy Orchestrator configuration, the existence of automation and reporting

components integrated with existing technology that would be impacted by the introduction of

Endpoint Security 10.1 can be identified.

There may be no integrations present, however since ePolicy Orchestrator provides very powerful

automation of both reporting and responses, these can be used to create significant workflows. This

can include dashboards and queries, server tasks, tags, tag-defined client tasks, automated and

manual workflows, automated rules and responses, directory sorting and other configuration

designed to react in some manner to endpoint characteristics or events.

If integrations are identified, understand the impact of switching from existing products to Endpoint

Security 10.1, determine any changes required in order for these integrations to continue to function

with Endpoint Security 10.1, (include the building of these integrations within both the test and

production environment), and include testing of these integrations within Piloting in the lab and

Piloting on production systems.

External integrations It is important to understand if there is integrations between ePolicy Orchestrator and any external

systems. This may consist of feeding information in to ePolicy Orchestrator - for example by using

the ePolicy Orchestrator Web API to allow an external system to trigger activity or assign

configuration within ePolicy Orchestrator. Equally it may involve extracting out information from

ePolicy Orchestrator, (such as by the use of a Security Information and Event Management (SIEM)

connector).

If external integrations are identified, the same action should be taken as for any internal

integrations identified.

Note that there may also be integration between the endpoint itself and external systems although

this is less likely. For example, there may be a process monitoring and collecting information from

the Event Log of an endpoint. This may require reconfiguration when VirusScan Enterprise is

replaced by Endpoint Security 10.1.

Check known issues for relevance Check the current list of known issues to determine if any of these issues are likely to impact on

either the deployment or operation of Endpoint Security 10.1 within your environment.

Resources Endpoint Security 10.1 known Issues:

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

Identify personnel involved in migration process In this step the contact details, roles and responsibilities of those people involved in the migration

should be confirmed. Confirm their availability for the anticipated duration of the project.

Identify suitable pilot users and endpoints When identifying groups of users that are suitable for testing consider including selection criteria

such as user location and proximity to test environment, willingness to embrace change, higher

tolerance to testing, those users using representative hardware and software, and those users that


currently experience issues designed to be solved by the new solution: improved protection and

performance.

Consider selecting smaller initial groups and then expanding on this until approximately 10% of the

overall endpoint population is included. One strategy that works is to pilot in groups of 10, then

expand this to 100 and then 1000. This allows general problems to be spotted early, limits the

impact on the overall user base, and once confidence has been built, allows rapid deployment to

larger groups.

When selecting systems, ensure that the pilot covers endpoints that are distributed across the

environment to cover the different kind of activities taking place within the organization

Document findings and decisions It is highly recommended to document the information collected up to this point, to record the

current position - the starting point, and to include the extent of change required. This information

can be referred to later and be used during the pilot and production migration.


Design Phase

Design a test plan Prior to performing any pilot, basic testing should occur on test endpoints within a lab environment,

to ensure all anticipated and common functionality operates as expected, and no obvious

incompatibilities are present.

Once this testing has completed the pilot can commence, where functionality is tested in a live

environment with real users. The objective here is to confirm that both anticipated and common

functionality operates as expected and that no incompatibilities are present within a production

environment.

Start and duration of test

Determine the start and total duration of the testing. The length of the time taken for testing will

determined by the number of endpoints tested and the amount of testing to be performed.

Availability of personnel during test

It is important to confirm availability of those personnel who will be responsible for performing

testing for the duration of the test process.

Availability of test endpoints

It is important to confirm availability of representative hardware and software. At this stage it is

likely testing will be run on non-production systems, so it is important to ensure the hardware

selected is representative of typical hardware found within the organization and in widespread use,

and that it has the same software build(s) as found within the production environment. Results

found through testing performed on non-standard hardware with custom builds is unlikely to reflect

behavior found on production systems.

Availability of other resources

It is important to confirm availability of any test hardware, software or other resources for the

duration of the process. For example, if a SIEM is required for integration testing, and will be used

during the test stage, will this be available when required?

Design test cases The main focus areas of testing should be: does Endpoint Security 10.1 functionality work as

advertised (functional testing), does it work successfully within our environment (soak testing), will

any integration with the legacy product be impacted when these products are replaced with

Endpoint Security 10.1 (integration testing), and how simple and successful is the migration from

existing products to Endpoint Security 10.1, (migration testing).

It is recommended to split testing into four types identified in the paragraph above. Initial testing of

the above cases is performed within a test environment, and once successful used to inform and

potentially modify the approach used within the pilot environment.

Functional, Integration and Migration testing should be performed on the typical endpoint types

present within an organization. The order of these test is unimportant, and they can run

concurrently.


Functional testing Functional testing within the lab environment, is designed to confirm that features used within the

legacy technology and new features that will be used, operate as expected. Endpoint Security 10.1

includes a number of existing, new and modified features. As part of the testing process these

features should be tested. This test assumes the software is installed on a fresh system that has no

previous software installed, and is designed to prove basic functionality operates as expected.

Integration testing The previous stage, ‘Identify any integration processes’ is designed to highlight where either ePolicy

Orchestrator or the existing legacy software were integrating into other Intel Security or third party

systems. Integration testing within the lab environment is designed to confirm that any internal or

external integrations continue to function with Endpoint Security 10.1.

The testing in this section will depend upon any specific integrations discovered during the

Assessment Phase. There may be none at all, or there may be a number of processes discovered,

that could potentially be impacted by a migration.

Where ePolicy Orchestrator is required to be upgraded, it should be confirmed that the new version

of ePolicy Orchestrator is capable of that same integration, and as above, how this can be achieved.

The integration, and its operation should form part of the integration test plan.

Where legacy software is directly involved with the integration, (as opposed to information from the

legacy software being collected from the management system and then used), it should be

confirmed that Endpoint Security 10.1 is capable of that same integration, and what if any changes

are required in order to achieve this integration. The integration, and its operation should form the

remainder of the integration test plan.

Product migration testing Product migration testing within the lab environment is designed to confirm the process of removing

legacy software and installing Endpoint Security 10.1 completes as expected. This testing involves

testing the process of removal of legacy software and replacement with Endpoint Security 10.1. If

different groups of systems have different mixes of software, then all combinations widely in use

should be tested. For example, desktops may run Anti-virus and use the Host IPS Firewall, whereas

laptops may additionally run Site Advisor Enterprise. Servers may have a mix of Anti-virus, and Host

IPS. In this situation, lab systems should be set up mimic the existing software deployment, and

migration testing carried out across these systems in parallel. It is expected that this process will be

performed through ePolicy Orchestrator using the same version that will be used during the pilot

process and production migration.

Another consideration here is the mix of other Intel Security or McAfee software present on

endpoints to be migrated. For example Application Control or Device Control may be being used

within the environment. Whilst Endpoint Security 10.1 does not currently replace either Application

Control or Device Control, migration and other testing should include endpoints built and protected

in a way to that commonly found within the organization. If every endpoint in production is running

Device Control, all testing should be done on endpoints that have Device Control installed.


Management migration testing Management migration testing is the process of switching the management of an endpoint from one

management system, (in this case the current production ePolicy Orchestrator server), to another, (a

new ePolicy Orchestrator server), and ensuring this process completes as expected.

The requirement to perform this step will depend upon whether during assessment, (specifically the

Management scalability step), the decision was made to build a new production management

infrastructure to support Endpoint Security 10.1. If the decision was made that the existing

environment would suitable for management of Endpoint Security 10.1 then this step is not

required.

If a new production management infrastructure is deemed necessary, whilst switching management

systems, (existing to new ePolicy Orchestrator server), and switching protection technologies,

(VirusScan Enterprise etc. to Endpoint Security 10.1), could occur concurrently, it is recommended

that these two steps are separated. There are two reasons for this recommendation.

Firstly if problems occur it is useful to minimize the number of simultaneous changes to help

isolate the actual change that caused the issue.

Secondly, during the production rollout, it is unlikely every system will be migrated

simultaneously and so it will be useful to have tested the situation where the new ePolicy

Orchestrator server is being used to manage legacy technology.

Migration between ePolicy Orchestrator servers can be performed in a variety of ways, from using

the built in Agent | Transfer Systems capability, (present within ePolicy Orchestrator 5.x), from the

ePolicy Orchestrator System Tree, to using the frminst.exe with switches on the endpoint - see the

resources section below for details.

Soak testing Soak testing involves testing a system with a typical production load, over a continuous availability

period to validate system behavior under production use. Whilst it is important to ensure Endpoint

Security 10.1 functions correctly, it is more important to ensure the endpoint continues to function

as expected, and the user experience is acceptable. This testing is designed to confirm these points.

Sample test cases Some examples of test cases for each of the above types of testing are now provided. These can be

used as the basis for testing, but should not be considered exhaustive. These should be amended to

represent the features, configuration and operations present within the organization planning

migration.


Sample functional test cases Table 2. Sample functional test cases.

Module Feature Test

Endpoint Security Platform Module

Updating Perform end to end update, (i.e. pull from Intel Security repository, through ePolicy Orchestrator and push to distributed repository with endpoint updating from this point). Confirm update occurs successfully.

Confirm successful signature rollback is possible after an update.

Confirm new signature version is reflected within ePolicy Orchestrator queries and dashboards.


GUI Password protection

Set Client Interface Mode to Standard access, configure the administrative password and confirm this is required in order to access settings through the local GUI.


Uninstall password protection

Set uninstallation to require a password, configure the password and confirm that a local uninstall requires the password to be entered to proceed.


Self-protection Enable Self-Protection for Processes and confirm the mcshield.exe process cannot be stopped when using administrative rights.

Threat Protection Module

On-access scanner detection

Confirm malware is detected for example using EICAR (see below).

Check GTI-based malware detection succeeds for example using GTI test files (see below).

Ensure samples are quarantined correctly when detected.

Confirm malware detection generates a local and ePolicy Orchestrator event.


On-access scanner impact

Ensure VirusScan Enterprise on-access scanning is enabled, perform an update and after completion install a major application such as Microsoft Office, and record the install time.

On an identical system ensure Endpoint Security 10.1 on-access scanning is enabled, perform an update and after completion install a major application such as Microsoft Office, and record the install time.


Module Feature Test


On-demand scanner detection

Confirm malware is detected for example using EICAR (see below).

Check GTI-based malware detection succeeds for example using GTI test files (see below).

Ensure samples are quarantined correctly when detected.

Confirm malware detection generates a local and ePolicy Orchestrator event.


On-demand scanner scheduling

Schedule an on-demand scan and confirm it starts, completes and repeats according to the configured schedule settings.


On-demand scanner scan duration

Perform an update and then run an on-demand scan using VirusScan Enterprise and note the scan duration.

On an identical system perform an update and then run an on-demand scan using Endpoint Security 10.1 and note the scan duration.


Zero impact scheduled scanning

Schedule a scan with ‘Scan only when the system is idle’ enabled, to start at a time when there is activity on the endpoint.

Confirm no scanning takes place by monitoring the CPU consumed by the mcshield.exe process within task manager.

Stop activity on endpoint and confirm scanning commences.

Start activity on endpoint and confirm scanning pauses.

Stop activity on endpoint and confirm scanning completes.


Access Protection Standard Rules

Test standard access protection rules enabled do not trigger during normal operation.

Test standard access protection rules enabled trigger when expected.

Test trigger of standard access protection rules generate a local and ePolicy Orchestrator event.


Access Protection Custom Rules

Test custom access protection rules enabled do not trigger during normal operation.

Test custom access protection rules enabled trigger when expected.

Test trigger of custom access protection rules generate a local and ePolicy Orchestrator event.

Firewall Module

Allowing access Confirm access to network based applications is allowed.

Confirm access to corporate Intranet is allowed.

Confirm access to Internet is allowed.

Confirm access does not generate a local event or an ePolicy Orchestrator event.

Firewall Module

Blocking access Confirm access to a denied IP address is blocked.

Confirm access to unspecified IP address is blocked, (default Block All Traffic rule).

Confirm blocking action generates a local log event.

Confirm blocking action does not generate an ePolicy Orchestrator event unless configured as intrusion.

Web Protection Module

Content actions Ensure Web Control is enabled and attempted access to a known good green site, (e.g. http://green.test.csm-testcenter.org), is allowed.

Ensure Web Control is enabled and attempted access to a potentially dangerous yellow site, (e.g. http://yellow.test.csm-testcenter.org), results in a caution message to the user, and the need to click Continue, before access is granted.

Ensure Web Control is enabled and attempted access to a malicious red site, (e.g. http://red.test.csm-testcenter.org). is blocked.

Confirm access to malicious and potentially dangerous sites generates a local and ePolicy Orchestrator event.

Confirm an attempt to download a malware test file, (e.g. EICAR), is blocked and results in a local and ePolicy Orchestrator detection event.

Web Protection Module

Impact Ensure Site Advisor Enterprise is enabled, access an Intranet site and record the page time to load.

On an identical system ensure ENS 10.1 web control is enabled, access an Intranet site and record the page time to load.


Sample integration test cases Table 3. Sample internal integration test case.

Integration Test

Automatic quarantine of Endpoints with on-access scanning disabled

Confirm queries, tasks and tagging associated with detection of endpoints running Endpoint Security 10.1 with on-access scanning disabled operates correctly.

Confirm policy assignment rules successfully apply a quarantine policy to tagged endpoints within ePolicy Orchestrator.

Confirm quarantine policy is successfully applied to relevant endpoints.

Table 4. Sample external integration test cases.

Integration Test

Reporting of events into a Security Information & Event Management (SIEM) system

Generate test detection events on endpoints running Endpoint Security 10.1.

Confirm test events are reported to ePolicy Orchestrator.

Confirm ePolicy Orchestrator events are collected and reported within the SIEM.

Import and deployment to Active Directory-based endpoints

Add a new endpoint in to Active Directory.

Run the Active Directory synchronization process within ePolicy Orchestrator.

Confirm deployment of Endpoint Security 10.1 on the new endpoint occurs as expected.


Sample product migration test cases Table 5. Sample product migration test cases.

Endpoint Role

Hardware Operating System

Existing Software Test

Sales Laptop

Lenovo Thinkpad T450s

Windows 8.1

VirusScan Enterprise 8.8 P6 Host IPS Firewall 8.0 P6 Site Advisor Enterprise 3.5 P4

Removal of legacy software, i.e. VirusScan Enterprise & Site Advisor Enterprise, is successful1.

Deployment of selected modules of Endpoint Security 10.1, i.e. Endpoint Security Platform, Threat Prevention, Firewall & Web Control is successful.

Update task completes and updates applied successfully.

Configuration from policy applied successfully.

Support Desktop

HP Compaq 8200 Elite

Windows 7 SP1

VirusScan Enterprise 8.8 P5

Removal of legacy software, i.e. VirusScan Enterprise, is successful.

Deployment of selected modules of Endpoint Security 10.1, i.e. Endpoint Security Platform & Threat Prevention is successful.



Support Laptop

HP ZBook 15u G2

Windows 8.1

VirusScan Enterprise 8.8 P6 Host IPS Firewall 8.0 P5

Removal of legacy software, i.e. VirusScan Enterprise, is successful1.

Deployment of selected modules of Endpoint Security 10.1, i.e. Endpoint Security Platform, Threat Prevention & Firewall is successful.



Manager laptop

Lenovo ThinkPad X1

Windows 10

VirusScan Enterprise 8.8 P6 Host IPS Firewall 8.0 P6 Site Advisor Enterprise 3.5 P4

Removal of legacy software, i.e. VirusScan Enterprise & Site Advisor Enterprise, is successful1.

Deployment of selected modules of Endpoint Security 10.1, i.e. Endpoint Security Platform, Threat Prevention, Firewall & Web Control is successful.



1 Host IPS will not be removed, since this product also provides IPS functionality which can run alongside Endpoint Security 10.1, (and will not be changed as

a result of installing Endpoint Security 10.1 on the endpoint).


Sample management migration test cases Table 6. Sample management migration test cases.

Action Test

Recreated system tree on pilot ePolicy Orchestrator server

Ensure the correct system tree structure has been created.

Export policies and tasks from existing production ePolicy Orchestrator server

Confirm policies and tasks export successfully.

Import policies and tasks to pilot ePolicy Orchestrator server

Confirm policies and tasks import successfully and without conflict.

Assign appropriate policies and tasks within the system tree

Confirm assignments applied correctly within system tree structure.

Migrate endpoints to pilot ePolicy Orchestrator

Confirm endpoints are located correctly within the system tree structure.

Confirm endpoints communicate successfully and receive correct configuration

Confirm endpoints communicate with pilot ePolicy Orchestrator server.

Confirm Status Monitor shows tasks deleted and added as expected.

Confirm last communication time updated accordingly within system properties.

Confirm correct policies applied and assigned tasks execute as expected.

Resources The following test files and sites are available and recommended for performing malware testing:

The EICAR test malware: http://www.eicar.org/download/eicar.com.

GTI Test files: https://kc.mcafee.com/agent/index?page=content&id=KB53733.

Site Advisor & Web Control test pages: https://kc.mcafee.com/corporate/index?page=content&id=KB72563.

The following information may be useful during migration to a different ePolicy Orchestrator server:

How to transfer/move computers from one ePolicy Orchestrator server to another:


How to redirect the communication of McAfee Agent 4.x to a new ePolicy Orchestrator server:



Design pilot plan Once testing within a test environment has completed, groups of pilot endpoints within the

production environment can be used to allow testing over a great range of endpoints.

Testing of this nature is designed to confirm that the functional, integration and migration testing in

the lab environment is valid within the mix of endpoints found within the product environment. In

addition, it is used to confirm that an endpoint continues to perform as expected, that there are no

conflicts with existing software or hardware, and the same behavior and responses exists as prior to

the migration. Therefore it is essential that this testing is carried out across a wide variety of

endpoint types and roles to ensure that all applications and systems perform as expected.

The pilot can also be used to determine the speed at which multiple endpoints can be migrated

concurrently. This information can then later be used to feed in to the production rollout plan, and

can be useful is estimating the duration of the production rollout.

Pilot plan considerations Factors to be considered within pilot plan are discussed below.

Environment in which to run pilot

After completing testing within a lab environment and test ePolicy Orchestrator server, the choice

can be made to either continue testing production systems on the test ePolicy Orchestrator server,

or to use the production ePolicy Orchestrator server. Each approach has benefits and drawbacks.

Table 7. Pilot ePolicy Orchestrator server selection considerations.

Pilot on test ePolicy Orchestrator server Pilot on production ePolicy Orchestrator server

Benefits No changes are required to be made on the production ePolicy Orchestrator server.

A great degree of control and separation is possible, since endpoint can be switched between environments to indicate which protection technology they should be running, and reporting on endpoints present on the test ePolicy Orchestrator server is a good indication of exactly how far the pilot has progressed.

Very little effort is required to commence the pilot. Pilot endpoints within the production environment simply need to be assigned the correct Endpoint Security 10.1 policies and tasks prior to upgrading VirusScan Enterprise etc. to Endpoint Security 10.1.

Drawbacks Additional effort is required to configure the test ePolicy Orchestrator server. Prior to migrating endpoints management to the test ePolicy Orchestrator server, VirusScan Enterprise and other products policies and tasks assigned to the pilot endpoints should be migrated, (which in turn will require the System tree structure to be replicated at least partially), to ensure the correct policies are present on the test ePolicy Orchestrator server.

Changes will be required to be made on the production ePolicy Orchestrator server before piloting can commence, (e.g. the addition of the Endpoint Security 10.1 package and policies)

Testing will be performed on the production ePolicy Orchestrator server as opposed to a test server.

There is a great scope for errors that impact the entire environment, (e.g. accidentally deploying Endpoint Security 10.1 to every managed endpoint as opposed to just selected pilot systems).

Start and duration of pilot

Determine the start and total duration of the pilot. The length of the pilot will be determined by the

speed of deployment and the extent of testing performed on pilot endpoints.


Speed of deployment

Consider how quickly deployment, (migration), will be performed, and whether deployment occurs

at all endpoints concurrently, or whether a staged deployment is used. For example, an organization

may choose to deploy to 1000 endpoints in total for the pilot process, but this may be carried out in

different ways with examples shown below.

Table 8. Increasing-size group deployment.

Time period

1 2 3 4 5 6

Number of endpoints deployed

10 50 100 250 500 Remainder

Table 9. Equal-size group deployment.

Time period

1 2 3 4


250 250 250 250

Table 10. Single group deployment.

Time period

1


1000

Tests performed on pilot endpoints

How much active testing is to be performed on pilot endpoints, (functional testing) and how long

this takes will impact duration. One approach is to perform comprehensive testing initially and

reduce this as more confidence is gained if no problems are encountered, as below. Alternatively, an

equal amount of functional testing may be carried out across all groups.

First group deployed

Second group deployed

Time

Third group deployed

En

dp

oin

ts

Perform functional testing


Perform functional

testing

Figure 13. Decreasing functional testing times.

How long endpoints should remain within the pilot process in soak testing, (used to verify an

endpoint's stability and performance over an extended period of time) should be decided.


First group deployed

Second group deployed

Time

Third group deployed

En

dp

oin

ts



Perform functional

testingPerform soak testing

Perform soak testing

Perform soak testing

Figure 14. Soak test duration.

It is suggested that slippage time is incorporated into the pilot plan.

Availability of personnel during test

It is important to confirm availability of those personnel who will be responsible for performing

testing for the duration of the pilot process.

Availability of pilot users and endpoints

It is important to confirm availability of those users and endpoints selected to be part of the pilot

process for the duration of the process. Users may have planned projects or vacation which may

impact on their availability, so their availability should not be assumed.

Availability of resources

It is important to confirm availability of any test hardware, software or other resources for the

duration of the process. For example, if a SIEM is required for integration testing, and will be used

during the pilot, will this be available when required?

Soak testing Soak testing is an important part of the pilot process. Whilst this testing should be carried out across

a variety of systems, it is not particularly arduous, since it mainly consists of informing users that

new software is to be deployed, deploying the actual software and monitoring the pilot group to

ensure no problems are observed. However, the time required to undertake this process should be

factored in to the pilot plan. The time period chosen should span typical user activities - e.g. if some

activities take place every week, whereas others take place at the end of each month, soak testing

should include both situations.

Design test & pilot environment It is important to complete this stage once the test cases have been determined, because

requirements for the test and pilot environment may be generated as a result of the test cases

developed. For example, if any external integration testing is required, access to the same or very

similar external systems should be available within the test and / or pilot environment.

The test environment should approximately resemble the production environment if possible, to

allow the most complete test results to be obtained. However, whilst the production environment

may consist of a high specification ePO Server(s), a separate SQL Server, one or more discrete Agent


Handlers, Distributed Repositories, etc., in practice most test environments may simply consist of an

ePO Server running SQL Express.

Also consider that whilst this environment will be used for testing on a small number of endpoints

within the lab, it may be used during the pilot, to manage a much larger number of endpoints within

the production environment, depending on the decision taken during the Pilot plan considerations

step. Ensure the initial hardware selected is suitable for the size of the pilot environment and ensure

that any build standards required in order for the pilot environment to access endpoints within the

production environment are met, if the option to run the pilot on the test ePolicy Orchestrator

server is selected.

Migration between management systems

It is anticipated that all testing within the test environment will use the test environment ePolicy

Orchestrator server exclusively, since test systems are unlikely to be managed by the production

ePolicy Orchestrator server.

However within the Piloting on production systems stage, production systems will be selected and

used for testing, and these production systems will be initially be being managed by the existing

production ePolicy Orchestrator server. Therefore one additional aspect of testing during pilot may

be required - the migration from the existing production ePolicy Orchestrator server to pilot ePolicy

Orchestrator server. Alternatively, the piloting may be carried on the production ePolicy

Orchestrator server, in which case the endpoint management system would not change, but

additional preparation would be required on the production ePolicy Orchestrator server.

The chart below outlines the different states that the pilot endpoint will move through.

Existing endpoints managed by prod.

ePO server

Assign existing product config. to

test ePO Server

Migrate endpoints to

test ePO Server

Add ENS 10.1 package and extn’s to prod. ePO Server

Migrate VirusScan etc. to ENS 10.1 on

endpoints

Migrate legacy policy to ENS

10.1 policy

No

Use prod.ePO Server for

pilot?Yes

Figure 15. Management and endpoint protection states.

If using the test ePolicy Orchestrator server for piloting any existing policy and task assignments

already present on the existing ePolicy Orchestrator server must be replicated to the test ePolicy

Orchestrator server. If this is not done, when the endpoint is migrated to the test ePolicy

Orchestrator server it will assume default policies which may not be compatible with the endpoint.

At this early stage of piloting any negative feedback from the user will disproportionally impact the

overall perception of the migration and the effectiveness of the new technology, even though the

new technology will not even have been deployed!

Test cases are provided within the Design test cases section of this document.


Design user information plan Users within most environments will have minimal interaction with the security products deployed

on their endpoints, with any actions or responses selected by the administrator.

However, during the migration process the user may see unusual activity as a result of removing

legacy software and installing the replacement applications. It is recommended that users are

informed of these changes, so they do not come as a surprise. It is also suggested that a system is

rebooted after installing Endpoint Security 10.1, and so the information plan can include this

suggestion.

In addition, users may notice a change in icons, start menu items, or consoles for the same reason,

and if the installation of Endpoint Security 10.1 also results in the addition of more functionality,

(such as adding the Firewall or Web Control module) where the legacy products were not previously

present, they may see changes in other areas, such as their web browser. To ensure that none of

these changes cause the user concern, (and in order to prevent a call to the help desk), the user

should be made aware that changes will be happening, when these are expected to happen, why

they are being made, and what impact they are expected to have.

Providing this information ahead of time, with the correct contact details of whom users should

contact can speed up the identification and resolution of any migration issues. The user information

plan should highlight how and when users are informed of any processes that will directly or

indirectly impact on their work environment.

Note that this plan may require updating after piloting has complete, and based on any findings

during the pilot phase. The step Document endpoint transition in the Test & Pilot Phase is used to

record the expected behavior during transition from current technology to Endpoint Security 10.1,

and can be used to update the user information plan if necessary.

Design production management architecture The production management architecture, (e.g. ePolicy Orchestrator server, SQL Server, Agent

Handlers, Repositories, and Super Agents), required to manage Endpoint Security 10.1 will be one of

the following:

The same set of systems that are used to manage the current environment

Based on the current environment but requiring some updating, (e.g. deployment of the latest

McAfee Agent)

An entirely new environment using the migration as an opportunity to update hardware for

example.

Regardless of the choice, if any new hardware or systems are required, or if new or updated

software must be installed, then this should be included within the production rollout plan. If new

items or significant changes are required, it’s important to consider lead time required to obtain the

new systems or software, and sufficient time to adhere to the organization’s change control

processes.

If an entirely new environment is selected to be used, the final part of this step is to document the

design, including the reasons behind the design decisions made. This will be useful in guiding the

operations team on how the design and environment can best be used to deliver security efficient

and effectively. It will also act a check on the logic of design decisions – if a design choice cannot be

explained and justified, is it the right choice?


Design production rollout plan Following successful piloting, the new software must be rolled out across the remainder of the

production environment. The production rollout plan is designed to highlight when and how the

software will be rolled out across all remaining endpoints, (desktops, laptops and servers).

It should include time scales for the creation of any infrastructure and the installation or upgrade of

any software required to support the rollout, and the actual rollout process, which users, groups or

departments are targeted and in which order, the personnel responsible for this activity, milestones,

who and how any issues reported are handled, and any back-out plans.

At this stage it is unlikely that all information will be available to complete the production rollout

plan, so this step can be started but not completed. Feedback from the Test & Pilot Phase should be

incorporated into the production rollout plan. Factors such as the best approach to migration and

how quickly migration can occur will feed in to the production rollout plan.

Design handover plan for operations The handover plan used to assist in the transition from the team responsible for the migration to the

team responsible for day to day running of the environment, should include training of the

operations personnel on product policy and reporting, any changes to the troubleshooting process,

defining how much of migration will be performed by the piloting or migration team compared to

the operations team, when the handover is to take place and whether the handover will be all in

one, or done on a group by group basis as the migration occurs.


Build Phase

Build test environment The environment planned within the Design test & pilot environment step should be built in this

step. This environment may be used to perform both testing on both test endpoints in lab

conditions, (i.e. with no real users or data involved), and later to test production systems, (where

real users and data will be present), during the Piloting on production systems step.

Replicate policy and task assignments If the option to pilot on the test ePolicy Orchestrator server was selected, this step will be required.

The purpose of this stage is to ensure that when an endpoint is migrated to the pilot ePolicy

Orchestrator server it will assume identical policies to those assigned to the endpoint under the

existing production ePolicy Orchestrator server. Note that not all policies and tasks need to be

migrated – only those assigned to the endpoints selected in the step Identify suitable pilot users and

endpoints.

If the option to pilot on the production ePolicy Orchestrator server was selected, this step will not be

required

Replicate integrations The purpose of this stage is to implement any integrations discovered within the current

environment, within an Endpoint Security 10.1 test environment. This should include configuration

of both internal and external integrations. These integrations will then be tested both in the lab on

test systems, and during the pilot on production systems, according to the Design test cases created

in the Design Phase.

Policy and task pre-migration review There are a number of factors that drive complexity within an environment: the need to cater for a

diverse population of users and their work environments, a multitude of different applications and

application versions, a number of different roles of desktops, laptops and servers, the adoption of

new Intel Security software and new versions of existing technology from Intel Security, the need to

cater for temporary requirements, etc. All of these reasons and more can drive the creation of more

policies and tasks within the ePO console.

However, during a migration, the more policies and tasks present, the greater the effort required to

migrate this configuration to the equivalent configuration for Endpoint Security 10.1. Prior to

migration is a great opportunity to review what policies and tasks exist and how or even if these

policies and tasks are used. If not assigned then are they required?

Note that some policies and tasks may only be used where specific conditions are met, (such as

during a lockdown period or when a new system is introduce to the environment), so unused

policies or tasks cannot automatically be removed, but they should be investigated to see if they are

in fact required. Unassigned policies and tasks that are required to be migrated will need to be

noted, since the Endpoint Migration Assistant, (mentioned below), will not migrate these objects

when running in Automatic mode. One approach here is to identify these unassigned objects,

(policies and tasks), that are required, create a temporary group, and assign these objects to the

temporary group(s).

Where a large number of different policies or tasks are used across similar systems, consider

whether these can be amalgamated into fewer or preferably a single policy or task. The ePO Policy


Comparison feature can be used to identify differences in policy, which can be useful in helping

identify policies best merged, and hence allow the overall number of policies to be reduced.

The need for specific exclusions are a great source of policy variations and hence can result in many

policies being created. Consolidation of exclusion policies is one way to solve this problem, but

another is to determine if the exclusions are still required. Exclusions may have been present for 5,

10 or more years, when anti-virus technology was highly intrusive and so absolutely required. Today

technology is generally less intrusive, and so it is possible that these exclusions are no longer

required. If so, this can greatly reduce the need for variations in policy.

One further consideration here is that the new trust model used in the Anti-Malware Core (AMCore)

could make many exclusion unnecessary and in some cases actually hinder performance. The

suggested practice here is to not simply migrate on-access scanner and on-demand scanner

exclusions but to investigate if these are still required. Where performance issues are encountered,

one troubleshooting approach that should be considered is to removal all exclusions to determine if

this improves the situation. Note that this recommendation does not apply to Access Protection

exclusions, which should be retained.

Once policies have been rationalized the process of switching from current to Endpoint Security 10.1

policies can begin.

Policy and task migration It is recommend that the Endpoint Migration Assistant is used for policy and task migration, because

it greatly simplifies the policy migration process. This is accessed by installing the Endpoint Migration

Assistant extension in to ePolicy Orchestrator.

The Endpoint Migration Assistant

Overview The Endpoint Migration Assistant migrates policy settings between current technology policies and

tasks and Endpoint Security policies and tasks.

It has two modes of operation:

Automatic migration which migrates all assigned existing policies, assigned client tasks, policy

assignments and the Host IPS Catalog. If a previous migration has been run using this tool, it

removes previously migrated objects (policies and tasks). Note that any unassigned objects will

need to be migrated separately.

Manual migration requires the administrator to select objects to migrate and customize the

objects during the migration process, if needed.

Requirements The Endpoint Migration Assistant requires ePolicy Orchestrator version 5.1.1 or higher. The

extension requires that the Endpoint Security 10.1 extensions are checked in to ePolicy Orchestrator.

Internet Explorer 10 or higher, Firefox or Chrome should be used.

Legacy products The Endpoint Migration Assistant supports migration of policies and tasks assigned to any of the

products and patch levels listed below.


Table 11. Products and patch versions supported for policy migration.

Product and patch level RTW Patch 1 Patch 2 Patch 3 Patch 4 Patch 5 Patch 6

VirusScan Enterprise 8.8

Host IPS 8.0 (both IPS + FW modules enabled)

Host IPS 8.0 (FW only enabled)

Site Advisor Enterprise 3.5 N/A N/A

Resources A video, ‘Introduction to McAfee Endpoint Security 10.1 Migration Assistant’, can be found here,

https://www.youtube.com/watch?v=NZj8A39YpDM and https://community.mcafee.com/docs/DOC-

8073.

A video, ‘Migrating from McAfee VirusScan Enterprise 8.8 to McAfee Endpoint Security 10.1’ can be

found here, https://youtu.be/Z1xaq379Z1g.

A video, ‘Migrating McAfee Host IPS 8.0 to McAfee Endpoint Security 10.1’ can be found here,

https://www.youtube.com/watch?v=9OqAsQVQP5E.

The Endpoint Migration Assistant Guide can be found here,

https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/26000/

PD26235/en_US/ens_1010_mg_0-00_en-us.pdf.

Consolidating policies and tasks from multiple ePO servers The Endpoint Migration Assistant will migrate policies within a single ePolicy Orchestrator server.

However, it’s possible that as part of the migration to McAfee Endpoint Security 10.1, an

environment is being consolidated from multiple to fewer or to a single ePO server. In this situation,

to migrate policies from multiple ePolicy Orchestrator servers’ two approaches can be used to

achieve the same outcome.

The first option is to determine which of the ePolicy Orchestrator servers will remain after

consolidation, (or if more than one are to remain, which server contains more policies requiring to

be migrated) – referred to here as the master ePolicy Orchestrator server. At each of the other

donor ePolicy Orchestrator servers, export the policies (and / or tasks) to be migrated, and import

these in to the master ePolicy Orchestrator server. Once completed, policies can be migrated as

above.

The second approach is to use the policy and task sharing capabilities of ePolicy Orchestrator.

Configure the donor ePolicy Orchestrator servers to share their policy and task objects to the master

ePolicy Orchestrator server, and migrate these tasks at the master ePolicy Orchestrator server, as

above.

Note that when either sharing or exporting, (and re-importing), policies, it is strongly recommended

that the servers involved are running the same major version and patch level of ePolicy Orchestrator

software, and that all ePolicy Orchestrator servers have the same extension versions checked in.


Migration progress reporting It is recommended that a process is created for tracking the progress of migration. This is not only

useful to answer the question ‘Where are we with the overall migration?’, but can be targeting at

specific groups of endpoints to determine if the anticipated upgrades have successfully completed.

Create a query for tracking the migration process.

Queries can be created within ePO to report on overall progress of migration – for example a query

could be created based on the ‘Others | Systems Per Product’ query type. This would show the

count of all products deployed, and should change to reflect the number of nodes running both the

current and new Endpoint Security 10.1 software.

Figure 16. Migration tracking query.

Create a process to track and respond to systems with possible migration issues.

During any migration there will be systems in one of three potential states – those that have the

current software and have not yet been subject to migration, those that have been successfully

migrated, and those that have been selected for migration where that migration has not yet

completed. It is very useful to track this third class of system, to ensure that migrations occur

successfully. ePolicy Orchestrator tagging and reporting can be used very effectively to provide this

information.

The queries ‘Product Deployment in the Last 24 Hours’ and ‘Failed Product Deployment in the Last

24 Hours’ can also be used to identify the number of success and failures, and highlight where these

have happened.


Figure 17. Query showing failed deployments.

Figure 18. Query showing successful deployments.

Consider using tagging for targeting endpoints

Tagging can be used to identify systems where migration should have occurred, and can help focus

effort on the correct subset of systems. For example, running an ‘Others | Systems Per Product’

report and limiting the scope to systems that should have migrated can highlight problems.


Test & Pilot Phase

Train administrators and helpdesk Training should focus on the differences between the existing and new software features, the

redesigned policy configuration pages, new dashboards and queries available, and any known issues.

In addition, the migration time and any reboots to be expected should also be shared with

administrators and helpdesk staff.

Piloting in the lab It is expected that functional, migration and integration testing will occur in the lab environment, to

confirm that basic functionality and software upgrades operates as expected. The test plan

developed in the Design Phase should be implemented here.

Piloting on production systems It is recommend that small groups of endpoints are initially targeted, and based on feedback

received this process can be adapted as required, as per the Design pilot plan, which should be

implemented here.

Changes may involve any of the following areas:

Changes in the preparation of systems or ensuring other endpoint pre-requisites are met

prior to migration

Changes to the process of migration to work around any issues encountered

Pre-migration or post-migration configuration (policy) changes

Increasing or decreasing the number or rate of endpoints being migrated.

In addition to refining the migration process, this step should help determine the maximum rate of

migration of production endpoints, and help enhance any processes required should issues be

encountered.

Determine migration rate Piloting within the production environment should be used to provide a good indication as the

maximum rate of migration.

Review and / or refine production rollout plan The Piloting on production systems phase will provide valuable feedback to confirm the validity and

viability of the rollout plan or otherwise provide information that allows the production rollout plan

to be enhanced. Prior to moving to the next stage it is advisable to gather feedback from those

involved in the Piloting in the lab and Piloting on production systems phase to learn what worked

well, what changes had to be made and how any other lessons learned could be incorporated into

the production rollout plan.

Document endpoint transition Once testing is complete the process of migrating an individual endpoint should be clear. This will

involve determining any product updates or changes to configuration required prior to migration

taking place, the expected migration duration (removal of existing software, installation of Endpoint

Security 10.1, any updating and reboots required), the user experience during migration, (usability

and response) , and information on expected reboots.

The overall goal should be to create a process that is fast, efficient and minimizes disruption to end

users. It should instruct users on expected behavior, and provide a process for users of endpoints


experiencing issues to contact support. This information can be used to understand when and how

users should be contacted, and how the migration for an individual endpoint occurs.

The information collected here can be used to update the Design user information plan created in

the Design Phase if necessary.

Prepare users Ensure that you deliver the user information plan to users ahead of making any changes that will

impact them. This will accomplish two main goals – ensure that users are aware that changes will be

being made, so that these changes will not alarm users, and provide users contact details should

problems arise.


Implement Phase

Update production rollout plan The production rollout plan is likely to have been started in the Design Phase, but not completed.

The experiences and insights gained within the Test & Pilot Phase should be used to make changes

to the production rollout plan when necessary.

For example, if the anticipated speed of rollout is 100 systems per day, but the pilot successfully

rolled out 250 per day, then the schedule can be adjusted. Alternatively if issues were discovered

with a particular driver, then the production rollout plan should ensure that the affected systems are

identified and the issue resolved or the driver replaced prior to migrating specific endpoints.

Create production management environment The Test & Pilot Phase will have used management hardware and infrastructure sized to manage the

number of endpoints present within the pilot environment, and configured for testing of

integrations selected during the design of test cases.

It is likely that the management hardware and infrastructure used within piloting is not suitable for

the entire production environment, and so a production environment most be developed.

This step is therefore to create or adjust the existing production hardware in order for it to be

suitable to manage the new environment. As stated previously, one approach here is to reuse the

existing production environment, another is to create a new environment.

Build new ePO infrastructure

Migrate configuration to new ePO Server

Migrate endpoints to

new ePO Server

Add ENS policies and packages to

ePO Server

Migrate legacy products to ENS

on endpointsYes

Migrate legacy policy to ENS policy

on ePO Server

Use prod.ePO Server for

production?

No

Figure 19. Creation of the production environment.

Use existing hardware and infrastructure The massive benefit of selecting to use and modify the existing environment, is that not only does it

exist, but all of the configuration, (with the exception of that connected with Endpoint Security

10.1), is already in place.

If existing hardware and infrastructure is to be used, (which is the recommendation), the Endpoint

10.1 package and extensions must be checked in. This will enable repository pull and replication

tasks to download the version 3, (or V3) dats used by Endpoint Security 10.1. These are referred to

within the ePO repository and pull task as AMCore Content Package XXXX.X. If selective pull and

replication is used within the production infrastructure, ensure this new content is selected to be

included within these tasks.

Build new hardware and infrastructure If new hardware and infrastructure is to be used, the existing environment must be replicated to this

new hardware. This includes everything from the system tree, policies, client and server tasks,


responses, dashboards and queries, internal and external integrations, registered servers, etc. This is

a major undertaking within a large or complex environment. Depending on the existing

environment, the easiest way to achieve this may be to perform a backup of the existing ePolicy

Orchestrator server and restore to the new infrastructure. Once the new infrastructure is configured

to be able to support the current production environment, the Endpoint 10.1 package and

extensions must be checked, and new content must be replicated within the environment as

mentioned above.

Resources

Recommended procedure for migrating or moving an ePO database to a new SQL server:


ePolicy Orchestrator server backup and disaster recovery procedure:

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

How to upgrade and migrate ePO 4.x to ePO 5.x and from a 32-bit to a 64-bit operating system:


Commence deployment Once the environment is fully prepared for Endpoint Security 10.1, the process of migration has

been tried and tested, administrators have been trained accordingly, and users have been notified,

migration of the production environment can commence.

Migration should follow the production rollout plan developed earlier.

Monitor success of deployment The production rollout can be measured using a similar approach to that used within the Test & Pilot

Phase, and as described within the step located in the Build Phase.

Monitor impact and issues During the deployment of Endpoint Security 10.1, the impact of the migration should be measured.

This can be measured reactively – for example, by monitoring the number of helpdesk calls, or

proactively - for example, by reaching out to users to ask for feedback, or a mix of the two.

Hand over management to operations team Handover of management responsibilities requires that helpdesk and operations team are fully

trained on Endpoint Security 10.1, and processes have been modified accordingly to handle any calls

generated, (for example by adding a new helpdesk category for Endpoint Security 10.1 to the

helpdesk system being used).

The handover may occur once the full migration has completed, or may happen group by group, as

migration completes on a subset of the environment. This process should follow the plan developed

earlier in the Design Phase.


Post-migration optimization Once migration has completed, it is important to ensure that where necessary policies, tasks and

processes are optimized to take advantage of the new capabilities introduced with Endpoint Security

10.1. There are a number of ways in which this may be achieved, from obtaining information from

users, to examining new capabilities, with some examples given below.

Table 12. Optimization suggestions.

Suggested action or feature Potential optimization

Monitoring Help desk calls The type, frequency and resolutions of calls may make it possible to determine common issues that may be addressable through changes to configuration or approach.

User questionnaires These can be used to seek feedback from users on their observations around the impact of ENS 10.1 to determine what works and what may need attention.

Right-click scan configuration For the first time this is achievable through ePolicy Orchestrator, and allows a customizable rather than the default scan configuration to be made available to users.

On-demand ‘scan on idle’ This feature may work best if scans are rescheduled to begin at the start of the business day, and may in some cases allow a scan to occur when no scan was previously possible.

Protection and reporting changes For example, enhancements to Access Protection allow blocking of executables based on a hash, (in a similar way to that provided by Host IPS). New queries and more descriptive threat events include reporting on file hashes, Therefore a better response to detections and other events reported from an endpoint may be possible.

Conclusions McAfee Endpoint Security redefines the way in which Intel Security (formerly McAfee) implements

threat protection on both Windows and Mac OS X endpoints, delivering improvements in protection

and performance, whilst simplifying management through the use of unified policies.

Since no new versions of VirusScan Enterprise, Host Firewall or Site Advisor will be released,

Endpoint Security 10.1 and subsequent releases should be seen as the replacement and logical

upgrade step for these products. Whilst no end of life has been announced for VirusScan Enterprise,

Host Firewall or Site Advisor, organizations should be planning when a migration would best suit

their timescales. Part of this process is determining the time and effort required for the migration.

This document is designed to help with the planning of the processes and estimating of the

resources required to undertake the migration. Not every step mentioned will be necessary for

every organization - the steps here are largely suggestions rather than mandated, and are present to

ensure the step is considered, even if eventually discarded. Ultimately migration planning should be

influenced by the typical processes that occur when your specific organization undertakes a software

migration project.


Glossary The following acronyms may be used throughout this document

Acronym Full name

AH Agent Handler

AMCore Anti-Malware Core

AP Access Protection

ENS McAfee Endpoint Security

ePO ePolicy Orchestrator

FW Firewall

HIPS Host Intrusion Prevention System

IPS Intrusion Prevention System

OAS On-Access Scan or On-Access Scanning

ODS On-Demand Scan or On-Demand Scanning

SA Super-Agent

SAE Site Advisor Enterprise

TIE Threat Intelligence Exchange

TP Threat Prevention

VSE VirusScan Enterprise

WC Web Control

Documents

Endpoint Security 10.1 Migration Planning Document