Reckless or Riskless: IBM i App Dev Experts Talk Security
February 5, 2018 Dan Burger
It is safe to say that your most sensitive and most valuable data is not safe. The threat of stolen data is a reoccurring nightmare for executive management who are mystified and somewhat dumbfounded by the number of vulnerabilities in their IT systems. Not all of them worry about the same things or are hearing the same strategies from their IT experts.
Most can agree that what’s been done in the past isn’t going to cut it in the present, much less the future. One of the holes in the wall that protects data is at the application level. Existing applications, whether they are developed in-house or purchased from software vendors, can be changed to secure data. And new applications can be written to prevent data accessibility by those who have no business messing with valuable data.
All data on a system can be protected. How an application is written often allows easy access to data that needs protection.
Four subject matter experts in IBM i application development provided IT Jungle with their insights into programming with security in mind.
Brendan Kay
Chief Technology Officer
Fresche Solutions
Application security is something that developers should be approaching in a more systematic way. It is a potentially complicated topic, but many principles are well established. Some of the basic tenants such as only granting the minimum authority required to perform a task are made much easier to achieve with the security tracing that is available in IBM i 7.3. For any customer that has truly sensitive data (and who doesn’t), this should be a regular part of development.
I see adopted authority as both a potentially helpful tool and a potential security trap. If it is used judiciously and deliberately it can greatly assist maintaining minimal security authorization for users. However, if it is over-used, it can become a risk. I personally like to see it used only in cases where the usage can be simply explained, and the execution path is tight. This not only enhances the security profile, but also avoids strange run-time behaviors.
The main items that I emphasize for my internal development teams are: always implement based on the granting of minimal authority; remember that the application is one part of a larger system and security exposure is determined by the weakest link; and you need to put in at least as much effort to protect data as someone else would put in to breach it.
One of the great things about IBM i is that object level security is built into the system and you don’t get different access depending on the stack that made the request. We see most security issues in hybrid systems using mixed security models. In these cases, there is often a tendency to implement overly permissive security authorizations. Of course, even a single system can be set up in an overly permissive way, but that is less common in our experience.
The most adamant view that I have about this topic is that security by obscurity is not acceptable. There are many applications that implement home-grown security protections that are primarily based on no-one else understanding the implementation. This is “a big no” in my book, but is far too common. Good application security will always be based on well-proven design patterns and will be designed to protect data even when the attempted breacher fully knows how the application works.
Alex Roytman
Chief Executive Officer
Profound Logic
Security goes way beyond just network security. It is extremely important in application development. All code should be written with security in mind. This, of course, applies to both in-house developers and application vendors.
Security is especially pertinent today because people are building Web services and Web applications, which are by default more open than green-screen applications or even desktop applications. Single page apps, which use AJAX to reload partial content rather than reloading entire pages are very common today because they give users a better experience. But if not done right (And it’s very easy to get this wrong!), you may be exposing your data to anyone who is handy with browser developer tools.
You can’t just start writing PHP, Node, or CGIDEV2 code that provides data to your browser or mobile application. The Web is a stateless environment, which could mean data can be fetched not just by your application, but by any capable hacker as well.
For secure Web development, you need a system or framework that imitates statefulness in a stateless environment. That means before you start writing application code, you have to first build or invest in a framework or tool that will securely manage the state of a Web application, and not allow users to navigate or make requests to your application’s URLs at will. This is not something that you even have to think about in green-screen development, because statefulness is built right in.
Another big concern with Web apps is SQL injection. As a developer, you have to be aware of it and make sure you’re constructing your SQL statements securely. You have to understand parameter markers before writing any SQL code. A good solution can be to invest in a Web development tool or framework that already takes this into consideration. A tool can force you in the right direction and make sure you are getting it right.
Use of adopted authority in application development is another area where you have to be very careful. Sometimes it may seem necessary to use for technical reasons and developers may not be thinking of all the consequences. You don’t want to ship a program that has QSECOFR authority and provides a command line, for example. This would inadvertently grant any user all access to anything on the system.
Robin Tatam
Director of Security Technologies
HelpSystems
Security has largely been ignored by most internal programmers and even by many commercial application developers. Why? Programmers are often under workload pressure to deploy applications quickly, plus there is a general lack of understanding regarding security controls and the sense that security is the responsibility of the system owner. Commercial providers believe their support desks will be burdened with handling client-unique security challenges and questions. There’s also a misconception that security beyond credential validation is unnecessary because employees with access an application would never do harm!
Like user education, application security has a significant positive impact on an organization’s security stance. Constraints that prevent data leaks and unauthorized viewing and manipulation of data should always be present to avoid credentials being compromised or abused. But while the fear of being hacked leaves modern data owners with a desire for greater security, the fear of causing a critical business application to break is often greater. Many security initiatives quickly stall for this reason.
Application security starts with a cohesive design that leverages the numerous security capabilities of IBM i. That means assigning object-level authorities to establish appropriate levels of access to libraries, application programs, and the database. Many application designers overlook the idea that users can leverage file editors such as DFU and use powerful data inquiry and manipulation tools such as Interactive SQL to access the database outside of the constraints of the application. With a little forethought, application design will utilize powerful programming techniques such as authority adoption and profile swapping to grant a user temporary access to the necessary functions only when using the approved application interface. The application itself should then oversee the functions that the user can perform.
Designing security into a new application is easy and seldom prone to challenges. It should be part of the initial design, just like database structure and application flow. Good security is applied in layers and should include good server configuration, exit programs to oversee PC connections, menus, command line restrictions, and application- based, functional security. Authority adoption is also a programming technique that can reduce the necessity for private authorities and even administrative special authorities. The average Power Server operates with 200 users with *ALLOBJ authority. Reduction of that number should be a high priority.
Jon Paris
App Dev Expert
System i Developer
Should developers be doing more? It really depends how far you take the scope of the word developer. If I develop a web service, am I responsible for ensuring the security of that service? In some small IBM i shops, that’s a possibility. But in most shops, this type of issue is a corporate function. Should the database be encrypted? Probably in many cases it should. But again, it’s rarely a developer’s responsibility.
There are things that are a developer’s responsibility. For example, sanitizing user input to prevent the possibility of SQL injection attacks. Or at the very least, understanding when and where this might be an issue.
Personally, from a developer’s perspective, I have greater concern over a lack of security in the context of applications that are bullet-proofed and fail gracefully. The biggest threat to data integrity in many shops does not arise from outside forces, but from programmers who don’t defend their code from errors. Too often apps still terminate with the “green screen of death” because the developer failed to anticipate certain programming situations. Sometimes such errors go unreported (user just starts up again). Subsequently, mostly because of a lack of use of features such as commitment control and referential integrity, the database gets out of sync. Fix-up routines are then written to resolve the issue, but such routines are often not audited/code reviewed. If I wanted to defraud a company for within, this is the attack vector I’d look for, not fancy firewall breaches.
What I’m really saying is that while security is critical and of ever-increasing concern, most shops that I know have far greater data integrity issues internally than they face due to outside attacks. When talking with users, I am frequently amazed by the number that don’t even use journaling, let alone commitment control. And many of these are banks, insurance companies, and health providers!
RELATED STORIES
Testing For Security Inadequacies
Developers Can Improve Security and Reduce the Administrative Cost of Security
