I think just about everyone recognizes the necessity behind securing the data on AS/400s. That necessity is becoming even more urgent because the traditional AS/400 environment is changing. Originally, an AS/400 often sat relatively isolated, somewhat safely enclosed in the glass walls of a computer room. Now, the AS/400 is having to face a more open and, in a sense, more hostile environment. Openness means easier access to sensitive data both for those who should have access to that data and for those who shouldn't.
Somewhat as a result of the experience with having the AS/400s safe in the computer room, many AS/400 installations' approach to securing data is often relatively simple. These security methods are usually focused on controlling local users' access to data through well-known interfaces. For example, many installations limit end users to selections from application menus and restrict the entry of commands.
In today's AS/400 system environment, this menu security is inadequate. For example, Client Access (PC Support) gives the PC user the ability to enter commands and transfer files to and from the AS/400 and the PC. If your AS/400 is in a network environment, many other ways to access the AS/400 cannot be controlled by menu security.
When users are authorized to production data, the potential for the user to copy, modify, or delete production data exists. If your installation, like many AS/400 installations, authorizes users to production data and relies on menu security to protect data, your security strategy needs to be modified. This article discusses the problems associated with our current and typical methods for securing data. In future articles, I will give you an overview of a new security strategy called application-only access, which restricts access to production data outside of an application. Application-only access protects production data using the AS/400 security features of security level 30 and above. AS/400 security can prohibit access to production data, but some installations allow public read-only access to production data for data warehouse applications.
These future articles will also describe, in detail, how to implement application-only access. The articles will describe the problems that I ran into when I first tried to use this new strategy and the solutions that helped me turn this into a useful technique. First, though, I want to discuss the security exposures I'm attempting to prevent.
An AS/400 security strategy should include both the control of user access to and the assignment of ownership of production data and programs. The ownership of production objects is critical because the object owner can authorize any other users to access the object. Ownership of an AS/400 object allows the owner unrestricted access to the object. 1 shows the frequently used method for object ownership. 2 shows the advantages and disadvantages of the different ownership techniques.
An AS/400 security strategy should include both the control of user access to and the assignment of ownership of production data and programs. The ownership of production objects is critical because the object owner can authorize any other users to access the object. Ownership of an AS/400 object allows the owner unrestricted access to the object. Figure 1 shows the frequently used method for object ownership. Figure 2 shows the advantages and disadvantages of the different ownership techniques.
There are three commonly used methods to control user access to data:
o Menu security-Users are restricted from the command line and are limited to selection of menu options.
o Library security-Individual data objects have *PUBLIC authority, but access is restricted to the libraries that contain the data. Often, the programs and data are stored in different libraries.
o Object security-This limits access to the individual objects within a library.
Menu security limits users to application-provided menu choices. The menu choices allow the user to run programs that display and modify production data. Business controls are often included in the production applications to limit the changes users can make. Some typical application controls limit the size of transactions users can perform to prevent the transfer of large amounts of money or allow a user to view only specific sections (subsets) of production data.
When using menu security, users are restricted from entering AS/400 commands because LMTCPB(*YES) is specified in their user profiles. If a user is a member of a group profile that owns production objects, preventing access to AS/400 commands is essential. If a user has both ownership authority from his group profile and command line capability, he could modify or delete production data.
Menu security alone is insufficient to restrict users in today's online environment. IBM Client Access/400 can run programs that allow the transfer of AS/400 files to and from PCs. The Client Access program RTOPC will transfer (download), from the AS/400 to the PC, any file the user is authorized to. Users can modify the data at a PC and then use the Client Access program RFROMPC to transfer (upload) the data from the PC to the AS/400. The users of RUMBA/400 and other Windows terminal emulators have icons on their PCs that simplify the file transfer operations.
In addition to file transfer, PC users can issue AS/400 commands using the Client Access program RMTCMD. When users issue OS/400 commands using RMTCMD, the user profile setting LMTCPB(*YES) restricting the command line does not restrict entry of CL command functions. If users are authorized to the production data, then the file transfer operations or CL commands will work.
Some installations attempt to restrict the use of these Client Access PC interfaces by not loading the PC programs (such as RMTCMD) on the users' PCs. This is a good first line of defense, but, unfortunately, it will not stop knowledgeable PC users who want access to file transfers or remote commands. PC users can get copies of the Client Access PC programs and run them from a floppy disk. The installation of diskless workstations does not offer full protection-a user may have dial-in access from a full-function PC.
The "personal" in "personal computers" means that individuals can tailor their PCs to their needs. Controls to restrict the PC user must be placed on the AS/400, not the PC. Let's look at other ways to access data.
Most AS/400s are connected to other AS/400s or platforms. This trend of increased network connection is likely to expand in the future, giving remote system users even more potential to access your production data. There are a number of methods for local and remote users to initiate jobs or requests to access production data on the AS/400. 3 lists some potential methods of network access. The list is incomplete, because many of the new functions IBM provides with each release (DDM, TCP/IP, ODBC, IFS) offer new opportunities for network access to data.
Most AS/400s are connected to other AS/400s or platforms. This trend of increased network connection is likely to expand in the future, giving remote system users even more potential to access your production data. There are a number of methods for local and remote users to initiate jobs or requests to access production data on the AS/400. Figure 3 lists some potential methods of network access. The list is incomplete, because many of the new functions IBM provides with each release (DDM, TCP/IP, ODBC, IFS) offer new opportunities for network access to data.
This is not an article on how to hack the AS/400, so I purposely have not provided details on how each method to access data works. The conclusion I want you to reach is that network access offers many ways for users to access your production data. This does not mean that you should wish for the "good old days" of centralized systems and dumb terminals. Distributed computing and client server applications are here and growing. You need to consider their impact on your security strategy.
A resource security strategy protects application data by restricting user access to the data. There are two basic strategies to protect data and many variations of these basic strategies. Most installations use a combination of both strategies. Here are the two strategies:
o Strategy 1-Block the use of the methods to gain access.
This strategy is similar to locking all of the doors to a building. If the doors are locked, intruders are not allowed access into the building. This prevents intruders from accessing the resources (data) stored in the building. However, if one door is left unlocked, the potential for unauthorized entry exists.
This symbolic locking of the doors is done on the AS/400 by restricting the functions that give users access to data. A PC access exit program is an example of how to restrict access for PC requests. No single method can be used to block all of the potential ways for users to access the AS/400. A variety of methods are used, including exit programs, restricting access to the IBM servers, and authorization lists to control specific functions.
Unfortunately, this strategy of blocking the methods of access will have limited success since different approaches must be used for each method of access, making the job complex (different doors require different locks). Also, there is no assurance that the installation has blocked all of the potential ways to access data (have you locked all the doors?).
In addition, IBM seems to invent additional features that give users new methods to access data (new doors get added). IFS and the Open Database Connectivity (ODBC) functions recently added to Client Access illustrate the addition of new ways for users to access data.
Finally, for the FTP and remote relational database requests, no exit programs are available (there are no locks for some doors), so the installation must secure the individual objects.
o Strategy 2- Limit access to the data.
Rather than trying to lock all of the doors to a building, the limit access to the data security strategy is similar to locking the critical resources in a vault. Only those users with the combination (authorized to the data) will be allowed entry into the vault. As further protection, the application programs can limit the actions users can perform in the vault.
Limiting access to the data involves using object or library security, or a combination of the two. For this kind of security to be effective, your system must be at security level 30 or higher. The advantage of this strategy is that it will be effective for all potential methods of access for both the local and remote users.
The difference between these two strategies is shown in 4. The top of the picture represents restricting the potential ways to access production data. Each of the ways the user can access the data must be blocked. However, there are some methods of access (TCP/IP FTP and remote relational database requests) that cannot be blocked at entry. The bottom figure is similar to the top, except AS/400 resource security is used to limit users' access to production data. Using object resource security has the advantage that the same method works for all methods of access.
The difference between these two strategies is shown in Figure 4. The top of the picture represents restricting the potential ways to access production data. Each of the ways the user can access the data must be blocked. However, there are some methods of access (TCP/IP FTP and remote relational database requests) that cannot be blocked at entry. The bottom figure is similar to the top, except AS/400 resource security is used to limit users' access to production data. Using object resource security has the advantage that the same method works for all methods of access.
In the highest level of protection, limiting access to data means users must have no authority to data and the *PUBLIC access to production data is *EXCLUDE. Individual user profiles have no authority to the production data. Users should not have a group profile that owns or is authorized to the data. If users are authorized through their group profiles, then they have the potential to perform file transfers or gain other access. Rather than strictly preventing access to data, some installations allow read access to production data. These installations are concerned with unauthorized modification of data but are not concerned with disclosure of information.
I developed application-only access after recognizing that the current methods aren't robust enough to meet the challenges of the open environment that the AS/400 is now facing. Application-only access is essentially an extension of the resource security strategy that also secures data when people are using tools that don't go through the menus many of us are used to. This new strategy defines application-based routes to the data, and these applications are what create the additional level of security.
The security strategy of limiting users to menus should be continued because the end users are not exposed to more functions than they need. However, menu security is not adequate to protect critical data from the experienced user. The networking and openness features being added to the AS/400 require that this new security plan be adopted.
The valid users of the system still need to run applications to look at information, create reports, and even modify the production data as part of their jobs. The functions a user can perform are often controlled within the scope of the business application.
Application-only access is a solution that helps secure the system from the new connectivity features that are continuing to appear in OS/400. In the next installment of this series, I will expand on the details of the implementation of application-only access.
Application-only access is the method I recommend. I hope you'll stick with me for my next article.
Wayne O. Evans is an AS/400 security consultant and a frequent speaker on security topics. During his 27 years with IBM Corporation, he was involved with AS/400 security design issues. The application-only access method was developed after he recognized that the implementation of security at several of his clients' installations allowed users excessive access to production data. He can be reached by E-mail at
Application-only Access: Security Exposures Revealed
Figure 1: Common Methods for Object Ownership
Object Ownership Alternatives
Every AS/400 object is assigned an owner user profile. These are the alternatives for ownership.
o Creator-When users create objects, the creator user profile becomes the owner of the object.
o Creator with Group Access-When users create objects, the creator profile is the owner of the objects, but the group profile is granted access to the object.
o Group Profile-When a user creates an object, the ownership of the object is transferred to the user's group profile.
o Production Owner-The ownership of objects is assigned to a user profile whose purpose is to be the object owner. The production owner is not a group profile.
o Special Owner-The special owner is a variation of the production owner and is frequently used for programs that adopt authority. The special owner user profile will often have special authority that is required for some specific function.
Application-only Access: Security Exposures Revealed
Figure 2: Analysis of Object Ownership Techniques
Ownership Common Advantages Disadvantages Method Usage Creator o Useful when users o Requires no o Deletion of user pro do not share access management of file requires owned (such as security object ownership objects to be deleted administrators) or transferred to o Potential for users to access data outside of application Creator with o Useful when users o Requires no o Deletion of user pro Group Access share access, but management of file requires owned you do not want to object ownership objects to be deleted share full ownership or transferred to access with group o Granting group another owner members access is provided by the GRPAUT o Potential for users to option in the access data outside user profile of application Group Profile o Useful when several o Simplifies deletion of o Potential for users to users need to share user profiles delete objects if not access of data restricted by menu o User profile option security o Often used when OWNER(*GRPPRF) multiple program allows automatic o Potential for users to mers work together transfer of objects to access data outside as a team a group profile of application Production o Method to o No user access o No automatic Owner prevent access to to data outside method to data outside of application transfer objects to of production program production profile application o Same security o Ownership change method protects should be included production data as part of the from both local and release into network users production Special o Adoption of authority o Reduces number o Design of programs Owner allows users access of users who need should not allow to specific functions special authority users access to a in system command line while running with adopted authority
Application-only Access: Security Exposures Revealed
Figure 3: Local and Remote Methods to Access Data
Controls in Where Requests Addition to Can Be Started Object Authority Comments Local System Jobs o Interactive job o User must sign on o Menu security can limit access o Passthrough Job o Remote system o Menu security can user, but user must limit access sign on o System value QRMT SIGN can restrict access or name an exit program o Submitted jobs o Local o Scheduled o Job scheduler entry o JOBD objects that batch job specify a user name are a potential exposure. Limit access to the JOBD, but it's best to set security level to 40. Client Access o General rules o The users who are o No function can be allowed to start the performed until the router can b router is started. The restricted using an user ID and password exit program in the are authenticated network attribute before the Client Acces PCSACC. router is started. o Submission of remote o Remote PC o Network attribute commands DDMACC o Restricting access to IBM server program o File Transfer (RTOPC o Remote PC o Network attribute RFROMPC) PCSACC o Restricting access to IBM server program o Shared Folders o Remote PC o Network attribute PCSACC o ODBC o Remote PC program o Network attribute o V3R1 APIs allow PCSACC access to data files from PC programs o V3R1 registration facility o The ODBC function SQLExecute or SQLExecDirect can be used to issue AS/400 commands o Not all non-IBM ODBC drivers support the exit programs. Be careful if you use other ODBC drivers. o Integrated File o Remote system o V3R1 registration o V3R1 PC commands System or PC facility have potential to access AS/400 o Restricting access to objects IBM server program o File manager of o Authorization list OS/2 and Windows QPWSERVER (PTF- can delete AS/400 SF23879) limits objects access to QSYS.LIB
Application-only Access: Security Exposures Revealed
Figure 3: Local and Remote Methods to Access Data (continued)
Controls in Where Requests Addition to Can Be Started Object Authority Comments Client Access o Communications jobs o Program start o No protection other o User ID and authen between systems request from than object security tication included as remote system part of start request DDM o Submit remote o Remote system o Network attribute command DDMACC o Restricting access to IBM server program o DDM file access o Remote system o Network attribute DDMACC o Restricting access to IBM server program TCP/IC o FTP o Remote system may o No protection other o User must supply a be AS/400 or another than object security user ID and pass platform word on the PASS WORD command prior to starting the file transfer ICF o User Programs o Remote system o No protection other than object security o IBM program o Remote system user o Restricting access QY2FTML must provide user to IBM server profile and password program for local system SNADS o Send network files o Local system o Access to SNDNETF command o Network job o Remote system o Network attribute submission JOBACN Remote Relational Database o Remote system o No protection other than object securityApplication-only Access: Security Exposures Revealed
Figure 4: Two Ways to Limit Data Access
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online