Security Management

Hi List,

I'm having a hard time convincing the "decision makers" who should be managing security and who should be able to use the Security Workbench. I know that every company is different and our company is different across the board as well. The security approach is different here at our Head Office then it is for our manufacturing divisions.

I feel that the CNC people should manage it and a lead application person should know the functionality and be able to view the setup but not be able to perform the security changes.

I'd like to know what other companies do for their security and management of it. Can I get some reponses on who does the management of OneWorld security in your company and who has what access to security workbench, etc? Any additional suggestions would be appreciated too.

thanks,
Kevin

All security requests are logged in our issue tracking system. They
have to be approved by the PL of the functional area (sales, finance,
distribution, etc.). Then the request goes to the CNC/Security group to
make the change and notify the PL and requestor that the change has been
made. Only the CNC group can make the security and menu and profile
changes. Satisfies the EDP auditors.

The CNC group provides the tools to the PLs to view the security of
objects, people, groups, etc. Some reports provide exploded views of
what is on menus and what they have authority to do. Given the right
tools the PLs can make good recommendations.

Dan





OW 7321, SP 12.5, coexistant, ES 400 V4R5, DS NT

Kevin,

We are following the scenario you are describing. Our CNC group has access to add/change/delete in the security workbench. Application folks have access to view security, but cannot make changes.

All security requests go through the appropriate business analyst for approval before being implemented by the CNC team.

This setup has worked well for us.

DeRay Scholz
OneWorld XE SP16.1 U3
AS400 / Citrix

Kevin,

Definately security should be maintained by CNC ans should be limited to a few persons if you have multiple CNC admins. If your company preference is to give view access to others that ok, but no one but the designated CNC security admins should have the ability to alter security. That's the reason it is called security if it's open then it's not security

Kevin,

Of course it should be a CNC person - 1 primary and 1 backup in my opinion.

Security is more than just application access - it may at your site include Row and Column (data) security - which requires a good understanding (and sometimes testing) of what can be affected by a knowlegable CNC person. If this applies then try using the argument that a non-CNC person can damage/corrupt the system if they don't know what they're doing (FUD - Fear, Uncertainty, and Doubt - can work for you).

I remember a bank I used to work at where a non I.T. person was the security administrator per management policy. We (I.T.) provided all the tools, training, deciphered requests, and told this "administrator" exactly what to do on every request - but Management was happy because I.T. wasn't "controlling security". :}

Good Luck Kevin

There are two issues here: the first, a functional segregation of duties to prevent unauthorized access to company data; second, placing competent (as well as responsible) employees in charge of this function.

In the many roles that I have played in my career, I have seen the damage that can be caused by not separating the record keeping functions from access granting functions. The main questions to ask are: what data (corporate internal financials, payroll) are most in need of safeguarding, what the exposure is (lawsuits, loss of business) if this information were to be exposed, who has access to the data and what checks are in place to ensure that this data is not put at risk. We are put in charge of the safeguarding of this information, and IT departments are (generally) good in setting up such checks and balances in their own area. When the number of users who have the ability to set up system access extends beyond the department, the risk of exposure of the information increases.

Equally as important as controls over those who could knowing grant improper access is ensuring that competent, capable people are in charge of this access function. As everyone can attest to, the security on the OneWorld product is extensive and complex. Thus, those who know the software best are the best suited for the task of setting and maintaining security. Those outside of IS often do not have an appreciation for the complexity of "locking down" the software.

Your note does not mention how big your company is, or your IT department. This however is a topic of significant import as to suggest a meeting of the department heads, and if possible, a discussion with the IT portion of your audit firm (if this applies).

Kevin,

Your proposed scenario is in practice at my company.

Here are our checks and balances for US security requests (We have five countries using our system, each country manages security independently).

1) A business lead puts in a security request to the JDE Business Support team.

2) The Business Support team evaluates the request, obtains approval from functional area owners (a finance manager approves finance changes; procurement approves procurement changes, etc).

3) A business App lead, who has view only access to the security workbench, composes the security change request and sends the request over to the CNC group.

4) The CNC group makes the appropriate changes to security and sends a note back to the business informing them that the change has been made.

5) The Business App lead communicates with the user that their change has been made.

Other aspects to this partnership. The JDE Business Support Team does our QA testing of security changes and custom applications. The JDE Business team provides second tier application support (the first tier is the Help desk). We employ both internal auditors, both IT and business, and external auditors to periodically review our system. All audit findings are reviewed and scrutinized. We have defined global standards for data integrity, security, programming conventions, UDC control and more.

We rely on JDE software to help us manage a Fortune 500 corporation. We have support from the top levels of IT and the business to "run a tight ship." Taking security seriously is one of the cornerstones of that idea.

Good luck in battening down your hatches!

Gregg Larkin
North American CNC, Praxair, Inc.

Production system: XE, SP19.1, Win2K, SQL 2K, Citrix XP
Test System: XE, SP21, Win2K, SQL 2K, Citrix XP, Websphere, XPI

Thanks for the responses! I only received reponses that basically agreed with my thinking though.

Just so you know, here's a little bit about our company:
We have 5 separate OneWorld Installs (all running Xe) within the company and we use Financial, Sales, Payroll, Inventory Management and MRP. For 4 of the sites I am the CNC guy. We do have someone else who spends about 60% of his time doing CNC stuff too. On the applications side we have approximately 20 people which includes a project manager, system analysts and programmers. These people do all the applications stuff for 4 of these sites too. (the other site is has its own IT staff)

Anyway, the Head Office is really the first site to be implementing security and that is where we do Financials and Payroll. The other sites have been mostly manufacturing and sales and the security was setup a couple years ago but we will be changing the whole company setup after we get security implemented and the procedures drawn up at the head office.

The big thing here for me is that the old legacy system currently has the programmers for each program granting security and they want to model that within OneWorld. I don't agree and I just wish I had hard evidence to show why we shouldn't be giving the security workbench to anyone other than the CNC people. And if we set it up like this for our head office we will end up setting up the same for all the divisions.

Kevin

The Programmers should only have security to access the PY environment.

CNC should control security.

The best approach to security is to allow access on a Function/Role basis. How are the programmers to know who should be allowed to use an application?

I assume this is a limitation of your legancy set up, this is a good opportunity to put it right.

Programmers should have limited access to OMW with well defined roles, to limit them to development work.

The absolute best way to handle this situation is to make those who have access to the security- responsible for the security. You'd be amazed at how quickly the folks who wish to have access to security run away when you ask them to sign off on approval and create a true responsibility.

Interesting that all the people advocating that CNC Team contain security are CNC Team members! We oeprate multi national / location sites and we centrlise the 'role' as a role - Security Officer. With the correct procedures in place this person can control access also to the CNC Team!! This person is the last defence against segregation of duties issues and is available 24/7 to address existing and new requirements. Auditors love this.

Whoever is the security person needs to understand the OneWorld system from a technical and applications perspective. The security request that come from the application team often do not translate directly into OneWorld security. Once translated into OneWorld security it has to be evaluted on the basis of impact to other application and occasionaly against system performance and reliability. You can crash application by placing security on certain rows and columns.

Does this person need to be CNC? 'No'. However 'CNC' tends to be where this task ends up because you can find a person who has a grasp on both the technical and application side.

Security is a combersome and thankless task. If someone else wants the task, CNC should be glad to let it go and give them support as needed to ensure their success. The key with security is to have a single person responsible and a good security plan.