IBM i 7.3: High Time For High Security

April 25, 2016 Dan Burger

How important is data confidentiality to you? On a scale of one to 10, it should be the only double-digit number you can choose. The risks for those unable to control and protect their information are far greater than ever before. The same thing will be said each year into the foreseeable future. So when looking for innovative ways to protect information, IBM acted by adding a tool called authority collection to the new i 7.3 release.

Call it a tool, a utility, or a capability authority collection is now built into the latest OS. The simplest explanation is that it identifies which users have access to what data and determines what level of access they have and what level of access they should have. The goal is to assign the lowest level of authority required to successfully run the applications necessary to their jobs.

“There is a huge gap between how secure the system could be and reality. That gap is in the level of authorization of the objects within the applications–where it is set and where it could be set,” says Jeff Uehling, security architect for the IBM i development team. “The gap exists when an application is created and security is just an afterthought. There are better ways to lock things down.”

If security was a high priority during the application development process, we wouldn’t be talking about authority collection today. But many apps in use today were developed in less threatening times, for use on systems far less complex. Security at the application level has been talked about for years in tech conference sessions and presentations made at local user group meetings. Apparently the threat level has yet to set off widespread alarm, but most would agree the dangers are increasing not diminishing. Added to that is the perception of a safe and secure system, a perception that feeds on a misunderstood reputation that IBM i is inherently secure.

“You can configure the system in a way that it is very secure,” Uehling says. “From an integrity aspect, we feel comfortable that someone cannot bypass our authorization or auditing mechanisms if users are running at the high security levels. Where things become interesting is when you start looking at the data and the data objects. It’s very easy to take data objects and set public authority exclude on those objects. If you do that, you are going to have a very secure environment. But in reality for an app to run successfully, the user of the app has to have access to the data files. That access can be attained if the app is developed correctly with regard to security. The user gains access and the ability to read and write that file using adopted authority at runtime. The application has complete control over what gets read and written.”

Uehling maintains the message from IBM had always been that IBM i is securable, which is different than saying it is inherently secure. Configuring the system is at the heart of IBM i reputation for exceptional security. And there is a lot to be accomplished before that reputation is backed up in real world situations.

“Applications available for the IBM i server often have excessive authority granted to the objects within the application, even with current laws and regulations requiring security of sensitive data. Traditionally, the public authority of objects within an application is set to an authority value that exceeds the authority that is required to run the application,” Uehling wrote in Dawn May’s i Can blog. “This excessive authority setting opens a potential security exposure in the system as the data in this particular table object can be changed, outside of the application, by users of the system. The authority collection support is designed to provide the system administrator and application provider a utility to help lock down the security of application objects.”

A subset of the object information retrieved by authority collection is shown in this screen shot.

Uehling expects the IBM i application software vendors will be the early consumers of authority collection support and that they will leverage the capabilities prior to shipping apps.

Given the security threat environment that exists today, he says it’s more likely that IBM i shops will be asking application vendors more security questions before purchasing applications. Discussions with vendors will include questions such as: Is this app secure? Is my data secure when I’m running your app? What have you done to secure your application?

Security skills will certainly be a factor. Like a lot of other features that are built into the IBM i on Power platform, they are useless if the skills to use them are missing. A lot of IBM i shops do not have the necessary skills to take advantage of authority collection.

Third-party security vendors are lining up to provide the expertise as a service. Some of those vendors were involved with the 7.3 beta program testing of authority collection. Uehling says the feedback was positive.

“If you are literate in security and how authority checking works, you can make use of the tool,” Uehling says. “There is a lot of info in authority collection for an admin who manages apps, applies PTFs, and keeps the system up and running. We have lots of vendors who offer consulting and will be able to analyze the data.”

The IBM i security vendors already have tools and skills relating to security configuration monitoring. In that category are items such as system values, network attributes, TCP/IP configurations, and the capability to analyze audit data. Some report on current authority value, which touches on authority collection.

Also available from the vendors is software that monitors network security via exit points. Monitoring exit points is helpful in locking down network access to the objects.

Authority collection searches for users with access to the box and access to data objects via the command line or a program that opens or accesses a file. It takes object-level reporting beyond identifying libraries with public authority by analyzing the private authorities and determining whether the level is excessive. The tool is designed to cover all the data objects on the box and all the end users who are running applications on the system.

Having a tool to accomplish security settings is useful, but it’s far from the best security fix, according to Pat Botz, an IBM i security consultant. It’s the application development process that bears the ultimate responsibility.

Botz discussed this during an interview with IT Jungle before i 7.3 was announced. That discussion led to an article titled Testing For Security Inadequacies, which included Botz’s insights into the questions of who handles security at the app dev stage. Botz believes it’s the developer, not the system administrator.

Since that article, Botz wrote a blog that appears in his email newsletter called Botz Security Bytes. Botz worries that “authority collection will further the mistaken notion that user profiles require authority to any object in order for an application to perform actions on those objects!” His argument is that end users don’t need authority to application objects; it’s the job that needs authority.

If this topic of controlling and protecting information interests you, read what Botz, a former security architect for the AS/400 and its successor platforms, has to say on the subject.

One of the reasons for authority collection coming now is system performance related. The processing capabilities in the IBM Power Systems iron with Power7 and Power8 processors have opened the doors to significant innovation. Uehling says authority collection could have run on Power6, but system degradation would have been noticeably higher. Performance testing at IBM shows a 2 percent to 3 percent degradation on a large partition or a small partition that is running 90 percent CPU utilization, according to the IBM i security architect.

“There is overhead because every authority check involves collecting data–which programs are involved, which job is running, and capturing all the adopted authority information, which includes information about groups and users.

“One of the things we were worried about is that someone would turn on authority collection for many users and all the objects. The overall effects of that on a production machine could be significant. We put warnings in the documentation and recommend testing on a test partition. However, if you are smart about it and focus on certain libraries or files within an application and a single user at a time, it could be done on a production partition. Performance degradation depends on how crazy you get with the collection parameters.”

Disk space could also take a hit if collection parameters were completely unbridled. Every collection entry gathered by authority collection is about 200 bytes, so it takes 5,000 entries to make a megabyte. During testing with what Uehling described as “a fairly large app over many hours” approximately 10,000 entries were gathered, which equals about 2 MB.

To provide some perspective on the importance of this project, Uehling’s team devoted more than a year’s worth of effort to deliver this support. He describes it as “basically CL commands and Navigator support built into the OS.”

Because authority collection is a feature specific to i 7.3, there won’t be a lot of customer feedback until we get deeper into the OS upgrade cycle, which typically comes about two years after it debuts. Uehling says there’s no chance that it will be retrofitted to earlier releases of the OS due to the complexity and expense of the project. He wouldn’t be surprised, however, to see large IBM i shops that are not ready to do an OS upgrade spinning up a 7.3 test partition, run an app there, use authority collection to gather data, and then take the changes back to 7.1.

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search