Pushing The Limits

Here are some situations that QSAs encounter way too often.

• Organizations that conduct their annual penetration test 30 days before the deadline to file their self-assessment questionnaire (SAQ) or Report On Compliance (ROC).
• Organizations that conduct their final quarter vulnerability scan 30 days before the deadline to file their SAQ or ROC.
• Organizations that decide to implement a compensating control worksheet (CCW) within 30 days before the deadline to file their SAQ or ROC.

Why are these situations a problem?

For the first two conditions, it is because if any of these results in a remediation effort, you either (a) have to remediate the findings and retest before filing your SAQ/ROC or (b) you have to put compensating controls in place and test those to ensure you are mitigating the risk of not remediating. Both of these situations can easily result in missing an organization’s compliance filing date.

For any CCW, it is a problem because you need to test all of the controls you are using to compensate for not being able to comply with a requirement and prove they are functioning as designed. In a lot of cases, those controls are going to be new controls and will take time to implement and then test.

While this “fire drill” is going on, your QSA sits and waits for you to complete remediation or implement your compensating controls so that they can test things and ensure that you are in compliance. Unfortunately, while your QSA waits, the stress of getting things done accumulates and people lash out at the QSA for their organization’s poor planning with the expectation that the QSA will just look the other way.

As a QSA, I would really like to help you. But as the old adage goes, poor planning on your part does not create an emergency on my part. Unfortunately, clients never see it that way when they are trying to hit a deadline, but it is still true.

So the way to minimize these situations is to plan ahead. Make sure that your annual penetration test is conducted no later than the start of the fourth quarter of your reporting period. This will give you around 90 days to address any issues and retest. For vulnerability scanning, I would also highly recommend doing your final quarterly vulnerability scan no later than the start of the fourth quarter of your reporting period as well for the same reason. These both are particularly true if your organization has a history of not getting passing results.

For CCWs, you want your QSA to identify those as soon as possible so that you can work on getting the controls in place and functioning. As a result, you should schedule your assessment to start no later than the third quarter of your reporting period and as early in that quarter as possible. If your organization is large, you may even want to start in the second quarter of your reporting period.

If you have CCWs in place and you will keep them in place for your coming assessment, you should be conduct your own testing prior to your QSA arriving to make sure you can fix any out of compliance situations.

So before you chew off the head of your QSA for some self-inflicted wound, think about how you got into this predicament. Next year plan better and your assessment will likely go better.

Advertisement

Compensating Control Refresher

From time to time, organizations find themselves in the predicament of not being able to meet a PCI DSS requirement due to business or technical constraints. To address that situation, the PCI SSC has provided the compensating control worksheet (CCW) as a way to work around those requirements that cannot be met directly as stated in the PCI DSS. When the CCW was updated back in 2010 for v1.2, I wrote about those changes and how to write a CCW. However, here we are at v3.1, five years down the road and I still see a lot of poorly and improperly written CCWs. As a result, I think it is time to take people through a refresher on the CCW.

First and foremost, the writing of any CCW is your organization’s responsibility. Your QSA can provide input and guidance, but the origination of the CCW is up to the organization. Once developed, your QSA can review it and make suggestions to enhance and improve the CCW. Once that has been completed, you will then want your acquiring bank to review it to ensure that they will accept it as part of your self-assessment questionnaire (SAQ) or Report On Compliance (ROC) filing.

Secondly, the format of the CCW is dictated by the Council and that format is provided in Appendix B of the SAQ D or in Appendix C of the ROC. Failure to use the proper format will create issues with your QSA, your bank and with the Council, particularly if you are doing a ROC. So please use the Council supplied format and not develop something on your own.

Finally, the PCI SSC has stated that any requirement can have a CCW. In the past, the Council instructed QSAs and ISAs that requirement 3.2 [Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process] was not allowed to have a CCW. At the 2014 Community Meeting, the Council backed away from that restriction and said that any requirement can have a CCW with no restrictions. However, as a QSA I would have a serious problem accepting a CCW for requirement 3.2 because storing sensitive authentication data (SAD) is the whole reason why the PCI DSS was created to stop.

To remind everyone, the CCW is broken into seven sections.

• Identification of the PCI DSS requirement(s) being compensated.
• The constraint or business justification for needing the CCW.
• The original objective of the requirement(s) being compensated.
• Identification of any additional risks because of the CCW
• The compensating controls.
• The procedures your QSA/ISA followed to confirm that the compensating controls are in place and functioning.
• The procedures followed by your organization to maintain the compensating controls.

While the Council tells everyone to have an individual compensating control for each requirement, there are some places where a compensating control is the same for a number of requirements. This most often occurs for requirements in section 8 around the various user management requirements or 6.1, 2.2, 11.2 and the processes of vulnerability management. I would highly recommend using one CCW per requirement, but I can understand why you might combine some. Just be judicial in combining them. Also, list not only the number of the requirement(s), but also the text of the requirement from the Requirements column in the PCI DSS. While your QSA might have memorized the PCI DSS requirements, bankers and others that will read the CCW have typically not committed to that level of detail and it will help them with the context of the CCW.

The business justification needs to be more than just “we don’t want to” or “it was too hard”. Believe it or not, I have had a lot of organizations provide just such simplistic and silly reasons for justifying a CCW. Proper justifications can involve budgetary constraints, timing (e.g., not enough time to complete remediation by the end of the assessment period), application requirements (e.g., the application requires XP to run) and/or vendor requirements (e.g., the vendor requires a hardware upgrade to correct the issue). If you do have a target date for addressing the CCW, this is where you want to provide that information so that readers know that the CCW has some time limit.

The original objective is the easiest part of the CCW to develop. The Council has provided the “Guidance” column in the PCI DSS for each requirement and it is the verbiage in that Guidance column that you should use to explain the original objective of the requirement. If you are using the CCW for multiple requirements, this section can get rather lengthy and I would recommend identifying the Guidance information with its requirement to help understanding of the information.

The next section can sometimes be the toughest to develop and that is identification of any additional risks because you are using a CCW. In some cases, there may actually be no additional risk perceived by using a CCW. One such example is when organizations have a separate system management VLAN where network and system administrators can use telnet, SNMPv2 and other “unsecure” protocols in addition to SSH, RDP and other secure protocols to manage devices/systems. These system management VLANs typically require the use of an out of band (OOB) to gain access, administrator credentials different from the administrator’s user credentials and two factor authentication to name just a few of the controls you see in this example. These management/administrative VLANs are no more risky than using only secure protocols.

However, if you are compensating for having to keep Windows XP running, that will likely be a very different story and depending on the compensating controls put in place, the risk could be moderately higher than not have XP around. The key here is that it is that the risk should be assessed and then honestly discussed in the CCW. If you think you are going to say that having XP does not increase risk to your cardholder data environment (CDE), I would seriously think again regardless of your compensating controls in place because any outdated Windows implementation is a security problem waiting to happen regardless of how you think you have mitigated the risk.

The compensating controls section is where the rubber finally meets the road. It is here that you document each individual control that compensates for your organization’s inability to meet the requirement(s) in question. I recommend that people either bullet point or number list each individual control. The reason is that in the next two sections, you need to tie the validation and maintenance items to the controls in this section and doing some sort of list makes it easy for people to ensure they have covered all controls in each section.

The most common mistake made in this section is organizations state that they have a project to remediate the issue(s). Sorry, but this is NOT a control. It is nice information, but it is not a control that can be relied upon. QSAs never want to ever see such statements made about future projects ever in this section. This section is all about what you are doing from a controls perspective to manage the fact that you cannot meet the requirement(s).

Valid controls in this section must also go “above and beyond” what is required by the PCI DSS. Examples of “above and beyond” include:

• Reviewing log data in real time for a particular condition that would indicate an out of compliance condition on a control. This is above and beyond because log data only needs to be reviewed daily for such conditions.
• Using whitelisting to identify applications that do not belong on a PC and generating an alert in real time if such applications are found. Such technology is above and beyond because it is not currently required by the PCI DSS.
• Using critical file monitoring to identify rogue applications that do not belong on a PC and generating alerts in real time if found. Critical file monitoring is a PCI requirement, but this goes above and beyond because monitoring is only required on a weekly basis.

The list here can go on and on, but hopefully I have given you some ideas of how to create compensating controls that can actually compensate for your inability to comply with the requirement(s).

One key point though is that you cannot use a requirement in the same requirement group to compensate for a different requirement in the same group. For example, requirement 6.4 has bunches of sub-requirements under it. You cannot write a compensating control for one sub-requirement in 6.4 and then use a different sub-requirement under 6.4 as one of your compensating controls regardless if it is above and beyond.

The next section will list how the controls were assessed by your QSA/ISA to prove they have been implemented. So using our previous bullet list, here is what the control validation bullets would look like.

• Observed the system information event management (SIEM) solution and verified that alerts are generated in near real time for [control failure condition] and that the alert is followed up by the security analyst to determine if the alert is valid. If valid, the security analyst opens a service ticket and assigns that ticket to the appropriate area for further investigation.
• Observed the [whitelisting solution name] and verified that if rogue applications are loaded on a workstation a near real time alert is generated back to the [whitelisting solution name] master console and that the alert is followed up by the security analyst to determine if the alert is valid. If valid, the security analyst opens a service ticket and assigns that ticket to the appropriate area for further investigation.
• Observed the [critical file monitoring solution name] and verified that if rogue applications are loaded on a workstation a near real time alert is generated back to the [critical file monitoring solution name] master console and that the alert is followed up by the security analyst to determine if the alert is valid. If valid, the security analyst opens a service ticket and assigns that ticket to the appropriate area for further investigation.

Finally, you need to document what your organization will do to ensure that the controls remain implemented and effective. This is where most compensating controls fall apart. The organization gets through their assessment and then neglects to keep the compensating controls working. Using our list from the compensating controls section, the maintenance controls would look something like this.

• [Organization name] reviews on a [weekly/monthly/quarterly] basis the SIEM and test that the alerts for the [control failure condition] are still functioning as designed.
• [Organization name] reviews on a [weekly/monthly/quarterly] basis the [whitelisting solution name] and test that the alerts for rogue applications are still functioning as designed.
• [Organization name] reviews on a [weekly/monthly/quarterly] basis the [critical file monitoring solution name] and test that the alerts for rogue applications are still functioning as designed.

A good idea in the maintenance section is to set timeframes for remediating any control testing failures.

One other important item of note about the controls, validation and maintenance lists. Notice that there are no “forward looking” statements made such as someone “will” perform or “will” review. CCWs must be shown to be in place and operating. A promise of implementing a control is NOT a control either. The control must be shown to be operating and maintained. That is an important point a lot of organization miss. It means that CCWs cannot be created at the last minute and then be operational past the filing of your SAQ or ROC. If you are going to have to use a CCW, that means you will need to identify the situation early and then get the compensating controls implemented, validated and through at least one maintenance cycle before it can be accepted.

CCWs can buy organizations time while they address issues that will take longer to address than their PCI assessment period. Unfortunately, there are organizations that see the CCW as a way to be judged PCI compliant without addressing their serious security shortcomings. It is not unusual for large organizations to have a number of CCWs particularly if they have legacy applications and hardware. However, I would highly recommend that all organizations only rely on CCWs if there are no other options to achieving PCI compliance.

Requirements That Are Never ‘Not Applicable’

Believe it or not, there are two PCI DSS requirements that can never be marked ‘Not Applicable’.  According to the PCI SSC, requirements 1.2.3 and 11.1 can never be noted as ‘Not Applicable’.

Requirement 1.2.3 states:

“Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.“

Even if an organization does not have wireless, the PCI SSC has stated that this requirement may never be marked as ‘Not Applicable’.  The QSA is required to document the network and describe any wireless the organization has implemented, regardless of whether or not the wireless has any contact with the cardholder data environment.

While this may seem a little over the top, think about why it is included in the PCI DSS.  One of the largest breaches that ever occurred was the result of a poorly engineered and operated wireless network.  As a result, to prevent future breaches due to wireless networking, the PCI DSS requires that the QSA ensure that any wireless, in or out of scope, is evaluated to determine if it is securely implemented.

When an organization does have wireless networking implemented, the PCI DSS requires that wireless networking to be segregated from the cardholder data environment (CDE) whether the wireless is used to carry cardholder data (CHD) or not.  Again, this is in response to the large breach.  Wireless is broadcast over public airwaves and an organization cannot be assured that someone is not eavesdropping on that broadcast.  However, it is this broadcasting over public airwaves that trip up most organizations.  People neglect or forget this fact and do not put in place the appropriate security and controls over wireless networks.  As a result, the PCI DSS is trying to ensure that should wireless be compromised, the entire network is not also compromised by default.  That then requires that controls such as ACLs and/or firewall rules are put in place to restrict traffic flow between any wireless networks and any other networks.

And even if an organization does not have wireless networking, under this requirement the QSA is required to document what procedures they used to determine that there was no wireless implemented.

As a result, a QSA is not allowed to place a ‘Not Applicable’ for this requirement.

As with requirement 1.2.3, requirement 11.1 was also put in place in response to that large breach as well as a number of other, unrelated breaches.  This requirement is also in response to the low cost of wireless networking equipment and the ease with which it can be implemented in a stealthy manner thus providing an attacker with a way into an organization’s network.  For reference, requirement 11.1 states:

“Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.”

Whether an organization has wireless networking or not, the PCI DSS requires that the organization periodically assess its wireless networking posture to ensure that either wireless is still not present or that if wireless is used, that only the organization’s wireless is present on their network.

For an organization with only one or a few locations, this requirement is not that onerous.  However, for a Wal*Mart or Target with thousands of locations, scanning each of those locations on a quarterly basis is daunting.  As a result, you get wireless intrusion solutions such as those from Motorola and AirTight to automatically detect unapproved wireless devices.  While these solutions meet the requirements of 11.1, they can be expensive and difficult to implement, monitor and manage.  There is the alternative of implementing other controls on the network which can also be used to meet this requirement that I have discussed in another blog entry.  However, this compensating control has its drawbacks as well.

As with requirement 1.2.3, no organization can mark requirement 11.1 as ‘Not Applicable’ just because they do not have wireless networking implemented.

At the end of the day, the bottom line here is that all organizations are required to ensure that wireless networking is either not present on their network or, if present, it is only their wireless devices and that those wireless devices are appropriately implemented and secured.

Writing A Compensating Control

This is a very popular topic these days as more and more organizations have to rely on compensating controls to comply with the PCI DSS.  With the exception of requirement 3.2 – do not retain track data, any of the other PCI DSS requirements can be met with a compensating control.

First, let us get familiar with what is required for a compensating control.  For v1.2 of the PCI DSS, there are seven elements to the compensating control.

• Identification of the PCI DSS requirement that the compensating control is addressing.
• Identifying the business constraint(s) as to why the organization cannot meet the PCI DSS requirement.
• Defining the objective(s) of the original PCI DSS requirement and the objective(s) that this compensating control addresses.
• Identification of any additional risk presented by having the organization rely on the compensating control.
• Identification and definition of the compensating controls.
• Procedures followed to validate the compensating controls.
• Procedures followed to maintain the compensating controls.

The first rule is that a compensating control should only address one PCI DSS requirement.  However, in practice, I write some compensating controls addressing a single group of PCI requirements such as with 8.4 where you have an (a) and (b) component.  For requirements like 8.5 where you really have separate requirements, I write those as separate compensating controls.  It is up to your QSA to determine whether or not multiple requirements can be covered by a single compensating control.

Identifying the business constraint should be the easiest part of a compensating control.  However, I have seen too many constraints that indicate the only reason there is a compensating control is because of a lack of the business’ ability to implement the requirement.  That just does not cut it.  You really need to document valid business reasons as to why a compensating control is needed.  The fact that your organization does not have the backbone to implement PCI DSS requirements is not a valid reason.

However, the biggest areas where things go awry is with sections 4, 5 and 6 of the compensating control form.  Section 4 is where the organization documents the controls that compensate for the fact that the original requirement not being implemented.  Section 5 is where the organization documents the processes for validating that the controls in section 4 are operating effectively.  And section 6 is where the organization documents its processes that maintain the controls documented in section 4.

The rule that people seem to miss is that if you document a control in section 4, then you need corresponding discussions in sections 5 and 6 to provide the processes that validate and maintain that control.  I have seen too many instances where a lot of great controls are documented in section 4 and then in sections 5 and 6 those same controls are never discussed.

To avoid this situation, I tell my clients to list out all of your compensating controls in section 4.  Then in the same order as in section 4, go through in sections 5 and 6 and document what was done to validate and maintain the controls.

As an example, if section 4 says, “Hardening standards for Linux go beyond the vendor standard and all services are removed other than those services absolutely needed for the Linux server to function as a Web server.”  Then in section 5, I would expect to see, “Validated that the client’s Linux hardening standard goes beyond the vendor’s by comparing the two standards.  Compared the hardening standard to the configuration of a sample of x of y Linux servers and confirmed that the standard was in fact implemented.”  In section 6, I would want to see, “Client’s Linux system engineers evaluate each security patch for its applicability to their environment and whether it enables unnecessary services.  Patches are implemented in a test environment and evaluated with port and vulnerability scanners to ensure that the patch does not enable services that are not necessary.”

Hopefully this clarifies for all of you how to write a proper compensating control.

Above and Beyond

Here is a topic that gets very little discussion but is a big sticking point between a lot of organizations and their QSAs.  I think there is an assumption that since there is a fairly detailed discussion regarding this topic in the PCI DSS that everyone understands the topic.  However, for those of us out in the field, either people are not reading the dissertation in Appendix B of the PCI DSS or there is still confusion.

To review, a compensating control needs to:

• Meet the intent and rigor of the original PCI DSS requirement;
• Provide a similar level of defense as the original PCI DSS requirement;
• Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement; and
• Be “above and beyond” other PCI DSS requirements.

To be ‘above and beyond’ requires the following attributes.

• Existing PCI DSS requirements cannot be considered as compensating controls if they are already required for the item under review.
• Existing PCI DSS requirements may be considered as compensating controls if they are required for another area, but are not required for the item under review.
• Existing PCI DSS requirements may be combined with new controls to become a compensating control.

To explain these three principles, I think some real world examples are the best.

An organization has six character long passwords on one of their PCI in-scope systems.  As a result, they needed a compensating control for PCI DSS requirement 8.5.10.  One of their compensating controls was the fact that they required passwords to contain special characters.  A lot of people would say that requirement 8.5.11 would rule out specifying special characters in passwords, however they would be wrong.  Requirement 8.5.11 states, “Use passwords containing both numeric and alphabetic characters.”  There is nothing in 8.5.11 requiring special characters, so therefore requiring special characters in a password is ‘above and beyond’.  That said, this organization in their compensating control for 8.5.10 also stated that they required password changes every 90 days, which is already required by requirement 8.5.9.  As a result, the organization either had to change their passwords more often than every 90 days or remove that from their compensating control document.  They chose to remove the 90 day change requirement.

An organization does not have anti-virus on their Windows-based Web servers and therefore needed a compensating control for PCI DSS requirement 5.1.  One of the areas where this organization was original was in their using their very strict monitoring of their network traffic, critical file monitoring console and their real-time event log analysis as ways they determine if malware is put on these systems.  They also conduct daily vulnerability scans and monthly penetration testing.  All of these go ‘above and beyond’ because while all of these items are required by the PCI DSS, the execution of these activities was at a greater frequency than required by the PCI DSS.

In an earlier post on wireless scanning compensating controls, I give a couple of examples of combining and using existing PCI DSS controls to provide ‘above and beyond’ compensating controls.  One of the controls I mentioned was enabling MAC address filtering on the switch ports.  Since MAC address filtering is not required by the PCI DSS, this control will go above and beyond.  In addition, I suggested that there should be monitoring the network for any devices that do not respond to SNMP inquiries using your organization’s SNMP private community string.  Monitoring of this sort is not even called out in requirement 10, so I would say that this sort of monitoring would go above and beyond.

These examples should give you some clarity on what is considered “above and beyond.”

Wireless Scanning Compensating Control

I got a comment regarding my post titled “Wireless Security – Random Thoughts On How To Fix” asking what sorts of compensating controls would address requirement 11.1.  Since I have been looking for a topic, I thought I would address this as well as provide people with an example of how you develop a compensating control.

In order to construct a proper compensating control, you must first answer a couple of basic questions.

• Define the objective for the original requirement; and
• Identification of how the compensating control addresses the aforementioned objective.

In order to be able to define the objective for the original requirement, you need to understand the requirement.  Requirement 11.1 states, “Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.”  On the face of it the purpose of requirement 11.1 is to ensure that all wireless access points are accounted for at each location using a wireless scanner or WIDS/WIPS, so that any potential rogue access points are identified and therefore can be removed from the network.  But is that the “real” objective of the requirement?  Before you go running off for alternative ways of identifying rogue access points, let us ruminate a bit further about the objective of requirement 11.1.  What is the “real” objective of requirement 11.1?  The real objective is to make sure that rogue access points do not end up on your network and if they do, you can identify and remove them as soon as possible.

Remember the criteria for compensating controls.  Compensating controls must:

• Meet the intent and rigor of the original PCI DSS requirement;
• Provide a similar level of defense as the original PCI DSS requirement;
• Existing PCI DSS requirements CANNOT be considered as compensating controls if they are already required for the item under review;
• Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area, but are not required for the item under review; and/or
• Be “above and beyond” other PCI DSS requirements.

With all of this in mind, what are controls you can put in place to keep rogue wireless access points from being placed on your network in the first place?  The following should not be considered a complete list of controls you can put in place, but it does provide enough controls to create a compensating control for requirement 11.1.

• Disable all unused switch ports.  If unused switch ports are disabled, the installation of a rogue access point cannot be accomplished by plugging it into an open port on the switch.  This approach is usually not appreciated by network administrators as it requires the re-enabling of a port whenever a device needs to be added at a location.  It can also be disliked by remote facility personnel as it means there can be additional delays in getting another network device on the network.  While this control is referenced in requirement 9.1.2, it is not germane to requirement 11.1, so we can use this control for our compensating control for requirement 11.1.
• Enable MAC address filtering on the switch ports.  This control will restrict what device can be plugged into an active switch port.  Essentially tying a single device to a single switch port.  As with the first bullet, MAC address filtering creates a network management issue when you want devices added or changed.  So you will be adding to the effort required to change any devices out in the field.  Since MAC address filtering is not required by the PCI DSS, this control will go above and beyond.
• Monitoring of switch ports and generating alerts whenever a device is unplugged or plugged into a switch port.  Most switches will generate log entries when a device is either unplugged or plugged into a switch port.  Those events should be investigated immediately.  Such events can be the first sign of someone trying to plug in any sort of rogue device from a wireless access point to their own laptop.  Monitoring of this nature is required as part of requirement 10.  However, how you use monitoring to meet requirement 11.1 is not considered part of that requirement, so you can use the information you gather and monitor in requirement 10 to meet your requirement for 11.1.
• Monitoring the network for any devices that do not respond to SNMP inquiries using your organization’s SNMP private community string.  Again, if a device does not respond to SNMP inquiries using your organization’s SNMP private community string it is either mis-configured or does not belong.  So if you cannot communicate with the device, it needs to be investigated and either fixed or removed.  Monitoring of this sort is not even called out in requirement 10, so I would say that this sort of monitoring would go above and beyond.
• Disable dynamic host configuration protocol (DHCP).  DHCP is a wonderful service, but it is also a dangerous service.  It is dangerous because it allows any device, whether it belongs on your network or not, to obtain an IP address immediately when it connects to the network.  If any device can obtain an IP address when connected, then it has full connectivity to your network.  By not implementing DHCP, you remove that risk by requiring all devices to be preconfigured for their segment of the network.  Yes, your networking people will likely not appreciate this, but it provides a good security feature.  DHCP is called out as part of requirement 9.1.2, but again, it is not germane to 11.1, so we can use it here for our compensating control.

Because these controls can have a significant impact on your network and computing environment, we need to discuss a few more items.

First, you only need to disable DHCP at your retail locations, not your corporate office.  Typically, an organization has a lot more control over their computing environment at their corporate office, than at their retail locations.  As a result, enabling DCHP at the corporate office is not as risky, but you should still avoid enabling unused switch ports and unused jacks throughout any of your facilities.

If you are going to utilize wireless in any of your organization’s locations, make sure to properly isolate the wireless network from the rest of your network.  Even though you have implemented all of the compensating controls above to secure your network from rouge access points, you still need to ensure a secure wireless networking environment.  If you need wireless for operational purposes, make sure to secure it properly so that it cannot easily be compromised.  Such measures typically include not broadcasting the SSID and using WPA2 Enterprise security.

If you wish to provide wireless access to guests at your corporate office, make sure that their traffic is separated from any other wireless traffic and that they are only granted access to the Internet and no other internal resources.  A lot of organizations today require even guests to authenticate to their wireless as an extra security measure to keep people from using the available bandwidth at will as well as providing a mechanism to have guests acknowledge their responsibilities when using the wireless network.

Once you have the aforementioned information documented, you still have a few more things to cover in your compensating control.  You still need to implement your own feedback loop on these controls to ensure that they are functioning as designed.  Unlike Ron Popiel’s  miracle TV  oven, you cannot just ”set it and forget it” with these controls.  You need to have a plan in place to periodically follow up on all of these controls to ensure that they are functioning as designed.  Typically, that means tracking statistics collected from the monitoring controls.  It also means periodically observing these controls in action to ensure that monitoring is taking place and that ports really are disabled.  This sort of follow up is easily implemented as part of your financial field audit work.

In addition to your own follow up.  Your QSA also has to document what they did to confirm that these controls were in place and functioning as designed.  Their work is going to be similar to your own internal follow up work, but will likely be less extensive than your internal work as long as no exceptions are found.

You should now have a compensating control for requirement 11.1.  But better than that, you should now have a much better understanding of how a compensating control is developed and documented.

Compensating Controls

A lot of organizations are relying on numerous compensating controls to achieve their compliance with the PCI DSS.  For version 1.2 of the PCI DSS, compensating controls have two new requirements and these new requirements will have the potential to cause a lot of organizations to become non-compliant.  As a result, I expect to find the next year very painful for our new clients as we explain these new rules and they attempt to come up with the documentation to keep their compensating controls.

There are now six requirements to the Compensating Controls worksheet.  The original four:

• The PCI DSS requirement that cannot be met;
• The control objective(s) of the PCI DSS requirement;
• The business reason(s) why the PCI DSS requirement cannot be met; and
• The compensating control(s) that have been put into place to achieve the PCI DSS requirement.

In addition to the original four requirements, two more have been added.  Those requirements are:

• Validation that the compensating controls are functioning as defined; and
• How the organization maintains the compensating controls.

The easier of the two new requirements is how an organization maintains the compensating controls.  However, while it is the easier of the two from a discussion standpoint, the fact that an organization must be able to document its maintenance processes for controls could be problematic.  In most organizations, the change control process for the control environment is typically not documented.  As a result, most organizations will have to adopt their change control processes for other business issues and just apply it to changes to their control environment.

The other new requirement is the one that most organizations will struggle with, providing documentation that the controls they are using to compensate for their lack of meeting the PCI DSS requirement are functioning as designed.  While this sounds simple and straight forward, I can tell you from personal experience that a lot of the compensating controls that were documented under v1.1 of the PCI DSS cannot provide this sort of proof.  In addition, a lot of compensating control cannot undergo the scrutiny of testing required to determine that they are functioning as designed.

So, where is the problem?  An organization must prove that it walks the walk, not just talks the talk.  This is where the wheels typically come off the bus.  It is very easy to say that something is a control; it is another thing to be able to actually prove it.  Organizations will have to provide documentation in the form of completed checklists or other formal documents that proves that the control is not only being used but that if a control exception occurs, the exception is addressed.  In addition, the QSA will also have to observe these processes at work so that they can satisfy themselves that the control is functioning.

I am not saying that compensating controls are a bad thing.  There are instances where organizations have no other choice.  The most common issue in this category is the database that takes more than 9 to 15 months to re-encrypt in order to change encryption keys.

In my experience, though, there are even more organizations that are using compensating controls because it is an easy out.  One of the most common reasons is that they need to avoid a large expenditure.  There are also those organizations where meeting the requirement will take a cultural change that management cannot step up to make.  There are also those organizations that just despise being told what to do and are just digging in their heels.  And, finally, there are those organizations that just plain do not want to have to get off their rear and do something.  For organizations like this, the jury rigging and hurdles they go through to make a compensating control work is mind boggling and, more often than not, costs more in time and resources than just meeting the original requirement.

If your organization is relying on compensating controls to be compliant with the PCI DSS, then you will want to make sure that you absolutely have no other alternative than a compensating control.  You should do an analysis of what it costs to maintain and comply with the compensating control versus implementing the PCI DSS requirement as written.  I would say that in about 85%+ of the cases, you will find that meeting the original requirement can be achieved easier and cheaper than using the compensating control.