THIRD BRIGADE DEEP SECURITY HOST INTRUSION PREVENTION SYSTEM (WINDOWS SERVER 2003) PRODUCT REPORT ON PCI SUITABILITY

Transcription

1 THIRD BRIGADE DEEP SECURITY HOST INTRUSION PREVENTION SYSTEM (WINDOWS SERVER 2003) PRODUCT REPORT ON PCI SUITABILITY HOST INTRUSION PREVENTION (HIPS) NSS LABS CRITERIA VERSION: 1.2 PCI DSS 1.1 APRIL 6, 2008

2 Published by NSS Labs NSS Labs CONTACT: 5115 Avenida Encinas Suite H Carlsbad, CA Tel: info@nsslabs.com Internet: All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the authors. This report shall be treated at all times as a confidential and proprietary report for internal use only. Please note that access to or use of this Report is conditioned on the following: 1. The information in this Report is subject to change by NSS Labs without notice. 2. The information in this Report is believed by NSS Labs to be accurate and reliable, but is not guaranteed. All use of and reliance on this Report are at your sole risk. NSS Labs is not liable or responsible for any damages, losses or expenses arising from any error or omission in this Report. 3. NO WARRANTIES, EXPRESS OR IMPLIED ARE GIVEN BY THE NSS LABS. ALL IMPLIED WARRANTIES, INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT ARE DISCLAIMED AND EXCLUDED BY NSS LABS. IN NO EVENT SHALL NSS LABS BE LIABLE FOR ANY CONSEQUENTIAL, INCIDENTAL OR INDIRECT DAMAGES, OR FOR ANY LOSS OF PROFIT, REVENUE, DATA, COMPUTER PROGRAMS, OR OTHER ASSETS, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. 4. This Report does not constitute an endorsement, recommendation or guarantee of any of the products (hardware or software) tested or the hardware and software used in testing the products. The testing does not guarantee that there are no errors or defects in the products, or that the products will meet your expectations, requirements, needs or specifications, or that they will operate without interruption. 5. This Report does not imply any endorsement, sponsorship, affiliation or verification by or with any companies mentioned in this report. For PCI-related reports, this does not constitute an endorsement by the PCI Security Standards Council. 6. All trademarks, service marks, and trade names used in this Report are the trademarks, service marks, and trade names of their respective owners, and no endorsement of, sponsorship of, affiliation with, or involvement in, any of the testing, this Report or NSS Labs is implied, nor should it be inferred.

3 EXECUTIVE SUMMARY In Q1 of 2008, NSS Labs performed comprehensive testing of the Third Brigade Deep Security software as a Host Intrusion Prevention System (HIPS) for use in payment card environments. This report contains the conclusions and associated data from a series of exacting tests performed on a Windows Server 2003 installed in our real-world test lab. Support for PCI DSS requirements was well thought out and clearly part of a dedicated effort to empower customers. NSS Labs found that Deep Security successfully passed 19 DSS requirements, and supported 38 others indirectly. There was one (1) failure of an indirect requirement: obfuscating cardholder data. However since obfuscation is expected of the payment application itself, we did not consider it to be a serious shortcoming. Overall, out of 58 tested requirements, the product supports 57 (98%). Note: Users are advised to consult with their QSA regarding use and configuration of this product for compliance purposes. The security effectiveness of Deep Security was tested with 59 live exploits targeting a real Windows 2003 Server operating system and numerous applications, including IIS, Apache, DNS, sendmail, Exchange, Oracle DB, and various commonly used open source server applications. Deep Security detected and blocked a total of 59 exploits (100%) all of which were Attacker Initiated. We found this effectiveness to be extraordinary and beyond our usual expectations for product of this nature, It should be noted that NSS Labs does not test client/target Initiated attacks as part of its Host Intrusion Prevention methodology since most HIPS products are designed to protect servers, and most servers run client applications very infrequently if at all (i.e. Apple QuickTime, Adobe Acrobat, MS Word, and Internet Explorer). Deep Security is separated into two components: Deep Security Agent, which is installed on the protected server, and Deep Security Manager, a Web UI Client that is installed on a dedicated management server. Deep Security Manager provides a quick and easy means to manage a Deep Security Agent, offering a straightforward way to configure the HIPS, view alerts, and so on. Alert handling especially real-time alert handling is powerful and flexible. In our opinion, Third Brigade s Deep Security is a capable Host Intrusion Prevention System, and should be on any short list as a candidate for deployment in the Corporate Perimeter, E-Commerce Datacenter, Internal Datacenter environment, or on Windows Server 2003 back-end servers in Large Retail Storefronts.

4 Third Brigade Deep Security HIPS for Windows Server 2003 is suitable for use in: Internal / Core Datacenters, where there are complex communications between internal hosts. (i.e. RPC, SMB, NetBIOS, SNMP, Backup [VERITAS/EMC], Storage [iscsi/nfs], and various DB applications such as Oracle, SQL, MySQL, DB2) E-Commerce / Internet Datacenters, where there are internet facing services (i.e. HTTP, SMTP, IMAP, POP-3, and DNS, and Outlook Web Access) Corporate Perimeter Environments, where there are few hosted services (i.e. HTTP, SMTP, IMAP, POP-3, and DNS and Outlook Web Access) available to external users. Large Retail Storefronts (with Servers), where there are complex communications between Point of Sale Terminals and back-end Servers. (i.e. Samba, SNMP, Backup [VERITAS/EMC], Storage [iscsi/nfs], and various DB applications such as Oracle, MySQL)

5 CONTENTS 1 Introduction The Product Under Test Third Brigade Deep Security HIPS PCI Test Environment Testing HIPS HIPS test environment Results Summary About PCI DSS Functionality Validation Legend of results PCI DSS Requirements Validation Map Security Effectiveness NSS Test Methodologies Recommended Configurations Firewall Stateful Firewall (optional) Firewall Security Policy Strict Enforcement - Only Traffic Allowed By Policy Firewall Metadata Stateful Operation Restrict Outbound Traffic from PCI Systems Intrusion Prevention Protected Services Evasion and Obfuscation Resistance to False Positives Logging and Reporting HIPS Logging and Reporting Administrative Access Logging and Reporting updates and configuration changes Synchronization of System Clock Centralized Logging Over Secured Communications Channels Masking / Omission of Restricted Card Holder Data Updates Support secure, non-refutable updates Online Updates Offline Updates HIPS Frequent Updates... 26

6 9 Management & Administration PCI Default Configuration - No Default Usernames / Passwords Password Policy No Shared User Accounts Authentication Methods Secured Management Interface PCI Scanner Allow All Appendix A: Test Infrastructure... 30

7 1 INTRODUCTION In Q1 of 2008, NSS Labs performed comprehensive testing of the Third Brigade Deep Security against our Host Intrusion (HIPS) for PCI criteria. This report contains the conclusions and associated data from a series of exacting tests performed on a device installed in our real-world test lab. The NSS Labs Product Reports on Compliance for PCI are designed to address the challenges faced by IT departments in selecting security products to address the compliance requirements of the Payment Card Industry s Data Security Standard (PCI DSS). This NSS Labs report provides readers with empirically validated evidence about a product s suitability for use in a payment card network. Fulfillment of specific PCI DSS v1.1 requirements, including logging and reporting Recommended Configuration Details for PCI network deployment Security Effectiveness Appropriate Usage Recommendations Product Stability and Reliability The NSS Labs Product Reports on Compliance for PCI (HIPS) attests to the abilities of a HIPS product to serve as a: Host Intrusion Prevention System (HIPS) NSS Labs reports now implement the concept of Appropriate Usage (see NSS Labs whitepaper Evaluating Products based on Appropriate Usage ). Testing products based upon Appropriate Usage (applying a Use- Case based methodology) provides a clear picture of which security technologies are effective against a particular type of threat or attack. Thus, products can be evaluated based on their capabilities against specific deployment scenarios and protection requirements. Evaluated products are categorized for Retail Storefront, Corporate Perimeter, e-commerce Datacenter, and Internal/Core Datacenter environments. Third Brigade Deep Security HIPS PCI p. 1

8 2 THE PRODUCT UNDER TEST 2.1 THIRD BRIGADE DEEP SECURITY The Third Brigade Deep Security Host Intrusion Prevention (HIPS) product is a software package (agent + manager) that should be installed separately on two separate servers the agent on the server being protected, and the Manager on a server that will be used for Central Management. Third Brigade offers their Agent software for Windows, Linux, and Solaris. For the purpose of this report, we tested the Deep Security on Windows 2003 SP1 & SP2 Servers for both the agent & management station. Third Brigade positions their Deep Security HIPS for use on Servers throughout an organization. Third Brigade Deep Security is an advanced, host-based intrusion defense system that brings proven network security approaches, including firewall and intrusion detection and prevention, down to individual networked computers and devices. Third Brigade Deep Security consists of three main components: Deep Security Manager is a centralized management system that allows administrators to apply security profiles to hosts, and track threats and preventive actions taken in response to them. Detailed reports document attempted attacks, and provide an auditable history of security configurations and changes. Deep Security Agent is a small, host-based software component that includes a high performance deep packet inspection engine. The Agent defends the host by monitoring incoming and outgoing traffic for protocol deviations, content that signals an attack, or policy violations. When necessary, the Agent intervenes and neutralizes the threat by blocking the malicious traffic. Third Brigade Security Center provides information on the latest vulnerabilities, and security updates that shield these vulnerabilities and reduce risk. Third Brigade Deep Security HIPS PCI p. 2

9 3 HIPS PCI TEST ENVIRONMENT 3.1 TESTING HIPS The ultimate goal of any attack into a computer system is to gain access to a target host and attempt to perform an unauthorized action. The unauthorized action could be reading of a system file, accessing a memory location, execution of malicious code, or any number of other actions. Unauthorized access of this nature is considered an intrusion. Computer systems are designed with many levels of protection to prevent unauthorized access and grant authorized access. However, intruders may circumvent these levels of protection by targeting vulnerable services, invoking back door privilege escalation, or replacing key operating system files. Host Intrusion Prevention Systems (HIPS) are designed to protect against remote attacks through continuous monitoring of the network traffic and protected operating system / applications using a software agent installed on the host operating system. Given that most HIPS products are designed to protect servers and server applications, not PC clients / applications, NSS Labs tests HIPS products by attempting to compromise remotely accessible services such as HTTP, IMAP, POP-3, DNS, RPC, NetBIOS, Oracle-Net, and LSASS (using attacker-initiated exploits). HIPS products must properly identify and block exploit attempts and unauthorized system usage without impeding legitimate usage and legitimate network access. NSS Labs HIPS testing focuses on the ability of a HIPS to mitigate unauthorized system activities including: network exploits targeting vulnerable services, localized privilege escalation / root kits, unauthorized access to internal operating system resources, and modifications to key operating system files and configuration data; while processing legitimate applications and servicing legitimate network requests. First, baseline vulnerabilities & successful attacks are determined for each host to be protected using realworld exploits. Next, the target systems are restored to their pre-compromised state and the HIPS software is installed and configured. Then the target host/applications are re-validated to ensure that the HIPS software does not interfere or prohibit legitimate usage. Finally, the protected system is attacked with the successfully validated exploits that should now be mitigated or prohibited by the HIPS software. The overall effectiveness and system impact is then recorded and provided within this report. 3.2 HIPS TEST ENVIRONMENT NSS Labs tests HIPS products in a complex, real world configuration supporting several addressing models, inspection policies, protocols, and content types. HIPS s are tested in Internal/Core Datacenter, e- Commerce Datacenter, and Enterprise Perimeter (DMZ) environments: HTTP, SMTP, IMAP, POP-3, Exchange, and DNS servers protected in a Corporate Perimeter (DMZ) HTTP, SMTP, IMAP, POP-3, Exchange, DNS, and Application Servers protected in an e-commerce Datacenter Database, File & Print, data backup, and other Internal/Core Datacenter Services Third Brigade Deep Security HIPS PCI p. 3

10 4 RESULTS SUMMARY Support for PCI DSS requirements was well thought out and clearly part of a dedicated effort to empower customers. NSS Labs found that Deep Security successfully passed 19 DSS requirements, and supported 38 others indirectly. There was one (1) failure of an indirect requirement: obfuscating cardholder data. However since obfuscation is expected of the payment application itself, we did not consider it to be a serious shortcoming. Overall, out of 58 tested requirements, the product supports 57 (98%). Note: Users are advised to consult with their QSA regarding use and configuration of this product for compliance purposes. 4.1 ABOUT PCI DSS FUNCTIONALITY VALIDATION This section provides a summary overview of the PCI DSS v1.1 Requirements validated by NSS Labs evaluation of the product. The PCI DSS is both a broad and very prescriptive set of requirements which span product functionality, human and automated processes, and network architectures. The scope of NSS Labs product validation is limited to what can be evaluated in our test labs. NSS Labs evaluates and validates product capabilities. It should be noted that capable products can be implemented and configured in ways that do not meet DSS requirements. NSS Labs cannot and does not validate the implementations of the product at specific customer sites how it is configured, and where it is deployed. That level of compliance validation per organization is the sole purview of Qualified Security Assessors. Recognizing that products can support PCI DSS in different ways, NSS Labs has developed three distinct classes of validation to which it adheres in the evaluation process. Third Brigade Deep Security HIPS PCI p. 4

11 4.2 LEGEND OF RESULTS The following legend outlines the scoring criteria used by NSS Labs engineers when evaluating product functionality for support of DSS requirements. Validation Description & Interpretation The product has been validated to meet the objectives of the specified PCI DSS requirement. E.g. PCI DSS requirement 1.5: Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as port address translation (PAT) or network address translation (NAT). The product was designed in such a way that it supports procedures and processes called for within PCI DSS. * E.g. PCI DSS requirement 2.3: Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS (transport layer security) for web-based management and other non-console administrative access. NSS Test 9.5 validates that the HIPS tested is capable of enforcing this restriction on itself though a device of its type is not intended to enforce nor capable of enforcing this functionality on other devices and systems on the network. The product has been found to not adequately meet the objectives of the specified PCI DSS requirement. FAIL N/A E.g. PCI DSS requirement : Protect audit trail files from unauthorized modifications. Products that allow unauthorized modifications of log files would receive a fail. The requirement is neither directly nor indirectly applicable to the product. Most often used in the case of a direct procedural or policy requirement. E.g. DSS 2.1 Always change vendor-supplied defaults before installing a system on the network (for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts). Table 4.1 Third Brigade Deep Security HIPS PCI p. 5

12 4.3 PCI DSS REQUIREMENTS VALIDATION MAP The following chart depicts the /FAIL status of each test correlated to the associated PCI DSS section to which it applies. PCI DSS NSS TEST DESCRIPTION NSS TEST ID N/A 1.1 N/A N/A N/A N/A N/A Firewall Metadata N/A N/A N/A 1.2 Stateful Firewall Firewall Policy - Implicit Deny Firewall Policy - Explicit Allow Strict Enforcement - Only Traffic Allowed By Policy Stateful Firewall Stateful Inspection 5.5 N/A N/A N/A Restrict Outbound Traffic from PCI Systems 5.6 N/A N/A N/A Firewall Policy - Implicit Deny Stateful Firewall 5.1 N/A N/A N/A 1.4 Stateful Firewall 5.1 N/A N/A N/A Restrict Outbound Traffic from PCI Systems 5.6 N/A 1.5 N/A N/A N/A 2.1 N/A N/A N/A N/A N/A Third Brigade Deep Security HIPS PCI p. 6

13 PCI NSS DSS NSS TEST DESCRIPTION TEST ID * 2.2 PCI Default Configuration - No Default Usernames / Passwords 9.1 N/A N/A N/A * 2.3 Secured Management Interface 9.5 * 2.3 Separate Interface for Management * 2.3 Administrative Access on Trusted Interface N/A N/A N/A FAIL 3.4 Masking / Omission of Restricted Card Holder Data 7.6 N/A 3.3 N/A N/A N/A 4.1 N/A N/A 4.2 N/A 5.1 N/A N/A 5.2 * 6.1 Updates 8 * 6.1 Support Secure, Non-refutable Updates 8.1 * 6.1 Online Updates - Using Hosted Provider * 6.1 Online Updates - Not Susceptible to Man in the Middle Attacks * 6.1 Offline Updates Removable Media * 6.1 Offline Updates - Digitally Signed and Encrypted * 6.1 Frequent Updates 8.4 N/A N/A Third Brigade does appear to have application security capabilities; however they were not tested in this HIPS report. Third Brigade has submitted Deep Security to be tested in NSS Labs upcoming Technology Sector Report: WAF (available in Q3 2008) N/A 7.1 N/A N/A * 7.2 No Shared User Accounts 9.3 * 8.1 No Shared User Accounts 9.3 * 8.2 Password Policy 9.2 N/A Third Brigade Deep Security HIPS PCI p. 7

14 PCI DSS NSS TEST DESCRIPTION NSS TEST ID * 8.2 Authentication Methods Password, Token devices (e.g., 9.4 SecureID, certificates, or public key), or Biometrics * 8.4 Secured Management Interface 9.5 * 8.5 Password Policy Altering Case Password Policy No Consecutive Repeating Characters or * 8.5 Sequences * PCI Default Configuration - No Default Usernames / Passwords 9.1 N/A N/A N/A * No Shared User Accounts 9.3 * Password Policy Password Expiration 90 Day Max * Password Policy Password Length * Password Policy Enforces Non Alpha-Numeric * Password Policy No Repeat of Last Four Password N/A N/A N/A N/A 9 N/A N/A 10.1 Logging and Reporting 7 N/A N/A N/A * Administrative Access Logging and Reporting 7.2 * HIPS Logs - Resulting Action of the HIPS * HIPS Logs - Targeted Vulnerabilities Sorted by IP and Severity * HIPS Logs - Severity Levels Rated * HIPS Logs - Details for Each Vulnerability Found * HIPS Logs - Targeted Vulnerability Name * HIPS Logs - Severity Level * HIPS Logs - Comprehensive Explanation N/A N/A N/A Third Brigade Deep Security HIPS PCI p. 8

15 PCI NSS DSS NSS TEST DESCRIPTION TEST ID * Change Logs - User Identification * Change Logs - Type of Event * Change Logs - Date and Time * Change Logs - Success or Failure of an Action * Change Logs - Origination IP Address * Change Logs Resource Affected Updates and Configuration Changes Logging and Reporting Change Logs - User Identification HIPS Logs - Industry Reference Numbers Change Logs - Type of Event Change Logs - Date and Time Change Logs - Success or Failure of an Action Change Logs - Origination IP Address Change Logs Resource Affected Synchronization of System Clock Centralized Logging Over Secured Communications Channels N/A N/A N/A 10.6 HIPS Logging and Reporting 7.1 N/A 10.7 N/A N/A N/A 11.1 N/A N/A 11.2 PCI Scanner Allow All 9.6 N/A N/A N/A Intrusion Prevention Updates Third Brigade Deep Security HIPS PCI p. 9

16 PCI DSS NSS TEST DESCRIPTION NSS TEST ID N/A 11.5 N/A N/A N/A N/A * The HIPS tested is capable of enforcing this restriction on itself though a device of its type is not intended to enforce nor capable of enforcing this functionality on other devices and systems on the network. 4.4 SECURITY EFFECTIVENESS Below are results displayed in the terms of Attack Source and Attack Impact. Attack Source defines whether an attack was launched directly by an external attacker ( Attacker Initiated ) or erroneously initiated by an internal user sitting at their PC or workstation ( Target Initiated, aka Client Initiated). Attack Impact defines whether a successful attack would have compromised a service ( Service Exposure i.e. an application such as Adobe Acrobat or Oracle database) or compromised the entire system ( Systems Exposure i.e. root access). System or Service Fault impact would make unavailable a specific service/application on the target system or crash the entire system. The security effectiveness of Third Brigade s Deep Security was tested with live exploits and threats targeting a real Windows 2003 Server operating system and various server applications. It is important to note that the vendor was not aware in advance of the attacks selected for the test. The test results therefore reflect a very real-world scenario in which there is no ability to perform custom tuning for a lab environment. The test results therefore reflect a very real-world scenario in which there is no ability to perform custom tuning for a lab environment. This approach differs considerably from any other public testing methodology currently in existence. Each attack was verified to compromise a host in a number of ways prior to placing the device into the test harness. These tests were performed using Immunity s Canvas, Core Impact and Metasploit as well as an extensive test suite taken from the NSS exploit library consisting of thousands of live exploits developed by NSS and our vulnerability research partner Assurent ATTACK INITIATION Most servers run client applications very infrequently if at all (i.e. Apple QuickTime, Adobe Acrobat, MS Word, Internet Explorer, etc.). Therefore NSS Labs does not test client / Target Initiated exploits as part of its Host Intrusion Prevention methodology since most HIPS products are designed to protect servers, and not end user PC/Clients. Type Missed Tested Caught % Attacker Initiated % Target Initiated 0 0 0% TOTAL % N/A Third Brigade Deep Security HIPS PCI p. 10

17 In Attacker Initiated exploits the Deep Security caught 100% of System Exposure, 100% Service Exposure, and 100% of System and Service Faults, for an overall security effectiveness rating of 100%. We found this effectiveness to be extraordinary and beyond our usual expectations for product of this nature, although it should be noted that there are not yet many known exploits for this particular server platform, as reflected in the size of the test suite IMPACT TYPE NSS Labs evaluates and measures exploit severity using a number of methods. For the purposes of our reporting, we believe the impact type should reflect the resulting effect of an exploit rather than an arbitrary High, Medium or Low indication as is typically given by a system such as CVE. Such systems do not take into account the assets being protected, and therefore can lead to false estimations of severity. For example, a vulnerability labeled as LOW severity under CVE, could be of relatively HIGH importance if one has critical assets on that system. The most serious exploits were those which resulted in a remote system exposure (compromise), providing the attacker with the ability to execute arbitrary system level commands. Exploits in this class that are weaponized provide the attacker with a fully interactive remote shell on the target client or server. Third Brigade Deep Security proved to be very strong in this highly critical area, detecting 17 out of 17 (100%). Type Missed Tested Caught % System Exposure % Service Exposure % System or Service Fault % TOTAL % Slightly less serious are the attacks resulting in an individual service exposure (compromise) but not arbitrary system level command execution. Typical attacks in this category include service specific attacks such as SQL injection that enable the attacker to execute arbitrary SQL commands within the database service. These attacks are somewhat isolated to the service and do not immediately result in full system level access to the operating system and all services. However using additional localized system attacks it may be possible for the attacker to escalate from the service level to the system level. Of the 38 exploits in this category, Deep Security detected 38 (100%). Finally, there are the attacks which resulting in a system or service level fault that crashes the targeted service or application (or causes it to enter into a race condition) and which require administrative action to restart the service or reboot the system. These attacks do not enable the attacker to execute arbitrary commands. However the resulting impact to the business could be severe given that the attacker could crash the protected system or service. Of the 4 exploits in this category, Deep Security detected all attacks (100%). Third Brigade Deep Security HIPS PCI p. 11

18 It appears that Third Brigade s strategy of providing strong server protection for Windows 2003 Server and commonly used server applications has paid off. The overall security effectiveness of the Deep Security was tested with 59 live exploits targeting several real Windows 2003 operating systems running various server applications, including IIS, Apache, DNS, Exchange, Oracle DB, plus basic File & Print, and other standard Microsoft Windows services. Deep Security had an overall blocking and effectiveness rating of 100%. We noted some noise, with a few test cases raising multiple alerts for a single exploit. However, this can be attributed to multiple host-based protections detecting various elements of the exploits. Resistance to known evasion techniques was excellent, with Deep Security properly detecting exploits throughout our evasion tests. 4.5 TESTS PERFORMED BY NSS LABS The following chart depicts the /FAIL status of each NSS Labs test, correlated to the associated PCI DSS section to which it applies. Note that NSS Labs test ID s start with section 5 of this document. There is not always an applicable DSS reference for the test. These NSS Tests reflect recommended features of a product to be used in a payment card environment, and have been included as a best practice. RESULT NSS TEST ID TEST DESCRIPTION PCI DSS ID Firewall 5.1 Stateful Firewall Stateful Firewall Stateful Firewall Stateful Firewall 1.4 Firewall Security Policy Firewall Policy - Implicit Deny Firewall Policy - Implicit Deny Firewall Policy - Explicit Allow Strict Enforcement - Only Traffic Allowed By Policy Firewall Metadata Stateful Inspection Restrict Outbound Traffic from PCI Systems Restrict Outbound Traffic from PCI Systems Intrusion Prevention Third Brigade Deep Security HIPS PCI p. 12

19 RESULT NSS TEST ID TEST DESCRIPTION PCI DSS ID Intrusion Prevention 11.4 Logging and Reporting 7 Logging and Reporting HIPS Logging and Reporting 10.6 * HIPS Logs - Resulting Action of the HIPS * HIPS Logs - Targeted Vulnerabilities Sorted by IP and Severity * HIPS Logs - Severity Levels Rated * HIPS Logs - Details for Each Vulnerability Found * HIPS Logs - Targeted Vulnerability Name HIPS Logs - Industry Reference Numbers * HIPS Logs - Severity Level * HIPS Logs - Comprehensive Explanation * 7.2 Administrative Access Logging and Reporting * Change Logs - User Identification Change Logs - User Identification Updates and Configuration Changes Logging and Reporting 10.3 * Change Logs - Type of Event Change Logs - Type of Event * Change Logs - Date and Time Change Logs - Date and Time * Change Logs - Success or Failure of an Action Change Logs - Success or Failure of an Action * Change Logs - Origination IP Address Third Brigade Deep Security HIPS PCI p. 13

20 NSS TEST RESULT ID TEST DESCRIPTION PCI DSS ID Change Logs - Origination IP Address * Change Logs Resource Affected Change Logs Resource Affected Synchronization of System Clock Centralized Logging Over Secured Communications Channels 10.5 FAIL 7.6 Masking / Omission of Restricted Card Holder Data 3.4 Updates * 8 Updates Updates 11.4 * 8.1 Support Secure, Non-refutable Updates 6.1 * Online Updates - Using Hosted Provider 6.1 * Online Updates - Not Susceptible to Man in the Middle Attacks 6.1 * Offline Updates Removable Media 6.1 * Offline Updates - Digitally Signed and Encrypted 6.1 * 8.4 Frequent Updates Configuration * 9.1 PCI Default Configuration - No Default Usernames / Passwords 2.2 * 9.1 PCI Default Configuration - No Default Usernames / Passwords * 9.2 Password Policy 8.2 * Password Policy Password Length * Password Policy Enforces Non Alpha-Numeric * Password Policy Altering Case 8.5 * Password Policy No Consecutive Repeating Characters or 8.5 Sequences * Password Policy Password Expiration 90 Day Max Third Brigade Deep Security HIPS PCI p. 14

21 NSS TEST RESULT ID TEST DESCRIPTION PCI DSS ID * Password Policy No Repeat of Last Four Password * 9.3 No Shared User Accounts 7.2 * 9.3 No Shared User Accounts 8.1 * 9.3 No Shared User Accounts * 9.4 Authentication Methods Passwords, Token devices (e.g., 8.2 SecureID, certificates, or public key), or Biometrics * 9.5 Secured Management Interface 2.3 * 9.5 Secured Management Interface 8.4 * Separate Interface for Management 2.3 * Administrative Access on Trusted Interface PCI Scanner Allow All These tests are in addition to the PCI DSS and do not directly map to DSS Requirements Table RECOMMENDED CONFIGURATIONS Very few products, if any, are ready to be installed directly out of the box. Furthermore, PCI DSS calls for a number of specific settings and configurations to be implemented in order to support compliance. Identifying which settings are required is a non-trivial task, especially given the wide variety of product types, and the plethora of product manufacturers, each with a number of distinct product lines and products. Thus, enabling a specific setting can vary greatly across products and vendors. NSS Labs reports for PCI strive to simplify the process of configuring a product to support PCI compliance. Therefore, we have included recommended configuration settings in each report. These are presented in short-hand with the intention of guiding a knowledgeable administrator where to find the specific settings. These can either be validated or modified as needed. In the following sections, PCI Test Methodologies are listed with details of the tests performed and the result. The appropriate audit reference and steps to view/modify the recommended configuration are included in the right side of the table. Note: Due to the default manner in which Deep Security is provided to customers, there is very little documentation required to manage the HIPS in a manner consistent with PCI compliance. Third Brigade Deep Security HIPS PCI p. 15

22 5 FIREWALL This section verifies that the HIPS firewall module (optional) is stateful and is capable of operating in an explicit manner, whereby only actions that are explicitly defined are performed. Since a HIPS can only protect the host within which it is installed, NSS Labs methodology does not call for DMZ capabilities as that would not make sense. However, it does call for basic protection capabilities that would be expected of any firewall especially in a retail merchant or service provider (PCI) environment. 5.1 STATEFUL FIREWALL (OPTIONAL) The HIPS should support a stateful firewall and the ability to manage firewall policy. It is expected that the firewall component of a HIPS will be transparent to the network. Policy Tab 5.2 FIREWALL SECURITY POLICY Firewall security policies must enforce the fundamental premise of anything that is not explicitly allowed is denied. These tests verify the ability of the HIPS to manage access policies and properly enforce stateful traffic rules. For each test, protocol specific traffic is targeted at each physical interface verifying allow and deny policy effectiveness FIREWALL POLICY - IMPLICIT DENY The default rule for undefined network access should be deny any all. The HIPS must deny all other inbound and outbound traffic not specifically allowed. Policy Tab FIREWALL POLICY - EXPLICIT ALLOW The HIPS should support granular policy definitions based on source and destination IP addresses as well as TCP or UDP port values. Policy Tab 5.3 STRICT ENFORCEMENT - ONLY TRAFFIC ALLOWED BY POLICY The HIPS must not leak or pass traffic that not been explicitly allowed by policy. Policy Tab STRICT ENFORCEMENT BLOCK TRAFFIC NOT SPECIFICALLY ALLOWED Network access must be blocked for any network traffic that has not been specifically allowed by policy. * Third Brigade Deep Security HIPS PCI p. 16

23 5.3.2 STRICT ENFORCEMENT - FAIL CLOSED DURING REBOOT/SYSTEM CRASH The policy must remain in effect or block all network access during a reboot or system failure event. * Testing confirmed that traffic would not flow to applications/services firewalled by the HIPS during reboot or system failure. The firewall started before other applications. 5.4 FIREWALL METADATA The HIPS should provide a description field for groups, roles, and responsibilities for logical management of network components. HIPS Agents can be administered centrally using management console 5.5 STATEFUL OPERATION The Firewall must implement stateful inspection and only allow established connections. The HIPS should provide stateful protocol support for HTTP, HTTPS/SSL, SMTP, SSH, and IPSec VPN. Testing confirmed that stateless traffic was not allowed by the HIPS 5.6 RESTRICT OUTBOUND TRAFFIC FROM PCI SYSTEMS Restrict outbound traffic from payment card applications to explicitly defined IP addresses This assumes that the payment card application is housed within the host being protected by the HIPS Third Brigade Deep Security HIPS PCI p. 17

24 6 INTRUSION PREVENTION This section verifies that the HIPS intrusion prevention module is capable of detecting and blocking a wide range of common exploits accurately, whilst remaining resistant to false positives. The latest signature pack is acquired from the vendor, and the HIPS is deployed with the DEFAULT SECURITY POLICY or RECOMMENDED SETTINGS only, based on the target Appropriate Usage environment. Although intrusion detection systems operate in detection only mode, a HIPS is required to block and log exploit attempts and hostile traffic. Basic Denial of Service attacks should also be blocked. However Distributed Denial of Service attacks are left to the dedicated NSS Attack Mitigator testing track. Attackers are becoming increasingly sophisticated and HIPS must decode and intercept common evasion techniques. A HIPS that cannot detect attacks subjected to the following script kiddie evasion techniques is easily bypassed: Packet Fragmentation Basic IP fragmentation evasion techniques. TCP Stream Segmentation Basic TCP segmentation evasion techniques. URL Obfuscation HTTP attacks applying various levels of URL obfuscation. For each of the evasion techniques the success or fail of the exploit against the target vulnerability is noted. Also noted is the signature or alert that triggered during the attack. The HIPS signature engine should decode all obfuscation techniques to identify and block the base exploit instead of blocking based on anomalous traffic. It should be noted that NSS Labs does not test target/client initiated attacks as part of its Host Intrusion Prevention methodology since most HIPS products are designed to protect servers from external attacks. In addition, most servers run client applications very infrequently if at all (i.e. Apple QuickTime, Adobe Acrobat, MS Word, and Internet Explorer), and client protection will be fully tested in NSS Labs upcoming Endpoint Security methodology. REAL EXPLOIT LIBRARY & REAL TARGETS While it is not possible to validate the entire signature set of any HIPS, NSS Labs testing regime provides a demonstration of effectiveness for the HIPS to protect vulnerable assets from targeted threats and exploitation. Our threat and attack suite contains thousands of real, publically available exploits (including multiple variants of each exploit) from which we will carefully select groups of exploits to test based on Appropriate Usage. (see NSS Labs whitepaper Evaluating Products Based on Appropriate Usage) Each exploit has been validated to impact the target vulnerable host(s). This asset/target + threat based approach forms the basis from which HIPS security effectiveness is measured. Third Brigade Deep Security HIPS PCI p. 18

25 Attacker Initiated Client/Target Initiated Retail Storefront Corporate Perimeter E-Commerce Datacenter Internal/Core Datacenter HIPS are expected to protect both internal and Internet based services, and are tested using Attacker Initiated exploits. Given that most Retail Storefronts do not have web servers, mail servers, etc., NSS Labs tests Retail Storefront protection utilizing target initiated exploits (such those targeting web browsers). Following the same reasoning, NSS Labs assumes Internal/Core Datacenters are primarily servers running File/Print, Database, and ERP/CRM applications, and e-commerce environments are primarily servers running internet services (such as HTTP, SMTP, IMAP, POP-3, DNS, FTP, etc.) Therefore, NSS Labs tests both Internal/Core Datacenter protection and E-Commerce Datacenter protection utilizing attacker initiated exploits. Similarly, Corporate Perimeters likely have both Internet servers in a DMZ, and end users running client applications from the internal network but not Internal/Core file & print, Database, or ERP/CRM applications. 6.1 PROTECTED SERVICES The HIPS must detect and prevent attacks which are classified as basic attacks to publicly available services hosed in the Internal/Core or e-commerce and Corporate Perimeter DMZ. Basic attacks are defined as exploit frameworks or scripts that are publicly available and can be executed with limited exploit knowledge. The HIPS should protect both Internal/Core and commonly used DMZ services OPERATING SYSTEMS The HIPS must be capable of protecting against threats to common operating systems (AIX, BSD variants, Linux, Sun Solaris, and Microsoft Windows). Third Brigade Deep Security was tested on Windows 2003 Servers only. Please see separate reports on Deep Security for Solaris and Linux platforms both of which are in the process of being tested at this time DMZ - WEB SERVERS The HIPS must be capable of protecting against threats to common web server software (Apache, Lotus Domino, Microsoft IIS, Sun One). Third Brigade Deep Security HIPS PCI p. 19

26 6.1.3 WEB APPLICATION SERVERS The HIPS must be capable of protecting against threats to common web application server software (BEA Weblogic Server, IBM Websphere, Apache Jakarta Tomcat, JBOSS). Applicable for HIPS in ecommerce environments MAIL SERVERS The HIPS must be capable of protecting against threats to common mail server software (Lotus Domino, Microsoft Exchange, Netscape Messaging Server, Sendmail). Applicable for HIPS in e-commerce and Corporate Perimeter environments COMMON DMZ SERVICES The HIPS must be capable of protecting against threats to common DMZ services (HTTP, SMTP, SSH, DNS, IMAP, POP-3, etc.) 6.2 EVASION AND OBFUSCATION The HIPS should detect and resist evasion and obfuscation methods aimed at bypassing functionality EVASION AND OBFUSCATION DETECT ALTERNATIVE CHARACTER SETS The HIPS should detect the use of alternative character sets such as insertion of the delete character to mask true intent of the URL string EVASION AND OBFUSCATION - TCP FRAGMENTATION The HIPS should demonstrate that it is able to accurately reassemble fragmented attacks. This was confirmed by fragmenting attacks and confirming said attacks were correctly detected and blocked by the HIPS EVASION AND OBFUSCATION - URL OBFUSCATION The HIPS should detect the use of alternative character sets such as insertion of the delete character to mask true intent of the URL string. The HIPS was able to detect Unicode attacks Third Brigade Deep Security HIPS PCI p. 20

27 6.3 RESISTANCE TO FALSE POSITIVES The HIPS must be resistant to false positives FALSE POSITIVES - BENIGN TRAFFIC PROPERLY IDENTIFIED The HIPS must demonstrate that it does not falsely identify traffic which is benign as dangerous traffic. The HIPS had reasonably good resistance to positives. The HIPS appeared to have queried the OS for resident applications and defined protection accordingly. This was surprisingly efficient FALSE POSITIVES - NOT BLOCK LEGITIMATE TRAFFIC The HIPS must not inappropriately block legitimate traffic. The HIPS was able to identify legitimate traffic Third Brigade Deep Security HIPS PCI p. 21

28 7 LOGGING AND REPORTING 7.1 HIPS LOGGING AND REPORTING For any traffic identified as possible intrusion attempts into protected systems the HIPS must log the pertinent data HIPS LOGS - RESULTING ACTION OF THE HIPS The HIPS must log the resulting action of the HIPS (block traffic, drop connection, blacklist source IP address) HIPS LOGS - TARGETED VULNERABILITIES SORTED BY IP AND SEVERITY The HIPS must log the targeted vulnerabilities sorted by IP address and severity, with the most critical vulnerabilities listed first HIPS LOGS - SEVERITY LEVELS RATED Severity levels should be rated in accordance with the NIST CVSS standards and have a CVSS value assigned HIPS LOGS - DETAILS FOR EACH VULNERABILITY FOUND The HIPS must log the details of each vulnerability found HIPS LOGS - TARGETED VULNERABILITY NAME The HIPS must log the targeted vulnerability name HIPS LOGS - INDUSTRY REFERENCE NUMBERS The HIPS must log the industry reference numbers such as CVSS, CVE, CAN, or Bugtraq ID. Third Brigade Deep Security HIPS PCI p. 22

29 7.1.7 HIPS LOGS - SEVERITY LEVEL The HIPS must log the severity level of the event HIPS LOGS - COMPREHENSIVE EXPLANATION The HIPS must log a comprehensive explanation of the event. 7.2 ADMINISTRATIVE ACCESS LOGGING AND REPORTING The HIPS must log all actions by users with administrative privileges including modifications to any system or application logs. SUPPORT Deep Security Manager is required to manage a Deep Security Agent. The Deep Security Manager software provides a detailed audit trail capability. 7.3 UPDATES AND CONFIGURATION CHANGES All updates and configuration changes to the HIPS must be logged CHANGE LOGS - USER IDENTIFICATION The HIPS must log the identity of the user who caused the event. SUPPORT Administrators must perform all policy administration through Deep Security Manager, which provides this capability CHANGE LOGS - TYPE OF EVENT The HIPS must log the type of event. SUPPORT Administrators must perform all policy administration through Deep Security Manager, which provides this capability CHANGE LOGS - DATE AND TIME The HIPS must log the date and time of the event. Administrators must perform all policy administration through Deep Security Manager, which provides this capability CHANGE LOGS - SUCCESS OR FAILURE OF AN ACTION The HIPS must log the success or failure of the action. Third Brigade Deep Security HIPS PCI p. 23

30 Administrators must perform all policy administration through Deep Security Manager, which provides this capability CHANGE LOGS - ORIGINATION IP ADDRESS The HIPS must log the source IP address of the event. Administrators must perform all policy administration through Deep Security Manager, which provides this capability CHANGE LOGS RESOURCE AFFECTED The HIPS must log the resource affected by the event. Administrators must perform all policy administration through Deep Security Manager, which provides this capability 7.4 SYNCHRONIZATION OF SYSTEM CLOCK The HIPS must support the synchronization of system clock to facilitate accurate log entries. This is performed through Windows Time Management, and must be performed on both the server with the HIPS Agent and the HIPS Management Console 7.5 CENTRALIZED LOGGING OVER SECURED COMMUNICATIONS CHANNELS The HIPS must support centralized logging over secured communications channels. Logging from Deep Security Agent to Deep Security Manager is done securely using digital signatures & an encrypted channel 7.6 MASKING / OMISSION OF RESTRICTED CARD HOLDER DATA The HIPS should support the masking / omission of restricted card holder data (e.g. PAN) from logs. FAIL Deep Security does not support this capability. This should, however be supported by the payment card application which the HIPS is protecting Third Brigade Deep Security HIPS PCI p. 24

31 8 UPDATES 8.1 SUPPORT SECURE, NON-REFUTABLE UPDATES Must support secure, non-refutable updates such as firmware, software, signature, or database updating. Updates are secured by a digital signature. If the update is not signed by Third Brigade, the update will not work. Furthermore, updates between Deep Security Manager and Deep Security Agent utilize digital signatures so that only updates provided by authenticated Deep Security Manager were accepted. 8.2 ONLINE UPDATES ONLINE UPDATES - USING HOSTED PROVIDER Online updates using a hosted provider Testing confirmed that the Deep Security Manager connected to Third Brigade hosted update site for system updates ONLINE UPDATES NOT SUSCEPTIBLE TO MAN IN THE MIDDLE ATTACKS Online updates must not be susceptible to man in the middle attacks. Updates are secured by a digital signature. If the update is not signed by Third Brigade, the update will not work. Furthermore, updates between Deep Security Manager and Deep Security Agent utilize digital signatures so that only updates provided by authenticated Deep Security Manager were accepted. 8.3 OFFLINE UPDATES OFFLINE UPDATES REMOVABLE MEDIA Offline updates using removable media or localized network connection. It is possible to update Deep Security Manager manually/offline, but the update must contain a digital signature from Third Brigade. Deep Security Agent requires a properly authenticated (via digital signature) connection to Deep Security Manager to receive updates OFFLINE UPDATES - DIGITALLY SIGNED AND ENCRYPTED Offline updates must be digitally signed and encrypted. It is possible to update Deep Security Manager manually/offline, but the update must contain a digital signature from Third Brigade. Deep Security Agent requires a Third Brigade Deep Security HIPS PCI p. 25

32 properly authenticated (via digital signature) connection to Deep Security Manager to receive updates. 8.4 HIPS FREQUENT UPDATES HIPS should support frequent updates to remain current to evolving public Internet threats. Third Brigade Deep Security HIPS PCI p. 26

33 9 MANAGEMENT & ADMINISTRATION 9.1 PCI DEFAULT CONFIGURATION - NO DEFAULT USERNAMES / WORDS Upon initial setup of the HIPS, the administrator should be forced to change the default administrative user parameters and password. Deep Security Manager requires unique username and strong authentication (Uppercase, Lowercase + Special Character) 9.2 WORD POLICY The HIPS must support the enforcement of password policies. Use of Passwords is enforced by Deep Security Manager WORD POLICY WORD LENGTH The HIPS must require users to create new passwords with a minimum length of seven characters. Deep Security Manager requires unique username and strong authentication (Uppercase, Lowercase + Special Character) WORD POLICY ENFORCES NON ALPHA-NUMERIC The HIPS must require users to create new passwords containing non alpha-numeric characters. Deep Security Manager requires unique username and strong authentication (Uppercase, Lowercase + Special Character) WORD POLICY ALTERING CASE The HIPS must require users to create new passwords which include both UPPERCASE and lowercase letters. Deep Security Manager requires unique username and strong authentication (Uppercase, Lowercase + Special Character) WORD POLICY NO CONSECUTIVE REPEATING CHARACTERS OR SEQUENCES The HIPS must prevent users from creating passwords containing repeated or sequential characters (i.e or 1234.) Deep Security Manager requires unique username and strong authentication Third Brigade Deep Security HIPS PCI p. 27