REDSEAL NETWORKS SOLUTION BRIEF. Proactive Network Intelligence Solutions For PCI DSS Compliance

Transcription

1 REDSEAL NETWORKS SOLUTION BRIEF Proactive Network Intelligence Solutions For PCI DSS Compliance

2 Overview PCI DSS has become a global requirement for all entities handling cardholder data. A company processing, storing, or transmitting credit card numbers must be PCI DSS compliant or they risk losing the ability to process credit card payments. These companies are broken down into two distinct categories; Merchants are authorized acceptors of cards for the payment of goods and services. Service Providers are organizations that process, store, or transmit cardholder data on behalf of card members, merchants, or other service providers. Merchants and Service Providers are typically classified at different levels based on the number of annual transactions processed although this can differ depending on the credit card issuer. In general, Level 1 Merchants and Level 1 & 2 Service Providers submit the greatest number of transactions and therefore must validate compliance with an audit by a PCI DSS Qualified Security Assessor (QSA) Company. Level 2, 3, &4 Merchants and Level 3 Service Providers must complete an annual self-assessment questionnaire and quarterly network scans to prove compliance. Merchant and Service Providers are constantly at risk of losing cardholder information. Security incidents involving the loss of such data may result in fines, legal action and bad publicity. This in turn leads to loss of revenue and business disruption. Achieving compliance to the PCI Data Security Standard is a high priority for any organization carrying out business transactions involving the use of credit cards. How RedSeal Addresses the PCI DSS Policy Requirements RedSeal Network solutions help address the following PCI DSS requirements: PCI DSS Requirements Testing Procedure RedSeal Solutions for PCI DSS Requirements 1.1 Establish firewall and router configuration standards that include the following: A formal process for approving and testing all network connections and changes to the firewall and router configurations Current network diagram with all connections to cardholder data, including any wireless networks Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations a Verify that a current network diagram (for example, one that shows cardholder data flows over the network) exists and that it documents all connections to cardholder data, including any wireless networks b Verify that the diagram is kept current a Verify that firewall configuration standards include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone b Verify that the current network diagram is consistent with the firewall configuration RedSeal works with customers to help define and customize formal processes to incorporate testing, approval and documentation of business justifications for Layer 3 devices (firewalls, routers, load balancers) for all connections in and out of the PCI Cardholder Data Environment (CDE). RedSeal maintains a living network diagram by importing ALL Layer 3 devices and running complete analysis of end-to-end access on a daily basis providing complete visibility into security architecture of the Enterprise and CDE. Customers populate CDE locations into single a Zone to test and document all connections (Untrust, DMZ, Wireless, General) or data flows in and out of the CDE. The RedSeal network diagram is updated after each analysis. The network diagram can be exported to Visio and other formats, and is included in the RedSeal out-of-the box PCI Report. RedSeal continuously monitors and validates firewall placement between the DMZ and CDE by analyzing every data flow end to end to ensure a firewall is in the path. RedSeal continuously monitors the network diagram as built to documented business approvals and configuration standards using best practice checks that can be customized to the Customer environment and REDSEAL NETWORKS 2

3 1.1.5 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure. Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP Requirement to review firewall and router rule sets at least every six months 1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment. Note: An untrusted network is any network that is external to the networks belonging to the entity under review, and/ or which is out of the entity s ability to control or manage Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports Limit inbound Internet traffic to IP addresses within the DMZ Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment Do not allow internal addresses to pass from the Internet into the DMZ Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet a Verify that firewall and router configuration standards include a documented list of services, protocols and ports necessary for business for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols b Identify insecure services, protocols, and ports allowed; and verify they are necessary and that security features are documented and implemented by examining firewall and router configuration standards and settings for each service a Verify that firewall and router configuration standards require review of firewall and router rule sets at least every six months. 1.2 Examine firewall and router configurations to verify that connections are restricted between untrusted networks and system components in the cardholder data environment, as follows: a Verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented b Verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit deny all or an implicit deny after allow statement Verify that there are perimeter firewalls installed between any wireless networks and systems that store cardholder data, and that these firewalls deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. 1.3 Examine firewall and router configurations including but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment to determine that there is no direct access between the Internet and system components in the internal cardholder network segment, as detailed below Verify that a DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports Verify that inbound Internet traffic is limited to IP addresses within the DMZ Verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment Verify that internal addresses cannot pass from the Internet into the DMZ Verify that outbound traffic from the cardholder data environment to the Internet is explicitly authorized RedSeal provides Customer with detailed analysis of all Layer 3 traffic in and out of the CDE and the entire security architecture for the Enterprise. This enables Customers to document and incorporate business justified services, protocols, and ports allowed within the CDE into Customer Information Security Policies. The RedSeal analysis saves our Customers, and their QSAs, thousands of hours a year in manual analysis of firewall and router rule sets and is more comprehensive than the traditional sample size approach. RedSeal s continuous monitoring analyzes the Layer 3 (firewalls, routers, load balancers) on a daily basis and alerts system administrators of changes that may violate compliance. Business justifications documented in RedSeal can be set to expire on specific dates and force review and provide evidence of firewall and router rule set review completion. RedSeal identifies forbidden traffic flows and enables Customers to document and approve all business justified connections in and out of the CDE. RedSeal s analysis of the Layer 3 security architecture of the Enterprise identifies all possible inbound and outbound access and flags any access violating policy. RedSeal continuously monitors and validates firewall placement between the Wireless Zones and CDE by analyzing every data flow end-to-end to ensure a firewall is in the path. RedSeal continuously monitors, analyzes all access end-to-end (firewalls, routers, load balancers) and identifies if access is available directly between Untrusted (Internet) and the CDE. RedSeal s PCI Zones and Policies enables Customers to document their DMZ locations and approvals for authorized traffic. Continuous analysis of Layer 3 end-to-end access validates that the Customer maintains compliance and alerts the Customer if any change to a Layer 3 device violates PCI compliance. RedSeal s continous analysis of Layer 3 end-to-end access identifies any forbidden traffic flows from Internet into CDE and validates inbound Internet traffic is limited to the DMZ. RedSeal s continuous analysis of Layer 3 end-to-end access identifies any direct connection (inbound or outbound) for traffic between the Internet and the CDE. RedSeal PCI Policy validates anti-spoofing is enabled on DMZ firewalls. RedSeal s continuous analysis of Layer 3 end-to-end access identifies any direct connection (inbound or outbound) for traffic between the Internet and the CDE. REDSEAL NETWORKS 3

4 1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only established connections are allowed into the network.) Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks Do not disclose private IP addresses and routing information to unauthorized parties. 2.1 Always change vendor-supplied defaults before installing a system on the network, including but not limited to passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts. 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening Sources of industry-accepted system hardening standards may include, but are not limited to: Center for Internet Security (CIS) International Organization for Standardization (ISO) SysAdmin Audit Network Security (SANS) Institute National Institute of Standards Technology (NIST) Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc Configure system security parameters to prevent misuse Verify that the firewall performs stateful inspection (dynamic packet filtering). (Only established connections should be allowed in, and only if they are associated with a previously established session.) Verify that system components that store cardholder data are on an internal network zone, segregated from the DMZ and other untrusted networks a Verify that methods are in place to prevent the disclosure of private IP addresses and routing information from internal networks to the Internet. 2.1 Choose a sample of system components, and attempt to log on (with system administrator help) to the devices using default vendor-supplied accounts and passwords, to verify that default accounts and passwords have been changed. (Use vendor manuals and sources on the Internet to find vendorsupplied accounts/passwords.) 2.2.a Examine the organization s system configuration standards for all types of system components and verify the system configuration standards are consistent with industry-accepted hardening 2.2.c Verify that system configuration standards are applied when new systems are configured a For a sample of system components, inspect enabled system services, daemons, and protocols. Verify that only necessary services or protocols are enabled b Identify any enabled insecure services, daemons, or protocols. Verify they are justified and that security features are documented and implemented b Verify that common security parameter settings are included in the system configuration c For a sample of system components, verify that common security parameters are set appropriately. The RedSeal PCI Policy includes a verification check for firewalls required between the DMZ and CDE. The firewalls required check will only identify stateful devices. Utilizing RedSeal s Zones and Policies to identify DMZ locations, placing networks that contain cardholder data into the CDE Zone, Customers can continuously validate PCI scoping and segmentation of the CDE, DMZ and untrusted networks. Redseal PCI Policy includes verification that only RFC1918 address space is utilized in the DMZ. If registered or public IP addresses are used in the DMZ or CDE, a violation is noted in the PCI Policy and Report. Additionally, RedSeal provides analysis and output that identifies the Pre-IP/ PORT mapping to Post-IP/PORT across the entire Layer 3 environment documenting the devices and rule location of NAT mapping in the output for secondary validation of by the QSA. Device configurations are checked during import for violations of generally accepted best practices, such as unset or easy to break passwords. In addition to device-specific checks, several checks are also run against the network itself, looking for exposed access to the devices. RedSeal automatically checks all device configurations or a sample for such things as default passwords and enabled protocols that should be disabled. RedSeal s Best Practices Checks (BPCs) are tests that look for incorrect or undesirable conditions in the network device configurations imported into the RedSeal database. RedSeal has over 130 BPCs that identify insecure services and protocols on network devices such as firewalls, routers, load balancers, etc. to enable the hardening of network device configurations. The severities of the BPC violations are rated as High, Medium or Low risk. System administrators can create their own custom checks using input dialogs in the RedSeal user interface, or they can write their own XML files and import them into the RedSeal database using the file import mechanism. RedSeal s Best Practices Checks (BPCs) can report on new network devices and whether or not they comply with the required configuration when added to the model. Insecure conditions such as Telnet Enabled, or TFTP Enabled, for example, will be identified. A Report can be generated that lists the Best Practices failures for each device in a specified group of devices during a specified time period. RedSeal s Best Practices Checks (BPCs) can report on a sample of system components and whether or not they comply with the required configuration when added to the model. Insecure conditions such as Telnet Enabled, or TFTP Enabled, for example, will be identified. Reports can be generated that identify configuration issues by locating devices which fail Best Practices checks. A summary report of Best Practice Violations also tracks the network configuration management issues by check failure/remediation counts. A Best Practices failure report will be created for each newly detected incident; failure reports remain open in the data base until a newly updated device configuration - in which the condition has been corrected - has been imported into RedSeal For each Best Practice check, there is a block of descriptive text, which describes the conditions that will cause a device to fail the check, and a block of remediation text, which offers advice on how to avoid failing the check in the future. RedSeal can run a certain range of checks that would cover some or all of the requirements in the security standard. As an example, the common security checks for Cisco IOS include 33 common security parameters in addition to the ALL Platform and Network (non-device) checks; Best practice checks for network device platforms other than Cisco IOS include: Brocade Ironware, Checkpoint, F5 BIG-IP, Fortigate, Juniper JunOS / ScreenOS, Palo Alto Networks. RedSeal s BPC feature reports violations on network components when common security parameters are not set appropriately. Examples include the presence of Default Passwords, Default SNMP Community strings, or In-band Management Not Logged. Customers can also extend these checks with Custom BPCs. REDSEAL NETWORKS 4

5 6.1 Ensure that all system components and software are protected from known vulnerabilities by having the latest vendorsupplied security patches installed. Install critical security patches within one month of release. Note: An organization may consider applying a risk-based approach to prioritize their patch installations. For example, by prioritizing critical infrastructure (for example, public-facing devices and systems, databases) higher than less-critical internal devices, to ensure high-priority systems and devices are addressed within one month, and addressing less critical devices and systems within three months. 6.2 Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities. Notes: Risk rankings should be based on industry best practices. For example, criteria for ranking High risk vulnerabilities may include a CVSS base score of 4.0 or above, and/or a vendor-supplied patch classified by the vendor as critical, and/or a vulnerability affecting a critical system component. The ranking of vulnerabilities as defined in 6.2.a is considered a best practice until June 30, 2012, after which it becomes a requirement. 6.1.a For a sample of system components and related software, compare the list of security patches installed on each system to the most recent vendor security patch list, to verify that current vendor patches are installed. 6.2.b Verify that processes to identify new security vulnerabilities include using outside sources for security vulnerability information. RedSeal provides a risk ranking to vulnerabilities based on host exposure and downstream risk. Downstream Risk (DSR) is the sum of the RedSealcalculated risk scores of all hosts downstream (reachable either directly or indirectly and which could therefore be exposed to leapfroggable vulnerabilities from this host). DSR takes into account a threat vector only if it represents a primary threat source; if the target is equally or more exposed to the same threat from a different source (has an attack depth equal to or lower than the attack depth of the host for which DSR is being calculated), then the threat vector will not be used in the current DSR calculation. Within the RedSeal environment, a vulnerability is a specific Threat Reference Library (TRL) entry which defines a specific exploitable weakness. The RedSeal analysis engine will match these vulnerabilities to hosts based on the applications and services known to be in use on your network, identified by vulnerability scanner input. The RedSeal software can also infer vulnerabilities based on references to ports in network device configurations. The RedSeal approach to risk allows for the prioritization of vulnerabilities and remediation efforts based on the criticality to the network as a whole, and ensures that high-priority systems can be ranked for remediation efforts before low-priority systems. Everything the RedSeal system knows about individual security risks is contained in the Threat Reference Library (TRL). Entries in the TRL define individual vulnerabilities derived from the NVD (the U.S. federal government s vulnerability database, using industry standard CVSS scores, plus additional vulnerability information gathered by various third-party security providers and RedSeal Networks in-house security experts. Summary Through auditing, monitoring, reporting and proactive network intelligence based on all layer 3 devices, RedSeal s solution can help organizations address multiple sections in the 12 PCI requirements. RedSeal Networks solutions help organizations meet PCI DSS compliance requirements as part of a holistic approach to network security. By implementing proactive security intelligence solutions to ensure critical PCI asset protection, in addition to other security solutions (such as data encryption and two factor authentication), organizations will go a long way towards achieving compliance. About RedSeal Networks, Inc. RedSeal Networks is the leading provider of proactive enterprise security management solutions that enable organizations to continually assess and fortify their cyber-defenses while automating compliance. The RedSeal platform enables businesses and government agencies to simplify the modeling and analysis of complex network and security control interactions across the entire network of firewalls, routers, load balancers and hosts to better understand their security state and regulatory compliance, identify the inherent risk to their operations and critical assets, and drive actions that reduce the risks associated with associated with cybertheft and cyberespionage. For more information, visit RedSeal at RedSeal Networks, Inc Freedom Circle, Suite 800, Santa Clara, (888) info@redsealnetworks.com RedSeal Networks, Inc. All rights reserved. RedSeal and the RedSeal logo are trademarks of RedSeal Networks, Inc. RS-SB