Behind every PCI requirement is an intent. Unfortunately the intent is almost always obscured by the level of detail and specificity within each requirements’ description and testing procedures. But it’s important to understand this concept or you’ll end up chasing rainbows.

The networking section (PCI DSS Section 1.X) is no exception, so before I can provide an above-and-beyond I have to provide a baseline.

The intent of Section 1 is basically four-fold (I’m ignoring personal firewalls and network diagrams for now):

1. Keep the bad guys out, especially from the Internet
2. Limit communication between trusted and un-trusted systems to what’s necessary for their business function
3. Limit ANY connectivity to/from in-scope systems to/from the Internet
4. Limit insecure protocols, or ensure that their use is both justified and the risk mitigated

The ONLY thing in PCI that you cannot compensate for is the retention of sensitive authentication data (SAD) post-authorisation, EVERYTHING else can replaced with other controls as long as the risk mitigated by the original control is not greater with the replacement control(s).

For example; you do not have a personal firewall running on administrator laptops. All you have to do here is restrict all connectivity to in-scope devices to a jump server / bastion host through which ALL administrative connections must pass (BTW, this works just as well for lack of 2-factor authentication too). Note: You’ll hear QSAs use the phrase; “above and beyond” here, but it’s the intent of the requirements that’s the overriding factor.

As long as you have met the intent of the above 4 bullet points, you have your baseline, all of the following therefore are above-and-beyond (AaB.):

1. A rule-set review more frequently than twice a year – Depending on your environment, having each rule owner (which should correspond to a data and/or business process owner) confirm that all rules are still required more than semi-annually is considered AaB. This would be especially effective if the network administrators could confirm the frequency of each rules’ use during that quarter.
   o
2. A business justification for every rule – PCI only says that you must limit inbound and outbound traffic; “to that which is necessary for the card holder data environment.”, and between ‘trusted’ and ‘un-trusted’ networks. Which means that not only can these justifications be done at the protocol level (and not at the individual IP level), but does NOT have to be in effect between trusted networks. Therefore, if you have the following in place, you have gone wayyyyy AaB:
   o
   i.    Business justification of ALL ingress and egress filtering, including that between trusted networks
   ii.   Filtering down to the IP level (not subnet blocks / services), but this can be EXTREMELY complex so a judgement call is required
   o
3. Automated confirmation of rule set accuracy – If both firewall rule sets AND the end systems were perfectly configured, there would be no ‘denies’ in the firewall logs except that which corresponds to changes in the environment (which should have a change control request next to it), or to things that should be investigated. This can work in both directions; system configuration validation and rule set validation, but a significant base-lining effort would need to be performed and maintained by Asset Management (see PCI – Going Beyond the Standard: Part 6, Asset Management).
   o
4. Review and baseline firewall / router traffic logs – The logging requirements in PCI refer to administrative connections to the network devices themselves, nothing in PCI says you must collect and retain traffic logs, therefore including these in your ‘daily review’ can be considered AaB. It will also be impossible to do 3. above if you don’t.
   o
5. Network devices capable of more than stateful pack inspection (SPI) – PCI only requires that the network devices in use are capable of SPI, which can be performed at layers lower down the OSI stack than todays’ devices are capable of performing. Therefore, a network device which also performs application layer filtering can be considered as AaB in all instances except where it would be required anyway (i.e. Requirement 6.6)

A recurring message throughout the next 12 blogs (which corresponds the DSSs’ 12 sections), is the need to read the requirements VERY carefully. Good security consultants will naturally make assumptions on a requirements’ intent based upon their perception of good practice, but PCI is a bare minimum standard, and quite often allows things that make little sense (daily review of log files for example).

Most of the above AaB points are easy to achieve, and by doing so you are building a portfolio of compensating controls which can be used in places where you cannot meet the DSS requirements language.

There will be many.