Requirement 6.3.3

[dd216]

Hi folks, I'm new here, and new to PCI, I've recently accepted a position with a company that requires PCI compliance. My past experience has been with SOX, and my question pertains to the above titled requirement.

Separation of duties between development, test, and production environments.

My question: Does this requirement mandate that access on development/test boxes exist to a specific group of people that would not have any access to the production systems? This is how we handled a similar issue with SOX. Our programmers had access to their test systems, but no access at all to the production systems. Further, are folks with production system access then prohibited from access on the test/dev systems?

I'd be very interested in hearing anyone's thoughts on this issue. Are you running multiple sets of Admins for each environment? Do you limit physical access to servers, based on which servers each group has access to?

Thanks in advance, and Thanks to the staff for providing this website, I'm sure I'll be spending a good amount of time here reading, and asking questions :)

Doug

[lyalc]

I'm sure responses will vary on this one.
In my experience, we have dealt with service providers that have as few as 8 staff, up to those with several thousand in their IT department alone.
Ideally, developers etc should not have access to production.

Where this is not practical (e.g. a company of 8 employing an additional 2 staff just to do the rare production support call), then my approach has been to ensure the dev/test/support roles have unique login IDs, thus providing added auditing ability while they are logged into Prod, and reducing somewhat the potential for leaking Prod data into Dev/Test environments or for 'on the fly' changes.
Discouraging single sign on approaches helps by requiring a conscious decision to log into Prod, etc, session timeouts etc.

Minimising the exposure of Prod systems to the powerful data access tools and mechanisms that developers have reduces the potential for compromise via deliberate actions or accidental 'I forgot' moments.

Just one view
lyalc

[jbhall56]

In the best situations where you have separate application development, quality assurance (QA) and production operations groups, the application developers and QA personnel NEVER have access to production. There's really no need except for very, very rare circumstances where the problem/issue cannot be replicated in the development or QA testing environments.

However, in this day and age, most organizations, even in some large organizations, the application development groups can be fairly small because of packaged solutions with very limited, if any, modifications. And the QA group may not even exist. As a result, segregation of duties in these small IT operations can become challenging. But, that does not mean that it cannot be accomplished. Organizations just have to be more creative in their approach to segregation of duties.

The most common way that we address segregation of duties between development, QA and production is to always treat production as production and development as development. If you are a production system or network administrator, you are NEVER a developer. If you are a developer, you are NEVER a production administrator. That means that personnel in either group can perform the QA function.

If an application developer is performing the QA function, then they are NEVER allowed to QA applications they have developed or worked on. And, the application developer performing the QA function is NEVER allowed to migrate any changes to production.

If a production administrator is performing the QA function, that administrator is NEVER an application developer. If a production administrator is conducting the QA function for an application, then another administrator must be the one to put that application into production once it's certified by QA as ready for production.

The key to this whole process is to have a paper or electronic audit trail to prove who did what and when by their 'signing' of change control documentation based on their responsibility in the change management process. I have clients that use everything from Excel spreadsheets and paper documents, to a shared folder on Exchange for changes, to sophisticated change management solutions.

This model works in organizations with as few as two developers and two production administrators. I would say that if you have anything smaller than that, you should seriously assess what you are doing from an IT management and control perspective.

And for those of you naysayers out there that claim segregation of duties just inflates the number of personnel required to run your business, I would like to say that I cannot tell you how many times per year my Firm gets called in to investigate fraud or other illegal activities that are the result of segregation of duties not being enforced and/or monitored. It is the most common reason for these problems. The bottom line is that if there are no checks and balances, people will recognize it and will, at some point, abuse it.

[dd216]

Thanks guys,

Our IT department is broken into three sections, with the relevant ones being the programming section and an infrastructure section. My previous experience with SOX seems similar to the PCI requirements regarding this specific PCI requirement. We used to have a group of programmers that would create the product, and updates, test them on the dev environment, after their testing they would submit changes to the QA dept and they would go through their validation testing, finally the changes would be approved and submitted for change to our production environment. At no time did a programmer install any changes to either QA or production, and similarly QA never installed on our production environment.
I'm hearing that we can meet this requirement with our two current departments, but just have to verify that the folks (within the same depts) who create changes aren't the ones that implement the changes. I'm sure we can put a process like that into place.

Thanks again for your replies!

Doug