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.
