Information Security Risk Assessment Guidelines for Systems Introduction and Overview Information security risk management is a foundation of our information security program. The risk assessment is an integral part of a risk management process designed to provide appropriate levels of security for information systems and facilities. Information security risk assessments are required for systems by the University of Maine System Information Security Policy and Standards Section 3.1. A risk assessment of the facility in which a system is located is required by Section 6.1.4. Separate guidelines are provided for performing risk assessments of facilities. The risk assessment will help each university determine the acceptable level of risk and the resulting security requirements for the system and its corresponding facility. The university must then devise, implement and monitor a set of security measures to address the level of identified risk. These guidelines should be tailored to the system being assessed. For a new system the risk assessment is typically conducted at the beginning of the System Development Life Cycle (SDLC). For an existing system, risk assessments may be conducted on a regular basis throughout the SDLC and/or on an ad-hoc basis in response to specific events such as when major modifications are made or in response to a security incident or audit. This risk assessment process is based on standard risk assessment practices such as those identified in NIST SP800-30. While NIST identifies a nine-step risk activity process, this guide combines steps and is presented in five phases: 1. System Documentation Phase 2. Security Level Determination Phase 3. Self Assessment Phase 4. Risk Determination Phase 5. Safeguard Determination Phase Completion of the risk assessment will result in a report that will be used to determine the appropriate management action. The risk assessment report will include: A summary of the system architecture and components, and its overall level of security. This summary will also identify the scope or system boundary for the purposes of the report as well as the status of risk assessment for interconnected/cross-dependent systems A self-assessment of the system against the Policy and Standards A list of threats and vulnerabilities, with severity of impact and likelihood of occurrence, the system s current security controls, and its risk levels The recommended safeguards, and a description of the expected level of risk that would remain if these safeguards were put in place The level of residual risk that would remain after the recommended changes are implemented. The Appendix provides a template for the documentation of the Risk Assessment report. UMS Security Risk Assessment Guidelines v1.0 Page 1
1. System Documentation Phase The System Documentation Phase provides a description of the system and the data it handles, as computing assets used to fulfill the organization s business mission. The information owner in conjunction with Campus or System IT provides the system identification, including the system description, business function and assets. This phase also sets the boundaries for the set of components that constitute the information system. An information system is a group of computing and supporting components that share a business function, under common ownership and management. System Identification List the system name, other related information, and the responsible organization. Complete the System Identification table in the Appendix. System Purpose and Description To identify the assets covered by the risk assessment, provide a brief description of the function and purpose of the system and the organizational business processes it supports, including functions and processing of data. Complete System Purpose and Description Table in the Appendix and attach a network diagram defining the system boundaries. Technical Description and Environmental Factors General description of function and purpose the system General functional requirements Business processes supported Applications supported, services running Technical and business users, list of system user accounts System ownership: Shared or dedicated Description of physical components (include asset and tag numbers) Environmental factors that give rise to security concerns General information flow Network diagram with system boundaries Interrelated systems with cross dependencies or interconnections.(include feeder systems) System Connections and Information Sharing Connected components LAN and WAN connections and topology, firewall configurations Software dependencies Interfaces 2. Security Level Determination Phase The Security Level Determination Phase ranks the level of security based on set criteria. The information owner in conjunction with Campus or System IT must determine the appropriate security levels based on the organization s confidentiality, integrity and availability requirements for the information, as well as its criticality to the organization s business mission. This is the basis for assessing the risks to business operations and assets and in selecting appropriate security controls and techniques. UMS Security Risk Assessment Guidelines v1.0 Page 2
Security Level For this step, the team will document the criticality and sensitivity of the information handled by the system, then classify the resulting level of security requirements for the system itself. Complete Information Security Levels and Overall System Security Level Table in the Appendix. Below are information security levels that establish common criteria for security by information category. The first table defines the criticality levels. The second table defines sensitivity levels. In cases where information of varying security levels are combined in one system, the highest security level takes precedence. Information Security Levels by Criticality Criticality Description Catastrophic Very serious Moderately serious Explanation Complete loss of mission capability for an extended period; or would result in the loss of major assets or resources and could pose a threat to human life. Severe impairment to an university s missions, functions, image, and reputation. The impact would place an university at a significant disadvantage; or would result in major damage, requiring extensive repairs to assets or resources. Noticeable impact on an university s missions, functions, or reputation. A breach of this security level would result in a negative outcome; or would result in damage, requiring repairs, to an asset or resource. Criticality Level High Medium Low Information Security Levels by Information Classification Information Classification Compliant Data Business Sensitive Data Explanation and Examples Information which has specified requirements for the control of confidentiality, availability, or integrity of the data due to statute or contract or other law or agreement. Compliant data is information which requires special protection because the misuse could harm members of the UMS community or compromise the mission of the System and/or any one of the Universities. Compliant data includes, but is not limited to, personally-identifiable information, confidential research information, and information that requires protection under law or agreement such as the Maine Data Act, FERPA (the Family Educational Rights and Privacy Act), GLBA (the Gramm-Leach Bliley Act), HIPAA (the Health Insurance Portability and Accountability Act), FTC Red Flag Rule, -by the PCI (Payment Card Industry) data security standards, and data placed on legal hold in accordance with e-discovery. Examples of Compliant Data include: financial records, health records, student educational records, and any information which could permit a person to attempt to harm or assume the identity of an individual. Information that is not the subject of statutory or contractual controls, but where the compromise of the confidentiality, integrity, or availability of the information would result in damage or loss to UMS. Sensitivity Level High Medium UMS Security Risk Assessment Guidelines v1.0 Page 3
Information Classification Unclassified Data Explanation and Examples Information that does not fall into either of the above categories. This includes any information that is declared for public consumption by official authorities. Sensitivity Level Low 3. Self Assessment Phase The goal of the Self Assessment phase is to measure compliance with the Policy and Standards specific to the systems. Use the Self Assessment Checklist in the Appendix to document what measures are being taken. If contractors access or host the system, also complete the part of the checklist that pertains to contractors/third parties. 4. Risk Determination Phase The goal of the Risk Determination Phase is to calculate the level of risk for each threat / vulnerability pair based on the likelihood of a threat exploiting a vulnerability, and the severity of impact that the exploited vulnerability would have on the system, its data and its business function. Consider the impact in terms of loss of confidentiality, integrity or availability of the data classified in the Security Level Determination Phase, Phase 2. Information will be collected in the form of questionnaires, interviews, documentation review, and automated scanning tools. The Risk Determination Phase is comprised of six steps: 1. Review the most recent vulnerability scan and efforts to remedy deficiencies 2. Identify threats and vulnerabilities 3. Identify existing controls to reduce the risk of the threat exploiting the vulnerability. 4. Determine the likelihood of occurrence for a threat exploiting a related vulnerability given the existing controls. 5. Determine the severity of impact on the system by an exploited vulnerability. 6. Determine the risk level for a threat/vulnerability pair given the existing controls. This six-step process for Risk Determination is conducted for each identified threat / vulnerability pair. Use the Risk Determination Table in the Appendix to document the analysis performed in this phase. Review the most recent vulnerability scan Review the vulnerability scan and the associated remaining deficiencies when completing the next step regarding vulnerabilities. Identify Threats and Vulnerabilities Identify potential dangers to information and system (threats) and the system weakness that could be exploited (vulnerabilities), and generate the threat / vulnerability pair and describe the risks that are associated with the vulnerability pair. Common threat/vulnerability pairs are included in the Risk Determination Table. If any of these pairs are not applicable, N/A can be marked on the table. Other threats/vulnerabilities should be considered. Using the output the system purpose and description task, consider the system s connections, dependencies with other systems, inherited risks and controls, risks from software faults and staff errors and malicious intent, and such factors as proximity to the Internet, incorrect file permissions, risks from maintenance procedures and personnel changes. UMS Security Risk Assessment Guidelines v1.0 Page 4
Identify Existing Controls Identify existing controls that reduce the likelihood or probability of a threat exploiting a system vulnerability, and/or reduce the magnitude of impact of the exploited vulnerability on the system. Existing controls may be management, operational or technical controls depending on the threat / vulnerability and the risk to the system. Determine Likelihood of Occurrence Estimate the likelihood that a threat will exploit a vulnerability. Likelihood of occurrence is based on a number of factors that include system architecture, system environment, information system access and existing controls; the presence, motivation, tenacity, strength and nature of the threat; the presence of vulnerabilities; and the effectiveness of existing controls. Refer to this table to when estimating the likelihood that the threat will be realized and exploit the vulnerability on the system. Likelihood Negligible Very Low Low Medium High Very High Extreme Likelihood of Occurrence Levels Description Unlikely ever to occur Likely to occur two/three times every five years Likely to occur once every year or less Likely to occur once every six months or less Likely to occur once per month or less Likely to occur multiple times per month Likely to occur multiple times per day Determine Severity of Impact Determine the magnitude or severity of impact on the system s operational capabilities and the information it handles, if the threat is realized and exploits the associated vulnerability. Determine the severity of impact for each threat / vulnerability pair by evaluating the potential loss in each security category (confidentiality, integrity, availability) based on the system s information security level as explained in the Appendix. Insignificant Minor Significant Damaging Serious Critical Impact Severity Levels Little or no impact Minimal effort to repair, restore or reconfigure Small but tangible harm, maybe noticeable by a limited audience, some embarrassment, some effort to repair Damage to reputation, loss of confidence, significant effort to repair Considerable system outage, loss of connected customers, business confidence, compromise of large amount information Extended outage, permanent loss of resource, triggering business continuity procedures, complete compromise of information Determine Risk Levels Risk level is the likelihood of occurrence multiplied by the severity of impact. The final value is subject to the information owner s and system technical owners discretion. Risk determination For each threat / vulnerability pair, assess the following: - Likelihood of the threat attempting to exercise the vulnerability; UMS Security Risk Assessment Guidelines v1.0 Page 5
- Magnitude of impact if the threat / vulnerability exploit is successful; - Adequacy of planned or existing security controls for reducing or eliminating risk; Note: The project team must decide whether to use only currently implemented controls for this analysis, or to include controls that are budgeted and scheduled for installation, and document that decision in the Report. - Resulting risk to the information on the system from the threat and vulnerability. This table shows the resulting risk level, for each degree of likelihood and each level of severity. Risk Levels Likelihood Impact Severity of Occurrence Insignificant Minor Significant Damaging Serious Critical Negligible Low Low Low Low Low Low Very Low Low Low Low Low Moderate Moderate Low Low Low Moderate Moderate High High Medium Low Low Moderate High High High High Low Moderate High High High High Very High Low Moderate High High High High Extreme Low Moderate High High High High 5. Safeguard Determination Phase The safeguard determination phase involves identification of additional controls, safeguards or corrective actions to minimize the threat exposure and vulnerability to exploitation for each threat/ vulnerability pair with a moderate or high risk level. The residual risk level is the amount of risk that would remain if the recommended control or safeguard were implemented. Safeguard determination steps: 1. Identify controls and safeguards to reduce the risk level of each risk-threat pair, if the risk level is moderate or high. 2. Determine the residual likelihood of occurrence of the threat if the recommended safeguard is implemented. 3. Determine the residual impact severity of the exploited vulnerability once the recommended safeguard is implemented. 4. Determine the residual risk level for the system. Consider safeguards related to testing and maintenance, improved audit capability, and restricting physical access. Recommend Controls and Safeguards Identify controls and safeguards to reduce the risk presented by each threat / vulnerability pair with a moderate or high risk level as identified in the Risk Determination Phase. When identifying a control or safeguard, consider: 1. Security area where it belongs, such as management, operational, technical. 2. Method it employs to reduce the opportunity for the threat to exploit the vulnerability. 3. Its effectiveness in mitigating the risk to information. 4. Policy and architectural parameters required for its implementation in the environment. UMS Security Risk Assessment Guidelines v1.0 Page 6
5. Information security category (confidentiality, integrity, availability, access control, audit, etc.) to which the safeguard applies. 6. Whether the cost of the safeguard is commensurate with its reduction in risk. If more than one safeguard is identified for the same threat / vulnerability pair, list them in this column in separate rows and continue with the analysis steps. The residual risk level must be evaluated during this phase of the assessment and may be further evaluated in risk management activities outside the scope of this project. If the recommended safeguard cannot be completely implemented in the environment due to cost, management, operational or technical constraints, document the circumstances and continue with the analysis. Consider control elements implemented as policies and procedures, training, and improved policy enforcement. Determine Residual Likelihood of Occurrence Follow the directions in the Likelihood of Occurrence step of the Risk Determination phase, while assuming the selected safeguard has been implemented. Determine Residual Severity of Impact Follow the directions in Severity of Impact step of the Risk Determination phase while assuming the selected safeguard has been implemented. Determine Residual Risk Levels Determine the residual risk level for the threat/vulnerability pair and its associated risk once the recommended safeguard is implemented. The residual risk level is determined by examining the likelihood of occurrence of the threat exploiting the vulnerability and the impact severity factors in categories of Confidentiality, Integrity and Availability. Follow the directions in the Risk Levels step of the Risk Determination phase to determine the residual risk level once the recommended safeguard is implemented. Depending on the nature and circumstances of threats and vulnerabilities, a recommended safeguard may reduce the risk level to Low. Make a note of the situation with a description below the table, if needed, if such special conditions exist. UMS Security Risk Assessment Guidelines v1.0 Page 7