RE: User Security Advice

["Brian Piotrowski" <bpiotrowski@xxxxxxxxxxxxxxx>]

Excellent ideas, everyone - thanks!  I appreciate the input.  Now to
figure out an attack plan. :)

Thanks!

/b;

-----Original Message-----
From: Al Mac [mailto:macwheel99@xxxxxxxxxxx] 
Sent: Thursday, September 21, 2006 12:13 PM
To: Midrange Systems Technical Discussion
Subject: Re: User Security Advice

I suggest expanding the PF design to house some code representing 
application such as General Accounting, or specific areas of Accounting,

such as General Ledger, that the relevant dept head may want to limit 
different people different kinds of access different areas.  So you have
a 
code like A* for Accounting, AG for General Ledger.  Develop this for
all 
applications.  Include IT dept e.g. accessing Security itself.  Instead
of 
a set of flags for ALL programs, you have ALL application areas, with
room 
for some growth.

So basically for an application like General Ledger, you'd have some
codes 
representing major activities ... is this person allowed to delete old 
journals, are they allowed to update journals, can they see critical 
accounts like owner's equity.  You come up with a set of access rules by

application manager desires, and recognize the software may not be 
structured to permit this set of rules to be implemented immediately,
but 
what you are doing is designing the security file to support reasonable
needs.

In the comments in the front of each program source code you have a 
reminder to the programmer about its security classification.  If ANYONE

asks you to modify this program to support activities outside this
security 
classification, identify relevant department heads who should be
notified 
what is going on here.

In front of EVERY program you'd have a CL to call the security checking 
routine.  It have parameter saying "I am accounting or whatever granular

area" and to run me people need whatever security classification.  This 
routine returns a YES GO or NO STOP flag to the calling program.  If the

result is NO, it might also send a MESSAGE to a security message queue
... 
such and such a user tried to run whatever software but did not have the

proper clearance.  This would be reviewed by the relevant dept managers
to 
say whose security and what programs ought to be adjusted to different 
security settings.

Can people access this stuff without going thru the front door menus, 
particularly the security file itself?  Does this stuff need to be
encrypted?

> Hi All,
>
>
>
> Does anyone have any advice on protecting home-grown programs and user
> security?  Right now we have a very rudimentary security system that
> protects programs based on the users "level".  This level has nothing
to
> do with the built-in security used by the AS/400.  Instead, there's an
> additional PF that houses the username, a security category (ie: "A"
for
> all programs, "S" for only scanning programs, etc.). and a security
> level (3 - can do everything, 0 - can do very little).
>
>
>
> We're looking at revamping our entire security system to make it more
> granular.  Instead of having a broad security level such as "A3", I'm
> looking to go right down to the menu items and restrict on that.  So if
> we have "001 - Production Control, 002 - Trailer Control, 003 - User
> Profiles", I would have the user maintenance program allow access to
> 001, and 003 for a user, but restrict them from using 002.
>
>
>
> However, we have almost 275 programs spread across 15 menus, so a
user's
> profile may be large because in addition to their name and password,
> they will have an extra 275 fields that will have a "Y" or "N" in them
> to restrict their access to the programs.  Furthermore, when new menu
> items are added, I will need to go into the user profile program and
> update all records.  So I'm not sure if this is a viable solution.
>
>
>
> I thought I'd consult the group for some advice, since I'm sure there
> are others who have done this before.  If not, are there any good
> Redbooks that cover this issue or has everyone rolled out their own
> security solutions?
>
>
>
> Thanks!
>
>
>
> /b;
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> Brian Piotrowski
>
> Assistant Mgr. - I.T.
>
> Simcoe Parts Service, Inc.
>
> Ph: 705-435-7814 x343
>
> Fx: 705-435-6746
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.