Re: Change Management

Bryan,

My recommendations would be the following:

1) Analyze which specific tasks your staff needs *ALLOBJ for. Create specific programs (you'll probably only need CLPs) that adopt *ALLOBJ to do ONLY these functions and secure the programs so that only the relevant staff members can run them. Document the rules for granting authorities to the programs and for using them.

2) Analyze why your files have *PUBLIC *CHANGE. MAPICS ships with *PUBLIC *EXCLUDE, after all, and all MAPICS programs adopt AMAPICS authority so that they can work with them. If you have programs of your own that use MAPICS files, why not use the same scheme? Be sure to document whatever you do.

3) If you have files that users need *READ access to (for queries or other things where adoptive authority is difficult to use), consider using authorization lists for them. Yes, there's a (very small) performance impact at file open, but it's negligible for any decently-sized modern system. Use the same authorization list for each file group and maintaining access takes very little work. Make sure you document whatever you do.

Third-party tools can make managing access easier. In addition to security tools, you might also want to consider change management tools like TurnOver or Implementer. My suggestion, though, is to decide how you want to manage your system first, and then look at tools to support that. Systems that are well-thought-out and capable of being managed manually are much easier to automate with tools.

Ultimately, though, if you want to satisfy SOx auditors, documentation is everything. Well defined, well documented, sensible processes will almost always pass audit; poorly documented practices based on expediency will not.

Good luck with whatever you do!

Dave Shaw
MAPICS-L moderator

----- Original Message ----- From: "Burns, Bryan" <Bryan_Burns@xxxxxxxxxxxx>
To: <MAPICS-L@xxxxxxxxxxxx>
Sent: Thursday, July 24, 2008 9:03 AM
Subject: [MAPICS-L] Change Management

We'll be undergoing an internal controls IT audit later this year and like a lot of small shops, our MIS staff has *ALLOBJ special authority in their user profiles. In addition, all our AMFLIBx files have authority for *PUBLIC as *CHANGE. Because our users don't have a command line and we control ODBC updates through an exit point package, *PUBLIC having *CHANGE to files isn't an issue. But the MIS staff having *ALLOBJ to production files and being able to DFU any one of them is an issue.

I believe there're at least 3 ways we can approach this:

1. Implement object level authority. (This is something management really doesn't want to consider).
2. Run a nightly program to GRTOBJAUT of *EXCLUDE for every object in our production libraries for every MIS user profile. In addition, remove *ALLOBJ special authority from the MIS user profiles.
3. Implement a third party package like Authority Broker from the PowerTech Group.

Have any of you had a similar security set-up as we have and had to comply with Sarbanes-Oxley regulations or something similar? If so, I'd like your input on the three approaches above or any other approach you might recommend.