Getting Started with IBM i Security: User Privileges

All trademarks and registered trademarks are the property of their respective owners.© HelpSystems LLC. All rights reserved.
Getting Started With
IBM i Security:
User Privileges

HelpSystems Corporate Overview. All rights reserved.
ROBIN TATAM, CBCA CISM
Director of Security Technologies
952-563-2768
robin.tatam@helpsystems.com
Your Speaker

• Premier Security Products (globally-recognized “PowerTech” brand)
– Represented by industry veteran, Robin Tatam, CISM
• Comprehensive IBM i Security Services
– Represented by industry veteran, Carol Woodbury, CRISC
• Member of PCI Security Standards Council
• Authorized by NASBA to issue CPE Credits for Security Education
• Publisher of the Annual “State of IBM i Security” Report
About HelpSystems’ Security Investment

Your users have the
virtual “keys” to your
corporate data.
Do you trust them not
to even try to “drive” it?
Would you bet your
ENTIRE business
(or career) on it?
A Big Gamble

PowerTech uses anonymous audit data from our Security Scan tool to compile an
annual study of security statistics. This study, available online, provides a picture of
what IBM i shops are currently doing with their security controls.
Year after year, it shows that there is still room (and need) for improvement!
The State of Our Security

Do you have
obsolete user
profiles?
Did you know IBM i
has the ability to
automatically
disable an inactive
account?
(ANZPRFACT)

Default profiles are
banned by
compliance
mandates, and for
GOOD reason!
Review and resolve
using ANZDFTPWD
Change outdated
provisioning
procedures
All Default Passwords
Enabled, Default Passwords

IBM i uses three main user entities:
User Profile
This is what we typically think of as a “user”
SST/DST User
A user of low-level system admin tools
Validation List Users
Maintained by applications (e.g., HTTP users)
What Are User Profiles?

User Profiles are objects of type *USRPRF
They define each user’s capabilities, default environment
settings, and resource (object) permissions.
IBM supplies a number of profiles with the system − basic
ones, and others associated with licensed products (e.g.,
QSECOFR, QBRMS).
What Are User Profiles?
“I’m not a number…
I’m an object!”

A profile/password is the biggest (and often the ONLY)
hurdle put between a person and the corporate data – so
make it count!
Don’t ever make the mistake of assuming that “my users
could not / would not (know how to) do that!”
Remember, you already gave them
a valid login.
General Requirements

“Security by
Obscurity” is no
longer a good
option…
Of course, it never
really was!
A False Sense of Security

Sharing can be nice!

Sharing can also be a problem!

Require that users maintain their own profiles, using
passwords that meet corporate rules.
IBM i has numerous password system values,
including a system value (QPWDRULES) in V6R1+
that allows more flexible rules to be used.
WRKSYSVAL SYSVAL(QPWD*)

Establish a security policy to identify
the purpose of the profile and
its associated capabilities.
The policy should identify data
access rules, as well as the job
roles that require access to the
data.
Once the identification work is
done, ongoing compliance verification
is much easier.
Before Profiles Are Created

• Consider using template profiles based on job role, rather than
simply copying another ‘similar’ profile.
• Safeguard profiles and staff who create / modify profiles.
• Use a programmatic approach for password resets and re-
enablement.
• Audit profile creation / change activity under *SECURITY
events.
NOTE: Deletion is recorded as a *DELETE object event!
Before Profiles Are Created

You have to be a Security Administrator
(*SECADM special authority), but you can’t grant
a user any special authorities that you also don’t
have (unless you have *ALLOBJ which allows you
to run a job as someone else).
Set up a new profile using the Create User Profile
(CRTUSRPRF) command,
or via Navigator for i.
Setting Up A New Profile

User Profile (USRPRF)
Assign a name to the user using an agreed upon naming
convention, although best practices recommend one that is not
easily guessed (e.g., based simply on the user’s name).
Department / Location / Name combination
User Profile Parameters
RTATAM User Profile = RTATAM

Password (PWD)
• Do NOT ever retain the default (*USRPRF), even if you expect
the user is going to change it.
• Use *NONE for Group Profiles, object-ownership profiles, or
any profile you wish to prevent signing on.
• IT should use system controls to enforce the corporate
password policy.

Password (PWD)
• IBM changed from using default passwords to *NONE on
some of their own profiles. If you are running an
older/migrated system—beware!
• Use the Analyze Default Password (ANZDFTPWD) command
to find profiles that are assigned default passwords (this
should be part of your ongoing review process).

Password (PWD)
Before IBM i v7.2, administrators could assign ANY
password, even those that do not comply with the system
password rules (including setting back to default).
v6.1 will log if passwords don’t meet policy
v7.2 enables enforcement on admins (*ALLCRTCHG)
Users are unable to set the password to match their user
name, so we can’t “blame” them if we find it.

Set Password To Expired (PWDEXP)
• Forces a user to change the password at the next valid
sign on.
• Do NOT rely on this control for new profiles as there’s nothing
guaranteeing who that first user actually is!
• Cannot be used in conjunction with password *NONE

Password Expiration Interval (PWDEXPITV)
• Define how often you want the user to be forced to change
their password.
• Use this as an override to the QPWDEXPITV system value.
• Don’t ever set this to *NOMAX unless it’s an application
profile!

Block Password Change (PWDCHGBLK)
• Specify the number of hours (1−99) to pass before a user can
change their password again.
• Use this as an override to the QPWDCHGBLK system value.
• This new control is designed to prevent a sneaky user from
changing their profiles in rapid succession to get back to their
original password.
V6R1

Display Signon Information (DSPSGNINF)
• This value displays a post-sign on screen to indicate the date
and time of the last successful sign on.
• Although end-users will not pay attention to this “nag” screen,
it is recommended that administrators turn this on to validate
the expected timestamp.

Limit Device Session (LMTDEVSSN)
• V5R4 and earlier: This is an on/off type of control that allows
a limit of 1, or no limit (*YES / *NO).
• Updated in V6R1 to make it more usable – allowing you to
designate a number between 0 and 9 (old ‘binary’ values are
still supported).
• Use this as an override to the QLMTDEVSSN system value.
ENHANCED
V6R1

Status (STATUS)
• Specify if you want the profile enabled /disabled for sign on.
• Disabling does NOT prevent a profile from running a job, or
owning objects, etc.
• Used in conjunction with QMAXSIGN and QMAXSGNACN
system values to control abuse.

Status (STATUS)
• The recommendation is to disable STATUS in conjunction with
setting password to *NONE if the profile is not to be used for
sign on.
• If QSECOFR becomes disabled, you can still sign on at the
console and re-enable it again (assuming you know the
password).

User Class (USRCLS)
Five templates based on the common types of users:
*SECOFR Security Officer
*SECADM Security Administrator
*SYSOPR System Operator
*PGMR Programmer
*USER User

*SECOFR *ALLOBJ, *SECADM, *SAVSYS,
*JOBCTL, *SERVICE, *SPLCTL, *AUDIT,
*IOSYSCFG, *JOBCTL
*SECADM *SECADM
*SYSOPR *SAVSYS, *JOBCTL
*PGMR None
*USER None
User Class (USRCLS)
Each template controls the visible IBM menu options, and
default special authority assignment:
NOTE: There are additional authorities assigned at security level 20 (not recommended)

Special Authority (SPCAUT)
• Only the default assignment is controlled by User Class when
*USRCLS (overriding possible and common).
• Defining users by role / job function is beneficial.
• Do not assign special authorities unless there is a proven
requirement.

• Special authorities from Group profiles are inherited by all
members of the group. This can make assignment easier
when the group members are added / removed.
• Don’t overlook group inheritance when checking settings.
• Consider programmatically addressing occasional
access requirements (adopted authority or
swap profile APIs).

*ALLOBJ
All Object is the “gold key” to every object, and
almost every administrative operation on the
system, including unstoppable data access.

*SECADM
Enables a user to create and maintain the
system user profiles without requiring the user
to be in the *SECOFR user class, or giving
*ALLOBJ authority.

*IOSYSCFG
Allows the user to create, delete, and manage
devices, lines, and controllers.
Also permits the configuration of TCP/IP, and
the start of associated servers (e.g., HTTP).

*AUDIT
The user is permitted to manage all aspects of
auditing, including setting the audit system
values and running the audit commands
(CHGOBJAUD / CHGUSRAUD).

*SPLCTL
This is the *ALLOBJ of Spooled Files. Allows a
user to view / delete / hold / release any
spooled file in any output queue, regardless of
restrictions.

*SERVICE
Allows a user to access the System Service
Tools (SST) login, although, since V5R1, they
also need an SST login.

*JOBCTL
Enables a user to be able to start / end
subsystems, manipulate other users’ jobs. Also
provides access to spooled files in output queues
designated as “operator control.”

*SAVRST
Enables a user to perform save/restore
operations on
any object on the system, even if there is
insufficient authority to use the object.
Be cautious if using security at only a library level.

IBM i Special Authorities
State of Security Study, 2016

Limit Capabilities (LMTCPB)
The limit capabilities setting controls certain
green-screen functions that the user is allowed
to perform / override themselves.
There are three options: *Yes, *No, and *Partial

Many admins are surprised to learn that
end users may be able to use the CHGPRF
command to change (or the signon screen
to override) the following:
Initial Program
Initial Menu
Current Library
Attention Program
*NO *YES *PARTIAL




☐
☐
☐
☐

☐
☐
☐

If you use the standard IBM-supplied sign on screen, you
have exposure from non-limited users, so consider
modifying it.

The biggest impact of Limit Capabilities *NO and
*PARTIAL is the ability for the user to execute
(authorized) commands directly on a command
line.
Although most admins see this as a user-level
restriction, it is actually something that is
assigned as part of the command definition.

The following IBM-shipped commands can
be executed by even limited users:
SIGNOFF, SNDMSG, DSPMSG, WRKMSG, STRPCO,
DSPJOBLOG, DSPJOB, WRKENVVAR

Security-Oriented
Parameters
To allow other commands to be executed by
limited capability users, use the CHGCMD
command on the desired command, and
specify the following parameter:
ALWLMTUSR(*YES)

A WARNING:
Limiting command access via this parameter, is
only truly effective on a green screen.
Other interfaces “may” not observe the restriction,
which can compromise your security scheme if
you rely primarily on commands.

Group Profiles
A group profile is basically
a way to associate a set
of users with similar
security requirements.
Several user profile
parameters pertain to
how a user is treated
when they are a member
of an authority ‘group.’
ACCTG H/R
A/P

Creating A Group Profile
A group profile starts life as a regular user profile, although they
have some recommendations of their own:
PROFILE(GRP_XXX) PASSWORD(*NONE)
INLMNU(*SIGNOFF) INLPGM(*NONE)
LMTCPB(*YES)
Group Profiles should not own objects that need to be secured from
the application users.
Turn the profile into a ‘group’ profile by designating it as a group on
your actual users’ profiles.

Group Profile (GRPPRF)
Designate the name of the group that this user
belongs to.
IBM originally only allowed 1 group
assignment, but added the ability to be the
member of up to 15 supplemental groups using
a separate SUPGRPPRF parameter.

Group Profile (GRPPRF) &
Supplemental Groups (SUPGRPPRF)
If more than 1 group, then the groups are checked in
the order that they are specified (this is a performance
consideration).
Special authorities on the group profile pertain to every
member of the group, in addition to the authorities
they might already possess.
Private authorities that the group have also are
ADDITIVE and are granted to all the members,
although individual private authorities take precedence.

Owner (OWNER)
If the profile is the member of a group, specify
whether any new objects that the user creates
should be the owned by the user, or by the
group.
Group Authority (GRPAUT)
If you want the user to own new objects, then
this parameter specifies what authority should
be given to the other members of the group.

Authority (AUT)
Designate the public authority that all other
users have to the user profile object itself.
Unless you have a VERY strong reason, this
should always be *EXCLUDE to prevent
abuse and the possibility of users ‘hijacking’
the profile.
Note: Check your profiles with the PRTPUBAUT command.

The following parameters have an equivalent system value.
The user profile default is *SYSVAL, but you can use these
parameters to specify an override that takes precedence
over the system value.
PWDEXPITV Password Expiration Interval
DSPSGNINF Display Sign on Information
LMTDEVSSN Limit Device Session
BLKPWDCHG Block Password Change

Command Capability Restrictions Can Be
Circumvented via Non-traditional Interfaces
• Ensure that you have all interfaces secured using an exit
program. Selectively block those network functions that do
not have a proven business use.
• Bottom Line: Don’t rely on command line or menu
restrictions to prevent access to your objects.
How Profiles Can Be Abused

Inherited Capabilities from Group Profiles
• Both special authorities and private authorities are added to
those provided to the members of the group.
• A user’s private authorities are always checked before the
group, and, if found, the group’s authorities are not used)
• If a group owns objects, then so do the members.

Programs That Run With Adopted Authority
• A program can run using the credentials of the calling user, or
with the addition of capabilities from the profile that owns the
program.
• Closely audit the functions of any programs that adopt
authority and ensure that they don’t present screens with a
command line!

Security Level Below 40
• At security levels below 40, a user can run a job as an
alternate profile WITHOUT having any authority to the
target profile!
• It simply requires authority to a job description that uses a
named user profile in its configuration.
• This security ‘violation’ is logged, but not prevented.

Profiles That Are Not Publicly Excluded
If a user has authority to another user profile object, they
potentially have the ability to submit a job with the other
profile’s credentials.
This is a HUGE exposure at ALL security levels, especially if
the user or group has *ALLOBJ special authority since this
gives them authority to EVERY profile on the system. Also,
if the open profile has *ALLOBJ, then it’s a nightmare!

Do NOT give *ALLOBJ to a programmer (no matter how much
they complain).
Consider auditing ‘powerful’ profiles
(users with command line capabilities
and/or special authority).
Do NOT make Help Desk users
security officers simply to reset
passwords, etc.
Other Suggestions

Run a HelpSystems Security Scan

Security awareness among IBM i
professionals is generally low.
IBM i awareness among audit
professionals is even lower.
Some of the most valuable data is
stored on a Power Systems server
(iSeries, AS/400).
Most IBM i data is not secured and
the users are far too powerful.
Most data is easily accessed via PC
interfaces with little-to-no oversight
The Perfect IBM i Security “Storm”

Learn more about IBM i security
Free Download:
2016 State of IBM i Security
https://www.mc-store.com/products/ibm-i-security-
administration-and-compliance-second-edition

Questions

http://www.helpsystems.com/getting-started-security-series
Thank You
See you on July 19th at 12 noon CST to discuss IFS Security

Getting Started with IBM i Security: User Privileges

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Getting Started with IBM i Security: User Privileges

Ähnlich wie Getting Started with IBM i Security: User Privileges (20)

Mehr von HelpSystems

Mehr von HelpSystems (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Getting Started with IBM i Security: User Privileges