Using a generic userid for processing

As per SOX, use of generic IDs is big "NO". I have been with E&Y auditors several times on this issue. The issue here is if

Generic IDs are used, it is very hard to pin point any perticular individual and typically users are less carefull in securing the password.

So although this is very inconvinient at times, use of generic IDs should be avoided at all costs.

 

 

Also as far as Jobs and reports are concerned, those can be copied to the new user ids.

I have been told to eliminate generic ids by auditors as well. Even an IT id is frowned upon. Some companies use this to keep the number of named users down, but I don't think it will fly much longer.

That's very true. Each ID needs to be deleted or modified every time the employee leaves or changes the job function. I guess this is the best way to hold people responsible, of course this is lot of inconvenience to business and additional work for IT and security group.

EDI and Process Flow processes are typically run under generic users. These id's will often have expanded permissions and security access. I am uder the impression that Lawson documentation suggests using such id's when the product is installed. The output of their jobs however must be monitored by a real user.

Keys to SOX compliance are Monitoring and Evidence. These are two requirements stated within the law. As long as these requirements are being met, the type of user is not mandated. [The generic user must be subject to authenicatation and password security in the same fashion as a real user.] Thus, where a process has been automated with a generic user, AND a seperation of duties is required, you can implement an approval (validation) process to comply with SOX standards.

how do you identify the actual person using the generic id if you find that the id is doing something that it should not? How do you enforce segregation of duties if the people in these roles all have the ability to login to the generic id?

You can't, but no user other than the administrator should ever know the passwords for those IDs.

Do you think that is true in practice?  Or, how do you prove that to an auditor?

We do use generic IDs for our daily/monthly recurring jobs and for interfaces that run into Lawson. We ran into a problem with auditing because IT's real user IDs were linked to changes in employee records due to the interfaces and recurring jobs so we use these generic IDs to keep the employee records clean. I understand that this could be a security risk if the passwords get out but this is what is best for us right now.

Using the generic IDs to run the automated processes is not really the issue as long as it can be tracked back to being an automated process. The output of any automated job can be sent to distribution lists or ProcessFlow tasks which would not require anyone knowing the generic login and password to monitor and receive the automated data. The disrtribution lists and ProcessFlow tasks would need to be maintained as people come and go so that the data is still being sent to a real person for monitoring.

You can also modify the automated jobs without having to log in as the generic user.  I monitor all EDI, ProcessFlow and Fax jobs which run under a generic user.  I have no access to the password for the generic id.  When I need to modify or fix a job in recdef or jobdef I can access all jobs under that generic id logged in as myself in LID. 

Jon

MMISS, MidMichigan Health

Hi All -

Another thought here is to keep the generic ID for the system jobs and use Process Flow to actually trigger the jobs from a "Job Approval" inbasket, thereby capturing the WF-ID in the WFACTIVITY / WFMETRICS tables for the SOX Auditors.

Control User Security access through the BPM Menu and RM etc.

You could also add Job Error Handling & Notification in your flow by querying QUEUEJOB table as well as limit any user induced process variation on job execution.

A client last week completely hosed their payroll when their Payroll manager ran the job with incorrect parameters, causing the ACH to be stopped at the bank, checks cancelled and later retransmitted. PFI submitting the job would have prevented this catastrophe caused by the functional user....

Dear All,

The genric Id's scenario can be handled by PIM solutions (Privilege identity management).
There are tools that helps in logging, monitoring and keeping track of each and every activity performed by each and every individual in your organization.
One such tool is ARCOS. Well even though we use Generic Id's, but the user has to first login through his Unique id. And ARCOS will take care of the rest.

:)

Regards,

Ashish Karkera,
ANB solutions,
India

Dear All,

The genric Id's scenario can be handled by PIM solutions (Privilege identity management).
There are tools that helps in logging, monitoring and keeping track of each and every activity performed by each and every individual in your organization.
One such tool is ARCOS. Well even though we use Generic Id's, but the user has to first login through his Unique id. And ARCOS will take care of the rest.

:)

Regards,

Ashish Karkera,
ANB solutions,
India