Locking the Barn Door - Part II
System Manager's Corner - Summer 2001
We recently were handed a challenge by a client: Tighten security across his production and development modules, while doing everything possible to not cause a problem.
There are lots of dangers when tightening security on a production module. It's very possible to make an error when creating access controls, which results in a production process failing by not having proper access to a file or directory that it needs. In a production environment, any outage is unacceptable. As a result, many system managers are reluctant to implement access controls, and have decided to live with the risk of allowing everyone access to the system.
In this and subsequent articles we'll discuss how to minimize the risk of implementing security in a production environment. We will focus on disk and directory access, with a discussion of the related topics.
Step One
Turn on security_admin on all your modules. Place this command in your module_start_up.cm so that it will be re-enabled after reboots. security_admin doesn't take any action itself, but simply enables logging of security problems. It also doesn't cause measurable overhead, unless you are having severe security problems.
With security_admin turned on, make it a daily practice to review (display) yesterday's (master_disk)>system>security_log.(date –1 day) on each module. This will tell you what security violations that are occurring even before we start to tighten security. Investigate and take steps to correct any serious errors which may be disrupting production.
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.
Passwords, Groups, and Access
Our project will consist of three phases:
- Turn on password expiration and other password controls;
- Assign every user to a new group_name based on their need to access modules, disks, and directories; and
- Implement access control lists (ACLs) for all the disks and directories
Password Controls
Password controls and password expiration must be implemented if you're serious about security. Password expiration, in particular, helps keep the system safe if your system administrator doesn't have the time or isn't in the loop for personnel transitions: Terminated or re-assigned staff must result in their registration on the system being removed, or at least de-activated.
We recommend that:
- All generic IDs (i.e. user_name "operator", "Guest", "Install","Stratus_CAC", etc.) be removed. Anyone using these IDs should be given their own personal ID. ID sharing should be strongly discouraged. Vendor IDs such as the Stratus support IDs should be changed to something non-obvious. Unless each ID is assignable to a single party, the instigator of mistakes or malicious behavior cannot be easily determined.
- The site establish a policy for passwords (but don't implement this until after Step Three below is complete:
- Passwords should expire every 30, 60, or 90 days (pick one);
- The password grace time should be 15 days to allow a user to change an expired password (see the login_admin command);
- The passwords must conform to at least an "alpha plus numeric" format. If the site desires more stringent controls may be implemented. (See the options under the set_password_security command, shown in step four.)
- All users be given instructions that password controls and password expiration will be placed into force on a specific date, and that they should change their passwords according to the new format rules as soon as possible.
Step Two
Instruct all your users to change their passwords ASAP, and not later than a specific date. Usually you can give them a date one or two weeks in advance.
Step Three
Use the macro below to verify that your users have changed their passwords. When all of the production-critical ones have changed, and enough of the others have and the date given in Step Two has arrived, proceed toStep Four.
verify_pwd_expiration.cm
- &begin_parameters
- &end_parameters priv
- &echo command_lines
- &
- &if (index (user_name) SysAdmin) ^= 0
- &then &goto GRPOK
- &display_line ##########################################################
- &display_line You must be SysAdmin to execute this command
- &display_line ##########################################################
- &return
- &
- &label GRPOK
- &set_string CDIR (current_dir)
- &set_string PATH (master_disk)>system>configuration
- !change_current_dir &PATH&
- !log_registered_users
- &
- &set LINE 0
- &label LOOPTOP
- &set LINE (calc &LINE& + 1)
- &set_string TEXT (contents &PATH&>registration_file.tin &LINE& -hold)
- &if (end_of_file &PATH&>registration_file.tin) ^= 0
- &then &goto DONE
- &if (length (string &TEXT&)) < 10
- &then &goto LOOPTOP
- &if (index (string &TEXT&) '=person') = 0
- &then &goto LOOPTOP
- &set_string TEXT (rtrim (ltrim (after (string &TEXT&) person)))
- display_registration_info &TEXT&
- &goto LOOPTOP
- &label DONE
- !change_current_dir &CDIR&
- &return
Step Four
Turn on password security on all modules. Place the commands below in the module_start_up.cm on all modules. Expect to get a few calls from those who didn't change their passwords in time. (Note: We don't show all the parameters for the below commands. The parameters shown are our recommendations. The other parameters are your choice.)
- --------------------------------- login_admin --------------------------------
- -password_exp_time: 90
- -min_password_len: 8
- -password_grace_time: 15
- -password_format: any
- ---------------------------- set_password_security ---------------------------
- -forbid_vowels: no
- -forbid_repeating_chars: yes
- -forbid_user_name: yes
- -forbid_repeat_password: yes
- -forbid_reverse: yes
- -forbid_anagram: yes
- -req_alpha_numeric: yes
- -req_change_first_login: yes
|