Segregation of Duties - developer list 2063

lisa2007

Could anyone please share with me how do you normally define ‘developer list’?
Would it be sufficient just to gather the list of users with modify access to code repository?
If a ‘developer’ does not have access to code repository but has modify accesss in production environment, do we need to worry about this? Is this validation necessary?
When gathering a list of users with check-in and check-out access to the folder where source code resides in the code repository, do we only check the list of users with modify access to the highest folder (normally main folder) in the hierarchy, or do we check the list of users with modify access to the main folder and each and every subfolders under the main folder?

NC

Hi
W.r.t point No. 1 Ideally:
’ Developers should not have access to Source code repository at all’
‘No-body should have access to make direct changes in Production environment at all’
A developer can have access only to the development environment and worst come worst to the Mock or Test envrionment. We need to ensure that developers do not have access to Production environment( to ensure confidentiality of data, they should not even have read access to PRD). Segregation of Duties needs to be ensured between the developer and the application administrator( who ports changes across environments)
w.r.t point 2, we need to first verify if access rights of sub-folders are inherited from the parent folder, if yes we need to not check access for each sub-folder. If rights are not inherited then we need to go ahead and gather info for sub-folder. However, use of VSS tool can ideally eliminate this issue altogether.
cheers

harrywaldron

NC offers excellent advice and I agree with the good controls noted. Below are additional ideas:

Could anyone please share with me how do you normally define ‘developer list’?
This is a good question, particularly when ‘end user computing’ techniques are employed, and lines between IT and the business professional merge. Typically, it’s folks who setup the systems, author source code, etc. They should be differentiated with the normal user who uses the system ‘day-to-day’. Sometimes, the developer and user can be the same person for an Excel spreadsheet, Access/Toad query, etc.
However, for traditional automated financial systems, developers are IT folks
Would it be sufficient just to gather the list of users with modify access to code repository?
That’s definitely one good review point. Sometimes on highly sensitive financial applications, you want to check to see who may have read access also (e.g., you may want to keep the layouts, field names, schemas, etc., all confidential even on a read basis).

If a ‘developer’ does not have access to code repository but has modify accesss in production environment, do we need to worry about this? Is this validation necessary?
Yes, one should always test security (whether it’s absolutely required by SOX or not). I’ve seen cases where errors have been made in access rights of users or the servers themselves. It should be a quick test to ensure these developers can’t access the source library.
We use ‘emergency’ accounts called ‘Fire IDs’ that are extensively logged when production access is needed to sensitive applications. This provides a 24 hour Window and the developer would request another one if needed. This way routine access to production systems isn’t available, and the reasons are also well documented when the need does surface.
2. When gathering a list of users with check-in and check-out access to the folder where source code resides in the code repository, do we only check the list of users with modify access to the highest folder (normally main folder) in the hierarchy, or do we check the list of users with modify access to the main folder and each and every subfolders under the main folder?
As NC shares, sub-application security should be inherited from the primary folder, however it’s good to spot check, as individual sub-folders can be set independently as well.

jheuer

Regarding the comment below, in principle I understand and agree, however; we are not a large shop and out developers are also second level support. We do not have the resources to have a full mirror of production for the developers to troubleshoot problems.
One solution we have is to allow them full READ access to Production at the application level (with the exception of Payroll) with no ability to modify data.
This is in a JDE/PeopleSoft environment. Has anyone else had similar issues, and how did you get around them while keeping the SOD controls intact?
We need to ensure that developers do not have access to Production environment( to ensure confidentiality of data, they should not even have read access to PRD).

harrywaldron

One solution we have is to allow them full READ access to Production at the application level (with the exception of Payroll) with no ability to modify data.
This can actually be okay in cases where information is less sensitive, there are strong IT policies, and compensating controls. Internal auditor might also want to evaluate the current process, to see if there are areas that need strengthening.
Some more detailed thoughts on this are as follows:

IT professionals sometimes need access to the underlying production data to solve production system problems (e.g., so they know exactly when conditions triggered an abend, OOB, or other problem). They may also need to write one-time reports (that won’t go into the production environment). We sometimes use emergency access accounts for sensitive applications called ‘Fire IDs’ so that developers use a special logon where access is tracked.
IT policies should be in place to ensure information is not disclosed in an unauthorized manner. Developers are entrusted to use this responsibility and ensure an air of confidentiality at all times.
Special encrypted protection of any SSNs, credit card, bank accounts, etc. is highly recommended. This data shouldn’t reside on Internet servers and should be protected to avoid major embarrasments and expense to the organization.
While Payroll data is important, you may later want to review key production systems to see if more areas need protection. From a SOX viewpoint, the financial data is the key area where controls and good security should be in place. Still, reviewing information protection and sensitivity on an application-by-application basis is a good thing
For the most sensitive systems, developing fictious data to test with might help (e.g., moving all 9’s to SSN, ‘Mickey Mouse’ to name fields, and doctoring up the data so that it can run through programs but has no tie-in to true account information). Users may also key up test data as well in these cases.
As a bottom line, risk management and best practices play an important role when developers need production access. It’s beneficial to look beyond just the SOX compliancy standards so you have a uniform approach for the IT staff. It should be balanced, so it’s not burdensome for them yet provides assurances that production information will be used in a responsible manner.