Sat, Sep
0 New Articles

What Perturbs Carol About IBM i Security?

IBM i (OS/400, i5/OS)
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Carol provides her pet peeves when it comes to IBM i security configuration.


At this time of year, many lists of favorites are published, but I thought I'd take a slightly different twist and publish my list of IBM i security pet peeves.


#1: Administrators with non-expiring passwords

Among the items we check when performing a security checkup are the password rules on the system, including the password expiration interval (that is, how often a password has to be changed). We also check to make sure that the password expiration interval has not been overridden at the user profile level. Now, it's appropriate to have service accounts with a non-expiring password, but it's not appropriate to have profiles used for sign-on with a non-expiring password. My pet peeve is when I see administrators' accounts with a non-expiring password. These accounts are some of the most powerful on the system. If compromised, the profile can be used—and abused—forever.


Administrators, change your passwords!


#2: Granting *ALL authority instead of what's actually required

Application profiles—especially those making an ODBC or JDBC connection to IBM i to access a database file—will need authority to the file to be able to read or update it. My pet peeve is when an administrator (usually a system administrator or application manager) grants *ALL authority for this profile to the database file or directory being written to rather than granting only the authority required. For example, if a file is being read, the application profile only requires *USE authority. Granting *ALL authority gives the application the authority to delete or modify records, delete the file, or authorize others to the file. Same with granting *ALL authority to a directory. If the application simply needs to write a file to a directory, the application profile should only need *W authority. It should not be granted the ability to read the contents of the directory, clear the directory, or grant others access. My pet peeve is not just that this is a security risk, but this practice makes it incredibly difficult to modify access later. The personnel familiar with the process have often moved on, so you have to try to determine what the process is doing and then use the trial-and-error method to determine what authority is actually required.


Administrators, determine what authority is required when you first set up the process! Don't just grant *ALL to any profile requiring access!


#3: Granting all special authorities to service accounts

A slight variation to the #2 pet peeve is my #3 pet peeve—the assignment of all special authorities to service accounts, regardless of whether they actually require them to perform their tasks. Many service accounts are used to make a connection between IBM i and another server or to FTP files. In these cases, there's no need for the profile to be granted any special authority. Users performing those tasks simply need authority to the files being accessed. Blindly granting all service accounts all special authorities just because they are service accounts presents an even greater security exposure than #2 because most service accounts have non-expiring passwords that are often known by multiple individuals. Over-authorizing these profiles provides these individuals (usually programmers) access to a very powerful profile.


Stop granting special authorities to profiles when they are not required!


#4: QCRTAUT system value set to *ALL

Along the same lines as granting *ALL rather than just the authority that's required, changing the QCRTAUT (Create authority) system value has the same effect. Setting the QCRTAUT system value to *ALL means that the *PUBLIC authority of newly created objects will be set to *ALL. Once again, this is a significant security risk because any user on the system has the authority to read, modify, and delete objects. My pet peeve is that, once set to *ALL, it's very difficult to change back to a more restrictive value because it's unpredictable what will break. For most object types, it won't be a problem. Failures typically come when accessing database files. One would think that *CHANGE authority on a database file would be sufficient. But if the process is adding a physical file member, the process requires *CHANGE plus *OBJMGT authority. Unless someone is intimately knowledgeable about these processes, it is impossible to know that this additional authority is required until you start testing.


Please avoid any temptation to set QCRTAUT to *ALL!


#5: Auditing is not configured

One excuse I often hear when I discover a system where auditing has not been configured is, "Nothing has ever happened, so why should I bother auditing?" To that I reply, "If you're not auditing, how do you know nothing's happened?" Another excuse is, "We don't have time to look at all of the audit entries, so why should I bother?" My reply to that excuse is that, even if you don't plan to examine the audit journal regularly, you want to have the logs just in case they're needed for an investigation. Many of you know the story of my being called in to investigate a breach only to discover that the client had deleted all of the audit journal receivers, history logs, and joblogs; therefore, there was nothing I could review for inappropriate behavior.


Please avoid this pet peeve and enable auditing—even if you don't intend to review the activity regularly.


#6: Leaving inactive profiles on the system

If a profile is on the system, its security implications must be considered; therefore, if a profile isn't being used, it should be deleted. Let me give you some examples. If a profile has excess special authorities, they should be removed, right? The answer is yes, but if the profile is inactive, why not just delete the profile and not bother with removing the authorities? The same applies to profiles with a default password. If the profile has a password that's the same as the user name but it has either never been used or not used in the last 90 days, why bother doing something with the password? Just remove the profile from the system. And profiles of employees that have left the company should always be removed to avoid the possibility that the profile could be accessed by the former employee. Also, inactive profiles add unnecessary time to the Save Security Data (SAVSECDTA) process and worse, to the Restore User Profile (RSTUSRPRF) process should the system have to be rebuilt.


On some systems I've seen thousands (no exaggeration) of inactive profiles; this is a huge exposure and such a waste of system resource that inactive profiles have become one of my pet peeves.


#7: Inactive profiles that must remain on the system due to poor programming practices

How a programmer thinks these are good idea is beyond me, but I've seen cases where administrators have no choice but to leave profiles on the system—even though they're inactive—because when a history report of a user's application activity is generated, the description for the user is taken from the user profile's Text field parameter. If the profile has been removed from the system, the text field says, "User not found." What programmer in their right mind would program a history file and not keep all of the history—that is, the user's text field—and instead rely on the profile remaining on the system indefinitely? Another scenario that baffles me is when a profile's existence is used to verify that a user can run an application. Not a valid user id and password combination, mind you—just the presence of the profile on the system. So in this case, the profile's "Last used date" isn't updated. So, to the system, the profile appears to be inactive since the Last used date is never updated. However, if you delete the profile, the user can no longer access the data.


This pet peeve is best described as stupid programmer tricks.


#8: Vendors that require the use of QSECOFR

The QSECOFR user profile should be used only for system upgrades, not for regular sign-on or daily tasks. My pet peeve is when vendors require application administrators to sign on with QSECOFR to install or configure their application. This is pure laziness on the part of the vendor, and there's absolutely no need to require this authority.


Vendors, stop requiring the use of QSECOFR!


#9: Vendors that require too much authority to run their application

Some vendors require their application users to have *ALLOBJ and other special authorities assigned to their profile even though the application performs no function that requires them. My pet peeve is that vendors fail to determine what special authorities are truly required and cause organizations to have to excessive special authority assignments for no reason.


Vendors, stop requiring special authorities you don't need!


#10: Vendors that don't care

Back in the day, it was quite easy to secure application data. All a vendor had to do was tell administrators how to configure application users' profiles so they went into the correct application menu. Between that and ensuring profiles were set to Limited capabilities (LMTCPB) - *YES, data was secure. No technology existed that allowed direct access to data. So at that time, it really didn't matter what authority vendors set on their application objects, including database files. However, those days are long gone, and now it does matter what the authority settings are because of the plethora of methods that allow data access in addition to menu access.


I've heard many complaints about the wide-open settings that vendors configure for their application objects. Unfortunately, it's not just a simple matter of changing an application's security configuration. If vendors suddenly changed from setting *PUBLIC *ALL authority on their application files to *PUBLIC *EXCLUDE, after an upgrade, all processes using protocols such as ODBC, DDM, and FTP would stop working due to authority failures. No one would appreciate that outcome. What is possible, however, is for vendors to (1) start shipping their applications in a way that makes it easier to secure the application data and (2) provide guidance for their customers on how to achieve either read-only or deny-by-default access for their application database files. Some vendors such as JDEdwards and Infinium provide such guidance. My pet peeve is when vendors simply don't care about their customers' data security concerns, refuse to provide guidance, and threaten to pull support if the security configuration of their application is modified. I cannot believe how irresponsible that is in today's world! I was actually escorted out of a vendor's office because they didn't want to hear what I was telling them about their application…true story!


Vendors, you need to care about your clients' security!


Final Thoughts

You've gotten some insight into things that really annoy me, but the reason they annoy me is because of the unnecessary vulnerabilities they pose to IBM i and to your organization's data. I hope you take a few minutes to think about whether any of these scenarios exist in your organization and then take measures to eliminate them.


Carol Woodbury


Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies – SkyView Partners and DXR Security. Her current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known world-wide as an author and award-winning speaker on security technology, specializing in IBM i Security topics. She has written seven books on IBM i Security. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.


MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

IBM i Security Administration and Compliance: Third Edition IBM i Security Administration and Compliance: Third Edition
Don't miss the newest edition by the industry’s #1 IBM i security expert.
List Price $71.95

Now On Sale

IBM i Security Administration and Compliance: Second Edition IBM i Security Administration and Compliance: Second Edition
Get the must-have guide by the industry’s #1 security authority.
List Price $71.95

Now On Sale

IBM i Security Administration and Compliance IBM i Security Administration and Compliance
For beginners to veterans, this is the definitive security resource.
List Price $69.95

Now On Sale



Support MC Press Online

$0.00 Raised:

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: