MUSC Information Security Guidelines: System Documentation

Author: Richard Gadsden
Contact: gadsden@musc.edu
Version: 0.4
Date: 12 Dec 2006
Status: DRAFT

Contents

1   Purpose and Scope

These guidelines are intended to help MUSC System Owners to meet the documentation responsibilities that are assigned to them by MUSC's information security policies. Two main topics are covered in these guidelines:

  • Documenting your System's risk management process
  • Documenting your System's security policies and procedures

2   Applicable MUSC Policies

3   Applicable MUSC Standards

4   Documenting the Risk Management Process

Every Information System that is implemented and used within the MUSC enterprise must have a designated Owner. The Owner of the Information System is responsible for the risk management process for that System. The risk management process for the System must be documented, throughout the life of the System.

The document MUSC Information Security Guidelines: Risk Management explains the essential elements of the risk management process for an Information System, and introduces the three primary tools that MUSC recommends for documenting the risk management process:

  • System Identification
  • Risk Analysis Worksheet
  • Security Plan Summary

The System's risk management team, under the leadership of the System Owner, can use these three tools to document the risk management process, throughout the life of the system. The System Owner must ensure that these documents are revisited and revised when necessary. The System Owner is also responsible for ensuring that reference copies of each revision are retained for a minimum of six years.

Templates for each of MUSC's recommended documentation tools for risk management can be found on the MUSC Information Security Tools web page.

5   Documenting the System's Policies and Procedures

Policies and procedures are an essential element of any Information System's security plan. System Owners must not only ensure that security policies and procedures (identified in the security plan as necessary for their system's secure operation) are developed and documented, they must also ensure that users and other operational personnel are trained in the procedures that apply to them. Ultimately, the System Owner must ensure that the System's policies and procedures are not only effectively implemented, but also updated as necessary, throughout the life of the System. If the System's security policies and procedures are not documented, and kept current, then none of these other requirements can be met.

5.1   Definitions

A policy addresses a general principle, or a desired goal or result. A policy may also assign high-level responsibilities. As a general rule, implementing a new System does not require the creation of much, if any, new policy. For most Systems, existing security policies, that have already been adopted and documented at the institutional level, are sufficient to articulate the basic security principles and goals that personnel are expected to support. System-specific policies can help to translate institutional policies, which are necessarily general, into terms that are more concrete and relevant to the users of the System. System-specific policies can reinforce and fill gaps in institutional policies, but they may not contradict institutional policies.

A procedure explains how a desired result (often expressed as a policy goal) is actually to be achieved. As a general rule, implementing a new Information System requires the development of many new, system-specific security procedures. All of these procedures need to be documented in sufficient depth and detail to ensure their effective implementation.

While policies identify broad goals and desired results, and often assign high-level responsibilities for meeting these goals, procedures document very specific objectives, the sequence of steps to be followed in reaching those objectives, and the specific responsibilities of each party involved in each of those steps.

Finally, while there is usually little or no risk in publishing policies openly, procedural documents often contain sensitive information about the inner workings of an Information System. Access to these documents needs to be restricted, to those with a need to know. This poses an additional challenge for System Owners, in that the System's procedural documentation must be made readily available to those who need it, but at the same time, it must also be protected from unauthorized access.

5.2   Organizing the Documention of Security Procedures

Some of a System's security procedures are integral to the System's general operational procedures. It may make more sense to integrate the documentation of these security procedures into the System's general user documentation, than it would be to document the security procedures separately.

On the other hand, some security procedures are particularly sensitive in nature, and only a few of the System's personnel have any involvement in implementing them. Such procedures should be documented separately from general operational procedures, and access to this type of documentation should be limited to those with a need to know.

Usually, security procedures can be organized in the same way that other operational procedures are organized. For example, the procedural documentation for most systems is commonly divided into separate documents for users, system administrators, data center operators, etc. It usually makes sense to organize security procedure documents the same way.

In all cases, procedural documentation should be written and organized in a way that maximizes its value and its accessibility to the personnel who are responsible for following the procedure. A procedure that is clearly documented, with the documentation readily accessible for reference to those who need it, when they need it and where they need it, stands a much better chance of being successfully implemented.

Like all other security-related documentation, a System's security policies and procedures must be retained for a minimum of six years. For compliance purposes, it must be possible to track the history of all changes to security policies and procedures. When changes occur, affected users, and any other affected personnel, must be notified.

6   Typical Security Procedures

Although no two information systems are the same, all systems at MUSC need to have documented procedures in the areas required by MUSC's information security policies. Each of these policies, and the procedures generally need to be documented (and implemented) in order for the System to be in compliance with the policy, is covered in the following sections.

Note

The Typical Procedures listed in this section are for illustrative purposes. They may or may not be appropriate for your System, or for your System's threat environment. Only by assessing your System's risks and by understanding your Sytem's environment can your Risk Management Team develop reasonable and appropriate procedures for managing your System's risks.

6.1   Risk Management

The institutional policies, standards and guidelines for risk management are well-documented. As long as you and your Risk Assessment Team use MUSC's recommended tools (the Sytem Identification, Risk Analysis Worksheet, and Security Plan Summary) at all appropriate points in the lifecycle of a System, there is no need for you to develop and document any System-specific procedures to comply with the MUSC Risk Managment Policy.

6.2   Evaluation

This policy requires every System Owner to monitor and evaluate the effectiveness of all System-specific policies and procedures. To comply with this policy, you should document the general procedures (methodologies) that will be used to accomplish these goals for your system, and you should document that these evaluation procedures are being followed.

Typical Procedures:

  • The Risk Assessment Team meets quarterly to review incident reports, discuss any changes in the overall environment, and evaluate the need for changes in procedures and other controls.
  • The System Administrator arranges for the ISO to conduct monthly vulnerability scans of all of the System's networked components.
  • The System Owner contracts for a comprehensive, external penetration test of the System, to be performed no less frequently than annually.

For each of the procedures listed above, you would need to document that the procedure is actually being followed. For example, by keeping minutes of your Risk Assessment Team meetings, results of your monthly vulnerability scans, etc.

6.3   Workforce Security

The managers and supervisors of all workforce members are responsible for determining each assigned workforce member's authorized level of access to any Information System that houses protected information. You must then provision and maintain each user's account with the minimum privileges that are needed for that user to perform his or her job duties, as authorized by his or her supervisor.

Your system must have clearly documented procedures for authorizing and provisioning accounts for your users. Managers and supervisors authorize access for users, but your System Administrator probably provisions the actual user accounts on your system. The primary purpose of your documented procedures is to describe the workflow that connects your users' managers and supervisors to your System Administrator.

Your system must also have clearly documented termination procedures. These are the procedures for adjusting or disabling system access for a workforce member, in a timely manner, whenever his job duties change, or his affiliation or role is terminated.

Typical Procedures:

  • Supervisors sign off on all account creation or change requests (e.g. using an account request form).
  • Supervisors follow a documented procedure for notifying the System Administrator when a workforce members duties or role has been changed or terminated.
  • System Administrators follow documented procedures for performing regular account maintenance, including changes and terminations. As a safeguard, any change to a user's level of access should be reported to the user's supervisor; this report should document the user's current (new) level of access.
  • Your system should have a procedure for handling terminations for cause, and other potentially unfriendly separations. This procedure must ensure timely and effective coordination between the terminated user's supervisor and your System Administrator.
  • Accounts should be regularly reviewed. You should have documented procedures, involving both your users' supervisors and your System Administrator, for periodically reviewing all users' levels of access within the system, and documenting the conduct and outcome of these reviews.

6.4   Awareness and Training

Each workforce member should meet information security training requirements that are appropriate for the workforce member's level of knowledge, experience, and responsibilities. As a System Owner, you share in the responsibility for training each workforce member who has an account on your system.

Typical Procedures:

  • Users must sign a confidentiality agreement as part of the process for getting an account on the system.
  • Users must complete system-specific security training as part of the process for getting an account set up on the system. The training should cover the system's policies and procedures, and the user's specific responsibilities. (Training content, and training records, like other security-related documentation, should be retained for at least six years.)

6.5   Incident Response

Your system should have documented procedures for identifying, reporting, and recovering from information security incidents involving the system.

Typical Procedures:

  • All of the following topics are covered in your system's user training: how to recognize a potential security incident involving or affecting your system; the procedure for reporting a suspected scurity incident; any other steps that users should take if an incident occurs, e.g. to contain potential damage to your system or to others.
  • You have documented your System Administrator's duty to report all known or suspected security incidents involving your system to the CSIRT, and to coordinate incident response and system recovery actions with the CSIRT.

6.6   Contingency Planning

A contingency plan should be developed and maintained for your system. The plan should include policies and procedures for handling disasters and other types of emergencies that might disrupt the operation of the system and/or interrupt access to its information by authorized users.

Typical Procedures:

  • Backup procedures.
  • Restoration and recovery procedures.
  • Procedures for emergency mode operations (business continuity).
  • Procedures for testing the contingency plan.
  • Procedures for periodically reviewing the contingency plan, and revising it in response to environmental, operational, policy or regulatory changes.

6.7   Workstation Use

If any workstations are included within the boundaries of your system, then those workstations must be administered and operated in compliance with MUSC's Workstation Use Policy.

Typical Procedures:

  • The list of authorized applications on each workstation is clearly evident to prospective users, and users are not allowed to install or use any other applications.
  • Users follow documented procedures for initiating, terminating and suspending their sessions on the workstation.
  • The physical access controls that prevent unauthorized access to workstations are documented.
  • The physical access controls and other procedures that prevent unauthorized viewing of workstation displays are documented.

6.8   Device and Media Controls

Any of your system's hardware and/or media that have been used to store protected information must be protected from unauthorized access.

Typical Procedures:

  • Your System Administrator documents the lifecycle of all hardware and storage media in your system's inventory, including tracking of all movement, and the final disposal or re-use of each item.
  • If any mobile or portable devices or media are used to store protected information, then documented procedures are followed to: protect the devices and/or media from loss or theft; protect information on the devices and/or media from disclosure in the event of loss or theft (e.g. by using encryption); enable the System Administrator to quickly and accurately determine the contents of any device and/or media that has been lost or stolen.
  • Storage media that is being disposed or re-used is securely erased or purged, following a documented procedure.
  • Storage media that cannot be securely erased or purged is destroyed, following a documented procedures.

6.9   Access Control

Your system's access control policies and procedures must enforce the principle that access to protected information must be restricted to authorized users of the information.

Typical Procedures:

  • Your System Administrator follows a documented procedure to assign a unique identifier to each user of your system, to enable tracking each user's access to the system's protected information.
  • As part of their system-specific security training, users of your system are trained in the proper procedures for the management of their passwords and other credentials.
  • User sessions that may provide access to protected information are terminated after a reasonable period of inactivity.
  • There is a documented procedure to allow authorized users to obtain access to the system's protected information in the emergency scenarios considered in your system's contingency plan.

6.10   Network Access

For each of your system's components that is connected to the MUSC network, your System Administrator must ensure that the device does not create any reasonably anticipated security threats, either to itself, or to other devices and/or systems on the network.

Typical Procedures:

  • Your System Administrator follows documented procedures for applying patches, configuration changes, or other recommended workarounds for known software vulnerabilities that affect each of the system's components.
  • Documented procedures are followed to prevent unnecessary software from being installed on any of the system's component devices.
  • Documented procedures are followed to prevent unnecessary services from running.
  • Documented procedures are followed for installing and maintaining anti-virus and other controls for preventing and detecting malware.
  • Your System Administrator follows the principle of least privilege when granting rights and privileges to user accounts.
  • Documented procedures are followed to prevent the use of blank passwords, easily guess passwords, and default passwords.

6.11   Audit Controls

Your system must have audit controls that are sufficient to meet all legal, ethical, and business requirements. System activity records must be regularly reviewed by the appropriate personnel.

Typical Procedures:

  • Your System Administrator has followed documented procedures for configuring the system to log user sessions, user access to records containing protected information, and other security related events.
  • There is a documented retention schedule for your system's log records, and it is being followed.
  • There are documented procedures for ensuring regular review and analysis of your system's log records, sufficient to ensure that logged evidence of possible security incidents involving or affecting your system is discovered in a timely manner.
  • There are documented procedures for making your system's log records available for external review by the ISO, and other authorized parties.

6.12   Person or Entity Authentication

Your system must have procedures for authenticating every person or entity that seeks access to its protected information.

Typical Procedures:

  • If possible, your system should use MUSC's centrally managed identity and access management services. (Even if this is not possible during initial implementation, the possibility should still be periodically reassessed during the life of the system, and the centralized services should be adopted if and when feasible.)
  • User authentication procedures that should be documented include: identity proofing; provisioning of passwords and other access credentials; handling of lost, expired, forgotten and/or compromised credentials; password policies; password changing procedures.

6.13   Data Integrity

Each system's integrity controls must protect data against improper alteration or destruction during storage, during processing, and during transmission over electronic communication networks.

Typical Procedures:

  • Your system's procedural and technical controls for preventing and/or detecting improper modification of data within the system should be documented.

6.14   Encryption

Depending on the assessed risks, it may be necessary to encrypt your system's protected information during storage, during processing, and/or during transmission over electronic communication networks. Encryption may be especially warranted in certain known high-risk scenarios, such as if protected information is stored on an end-user workstation or on a mobile or portable device such as a laptop or PDA, or if it is transmitted across a network where its protection against eavesdropping cannot be assured.

Typical Procedures:

  • Documented procedures are used to encrypt some or all network data transmissions within your system, or between your system and other systems. Your documentation should identify all information flows where encryption is used, specify the protocols that are used, and describe how the encryption keys are managed.
  • If your system's policies permit protected information to be stored on end-user worstations or on mobile devices, then you should have documented procedures for encrypting the information and managing the encryption keys. (The workstation or mobile device should also be regularly backed up, to enable your System Administrator to be able to document what its contents were, in the event that it is lost, stolen, or otherwise compromised.)
  • If your system's policies permit your system's protected information to be sent via e-mail, then you should have documented procedures for encrypting the information and managing the encryption keys.

6.15   Documentation

All documentation relating to the management of your system's security must be securely maintained, made available to authorized personnel, and retained for a minimum of six years.

  • You should have documented procedures for collecting and maintaining your system's security management documentation.
  • Your system's security procedures are published in a controlled manner, making them readily available to all authorized users.