27
Sep
14

Interested In Business As Usual?

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.

Advertisements

9 Responses to “Interested In Business As Usual?”


  1. 1 Dave
    December 5, 2014 at 4:47 AM

    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

    • December 5, 2014 at 7:20 AM

      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.

  2. 3 NS
    September 29, 2014 at 12:27 PM

    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).

    • September 30, 2014 at 5:30 AM

      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.

  3. September 29, 2014 at 9:34 AM

    Guru,

    Is it possible for you to make your analysis available? for example, which of the requirements/test are to be done daily? ect.

    • September 30, 2014 at 5:24 AM

      As I stated earlier, I am a consultant and that is a work product for my clients and company.

  4. 7 Pat
    September 28, 2014 at 9:27 PM

    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.

    • September 29, 2014 at 5:20 AM

      I am a consultant and that work product is unfortunately not available. Not being mean, but this is how I make my living.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

September 2014
M T W T F S S
« Aug   Oct »
1234567
891011121314
15161718192021
22232425262728
2930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,857 other followers


%d bloggers like this: