Document Comparison
Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf
→
Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf
97% similar
26 → 26
Pages
7427 → 7514
Words
40
Content Changes
Content Changes
40 content changes. 7 administrative changes (dates, page numbers) hidden.
Added
p. 2
May 2017 1.1 Correction of minor typographical errors, minor clarification to wording (with added footnote) in Section 3, and correction of errors in the Scenario 1 and Scenario 2 Logical Data Flow diagrams (in the legend, and diagram and legend, respectively).
5, 10, 11, 17, 22 Information Supplement
5, 10, 11, 17, 22 Information Supplement
Added
p. 7
• 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 cost of the PCI DSS assessment
• The cost and difficulty of implementing and maintaining PCI DSS controls
Added
p. 11
FIGURE 1
• PCI DSS Scoping Categories In this approach, system components can be categorized into only one of these categories. These categories 8 SAQ-eligible entities meeting all criteria for a particular SAQ may consider the applicable requirements to be those identified within that SAQ.
• System component stores, processes, or transmits CHD/SAD. OR
• for example, a web redirection server or name resolution server. OR
• PCI DSS Scoping Categories In this approach, system components can be categorized into only one of these categories. These categories 8 SAQ-eligible entities meeting all criteria for a particular SAQ may consider the applicable requirements to be those identified within that SAQ.
• System component stores, processes, or transmits CHD/SAD. OR
• for example, a web redirection server or name resolution server. OR
Added
p. 13
• System component does NOT store, process, or transmit CHD/SAD. AND
Modified
p. 4
Just because a system is not in scope for PCI DSS it doesn’t mean the entity should leave that system unprotected, as it could still pose a risk to the entity’s network and business. A common pattern seen in data breaches is where the attacker targets systems deemed by the entity to be out-of-scope for PCI DSS, then leverages those systems to gain access to more systems, which eventually provide a path to systems where CHD data can be found. …
Just because a system is not in scope for PCI DSS it does not mean the entity should leave that system unprotected, as it could still pose a risk to the entity’s network and business. A common pattern seen in data breaches is where the attacker targets systems deemed by the entity to be out-of-scope for PCI DSS, then leverages those systems to gain access to more systems, which eventually provide a path to systems where CHD data can be …
Modified
p. 5
Ultimately each entity is responsible for making its own PCI DSS scoping decisions, designing effective segmentation (if used), and ensuring its own
Ultimately each entity is responsible for making its own PCI DSS scoping decisions, designing effective segmentation (if used), and ensuring its own PCI DSS compliance and related validation requirements are met. Following this guidance does not guarantee that effective segmentation has been implemented, nor does it guarantee compliance with PCI DSS.
Modified
p. 6
The principals of scoping and segmentation are outlined in the “Scope of PCI DSS Requirements” section of the PCI DSS. Some excerpts from this section are provided below with additional guidance.
The principles of scoping and segmentation are outlined in the “Scope of PCI DSS Requirements” section of the PCI DSS. Some excerpts from this section are provided below with additional guidance.
Modified
p. 6
Scope of PCI DSS Requirements The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data.1 An organization’s CDE is only the starting point to determine the overall PCI DSS scope. Accurate PCI DSS scoping involves critically evaluating the CDE and CHD flows, as well as all connected-to and …
Scope of PCI DSS Requirements The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data.0F1 An organization’s CDE is only the starting point to determine the overall PCI DSS scope. Accurate PCI DSS scoping involves critically evaluating the CDE and CHD flows, as well as all connected-to and …
Modified
p. 7
• 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.1F2 The intent of segmentation is to prevent out-of-scope systems from being able to communicate with systems in the CDE or impact the security of the CDE. Segmentation is typically achieved by technologies and process controls that enforce separation between the CDE and out-of-scope systems. …
Modified
p. 8
The existence of separate network segments alone does not automatically create PCI DSS segmentation.
The existence of separate network segments alone does not automatically create PCI DSS segmentation. Segmentation is achieved via purpose-built controls that specifically create and enforce separation and to prevent compromises originating from the out-of-scope network(s) from reaching CHD.
Modified
p. 8
Refer to PCI SSC Information Supplement: Third-Party Security Assurance3 for guidance on management third-party relationships.
Refer to PCI SSC Information Supplement: Third-Party Security Assurance2F3 for guidance on management third-party relationships.
Modified
p. 9
If network segmentation is in place and being used to reduce the scope of the PCI DSS assessment, the assessor must verify that the segmentation is adequate to reduce the scope of the assessment.5 All segmentation controls must also be penetration tested at least annually per PCI DSS Requirement 11.3.46, to ensure that controls in place continue to provide effective segmentation.
If network segmentation is in place and being used to reduce the scope of the PCI DSS assessment, the assessor must verify that the segmentation is adequate to reduce the scope of the assessment.4F5 All segmentation controls must also be penetration tested at least annually per PCI DSS Requirement 11.3.45F6, to ensure that controls in place continue to provide effective segmentation.
Modified
p. 10
2. Document all CHD flows, and identify the people, processes, and technologies involved in storing, processing, and/or transmitting of CHD. These people, processes, and technologies are all part of the CDE7.
2. Document all CHD flows, and identify the people, processes, and technologies involved in storing, processing, and/or transmitting of CHD. These people, processes, and technologies are all part of the CDE6F7.
Removed
p. 11
FIGURE 1
• PCI DSS Scoping Categories In this approach, system components can be categorized into only one of these categories. These categories are hierarchical, with CDE Systems as the highest category that should be considered first; if a system meets any criteria in CDE Systems, it is a CDE system regardless of whether it also meets a description for a lower The categories provided here are examples only, and illustrate one way to consider different components and the impact on PCI DSS scope. Entities can follow this approach or use another evaluation process, at their discretion. Use of these categories is not required.
• PCI DSS Scoping Categories In this approach, system components can be categorized into only one of these categories. These categories are hierarchical, with CDE Systems as the highest category that should be considered first; if a system meets any criteria in CDE Systems, it is a CDE system regardless of whether it also meets a description for a lower The categories provided here are examples only, and illustrate one way to consider different components and the impact on PCI DSS scope. Entities can follow this approach or use another evaluation process, at their discretion. Use of these categories is not required.
Modified
p. 11
Note that being in scope does not mean that all PCI DSS requirements apply to a given system component; the applicable PCI DSS requirements depend on the function and/or location of the system component.
Note that being in scope does not mean that all PCI DSS requirements apply to a given system component; the applicable PCI DSS requirements7F8 depend on the function and/or location of the system component.
Removed
p. 12
Must be evaluated against all
Must be evaluated against all
System component supports PCI DSS requirements, such as time servers and audit log storage servers.
Must be evaluated against all
System component supports PCI DSS requirements, such as time servers and audit log storage servers.
Modified
p. 12
Description Scope and Applicability CDE Systems System component stores, processes, or transmits CHD/SAD.
Description Scope and Applicability CDE Systems
Modified
p. 12
• System component is on the same network segment
•for example, in the same subnet or VLAN as system(s) that store, process, or transmit CHD/SAD.
•for example, in the same subnet or VLAN as system(s) that store, process, or transmit CHD/SAD.
Modified
p. 12
• Are in scope for PCI DSS.
Modified
p. 12
• Must be evaluated to determine the applicability of each PCI DSS9 requirement.
Modified
p. 12
• System component is on a different network (or subnet or VLAN), but can connect to or access the CDE (e.g., via internal network connectivity). OR
Modified
p. 12
• System component can connect to or access the CDE via another system
•for example, via connection to a jump server that provides access to the CDE). OR
•for example, via connection to a jump server that provides access to the CDE). OR
Modified
p. 12
• System component can impact configuration or security of the CDE, or how CHD/SAD is handled
Modified
p. 12
• System component provides security services to the CDE
•for example, network traffic filtering, patch distribution, or authentication management. OR
•for example, network traffic filtering, patch distribution, or authentication management. OR
Modified
p. 12
System component provides segmentation of the CDE from out-of-scope systems and networks•for example, firewalls configured to block traffic from untrusted networks.
• System component supports PCI DSS requirements, such as time servers and audit log storage servers. OR System component provides segmentation of the CDE from out-of-scope systems and networks
•for example, firewalls configured to block traffic from untrusted networks.
•for example, firewalls configured to block traffic from untrusted networks.
Modified
p. 12
• Are in scope for PCI DSS. Even where a connection is limited to specific ports or services on specific systems, those systems are included in scope to verify that the applicable security controls are in place.
Modified
p. 12
• Must be evaluated to determine the applicability of each PCI DSS8F9 requirement.
Modified
p. 12
• Must not provide an access path between CDE systems and out- of-scope systems.
Modified
p. 13
Description Scope and Applicability Out-of- scope Systems System component does NOT store, process, or transmit CHD/SAD.
Description Scope and Applicability Out-of- scope Systems
Modified
p. 13
• System component is NOT on the same network segment or in the same subnet or VLAN as systems that store, process, or transmit CHD. AND
Modified
p. 13
• System component cannot connect to or access any system in the CDE. AND
Modified
p. 13
• System component cannot gain access to the CDE nor impact a security control for CDE via an in-scope system. AND
Modified
p. 13
• System component does not meet any criteria described for connected-to or security-impacting systems, per above.
Modified
p. 13
• Are not in scope for PCI DSS; therefore PCI DSS controls are not required.
Modified
p. 13
• Have no access to any CDE system; if there is any access, then system is in scope.
Modified
p. 13
• Are considered untrusted (or “public”)
•there is no assurance they have been properly secured.
•there is no assurance they have been properly secured.
Modified
p. 13
• If on the same network (or subnet or VLAN) as, or otherwise has connectivity to, a connected-to or security impacting system, controls must be in place to prevent the out-of- scope system from gaining access to the CDE via the in- scope systems. These controls must be validated at least annually.
Modified
p. 15
• Are permitted only between designated systems, ports, services etc., and all other connection attempts are blocked.
Modified
p. 15
• Are limited by business need
•for example, connectivity between workstations and a Directory Server is limited to only network authentication traffic.
•for example, connectivity between workstations and a Directory Server is limited to only network authentication traffic.
Modified
p. 20
All the controls that apply to Example 1 also apply to this example, with the exception that administrative access to the CDE is permitted from a designated administrative workstation in the Corporate LAN. In addition to the controls defined above, the following segmentation principles are applicable to this example. (See Figures 4 and 5.) A “jumpbox” (Bastion host8) is installed in the Shared Services network.
All the controls that apply to Example 1 also apply to this example, with the exception that administrative access to the CDE is permitted from a designated administrative workstation in the Corporate LAN. In addition to the controls defined above, the following segmentation principles are applicable to this example. (See Figures 4 and 5.) A “jumpbox” (Bastion host9F10) is installed in the Shared Services network.