top of page
Avoid the Traps: What You Need to Know About PCI Requirement 1 (Part 3)

Auditing and Compliance

Avoid the Traps: What You Need to Know About PCI Requirement 1 (Part 3)

Matthew Pascucci

Matthew Pascucci

Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam.

Tags

Share this article

9/9/14

Published

So we’ve made it to the last part of our blog series on PCI 3.0 Requirement 1. The first two posts covered Requirement 1.1 (appropriate firewall and router configurations) and 1.2 (restrict connections between untrusted networks and any system components in the cardholder data environment) and in this final post we’ll discuss key requirements of Requirements 1.3 -1.5 and I’ll again give you my insight to help you understand the implications of these requirements and how to comply with them.


  • Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports (1.3.1.):

    • The DMZ is used to publish services such as HTTP and HTTPS to the internet and allow external entities to access these services. But the key point here is that you don’t need to open every port on the DMZ. This requirement verifies that a company has a DMZ implemented and that inbound activity is limited to only the required protocols and ports.

  • Limit inbound Internet traffic to IP addresses within the DMZ (1.3.2):

    • This is a similar requirement to 1.3.1, however instead of looking for protocols, the requirement focuses on the IPs that the protocol is able to access.  In this case, just because you might need HTTP open to a web server, doesn’t mean that all systems should have external port 80 open to inbound traffic.

  • Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment (1.3.3):

    • This requirement verifies that there isn’t unfiltered access, either going into the CDE or leaving it, which means that all traffic that traverses this network must pass through a firewall. All unwanted traffic should be blocked and all allowed traffic should be permitted based on an explicit source/destination/protocol. There should never be a time that someone can enter or leave the CDE without first being inspected by a firewall of some type.

  • Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network (1.3.4):

    • In an attempt to bypass your firewall, cyber attackers will try and spoof packets using the internal IP range of your network to make it look like the request originated internally. Enabling the IP spoofing feature on your firewall will help prevent these types of attacks.

  • Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet (1.3.5):

    • Similar to 1.3.3, this requirement assumes that you don’t have direct outbound access to the internet without a firewall. However in the event that a system has filtered egress access to the internet the QSA will want to understand why this access is needed, and whether there are controls in place to ensure that sensitive data cannot be transmitted outbound.

  • Implement stateful inspection, also known as dynamic packet filtering (1.3.6):

    • If you’re running a modern firewall this feature is most likely already configured by default. With stateful inspection, the firewall maintains a state table which includes all the connections that traverse the firewall, and it knows if there’s a valid response from the current connection. It is used to stop attackers from trying to trick a firewall into initiating a request that didn’t previously exist.

  • Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks (1.3.7):

    • Attackers are looking for your card holder database. Therefore, it shouldn’t be stored within the DMZ. The DMZ should be considered an untrusted network and segregated from the rest of the network. By having the database on the internal network provides another layer of protection against unwanted access. [Also see my suggestions for designing and securing you DMZ in my previous blog series: The Ideal Network Security Perimeter Design: Examining the DMZ

  • Do not disclose private IP addresses and routing information to unauthorized parties (1.3.8):

    • There should be methods in place to prevent your internal IP address scheme from being leaked outside your company. Attackers are looking for any information on how to breach your network, and giving them your internal address scheme is just one less thing they need to learn. You can stop this by using NAT, proxy servers, etc. to limit what can be seen from the outside.

  • Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network (1.4):

    • Mobile devices, such as laptops, that can connect to both the internal network and externally, should have a personal firewall configured with rules that prevent malicious software or attackers from communicating with the device. These firewalls need to be configured so that their rulebase can never be stopped or changed by anyone other than an administrator.

  • Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties (1.5):

    • There needs to be a unified policy regarding firewall maintenance including how maintenance procedures are performed, who has access to the firewall and when maintenance is scheduled.


Well, that’s it! Hopefully, my posts have given you a better insight into what is actually required in Requirement 1 and what you need to do to comply with it.

Related Articles

Azure Security Best Practices

Azure Security Best Practices

Cloud Security

Mar 19, 2023 · 2 min read

How to Implement a Security-as-Code Approach

How to Implement a Security-as-Code Approach

Cloud Security

Mar 19, 2023 · 2 min read

A secure VPC as the main pillar of cloud security

A secure VPC as the main pillar of cloud security

Cloud Security

Mar 19, 2023 · 2 min read

Speak to one of our experts

bottom of page