An Expert’s View of the
Top Ten Vulnerabilities of
IBM i Security
Carol Woodbury, President
SkyView Partners, Inc
© SkyView Partners, Inc, 2013. All Rights Reserved.
1
Introduction
SkyView Partners was established in 2002. Since then, we have performed security assessments on hundreds of systems. Our security assessments are true vulnerability assessments—performed to help our clients find and assess the vulnerabilities on their systems,
providing them with the details they need to determine the level of risk each issue poses to
their organization so they can prioritize how and when to address the issue. SkyView
Partners’ assessments are not a marketing tool used to point out the need to buy additional
software.
The results documented in this white paper are based on the data amassed from years of performing security assessments on the hundreds of systems mentioned above. We want to
bring visibility to the top vulnerabilities that have been identified over the years to help the IBM
i community address the issues that we’ve discovered affect most organizations.
Carol Woodbury, President and co-founder of SkyView Partners, Inc. has
Carol earned the title of IBM i security expert by working in the area of
security since 1990, including 10 years working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager
of Security Technology in Rochester, MN. Carol is an award-winning
speaker and writer in the area of security. Carol's fourth book, IBM i
Security Administration and Compliance is a top-selling reference for many
IBM i organizations as they determine how best to administer and implement security on their servers. Carol is Certified in Risk and Information
Security Control (CRISC.)
.
www.skyviewpartners.com
© SkyView Partners, Inc, 2013. All Rights Reserved.
2
An Expert’s View of the Top 10 Vulnerabilities of IBM i
Security
The order in which these vulnerabilities are being presented is in ascending order of prevalence. In other words, Vulnerability #10 occurs with less frequency than Vulnerability #1.
Vulnerability #10 - No auditing
A handful of assessments showed that auditing was not active or didn’t include our minimum
recommended audit settings. In most cases, these were small shops and they were under the
impression that since they had no intention of reviewing the audit logs there was no point in
turning auditing on. Our recommendation was to turn on a minimum amount of auditing—
even if there was no intention of reviewing reports regularly—so that forensic information
would be available if they ever had to investigate an incident.
Vulnerability #9—Sharing root (‘/’)
We do find that the vast majority of organizations have left the root directory at the default setting. And while we call that out as something to remediate, an issue that poses more risk that
occurs in some organizations is when the root directory is shared. The exposure when root is
shared is that all of QSYS.LIB is also shared. This means that all of the traditional IBM i libraries are available through interfaces such as i Navigator and Windows explorer. The risk is
reduced if data has been protected with a strong object level security scheme, but most data
is not protected adequately (see Vulnerability # 1). With a wide-open security scheme, objects (e.g., files and programs) can be dragged into the Trash bin on the user’s desktop.
Note that I’m not saying that file shares are the issue—it’s the specific share to the root directory that’s the issue. File shares—applied to the directory containing the data to be shared—
do not pose a security threat as long as the directory is appropriately secured given the data it
contains.
Vulnerability #8 —Running at security level 20 or 30
Approximately 30% of assessments show systems still running at security level 30 and some
at level 20. The number of systems at QSECURITY 30 continues to drop over time, which is
good to see. Quite frankly, I haven’t seen a vendor application that doesn’t run at security
level 40 / 50 for many, many years. Typically, if any issue is discovered when the audit entries
showing level 40 / 50 issues are examined, they show issues with the use of specific job descriptions or user-written utilities or applications that call operating system programs directly.
Moving from security level 20 to 40 / 50 poses more challenges which is why, I believe we see
the number of systems at this level staying steady. Moving from level 20 requires you to determine how users will get access to data since their *ALLOBJ will be removed when going to
the higher security level.
www.skyviewpartners.com
I’ve written numerous other articles on the important of running at QSECURITY level 40 or
50, I’m not going to repeat myself, but if these vulnerabilities were listed in order of risk to data
rather than prevalence, this would be vulnerability #1.
© SkyView Partners, Inc, 2013. All Rights Reserved.
3
Vulnerability #7—Passwords
Never-expiring passwords
Password configuration can present a variety of vulnerabilities. The worse is when the
QPWDEXPITV (password expiration interval) system value is set to *NOMAX. In other words,
passwords never expire. This means that users never have to change their password and
may be using default or weak passwords forever. This poses a significant risk to the system
and data because, in this case, the user profile naming convention is usually obvious, so
someone intent to sign on the system only has to guess a password. A variation of this is
when the system value shows 90—as in passwords have to be changed every 90 days—but
all user profiles have been overridden with *NOMAX—meaning that the user profile configuration overrides the system value and again—no one has to change their password. This is a
clear and obvious violation of regulations such as the Payment Card Industry (PCI) requirements as well as security best practices.
While some organization have this issue (never-changing passwords), more organization
have the issue where selected profiles have the password expiration parameter overridden.
For some profiles, this is appropriate—for example, profiles used for ODBC or FTP—whose
passwords take special effort to change. But it is never appropriate for an individual’s profile
to be configured with a never-expiring password. The worse offenders….? Security
administrators’ profiles.
Default passwords
Default passwords are passwords that are the same as the profile name. They are
(obviously) easily guessed and pose a risk to the system and data. The risk increases if the
profiles are enabled (can be used for sign on). The risk also increases when the profile has
capabilities such as *ALLOBJ special authority.
If default passwords are discovered, about half are enabled and of those enabled about 20%
have special authorities such as *ALLOBJ.
Weak passwords
Another issue with passwords I must point out is the prevalence of weak passwords. While
the majority of assessments show that if password rules are set, they are usually set to best
practice settings, some are not. I encourage you to start using the QPWDRULES system
value that allows you to add additional controls for the composition of passwords such as requiring two digits instead of just one. The prevalence of weak passwords is likely to rise,
however, since the best practice recommendation for password length has increased from 7
to 8.
www.skyviewpartners.com
© SkyView Partners, Inc, 2013. All Rights Reserved.
4
Vulnerability #6—Denial
Denial that an organization has vulnerabilities in their IBM i security configuration is, fortunately, waning. When SkyView Partners was first formed, we saw significantly more organizations
subscribing to the theory that “IBM i (iSeries at the time) is secure—we don’t need to take further action on security.” The only reason they approached us was because they were forced
to because of audit, compliance or regulatory requirements. Now we’re seeing more organizations recognizing some of the vulnerabilities prior to contacting us. And more organizations
are contacting us as a part of their pro-active approach to security. It appears that more organizations are recognizing that you have to use the features of IBM i to have it be secure.
Another aspect of denial, that remains an issue however. That’s the theory that non-IT
personnel can only access data through menu interfaces. This can be true—as long as
proper controls have been put into place. However, without those controls, data can be—at
the very least—downloaded, if not change or deleted altogether. We continue to have to educate organizations, pointing out that the younger the employee, the more likely they’re aware
of interfaces that allow data access—or they know of someone who does. So unless all employees are over the age of 60, they have this issue!
Vulnerability #5—Multiple instances
We see multiple instances in a couple areas across the system. We will often see multiple
instances of vendor products. Obviously the product was upgraded and the old version left in
place until the new version was proven to be stable. But in the course of administering the
system, the old versions have (obviously) been forgotten and remain on the system. While
an extreme case, we’ve seen up to three old versions of the same vendor product! What’s the
problem with this you ask? If something’s on the system, you have to consider the security
implications. For example, say you have three versions of a product that allows users
(typically programmers) to modify data. You may have decided to lock down access—but only
in the latest version—because you’ve forgotten about the other versions being on the system.
Or you’ve added a module to log activity—but it only works on the latest version of the product. Programmers that know earlier versions of the product still exist can easily bypass the
additional controls and logging simply by using one of the previous versions.
The other area where we see multiple instances is multiple copies of production data. We see
multiple copies on production—typically copied to a developer library to test a fix or before a
massive change is made. We see production data on test systems as well as development
systems. The reason this is a problem is because the data is typically not secured the same
way as the original production file. Often, the production data is owned by the developer’s
group and/or the *PUBLIC authority is more open than the original version and any authorization list association is typically lost. The vulnerability is compounded when production data is
on test or development systems because users on these systems often have more capabilities
than they would on the production system. In other words, users on these systems often have
access to production data that they would not normally have otherwise.
www.skyviewpartners.com
© SkyView Partners, Inc, 2013. All Rights Reserved.
5
Vulnerability #4—DDM
DDM—Distributed Data Management—is rarely discussed as a security vulnerability yet it’s
quite prevalent. DDM, when run over SNA was much easier to secure. When first made
available, running DDM over TCP/IP offered few options for securing this feature. Now, several options are available but like many IBM i security features, they are rarely used.
The security vulnerability with DDM lies with whether a password is required to make a connection. By default, the server is configured to require a password, but most organizations
that use DDM change that attribute to not require a password. Herein lies the vulnerability.
When a DDM connection is made the system makes the connection on the target system
using the originator’s profile. In other words, if profile CJW is signed on to SYSTEM_A and
references a DDM file on SYSTEM_B, the connection to SYSTEM_B will be made as CJW.
But if, on SYSTEM_A, Carol has added a server authentication entry that says that any connection originating as CJW should connect to the target system as QSECOFR, all DDM connections established by CJW running on SYSTEM_A will connect to any system as
QSECOFR! Now you understand why this is called out as a vulnerability. If the DDM server
is required to use a password on the connection, CJW would presumably not know the
QSECOFR (or other powerful profile) passwords and would only be able to make DDM connections as herself.
Vulnerability #3—Inactive profiles
It’s rare that all profiles on a system are current. The good news is that, while there may be
inactive profiles on the system (that is, profiles that have not been used for batch processes,
FTP or ODBC connections or interactive sign on), many organizations have a process in place
to automatically set profiles to status of *DISABLED after a specific length of inactivity—
typically 90 days. And many of those organizations have either a manual or automated process to delete the profiles after another period of inactivity. Where the real issue lies is when
these processes don’t exist. We’ve seen profiles that have been inactive for many, many
years. I think the oldest one I remember was inactive since 1994! And no, I’m not exaggerating. I think administrators got burned in the past by only looking at the last sign on date rather
than the last used date and inactivated or deleted profiles that were active (typically these
were profiles used only for ODBC.) When that happened, they stopped setting profiles to disabled and definitely stopped deleting inactive profiles. The result are profiles that are always
available for use by anyone that can guess their password.
Even inactive profiles that are set to status of *DISABLED pose a threat to the system because they may accidentally be set back to *ENABLED. We always encourage our clients to
clean up old profiles.
www.skyviewpartners.com
© SkyView Partners, Inc, 2013. All Rights Reserved.
6
Vulnerability #2—Profiles with too much authority
Too much authority can come from a variety sources—the most obvious is when users have a
special authority—specifically *ALLOBJ special authority. While most users with *ALLOBJ
assigned directly to their profiles are administrators, what I’ll call ‘errant’ *ALLOBJ assignment
is often from the *ALLOBJ being assigned to end-users’ group profiles. Somewhere in the
past, they were told, that to use the application, application users need *ALLOBJ. Unless
you’re talking about security products whose function requires *ALLOBJ because the underlying operating system function requires it, application users never have to have *ALLOBJ. This
’requirement’ often comes from a consultant that is getting the application up and running and,
is, in my opinion, too lazy to take the time to configure the appropriate security aspects of the
application. I’m sure their thinking is, just give users *ALLOBJ and then we won’t have to
worry about that security ’stuff.’ Beware the vendor or the consultant that gives you this
’advice!’
Other special authority assignments can also pose a significant risk. By far, the most prevalent special authority assignment we see is that of *SPLCTL (spool control) special authority.
While the most convenient method of allowing users to share printed output, the risk is that a
user with this special authority can view any spooled file on the system, regardless of their
authority to the outq in which it’s contained. If you run payroll or print other documents containing private or confidential data and all users have *SPLCTL, your output is at risk of being
read by the wrong individual.
The overall conclusion of special authority assignments is that profiles often have more special authorities than is appropriate for the role they perform on the system. The role that most
consistently has inappropriate special authorities is that of a programmer. For example, we
often see programmers with *ALLOBJ perpetually assigned to their profile as well as
*JOBCTL, *SAVSYS and *SPLCTL. While programmers should not require *ALLOBJ to do
their job function, some organizations allow this assignment. But it’s my opinion that it should
not be allowed perpetually unless the profile is only available for use in an emergency situation. *SAVSYS allows any object to be saved from or restored to the system—regardless of
their authority to the object. Programmers can save their own objects without *SAVSYS.
*SAVSYS should only be assigned to the administrator and operator roles.
Another source of too much authority are users’ group profiles. I’ve already discussed groups
having *ALLOBJ but another vulnerability is caused when the profile that owns an application
is the users’ group. This is a huge risk because anything that a group owns—the members
also own. That means that if the users are a member of the group that owns an application,
all application users have *ALL authority to all application objects—meaning that they can
download and read data, upload and change data or delete or clear a library. This is where
the denial often kicks in. Management is often hesitant to believe that their users could take
advantage of this type of vulnerability. But… we’ve seen the effects of this vulnerability and it
is a fact that it can be exploited—even by non-IT personnel.
www.skyviewpartners.com
© SkyView Partners, Inc, 2013. All Rights Reserved.
7
Vulnerability #1
By far the most prevalent vulnerability we see is that of data not being secured appropriately.
We’ve seen assessments where the main concern is *PUBLIC authority to the library containing the data but that’s not where the vulnerabilities lie. Our focus is on files containing production data. Files containing production data—be it private data or company confidential data is
rarely secured appropriately. What do I mean by appropriately? I mean secured so that only
approved users have direct authority to the data. And those users with direct authority only
have enough authority to view the data not update it from outside of the data application’s
logic. Now it may be that data should be viewable by all—no problem, we’re not trying to say
that all data should be *PUBLIC *EXCLUDE. We’re saying that application data should be
secured in a manner that is appropriate for the type of data in those application files.
In looking at this vulnerability, we also recognize that production data may not just reside in
libraries, it may also be in directories. Production directories typically contain private and
sometimes company confidential data. The prevalence the directories inappropriately secured
is as high as it is for libraries.
Now some of you have chosen to protect data with exit point software. A subset to this vulnerability are organizations that choose this method but then never implement the software or
only implement the logging features of the software. Just because you’ve installed the software doesn’t mean that it’s protecting your data. Just like native IBM i security features, you
have to implement the software to get it to work for you.
Is this the way security is configured on all IBM i systems?
Can I unequivocally assert that this is “the state of IBM i security”? No. I would never do that.
Why? Because, even though we’ve amassed a huge number of data points with the assessments that SkyView Partners has performed, I realize that the organizations that have approached us are, for some reason, interested in security. So our data and the data from other
studies is skewed. My best guess is that the true state of IBM i security is actually worse than
what I’m reporting here. While I’m sure that there are some organizations that are fully secured and would never need our help, I believe there are many, many more organizations that
are totally ignoring the issue—they aren’t even at the point of denial—they just aren’t thinking
about it. Why do I say that? The number of new organizations who come to us each year
requesting an assessment or assistance because some event or some one has triggered their
awareness.
www.skyviewpartners.com
© SkyView Partners, Inc, 2013. All Rights Reserved.
8
What are you going to with this information?
My question to you is this: Now that you know about the Top Ten Vulnerabilities that SkyView
Partners has discovered over the years, what are you going to do with this information? Are
you going to add to the prevalence of Vulnerability #6 and be in denial that none of these vulnerabilities could possibly be found in your organization? Or are you going to do some
investigation to determine if any of these (or other) vulnerabilities exist?
How SkyView Partners can help
SkyView Partners’ Security Check-up Service examines your IBM i, AIX or Linux partitions
and provides the factual, unbiased analysis needed to determine risk to your data.
If you know that you should be checking your security configuration more often but you just
don’t have the time, SkyView’s Managed Services for Security Administration will monitor your
configuration for you.
SkyView’s Services will help you address the list of vulnerabilities and reduce the risk to your
data. Whether you want to address one specific issue, work on issues over time or attack
them all at once, the SkyView Services team will bring their security expertise and experience
to ensure your projects are accomplished in a timely and successful manner.
Contact us for more information.
www.skyviewpartners.com
© SkyView Partners, Inc, 2013. All Rights Reserved.
9