Audit Serve, Inc.
 |
Technical Articles |
|
|
Conferences |
|
|
Audit Programs |
|
|
Audit Serve Seminars |
|
|
Consulting Services |
|
|
Audit Vision Email Newsletter Free! |
|
|
What's New |
|
|
Contact Us |
The Worldwide Connection for Audit, Security, Control and Euro Project Professionals.
Global Audit Step Ref #:mmgasaaf maj/1.2
------------------
JCL used to generate a listing of commonly referenced audit steps
Audit Steps
-----------
1) Print all members within a partition dataset
//<jobname> JOB <include your site's job card requirements>
//<stepname> EXEC PGM=IEBPTPCH
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=<dataset name>,DISP=SHR
//SYSUT2 DD SYSOUT=*
//SYSIN DD *
PRINT TYPORG=PO,MAXFLDS=1
RECORD FIELD=(80)
/*
This job is used to print all members within a dataset. This is
commonly used to print source members but can also be used to
print sequential data files by changing the TYPORG statement from
PO to PS.
2) Print an individual member from a partitioned dataset or to
print a sequential file
//<jobname> JOB <include your site's job card requirements>
//<stepname> EXEC PGM=IEBGENER
//SYSUT1 DD DSN=<dataset name>(<member name>),DISP=SHR
//SYSUT2 DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
This job is used to print an individual member from a dataset.
This JCL is useful when a large source member needs to be
printed.
3) Print a sequential file
//<jobname> JOB <include your site's job card requirements>
//<stepname> EXEC PGM=IEBGENER
//SYSUT1 DD DSN=<dataset name>,DISP=SHR
//SYSUT2 DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
F1 - Info Ref #: mmgasaaf
Background
----------
JCL standards are different for each installation. Many times,
installations use system exits to enforce these standards.
Therefore, prior to the coding of any JCL member, the
installation JCL standards should be requested.
Variables within the JCL that can be changed
--------------------------------------------
<jobname>
The jobname is 1 to 8 alphanumeric name that is used to identify
the job to the operating system. The jobname that is selected
will appear on the first page of the output listing. Any name
can be selected, but some installations require that the jobname
be the same as the userid submitting the job.
<stepname>
The stepname is an optional alphanumeric name. A stepname is
required if subsequent JCL statements refer to the stepname.
<dataset name>
The dataset name is the PDS or file that is being printed.
<member name>
The member name is the member you want to print.
Key Parameters used within JCL statements
-----------------------------------------
Job Statement
The JOB statement is used to identify the JOB to the operating
system and to initiate the JOB.
The following is a list of commonly used key parameters used
within the JOB statement:
o CLASS=
CLASS specifies the job class. Job classes range from A to Z.
Installations establish a default job class when the CLASS
parameter is not specified in the JOB statement.
o MSGCLASS=
MSGCLASS specifies the JOB scheduler output class. The output
class is a single character. The installation sets a default
when an output class is not specified in the JOB statement. Each
installation has a specific output class that is used hold the
output from being printed. SDSF could then be used to view the
output from the JOB.
o NOTIFY=<userid>
NOTIFY specifies the userid that is sent a message when the JOB
is completed.
o PRTY=
PRTY indicates the JOB's execution priority. 0 - 15 can be
specified.
EXEC Statement
Each job steps begins with an EXEC statement that either invokes
a cataloged procedure or specifies the program to execute.
The following is a list of commonly used key parameters used
within the EXEC statement:
o PARM
PARM is used to pass parameters to the job step.
DD Statement
The following is a list of commonly used key parameters used
within the DD statement:
o DISP=
DISP indicates the data set disposition. In most cases DISP=SHR
is specified.
Steps to view output
--------------------
Instead of having to obtain the steps for printing output and
also to save paper, jobs are submitted to have their output held
in a class which does not print. Products like SDSF (System
Display Search Facility), which is contained on most systems can
then be used to display the output.
Perform the following steps to display output which was submitted
in a held class (i.e., class which does not print).
o Select SDSF from TSO/ISPF panel
o Select H from the SDSF PRIMARY OPTIONS MENU
o Type S in the NP column for the job that you want to display
Global Audit Step Ref #:mmgasaah
-----------------
Determine datasets that are contained on a volume
Audit Step
----------
Determine the datasets that are contained on a volume by
executing the TSO 3.4 option and enter the volume serial number
in the VOLUME field and leave the OPTION field blank.
F1 - Info Ref #: mmgasaah
Background
----------
Volume level is referred to DASD. During the course of the audit
you will need to determine the datasets that are contained on a
specific volume. One example of how it is used is a control
point which determines the users that have volume level access.
In order to determine the sensitivity of this access, you must
determine if the datasets contained on the volume are sensitive.
Global Audit Step Ref #:mmgasaai
-----------------
Determine which volume a dataset resides on
Audit Step
----------
Determine the volume that the dataset resides on by executing the
TSO 3.4 option and enter the dataset name in the DSNAME field and
leave the OPTION field blank.
F1 - Info Ref #: mmgasaai
Background
----------
The 3.4 TSO screen allows the volume that the dataset resides on
to be displayed.
This option can also be used to display the datasets that are
defined within a specific high level prefix.
For example to identify all of the datasets that are defined with
the SYS1 high level prefix type specify the following in the
DSNAME field:
DSNAME ===> SYS1
A screen will be displayed with all of the datasets using SYS1
which can be browsed by placing a 'b' on the left side of the
dataset.
If you wish to identify the amount a space that a dataset has
been allocated and used enter the dataset name and then type 'i'
in the OPTION field.
Masking characters are also accepted if the full dataset name is
unknown.
Global Audit Step Ref #:mmgasaaj
-----------------
Determine the CICS resources that a user has access to using
internal CICS security
Audit Steps
-----------
1) Obtain the Transaction definitions, File definitions, and
Signon Table (SNT) for each CICS region being reviewed.
2) Determine the users that can execute a particular transaction
If macro definitions used for transactions, perform steps 2.1-
2.3:
2.1) Review the Processing Control Table (PCT) and identify the
transactions in question.
2.2) Determine the security key that is set for the transaction
by reviewing the TRANSEC parameter.
2.3) Determine the users that have access to the transaction by
identifying the USERIDs in the Signon Table (SNT) that have
an equivalent security key (i.e., SCTYKEY) that was set for
the transaction. Example: DFHPCT TYPE=ENTRY,
TRANSID=<transaction>,TRANSEC=<security key>
If System Definition File is used to define transactions and CICS
release prior to 3.1.1 perform steps 2.4 - 2.6:
2.4) Review System Definition File (CSD) for Groups that contain
TRANSACTION definitions for the transactions in question.
2.5) Determine the security key that is set for the transaction
by reviewing the TRANSEC parameter in the TRANSACTION
definition.
2.6) Determine the users that have access to the transaction by
identifying the USERIDs in the Signon Table (SNT) that have
an equivalent security key (i.e., SCTYKEY) that was set for
the transaction. Note: all users can execute transactions
that have TRANSEC set to 1 or 0.
Example: TRANSACTION(xxxx) GROUP(<group name>)
TRANSEC(<security key>)
If System Definition File is used to define transactions and CICS
release 3.1.1 and later, perform step 2.7 - 2.10:
2.7) Review the System Definition File (CSD) for the Groups that
contain TRANSACTION definitions for the transactions in
question.
2.8) Determine if security checking is enabled by TRANSEC(YES)
being specified.
2.9) Determine the security key that is set for the transaction
by reviewing the TRANSECNUM parameter in the TRANSACTION
definition.
2.10)Determine the users that have access to the transaction by
identifying the USERIDs in the Signon Table (SNT) that have
an equivalent security key (i.e., SCTYKEY) that was set for
the transaction. Note: all users can execute transactions
that have TRANSECNUM set to 1 or 0
Example: TRANSACTION(xxxx) GROUP(<group name>)
TRANSEC(YES) TRANSECNUM(<security key>)
3) Determine if resource level checking is being used to
restrict the users from the resources that the transaction
in question accesses.
If macro definitions used perform steps 3.1 - 3.3:
3.1) Determine if resource level checking is enabled by reviewing
the PCT for the transaction in question and determine if
RSLC=YES is specified.
3.2) If resource level checking is enabled for the transaction,
determine the resource security key (RSL) set for the
transaction. Identify the users that have access to the
transaction via the security key by comparing each USERID's
RSLKEY to what is specified for the transaction's resource
security key (RSL). Note: If security keys and resource
security keys are both used, the user must have access to
both
Note:
When RSLC=YES and RSL=0 are specified the user is prevented from
using the transaction. RSL=PUBLIC allows all users to use the
transaction if they have access to the security keys.
3.3) Determine if resource security keys are specified for
programs (PPT) and datasets (FCT) that the transaction uses.
Review the associated PPT and FCT entries that are accessed
by the transactions and determine if RSL is specified. If
resource checking is being used, compare each USERID's
RSLKEY to what is specified for the program or dataset's
security key (RSL).
Note: The Programs that is executed by a transaction is specified
in the PROGRAM parameter within the PCT that the transaction was
identified. There is no systematic method for determining the
datasets that are used by the transaction, therefore, this
information must be obtained from the CICS application manager.
If System Definition File is used to define transactions and CICS
release prior to 3.1.1 perform steps 3.4 - 3.6:
3.4) Determine if resource level checking is enabled by reviewing
the CSD group for the transaction in question and
determine if RSLC(YES) is specified.
3.5) If resource level checking is enabled for the transaction,
determine the resource security key (RSL) set for the
transaction. Identify the users that have access to the
transaction via the security key by comparing each USERID's
RSLKEY to what is specified for the transaction's resource
security key (RSL).
Note:
If security keys and resource security keys are both used, the
user must have access to both. When RSLC(YES) and RSL(0) are
specified, then the user is prevented from using the transaction.
RSL(PUBLIC) allows all users to use the transaction if they have
access to the security keys.
3.6) Determine if resource security keys are specified for
programs and files that the transaction uses.
Review the associated program and file group definitions
that are accessed by the transaction and determine if a
Resource Level Key (RSL) is specified. If resource checking
is being used, compare each USERID's RSLKEY to what is
specified for the program or file's security key (RSL).
Note:
The Programs that is executed by a transaction is specified in
the PROGRAM parameter within the transaction definition where the
transaction was identified. There is no systematic method for
determining the files that are used by the transaction,
therefore, this information must be obtained from the CICS
application manager.
If System Definition File is used to define transactions and CICS
release 3.1.1 or later perform steps 3.7 - 3.9:
3.7) Determine if resource level checking is enabled, review the
CSD group for the transaction in question and determine if
RESSEC(YES) is specified.
3.8) If resource level checking is enabled for the transaction,
determine the resource security key (RESSECNUM) set for the
transaction. Identify the users that have access to the
transaction via the security key by comparing each USERID's
RSLKEY to what is specified for the transaction's resource
security key (RESSECNUM).
Note:
If security keys and resource security keys are both used, the
user must have access to both.
When RESSEC(YES) and RESSECNUM(0) are specified, then the user is
prevented from using the transaction. RESSECNUM(PUBLIC) allows
all users to use the transaction if they have access to the
security keys.
3.9) Determine if resource security keys are specified for
programs and files that the transaction uses.
Review the associated program and file group definitions
that are accessed by the transaction and determine if a
Resource Level Key (RESSECNUM) is specified. If resource
checking is being used, compare each USERID's RSLKEY to what
is specified for the program or file's security key (RSL).
Note:
The programs that is executed by a transaction is specified in
the PROGRAM parameter within the transaction definition. There is
no systematic method for determining the files that are used by
the transaction, therefore, this information must be obtained
from the CICS application manager.
F1 - Info Ref #: mmgasaaj
Background
----------
This global audit step is used for identifying the users that
have access to a specific transaction that you are reviewing
based on using CICS internal security.
There are variations to the audit steps that are used based on
the release of CICS that you are running within the CICS region
being reviewed and the method used to define CICS resource
definitions.
Prior to CICS version 1.6 there was only one method available for
defining the transactions, terminals, programs, and datasets that
were used within CICS to perform online processing. These
resource were defined in individual source files which are
referred to as macro definition which had to be assembled in
order to define them to CICS. In CICS version 1.6, transactions
which were previously defined in the PCT (Processing Control
Table) and Programs which were previously defined in the PPT
(Program Processing Table) could now be defined in a VSAM file
called the CICS System Definition File) which is maintained by
the CEDA and CEDB transactions which is also referred to as
Resource Definition Online (RDO). The CSD file is structured
where programs and transactions are preassigned parameters which
is tailored by the installation according to their processing
needs. These resource definitions are assigned to GROUPs which
are attached to LISTs. Each CICS region uses a particular list
based on the GRPLIST parameter that is set in the region's System
Initialization Table.
As of CICS release 1.7, Terminals, which were previously defined
in the TCT (Terminal Control Table) were added to the CSD using
the TERMINAL, SESSIONS, and CONNECTION resource definitions.
As of CICS release 3.1.1, files, which were previously defined in
the FCT (File Control Table) were added to the CSD using the FILE
resource definition.
Transactions can be defined in the Processing Control Table (PCT)
or CICS System Definition File (CSD) if Resource Definition
online used starting in CICS release 1.6. Files can be defined
in the File Control Table (FCT) or CICS System Definition File
(CSD) if Resource Definition online used starting in CICS release
3.1.1.
Audit Step Info
---------------
Since the security parameters that are used are different based
on using macro definitions and CSD and the release of CICS that
you are using, audit steps are provided for each.
When using the CSD file to define CICS resources, the following
must be considered:
Groups are assigned to LISTs which are defined to specific CICS
regions based on the GRPLIST parameter in the region's System
Initialization Table (SIT). If a transaction is contained in
multiple groups that are assigned to one region, CICS uses the
transaction definition according to the LIST that appears first
in the CSD listing (i.e., if transaction is in separate groups
that are defined to different LISTs) and then according to the
sequence that the group appears.
Global Audit Step Ref #:mmgasaba maj/1.2
-----------------
Determine the users that have access to a specific dataset
Audit Steps
-----------
1) Determine if a dataset profile is present for the entire
dataset name or a generic profile present for a portion of
the dataset.
1.1) Issue the following RACF command from the TSO READY prompt
or TSO command line which will display the dataset profile
if a dataset profile is present for the entire dataset name:
LD DA('<full dataset name>') ALL GEN
If a dataset profile is not present for the entire dataset
name, then execute LD DA('<first dataset qualifier>') ALL
GEN to determine whether a generic dataset profile is
present for a portion of the dataset name.
Notes:
If a dataset profile is not present and PROTECTALL is specified
in the SETROPTS (i.e., system options) then no users have access.
If a dataset profile is not present and PROTECTALL is not
specified in the SETROPTS then all users have access to the
dataset.
If the WARNING indicator is activated (i.e., YES specified in the
WARNING field), then RACF will issue a warning message instead of
failing the access attempt.
2) Determine the users that have access to the dataset profile
defined for the dataset being reviewed.
2.1) Determine the users that access to the dataset based on the
access level being reviewed.
Identify the row on the listing which has ID specified and
determine the userids specified along with the ACCESS that
they are permitted.
Since group profiles can be the IDs permitted access to the
resource, execute LG <group name> RACF command to identify
the users that are assigned to the group.
Note:
The Owner of the dataset can also update the dataset which is
identified in the LEVEL row of the profile listing.
Access to the dataset is either allowed or denied based on what
is specified in the dataset profile if a userid is specified.
F1 - Info Ref #: mmgasaba
Background
----------
This Global Audit Step is typically referred to by a control
point which has a general audit step which indicates whether the
appropriate individuals have access to a dataset. In many cases
the referred to appropriate individuals is indicated in the
control point.
Access to system resources are protected by profiles. There are
two types of profiles; (1) dataset profiles which determine
access to datasets and (2) general resource rules profiles
encompasses all other types of resources.
There are three methods that are used to determine the users that
are granted access to specific a dataset:
o Issuing individual commands from the TSO READY line or
command line to decompile rules for the dataset being
reviewed
o Submission of commands via a JOB
o Manually tracing through access listing to identify profiles
defined for each dataset being reviewed.
In addition, RACF provides ISPF panels which scrolls through the
various screens required to obtain the required information but
is not discussed specifically within the Audit Programs.
The most effective and easiest method for determining individuals
that have access to a dataset is by the issuing RACF commands at
the TSO command line or READY prompt. Therefore, this approach
is detailed within the audit steps.
Audit Steps
----------
Other methods which could grant a user access to the dataset
being reviewed include:
o Operations attribute on user profile or group profile that
user is connected to
o Universal access granted within the dataset profile
Global Audit Step Ref #:mmgasabc maj/1.2
-----------------
Determine the users that have access to a specific resource
Audit Steps
-----------
1) Determine the resource classes being reviewed.
2) Determine whether a profile exists for the resource being
reviewed.
2.1) Issue the following RACF command from the TSO READY prompt
or TSO command line which will display the general resource
profile exists for the resource being reviewed.
RL <resource class> <profile> ALL
Note:
The ALL parameter is required to list and components of the
general resource profile. Asterics can be specified to list all
components. For instance, RL APPL * AUTHUSER lists all general
resources profiles that are defined for the APPL RACF resource
class.
3) Determine the users that have access to the resource profile
defined for the resource being reviewed.
3.1) Determine the users that access to the resource based on the
access level being reviewed (Note: many general resources
only require READ access to have access to use all functions
of the resource).
Identify the row on the listing which has ID specified and
determine the userids specified along with the ACCESS that
they are permitted.
Since group profiles can be the IDs permitted access to the
resource, execute LG <group name> RACF command to identify
the users that are assigned to the group.
F1 - Info Ref #: mmgasabc
Background
----------
General resource profiles are associated with a resource class
which is defined in the RACF Class Descriptor Table.
This Global Audit Step is typically referred to by a control
point which has a general audit step which indicates whether the
appropriate individuals have access to a dataset. In many cases
the referred to appropriate individuals is indicated in the
control point.
Access to system resources are protected by profiles. There are
two types of profiles; (1) dataset profiles which determine
access to datasets and (2) general resource rules profiles
encompasses all other types of resources.
There are three methods that are used to determine the users that
are granted access to specific a dataset:
o Issuing individual commands from the TSO READY line or
command line to decompile rules for the dataset being
reviewed
o Submission of commands via a JOB
o Manually tracing through access listing to identify profiles
defined for each resource being reviewed.
In addition, RACF provides ISPF panels which scrolls through the
various screens required to obtain the required information but
is not discussed specifically within the Audit Programs.
The most effective and easiest method for determining individuals
that have access to a dataset is by the issuing RACF commands at
the TSO command line or READY prompt. Therefore, this approach
is detailed within the audit steps.
Audit Steps Info
----------------
The Auditor attribute is required to list all group profiles or
Group-Auditor is required which has profiles defined within the
scope of their group or subgroup.
A global command is not available to list all general resource
profiles that are defined for all resources classes. Therefore,
in order to obtain this type of information it would be advised
to submit the following command for each resource class in a
batch job:
RL <resource class> * ALL
Global Audit Steps Ref #:mmgasabd new/1.2
------------------
JCL to submit RACF commands in batch
Audit Steps
-----------
Code and submit the following JCL:
//<jobname> JOB <include your site's job card requirements>
//<step name> EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
<RACF commands>
/*
F1 - Info Ref #: mmgasabd
Background
----------
The IKJEFT01 program can be used to execute RACF commands in a
batch job. This method is alternative to the interactive
submission of commands.
Typically RACF commands would be submitted in batch when a large
listing is to be produced. Alternatively, if the site being
reviewed does not provide the auditor the authority to submit
RACF commands, all of the RACF commands that would executed
during the course of a review could be combined in a batch job to
have the security administrator to submit on the auditor's
behalf.
Audit Step Info
---------------
JCL standards are different for each installation. Many times,
installations use system exits to enforce these standards.
Therefore, prior to the coding of any JCL member, the
installation JCL standards should be requested.
Variables within the JCL that can be changed:
<jobname>
The jobname is 1 to 8 alphanumeric name that is used to identify
the job to the operating system. The jobname that is selected
will appear on the first page of the output listing. Any name
can be selected, but some installations require that the jobname
be the same as the userid submitting the job.
<stepname>
The stepname is an optional alphanumeric name. A stepname is
required if subsequent JCL statements refer to the stepname.
Key Parameters used within JCL statements
-----------------------------------------
Job Statement
The JOB statement is used to identify the JOB to the operating
system and to initiate the JOB.
The following is a list of commonly used key parameters used
within the JOB statement:
o CLASS=
CLASS specifies the job class. Job classes range from A to Z.
Installations establish a default job class when the CLASS
parameter is not specified in the JOB statement.
o MSGCLASS=
MSGCLASS specifies the JOB scheduler output class. The output
class is a single character. The installation sets a default
when an output class is not specified in the JOB statement. Each
installation has a specific output class that is used hold the
output from being printed. SDSF could then be used to view the
output from the JOB.
o NOTIFY=<userid>
NOTIFY specifies the userid that is sent a message when the JOB
is completed.
o PRTY=
PRTY indicates the JOB's execution priority. 0 - 15 can be
specified.
EXEC Statement
Each job steps begins with an EXEC statement that either invokes
a cataloged procedure or specifies the program to execute.
The following is a list of commonly used key parameters used
within the EXEC statement:
o PARM
PARM is used to pass parameters to the job step.
Steps to view output
--------------------
Instead of having to obtain the steps for printing output and
also to save paper, jobs are submitted to have their output held
in a class which does not print. Products like SDSF (System
Display Search Facility), which is contained on most systems can
then be used to display the output.
Perform the following steps to display output which was submitted
in a held class (i.e., class which does not print).
o Select SDSF from TSO/ISPF panel
o Select H from the SDSF PRIMARY OPTIONS MENU
o Type S in the NP column for the job that you want to display
Global Audit Step Ref #:mmgasabg new/1.2
-----------------
Determine the access entitlements granted to an userid
Audit Steps
-----------
1) Determine whether the userid has been granted to sensitive
privileges.
1.1) Execute the LU <userid> RACF command to display the userid
record of the userid being reviewed.
1.2) Determine whether any of the following sensitive privileges
are defined in the ATTRIBUTES field from the output of the
LU RACF command:
OPERATIONS - bypasses security checking
SPECIAL - maintains userids and resource access entitlements
AUDITOR - maintains logging of resources
1.3) Determine the groups that the userid is connected to and the
authorities that user has through the group access.
Execute the LG <group> RACF command for each of the group
userids that the userid is connected to.
Determine whether any of the following sensitive privileges
are defined in the CONNECT-ATTRIBUTES field from the output
of the LG RACF command:
OPERATIONS - bypasses security checking for group level
resources
SPECIAL - maintains userids and resource access entitlements
for resources defined to the group
AUDITOR - maintains logging of resources maintained by the
group
F1 - Info Ref #: mmgasabg
Background
----------
During the course of review, certain IDs are identified as being
sensitive in which the access entitlements granted to the ID
needs to be reviewed to determine whether it is appropriate.
However, since RACF design architecture is resource based,
whereby access to resources a centrally stored, it is difficult
to determine the resources that a user is granted access to
unless the entire rules database is reviewed. Therefore, within
the global step, only the sensitive privileges that a userid is
assigned is reviewed.
Group authorities
-----------------
USE user has all access rights for the group. User can create
RACF-protect user created datasets
CREATE user can RACF-protect group datasets for the group but
cannot remove RACF protection
CONNECT user assign other users to the group and assign USE,
CREATE, and CONNECT authority
JOIN user can define new users and groups to RACF, assign any
level of group authority
Example of output from LISTUSER command
----------------------------------------
USER=MHLJMC NAME=LEVINE.MITCHELL OWNER=EUJDSA CREATED=92.18
DEFAULT-GROUP=EUJDSA PASSDATE=92.188 PASS-INTERVAL=31
ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE
LAST-ACCESS=92.199/12:22:55
CLASS AUTHORIZATIONS=NONE
INSTALLATION-DATA=
NO-MODEL-NAME
LOGON ALLOWED (DAYS) (TIME)
---------------------------------------
ANYDAY ANYTIME
GROUP=EUJDSA AUTH=USE CONNECT-OWNER=EUJDSA CONNECT-DATE=92.18
CONNECTS=4 UACC=NONE LAST-CONNECT=92.199/12;22:46
CONNECT-ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE
SECURITY-LEVEL=NONE SPECIFIED
CATEGORY-AUTHORIZATION
NONE SPECIFIED
Definition of critical fields within userid listing
---------------------------------------------------
OWNER - individual user or group who is allowed to modify, list,
or delete the user profile
ATTRIBUTES - privileged authorities that allow the user to
control the administration of RACF (i.e., privileges include
SPECIAL, AUDITOR, OPERATIONS, REVOKE)
CLASS AUTHORIZATIONS - RACF resource class that the user is
allowed access to.
LOGON ALLOWED (DAYS) - Days in which the user is allowed to logon
onto the system. ANYDAY, WEEKDAYS or the specific day can be
specified
GROUP - list of RACF defined groups that user is a member of
CONNECT ATTRIBUTES - attributes like SPECIAL, ADSP that the user
connected to is assigned
SECURITY LEVEL - an additional layer of security whereby a user
is assigned a security level which enables them to access an
associated security level assigned set of resources
Definition of critical fields within group profile
--------------------------------------------------
USERS CONNECTED - list of users that are a member of the group
SUPERIOR GROUP - All groups except SYS1 group has a superior
group and is used to determine the organizational structure of
profile. However, superior groups do not take on the access
entitlements of its subordinate groups.
AUTHORITIES - defines the users capabilities within the group
o USE - access resources that the group is assigned
o CREATE - same as use but create datasets that group can
access
o CONNECT - all capabilities of USE and CREATE and connect to
group user
o JOIN - all capabilities to of USE, CREATE, CONNECT and define
new users or groups (will be subgroup ) to the group but
user requires CLAUTH user attribute for USER class
Global Audit Steps Ref #:mmgasabi
------------------
Obtain a listing of userid and group profiles
Audit Steps
-----------
Submit a job with the following JCL which executes the LIST
commands to obtain a list of userid profiles and group profiles.
//<jobname> JOB
//<step name> EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
LISTUSER *
LISTGRP *
//
Note:
The LISTUSER * command lists the contents of user profiles
The LISTGRP * command lists the contents of group profiles
F1 - Info Ref #: mmgasabi
Group authorities
-----------------
USE user has all access rights for the group. User can create
RACF-protect user created datasets
CREATE user can RACF-protect group datasets for the group but
cannot remove RACF protection
CONNECT user assign other users to the group and assign USE,
CREATE, and CONNECT authority
JOIN user can define new users and groups to RACF, assign any
level of group authority
Example of output from LISTUSER command
----------------------------------------
USER=MHLJMC NAME=LEVINE..MITCHELL OWNER=EUJDSA CREATED=92.18
DEFAULT-GROUP=EUJDSA PASSDATE=92.188 PASS-INTERVAL=31
ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE
LAST-ACCESS=92.199/12:22:55
CLASS AUTHORIZATIONS=NONE
INSTALLATION-DATA=ADEJMC -- RICHARD CONNOLY
NO-MODEL-NAME
LOGON ALLOWED (DAYS) (TIME)
---------------------------------------
ANYDAY ANYTIME
GROUP=EUJDSA AUTH=USE CONNECT-OWNER=EUJDSA CONNECT-DATE=92.18
CONNECTS=4 UACC=NONE LAST-CONNECT=92.199/12;22:46
CONNECT-ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE
SECURITY-LEVEL=NONE SPECIFIED
CATEGORY-AUTHORIZATION
NONE SPECIFIED
Definition of critical fields within userid listing
---------------------------------------------------
OWNER - individual user or group who is allowed to modify, list,
or delete the user profile
ATTRIBUTES - privileged authorities that allow the user to
control the administration of RACF (i.e., privileges include
SPECIAL, AUDITOR, OPERATIONS, REVOKE)
CLASS AUTHORIZATIONS - RACF resource class that the user is
allowed access to.
LOGON ALLOWED (DAYS) - Days in which the user is allowed to logon
onto the system. ANYDAY, WEEKDAYS or the specific day can be
specified
GROUP - list of RACF defined groups that user is a member of
CONNECT ATTRIBUTES - attributes like SPECIAL, ADSP that the group
that the user connected to is assigned
SECURITY LEVEL - an additional layer of security whereby a user
is assigned a security level which enables them to access an
associated security level assigned set of resources
Definition of critical fields within group profile
--------------------------------------------------
USERS CONNECTED - list of users that are a member of the group
SUPERIOR GROUP - All groups except SYS1 group has a superior
group and is used to determine the organizational structure of
profile. However, superior groups do not take on the access
entitlements of its subordinate groups.
AUTHORITIES - defines the users capabilities within the group
o USE - access resources that the group is assigned
o CREATE - same as group but create datasets that group can
access
o CONNECT - all capabilities of USE and CREATE and connect to
group user
o JOIN - all capabilities to of USE, CREATE, CONNECT and define
new users or groups (will be subgroup ) to the group but
user requires CLAUTH user attribute for USER class
Global Audit Steps Ref #:mmgasabj
------------------
Obtain a listing of RACF generic and discrete dataset profiles
and resource profiles
Audit Steps
-----------
1) Submit a job with the following JCL which executes the LIST
commands to obtain a listing of generic and discrete
profiles.
//<job name> JOB
//<step name> EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
LISTDSD *
//
2) Obtain a listing of generic resource profiles
2.1) Submit a job with the following JCL which executes the LIST
commands to obtain a list of userid profiles and group
profiles.
//JOB JOB
//STEP1 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
RLIST * ALL
LISTDSD *
//
F1 - Info Ref #: mmgasabj
Example of Dataset Profile
--------------------------
INFORMATION FOR DATASET PAYROLL.* (G)
LEVEL OWNER UNIVERSAL ACCESS WARNINGS ERASE
----- ----- ---------------- -------- -----
00 MHLKKK NONE NO YES
AUDITING
--------
FAILURES(READ)
NOTIFY
------
NO USER TO BE NOTIFIED
YOUR ACCESS CREATION GROUP DATASET TYPE
----------- -------------- ------------
ALTER MVSSTEER NON-VSAM
GLOBALAUDIT
-----------
NONE
INSTALLATION DATA
-----------------
NONE
SECURITY LEVEL
--------------
NO SECURITY LEVEL
CATEGORIES
----------
NO CATEGORIES
CREATION DATE LAST REFERENCE DATE LAST CHANGE DATE
(DAY) (YEAR) (DAY) (YEAR) (DAY) (YEAR)
------------- ------------------- ----------------
111 92 NOT APPLICABLE FOR GENERIC PROFILE
ALTER COUNT CONTROL COUNT UPDATE COUNT READ COUNT
----------- ------------- ------------ ----------
NOT APPLICABLE FOR GENERIC PROFILE
ID ACCESS ACCESS COUNT
---- -------- ------------
MHLJJK READ 000
PROGRAM ID ACCESS ACCESS COUNT
------- -- ------ -------------
PAYROLL USER01 UPDATE 009
NO ENTRIES IN CONDITIONAL ACCESS LIST
Definition of fields within dataset profile
-------------------------------------------
LEVEL
OWNER - owner of the dataset profile which controls the groups
that can administer access to the dataset
UNIVERSAL ACCESS - indicates the level of access that a user or
group is granted to the dataset when they are specifically not
included in the datasets access list
WARNING - if yes is specified, then RACF issues a warning message
instead of failing an unauthorized access attempt
ERASE - if yes is specified, then space occupied by dataset will
be erased when it is deleted.
AUDITING - specifies the types of accesses to log (ALTER,
CONTROL, UPDATE, READ). All accesses are logged to SMF
NOTIFY - specifies users to be notified in event of a violation.
YOUR ACCESS - access capabilities to dataset for user running
the report
CREATION GROUP - group the created the profile
DATASET TYPE - type of dataset (e.g., VSAM)
GLOBALAUDIT - auditing that is to take for access attempted
INSTALLATION DATA - installation defined field to place comments
SECURITY LEVEL - additional layer of security which compares a
security level of the user to the security level of the dataset
to determine whether they have access
UNIVERSAL ACCESS - access level that is granted to all users.
************************************************************************
Copyright 1991 - 2000, Audit Serve, Inc. All rights reserved. All Audit
Programs are copyrighted and may not be posted electronically or
redistributed unless written permission is granted by Audit Serve, Inc.
The Audit Programs may be used for internal use within organizations.
Audit Programs may not be resold.
*************************************************************
Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US
This website has been optimized for Netscape and Internet Explorer 4.0
and above. Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000 All rights reserved. 27 Pine Street, Suite 700, New Canaan,
CT 06840 USA.