I am encountering more and more organizations that are interested in business as usual or BAU. Organizations are finally realizing that the only way they are ever going to feel secure is to embed security controls in their everyday business processes and make sure that they periodically assess that those controls are working. The PCI SSC used a page and a half in the PCI DSS v3 to discuss the concept of BAU. This leads some of us to believe that BAU will become part of the requirements at some point in the future.
However, what is involved and what will it take to implement BAU? This post will give you an idea of what you will be up against.
Going through the PCI DSS v3, I did an analysis of the requirements and testing and came up with some interesting statistics regarding BAU.
- There are 14 requirements/tests that are required to occur at least daily.
- There are 18 requirements/tests that are required to occur whenever changes occur.
- There are five requirements/tests that are required to occur whenever significant changes occur.
- There is only one requirement/test that is required to occur at least weekly.
- There are three requirements/tests that are required to occur at least monthly.
- There are 11 requirements/tests that are required to occur at least quarterly.
- There are four requirements/tests that are required to occur at least semi-annually.
- There are 118 requirements/tests that are required to occur at least annually.
For my analysis, I assigned actual values to those requirements/tests that use the words “periodic” or “periodically” in their definitions. The values I assigned were based on other standards or security “best practices”. That is why my analysis does not include those references.
In total, there are 227 requirements/tests that need to be done at some frequency. There are some requirements/tests that are duplicated in this count because they are not only required to be performed for example at least quarterly or annually, but they may also be required to be performed whenever changes occur. The best example of this is vulnerability scanning which is required to be performed at least quarterly but also whenever a significant change occurs.
The biggest problem organizations will have with BAU is getting all of this integrated into their operational. To address that, I tied the requirements to their priorities from the Council’s Prioritized Approach spreadsheet. This allowed me to determine which BAU to implement first, second and so on. What I found was:
- There are 16 requirements/tests in BAU that have a ranking of ‘1’ (highest priority).
- There are 75 requirements/tests in BAU that have a ranking of ‘2’.
- There are 37 requirements/tests in BAU that have a ranking of ‘3’.
- There are 58 requirements/tests in BAU that have a ranking of ‘4’.
- There are 30 requirements/tests in BAU that have a ranking of ‘5’.
- There are 11 requirements/tests in BAU that have a ranking of ‘6’ (lowest priority).
Once BAU is integrated into operations, organizations will want to ensure that it continues to operate effectively. That will likely mean including the assessment of BAU as part of their internal audit activities. This will further mean that departments will have to maintain evidence of their BAU activities to prove that BAU is being followed. Some of that evidence will already be maintained in centralized logging and change control solutions. However, other evidence such as with new user setup or user termination may have to be retained in a folder in the email system or exported as a readable file and stored on a file server. The bottom line is that evidence of some form needs to be maintained to provide proof that BAU activities are performed and performed consistently throughout the year.
But that is the ultimate point about BAU. It is all about engraining the security concepts in the PCI DSS to better ensure security is being maintained throughout the year, not just at assessment time. And that is where most organizations fail with PCI is keeping the controls functioning throughout the year.
I have yet to encounter any organization that can prove to me that all of the PCI requirements are functioning at 100%, 24x7x365. All organizations have issues with controls, but with BAU, the idea is to have a mechanism that identifies those issues before they become damaging and correct them before too many controls fail and result in a breach. If you read any of the breach analysis reports, that is why the breach occurred because the controls were not functioning and no one addressed the failure.
PCI Guru 
This is something I have been meaning to do (done something similar for other standards), after doing a simple key word count for time based elements I am struggling to find the figures you quote.
Simple word count from PCI v3 standard (the entire text)
Periodic 20
Annual 37
Quarterly 24
Month 25
Daily 8
Day 12
Week 2
These words repeat across the 3 columns, are listed multiple times in the same requirement text meaning that these numbers are inflated to the actual number of checks required, additionally some of these are required configurations not tests i.e. Password changes
I know you cannot share your work (I am a consultant to) but a little clarity around your process would be helpful no requirement for the final output
Thanks
The process I used was to load the work program from the Reporting Template into a database and then queried only the tests themselves to remove all of the duplication in guidance, process, etc.
I was part of the SIG that created the BAU best practice document . One of the recommendation I had was to assign recommended control execution and test frequency to each control and make that part of the BAU best practice document. At one point it was in there but later got removed. Again this would have been just best practice recommendation and companies could change the frequency to fit their org. I think that would have provided a good start to companies implementing continuous PCI compliance monitoring program (like SOX).
Unfortunately, the Council is caught between a rock and a hard place in these instances. If they provide too much guidance or information, there are legal teams that will then drag them into lawsuits because their clients relied on that information (regardless of disclaimers) and got breached. They have to tread a fine line as to how much guidance they provide to avoid being held legally responsible for what happens when organization follow the standards.
Guru,
Is it possible for you to make your analysis available? for example, which of the requirements/test are to be done daily? ect.
As I stated earlier, I am a consultant and that is a work product for my clients and company.
Hi PCI Guru, this is a good piece elaborating on the BAU aspects. Would you be able to provide more details on your ranking methodology. It would be good if it is visible on how you rated the rankings.
I am a consultant and that work product is unfortunately not available. Not being mean, but this is how I make my living.