In previous issues of "Security Patrol," I have discussed adopted authority as one application security model. In this column, I'll discuss the process of re-architecting an application security model as well as the security models available.

Steps to Re-architecting an Application Security Model

Step 1: Change Your Mind-Set

The first step in re-architecting an application's security model is to make sure that everyone--upper management, team leaders, technical leaders, and programmers--are on the same page. For the greatest chance of success, everyone needs to understand and buy in to why the application security model needs to change in the first place. This often usually requires a mind-set change. The attitude of "that's the way we've always done it" will not get you success. Nor will the argument that "our end users are too unsophisticated to use ODBC, submit a remote command, or use FTP." Well, we've seen quite a bit of damage done by those "unsophisticated" users. The fact is that relying on menu security just doesn't work anymore. The sooner everyone accepts this, the sooner you will achieve success. While certain industries--such as healthcare and finance--have formal government regulations for securing their data, all industries need to be concerned with how they deal with private data (such as social security numbers and consumers' buying habits) as well as confidential data (such as credit card numbers).

The mind-set change will most likely evolve. It needs to start with a letter or memo from the CIO (or higher) stating that changes are needed to ensure both the security and availability of the company's applications and data. Team leaders and managers need to reinforce this mind-set by allocating budget to work on a re-architecting project and further educate their employees on the issues that need to be addressed. Project leaders and programmers also need to understand that "security" is not a one-time project. While re-architecting an application authorization scheme is certainly a project, they cannot stop thinking about security once the project is complete. Security considerations need to be made with every new application written and new technology integrated into the environment.

Step 2: Determine Business Requirements

The second step in re-architecting an application security model is to determine the needs of the business. You must examine the data associated with each application and determine its sensitivity, confidentiality, or other value to the business. For example, one of my clients determined that their vendor list was one of their most important assets. Therefore, the applications that dealt with this list had to have a more secure authorization implementation than the application that held the employees' internal phone extensions.

Step 3: Determine Access

The third step in this process requires that the data owner determine who should have access to the data as well as who should be able to run the application. This may look like one step, but it is two distinct steps. In today's environment, data is usually accessible two ways--through an application and through network interfaces such as FTP or ODBC. Even if the application uses one of these network interfaces, you must still consider whether you want the data available through the rest of the network interfaces.

Two approaches are often used for this:

• Least privileged approach: No one has access to the data unless they have a specific business need. This translates into setting *PUBLIC authority to *EXCLUDE to prevent user access. Specific users or groups are then given authority to the objects, or--more often--the application authorization model accommodates this and allows users who can run an application to have access to the data.
• Public information: This approach allows the data to be viewed by anyone on the system. The data is not confidential, so the business sees no need to prevent anyone from seeing it. However, the owner of the data often restricts who can actually change the data. This translates into setting *PUBLIC authority to *USE and again either giving users authority to the objects or accommodating it through the application authorization model. Reminder: Giving public *USE authority allows anyone to not only read the data, but also download it.

Step 4: Choose a Model

Based on the requirements defined in steps two and three, step four is to determine which application authorization model to use. The authorization model is the implementation of the previously determined requirements. Read on to see what authorization models are available to you.

Authorization Model Options

Several authorization model choices exist. Some are quite secure, but others are not. The following lists show the ones people are changing from and to.

From Here...

Menu security: End users sign on to the system and are immediately brought to a menu that gives them no access to a command line. So far, so good. Unfortunately, many application providers stop at this point, which leaves application data wide open. Not securing the application objects (e.g., data files, programs) means that, by default, anyone can modify application data or download the file to a PC, change it, and upload it. I am not saying that menu security should be abandoned. Rather, it should be used in conjunction with one of the secure authorization models listed below.

Public authority: An application depends on *PUBLIC having sufficient authority to perform all application functions. This is not a problem if the public authority is set to *USE. In most cases, the objects are set to *CHANGE or *ALL. With *ALL authority, anyone can not only access the data, but also download it, modify it, and upload it--or delete it entirely! One of the biggest benefits of changing from *ALL authority is the prevention of accidental errors that occur when users have too much authority.

Group authority: An application is owned by one group profile. Users who want to use the application must be members of this profile. Any object a group profile owns, each member also owns. This model is worse than default public access because object owners, by default, have all authority to the object. In this case, careless or malicious users have the power to replace application programs with Trojan horses, update database files incorrectly, or delete the entire application. How likely is this to occur, you ask? Any user running a Windows client can do this using the File Transfer Protocol (FTP) client that comes with a PC's operating system.

To Here...

Application-only access: A single profile owns the application. This profile owns or is authorized to access the data files associated with the application. Public access to the application objects is *EXCLUDE. Users are authorized to the initial menu or to run the command invoking the application. Because the application uses adopted authority, the end user is able to access the application data--but only through the application, not via other means (e.g., FTP, ODBC, DDM). This model is very restrictive and can be very secure.

Variation on application-only access: Rather than setting public authority to *EXCLUDE, it is set to *USE. This method allows anyone to view the information directly without going through the application and allows for reading or downloading the information through the network interfaces such as ODBC and FTP. The application still uses adopted authority to allow users coming through the application to change or update the data. The application owner again either owns the data or is authorized to change and update the data.

Accessing the Integrated File System (IFS): If you are accessing objects in the IFS--such as stream files or HTML--adopted authority won't work because the IFS doesn't honor adopted authority. Your options are to authorize the end user to the IFS objects or change the process or thread so it runs as a different user, one who has the authority to access the IFS object. To change the process to run as a different user, you have several choices: profile swap APIs, profile token APIs, and the UID and GID APIs.

Profile swap: Profile swap APIs have been around for quite a while. These are the APIs that the TCP/IP application servers (e.g., FTP, Telnet) use to get a job to run as the requesting user profile rather than the user profile under which the server started. When a process's profile is swapped, all security attributes are swapped in, including the new user's special authorities, limited capability attributes, and group profile(s). Use of the profile handle that's generated before the profile is actually swapped is limited to the process that generated it.

Profile token: Profile token APIs were introduced in V4R5. They have the same effect as the profile swap APIs, but they generate a token that can be passed between jobs. APIs can generate tokens as one-time use, multi-use, or multi-use regenerable types. These tokens time out and become invalid after a specified time.

UID and GID: UID and GID APIs were also new in V4R5. IBM added the setuid(), setgid(), and associated APIs to aid in the porting of Unix applications running in the Portable Application Solutions Environment (PASE). The native OS/400 versions--the qsy_setuid() and qsy_setgid() APIs--give OS/400 application developers a new option for an application's authorization model. Unlike the profile swap or profile token APIs that swap in all security information, the UID and GID APIs swap in only a user profile (in the case of the UID APIs) or a group profile (in the case of the GID APIs). By the way, the UID is a numeric representation of the user rather than the user profile name, and the GID is the numeric representation of a group profile.

The qsy_setgid() API has become my favorite application authorization method. When a user accesses an application, part of the application startup is to use the qsy_setgid() API to set the GID to the application owner. The application-owning profile is now the user's first group--but only for that particular thread or process. If the user starts up another process, the application-owning profile is not the user's first group! Before, the only way you could implement a similar model was to change a user's group profile and then use the swap APIs to swap to the same user to make the new group profile take effect. The problem was that if a user could start another process, the application profile was the user's first group profile, which lets the user access all of the application objects with owner rights. This produces the same problems and risks as the group authority method described above. These risks are eliminated when you use the GID APIs.

Carol Woodbury is co-author of the book Implementing AS/400 Security as well as co-founder of SkyView Partners, a firm specializing in security consulting and services. Carol has over 12 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Carol can be reached at carol_woodbury@mcpressonline.