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 is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting 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 practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.
Carol is known worldwide 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, including her two current books, IBM i Security Administration and Compliance, 3rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. 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 Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
|
 |
|
Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale
|
More 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.
TRY 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.
Forms 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.
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:
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.
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:
LATEST COMMENTS
MC Press Online