Symantec Data Loss Prevention Network Monitor and Prevent Performance Sizing Guidelines. Version 12.5

Transcription

1 Symantec Data Loss Prevention Network Monitor and Prevent Performance Sizing Guidelines Version 2.5 Last updated: 8 July 204

2 Symantec Data Loss Prevention Network Monitor and Prevent Performance Sizing Guidelines Last updated 8 July 204 Legal Notice Copyright 204 Symantec Corporation. All rights reserved. Symantec, the Symantec Logo, and the Checkmark Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. This Symantec product may contain third party software for which Symantec is required to provide attribution to the third party ( Third Party Programs ). Some of the Third Party Programs are available under open source or free software licenses. The License Agreement accompanying the Software does not alter any rights or obligations you may have under those open source or free software licenses. Please see the Third Party Legal Notice Appendix to this Documentation or TPIP ReadMe File accompanying this Symantec product for more information on the Third Party Programs. The product described in this document is distributed under licenses restricting its use, copying, distribution, and decompilation/reverse engineering. No part of this document may be reproduced in any form by any means without prior written authorization of Symantec Corporation and its licensors, if any. THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE. The Licensed Software and Documentation are deemed to be commercial computer software as defined in FAR 2.22 and subject to restricted rights as defined in FAR Section "Commercial Computer Software - Restricted Rights" and DFARS , "Rights in Commercial Computer Software or Commercial Computer Software Documentation", as applicable, and any successor regulations. Any use, modification, reproduction release, performance, display or disclosure of the Licensed Software and Documentation by the U.S. Government shall be solely in accordance with the terms of this Agreement.

3 Symantec Corporation 350 Ellis Street Mountain View, CA

4 Technical Support Contacting Technical Support Symantec Technical Support maintains support centers globally. Technical Support s primary role is to respond to specific queries about product features and functionality. The Technical Support group also creates content for our online Knowledge Base. The Technical Support group works collaboratively with the other functional areas within Symantec to answer your questions in a timely fashion. For example, the Technical Support group works with Product Engineering and Symantec Security Response to provide alerting services and virus definition updates. Symantec s support offerings include the following: A range of support options that give you the flexibility to select the right amount of service for any size organization Telephone and/or Web-based support that provides rapid response and up-to-the-minute information Upgrade assurance that delivers software upgrades Global support purchased on a regional business hours or 24 hours a day, 7 days a week basis Premium service offerings that include Account Management Services For information about Symantec s support offerings, you can visit our website at the following URL: All support services will be delivered in accordance with your support agreement and the then-current enterprise technical support policy. Customers with a current support agreement may access Technical Support information at the following URL: Before contacting Technical Support, make sure you have satisfied the system requirements that are listed in your product documentation. Also, you should be at the computer on which the problem occurred, in case it is necessary to replicate the problem. When you contact Technical Support, please have the following information available: Product release level Hardware information

5 Available memory, disk space, and NIC information Operating system Version and patch level Network topology Router, gateway, and IP address information Problem description: Error messages and log files Troubleshooting that was performed before contacting Symantec Recent software configuration changes and network changes Licensing and registration Customer service If your Symantec product requires registration or a license key, access our technical support Web page at the following URL: Customer service information is available at the following URL: Customer Service is available to assist with non-technical questions, such as the following types of issues: Questions regarding product licensing or serialization Product registration updates, such as address or name changes General product information (features, language availability, local dealers) Latest information about product updates and upgrades Information about upgrade assurance and support contracts Information about the Symantec Buying Programs Advice about Symantec's technical support options Nontechnical presales questions Issues that are related to CD-ROMs, DVDs, or manuals

6 Support agreement resources If you want to contact Symantec regarding an existing support agreement, please contact the support agreement administration team for your region as follows: Asia-Pacific and Japan Europe, Middle-East, and Africa North America and Latin America

7 Contents Technical Support... 4 Chapter About Symantec Data Loss Prevention Network Monitor and Prevent Performance Guidelines... 9 About network performance tests... 9 About network performance sizing guidelines... 0 Chapter 2 Network Monitor Performance Guidelines... About the Network Monitor performance test environment with Endace cards... About the Network Monitor performance test methodology for an environment with Endace cards... 4 Network Monitor performance test results and sizing guidelines for environments with Endace cards... 4 About the Network Monitor performance test environment with Napatech cards... 6 About the Network Monitor performance test methodology for an environment with Napatech cards... 8 Network Monitor performance test results and sizing guidelines for environments with Napatech cards... 8 Chapter 3 Network Prevent for Performance Guidelines... 2 About the Network Prevent for performance test environment... 2 About the Network Prevent for performance test methodology Network Prevent for performance test results and sizing guidelines Test policy details for Network Prevent for

8 Contents 8 Chapter 4 Network Prevent for Web Performance Guidelines About the Network Prevent for Web performance test environment About the Network Prevent for Web performance test methodology... 3 Network Prevent for Web performance test results and sizing guidelines Test policy details for Network Prevent for Web Index... 37

9 Chapter About Symantec Data Loss Prevention Network Monitor and Prevent Performance Guidelines This chapter includes the following topics: About network performance tests About network performance sizing guidelines About network performance tests Symantec tests Network Monitor, Network Prevent for , and Network Prevent for Web to assess their performance under load. Network Prevent for and Network Prevent for Web are also tested to compare performance between physical systems and virtual machine (VM) configurations. The key objective of these tests is to obtain data on the overall performance and throughput of the Symantec Data Loss Prevention Network Monitor and Network Prevent products. This document can also assist you with your network sizing efforts. These tests are designed to determine the achievable throughput of different system resource configurations. The test results provide general guidelines. Network and administrators can use these guidelines to estimate the number of servers that are required to support traffic loads on a network. The guidelines can also be used to estimate the required virtual system resources. Symantec recommends that you conduct your own testing

10 About Symantec Data Loss Prevention Network Monitor and Prevent Performance Guidelines About network performance sizing guidelines 0 with more representative traffic profiles and loads. Running your own tests validates that your results are in line with the sizing assumptions provided by Symantec. Symantec conducted tests using both Endace and Napatech high-speed packet capture adapters. Network Monitor test environments for each of these high-speed packet capture adapters are described in separate sections. See About network performance sizing guidelines on page 0. About network performance sizing guidelines When you use a virtualized environment you should expect some performance degradation (as compared to running on a physical system with similar system resources). Note that you may be able to minimize performance degradation by optimizing the VMware configuration specific to your environment. Follow these guidelines when planning any server deployment: All of the data that is presented in this documentation can be used as a reference for estimating deployment requirements. Validate sizing guidelines in your own test environments before deployment. You should test with those policies and configurations that are consistent with expected deployments. For example, IDM-, EDM-, DCM-, and VML-based policies, configuration filters, and so on. You should evaluate results using a traffic profile that is consistent with your live production environment. See About the Network Monitor performance test environment with Endace cards on page. See About the Network Monitor performance test environment with Napatech cards on page 6. See About the Network Prevent for performance test environment on page 2. See About the Network Prevent for Web performance test environment on page 29.

11 Chapter 2 Network Monitor Performance Guidelines This chapter includes the following topics: About the Network Monitor performance test environment with Endace cards About the Network Monitor performance test methodology for an environment with Endace cards Network Monitor performance test results and sizing guidelines for environments with Endace cards About the Network Monitor performance test environment with Napatech cards About the Network Monitor performance test methodology for an environment with Napatech cards Network Monitor performance test results and sizing guidelines for environments with Napatech cards About the Network Monitor performance test environment with Endace cards Symantec conducted Network Monitor performance testing in a lab environment. This lab was designed to demonstrate the comparative accuracy of all available capture methods against a replicated traffic load. Tests were conducted using Endace high-speed packet capture cards with the following hardware configurations. Table 2- describes the hardware environment that was used to test Network Monitor with Endace cards.

12 Network Monitor Performance Guidelines About the Network Monitor performance test environment with Endace cards 2 Note: Throughout this document, "core" refers to physical CPU cores, not to hyper-threading CPU cores. Table 2- Component Processor Network Monitor test hardware with Endace cards System hardware configuration x Intel Xeon E5620 processor (quad-core) (2.4 GHz, 066 MHz FSB) Memory 8 GB RAM or 6 GB RAM Ethernet controller used for testing native capture High-speed packet capture card Network tap Intel 8257 Gigabit Ethernet controller Endace 7.5 G2/G4 (PCIe) cards with DAG v4.2.4 drivers, utilities, and run-time libraries. A multi-port regenerative gigabit Ethernet tap facilitated distribution of the output from a TCP replay computer to the target Network Monitor servers. Tests were performed using the following operating-system configurations: Red Hat Enterprise Linux 5.7 and 6.4 (64-bit) with native packet capture. Red Hat Enterprise Linux 5.7 and 6.4 (64-bit) with Endace high-speed packet capture card. Figure 2- shows the relationship of test computers to the network traffic generator.

13 Network Monitor Performance Guidelines About the Network Monitor performance test environment with Endace cards 3 Figure 2- Network Monitor performance test environment with Endace cards Traffic generator TCP replay machine Network Monitor on RHEL with native packet capture Network Monitor on RHEL with Endace packet capture The Network Monitor servers were tested with a standard one quad-core processor configuration using both native capture and Endace capture methods. The servers were tested on Linux platforms. They were configured as follows: Red Hat Enterprise Linux 5.7 and 6.4 servers were configured for both Endace cards and for native tests. Network Monitor advanced settings were tuned as follows: Network Monitor advanced setting NUMBER_BUFFER_POOL_PACKETS NUMBER_SMALL_POOL_PACKETS KERNEL_BUFFER_SIZE Linux 64-bit systems,200,000,000, MB For 64-bit systems with a kernel buffer large enough to handle the processing capability of the NIC driver, increasing the buffer further showed no substantial increase in performance All standard protocols were active, in addition to custom protocol definitions for Telnet, SSH, and SSL.

14 Network Monitor Performance Guidelines About the Network Monitor performance test methodology for an environment with Endace cards 4 See About the Network Monitor performance test methodology for an environment with Endace cards on page 4. About the Network Monitor performance test methodology for an environment with Endace cards A single IDM policy was enabled that covered a target 20-MB document Sizing guidelines were derived from a background load of real-world traffic samples. These samples were delivered at rates ranging from 5,000 to over 200,000 packets per second. The resulting sustained background load ranged from 70 Mbps to near gigabit-level saturation. At each background load interval, 20 copies of the target file were played at a constant rate of 3000 packets per second. Monitors that correctly generated an incident for all 20 iterations of the target file at a 00% match rate were considered a success. That is, these monitors successfully handled the offered load. When a given capture method was no longer able to deliver total match accuracy, or when packet capture discards occurred, it was considered to have reached the limit of its performance capabilities See Network Monitor performance test results and sizing guidelines for environments with Endace cards on page 4. Network Monitor performance test results and sizing guidelines for environments with Endace cards Network Monitor servers were tested with different capture methods that accommodated different levels of network traffic. All systems were tested using Red Hat Enterprise Linux 5.7 and 6.4 (64-bit). Based on this performance testing, Symantec rates the tested configurations as shown in Table 2-2. Table 2-2 Supported pre-filter performance for Network Monitor capture methods for environments with Endace cards Server configuration Native packet capture Endace card packet capture (driver version 4.2.4) Bandwidth (Mbps) The test results for your network environment may be different. Variations in the protocol composition, protocol configuration, and policy load in a production

15 Network Monitor Performance Guidelines Network Monitor performance test results and sizing guidelines for environments with Endace cards 5 deployment make a difference. Symantec recommends testing in advance against live or recorded feeds from your production infrastructure and your target protocol and policy configuration. This advance testing enables you to assess the capability to meet the demands of your deployment. Note that you may have a configuration issue if there is a wide divergence of your performance numbers from those presented in this document. The issue may be with your network architecture, tap or span configuration, network card, or capture settings. See About network performance sizing guidelines on page 0. The Network Monitor tests were designed to determine at what level of overall network traffic the detection capability of a Network Monitor Server begins to decline. As traffic rates increase, additional servers should be added to balance the total load so that no individual server s load exceeds the target level. Table 2-3 shows the estimated number of Network Monitor servers that are required for different traffic levels. This estimation assumes that test results of a single Network Monitor Server are similar to those presented here. Table 2-3 Estimating the number of Network Monitor servers for testing with Endace cards Network traffic (Mbps) Linux native packet capture 2 2 Endace card packet capture The traffic estimates shown assume: Equal load distribution across all servers No redundancy See About the Network Monitor performance test environment with Napatech cards on page 6.

16 Network Monitor Performance Guidelines About the Network Monitor performance test environment with Napatech cards 6 About the Network Monitor performance test environment with Napatech cards Symantec conducted Network Monitor performance testing in a lab environment. These tests were designed to demonstrate the comparative accuracy of all available capture methods against a replicated offered traffic load. Tests were done using Napatech packet capture cards with the following hardware configurations. Table 2-4 describes the hardware environment that was used to test the performance of Network Monitor in an environment with Napatech packet capture cards. Note: Throughout this document, "core" refers to physical cores, not to hyper-threading cores. Table 2-4 Network Monitor performance test hardware for environments with Napatech cards Component Processor System hardware configuration quad-core Xeon E5620 CPU (2.4 GHz, 066 MHz FSB) Memory Ethernet controller used to test native capture High-speed packet capture adapter 6 GB RAM Intel 8257 Gigabit Ethernet Controller Napatech NT4E (non-std) adapter with driver v4.22c (Windows). Tools and run-time libraries as of Napatech software package v Napatech NT4E (non-std) adapter with driver v4.22 A (Linux). Tools and run-time libraries as of Napatech software package v Napatech NT4E (non-std) adapter with driver v4.26 A (RHEL 5.7 and 6., Windows 2008 R2). Tools and run-time libraries as of Napatech software package v Tests were performed using the following operating-system configurations: Windows Server 2008 R2 (64-bit) with native packet capture. Red Hat Enterprise Linux 5.7 and 6. (64-bit) with native packet capture. Windows Server 2008 R2 (64-bit) with Napatech adapter. Red Hat Enterprise Linux 5.7 and 6. (64-bit) with Napatech adapter.

17 Network Monitor Performance Guidelines About the Network Monitor performance test environment with Napatech cards 7 Figure 2-2 shows the relationship of test computers to the network traffic generator. Figure 2-2 Network Monitor performance test environment using Napatech cards Traffic generator multiport TCP replay machine Network Monitor on RHEL and Windows with native packet capture Network Monitor on Windows with native packet capture Network Monitor on RHEL and Windows with Napatech card Network Monitor on Windows with Napatech card The Network Monitor servers were tested on both a standard hardware configuration and a large system hardware configuration. Both native capture and Napatech capture methods on Linux and Windows platforms were used. The systems were configured as follows: Network Monitor advanced settings were tuned as follows: Network Monitor advanced setting NUMBER_BUFFER_POOL_PACKETS NUMBER_SMALL_POOL_PACKETS KERNEL_BUFFER_SIZE All 64-bit systems,200,000,000, MB Increasing the buffer further showed no substantial increase in performance for 64-bit systems. This assumes that the kernel buffer was large enough to handle the processing capability of the high-speed packet capture adapter.

18 Network Monitor Performance Guidelines About the Network Monitor performance test methodology for an environment with Napatech cards 8 All standard protocols were active, in addition to custom protocol definitions for Telnet, SSH, and SSL. See About the Network Monitor performance test methodology for an environment with Napatech cards on page 8. About the Network Monitor performance test methodology for an environment with Napatech cards A single IDM policy was enabled that covered a target 20-MB document Sizing guidelines were derived from a background load of real-world traffic samples. The samples were delivered at rates ranging from 5,000 to over 200,000 packets per second. The resulting sustained background load ranged from 70 Mbps to near gigabit-level saturation. At each background load interval, 20 copies of the target file were played at a constant rate of 3000 packets per second. If a Network Monitor Server correctly generated an incident for all 20 iterations of the target file at a 00% match rate, it was considered a success. When a given capture method was no longer able to deliver total match accuracy, it had reached the limit of its performance capabilities. See Network Monitor performance test results and sizing guidelines for environments with Napatech cards on page 8. Network Monitor performance test results and sizing guidelines for environments with Napatech cards Network Monitor servers were tested with different capture methods. The capture methods accommodated different levels of network traffic. Tests were performed with Windows Server 2008 R2 (64-bit); and Red Hat Enterprise Linux 5.7 and 6. (64-bit). The results of this performance testing are shown in Table 2-5. Table 2-5 Supported pre-filter performance for Network Monitor capture methods in environments with Napatech cards Server configuration Native packet capture Operating system Windows Server 2008 R2 Red Hat Enterprise Linux 5.7 and 6. Bandwidth (Mbps)

19 Network Monitor Performance Guidelines Network Monitor performance test results and sizing guidelines for environments with Napatech cards 9 Table 2-5 Supported pre-filter performance for Network Monitor capture methods in environments with Napatech cards (continued) Server configuration Napatech card Operating system Windows Server 2008 R2 Red Hat Enterprise Linux 5.7 and 6. Bandwidth (Mbps) Variations in the protocol composition, protocol configuration, and policy load in a production deployment may produce different test results for your network environment. Symantec recommends testing in advance against live or recorded feeds from your production infrastructure and your target protocol and policy configuration. This way, you can assess the capability of your setup to meet the demands of your deployment. If your performance numbers diverge from those presented in this document, that might indicate a configuration issue. Possible issues include problems with your network architecture, tap or span configuration, network card, or capture settings. See About network performance sizing guidelines on page 0. The Network Monitor tests determine at what level of overall network traffic the detection capability of a Network Monitor Server begins to decline for each capture method. As traffic rates increase, additional servers should be added to balance the total load so that no individual server s load exceeds the target level. Table 2-6 shows the number of Network Monitor Servers that are required for different traffic levels, assuming that test results of a single Network Monitor Server are similar to those presented here. Table 2-6 Estimating the number of Network Monitor Servers for testing in an environment with Napatech cards Network traffic (Mbps) Windows native packet capture Linux native packet capture Napatech card packet capture These estimates assume:

20 Network Monitor Performance Guidelines Network Monitor performance test results and sizing guidelines for environments with Napatech cards 20 Equal load distribution across all servers No redundancy See About the Network Prevent for performance test environment on page 2.

21 Chapter 3 Network Prevent for Performance Guidelines This chapter includes the following topics: About the Network Prevent for performance test environment About the Network Prevent for performance test methodology Network Prevent for performance test results and sizing guidelines Test policy details for Network Prevent for About the Network Prevent for performance test environment Using load generators and sample content, both standard hardware and virtual machine (VM) configurations were tested to simulate different customer environments. These test results provide a point-in-time measurement that was generated using the specific variables and the configurations that are described in this section. Network Prevent for Servers were tested on the Symantec-recommended hardware configurations for physical systems. They were also tested on two virtual machine configurations with different virtual CPU resources. Although memory configurations are listed, be aware that Network Prevent for performance is primarily CPU-bound, not memory-bound. Table 3- shows the hardware and operating system configurations that are used for the physical server computers and for the virtual machine host computers. Physical configurations were tested using Microsoft Windows Server 2008 R2,

22 Network Prevent for Performance Guidelines About the Network Prevent for performance test methodology 22 Enterprise Edition (64-bit). Virtual configurations were tested using Red Hat Enterprise Linux 6.4 (64-bit). Table 3- Network Prevent for performance test hardware Component Physical server hardware configuration quad-core Physical server hardware configuration 2 quad-core Virtual machine host server configuration quad-core Virtual machine host server configuration 2 quad-core Processor 3.0 GHz CPU 3.0-GHz CPUs 3.0 GHz CPU 3.0-GHz CPUs Memory 6 GB RAM 6 GB RAM 6 GB RAM 6 GB RAM NIC Copper GB/00 Mbps Ethernet NIC Copper GB/00 Mbps Ethernet NIC Copper GB/00 Mbps Ethernet NIC Copper GB/00 Mbps Ethernet NIC Network Prevent for was tested on the virtual machine host using one VM configuration running on the following platform: VMware: ESXi Server GB VM container Two VM configurations with a different number of virtual CPUs were tested: 4 CPU VM container 8 CPU VM container Note that hyper-threading was not enabled for the physical configurations that are presented here, but was enabled for the test VM configurations. See About the Network Prevent for performance test methodology on page 22. About the Network Prevent for performance test methodology Network Prevent for Servers were tested using a representative set of 20 policies. These policies included a variety of detection types. An auto-load generation tool (called sendmail tool in Figure 3-) was used to simulate an environment. The tool sent traffic in forwarding mode between a client and server with a Network Prevent for Server between them.

23 Network Prevent for Performance Guidelines Network Prevent for performance test results and sizing guidelines 23 Figure 3- Network Prevent for performance test environment Client with sendmail tool Network Prevent for Mail server (Postfix) The Network Prevent for Servers were tested using the same set of message attachments. For test purposes, message attachments were used to control message size and volume and to generate incidents. The test messages contained minimal body text with no content that violated policies. Number of messages = 0,000 Number of attachments = 35 Attachment size = average 0 KB Average size of s = 35 KB per message Attachments were a mixture of doc, html, jpg, pdf, png, ppt, txt, xls, and zip file types Approximately 5% of these message attachments contained content that violated one or more of the test policies. See Network Prevent for performance test results and sizing guidelines on page 23. Network Prevent for performance test results and sizing guidelines The following two tables present benchmark results. They indicate the throughput, message volume, and average processing time that you can expect from a single Network Prevent for Server. Symantec tested Network Prevent for TLS support in a configuration that is detailed in the Symantec Data Loss Prevention 64-bit Server Migration and Tuning Guide between MTAs and Network Prevent for Servers to determine the number of concurrent SMTP and TCP connections. In this configuration, enabling TLS processing caused a reduction of about 0% in the throughput compared to the value that is shown in thetable 3-2. This is the worst case at maximum load capacity. For example, if you push 40 messages per a second, the transfer time

24 Network Prevent for Performance Guidelines Network Prevent for performance test results and sizing guidelines 24 (latency) is However, if you are push message per second, the transfer time (latency) is much less. Your throughput may be reduced further if your MTA does not optimize TLS connection setup and reuse. This reduction happens because of the increased processing overhead necessary to establish secure connections. Consult your MTA documentation and perform additional testing to evaluate TLS performance in your environment. Note: The results in Table 3-2 do not include any redundancy, failover, or TLS processing requirements. The default setting is 8 message chains and 2 connections. Tuning is done between the number of cores and number of message chains. Table 3-2 Network Prevent for performance test results - no TLS System configuration Standard physical system quad-core tuned configuration, 8 GB RAM ( physical core:2 message chains) 2 quad-core default settings 2 quad-core tuned configuration ( physical core:2 message chains) VM container quad-core CPU VM container 2 quad-core default settings, 8 GB RAM Message volume (messages per second) Latency (in seconds) VM container 2 quad-core tuned configuration, 8 GB RAM ( physical core:2 message chains)

25 Network Prevent for Performance Guidelines Network Prevent for performance test results and sizing guidelines 25 The results in Table 3-3 do not include any redundancy or failover, but do include TLS processing requirements. Table 3-3 Network Prevent for performance test results - with TLS System configuration Message volume (messages per second) Latency (in seconds) Standard physical system quad-core tuned CPU, 8 GB RAM ( physical core:2 message chains) quad-core default CPU 2 quad-core tuned CPU ( physical core:2 message chains) VM container quad-core CPU, 8 GB RAM VM container 2 quad-core default CPU, 8 GB RAM VM container 2 quad-core tuned CPU, 8 GB RAM ( physical core:2 message chains) Network Prevent for Servers scale linearly to handle volumes in excess of the figures that are shown here. Most MTAs can distribute load to the corresponding Network Prevent for Servers as necessary. Network Prevent for Servers are commonly paired with MTAs in an N:N redundant, load-balanced configuration. You can estimate server requirements by extrapolating from the testing numbers that are shown here. You need to know the policy set and size of the message set. Understanding your organization s current traffic helps you determine how many Network Prevent for servers are needed to stay within the throughput

26 Network Prevent for Performance Guidelines Network Prevent for performance test results and sizing guidelines 26 and response time limits shown. For example, the SMTP traffic that needs to be processed in a network deployment can be obtained from two sources. It can come from the MTA itself or a general sizing guideline of X outbound messages per user may be estimated. A variety of factors influence performance of the virtual configurations. These factors include the number of CPUs and amount of physical RAM, as well as resource reservations for CPU cycles and RAM. Overhead from virtualization and guest operating systems can lead to a performance degradation in messaging throughput. This performance is compared to a standard physical system running on the same hardware. You may want to run multiple virtual instances on the same hardware to extract maximum performance and take full advantage of system resources. Note that when virtualized, Network Prevent for runs as its own VM image. If the MTA is also virtualized, then both Network Prevent for and the MTA can run on the same physical server within a given virtual container. A dedicated network interface should be used for each VM container. Your own test results should be used as a basis for sizing your Network Prevent for requirements. Note: The recommendations in Table 3-4 do not account for redundancy or failover, or TLS processing requirements. The recommendations are based on using tuned settings. Table 3-4 Estimating the number of Network Prevent for servers Traffic volume Number of 8-CPU physical servers needed Number of 8-CPU VM containers needed Number of 4-CPU VM containers needed 70 messages per second messages per second The traffic estimates shown in Table 3-4 assume: Equal load distribution across all servers No redundancy Your test results for your network environment may be different. A wide divergence of your performance numbers from the results that are presented here may indicate a configuration issue between your system and the Network Prevent for system.

27 Network Prevent for Performance Guidelines Test policy details for Network Prevent for 27 See Test policy details for Network Prevent for on page 27. Test policy details for Network Prevent for All tests of Network Prevent for were run using the same set of Symantec Data Loss Prevention policies. These policies are shown in the following table. Table 3-5 Policy Network Prevent for test policies Type Content Extraction Excel Content Extraction PowerPoint Content Extraction Word Visio Content Extraction PDF Content Extraction RDF Content Extraction Text Metadata Network Prevent for customized policy EDM Exceptions - Entire message Exceptions - IDM Exception Component Only File Name Exception Compound Rule - Keyword and Regex Policy Keyword Proximity - Whole Word with Wildcard Keyword and SSN rules with DCM Exceptions Content Extraction UTF8 Policy Keyword MS Excel Keyword - MS PowerPoint Keyword - Microsoft Word Keyword - MS Visio Keyword - pdf Keyword - rdf Keyword - txt Metadata Keywords EDM - SSN, Driver's License, Keywords and metadata IDM Regular expressions and metadata Keywords and regular expressions Keywords Keywords Keywords and Data identifiers (DI) Data identifiers (DI) Content extraction large size

28 Network Prevent for Performance Guidelines Test policy details for Network Prevent for 28 Table 3-5 Policy Network Prevent for test policies (continued) Type Protocol Keyword Regex Exception CCN Condition Regular expressions See About the Network Prevent for Web performance test environment on page 29.

29 Chapter 4 Network Prevent for Web Performance Guidelines This chapter includes the following topics: About the Network Prevent for Web performance test environment About the Network Prevent for Web performance test methodology Network Prevent for Web performance test results and sizing guidelines Test policy details for Network Prevent for Web About the Network Prevent for Web performance test environment Network Prevent for Web servers were tested on the Symantec-recommended hardware specifications for physical systems. They were also tested on two virtual machine configurations with different virtual CPU resources. Table 4- shows the hardware and operating system configuration that was used for the physical server computer. Tests were performed using Microsoft Windows Server 2008 R2, Enterprise Edition (64-bit) operating system.

30 Network Prevent for Web Performance Guidelines About the Network Prevent for Web performance test environment 30 Table 4- Network Prevent for Web physical test hardware configuration Component Processor (hyper-threading enabled) Memory Disk space NIC Physical server hardware configuration quad-core 2.4-GHz CPUs 6 GB RAM hyper-threaded 40-GB ultra-fast SCSI Copper GB/00 Mbps Ethernet NIC Physical server hardware configuration 2 quad-core 2.4 GHz CPU 6 GB RAM hyper-threaded 40-GB ultra-fast SCSI Copper GB/00 Mbps Ethernet NIC Table 4-2 shows the hardware and operating system configuration that was used for the virtual machine host computer. Table 4-2 Network Prevent for Web virtual machine test hardware configuration Component Processor Memory Disk space NIC Virtual machine host server hardware configuration quad-core 2.4 GHz E5620 CPU (8 cores total, with hyper-threading enabled) 6 GB RAM 40-GB ultra-fast SCSI Copper GB/00 Mbps Ethernet NIC Virtual machine host server hardware configuration 2 quad-core 2.4 GHz E5620 CPU (6 cores total, with hyper-threading enabled) 6 GB RAM 40-GB ultra-fast SCSI Copper GB/00 Mbps Ethernet NIC Network Prevent for Web performance was tested on the virtual machine host using two different VM configurations running on the following platform: VMware ESXi Server 5.0, VM version 8 6 GB VM container Two VM configurations with a different number of virtual CPUs were tested:

31 Network Prevent for Web Performance Guidelines About the Network Prevent for Web performance test methodology 3 quad-core CPU VM container 2 quad-core CPU VM container Note that hyper-threading was enabled for the test VM configurations. See About the Network Prevent for Web performance test methodology on page 3. About the Network Prevent for Web performance test methodology Using load generators and sample content, both standard hardware and virtual machine (VM) configurations were tested to simulate different customer environments. These test results provide a point-in-time measurement that was generated using the variables and configurations that are specified in this section. Network Prevent for Web servers were tested using a representative set of ten policies. These policies included a variety of detection types. To simulate web traffic, an auto-load generation tool was used. The tool sends ICAP requests and accepts the ICAP responses it receives from the Network Prevent for Web Server. The traffic consists of encapsulated HTTP POSTs, with no FTP or HTTPS traffic. Each encapsulated HTTP POST request contains a very small body of text with no policy violation and a file attachment that is selected from the data set. Multiple runs for each data set were executed with each test run lasting for ten minutes. Figure 4- shows the Network Prevent for Web test configuration that was used to produce the data in the following tables. Figure 4- Network Prevent for Web performance test environment ICAP response Incidents ICAP request Policies Test driver running ICAP performance tool Network Prevent for Web Enforce Server and database

32 Network Prevent for Web Performance Guidelines Network Prevent for Web performance test results and sizing guidelines 32 Three data sets with different characteristics were used to simulate HTTP traffic. Table 4-3 shows the characteristics of these small, medium, and large data sets. Table 4-3 Network Prevent for Web test data sets Small data set Medium data set Large data set Average file sizes 4 KB 0 KB.77 MB Number of files Number of incidents about 5% about 6% about 5% File types (by extension) asc, asp, bat, cfm, cpp, doc, eml, gif, h, htm, html, java, js, lnk, pdf, rtf, txt, vbs, xml, zip C, Doc, h, htm, html, js, mht, mpp, pdf, ppt, rtf, xls, zip doc, gz, h, htm, inf, jpg, log, pdf, ppt, rtf, txt, xls, zip The "Number of incidents" specifies the percentage of incidents that are created by a single run of the data set against the test policy set. See Network Prevent for Web performance test results and sizing guidelines on page 32. Network Prevent for Web performance test results and sizing guidelines With Network Prevent for Web in place, performance data was determined by logging request size and request processing time on physical hardware. These two data points were used to determine the throughput and incremental delay. Three different data set sizes were used: large, medium, and small. The following points about the testing and the test results represented in the following tables are important to note. When Network Prevent for Web is tuned to the defaults presented here, it runs at about 90% capacity. Adding a spare CPU can increase the performance of your Network Prevent for Web servers. SinceNetwork Prevent for Web is CPU, not RAM, bound, adding more RAM will not necessarily improve performance. Each test was done with both physical core to message chain and physical core to 2 message chains. All tests were done on Windows 2008 servers, with 6 GB RAM.

33 Network Prevent for Web Performance Guidelines Network Prevent for Web performance test results and sizing guidelines 33 In the following tables, latency refers to average processing time. HT = hyper-threaded. Table 4-4 details Network Prevent for Web performance with both physical hardware and virtual hardware, with CPU to message chain. Table 4-4 Network Prevent for Web throughput and incremental delay (latency) test data for physical and virtual hardware CPU to message chain Test server Small Medium Large physical core to message chain Latency (seconds) data set Throughput (Mbps) Latency (seconds) data set Throughput (Mbps) Latency (seconds) data set Throughput (Mbps) quad-core CPU, HT physical system quad-core CPU, HT physical system quad-core CPU, HT virtual system quad-core CPU, HT virtual system Table 4-5 details Network Prevent for Web performance with both physical hardware and virtual hardware, with physical core to 2 message chains. Table 4-5 Network Prevent for Web throughput and incremental delay (latency) test data for both physical hardware and virtual hardware physical core to 2 message chains Test server Small Medium Large physical core to 2 message chains Latency data set Throughput Latency data set Throughput Latency data set Throughput (seconds) (Mbps) (seconds) (Mbps) (seconds) (Mbps) quad-core CPU, HT physical system quad-core CPU, HT physical system

34 Network Prevent for Web Performance Guidelines Network Prevent for Web performance test results and sizing guidelines 34 Table 4-5 Network Prevent for Web throughput and incremental delay (latency) test data for both physical hardware and virtual hardware physical core to 2 message chains (continued) Test server Small Medium Large physical core to 2 message chains Latency data set Throughput Latency data set Throughput Latency data set Throughput (seconds) (Mbps) (seconds) (Mbps) (seconds) (Mbps) quad-core CPU, HT virtual system quad-core CPU, HT virtual system With Network Prevent for Web in place, performance data was determined by logging request size and request processing time on virtual hardware. These two data points were used to determine the throughput and incremental delay. Three different data set sizes were tested: small, medium, and large. Note: Virtual machine testing for Network Prevent for Web showed an average processing time per request ranging from 0. seconds to 2. seconds on a 64-bit Windows system with a quad-core CPU test server. You should perform in-house testing with your chosen hardware, virtual machine, and operating system configuration to validate performance results before deployment. The average processing time includes the time that Network Prevent for Web takes to receive the HTTP POST transaction (encapsulated in ICAP) from the tool. It also includes the time to perform a Data Loss Prevention inspection and send the inspected transaction back to the tool. The results that are shown in the previous tables assume that Network Prevent for Web is configured to inspect all requests larger than KB in size (the default setting is 4 KB). Tests in your network environment may have different results. However, a wide divergence of your performance numbers from those presented in this document may indicate an issue with network and Network Prevent for Web Server configuration. A variety of factors influence performance of the virtual configurations. These factors include: the number of CPUs, amount of physical RAM, as well as resource reservations for CPU cycles and RAM. The virtualization and guest operating system overhead can lead to a modest performance degradation in web throughput of large

35 Network Prevent for Web Performance Guidelines Network Prevent for Web performance test results and sizing guidelines 35 data sets. This is compared to a standard physical system running on the same hardware. You may want to run multiple virtual instances on the same hardware to extract maximum performance and take full advantage of system resources. See About network performance sizing guidelines on page 0. Your test results should be used as a basis for sizing your Network Prevent for Web server requirements. If your test results of a single Network Prevent for Web Server are similar to the results for the medium data set shown in Table 4-4, you should expect the results that are shown intable 4-6. Table 4-6 Estimating the number of Network Prevent for Web Servers HTTP traffic volume Number of quad-core physical servers with message chain to CPU ratio of : Number of 2 quad-core physical servers with message chain to CPU ratio of : Number of 2 quad-core VM servers with message chain to CPU ratio of : Number of quad-core physical servers with message chain to CPU ratio of :2 50 Mbps 00 Mbps Mbps Mbps Note: For the message chain to 2 CPU ratio, when estimating the number of Network Prevent for Web Servers, there are a few things to consider. When the message chain to CPU core ratio is set to :2, CPU utilization is near 95%. You should ensure that you have no other processors running and have a backup/redundantnetwork Prevent for Web Server as CPU utilization is so high. You should also monitor CPU utilization closely to understand the system health under load. The estimates shown assume that: Traffic flows are comparable to the Medium data set, with an average file size of 0 KB Equal load distribution across all servers No redundancy

36 Network Prevent for Web Performance Guidelines Test policy details for Network Prevent for Web 36 See Test policy details for Network Prevent for Web on page 36. Test policy details for Network Prevent for Web All tests of Network Prevent for Web were run using the same set of Symantec Data Loss Prevention policies. These policies are shown in the following table. Table 4-7 Policy Network Prevent for Web test policies Type Comments Credit Card Numbers U.S. Social Security Numbers State Data Privacy OMB Memo Data Identifiers (DI) Data Identifiers (DI) Data Identifiers (DI) Keywords 06-6/FIPS 99 NERC Encrypted Data Source code GLBA EDM Policy Fake Customer Policy Longevity IDM Policy Keywords Keywords and metadata Regular expressions and metadata EDM EDM IDM To achieve an incident rate of about 5%, source code file types are treated as exceptions instead of as one of the detection conditions in the policy. million rows, 4.25 MB EDM. An incident is created on 3 or more matches.,040,00 rows, 5.3 MB EDM. An incident is created on 3 or more matches. 600 documents

37 Index A advanced settings 3, 7 B background loads 4, 8 C cores 22, D drivers Endace 4 Endace DAG 2 Napatech 6 NIC 3 E Endace cards 2 Endace DAG drivers 2 Ethernet controllers 2, 6 H high-speed packet capture card 2, 6 HTTP POSTs 3 HTTP transactions 34 hyper-threading 2, 6, 22, 30 3 I ICAP 34 IDM policies 4, 8 M memory 2, 6, 22, 30 message chains 24 25, MTAs 25 N Napatech card drivers 6 network cards 22, 30 Network Monitor advanced settings 3, 7 sizing guidelines with Endace cards 5 sizing guidelines with Napatech cards 9 test environment with Endace cards 3 test environment with Napatech cards 6 7 test hardware with Endace cards 2 test hardware with Napatech cards 6 test methodology with Endace cards 4 test methodology with Napatech cards 8 test results with Endace cards 4 test results with Napatech cards 8 Network Prevent for sizing guidelines 23, 26 test environment 2 test hardware 22 test methodology 22 test policies 22 23, 27 test results Network Prevent for Web data sets for testing 32 physical test hardware 30 sizing guidelines 32, 35 test environment 29 test methodology 3 test policies 36 test results 32 throughput and incremental delay results for physical hardware throughput and incremental delay results for virtual hardware virtual machine hardware 30 network taps 2 NIC 22, 30 O outbound messages 26 P packet capture methods with Endace cards 4