Hi Hennie, Yes correct it is not the SOX way but it was to highlight that SOX basically is only as good as the ppl using it...if really I want to get around it I just either sit on some else vacant PC or ask them to login in my PC using their user id...its not right but 99% of the time you would not have much of a problem doing 'fraudulant' things this way...hence why I mentioned regular binary comparison of files by the customer is still a must if they want extra SOX brownie points (or rather avoid long winded discussions/arguments with the auditor's 'SOX theory masters').
I look forward to hearing more input on this topic from the group as this is something MBS MUST address otherwise many prospects can be waved good bye to in my personnal opinion. I believe a version of SOXs is already being formulated in the EU/Europe (maybe its already out I don't kow?) so this will not be limited to US listed companies. So things like user settings being saved in AOD files (not sure if they are as I mentioned) are things MBS should fix and save us all some headaches with auditors and heart ache with lost prospects....maybe the group would like to put their brains together and think of Axapta areas that are at risk of failing such an audit and possible solutions? Thanks James -----Original Message----- From: Axapta-Knowledge-Village@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Hennie Potgieter Sent: 15 July 2005 16:26 To: Axapta-Knowledge-Village@yahoogroups.com Subject: RE: [Axapta-Knowledge-Village] SOX compliance of Axapta Hi James, Thanks for your comments. I agree that copying the entire AOD file for the layer in which you develop should enable you to disable development tools in live and would also provide better version control in that you can copy the AOD file into a 3rd party source version control system and thus easily keep n, n-1 and n-2 versions of your live environment as per SOX requirement. You also wrote "I could just use another normal users network login". This is of course not allowed by SOX. Correct SOX way of doing things is to request a new login from the "User Administrator" (for lack of a better term) that is only active for a limited time to do what you agreed to do. Hennie -----Original Message----- From: Axapta-Knowledge-Village@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of James Flavell Sent: Friday, 15 July 2005 03:38 AM To: Axapta-Knowledge-Village@yahoogroups.com Subject: RE: [Axapta-Knowledge-Village] SOX compliance of Axapta To add to this: To pass the audit supposedly the way you should do live changes is not XPO/projects but via complete AOD files this way you can turn of dev tools in the live. So changes should be put into test system where user test and when okayed full test AOD moved to live (and remember to move any new permissions as well!!!) This will pass SOX audit ok I believe (experience is from XAL but same concepts apply). A few other thoughts/experience that might help .. basically I the developer have no rights to get to the live system (done at OS file level) therefore any raise requires me to request the customer to provide access to the live for a given period of time that I can move AOD files etc overall this basically means it is very difficult for any change to be made to the appl, of course it is not impossible (I could just use another normal users network login) but the final step is for binary file comparison by the customer to allow detection of any change in AOD files. The main problem I had with XAL and I am not sure whether it also exist in Axapta is: In XAL the main problem was any user setups on screens (hide fields etc) and filters was saved in the AOD (*_UTIL) and so these files had to be kept as read and write. If the AOD can be made read only (e.g. hopefully in Axapta the user settings can be contained in a separate file, if they are in the AOD I suggest you make a service request to MBS to change it for SOX compliance etc) then you should be able to lock down the dev side of Axapta no problem. Maybe someone can tell us where are user chagnes kept? And yes SOX is a real killer for EVERYONE involved, the only ppl who benefit are the audit firms who charge huge amounts to the customer to make them run their business twice as slow! I understand the reason behind it all but really in practice you will see it really is a bit of a joke...a sad joke at that! In closing, Axapta comes from a very open/flexible approach...SOX basically wants everything locked down and segregation of dutys for each user so your task is to change the fundamental thinking of the design of Axapta! Good luck :) Some SOX examples (for your enjoyment and my rehabilitation - yes it was really that bad an experience doing it for XAL which does not have field level permissions!) ... I have a customer who has the MD's secetary as the user rights admin...why? Because they need someone who does not use the system for any financial transactions to be in charge of assigning rights etc...you can imagine the amount of hotline calls I have had from this person who knows nuts about IT and even less about access rights!!! All the best James -----Original Message----- From: Axapta-Knowledge-Village@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Hennie Potgieter Sent: 14 July 2005 22:28 To: Axapta-Knowledge-Village@yahoogroups.com Subject: RE: [Axapta-Knowledge-Village] SOX compliance of Axapta Hi, We just went through a massive worldwide SARBOX audit and in myself and our auditors' opinion, Axapta is not SOX compliant. We did pass the audit however because of the implementation of a number of mitigating controls. Some of the issues were: 1. Source version control and project locking in Axapta is insufficient. 2. Development tools need to be enabled in live environment to be able to import XPO's from test environment. This was a major problem. 3. The fact that projects (XPO's) need to be recompiled in the live environment after importing (you may not recompile code in live) 4. Axapta does'nt automatically force a password change after first logon when the Administrator resets your password. 5. Passwords can be cleared through the database. 6. Data model changes are made by developers through the AOS and not the DBA. These were only some of the issues/shortcomings that came up. Cannot think of everything right now. Ironic thing is that in 1995 the USA proclaimed the "Paper Reduction Act" and now with SARBOX additional, filed paperwork with signoffs for just about everything is encouraged. Hennie -----Original Message----- From: Axapta-Knowledge-Village@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of ramyakrishnan_1023 Sent: Thursday, 14 July 2005 14:39 PM To: Axapta-Knowledge-Village@yahoogroups.com Subject: [Axapta-Knowledge-Village] SOX compliance of Axapta Hi All, can somebody throw light on whether Axapta is SOX compliant. If so where can I find some details on the same. thanks ramya Sharing the knowledge on Axapta. Yahoo! Groups Links Sharing the knowledge on Axapta. Yahoo! Groups Links Sharing the knowledge on Axapta. Yahoo! Groups Links Sharing the knowledge on Axapta. Yahoo! Groups Links Sharing the knowledge on Axapta. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/Axapta-Knowledge-Village/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
