PCI DSS · Domain 1
Build and Maintain a Secure Network
About 20% of the exam
Twelve requirements, six goals
- Secure network
- requirements 1 and 2
- Protect account data
- requirements 3 and 4
- Vulnerability management
- requirements 5 and 6
- Strong access control
- requirements 7, 8 and 9
- Monitor and test
- requirements 10 and 11
- Security policy
- requirement 12
- Requirement 1
- install and maintain network security controls
- Requirement 2
- apply secure configurations everywhere
Version 4.0 renamed the second goal to protecting account data, which covers cardholder data and sensitive authentication data together
Scope basics
- CDE
- people, processes and technology handling data
- In scope
- stores, processes or transmits data
- Connected to
- systems that can reach the CDE
- Security impacting
- could affect the security of the CDE
- Out of scope
- isolated with no connectivity
- Confirmed
- at least once every twelve months
Key dates
- Version 4.0
- published in March 2022
- Version 3.2.1
- retired in March 2024
- Future dated items
- became mandatory in March 2025
- Version 4.0.1
- limited revision published in 2024
- Assessment version
- whichever is current at assessment
- Best practice period
- the window before a date bites
Requirement 1, network security controls
- Configuration standards defined and approved
- Rules reviewed at least every six months
- Inbound and outbound traffic restricted explicitly
- Deny all unless business justified
- Network diagrams kept current
- Data flow diagrams show cardholder data
- Wireless networks separated from the CDE
- No direct public access to the CDE
Version 4.0 renamed firewalls as network security controls so cloud security groups and virtual appliances plainly count
Requirement 2, secure configuration
- Vendor defaults changed before deployment
- Default accounts removed or disabled
- Configuration standards cover every system type
- Standards follow accepted hardening guidance
- Only necessary services and ports enabled
- Wireless defaults including keys changed
- Management access encrypted, never in clear text
- Inventory kept for all system components
Community strings, sample accounts and forgotten management ports are the classic version of unchanged defaults
Segmentation
- Not required, but it shrinks scope
- Must genuinely prevent CDE access
- Firewalls, access lists, cloud security groups
- Tested at least every twelve months
- Service providers test every six months
- Failed segmentation puts everything in scope
Scope reducing technology
- Tokenization
- replaces the number with a token
- Validated P2PE
- significantly reduces merchant scope
- Outsourcing
- shifts work, never accountability
- Hosted payment page
- reduces scope without removing it
- Redirect
- still in scope for scripts
Things always in scope
- Jump hosts reaching the CDE
- Security monitoring serving the CDE
- Directory services authenticating CDE users
- Hypervisors hosting any CDE workload
- Backup systems holding cardholder data
- Administrator laptops with CDE access
Wireless duties
- Scan quarterly for rogue access points
- Detect and alert on unauthorized devices
- Change wireless defaults before use
- Use strong wireless encryption
- Keep guest networks away from the CDE
Cloud and virtual environments
- Security groups act as network controls
- A shared hypervisor pulls neighbors into scope
- Serverless functions handling data are scoped
- API gateways sit inside the boundary
- Provider duties documented in a matrix
- The customer still owns configuration choices
Documentation this goal demands
- A current network diagram
- A cardholder data flow diagram
- Configuration standards per system type
- Business justification per allowed service
- Rule review records every six months
- Inventory of in scope components
Network mistakes assessors find
- Diagram older than the last migration
- An any to any rule left temporarily
- A test system bridging two zones
- Segmentation never retested after changes
- Default community strings still in place
- Management traffic sharing the user network
Establishing scope, step by step
- Find every payment channel
- Map cardholder data flows
- List systems storing, processing, transmitting
- Add connected and security impacting systems
- Design segmentation
- Test the segmentation
- Document and confirm annually
- Data discovery scans find forgotten stores
- Scope is the assessed entity responsibility
- Significant change triggers a fresh review
- Understated scope invalidates the whole assessment
Rapid recall: requirement numbers
- Requirement 1
- network security controls
- Requirement 2
- secure configurations
- Requirement 3
- protect stored account data
- Requirement 4
- encrypt data in transit
- Requirement 5
- protect against malicious software
- Requirement 6
- secure systems and software
- Requirement 7
- restrict access by need
- Requirement 8
- identify and authenticate users
- Requirement 9
- restrict physical access
- Requirement 10
- log and monitor access
- Requirement 11
- test security regularly
- Requirement 12
- policies and organizational programs
Terms to fix early
- CDE
- the cardholder data environment
- NSC
- a network security control
- DMZ
- buffer between internet and internal
- Significant change
- triggers scans, tests and review
- Segmentation
- isolation that keeps scope small
Reference strip: goals, scope, controls, testing, records
Goals
- Six goals, twelve requirements
- Network first, policy last
- Account data covers CHD and SAD
Scope
- Store, process or transmit
- Connected and security impacting count
- Confirmed every twelve months
Controls
- Deny by default, justify each rule
- Defaults changed before deployment
- Only needed services enabled
Testing
- Rule review every six months
- Segmentation tested annually
- Service providers test twice yearly
Records
- Network and data flow diagrams
- Configuration standards and inventory
- Business justification per service
Quick exam traps
- Trap: Segmentation is a mandatory PCI DSS requirement
- Trap: Outsourcing payments removes all PCI DSS obligations
- Trap: A system with no cardholder data on it is automatically out of scope
- Trap: Only physical firewalls count as network security controls
- Trap: Scope only needs reviewing when the assessor asks
- Trap: Rogue wireless scanning is only needed where wireless is deployed
- Trap: Version 3.2.1 remains a valid basis for a new assessment
cybercertprep.com · original revision sheet written from the public body of knowledge