Re: Change Management

Phil,

I use PowerTech's PowerLock Network Security Product.


How big is your IT staff? Our total staff is 7 and only three are developers...

Bryan



-----Original Message-----
From: mapics-l-bounces@xxxxxxxxxxxx [mailto:mapics-l-bounces@xxxxxxxxxxxx] On Behalf Of Phil_Campa@xxxxxxxx
Sent: Thursday, July 24, 2008 12:26 PM
To: MAPICS ERP System Discussion
Cc: mapics-l-bounces@xxxxxxxxxxxx; MAPICS-L@xxxxxxxxxxxx
Subject: Re: [MAPICS-L] Change Management

We restrict all access to production data and source code changes for all
our IT staff.
If they need to correct a problem or modify a code the user needs to submit
a help desk request.
This request is evaluated by IT to see if it is a data or user issue. If
the request is approved the
programmer can checkout the source code or access the production
environment via the
'Authority Broker Profile. (PowerTech Group Software). The software
logs this activity and log the help desk.

Bryan, What is the name of your ODBC security software? Thank you




"Burns, Bryan"
<Bryan_Burns@Echo
-usa.com> To
Sent by: <MAPICS-L@xxxxxxxxxxxx>
mapics-l-bounces@ cc
midrange.com
Subject
[MAPICS-L] Change Management
07/24/2008 05:59
AM


Please respond to
MAPICS ERP System
Discussion
<mapics-l@midrang
e.com>






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.

Thanks in advance,


Bryan Burns