Network segmentation of, or isolating (segmenting), the cardholder data environment from the remainder of an entity’s network is not a PCI DSS requirement. However, it is strongly recommended as a method that reduces the following:-:
- The scope of the PCI DSS assessment
- The cost of the PCI DSS assessment
- The cost and difficulty of implementing and maintaining PCI DSS controls
- The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations)
Without adequate network segmentation (sometimes called a "flat network") the entire network is in scope of the PCI DSS assessment. Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to a particular segment of a network. To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.
ProCheckup utilises appropriately qualified infrastructure testers working in partnership with QSA to ensure that the requirements of PCI DSS are met.
ProCheckUp utilises a standard engagement model for all Network Segmentation Test engagements using a robust, holistic approach consisting of a number of phases as defined below: -
Firewall rules should be as restrictive as possible, only allowing access to specific hosts and services from specific hosts. Sometimes this will require a network to access a specific server service (in the case of a corporate email system) or any address to access a specific server service (in the case of a public web server).
Other things a ProCheckUp consultant may look to identify are missing controls, access to management services, access from Terminal Servers and access to clear-text protocol services, such as FTP or Telnet.
ProCheckUp use a two stage method to assess firewall rules, firstly using automated tools and in-house scripts to look for common security weaknesses and best practice oversights. Secondly, a ProCheckUp consultant will manually read through each rule to ensure that a thorough assessment has conducted.
Automated Firewall Assessment
Prior to the start of the assessment, ProCheckUp will request that the client provide the firewall rules included in the agreed scope of the test; this should be in the form of a flat text file which is extracted from the device’s running configuration file. Upon request from the client, ProCheckUp can normally provide guidance on how to extract this file from their firewall.
This text file will then be parsed through numerous automated tools and in-house scripts looking for security weakness and vulnerabilities; an automated audit conducted in this manner will perform a more comprehensive assessment than a purely manual approach, especially with large and complex rule sets that make use of object groups. The automated auditing tools employed by ProCheckUp are less likely to miss issues, such as duplicate and contradicting rules, than if tests were conducted through purely manual efforts.
It should be noted that for CheckPoint devices that manage large networks, getting the configuration file from the firewall module, rather than the management module, will enable ProCheckUp to audit that specific set of firewall rules only.
When a firewall rule is assessed it may be contrary to standard industry best practice and the consultant may identify it as a critical issue. However, there may be a perfectly valid business reason why the rule is configured in that manner. This is a common issue when the consultant does not understand the wider architecture of the environment and, thus, does not understand the context in which the rule has been applied. To try and reduce these false positives, ProCheckUp will often request that the firewall administrator be available to answer any questions the consultant may have during the engagement, either locally if the test is being conducted on-site, or remotely, with contact details provided in the case of remote testing.
Manual Firewall Assessment
A ProCheckUp consultant will manually read through the firewall rules provided by the client looking for issues and vulnerabilities which the automated tools may have missed, thus providing a high level of assurance to the client that their boundaries are presenting a suitably strong security posture.
Common checks which a ProCheckUp security consultant may conduct could include (but are not limited to):-
- Checking for rules that allow access to ‘any’ (or a range of) destination service(s).
- Checking for rules that allow access to ‘any’ (or a range/network of) destination address(es)
- Checking for rules that allow access from ‘any’ (or a range/network of) source addresses.
- Check that the traffic is denied if no rules match (this is not always the default action).
- Check the device operating system version.
- Check the device’s logging settings (and logging to external host).
- Check Administration services (Telnet, SNMP, SSH version 1).
- Check Authentication passwords (including any authentication keys).
- Check Login banners.
- Check Routing configuration (RIPv1 etc.).
- Check Protocol Analysis/IDS functionality.
- Check VPN configuration (encryption strength etc.).
It should be noted that some devices make use of ‘NOT EQUAL’, ‘LESS THAN’, ‘GREATER THAN’ etc. This means that a rule may be configured to permit traffic from a specific source to a destination that is not equal to a specific object (potentially allowing significant access). Such confusing rules often lead to unintended oversights which expose an environment to significant weaknesses.
The final stage of the manual assessment will look at configuration checks. Firewall devices will often include other facilities, such as management services, routing protocols, protocol analysis, IDS, VPN and so on. Other checklists may provide checks for specific services such as VPN. Any specific concerns the client may have should be communicated to the ProCheckUp consultant prior to the test commencing.
During this phase of testing the Consultant will attempt to access devices outside the CDE using a variety of protocols techniques and original thinking.
Also the Consultant will attempt to access devices within the CDE from adjacent networks using a variety of protocols techniques and original thinking.
The purpose of this is two-fold :
1.) To establish whether a breach of the surrounding infrastructure would impact the CDE and ensure proper segregation in relation to the guidance of the PCISSC.
2.) To ensure that an attacker that has breached the CDE cannot exfiltrate data outside of the CDE