|
I think the problem is that the policy owner is seriously (and maybe overly) concerned with the perceived ramifications of SOX, and has set the policy higher than (actually) necessary. The amount of money and effort being spent on this (that I can see) is mind blowing... We have security policies, but the main reason I put forward the inquiry was to get exactly what I got - input, outside our box... Thank you. Keep it up! Dave -----Original Message----- From: security400-bounces@xxxxxxxxxxxx [mailto:security400-bounces@xxxxxxxxxxxx] On Behalf Of Patrick Botz Sent: Thursday, August 24, 2006 2:00 AM To: Security Administration on the AS400 / iSeries Subject: Re: [Security400] Journal Receiver Retention for SOX... WARNING SOAPBOX This is another example of why companies need to have written security policies. Policies define, among other things, the organization's interpretation of SOX. If SOX (or any other regulation/standard) does not specifically mandate settings (and most don't, or only in a very few instances), then as long as a system administrator has implemented the organization's policies, the auditor has to argue with the policy owner. I understand that many companies and system administrators assume -- incorrectly -- that sysadmins are responsible for defining policy. But that's one of the main reasons for SOX. SOX is an attempt to make the rightful owners of policy legally responsible for policy (not to mention its implementation). Corporate officers or management are ultimately responsible for defining which employee roles are allowed to perform which functions on which business assets for which purpose. System administrators are only responsible for ensuring those policies are enforced on their systems. For example, it is management's responsibility to declare that only accounting department employees are allowed to use the HR salary database using the payroll application in order to print payroll checks. It's the system administrator's responsibility to implement appropriate security mechanism in order to enforce this policy. It follows that it is management's responsibility to define/declare data retention periods, etc...
From a sysadmins point of view: Got Policy? Don't Got SOX issue...
END SOAPBOX Patrick Botz Senior Technical Staff Member IBM Lab Services, Rochester Security Architecture & Consulting, i5/OS Security Architect (507) 253-0917, T/L 553-0917 CTC Fax # 507-253-2070 email: botz@xxxxxxxxxx For more information on CTC, visit our website at http://www.ibm.com/eserver/services http://www.ibm.com/servers/eserver/services _______________________________________________ This is the Security Administration on the AS400 / iSeries (Security400) mailing list To post a message email: Security400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/security400 or email: Security400-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/security400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
