Password Policy
SANS (www.sans.org) provides a wide range of security policies freely available on its website. These policies are based on these publicly available policies. You should visit SANS and use discussions in this chapter to spark your ideas. Granite Systems (www.granitesystems.net) based these policies on those recommended by SANS and allowed me to present them here.
In this policy, the company’s IT security department is known simply as the Corporate Security Team for Granite Systems. Granite Systems and other Granite Systems–specific departments will appear in italics throughout the policy; if you want to reuse this policy, you can replace these designations with your own.
Overview
Passwords are a crucial aspect of computer security. They are the first line of protection for user accounts. A poorly chosen password might result in the compromise of Granite Systems’ entire corporate network. As such, all Granite Systems employees (including contractors and vendors with access to Granite Systems systems) are responsible for taking the appropriate steps for selecting and securing their passwords, as outlined in the following sections.
Purpose
The purpose of this policy is to establish a standard for the creation of strong passwords, the protection of those passwords, and to define how often you should change them.
Caution
Passwords should be changed on a regular basis because user passwords are the first thing an attacker will try to crack. Most systems automatically prompt a user to change a password after a set amount of time has elapsed. Many of the newer operating systems apply some intelligence to a user’s password, thus forcing the user not to use words that can be guessed or found in a dictionary. If you are not using these features or are not sure whether they are a part of your systems, it is a good idea to research the matter and activate them.
Scope
The scope of this policy includes all personnel who have or are responsible for an account (or any form of access that supports or requires a password) on any system that resides at any Granite Systems facility, has access to the Granite Systems network, or stores any nonpublic Granite Systems information.
An account can be defined and expanded to include email, keypad locks, FTP, shared drives, and so on. All passwords used to access these kinds of resources should follow some sort of password policy, as discussed in other portions of this policy.
General Policy
All system-level passwords (for example, root, enable, Windows admin, application administration accounts, and so on) must be changed on at least a quarterly basis.
• All production system-level passwords must be part of the Corporate Security Team’s administered global password management database.
Note
Not every organization has such a grandiose sounding “global password database” way of tracking passwords and, frankly, it is not necessary for most organizations. However, you must track passwords and how often they are changed in some manner. This enables you to ensure that your policy is being followed. Of course, ensure that you restrict access to whatever tool you put in place.
• All user-level passwords (for example, email, web, desktop computer, and so on) must be changed at least every six months. The recommended change interval is every four months.
• User accounts that have system-level privileges granted through group memberships or programs such as administrator or root must have a unique password from all other accounts held by that user.
• Passwords must not be inserted into email messages or other forms of electronic communication.
• Passwords must never be given out to anyone, regardless of their position in the company by email, voice, text or instant message. Employees are instructed to directly contact Corporate Security if anyone asks for your password, before giving it out.
• Where SNMP is used, the community strings must be defined as something other than the standard defaults of “public,” “private,” and “system,” and must be different from the passwords used to log in interactively. A keyed hash must be used where available (for example, SNMPv2 and later).
Note
This last part means changing the default passwords for the device in question. It is amazing how many organizations have never changed the default passwords. When I run across a device for which I do not know the default password, I always consult this site: www.cirt.net/cgi-bin/passwd.pl. At the time of this writing, there are more than 162 vendors with a total of 1132 default passwords and an ever-growing list for wireless devices and their passwords (SSID).
All user-level and system-level passwords must conform to the guidelines described in the following section.
General Password Construction Guidelines
Passwords are used for various purposes at Granite Systems. Some of the more common uses include user-level accounts, web accounts, email accounts, screensaver protection, voicemail password, and local router logins. Because few systems have support for one-time tokens (that is, dynamic passwords only used once), everyone should be aware of how to select strong passwords.
Poor, weak passwords have the following characteristics:
• The password contains less than eight characters.
• The password is a word found in a dictionary (English or foreign).
• The password is a common usage word such as the following:
• Names of family, pets, friends, coworkers, fantasy characters, and so on.
• Computer terms and names, commands, sites, companies, hardware, software.
• The words “Granite Systems,” “energy,” “Granite Systems,” or any derivation.
• Birthdays and other personal information such as addresses and phone numbers.
• Word or number patterns such as aaabbb, qwerty, zyxwvuts, 123321, and so on.
• Any of the previous words spelled backward.
• Any of the previous words preceded or followed by a digit (for example, secret1, or 1secret).
• Sports teams or famous players.
• Do not post passwords anywhere.
Note
Chapter 12 “Tools of the Trade,” discusses word lists and dictionaries; however, while discussing passwords, it is also appropriate to mention word lists and dictionaries in this chapter. A word list is simply a list of words, such as words from the dictionary, sports teams, industry terms, slang words, names; or all these lists are available in many different languages on the Internet. A good online source is http://wordlist.sourceforge.net/.
Attackers use these word lists as the basis of an attack, hoping someone would use a derivation of a word found on one of these lists. Just to be sure, they also inject numbers. This capability of attackers is the basis for the preceding portion of this policy.
Strong passwords have the following characteristics:
• Contain both upper- and lowercase characters (for example, a–z, A–Z)
• Have digits and punctuation characters and letters (for example, 0–9, !@#$%^&*()_+|~-=`{}[]:“;‘<>?,./)
• Are at least eight alphanumeric characters in length
• Are not words in any language, slang, dialect, jargon, and so on
• Are not based on personal information, names of family, and so on
Note
Passwords should never be written down or stored online. Try to create passwords that you can remember easily. One way to do this is create a password based on a song title, affirmation, or other phrase. For example, the phrase might be: “This May Be One Way To Remember,” and the password could be “TmB1w2R!” or “Tmb1W>r~,” or some other variation. NOTE: Do not use either of these examples as passwords.
Password Protection Standards
Do not use the same password for Granite Systems accounts as for other non-Granite Systems access (for example, personal ISP account, option trading, benefits, and so on). Where possible, do not use the same password for various Granite Systems access needs. For example, select one password for the engineering systems and a separate password for IT systems. Also, select a separate password to be used for an NT account and a UNIX account.
Do not share Granite Systems passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, confidential Granite Systems information.
Following is a list of “don’ts”:
• Do not reveal a password over the phone to ANYONE.
• Do not reveal a password in an email message.
• Do not reveal a password to the boss.
• Do not talk about a password in front of others.
• Do not hint at the format of a password (for example, “my family name”).
• Do not reveal a password on questionnaires or security forms.
• Do not share a password with family members.
• Do not reveal a password to coworkers while on vacation.
If someone demands a password, refer him to this document or have him call someone on the Corporate Security Team.
Do not use the “Remember Password” feature of applications. (For example, Outlook, web browsers, and so on—clear caches often dictated by procedures and guidelines.)
Again, do not write passwords down and store them anywhere in your office. Do not store passwords in a file on any computer system (including Palm Pilots or similar devices) without encryption that has been approved by the Corporate Security Team.
Change passwords at least once every six months (except system-level passwords, which must be changed quarterly). The recommended change interval is every four months.
If an account or password is suspected to have been compromised, report the incident to the Corporate Security Team and immediately change all passwords.
The Corporate Security Team or its delegates can perform password cracking or guessing on a periodic or random basis. If a password is guessed or cracked during one of these scans, the user will be required to change it.
Enforcement
Any employee found to have violated this policy might be subject to disciplinary action, up to and including termination of employment.
Conclusion
Every security policy ends with a few common elements. These elements clear up all potential miscommunication and confusion on the part of the users, now that they understand what is permitted and what is not.
1. Enforcement: The most essential element is the enforcement and the ramifications to an employee if these policies are violated.
2. Definitions: Not every employee or user understands some of the terminology used in a policy; thus, it is always a good idea to provide yet another level of clarification by defining industry-specific terms.
3. Revisions: Changes are always applied to policies such as these. The source of these changes alter with time, however; it might be a change in management, new laws, clarification of older laws, new threats against your network’s security, your company has decided it wants to become certified (for example, ISO), or perhaps your company has new technology that needs to be covered. All these factors might require a policy change, and it is wise to document the changes.
Users always try to get around the restrictions placed on them via a password policy—no one likes to remember the cryptic passwords required in such a policy. If a user does not remember a password that meets these guidelines, do not worry—he will have to change it soon!
Unfortunately for users, they will have to remember and follow this policy. Password security is the first step in protecting your network; as such, beginning with the right expectations of your users helps to ensure that the overall security of your organization is preserved.
The next section examines a security policy targeted at virtual private networks (VPN) and what to look for to ensure their security.