Running PCI as an Agile Project?

First, I have only been ‘doing’ Agile stuff for a little over 2 weeks, so this will be less about project management and more about how achieving PCI compliance should be done. Or or this case, could be done …potentially …unless I’m completely off the mark.

Like any project, PCI is just a whole bunch of action items, assigned to an individual, with a due date. That’s it. Unlike frameworks such as ISO 27001, PCI is written down for you, so it makes sense that a methodology like Agile would be well suited to keep a PCI project moving.

The reason that PCI compliance is so difficult for a lot of organisations, is that regardless of the seeming simplicity, determining what those actions ARE, or which to start first, or even knowing when to stop, can be more of an art form that a science. This is why there are so few good QSAs, as they are the ones who are supposed to be providing the guidance on every question you may have, even before you know enough to ask them.

We’ll leave, budget, resources, and having having management who give a crap aside.

So, if you agree that because the DSS is written down for you that you can determine the list of action items required to validate compliance WELL before you begin, then my theory makes a little more sense.

For example; for every operating system you have, the DSS requirements and the actions items are very clear:

  1. Requirement 2: Have a configuration standard, show evidence that your systems follow it
  2. Requirement 5: Have AV, show evidence that it’s running, or have a compensating control
  3. Requirement 6: Document your vulnerability management process, show evidence that your servers are patched accordingly
  4. Requirement 7: Have some form of LDAP, show evidence that access control lists are enforced accordingly
  5. Requirement 8: Extension of Req 7., show authentication and ID management are enforced
  6. Requirement 10: Turn logging on, demonstrate that your SIEM is reacting accordingly, and that all times are synched
  7. Requirement 11: Have FIM, show that’s running

So for an Agile project, you just create a series of issues in the backlog that correspond to the above, and duplicate EVERY issue for all subsequent operating systems in your environment. Simple huh?

And you don’t need a dedicated project manager, just a scrum master who can run all of the daily stand-ups and bi-weekly / monthly sprints. Of course, getting all of the action items right will take a significant PCI expertise, but once this is done for your environment, there’s really no excuse for a stalled project.

The benefits seem to be;

  1. The level of effort required to achieve compliance is obvious very quickly, so resources can be applied in the most efficient manner
  2. Those not pulling their weight become obvious to everyone from the very first sprint, and a determination of anything from individual employee overload to utter incompetence can be determined
  3. You have to think about PCI in the only way that makes sense, and keeps things moving forward; bite-sized chunks of action items
  4. Workloads can be spread around, with current print tasks reassigned to those with more available time
  5. The process becomes repeatable when every action is recorded during the project’s lifecycle.

Anyone who’s ever seen a PCI project drag on for years, or had people on whom you were dependant make excuse after excuse for months on end, something like Agile could be the edge you’re looking for.

Unless I’ve completely missed the point.

Leave a Reply

Your email address will not be published. Required fields are marked *