Dennis, I would repost this on the midrange-l list, the security list has been so quiet for so long I had almost forgotten it was here. Having said that, I have the following questions and _partial_ recommendations: 0) Given that the word "Bank" is in your company name I would suspect that there are auditors that will want some say in any plan. 1) Do you have a change-control process? Is there software that manages source access, changes and promotions. Also, does that software maintain historical copies of source? 2) What is the current security model? It's very hard to revoke rights (from a managerial point of view, not a technical one) from people that have had access to data for a long time. 3) Revoke *PUBLIC rights to the world. Make a production user id (PRODUSER works) and grant that user change rights to the files. Make your production files owned by PRODUSER and use adopt authority. This way the only access people have to your files is through your programs. 3) ODBC makes life harder. Ideally you would use only stored procs to access the files and as such adopt authority would work. However, if you need "raw" access to the files then I would grant read (and ONLY read) access to the files. If there is a need for updating files make them use stored procs. I would also look at either writing your own exit programs or buying a package to monitor and control ODBC access. 4) In this model ad-hoc access (DFU, DBU, SQL, etc.) is difficult. There are two approaches to this access that I've seen, both have merrit. In both cases it's only IT staff that can use these, these tools are _never_ in the hands of an end user. In the first there is a generic user that has access to the files. This user is used by anyone that needs to use these ad-hoc tools. However, to signon as this user you must request access which is logged so you know who is really making the changes. The advantage to this approach is that you have an easier time granting access to files. The generic user is ganted access to everything. The disadvantage is that you must look at the log file to see who was really using that generic user profile. In the second approach your staff requests access to each file they need to update. Access is granted, the changes made and access revoked. The advantage to this is that the human user making the change is the same as the user profile used. The disadvantage is the increased administrative work of granting and revoking access. 5) As far as source access goes. I would say that _all_ access to source must be done through a source control program. In effect your programmers have read access to the source libraries, but no update rights. This way any updates are logged and can be rolled back if necessary. Security is not something you are ever done with. You can't implement security and call the project "complete", it continues to evolve for ever. Also, you make no mention of security of either the LAN or tapes, don't forget those either. -Walden ------------ Walden H Leverich III President Tech Software (516) 627-3800 x11 (208) 692-3308 eFax WaldenL@xxxxxxxxxxxxxxx http://www.TechSoftInc.com Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.) -----Original Message----- From: Dennis Nel [mailto:dennisn@xxxxxxxxxx] Sent: Monday, June 02, 2003 9:24 AM To: security400@xxxxxxxxxxxx Subject: [Security400] Security Model for iSeries Appllications Hi there! I am looking for an "EASY" to implement security model for the iSeries. We have an application (Green screen mainly, with some access via ODBC) with 4 libraries, Database and Object code for pgm's and file's. There are also libraries for Source code. What is the best approach to take, i.e. with group profiles, who owns the libraries, what should the *Public authorities be? Should I use Authority lists? Your comments and suggestions would be greatly appreciated. Best Regards Dennis Nel PRODUCTION SUPPORT Corporate IT ABSA Corporate & Merchant Bank T : 011 350 8109 F : 011 350 8004 M : 082 808 2687 E : dennisn@xxxxxxxxxx ______________________________________________ "The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. Absa is liable neither for the proper, complete transmission of the information contained in this communication, nor for any delay in its receipt, nor for the assurance that it is virus-free." _______________________________________________ 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.