| Author: | Richard Gadsden |
|---|---|
| Contact: | gadsden@musc.edu |
| Version: | 0.4 |
| Date: | 12 Dec 2006 |
| Status: | DRAFT |
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
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.
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.
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.
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.
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.
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.
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:
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.
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:
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:
Your system should have documented procedures for identifying, reporting, and recovering from information security incidents involving the system.
Typical Procedures:
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:
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:
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'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:
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 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 must have procedures for authenticating every person or entity that seeks access to its protected information.
Typical Procedures:
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:
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:
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.