Systems Manager Corner

Locking the Barn Door - Part III

The challenge: Tighten security across production and development modules, while doing everything possible to not cause a problem.

Last time we talked about turning on security_admin, and setting password controls and expiration on your modules. This article will discuss the next steps:

• Cleaning up the disks and directories; and
• Designing the new group_names.

Disk Cleanup

At this point in the project you need to discover where things are running; specifically, where data and ".out" files are being placed by the various jobs in the system. Here are the rules:

Rule A

The root level of each disk should have nothing in it except directories and paging files. Any other files should be moved or deleted. Any jobs that use the root level should be fixed to use a proper directory or the process_dir for files. The root level of each disk will eventually be secured such that only the "System" and "SysAdmin" groups have modify and write access.

Step Five

Remove all extraneous files from the root of every logical disk. Check this daily for a week or more, and modify any procedures so that they place files somewhere more appropriate. After you are comfortable that nothing is placing files at the root level, run the following macro for each logical disk.

set_device_access.cm

&begin_parameters
     path Path:device_name,required
&end_parameters
&echo command_lines
&display_line ----------------------------------------------------------
&display_line Setting access for &path& ROOT
&display_line ----------------------------------------------------------
!remove_default_access            &path& -all
!remove_access                    &path& -all
!give_access              modify  &path& -user *.SysAdmin
!give_default_access      write   &path& -user *.SysAdmin
!give_access              modify  &path& -user *.System
!give_default_access      write   &path& -user *.System
!give_access              status  &path& -user *.*
!give_default_access      read    &path& -user *.*
&display_line ----------------------------------------------------------
&return

You may want to consider adding the notify_security_violation command to your start_up.cm file. This will give you a 25th line message anytime that there's a new entry in the security_log. In any case, watch the security_log carefully for problems.

Rule B

A clear distinction should be made between read-only and read-write directories for each application. Usually a production system has a directory structure like this:

#disk>appl – the root directory of the application--> these should be read-only directories

command_librarysource_libraryinclude_library

object_library

--> these directories are modified by the application

dataout

log

Step Six

Review every application directory structure, checking for recently-modified files. Use the command given below to find them. Make sure that .out and data files are not in the read-only directories. Modify procedures as required to clean this up. (Note: This step may simply be too difficult to implement. Sometimes bad design is too hard to fix. Also note that you can use display_file_status to find out who created a particular file.)

 ----------------------------------- walk_dir ---------------------------------
 directory_name:      #disk>appl
 -depth:              10
 -down_command:       list -sort date_modified
 -down_start_process: no
 -up_command:
 -up_start_process:   no

Now we need to design our user groups and what kind of access they are allowed to the application directories. Here are the general recommendations:

• SysAdmin - restrict this to only those who need true SysAdmin access to the system. SysAdmin also should be the only privileged users. Many applications and utilities which run privileged don't need to do so.
• appl_dev - developers, with full access to the development directories, and null access to the production directories
• appl_qa - testers, with appropriate access to the test directories, and null access to the production directories
• appl_oper - operators, with read access to the production read-only directories, modify access to the production data/log/out directories, and null access to the development directories. The production application should be brought up by an operator in the appl_oper group.
• appl_support - certain individuals who are allowed modify access to both the read-only production and development environments.
• Other groups:
• appl_ftp, with read or write access to very tightly-controlled directories
• browse, with read access to the world, usually reserved for management
• Stratus, see below
• Group "System" should never be used

Note that jobs like backups or application startup can and should be designed to run as batch jobs. Backups can be easily automatically scheduled, with tape operations handled by the system_operator console. Application startup or restart can be handled by a perpetual batch job which is designed to kick off at system reboot time. Doing this enables even closer control of production IDs and privileged access.

Stratus support personnel are a special case. We recommend that you register the CAC and the FE staff with different IDs, under the group "Stratus." We also recommend that you register them with a second group of SysAdmin, in case they have to do emergency work. They should be registered default privileged, since 90% of the time they need to be privileged to do their work.

BEFORE you change any users to the new groups, however, we need to open up the access to the directories those users need, at least for the transition period.

Step Seven

Enable "open" access for all directories during this transition period. Run the macro shown below for each directory. Note that this removes any protections that you may have in place for that directory set. For this reason, the "transition period" should be as short as possible, perhaps less than 24 hours.

&begin_parameters
     path Path:pathname,required
&end_parameters
& **********************************************************
& set_open_access.cm
& **********************************************************
&echo command_lines
&
&label START
&display_line ------------------------------------------------
&display_line Setting OPEN access for &path&
&display_line ------------------------------------------------
&
!remove_default_access            &path& -all
!remove_access                    &path& -all
!give_access              modify  &path& -user *.*
!give_default_access      write   &path& -user *.*
&
!propagate_access &path&
&
&return

Step Eight

Re-register each user in one of the new Groups. Remove the old Group registration for that user. "group1" should reflect the user's primary job function and need for access. Any additional group registration should be carefully considered and restricted, especially SysAdmin. Monitor the security_logs carefully looking for and fixing problems.

Note that the registration_admin command allows you to change (drop & add) user registrations in bulk by using the -process_table option. Refer to the description of the registration_admin command in the Module System Administration manual, R283-04.