With so much fake news floating around, I thought I’d take the time to debunk the fake news I hear about IBM i security.
When I visit new clients, I often find that they have been misguided somewhere along the way and/or are making assumptions about features of IBM i security that were once true but aren’t any longer. This article goes through some of the more common misconceptions I hear.
User Class Forces the System to Check Authority
I can’t tell you the number of people who misunderstand how the system uses the User class attribute of a user profile. It is used to default the special authorities when the profile is created. It is not used when the system checks whether the user has sufficient authority to perform an operation, such as updating a file. Therefore, when you have to debug a problem to determine why a user is or isn’t gaining access, for example, you shouldn’t look at the setting of the User class. The user may be in the Security Officer (*SECOFR) user class yet have no special authorities or be in the User (*USER) user class and have all special authorities. Looking at the User class settings can easily misguide your analysis.
Enabling Security Causes Performance Issues
Given all the performance enhancements in the operating system itself as well as with the authority-checking algorithm and other security features, it’s very difficult to have security be a performance issue. That said, some security features have caused performance issues in the past but have been resolved.
Let’s take a look at those:
- Object auditing: When object auditing was first added to the operating system back in Version 2, simply enabling object auditing—that is, adding *OBJAUD to the QAUDCTL system value—caused a noticeable system overhead. However, that issue has long since been resolved. Enabling object auditing no longer has a noticeable impact. Configuring object auditing on an intensely used object has the potential to cause an impact, but in my experience, even that has not caused a performance issue. (The issue you’re more likely to see is disk space filling up with journal receivers.)
- Authorization lists: Admittedly, when authorization lists were used back in the early releases of AS/400, they did cause a noticeable performance hit. That has been eliminated with some code modifications as well as the advent of the authority cache that’s associated with each user (added in Version 4). The cache holds up to 32 private authorities and 32 private authorities to authorization lists. If users are accessing objects secured by one of the authorization lists in the cache, it’s a very fast check.
- Adopted authority: Once upon a time, adopted authority added overhead to authority checking as well. But, again, efficiencies have been added, and if the owner of the program that adopts owns the object that’s being accessed, the adopted authority check is one of the first things performed in the authority checking algorithm. Whoever thinks that using adopted authority adds overhead is sadly mistaken.
All of these performance gains came in at least by Version 5, so the idea that using any of these security features causes a performance issue today is believing fake news.
Default Passwords Can be OK
An auditor asked for clarification on this myth, and I was happy to clarify for her that there is absolutely no acceptable reason to have a profile with a default password (that is, a password the same as the profile name.) A default password is the first thing a hacker will attempt. The second issue I clarified is that it’s not a compensating control to create the profile with the password set to expired, meaning that it must be changed at first use. Regardless of whether it must be changed at first use, profiles should not be created with a default password!
QSECURITY 50 Enables All Password Rules
In one of my last “Coffee with Carol” webinars, I was asked whether security level (QSECURITY) 50 still enabled all of the password rules. I don’t know where this idea came from, but QSECURITY 50 has never affected the password system values. You must configure the password system values at every security level. No security level enables them automatically.
Adopted Authority Is Evil
While adopted authority can be enabled in such a way that it provides opportunity for exploitation, it is not dangerous if it’s implemented carefully, and it provides a method for temporarily allowing access or the ability to do something without having to perpetually provide access or assign special authorities. Thinking you shouldn’t use adopted authority takes away a very viable tool that will assist you in securing your IBM i system.
The System Can be Secured at QSECURITY Level 30
Some organizations have argued that they can be secure at security level 30. That is simply not the case. Why is this? First of all, operating system integrity is guaranteed only at security level 40 and above. This means that at levels 40 and 50, you can be assured that only operating system programs can call other operating system programs and access internal control blocks. User-written programs cannot directly call operating system programs to bypass authority checking and auditing, nor can operating system programs be replaced by a user-written program. Access is successful only through IBM-architected programs (Application Programming Interfaces, aka APIs) or commands. The second reason is that, at levels 20 and 30, you only have to have authority to a job description, not the user profile if one is specified in the job description. This means that, if you have authority to a job description that names a profile with all special authorities, you can use that job description to submit a job and run it as that privileged user. I used this example at a client to create a new job description that named the IDM profile (the profile that runs their identity management software) and then used the new profile to submit a job to create a new profile. The profile looked like it was created through their normal process but had all special authorities and a password that I knew and could use to access the system with elevated privileges.
Message: Get your systems to security level 40 or higher!
Use Only Parts of QSECURITY Level 40
When I was explaining the fact that the system can’t be secured at level 30 to one client, they asked if they could move parts of their system to security level 40. The answer is no. QSECURITY is a system value. That means it’s systemwide, and it’s all or nothing.
Laws, Regulations, and Best Practices Don’t Apply to IBM i
I know. You’ve read the heading and you’re saying to yourselves, Huh? I agree. But I’ve been questioned by IBM i administrators and especially programmers who claim that somehow they don’t have to comply with laws and regulations or follow best practices. I don’t understand how or why they have come to believe this fake news. Perhaps it’s a case of wishful thinking? Our community holds no exemptions from complying with any law or regulation or implementing best practices. But I often see organizations failing in this area. For example, organizations fail to scan their web applications for well-known vulnerabilities because they’re running on IBM i. It’s a web application. Just because it’s running on IBM i doesn’t exempt it from being coded poorly and leaving it open to vulnerabilities such as SQL injection errors or cross-site scripting issues. We would do our customers—those users whose data your IBM i holds—a favor by complying with laws and regulations and implementing security best practices.
IBM i Has Never Been Hacked
Fake news! IBM i has been hacked. As documented in Verizon’s Data Breach Digest, misconfiguration by the system’s administrator allowed a hacker to infiltrate the system and manipulate the application settings. I know this is not the first time that configuration mistakes have allowed either external hackers or internal users access to data they should not be able to reach. So yes, it has been hacked, but more than that, configuration mistakes and failure to patch known vulnerabilities—especially in open-source products—allows opportunity for inappropriate access to data.
Menu Security Is Sufficient
It still amazes me that I have to explain this, but here we go. Let me be direct (or perhaps I should just tweet this?): If you configure your users to use a menu when they sign on and do nothing to protect the data in your databases and believe your organization’s data is secure, you are believing the most fake of all fake news. What do I need to say to have you understand that users can figure out how to access data on your system, regardless of whether you promote the use of the data? Examples are all over the Internet of how to access data on IBM i. Whether you think you are providing access or not, you are! You must get serious about securing the data residing on your IBM i system!.
Summary
I hope that this discussion has helped you separate the truth from fiction. We have the most securable system available. And that’s not fake news!
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 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 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 For beginners to veterans, this is the definitive security resource. List Price $69.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