When Compliance Bites You In The Bum
Updated: May 24
No matter what industry security standard you are looking to apply to your organisation, is it important that you ensure that the controls are mitigating the risks to your business.
Take for instance, the PCI DSS controls for mitigating the wireless threats.
Often both businesses and Qualified Security Assessors (QSAs) might interpret these controls as being 'Not Applicable' (N/A) and, as a result, do not test to confirm that the business is effectively mitigating against this risk.
Is this a safe thing to be doing?
Let's take a look at some examples of the controls that could be deemed as being N/A:
1.2.3 Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.
11.1 Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis.
What is the harm of marking these as not being applicable controls?
1.2.3. We would hope that the business has implemented a perimeter firewall, to act as a gateway to filter the authorised from the unauthorised traffic (acting as a gateway filter). Therefore, even if you don't use wireless technologies, if an attacker was to set up a rogue wireless device just outside your environment, wouldn't it be prudent to ensure that your perimeter firewall has been configured to prohibit wireless access?
11.1. Marking this one as N/A always amazes me. If your business model does not rely on wireless technologies, wouldn't you want to test for the presence of rogue wireless devices? These could have been placed into your environment by one of your employees or could have been placed there, during a social engineering attack, to create a rogue access/egress point and thus compromising your environment.
The key to understanding the intent of the PCI DSS controls to mitigate identified risks is to ensure that you read the supporting guidance - right hand column from both the control (e.g. 1.2 and the Sub Control 1.2.3):
Always look at your compliance efforts from the view of the risks that you are trying to mitigate against and, therefore, by treating these controls as N/A you should ask yourself:
Without these controls, how am I mitigating the threat from rogue wireless access devices?
If you are self-assessing, apply careful consideration as to whether you really want to remove a mitigation control, for something that the PCI SSC have identified as being a known risk.
If you are required to undergo an annual formal QSA onsite evaluation, ensure that you challenge the QSA's decision to deem the controls as being N/A. At the end of the day, you may achieve that annual certification as being able to demonstrate that you have met the requirements of PCI DSS.
What value will that bring you, in the event of a N/A control being the opportunity for your attackers to compromise your environment and to undermine all your hard work?
Whichever industry security standard you decide to choose, they all provide effective baseline security to help you defend your organisation against opportunist attackers. However, please do not pay lip service to the intent and objectives of these controls, and do not be afraid to challenge the assessor's interpretation of the effectiveness of these controls.
Your assessor needs to work with you to ensure that your business operations are not only compliant but, additionally, are effective in reducing risk to within your company risk tolerances.
In regard to the applicability of the wireless controls, I am in complete agreement with the PCI Guru:
If there is ANY mention of wireless networking anywhere other than the requirements in 11.1, then 1.2.3 must NOT be marked as NA.
Despite the additional wireless guidance, provided by the PCI SSC almost 11 years ago, there still appears to be some confusion as to whether 1.2.3 & 11.1 should be deemed as applicable controls, in environments where no wireless technology is employed.
Hopefully, this will at last be cleared up with the release of PCI DSS v4.0.
In the meantime, please do not become one of those organisations who discover the applicability of a control through an attacker's ability to exploit these controls.