Sample Standards

Developing the standards for multiple security domains for two dozen or so policies can be complex and arduous. In the following section, we will create some sample standards based on work with commercial organizations during the past decade.

One practical admonition from experienced security managers is to understand that auditors will hold the security manager to what is written in policies and stan-dards and it will be prudent to ensure some “wiggle room” where needed.

For our sample standards development, let us consider a critical, all-encompass-ing policy regardall-encompass-ing access control. Our deceptively simple access control policy is:

Physical and electronic access to XYZ Corporation information assets must be con-trolled in a manner that effectively precludes the compromise of confidentiality, in-tegrity, and availability.

Considerable work could be required to develop a suitable set of standards that meet all of the aforementioned criteria in terms of providing the necessary controls without being needlessly restrictive.

First, we must consider how many classification levels must be addressed, with consideration of the system and infrastructure capabilities and constraints. That is,

setting standards that cannot be generally met will obviously create a problem.

Some legacy systems might only support six-character passwords, so setting stan-dards that require eight will create instant exceptions that must be considered.

12.5.2.3 Classifications

For most organizations, three or four security classifications will usually be ade-quate and may be excessive. These can include internal, confidential, and restricted in addition to unclassified or public. The granularity of a greater number of classifi-cations may not be warranted by the additional implementation and management requirements. Whatever the decision on the classification levels, optimally, stan-dards will be required for access control for each level, both physical and logical.

This is to avoid excessive restrictions on low-criticality assets and to maintain pro-portionality.

What access must to be considered? Given the aforementioned general access control policy, logical access to applications and systems as well as physical access to facilities must be addressed. Logical access will usually be handled by user ID and passwords so we will need a standard for identification and password authenti-cation. The following is a sample from a project to develop tightly controlled stan-dards for a financial organization, which may be excessive for many organizations but serves to illustrate possible approaches.

Standard Statement

Passwords are the primary authentication method utilized to control access to XYZ Corporation. IT systems and resources. This standard sets forth the minimum crite-ria necessary to ensure adequate security for these systems and minimize the risk of compromise. In addition to the standard, it is the responsibility of all personnel to maintain the security and confidentiality of passwords and to report to Security any situation that may result in compromise.

This standard must be used when passwords or personal identification numbers (PINs) are used as an authentication mechanism. The standard provides require-ments for the following:

앫 User communities 앫 Password/PIN format 앫 Password usage 앫 Password expiration 앫 Password control function 앫 Failed log-in attempts 앫 Password change process 앫 Password reset

앫 Password reuse 앫 Password generators

앫 Password storage 앫 Event logging 앫 Password transport 앫 Inactivity timeout

User Communities

There are several user communities or types of passwords used within XYZ Corpo-ration. These communities are based on the type of entity being authenticated:

앫 Employee user ID

앫 Administrative and superuser ID 앫 Contractor user ID

앫 Business partner user ID 앫 Customer user ID 앫 Service user ID

Password Format

The password format (complexity and length) determines the relative strength of a password. Passwords must conform to the minimum following format constraints, dependent on asset classification:

앫 Restricted: Minimum length eight characters 앫 Confidential: Minimum length ten characters 앫 Secret: Minimum length 12 characters 앫 Maximum length 16 characters

앫 Mix of both alpha and numeric characters 앫 At least one nonalphanumeric character 앫 At least one upper-case character

앫 The numeric value cannot exist exclusively in the last position of the pass-word (i.e., if the passpass-word contains only one numeric value, this numeric val-ue may not be in the last position of the password).

앫 May not be the same as the user ID 앫 Identical characters may not be adjacent

PIN Format

PINs must conform to the following requirements:

앫 Minimum length five numbers 앫 Maximum length 12 numbers

Password Usage

Passwords must be entered by means of individual keystrokes, not scripted in a function key, Web page form, or hot button, and entry must not be displayed on the monitor.

Password Expiration

All passwords must expire. Users must be notified, when possible, two weeks prior to password expiration. Different communities of passwords may expire at different intervals, not to exceed the following maximums:

Community of User ID Password Validity Period

Employee User ID 180 Days

Administrative/superuser ID 90 Days

Contractor user ID 180 Days or length of contract, whichever is less

Business partner user ID 180 Days

Customer user ID 365 Days

Service user ID 365 Days

Password Control Function

When passwords are used as the user authentication scheme for a system, the sys-tem must provide the following functions:

앫 Password expire function

앫 Password expiration notification function 앫 Password change function

앫 Password format enforcement function 앫 Failed log-in enforcement

Failed Log-in Enforcement

The authentication system must be configured so that the system will accept three attempts within a 24-hour period, then disable the associated user ID for a period of 10 minutes. Alternatively, the system may be configured so that the help desk must be contacted to reset the password subsequent to identification and authentication by two specific verifiable items.

Password Change Process

The system password change process must support:

앫 Reauthentication as part of the password change process 앫 All format and standards shall be checked and enforced.

앫 New passwords will be entered twice to ensure no errors.

앫 Users must be notified by e-mail that the password change was successful.

앫 A password must not be changed more then three times within a 24-hour peri-od.

Password Resets

When passwords are reset by a third party or a remote service, the following must be supported:

앫 Users must be authenticated prior to any system or password resets, using a combination of two verification or attestation methods.

앫 Users must be informed of the new password through an approved secure means.

앫 User must change password upon first use.

앫 Temporary passwords must expire within 72 hours.

Password Reuse

Systems shall not allow a password to be reused for 12 months or 15 passwords, whichever is least.

Password Generators

Random-password generators are permitted and desirable when humans are not the users of the password. Password generators must comply with this standard when used.

Password Storage

앫 Passwords are classified at the highest level.

앫 Systems being used to store passwords must be hardened.

앫 Passwords must be stored in an encrypted format using an approved process (i.e., approved one-way hash algorithm, such as SHA-1, MD5).

앫 Only authorized processes/systems may replace passwords within a data store.

앫 Passwords must not be “hard coded” into files, scripts, or programs.

Backup and Recovery

앫 Password stores may be backed up as part of the business process, provided the backup medium is classified and treated at the highest level.

앫 Password files must not be restored (passwords will be reset instead of restor-ing old passwords).

Event Logging

All applications using password authentication must log the following events and time of occurrence:

앫 User log-on 앫 User log-off

앫 User log-off reason, for example, user timed out or user logged off

Systems providing password storage and management must log the following events and time of occurrence:

앫 New user created and by whom 앫 Password change by user 앫 Password reset by whom 앫 User deleted and by whom

앫 For which application or system (if needed or performed remotely)

Password Transport

Passwords shall not be transported or stored in clear text form.

Inactivity Timeout

When an inactivity timeout mechanism is used to secure a system from abandon-ment, the period of time shall not be greater than 20 minutes. The user must reau-thenticate to obtain access. The reauthentication process may not be abbreviated in any way.

Scope

This standard addresses the treatment and characteristics of passwords and PINs used by XYX Corporation at the enterprise level. The standard applies to all infor-mation technology systems both external and internal facing, regardless of geo-graphic location. Passwords for employees and agents of XYZ Corporation and its Affiliates must meet the criteria set by this standard.

Consequence of Noncompliance

Failure to comply with this standard may result in corrective action up to and in-cluding termination and/or civil or criminal prosecution. XYZ Corporation reserves

the right to disclose to anyone, at its discretion, any information at any time without limitation.

Responsibility for Compliance

Any employee, individual, or entity with access to information assets belonging to XYZ Corporation and/or its Affiliates is responsible for complying with this infor-mation security standard.

Management of each department within XYZ Corporation and/or its Affiliates is responsible for ensuring that all employees understand and adhere to all informa-tion security policies, standards, and procedures. Management of each department within XYZ Corporation and/or its Affiliates is also responsible for noting any non-compliance, informing CIS and HR, and initiating corrective actions.

Rationale

Passwords represent the first line of defense for virtually all information assets.

Sharing of passwords, weak passwords, and infrequently changed passwords all pose easy targets for unauthorized users.

The foregoing standard makes a distinction for authentication requirements be-tween various security classification levels. In some situations, stronger authentica-tion may be required for highly sensitive or critical assets and two-factor implemen-tations may be warranted. In some situations, an organization may utilize the authorization standard to define access control for the various classification levels.