I realize that I’ve spent a lot of time explaining best practices and what my recommendations are, but I don’t often explain why some settings aren’t the best.
Some of my favorite magazines will describe a popular action and then explain why that practice is not so bad, pretty bad, or really bad. Using this method, I’m going to describe how bad certain security settings are.
QCRTAUT
QCRTAUT is the system value that sets the *PUBLIC authority when an object is created. IBM ships this value at *CHANGE. While it’s best practice to set this value to *EXCLUDE or *USE, I’m OK with it being left at *CHANGE as long as you set the Create authority value of all libraries containing data to *USE or *EXCLUDE. If I set QCRTAUT to *USE or *EXCLUDE, I generally set the Create authority value of vendor libraries to be *CHANGE, since they tested their code with QCRTAUT set to *CHANGE. So whether you set your data libraries’ Create authority attribute to *EXCLUDE and leave the system value at *CHANGE or set QCRTAUT to *EXCLUDE and change the vendor libraries, it accomplishes the same thing.
How bad is QCRTAUT set to *CHANGE? Not so bad.
However, it’s a different story when the QCRTAUT value has been set to *ALL. I cringe whenever we do a risk assessment and find QCRTAUT set to *ALL. That’s because it’s very difficult to predict what will fail when you change it. Even setting it back to the default of *CHANGE can cause failures. For example, processes that perform an Add Physical File Member (ADDPFM) need to have *CHANGE plus *OBJMGT to the *FILE. Same with Create Duplicate Object (CRTDUPOBJ). Clearing a physical file requires *OBJEXIST to the *FILE. So while you may think the only thing you’re preventing is the deletion of objects when you change QCRTAUT from *ALL back to *CHANGE, you may actually be preventing tasks that you may think should only require *CHANGE but actually require more.
How bad is it when QCRTAUT is set to *ALL? Really bad!
QSECURITY
QSECURITY is the system value that sets the “tone” or security level of the system. While you may think that I’ll say that security level 20 is really bad and 30 is not so bad, you may be surprised. At security level 20, all users are—by default—created with *ALLOBJ and *SAVSYS special authorities. Because the same authority-checking algorithm is run at both levels, you can remove the *ALLOBJ special authority from non-administrator profiles and have a system that runs, essentially, like it’s set to QSECURITY = 30. The problem with running at a security level less than 40 is that you don’t have operating system integrity and you can easily run as a different profile, with the possibility of elevating your privileges to a very powerful profile (as in a profile with all special authorities). This is done by using a Job description (*JOBD) that specifies a user profile. At security level 20 and 30, I only need authority to the *JOBD, not the profile specified in the job description. Many vendors ship *JOBDs with their products, often naming a powerful profile. All I have to do is run a remote command, submitting a job using one of these *JOBDs, and I’ve elevated to a powerful profile. This cannot be prevented at level 20 and 30; however, it is inherently prevented at level 40 and above. (At level 40 and above, I have to have authority to both the *JOBD and the user profile named in the *JOBD.)
How bad is running at either security level 20 or 30? Really bad!
QCRTOBJAUD
This system value sets the object auditing value when a new object is created. Setting the object auditing value to *ALL causes an audit journal entry to be generated every time the object is either read (a ZR entry) or updated (a ZC entry). This may sound like a best-practice setting, but before you set this system value to *ALL, you need to consider all of the objects being created on your system. Think of all of the data areas, user spaces, user queues, user indexes, database files, and other objects that are being read and updated on your system and how often that happens! Setting QCRTOBJAUD to *ALL tends to flood systems (as in, consume massive amounts of storage) with ZR and ZC entries because of temporary objects being deleted and recreated and read or updated multiple times in between. If you need to monitor when objects are both read and updated, a better approach is to either set the Create object audit value for the library the objects are being created into or be even more granular and run the Change Object Auditing (CHGOBJAUD) command to set the auditing value on a specific object or for all of the *FILEs in a particular library, for example. If you insist on changing the setting for the QCRTOBJAUD system value to something other than the shipped value of *NONE, choose *CHANGE. It’s typically the reads that consume the system storage. Auditing for updates only may be manageable from a system storage perspective.
How bad is setting QCRTOBJAUD to *ALL? Pretty bad!
Authorization Lists
I’m a big fan of authorization lists, especially when setting access controls for *FILEs. It allows me to grant access to many files (and other objects) all at once. I simply attach the authorization list to the objects and then grant users authority to the list. Whatever authority the users have to the authorization list, that’s the authority they have to the objects secured by the list.
The trick comes with setting *PUBLIC authority. When an object is secured with an authorization list, the object’s *PUBLIC authority can come either from the object itself or from the authorization list. My preference is to have it come from the authorization list. (To accomplish that, set *PUBLIC to *AUTL.) I especially want to do that when I’m working with a client and we’re reworking the security scheme of their application. At some point, we typically want to set all database files to be *PUBLIC *EXCLUDE. When all of the objects have been set to *PUBLIC(*AUTL), that’s easy to accomplish. Simply set the *PUBLIC authority of the authorization list to *EXCLUDE. If you don’t take that approach, you must go to each object and set the *PUBLIC authority on each object. That can be difficult, especially if the objects are *FILEs and the *FILEs are in use. I also like to set it on the authorization list to avoid confusion. If the object’s *PUBLIC authority is one value (say, *USE) and the authorization lists’ *PUBLIC authority is *CHANGE, which one does the system use? The answer is the object’s, but it’s easier if the setting just comes from the authorization list! Setting *PUBLIC authority on the authorization list also means that all authorities are coming from one place, so I don’t have to look at both the list and the object itself when trying to debug authority issues.
How bad is it when *PUBLIC authority comes from the object? Not so bad (just inconvenient and potentially confusing!).
Service Account Configuration
Most organizations have one or more profiles I refer to as “service accounts.” These are the profiles that don’t represent people. Rather, they run processes, often connecting to the system from other servers via FTP or ODBC. Most of you know to configure these service accounts to not allow signon—that is, set the Initial program (INLPGM) to *NONE and Initial menu (INLMNU) to *SIGNOFF. But it’s rare that I see the final step taken: setting the Attention program (ATNPGM) to *NONE. I can hear you saying, “But you can’t sign on to a 5250 emulation session with these settings.” True...except if you enter the user ID and password for the service account and press the Attention key when you get the message that the profile can’t sign on. If you press the Attention key quickly enough, you are taken to the Attention menu! Depending on the options on the Attention menu, and if you haven’t set the service account profile to LMTCPB(*YES), the profile may be used to enter commands and access data. When my team performs penetration testing for IBM i, we look for this scenario. When a service account has a default password (which is often the case), we are usually able to access data in this very unexpected way.
How bad is it to not set service accounts to best-practice settings? Pretty bad.
Password Level
QPWDLVL is the system value that sets the password level for the system. Leaving the system at the default of QPWDLVL = 0 exposes your enterprise to allowing a very weakly hashed version of the password that’s stored at level 0 or 2 to be exploited. This version of the password is only used by old clients. By “old,” I mean Windows 95, 98, and ME and Windows 2000 server. Hopefully, none of you are still using this technology. Or, if you are, you aren’t using these operating systems to map a drive to access the IBM i NetServer. Assuming this is the case, you can safely move up to either password level 1 (if running at 0) or password level 3 (if the system is currently running at 2.) For more information on moving to a higher password level, read this article.
How bad is running at password levels 0 or 2? Pretty bad.
QMAXSIGN
QMAXSIGN is the system value that controls how many times people can guess their password before some action is taken. Setting this system value to *NOMAX means that users are allowed to try forever to try to get the right combination. While this might be OK when users are trying to log on with their own password, it’s not OK when someone is trying to sign on with a profile other than their own, or a hacker has entered your network, or an insider is trying to exploit someone else’s profile. Best-practice range for this value is 3–5, and the recommended action to take when the limit is reached is to disable the profile or disable the profile and the device being used.
How bad is it when QMAXSIGN is set to *NOMAX? Really bad!
Summary
I hope this discussion has been a fun way to provide perspective on why some settings are better than others.
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