Endpoint Security 10.1 Migration Planning Document

Transcription

1 Endpoint Security 10.1 Migration Planning Document Author Jason Brown Enterprise Technology Specialist Intel Security February 2016 Version 1.0

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 antimalware 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 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 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, Jason.Brown@Intel.com. Endpoint Security 10.1 Migration Planning Document Page 2

3 Contents Summary... 2 Contents... 3 Figures and Tables... 6 Background... 7 Objectives... 8 Migration process overview... 9 Assessment Phase Identify products and modules in scope Assess compatibility of endpoints Hardware Operating System Resources Assess support for managing Endpoint Security Management software Management scalability Resources Gain familiarity with Endpoint Security Product to module mappings VirusScan Enterprise 8.8 policy mapping Host IPS 8.0 Firewall policy mapping Site Advisor Enterprise 3.5 policy mapping Installation with legacy products installed Resources Assess policies, tasks and assignments methods Identify current management personnel Identify any integration processes Internal integrations External integrations Check known issues for relevance Resources Identify personnel involved in migration process Identify suitable pilot users and endpoints Document findings and decisions Endpoint Security 10.1 Migration Planning Document Page 3

4 Design Phase Design a test plan Design test cases Functional testing Integration testing Product migration testing Management migration testing Soak testing Sample test cases Sample functional test cases Sample integration test cases Sample product migration test cases Sample management migration test cases Resources Design pilot plan Pilot plan considerations Soak testing Design test & pilot environment Design user information plan Design production management architecture Design production rollout plan Design handover plan for operations Build Phase Build test environment Replicate policy and task assignments Replicate integrations Policy and task pre-migration review Policy and task migration The Endpoint Migration Assistant Overview Requirements Legacy products Resources Consolidating policies and tasks from multiple epo servers Migration progress reporting Test & Pilot Phase Endpoint Security 10.1 Migration Planning Document Page 4

5 Train administrators and helpdesk Piloting in the lab Piloting on production systems Determine migration rate Review and / or refine production rollout plan Document endpoint transition Prepare users Implement Phase Update production rollout plan Create production management environment Use existing hardware and infrastructure Build new hardware and infrastructure Commence deployment Monitor success of deployment Monitor impact and issues Hand over management to operations team Post-migration optimization Conclusions Glossary Endpoint Security 10.1 Migration Planning Document Page 5

6 Figures and Tables Figure 1. Endpoint Security 10.1 architecture Figure 2. Migration process overview Figure 3. Query showing systems per product Figure 4. Query showing specific VirusScan versions Figure 5. Query filter criteria Figure 6. Tag-dependent task configuration Figure 7. Query showing operating system version Figure 8. Current product and policy to Endpoint Security module and policy mappings Figure 9. VirusScan Enterprise 8.8 policy mapping Figure 10. Host IPS 8.0 Firewall policy mapping Figure 11. Site Advisor Enterprise 3.5 policy mapping Figure 12. Query showing broken Inheritance Figure 13. Decreasing functional testing times Figure 14. Soak test duration Figure 15. Management and endpoint protection states Figure 16. Migration tracking query Figure 17. Query showing failed deployments Figure 18. Query showing successful deployments Figure 19. Creation of the production environment Table 1. Installation with legacy products installed Table 2. Sample functional test cases Table 3. Sample internal integration test case Table 4. Sample external integration test cases Table 5. Sample product migration test cases Table 6. Sample management migration test cases Table 7. Pilot epolicy Orchestrator server selection considerations Table 8. Increasing-size group deployment Table 9. Equal-size group deployment Table 10. Single group deployment Table 11. Products and patch versions supported for policy migration Table 12. Optimization suggestions Endpoint Security 10.1 Migration Planning Document Page 6

7 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 3 rd 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 Since its release a number of changes and enhancements have been made to the Endpoint Security 10.1 Migration Planning Document Page 7

8 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, 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 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. Endpoint Security 10.1 Migration Planning Document Page 8

9 Migration process overview The five phase migration approach is described below. Assess Design Build Test and Pilot Implement 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. Endpoint Security 10.1 Migration Planning Document Page 9

10 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. Endpoint Security 10.1 Migration Planning Document Page 10

11 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), Endpoint Security 10.1 Migration Planning Document Page 11

12 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. Endpoint Security 10.1 Migration Planning Document Page 12

13 Figure 7. Query showing operating system version. Resources Current system requirements information is maintained here, 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 or higher is required to be installed on an endpoint in order to manage Endpoint Security 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 For new installations the latest version should be deployed - this is either epolicy Orchestrator or epolicy Endpoint Security 10.1 Migration Planning Document Page 13

14 Orchestrator 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 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: Gain familiarity with Endpoint Security 10.1 Before proceeding, it is recommended that basic familiarity is gained with Endpoint Security 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. VirusScan Enterprise 8.8 Common Host IPS 8.0 (Firewall only) Threat Prevention Firewall Site Advisor Enterprise 3.5 Legacy product and policies Web Control Endpoint Security module and policies Figure 8. Current product and policy to Endpoint Security module and policy mappings. Endpoint Security 10.1 Migration Planning Document Page 14

15 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. Endpoint Security 10.1 Migration Planning Document Page 15

16 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 VirusScan Enterprise Host Intrusion Prevention Firewall Module Host Intrusion Prevention IPS Module Site Advisor Enterprise Endpoint Security module Threat Prevention Firewall Threat Prevention Web Control Action VirusScan Enterprise will always be removed. The Threat Prevention module will be installed if this is selected as part of the deployment task. 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. 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 will always be removed. The Web Control module will be installed if this is selected as part of the deployment task. Endpoint Security 10.1 Migration Planning Document Page 16

17 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: A video, Introduction to McAfee Endpoint Security 10.1 can be found here: The Endpoint Security 10.1 Release Notes can be found here: The Endpoint Security 10.1 Installation Guide can be found here: The Endpoint Security 10.1 Product Guide can be found here: The whitepaper Understanding the McAfee Endpoint Security 10.1 Threat Prevention Module is available here: 10-module.pdf. Understanding McAfee Next Generation Performance Technology here: How McAfee Endpoint Security 10.1 s Next Generation Technologies Protect and Perform can be found here, Endpoint Security 10.1 Migration Planning Document Page 17

18 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 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. Endpoint Security 10.1 Migration Planning Document Page 18

19 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 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: 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 Endpoint Security 10.1 Migration Planning Document Page 19

20 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 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. Endpoint Security 10.1 Migration Planning Document Page 20

21 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. Endpoint Security 10.1 Migration Planning Document Page 21

22 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 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 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. Endpoint Security 10.1 Migration Planning Document Page 22

23 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 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. Endpoint Security 10.1 Migration Planning Document Page 23

24 Sample functional test cases Table 2. Sample functional test cases. Module Feature Test Endpoint Security 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. Platform Confirm successful signature rollback is possible after an update. Module Confirm new signature version is reflected within epolicy Orchestrator queries and dashboards. Endpoint Security Platform Module 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. Endpoint Security Platform Module Endpoint Security Platform Module Threat Protection Module Threat Protection Module 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. On-access scanner detection On-access scanner impact 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. 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. Endpoint Security 10.1 Migration Planning Document Page 24

25 Module Feature Test Threat On-demand Confirm malware is detected for example using EICAR (see below). Protection scanner Check GTI-based malware detection succeeds for example using GTI test files (see below). Module detection Ensure samples are quarantined correctly when detected. Confirm malware detection generates a local and epolicy Orchestrator event. Threat Protection Module On-demand scanner scheduling Schedule an on-demand scan and confirm it starts, completes and repeats according to the configured schedule settings. Threat Protection Module Threat Protection Module Threat Protection Module Threat Protection Module Firewall Module Firewall Module Web Protection Module Web Protection Module On-demand scanner scan duration Zero impact scheduled scanning 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. 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 Test standard access protection rules enabled do not trigger during normal operation. Standard Rules 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 Test custom access protection rules enabled do not trigger during normal operation. Custom Rules Test custom access protection rules enabled trigger when expected. Test trigger of custom access protection rules generate a local and epolicy Orchestrator event. 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. 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. Content actions Ensure Web Control is enabled and attempted access to a known good green site, (e.g. is allowed. Ensure Web Control is enabled and attempted access to a potentially dangerous yellow site, (e.g. 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. 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. 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. Endpoint Security 10.1 Migration Planning Document Page 25

26 Sample integration test cases Table 3. Sample internal integration test case. Integration Automatic quarantine of Endpoints with on-access scanning disabled Test 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 Reporting of events into a Security Information & Event Management (SIEM) system Import and deployment to Active Directory-based endpoints Test Generate test detection events on endpoints running Endpoint Security Confirm test events are reported to epolicy Orchestrator. Confirm epolicy Orchestrator events are collected and reported within the SIEM. 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. Endpoint Security 10.1 Migration Planning Document Page 26

27 Sample product migration test cases Table 5. Sample product migration test cases. Endpoint Role Sales Laptop Support Desktop Support Laptop Manager laptop Hardware Lenovo Thinkpad T450s HP Compaq 8200 Elite HP ZBook 15u G2 Lenovo ThinkPad X1 Operating System Windows 8.1 Windows 7 SP1 Windows 8.1 Windows 10 Existing Software VirusScan Enterprise 8.8 P6 Host IPS Firewall 8.0 P6 Site Advisor Enterprise 3.5 P4 VirusScan Enterprise 8.8 P5 VirusScan Enterprise 8.8 P6 Host IPS Firewall 8.0 P5 VirusScan Enterprise 8.8 P6 Host IPS Firewall 8.0 P6 Site Advisor Enterprise 3.5 P4 Test Removal of legacy software, i.e. VirusScan Enterprise & Site Advisor Enterprise, is successful 1. 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. 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. Update task completes and updates applied successfully. Configuration from policy applied successfully. Removal of legacy software, i.e. VirusScan Enterprise, is successful 1. Deployment of selected modules of Endpoint Security 10.1, i.e. Endpoint Security Platform, Threat Prevention & Firewall is successful. Update task completes and updates applied successfully. Configuration from policy applied successfully. Removal of legacy software, i.e. VirusScan Enterprise & Site Advisor Enterprise, is successful 1. 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. 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). Endpoint Security 10.1 Migration Planning Document Page 27

28 Sample management migration test cases Table 6. Sample management migration test cases. Action Recreated system tree on pilot epolicy Orchestrator server Export policies and tasks from existing production epolicy Orchestrator server Import policies and tasks to pilot epolicy Orchestrator server Assign appropriate policies and tasks within the system tree Migrate endpoints to pilot epolicy Orchestrator Confirm endpoints communicate successfully and receive correct configuration Test Ensure the correct system tree structure has been created. Confirm policies and tasks export successfully. Confirm policies and tasks import successfully and without conflict. Confirm assignments applied correctly within system tree structure. Confirm endpoints are located correctly within the system tree structure. 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: GTI Test files: Site Advisor & Web Control test pages: 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: Endpoint Security 10.1 Migration Planning Document Page 28

29 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 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. 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. Pilot on production epolicy Orchestrator server 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 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. Endpoint Security 10.1 Migration Planning Document Page 29

30 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 Number of endpoints deployed Remainder Table 9. Equal-size group deployment. Time period Number of endpoints deployed Table 10. Single group deployment. Time period Number of endpoints deployed 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. Endpoints Third group deployed Perform functional testing Second group deployed Perform functional testing First group deployed Perform functional testing Time 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. Endpoint Security 10.1 Migration Planning Document Page 30

31 Endpoints Third group deployed Perform functional testing Perform soak testing Second group deployed Perform functional testing Perform soak testing First group deployed Perform functional testing Perform soak testing Figure 14. Soak test duration. Time 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 Endpoint Security 10.1 Migration Planning Document Page 31

32 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 Use prod. epo Server for pilot? Yes Add ENS 10.1 package and extn s to prod. epo Server Migrate legacy policy to ENS 10.1 policy Migrate VirusScan etc. to ENS 10.1 on endpoints No Assign existing product config. to test epo Server Migrate endpoints to test epo Server 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. Endpoint Security 10.1 Migration Planning Document Page 32

33 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? Endpoint Security 10.1 Migration Planning Document Page 33

34 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. Endpoint Security 10.1 Migration Planning Document Page 34

35 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 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 Endpoint Security 10.1 Migration Planning Document Page 35

36 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 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. Endpoint Security 10.1 Migration Planning Document Page 36

37 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, and A video, Migrating from McAfee VirusScan Enterprise 8.8 to McAfee Endpoint Security 10.1 can be found here, A video, Migrating McAfee Host IPS 8.0 to McAfee Endpoint Security 10.1 can be found here, The Endpoint Migration Assistant Guide can be found here, 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. Endpoint Security 10.1 Migration Planning Document Page 37

38 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. Endpoint Security 10.1 Migration Planning Document Page 38

39 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. Endpoint Security 10.1 Migration Planning Document Page 39