2

As a developer, when an Incident comes in and reaches Tier 3 support (The development team), how can the developers get access to query the Production Database, while remaining PCI Compliant? I'm admittedly a newbie when it comes to PCI Compliance. Is this just a case of Read-Only accounts? Is this a case of data masking? Is this a case of having a Production copy within Production so devs can't hit a "Live" db? What's the easiest, and compliant way for developers to be able to perform application incident support in production?

1 Answer 1

3

DSS 6.4.2 Separation of duties between development/test and production environments is careful to note that it is not prohibiting developers from Production, just controlling them:

The intent of this requirement is to separate development and test functions from production functions. For example, a developer may use an administrator-level account with elevated privileges in the development environment, and have a separate account with user-level access to the production environment.

So restricting privileges is a good start - read only access where possible, limited administrative rights enforced with something like sudo or PowerBroker as necessary.

Aside from restricting privileges, a standard way of dealing with this would be to use Incident and Change Control processes to document why any given developer was acting in Production at a given point of time, and to generate an audit log that can be used to evaluate what actions were taken in the time/place covered by a ticket. Remember, at some level, you want to be able to walk the auditor through your controls.

If your workflow permits it, dual control can be a useful restraint upon developers, ensuring that a second pair of eyes is monitoring the activity. That can be difficult to arrange; developers get called into Production emergencies because they're, well, emergencies, and not neatly scheduled.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .