MUSC Information Security Standards: Risk Management

Author: Richard Gadsden
Contact: gadsden@musc.edu
Version: 0.4
Date: 02 May 2005
Status: DRAFT

Contents

1. Purpose and Scope

A risk assessment involves the identification and classification of risks and their potential impacts on availability, integrity, and confidentiality in an information system. The purpose of a risk assessment is to enable the specification of security controls for the system that are sufficient to (a) reduce these risks and impacts to acceptable levels, and (b) meet all legal, regulatory and policy requirements.

2. Applicable MUSC Policies

3. Standards

3.1. Who is responsible for risk assessments?

The designated Owner of each information system in the MUSC enterprise is required to conduct risk assessments at appropriate points in the system's life cycle.

3.2. Are risk assessments required for all MUSC systems?

The Owner of every information system within the MUSC enterprise is required to (a) assess the risks to his system, and (b) ensure that security safeguards are implemented and maintained, to reduce risks to reasonable and appropriate levels, and to comply with applicable laws, regulations, and policies.

3.3. Must all risk assessments be documented?

It would be unreasonably burdensome for MUSC to require documented risk assessments for every system within the MUSC enterprise, regardless of the size, purpose, or nature of the system, or the environment in which the system is used.

MUSC requires a *documented* risk assessment for only those systems that meet *one or both* of the following criteria:

  • Protected information is stored by the system
  • The system has been formally designated as a critical system

Protected information is defined in the Information Security policy as “information that, because of its criticality, its sensitivity, and/or legal or regulatory requirements, requires special safeguards.” A documented risk assessment is required for any system that stores protected information. Certain other systems, even though they do not store any protected information, may nevertheless be designated as critical systems by the Office of the CIO; documented risk assessments are also required for these designated systems.

Important

The Owner of a system that does not meet either of the above criteria is still expected to conduct risk assessments and implement appropriate security controls, but MUSC does not require formally documented risk assessments of such a system, and MUSC will not require the Owner of such a system to meet the documentation standards in this document (3.6. What needs to be documented in a risk assessment?, 3.7. Should risk assessment documents be shared or published?, and 3.8. Do risk assessment documents have a retention period?).

3.4. When do risk assessments need to be performed?

The System Owner must conduct risk assessments at appropriate stages in the system life cycle:

  1. Initiation Stage: A preliminary risk assessment should be conducted when initial approval for the system is sought. The findings of this preliminary risk assessment should be reflected in the business plan for the proposed system.
  2. Development/Procurement Stage: A risk analysis should be performed with sufficient depth and detail to enable security requirements for the system to be included in the specifications for the system's development and/or procurement, including any RFP(s) associated with the system.
  3. Implementation Stage: Completion of an accurate and thorough system risk assessment should be one of the deliverables in the project plan for implementing the system. The output of this assessment should include the complete specification of all administrative, operational, physical and technical controls for the system.
  4. Post-Implementation: Additional risk assessments are required after initial system implementation, whenever there are environmental, operational, policy or regulatory changes that substantially affect the system.

3.5. Who should participate in a risk assessment?

The System Owner must ensure that his risk assessment team has members whose collective knowledge of the (proposed, planned, or implemented) system, whose knowledge of the organization, and whose understanding of applicable security policies and regulations, are sufficient to enable the team to identify threats, identify potential vulnerabilities, assess risks, analyze potential controls, specify an optimal set of controls, and communicate their findings to management.

3.6. What needs to be documented in a risk assessment?

The following core information must be included in any documented risk assessment:

  • The name of the System and its designated Owner
  • The effective date of the assessment, the purpose of the assessment, the names and roles of the participants in the assessment, and the name(s) of the assessment's principal author(s)
  • The purpose of the system in relation to MUSC's missions, and a concise description of the system's major function(s)
  • Classification of the system in terms of sensitivity and criticality
  • Documentation (using tables and/or diagrams) of key system components and features, which typically include: hardware, software, communications, users, end-user devices, information flows, data stores, system interfaces, and system boundaries

Beyond the core information listed above, the specific purpose of a given risk assessment will determine what additional information must be produced and documented through the assessment. Specific, additional documentation requirements are listed below for each of the four defined stages in the system development life cycle at which a risk assessment is typically required.

3.6.1. Initiation Stage

  • A preliminary risk assessment report must be produced, including all of the core elements listed above, and listing all major types of security controls that are expected to be required with the proposed system, given the proposed system's sensitivity and criticality, and anticipated threats and vulnerabilities
  • The projected costs of implementing and maintaining all expected security controls for the proposed system must be included in the business plan, including any incremental costs of extending existing enterprise security controls to cover the proposed system
  • Any significant information security risks that the proposed system would introduce to the MUSC enterprise must be documented in the business plan
  • If there are any known or potential problems with the proposed system, in terms of compliance with information security regulations or policies, these compliance issues must be documented in the business plan

3.6.2. Development/Procurement Stage:

  • A formal risk assessment report must be produced, including an accurate and complete inventory of all security controls that are required to be developed/procured with the proposed system
  • The risk assessment report must demonstrate that all reasonably anticipated threats to the system's availability, integrity and confidentiality, and that all functional and assurance requirements imposed by applicable security policies and regulations, have been considered in the specification of security controls for the system
  • The risk assessment report must also demonstrate that all the security specifications for the system are reasonable and appropriate, i.e. that together they will provide sufficient risk mitigation at the lowest overall cost to the MUSC enterprise, and with the lowest overall impact on MUSC's operations and assets
  • If components or services are to be procured by an RFP or other solicitation, then all security controls that are expected to be included in those components or services must be specified in the RFP/solicitation
  • If components or services are to be developed, then any security controls that fall within the scope of development must be included in the development requirements and/or specifications

3.6.3. Implementation Stage:

  • The risk assessment report must demonstrate that all reasonably anticipated threats to the system's availability, integrity and confidentiality, and that all functional and assurance requirements imposed by applicable security policies and regulations, have been considered in the selection of security controls for the system
  • The risk assessment report must also demonstrate that the set of security controls that will be implemented for the system will provide sufficient risk mitigation at the lowest overall cost to the MUSC enterprise, and with the lowest overall impact on MUSC's operations and assets
  • If there are any expected problems with the proposed system, in terms of compliance with information security regulations or policies, these compliance issues must be documented in the risk assessment report
  • The system implementation project plan must clearly identify the resources required to implement and maintain all security controls specified in the risk assessment report
  • The system implementation project team should include appropriate representation from the organizational units responsible for implementing and maintaining the security controls for the system
  • The system implementation project plan must incorporate testing and verification of the security controls for the system, and a final review of security controls to ensure compliance with the functional and assurance requirements of applicable regulations and policies

3.6.4. Post-Implementation

  • A formal risk assessment report must be produced, including an accurate and complete inventory of all security controls for the system
  • Any new or modified security controls, implemented or specified since the previous assessment, must be clearly denoted in the report
  • The specific purpose of the risk assessment must be documented in the report; i.e., the specific environmental, operational, regulatory, or policy change(s) that triggered the need for this post-implementation assessment
  • The risk assessment report must demonstrate that all reasonably anticipated threats to the system's availability, integrity and confidentiality, and that all functional and assurance requirements imposed by applicable security policies and regulations, have been considered in the selection of security controls for the system
  • The risk assessment report must also demonstrate that the system's security controls will, taken together, provide sufficient risk mitigation at the lowest overall cost to the MUSC enterprise, and with the lowest overall impact on MUSC's operations and assets
  • If there are any known or potential problems with the proposed system, in terms of compliance with information security regulations or policies, these compliance issues must be documented in the risk assessment report

3.7. Should risk assessment documents be shared or published?

The System Owner must provide a copy of each documented system risk assessment report to his organizational entity's Information Assurance Compliance Officer (IACO).

The System Owner must carefully control the distribution of all risk assessment documents. Because they contain sensitive information about the security measures implemented and/or planned for the system, they should be shared only with authorized personnel, and only on a need to know basis. Risk assessment reports should not be published.

3.8. Do risk assessment documents have a retention period?

The System Owner must retain all documents and records related to system risk assessments for a minimum of six years.