RE: Security Model for iSeries Appllications

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.