Security Administration Job Function  
(OS/390 RACF specific but can be used across all platforms)

 

Control Objective -  seajraab
A separation exists between the Security Administrators and the
DP area in terms of reporting structure and job responsibilities

Audit Steps
1) Determine if the security administration reports to a level
of management that is not directly responsible for the daily
activities of the data center.

2) Ensure that the security administrators are not responsible
for any other job function (e.g., programming or
operations).

Background
It is important that the security administration is a
functionally separate area to ensure that their ability to
maintain security controls is not influenced by those individuals
that are part of the process being controlled.

It is also important for the security administrators not to
perform any other data center duties, which could result in a
segregation of duties conflict.
 


Control Objective -   seajraae 
Only authorized individuals have security administration
capabilities

Audit Steps
1) Ensure that only security administrators can define users
and add/change data set and resource access entitlements.

1.1) Determine the users that have the SPECIAL attribute at a
SYSTEM level which enables them to administer access
entitlements across the entire system.

Review the SELECTED USER ATTRIBUTE REPORT section of the
DSMON listing (Ref GL PAS mgpasabc) and identify the users
that are assigned the SPECIAL attribute at the SYSTEM level.

1.2) Determine whether the users that have the SPECIAL attribute
at the SYSTEM level are only security administrators.

1.3) Determine the users that have the SPECIAL attribute at a
GROUP level which enables users to administer access
entitlements for profiles within their scope of authority.

Review the SELECTED USER ATTRIBUTE REPORT section of the
DSMON listing (Ref GL PAS mgpasabc) and identify the users
or groups that are assigned the SPECIAL attribute at the
GROUP level.

1.4) If GROUP-SPECIAL is defined, determine whether the users or
groups that have the GROUP-SPECIAL attribute at the GROUP
level are only security administrators or decentralized
security administrators (i.e., if decentralized security
administration is the approach used in your installation).
Note:
Since group profiles can be the IDs permitted GROUP-SPECIAL
access, execute LISTGRP <group name> to identify the users that
are assigned to the group.

1.5) If GROUP-SPECIAL is defined to non-security administrators
or decentralized security administrators, identify the
scope of their authority to determine if it is appropriate
(i.e., for decentralized security administrators verify that
the scope of their authority is appropriate and for non-
security administrators determine the sensitivity of
authority that has been granted).

Determine the GROUPS that the non-security administrators
and decentralized security administrators have
administration authority.

Review the RACF GROUP TREE REPORT section of the DSMON
report (Ref GL PAS mgpasacc) and identify the users group.
Identify all groups that in which it is the superior group.

2) Ensure that only security administrators can set or revoke
the logging of access violations and access attempts.

2.1) Determine the users that have the SPECIAL attribute by
reviewing the SELECTED USER ATTRIBUTE REPORT section of the
DSMON listing (Ref GL PAS mgpasabc) and identify the users
that are assigned the AUDITOR attribute at the SYSTEM level.
Note:
There is no exposure of having the group AUDITOR attribute as
long as the group does not own sensitive user, group, dataset,
generic and general resource profiles.

2.2) Determine whether the users that have the Auditor attribute
are only security administrators.

2.3) Determine the users that have the AUDITOR attribute at a
GROUP level, which enables users to administer logging for
profiles within their scope of authority.

Review the SELECTED USER ATTRIBUTE REPORT section of the
DSMON listing (Ref GL PAS mgpasabc) and identify the users
or groups that are assigned the AUDITOR attribute at the
GROUP level.

2.4) If GROUP-AUDITOR is defined, determine whether the users or
groups that have the GROUP-AUDITOR attribute at the GROUP
level are only security administrators or decentralized
security administrators (i.e., if decentralized security
administration is the approach used in your installation).
Note:
Since group profiles can be the IDs permitted GROUP-AUDITOR
access, execute LISTGRP <group name> to identify the users that
are assigned to the group.

2.5) If GROUP-AUDITOR is defined to non-security administrators
or decentralized security administrators, identify the
scope of their authority in order to determine whether it is
appropriate (i.e., for decentralized security administrators
verify that the scope of their authority appropriate and for
non-security administrators determine the sensitivity of
authority that has been granted).

Determine the GROUPS that the non-security administrators
and decentralized security administrators have
administration authority.

Review the RACF GROUP TREE REPORT section of the DSMON
report (Ref GL PAS mgpasacc) and identify the users group.
Identify all groups that in which it is the superior group.

3) Ensure that only security administrators can establish
profiles for RACF Resource Classes.

3.1) Determine the users that have the CLAUTH attribute by
reviewing the user profile listing and identify the userids
that have the CLAUTH attribute.
Note:
Since group profiles can be the IDs permitted access to the
CLAUTH attribute, execute LISTGRP <group name> to identify the
users that are assigned to the group.

3.2) Determine whether the users that have the CLAUTH attribute
are only security administrators.
Note:
If GENERICOWNER is specified in the SETROPTS list, then more
specific resource profiles cannot be established unless the user
is the owner of the resource, or has SPECIAL attribute, or has
group-special authority of the group that owns the resource
profile.

4) Ensure that only security administrators are the owner of
user, group, dataset, generic, and general resource profiles
which enables them to change access entitlements.

4.1) Review each dataset, generic, general and resource profile
and user and group profiles to determine whether a userid or
group is specified in the owner field.
Note:
Since group profiles can be the IDs specified as being the
owners, determine the identity of the individual userids by
executing LG <group name>.

4.2) Determine whether the users that have the owner authority to
the profiles are only security administrators.
Note:
If non-security administrators are defined as owners of dataset
and resource profiles, you should perform an additional review to
determine the sensitivity of the resource.

If your installation has a decentralized administration process
then, ensure that the decentralized administrators are only
owners of profiles within their scope of authority.

5) Ensure that no users have CONNECT or JOIN authority to any
Group profiles.

5.1) Review the Group profiles and ensure that none has JOIN or
CONNECT authority.
Note:
If users are defined with JOIN or CONNECT authority to the Group
profile, determine the exposure by reviewing the access
entitlements of the Group Profile.

Background
RACF provides many alternatives for assigning security
administration authorities. The method that is used is dependant
on whether a segregation of duties is desired within the security
administration function and whether security administration
function is decentralized, whereby individual areas are
responsible for their own security administration.

The following RACF security administration methods are available:

SPECIAL Attribute (SYSTEM Level)
SPECIAL is an RACF attribute that can issue RACF commands which
establishes and changes the entitlements specified in all types
of RACF profiles (User, group, dataset, generic, and general
resource). This capability enables a user to establish a user
profile who is assigned sensitive attributes and define specific
users or groups to have access to datasets and other general
resources.

The System level of the SPECIAL attribute is assigned to an
individual userid.

SPECIAL Attribute (GROUP Level)
When the SPECIAL attribute is assigned at a group level, the
scope of its authority is limited in the following manner:

o has complete authority to the group (e.g., USE, CREATE, JOIN,
and CONNECT) and all of the group profiles and sub-groups that
the group owns.

o has the ability to change all components of the dataset,
generic, and general resource profiles (i.e., which includes
administering access entitlements to the resources defined in the
profile) owned by the group.

It should be noted that GROUP-SPECIAL will not allow a user to
issue RACF security commands that would have a global effect on
RACF processing. For instance, with SPECIAL on a SYSTEM level,
can assign a user the OPERATION attribute which enables a user to
have full access to all resources. However, GROUP-SPECIAL will
not allow the OPERATIONS attribute to be assigned to a user.

AUDITOR attribute (SYSTEM Level)
AUDITOR is an RACF attribute that can issue RACF commands which
establishes the logging of events that occur on the system. The
System level of the AUDITOR attribute is assigned to an
individual userid.

The types of events that can be logged includes:

AUDIT/NOAUDIT - log RACF commands and RACDEF requests for any
resource class

UAUDIT - log RACF related events for a specific user

SAUDIT/NOSAUDIT
- NOSAUDIT bypass logging of RACF commands and RACHECK and RACDEF
requests issued by users of Special or group special

- SAUDIT logs the RACF command except LIST and SEARCH commands
of users with SPECIAL or group SPECIAL

OPERAUDIT/NOOPERAUDIT (default NOOPERAUDIT)
- OPERAUDIT audits all accesses to resources by OPERATIONS or
group OPERATIONS profiles

CMDVIOL/NOCMDVIOL (default CMDVIOL)
- NOCMDVIOL bypass logging of all violations detected by RACF
except RVARY and SETROPTS

- CMDVIOL logs of all violations detected by RACF

SECLEVELAUDIT/NOSECLEVELAUDIT
- Security labels are assigned to users and resources in order to
group resources in various security levels in which they can be
accessed by user that are assigned a security level that is equal
or greater. This approach to securing resources provides a more
simplistic view in determining the adequacy of resources that are
protected by forcing an installation to rank the sensitivity of
each resource.

A security level name is specified by the installation in the
SECLEVEL profile of the SECDATA class. Security validation can
be established for granting access to resources and/or to audit
access attempts. The SETROPTS SECLEVELAUDIT(<security level
name>) command is issued to establish auditing for a particular
security level (i.e., label) that your installation established.

This feature is available with JES2 or JES3 3.1.3.
The auditing can be bypassed by a program that issues RACHECK or
RACDEF request that specifies logging should not be performed.

REFRESH GENERIC
- Refreshes instorage generic profiles after changes

REFRESH RACLIST
- copies discrete and generic profiles in storage

SECLABELAUDIT/NOSECLABELAUDIT (default NOSECLABELAUDIT)
- Resources whose profiles have security labels can be audited.
The SECLABEL profile is used to define the security label.

LOGOPTIONS
- Access attempts to resources in RACF classes (i.e., Dataset
class and any active class in the class descriptor table) can be
audited. Resource profiles do not need to exist in order for
auditing to occur and overrides any auditing functions specified
in the profiles for the classes. The type of auditing is site
specified which includes, successful access attempts, failed
access attempts, and all. The auditing can be bypassed by a
program that issues RACHECK or RACDEF request that specifies
logging should not be performed.

AUDITOR Attribute (GROUP Level)
When the AUDITOR attribute is assigned at a group level, the
scope of its authority is limited in the following manner:

o has complete logging authority to the group (e.g., USE,
CREATE, JOIN, and CONNECT) and all of the group profiles and sub-
groups that the group owns.

o has the ability to change all logging components of the
dataset, generic, and general resource profiles (i.e., which
includes administering access entitlements to the resources
defined in the profile) owned by the group.

CLAUTH Attribute
The CLAUTH attribute allows a user to define profiles for
resources classes defined in the RACF descriptor table. The
specific classes are assigned that the user can administer are
specifically assigned. In order to set-up profiles for datasets
the USER class is required. A user with CLAUTH authority to a
specific class can assign another user access to that class.

Owners of profiles
Each type of profile regardless if it is a profile used to define
userids (i.e., User and Group profiles) or administer resource
access entitlements (i.e., dataset, generic, or general resource
profiles) allows for an owner to be defined which enables them to
modify, add, and delete access entitlements. For User and Group
profiles, the ability to specify RACF attributes is dependant on
the owner having the SPECIAL attribute.

Connect and Join authority Group Profiles
A Group profile is provided by RACF to group users together in
order to streamline the process of assigning access entitlements
to users. Each user is defined to the group with a specific
access level. The CONNECT authority allows a user to have the
access entitlement to resources assigned to the group and also
allows them to assign other users to the group. The JOIN
authority allows all access capabilities to the Group including
CONNECT authority but also the user to define new users or groups
(i.e., subgroup) to the group as long as the user also has CLAUTH
user attribute for USER class (i.e., Defined in the RACF Resource
Class Table of the DSMON listing).

Therefore, the CONNECT and JOIN authority are a function of
security administration. However, security administrators should
not be granted this access since it also provides them the access
entitlements of the group. There should always be a segregation
of duties between the person that establishes access entitlements
and the users defines as the ones that are accessing resources.
 


Control Objective -  seajraaf
Security administrators userids do not have access to any
resources except what is required to perform their job function

Audit Steps
1) Obtain a listing of the User profile of the security
administrator and the GROUP profiles that they are connected
to.

1.1) Based on Control Point seajraae which identified the various
methods used to grant security administration functions,
identify the security administrators IDs.
or
Determine the users that have the SPECIAL and AUDITOR
attribute at a SYSTEM level which enables the to administer
access entitlements and RACF logging across the entire
system by reviewing the SELECTED USER ATTRIBUTE REPORT
section of the DSMON listing (Ref GL PAS mgpasabc) and
identify the users that are assigned the SPECIAL and AUDITOR
attributes at the SYSTEM level.

Note:
Control Point seajraae identifies other methods that can be used
to assign security administration functions.

1.2) Display the user profile for the security administrators by
executing LU <userid>.

1.3) Display the group profile that the security administrators
are connected to by executing LG <group ID>.

2) Determine whether the security administrators have been
assigned the OPERATIONS attribute which would grant them the
ability to alter system resources by reviewing the SELECTED
USER ATTRIBUTE REPORT section of the DSMON listing (Ref GL
PAS mgpasabc).

3) Determine whether the security administrators are assigned
access to dataset, generic, or general resource profiles
that provides them the ability to update system resources.

3.1) Review the dataset, generic, and general resource profiles
determine whether the security administrator's userid or the
group profiles that they are assigned to are connected to
any the resource profiles with UPDATE or ALTER capability.

Note:
If security administrators have the ability to update datasets or
general resources on the system, an analysis should be performed
to determine the sensitivity of these resources.

Background
A security administrator does not require update access to any
files, protected programs, volumes or bypass capabilities.
Although the security administrators have the ability to add
these privileges to their own userid or establish a new userid
with this capability, an independent review should be performed
to identify this occurrence which is reviewed in another control
point that would identify these actions.

The only tools that the security administrator requires is TSO
access and READ access to some system datasets along with their
security administration attribute, SPECIAL.

The OPERATION attribute is a global method for allowing a user
access to all resources unless there access has been specifically
restricted within the individual profiles which define user
access entitlements to resources.

Audit Step Info
---------------
The review to ensure that OPERATION attribute is appropriately
assigned is reviewed in another subsection's control point.
However, this control point performs a review to ensure that the
security administrators have not been assigned this attribute
since it is part of the entire review which ensures that security
administrators do not have the ability to update system
resources.
 


Control Objective -   seajrabd
An independent review of the security administrators actions is
performed

Audit Steps
1) Ensure that the an audit trail is maintained of all changes
performed by users with the SPECIAL attribute

1.1) Ensure that the SAUDIT is set in the RACF System Resource
Options (SETROPTS) which logs all commands issued by users
with the SPECIAL attribute.

Review the SETROPT listing (Ref GL PAS mgpasabc) and ensure
that SAUDIT is specified in the ATTRIBUTES parameter.

2) Ensure that a process exists for the independent person to
review all changes to security profiles and RACF
installation options.

3) Ensure that an independent review process is taking place of
all changes made by the security administrator.

3.1) Determine whether RACF reports are generated which track the
following types of security changes:

o Changes to RACF installation options (SETROPTS)
o Changes to profiles

Ensure that the reports provide a list of the entire command
that was issued in order to identify the changes that were
actually made by obtaining a copy the RACF report Writer JCL
used by your installation to extract data for the security
reports.

3.2) Determine if the independent review of the changes made by
the security administrator actually occurs by reviewing a
sample period of the reports generated and compare them to
the access request forms for establishing userids and
changing user access entitlements.

Note:
In many installations, a separate authorization form is not used
to track changes to RACF installation options.

Background
The independent review of the security administrator is of the
utmost importance since they have the ability to assign
themselves privileges and access levels which would enable them
to control all resources on the system.

The review of the security administrators actions can be
performed in two ways:

o You can audit the ID which will detail all actions taken by
the security administrator. However, this is not a
preferred method since you will be logging events that are
unimportant to the independent review process.

o The more preferred method is to review the RACF commands
that were issued that alter security.

Audit Steps Info
The approach to this control point is to first determine whether
RACF is enabled to log the events that are used by the RACF
Report Writer to extract the information required to identify the
changes made by the security administrator. The integrity review
to ensure that SMF is extracting the SMF records which are
generated by the report writer and the other SMF integrity issues
(i.e., controlled process for dumping the SMF data, RACF exit
which suppresses the copying of RACF events to an output dataset,
and the security over the SMF files and dump datasets) is
reviewed in a separate control point within the RACF Integrity
Review Main Section.

After the audit trails of RACF security changes has been
verified, then a review can be performed to ensure that an
independent person reviews RACF report listings to ensure that
all changes made by the security administrator are appropriate.

RACF's Report Writer provides the tools necessary for
installation to report on any security related events that
occurs. RACF does not provide set reports for specific review
processes and therefore requires that the installation use the
RACF report writer command syntax to create JCL SYSIN statements
or issue on-line TSO commands to retrieve the installation
required reports.

The specified SYSIN statements would extract the following
events:

o In order to identify the changes to RACF installation
options (SETROPTS), the SETROPTS event name would need to be
specified in the EVENT subcommand.

o In order to identify userids and groups that are added to
the system the ADDUSER and ADDGROUP would need to be
specified in the event name.

o In order to identify changes to userids and groups access
entitlements the ALTUSER and ALTGROUP would need to be
specified in the event name.

o In order to identify resource access entitlement changes the
PERMIT, RDELETE, and RALTER commands would need to be
specified in the event name.

RACF provides sample Report Writer reports which includes summary
reports on the RACF commands that are issued by users or groups.
However, these summary reports could not be used to support the
review process since they do not identify the exact changes that
were made. They only provide an audit trail of the command that
was issued but not the complete command which identifies the
resource or userid that was altered or defined. For instance,
the Command Summary report only identifies that ADDUSER was
executed by a specific userid but does not specify the userid
that was defined.

The creation of reports which identifies the commands that were
issued is the most effective manner to monitor the changes to
security entitlements. This is because there are many methods
that can be used to change security entitlements which includes:

o Special Attribute
o CLAUTH Attribute
o Ownership to profiles
o AUDITOR attribute

However, regardless of the authority that is used by a user to
change security entitlements, they must issue RACF commands to
perform the changes.
 


Control Objective -  seajrabe
A controlled process exists for distributing and controlling
passwords

Audit Steps
1) Ensure that there is a process in place which reassigns
passwords to an authenticated user when the user forgets
their password.

1.1) Determine the method that is used for authenticating the
identity of a user.

2) Ensure that the distribution method used for newly
established passwords only allows the user of the ID to
gain knowledge of the password.

Background
When a user forgets their password it is a common practice for
the security administrator to change the password and convey the
password to the user.

Before the security administrator assigns a new password to the
user, a method needs to be in place to ensure that the user is
actually who they claim to be. Since in many cases the user is
not able to physically present to request the password
reassignment, a method needs to be in place to authenticate the
user's identity. Some alternatives might be:

o have user specify personal information that is stated in the
initial request form that was used to gain access to the
system

o call back verification (i.e., the security administrator
call back the user at their specified phone number)

In addition, a controlled process should be in place for the
distribution of newly created logonids and passwords. If the
user is not in the same location where the password can be hand
delivered, the mail is an alterative. Under no circumstances
should the password be distributed through the owners manager.
 


Copyright 1991 - 2006, 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.

AuditNet - The Global Resource for Auditors

Free
Audit Vision
Newsletter

Since 1991
Join 3,500 other subscribers

General Data Protection Regulation Seminar

Copyright © 2015. All Rights Reserved.