System Unit Key

Question: Our computer room is secured by an electronic swipe card system. The AS/400 system keys are kept in the computer room. One is kept at the side of the AS/400 as recommended by the service personnel; another is kept in a cupboard. The system manager is confident that security is not compromised because only people with the proper swipe cards can access the room.

What does IBM recommend for storage of the system keys? Can you tell me in detail the things a person could do when he gets hold of the key and changes the key lock position from normal to manual?

Answer: Service personnel often want to make it easy to service the machine and are not focused on security. It is the responsibility of the system manager to make the decisions needed to protect the computer. Therefore, they should be encouraged to expand protection of the system by locking up the system keys.

The IBM security reference manuals (Security–Basic V4R1 and Security– Reference V4R1) recommend that system keys be removed from the unit and secured physically. If the system is left in the normal position, there should be no need to use the keys except in very unusual cases. The risk is not in one of the staff members destroying the system, but in someone who has access using Dedicated Service Tools (DST) to change the password of QSECOFR back to QSECOFR and then gaining unrestricted access to the system. Starting DST is easy if the key is left in the system unit. The key is required to change the system setting to manual mode. Once the system unit is in manual mode, the set indicators on the system unit can be set to 21. Then, pressing Enter on the system unit will cause the DST sign-on to appear on the system console.

Someone running DST has unrestricted access to all data on the system. This service tool allows trained personnel to correct any unexpected problem, but could be used

also to circumvent the security of the AS/400. A mistake such as setting the wrong bit on could result in logical damage to objects, making the object inaccessible.

Programmer/Analyst Access

Question: We are a manufacturing company with only one AS/400 machine running all applications. I have just been assigned as the security officer for this machine. Each programmer/analyst is responsible for certain applications. The authorized users list carries user profiles with the description “application owner,” which is also assigned to all programmer analysts. The programmers have no other user profiles in the system, and therefore, use the profile for all development, testing, and migration.

The programming manager says he trusts the programmers and they need access to perform their duties. I am concerned that the programmers have too much access and would like your recommendations on how best to secure the system.

Answer: The situation you described is not the ideal situation indeed. The access given to programmers might be warranted if there is nothing of value on the system. But since your company has a single AS/400, both production business data and program development are being done on the same system. Luckily, AS/400 security can be used to safely allow both development and production on the same AS/400.

I recommend that programmers not use the profile for the owner of production data. If programmers sign on with the application owner user profile, they have access to all the production data objects and can delete or modify production objects by accident. Programmers should have their own user profile for application development and personal libraries that are used for program development. Programming staff usually has *USE authority to production files and libraries. *USE authority allows them read access to production files but prevents accidental update of production data while programs are being implemented and tested. When programmers need to test applications that update production data, the Copy File (CPYF) command can be used to copy the needed files into a test library. The programmers will have *ALL access to the copy of production data, which allows them to test applications before they are moved into production.

During the move to production, application ownership should be changed from the programmer to the application owner. As part of this move, the source of applications should be copied to a file that does not allow programmers to modify the source. (Programmers should have *USE access so that they can copy the programs into their personal libraries but cannot directly update the source of applications in production.) Employ division of duties so that the person responsible for implementing applications is not the person in charge of moving objects into production.

References Security–Basic V4R1 (SC41-5301, CD-ROM QB3ALB00) Security–Reference V4R1 (SC41-5302, CD-ROM QB3ALC00)