Applying Security to the CNC Administrator

kjohnson1

Member
Hello all.. We are in the middle of a Sox nightmare. Our internal auditors want to lock the CNC group (which currently do promotions, installations and all troubleshooting, no security) out of our Production envrionment. Is there anyone currently locked out of PD and if so have you seen any issues being locked out. I don't see there being a problem with the exception of building specs and generating tables. Boss has a small concern on the promotions but, I am not forbidden from objects on the AS/400 side (I still have all obj authority with my system id). They would just take the environment away from my jde id? Is there anyone out there that has done this so, I can put the questions at ease?
 
From a SOX perspective, this is not an unusual request. What will generally suffice a SOX audit is either locking out CNC admin from production, or having controls in place that track everything being done. Also, you don't need access to the actual production environment in order to perform promotions and/or package builds. Many companies also maintain a generic "PD troubleshooting" account that is controlled by the security officer.

If you stop to think about it, in many ways, CNC folks should actually enjoy not having access to production.
 
I do CNC and most the System Admin stuff. I also maintain the Security Workbench. The only thing I can't do in production are the table related functions and setting up a new user. The auditor didn't have a problem with this because I'm not classified as a developer. The developers do not have access to production. We are a government entity so SOX my not apply to us.

Patty
 
[ QUOTE ]
We are a government entity so SOX my not apply to us.

[/ QUOTE ]

No it doesn't. It's the government entities that are applying the rules to us! SOX applies for publicly traded US corporations.


Gregg Larkin
JDE System Administrator (CNC) / North America
Praxair, Inc.
 
Kathy,

What a pain in the neck! Our SOX auditors (internal or external) have not even suggested restricting CNCs from production. That would make troubleshooting and support a real challenge. Our developers have had their hands tied, much to their annoyance, but not the CNCs. Good luck with that battle!


Gregg Larkin
JDE System Administrator (CNC) / North America
Praxair, Inc.
 
I have been involved in this debate before when I was an IT manager. There were a lot of political turf wars involved. SOX was a political snap judgement in the wake of the Enron scandal. It is a pain in the butt for IT personnel.

I have two points to make. First, at least some IT personnel will require access to production for trouble shooting. Not giving IT personnel access will soon result in end users supplying IT personnel with passwords so that they can diagnose problems. This will not only breech security, but also mess up the audit processes.

Second, access has to be well thought out and complete. Restricting JDE access, but allowing AS/400 object access is pointless. You cannot allow back doors to be open and consider yourself secure.

It is not uncommon for auditors to want to restrict IT access, but they are not responsible for keeping things working. I am going to stop here before saying anything that I shouldn't.

Good luck.
 
Our auditors are still in a bit of a tizzy over that request as well. It doesn't make sense to lock the CNC out of production when the CNC is the only one who can do the locking and unlocking (at least here). And we've found that the CNC enters the PD environment constantly during the day for package builds, Q&A, UDC changes, etc. We are currently in the mode that the job dictates this certain situation which may not be with the best interest of SOx, but is a business requirement at this time. Close monitoring of the CNC is one thing that helps. Logs, etc. are another. But the final outcome is yet to be determined.
 
In my job, I have full CNC access to all environments as well as admin rights to all of the JDE servers. I do the CNC job for North America (3800 users, four countries) and the security admin for the USA. We have defined full access as a business requirement and have not had that challenged (although I wonder if that will change thanks to this thread!!). In my defense, our environment is so darn big and complicated, I can plead ignorance about the inner workings of the application that the users use. I confine myself to working in the admin tools unless I need to test some functionality for troubleshooting or security definition.


Gregg Larkin
JDE System Administrator (CNC) / North America
Praxair, Inc.
 
I agree with Gregg Larkin's statement. We are a public utility and go through external audits every year and pass with flying colors.

Our Developers have only view rights to Production and the CNC, which is me and I have one backup, have full rights to all environments.

We have a strong Change Management process and require double signatures for "anything" to be moved to Production. As CNC, System Administrator & Security Administrator I do not to any data changes to Production. If something were required, again our Change Management process requires two signatures and then the Database Administrator would do it.

The external Auditors do audit these functions and hold us to a tight compliance.
 
It has been a battle for the last year now. Their biggest concern is that I can log into an application, cut a check and update inventory status. I plead the I am clueless on how to do the process but, obviously that isn't enough. It has nothing to do with seeing the data. So, one solution is inquire only to non-technical apps. Then when we have to trouble shoot we sign out an id. Which still defeats the purpose of keeping us out.. I could have that Id and still do all the things they are afraid of us doing. I thank everyone for their response. I don't feel for anyone who would have to go through.
 
Wow...this is a fun topic. Remember folks, SOX is all about accountability and controls. There are no "rules" that are hard and fast. When I do SOX audits what I suggest to one company may be completely different than another company. The thing to always remember, validate and document. If you have a valid business reason for something, say full system access of all systems for one person (which, by the way, is VERY common), document it.

What you need to be careful of from an auditing perspective is not having the business reasons to back up any processes you aren't seeming in compliance with. For instance, if someone tells me "I need production access because I promote and do package builds in production"...that isn't going to fly, you do not need access for this. Now if the answer is "because I'm a IT island of one in the company", now you have a valid point. Now we can sit down and "document" how you will "control" your access when in production, and "document" on an ongoing basis your access in that environment.

Another thing I always tell folks when they start getting queasy about locking CNC out of production, is that as long as there is a separate account, and it's use is documented (that is a log or journal entry as to who used the account, when, what for), you've satisfied SOX requirements.

I find it humorous that the biggest gripe about a SOX audit is usually the access issues, when I see the biggest issues are doing things that many organizations haven't: Have a documented and tested DR plan, have a documented and implemented change control strategy, unifying software accross the enterprise (and documentation of licensing), and the level of documenting that will be needed to be performed on an ongoing basis.

Long and short of it, if you've got a valid reason, and you document it, there shouldn't be anything that can't be 'worked out' from a SOX perspective.
 
Great Topic,
I was wondering how many EnterpriseOne accounts had to do SOX Compliance.......
We have production support ID's for all developers that have fast path and access to all applications. These support ID's are inquiry only, no Add, Change, Delete access etc.
We have 3 security administrators, 2 are back ups.
We have 3 system administrators that are also authorized to do production deployments.
Our internal and external SOX team has identified many applications and UBE's that should have restricted access.
We have secured them and we have not had any problems related to deployments etc.

We have also developed several inquiry application for internal audit and the SOX compliance team that they use on a regular basis.
Not that I do not like meeting with the auditors, 120+ hours every qtr for internal audits and 80 to 120+ hours for the pre SOX audit, SOX audit and Post SOX audit.....
They can now find almost all the information they need on there own.
Dave
 
Hello There

I think all CNC's have gone thur this issue over and over again. In my organisation they wanted, some how we were able convince them that we need this access and they agreed ( not sure why they didot press too much I guess depends on who si the auditor).
However if the need be I am sure you can sure restrict the accesss to prodcution while having access to application which he need access to do hi tasks)
I see your point about cutting a check or doing anywting with prodution data. You would need to get a list of object which he need to get access to and for rest he should get read/view only access.

In my case, I have designed the secuirity system where as when an analyst logs in production, he can only do view /read only stuffs, However when he logs in other non production environment he can do what ever he wants to do. ( E810 multiple role came in handi)

IF you have closed security model, you can start adding back objects which CNC requires one by one ( make sure he is not the security admin aswell b/c that will defeat the purpose...


Jaise
 
Back
Top