Application Security: A Shared Responsibility
Last week I was on the road again, spending five days with a brand new PowerTech customer in Montreal, Canada. I always love these types of trips as they allow me to spend time with the customers who are really seeing the benefit of our solutions. It is also interesting to go to places that speak a different language, and all that entails.
It was an extremely productive trip, built around a packed agenda. Our original goal was to install our popular exit point solution, Network Security (NS), on two separate production machines, and start auditing the users’ activities that were previously invisible. I was also there to perform a formal security assessment; a combination of tasks that I expected would require some long days to accomplish in the time available.
When I arrived, I discovered that there was also a desire for me to help design a new security infrastructure for the application environment. A recent business acquisition, and an open vendor application environment, was driving the desire to secure user access based on business need, instead of hoping that users were doing only what they should. An admirable goal—and a service that we can certainly provide—but I didn’t anticipate we would have enough time to accomplish it during this particular trip.
The installation, initial configuration, and user training on Network Security went so smoothly that by the end of the first day we had already started to enter access control rules, and were hungrily awaiting more user transactions to come in. I was glad when my ‘trainee’ told me that he felt that the PowerTech software was intuitive and easy to use, and that the biggest challenge would be for them to identify whether a user was using a network access tool with approval or not (we later discovered that some activities were questionable). We also made some immediate and dramatic improvements in their security environment. For example, with a single NS rule we were able to protect the critical QSYS.LIB file structure from network access by any user on the system—even the ones with powerful access rights like *ALLOBJ.
Day two had me getting a jump-start on the security assessment, and some deeper insight into the strengths and weaknesses of this particular environment. Most of the issues were typical of most IBM i shops: overly powerful users, a few default passwords, some system value change recommendations, and confirmation of that open application data access model. And like most typical issues, some could be remedied easily; others require careful planning and testing. I had been able to perform some of the data analysis ahead of time using a proprietary data collection tool, and so I was able to provide the customer with a draft of the assessment for review before the end of the day.
Designing a resource security model for the corporate application was next. I’m always interested to see how so many commercial software vendors completely miss the mark when it comes to securing their application. I won’t name names, but this particular application relied on the QPGMR user profile owning the application objects and base IBM i security to control user access. The problem with this approach is that most customers have no idea how to implement a solid security model. Leaving their application open, or worse, requiring application users have *ALLOBJ special authority is shameful. Engineering security into an existing commercial application is not easy. You often have little to no control over the way the application executes its code and the objects it accesses. Good security can be incorporated into an application much more easily when it is part of the design. For example, have a custom (non-IBM) profile own all of the objects. Also, don’t require that application users have special authorities for tasks that can be handled through application code (like starting print writers).
Why do we frequently see this openness? Honestly, I think it is for two main reasons. First, IBM i security knowledge is rare and it is easier to put the burden on the end customer as they are the “owner” of the machine. Sure, every customer has different configurations to be accommodated, but a little forethought goes a long way. PowerTech does this with our own applications, so we know it is entirely feasible even when we have no idea of the configuration of the customer’s server. Second, I think that many vendors believe that that a wide open application reduces the support burden. Ironically, designing the application correctly often means fewer calls, as there are no unknown variables at play. I personally feel the responsibility for a secure environment is shared by the customer as the owners of the data, and with the application vendors whose software we trust to house and maintain that data.
In this particular case, we were fortunate to be able to map out a detailed application model that would work without requiring any application modifications. We started by identifying the types of users on the system. We mapped those users into one of four new group profiles to make life much easier when granting access to the numerous application objects. We secured at the library level first, and then at the object level using a couple of authorization lists. The programs are configured to use adopted authority, providing the users with the necessary elevated access only when using the line-of-business application. The group profiles also provide *USE access to certain command line users when using Query/400. As you would expect, there were a number of additional tasks identified, including a creative modification of the application subsystem (as adopted authority does not normally carry through to submitted jobs).
By the end of the week, we had accomplished everything outlined in the project scope; a detailed step-by-step task document would walk through the actual implementation of the object resource model for the application environment. There was even enough time left to help present PowerTech’s free weekly education Webinar; discussing the findings from our annual “State of System i Security” study.
I would like to thank the wonderful customer staff, Sylvain and Louise, for their kind hospitality and excellent French-English translation skills (putting my own to shame!). I am glad to report that everyone was extremely satisfied with what was accomplished in such a short period of time. I really enjoyed assisting them with all of their security initiatives, and I feel proud knowing that the data served from their IBM i servers is more secure than when I arrived.
If you weren’t aware that PowerTech performed professional services—revolving around our products, and also the base IBM i security controls—then I invite you to drop me a note. I think you will be pleasantly surprised to hear what we bring to the table.
Which leaves me with one final question: “Parlez Vous PowerTech?”

Robin Tatam is the Director of Security Technologies for
Jill Martin