Security. It surrounds every aspect of life in the new millennium, and it’s never going away. Human nature is such that any time we’re told there’s something we shouldn’t do or somewhere we shouldn’t go, someone is always going to do exactly that and go precisely there. This is especially true when there’s something to gain by violating the rules.
The proof? Barely a day passes without new headlines reporting another cyber attack, policy violation, or data breach. Secretly, we breathe a sigh of relief that it happened to someone else, but most of us know that we’ll all eventually feel the impact in some capacity. Maybe it’ll manifest itself through increased bank fees, higher retail prices, or more hoops to jump through when we log in to our corporate firewall. And eventually it could—nay, it will—be us that it happens to.
So who’s responsible for the security of an IBM i server and DB2 database? IBM builds the hardware and develops the operating system, application vendors and internal programmers write the business applications, and users maintain the corporate data. Who shoulders the responsibility for its integrity and its protection? After more than a decade of working as a security specialist, my answer is a resounding “EVERYONE!”
IBM has done their part. Power Systems servers running IBM i™ have garnered an envious reputation for being some of the most securable servers on the planet, with numerous world-class integrity features. Notice I said securable instead of secure. The annual IBM i Security Study reports alarming statistics showing that most of these servers are operating with default—and largely open—security configurations. You would never assume a server running Windows is secure, and you should never assume it with one running IBM i.
System users, such as programmers and administrators, should be managed by a combination of profile settings and good auditing controls. Application users should be managed by the applications. Ultimately, however, users will do whatever applications allow, not necessarily only what they’re designed to do. And it’s programmers who build those applications, so we have to talk about how to build a more secure application.
The goal of this article is to identify important development considerations that will empower programmers to enhance the security of our data rather than undermine it.
1. Docu-what?
Personal experience has taught me that documentation is a dirty word to many in the programming community. It hampers our simple desire to code. But documentation is also the map that guides future travelers. Without it, every enhancement and bug fix begins with a time-consuming discovery task and increases the likelihood that the application could be broken by the change. Before a single line of code is written, planning documents should identify operational requirements such as these:
- Application libraries
- Profile ownership
- Authorization lists
- Authority schemes—public and private
- Runtime attributes
Documentation should also be embedded in the application programs. Comments should be clear, concise, and in plain English (or your language of choice). In other words, do not simply repeat what any programmer can read from looking at the code.
2. Segregate Libraries
When building an application, many programmers lump all of the objects into a single library as it seems simpler on the surface. However, programs and files typically have different security requirements, and having them cohabit can make securing them more complicated. Segregating non-data objects and data objects into different libraries permits library-level security to control access.
3. “Softcode” Library Lists
<p>I was taught that hard-coding a library name into a program was a cardinal sin, but we’ve learned that search path manipulation is an easy way to wreak havoc and even circumvent security. An acceptable balance may be found by storing library names in data objects, such as data areas, so that they cannot be altered by users but can be changed without requiring modifications to the application code.</p>
4. Own Your Objects
Every object has an owner, and if you’ve ever had to delete a user’s profile, then you understand why ownership shouldn’t be retained by the programmer. Objects should never be owned by a group profile, especially one that consolidates the application users; each member would indirectly own the objects, giving them excess privileges. Instead, create a profile that has only one purpose in life: to own the application objects. Just remember, if new objects are created during the execution of the application, the program should also establish the correct ownership and authorities. Try to avoid assigning ownership to IBMsupplied profiles because if anyone—including IBM— makes a change to the profile, it might have an unpredictable impact on the application.
5. Design the Database
Take time to classify the data in order to identify how stringent the access control should be. For a simple scheme, consider public, semi-public, and private. The database should be normalized to prevent information redundancy, and I recommend encrypting fields that are classified as private. Strong encryption functions are inherent within IBM i, and third-party providers can assist if code modification isn’t possible. Journaling is a popular technique that originated with application recovery and now has uses for replication and for auditing. Consider collecting before and after images of data changes in critical files and archiving that journal data according to corporate policy and compliance mandates.
7. Good Code
While it seems obvious, write good code! My development career exposed me to some of the most horrendous applications I could imagine. Unwieldy programs with unmanageable top-down design, missing—or worse, inaccurate—comments, and redundant functions. Programs that are modular, concisely coded, and well-documented are easier to maintain and easier to review for unauthorized code modifications. ILE constructs make this easy. You should be taking advantage of them.
11. Cover Your Exits
IBM i contains a registry of exit points, which are almost like subroutines in the OS’s functions. When a function is invoked, the OS can pass control temporarily to the assigned exit program—if one exists— to perform any ancillary task before the OS resumes control and processes the request.
There are dozens of exit points in several different categories, but about 30 of them pertain to network access and should be considered critical. While objectlevel security remains effective during these requests, the OS can only enforce one setting across all interfaces, so a user who can change data on a green screen can also change data through an FTP or ODBC connection. While these exit programs can be written in-house, regulatory compliance typically frowns upon self-policing, so I strongly recommend evaluating a commercial solution to selectively process and audit user requests. Preventing data leaks is a requirement shared between exit programs and object-level security.
12. Plan for High Availability
System availability is often a requirement of regulatory compliance. Keeping systems running in the face of a technological disaster is a popular business initiative and one that continues to grow in popularity. When designing a new application, consider the expectation that the application may need to be replicated. A side-benefit of journaling for HA purposes is the audit and recovery trail that can be built into the application.
13. Query and Other Tools
When designing a security infrastructure, consider how the application data will be accessed. Programs can use adoption to temporarily access secured files, but other tools may not have that luxury. Placing the invocation command for a native tool (e.g., WRKQRY) inside a CL “wrapper” can allow it to take advantage of the same technique. Consider authorizing some generic profiles to the authorization list to allow users to access data in a limited capacity. For example, grant *USE access to a profile named READONLY and then swap to that profile if a user needs to use ODBC or Query to view the data. If data is encrypted, native reports may have to be authored if plain text viewing or reporting is required.
Summary
In my capacity as an auditor, I discover vulnerabilities on hundreds of servers every year. In the vast majority of cases, these servers are poorly configured and are running applications that rely heavily on legacy security mechanisms or have no security considerations at all. Ironically, many of those same organizations blame IBM for allowing users to extract data, instead of taking responsibility and investing in the design of a secure application.
Programmers are the linchpin when establishing secure applications. Regardless of whether they’re developing internal solutions or commercial products, acknowledge the risk posed by not having their cooperation, train them in security functions, and work to obtain their buy-in regarding the fact that securing an app is one of the most critical aspects of securing data and maintaining compliance.
