× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.







It's more than a signon program.  If I have a user profile with limited
capability and a signon program specified, there are a variety of methods I
can use to execute commands even though my user profile and JBA are both
set up to prevent this.

Again, if you are not using exit programs, you can not secure an AS/400.

Thanks.

Charlie Massoglia
Chief Information Officer
mailto:cmassoglia@xxxxxxxxxxxxx
517-780-4336
Fax:  517-789-4503




                                                                           
               "Santos, Fred"                                              
               <Fred.Santos@Nor                                            
               thSafety.com>                                            To 
                                        <CMassoglia@xxxxxxxxxxxxx>,        
               06/08/2006 08:58         "System 21 Users"                  
               AM                       <system21@xxxxxxxxxxxx>            
                                                                        cc 
                                        <bharper@xxxxxxxxxxxxxxxx>,        
                                        <mdearmond@xxxxxxxxxxxxxxxx>       
                                                                   Subject 
                                        RE: [SYSTEM21] Control of database 
                                        updates for Sarbanes-Oxley         
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




You are correct.  I left out that we setup our live users to go directly
into S/21.    Once in S/21, they cannot enter commands.

-----Original Message-----
From: CMassoglia@xxxxxxxxxxxxx [mailto:CMassoglia@xxxxxxxxxxxxx]
Sent: Thursday, June 08, 2006 8:35 AM
To: System 21 Users
Cc: bharper@xxxxxxxxxxxxxxxx; mdearmond@xxxxxxxxxxxxxxxx; Santos, Fred
Subject: Re: [SYSTEM21] Control of database updates for Sarbanes-Oxley





While your overall approach is quite good, I am a little concerned about
one statement you made:

4. Finally, Use the System/21 Administrative Functions to control that
none of your "LIVE" users have Command Line Authority.  This will stop
them from running SQL and other update jobs.

First, I assume there are some additional parameters you specify on user
profiles such as FRED:

Current library  . . . . . . . . . . . . . :   *CRTDFT
Initial program  . . . . . . . . . . . . . :   JBAPRDEXP (or whatever)
  Library  . . . . . . . . . . . . . . . . :     *LIBL
Initial menu . . . . . . . . . . . . . . . :   *SIGNOFF
  Library  . . . . . . . . . . . . . . . . :
Limit capabilities . . . . . . . . . . . . :   *YES

The key here is to specify LMTCPB(*YES).

However, even after restricting command line authority in JBA and in the
user profile there are numerous methods these profiles can run commands
on
the AS/400.  I am not sure you can prevent a user from running commands
no
matter how the user profile is created unless you use exit programs to
secure a variety of functions.

Again, your approach is excellent.  I just want to make sure you
understand
your people can execute commands using a variety of methods.

Thanks.

Charlie Massoglia
Chief Information Officer
mailto:cmassoglia@xxxxxxxxxxxxx
517-780-4336
Fax:  517-789-4503






               "Santos, Fred"

               <Fred.Santos@Nor

               thSafety.com>
To
               Sent by:                 "System 21 Users"

               system21-bounces         <system21@xxxxxxxxxxxx>

               @midrange.com
cc
                                        mdearmond@xxxxxxxxxxxxxxxx,

                                        bharper@xxxxxxxxxxxxxxxx

               06/07/2006 09:10
Subject
               AM                       Re: [SYSTEM21] Control of
database
                                        updates for Sarbanes-Oxley



                Please respond

                      to

               System 21 Users

               <system21@midran

                   ge.com>









Dan, we have completed our SOX controls here at NORTH Safety.  We feel
we have a very good control and verification of changes.  The question
you raised, we resolved by creating Group Teams to work in each of our
Three environments,
OY1 (live),
TST (User Testing),
DEV (Programmer Development testing)

1. We started by creating a dummy user OY1TEAM, one for each team.  This
ID is disabled.   And only used for Supplemental Grouping.
                          Display User Profile - Basic

 User profile . . . . . . . . . . . . . . . :   OY1TEAM

 Previous sign-on . . . . . . . . . . . . . :
 Sign-on attempts not valid . . . . . . . . :   0
 Status . . . . . . . . . . . . . . . . . . :   *DISABLED
 Date password last changed . . . . . . . . :   05/28/99
 Password expiration interval . . . . . . . :   *SYSVAL
   Date password expires  . . . . . . . . . :     08/26/99
 Set password to expired  . . . . . . . . . :   *NO
 Local password management  . . . . . . . . :   *YES
 User class . . . . . . . . . . . . . . . . :   *USER
 Special authority  . . . . . . . . . . . . :   *NONE
 Group profile  . . . . . . . . . . . . . . :   *NONE
 Owner  . . . . . . . . . . . . . . . . . . :   *USRPRF
 Group authority  . . . . . . . . . . . . . :   *NONE
 Group authority type . . . . . . . . . . . :   *PRIVATE
 Supplemental groups  . . . . . . . . . . . :   *NONE

2. We then assigned all live users to be a part of the Supplemental
group
User profile . . . . . . . . . . . . . . . :   FREDS

Previous sign-on . . . . . . . . . . . . . :   06/06/06  14:01:02
Sign-on attempts not valid . . . . . . . . :   0
Status . . . . . . . . . . . . . . . . . . :   *ENABLED
Date password last changed . . . . . . . . :   03/30/06
Password expiration interval . . . . . . . :   *SYSVAL
  Date password expires  . . . . . . . . . :     06/28/06
Set password to expired  . . . . . . . . . :   *NO
Local password management  . . . . . . . . :   *YES
User class . . . . . . . . . . . . . . . . :   *USER
Special authority  . . . . . . . . . . . . :   *NONE
Group profile  . . . . . . . . . . . . . . :   QPGMR
Owner  . . . . . . . . . . . . . . . . . . :   *GRPPRF
Group authority  . . . . . . . . . . . . . :   *NONE
Group authority type . . . . . . . . . . . :   *PRIVATE
Supplemental groups  . . . . . . . . . . . :   OY1TEAM

3.  We assigned Object Authority to all Physical Files in our live
environment, to allow QPGMR to "*USE" the data with the Team Group
"*ALL" Authority.  This allows the programmers to refresh data in DEV or
TST, But does not allow them to change.  "Any" program that tries to
perform an update to a physical file, and the user is not in the
OY1TEAM, will crash.

                            Display Object Authority

 Object . . . . . . . :   INP35           Owner  . . . . . . . :   QPGMR
   Library  . . . . . :     OY1@@F3       Primary group  . . . :   *NONE
 Object type  . . . . :   *FILE           ASP device . . . . . :
*SYSBAS

 Object secured by authorization list  . . . . . . . . . . . . :   *NONE

                          Object
 User        Group       Authority
 *PUBLIC                 *EXCLUDE
 *GROUP      QPGMR       *USE
 OY1TEAM                 *ALL


4. Finally, Use the System/21 Administrative Functions to control that
none of your "LIVE" users have Command Line Authority.  This will stop
them from running SQL and other update jobs.
XA100           Administration Functions                      System:
NSPS204
   Maintain User Profiles
    User Profile
Process
    CRPC1      * User not defined to OS/400 *
*Update

   Type changes, press Enter and then F3 to Update
    User level. . . . . . . . . . . 9 (1=Novice,3=Expert,8=Nov
Grp,9=ExpGrp)
    Initial menu  . . . . . . . . . AM
    Default sign-on company . . . . A2
    Single application task . . . .
    Default development application
    Language code . . . . . . . . .
    Default job queue / library . . QBATCH      /  QGPL
    Default print queue / library . PRTCRPUR01  /  QUSRSYS
    Hold on print queue . . . . . . 1       (1=Yes,0=No)
    Authorized to common functions  0       (1=Yes,0=No)
    Sign-off on leaving system. . . 1       (1=Yes,0=No)
    Date format (D/M/Y) . . . . . . M
    Allow submit job prompt . . . . 1       (1=Yes,0=No)
    Allow command entry . . . . . . 0       (1=Yes,0=No)
    Message delivery. . . . . . . . *USER
(*NOTIFY,*BREAK,*HOLD,*DFT,*USER)

5. We set each of our Environments up this way.  It works very well.  No
user can maintain "Live" data outside the System/21 Menu System.

6. You ask what happens in the event data "must" be patched in live and
no S21 function exists?

The Operations Staff has full control of assigning Authorities and User
Profiles.   They have a special user profile called "PRODUCTION".  This
user is normally disabled.  It can be activated by special written
authority, to allow corrections to data.   The correction is logged with
the request, and the update must be verified by the IT Manager,


-----Original Message-----
From: system21-bounces@xxxxxxxxxxxx
[mailto:system21-bounces@xxxxxxxxxxxx] On Behalf Of
DThomas@xxxxxxxxxxxxxxxx
Sent: Tuesday, June 06, 2006 3:55 PM
To: SYSTEM21@xxxxxxxxxxxx
Cc: mdearmond@xxxxxxxxxxxxxxxx; bharper@xxxxxxxxxxxxxxxx
Subject: [SYSTEM21] Control of database updates for Sarbanes-Oxley

We are interested in restricting database updates outside System 21
applications.  Our thoughts are to limit these changes (which should be
rare) to DBU and use the DBU auditing utility.  We wish to prevent use
of
interactive SQL (STRSQL) and DFU.  I'm looking for feedback from other
companies that have gone through the same issue.  Also, would
restricting
use of STRSQL affect embedded SQL statements in System 21 RPG programs?



Dan Thomas
Vice President
RxCrossroads
4500 Progress Blvd
Louisville, KY  40218-3420
Office Direct (502) 318-1208
Cell (502) 931-3736
Fax (502) 318-1128







This information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material, the disclosure of which is governed by applicable law.  Any
review, retransmission, dissemination or other use of, or taking of any
action in reliance upon, this information by persons or entities other
than the intended recipient is prohibited.  If you received this in
error, please contact me and destroy the materials contained in this
message.


_______________________________________________
This is the System 21 Users (SYSTEM21) mailing list
To post a message email: SYSTEM21@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/system21
or email: SYSTEM21-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/system21.



_______________________________________________
This is the System 21 Users (SYSTEM21) mailing list
To post a message email: SYSTEM21@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/system21
or email: SYSTEM21-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/system21.










As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.