Purpose

A security risk assessment is used to identify security risks, examine threats to and vulnerabilities of systems, determine the magnitude of risks, and identify the proper

security controls required to reduce the identified risk to an acceptable level defined by the business. This document provides guidance for data and system owners to conduct security risk assessments on their UTHSC resources for the purpose of determining areas of vulnerability and initiating necessary and appropriate remedies to the security of those resources. This standard is also designed to meet compliance requirements for data regulated by federal or state law. This includes, but is not limited to, security requirements and safeguards for the Family Educational Rights and Privacy Act (FERPA), Health Insurance Portability and Accountability Act (HIPAA), or Gramm-Leach-Bliley Act (GLBA).

Scope

This Standard applies to all UTHSC data and systems; regardless of technology, that

transmit, store, utilize, or manipulate UTHSC data. This also applies to all computers or other technology within the UTHSC Enterprise. In short, there are no exceptions nor exemptions of technology to this standard. This standard is applicable to all UTHSC employees, students, and third-party agents/vendors authorized to access UTHSC data.

Definitions

Impact – Impact refers to the magnitude of harm resulting from a threat source exploiting a vulnerability (or set of vulnerabilities).

Likelihood – Likelihood refers to the probability that a given threat source is capable of exploiting a given vulnerability (or set of vulnerabilities). The probability can be derived based on factors namely, discoverability, exploitability, and reproducibility. Predisposing Condition – A condition that exists within an organization, a mission or business process, enterprise architecture, information system, or environment of

operation, which affects (i.e., increases or decreases) the likelihood that threat events, once initiated, results in adverse impacts to organizational operations or assets. An office on the coast being susceptible to hurricanes would be a predisposing condition. Risk – Risk is defined as the function of:

The likelihood of a given threat source exploiting a vulnerability of an asset; and
The resulting impact of the occurrence of the threat event

Risk Assessment – The process of identifying, estimating, and prioritizing risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system.

Risk Tolerance – Risk tolerance is the level of risk the University is willing to tolerate to achieve University or Department objectives.

Security control – A safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements.

Threat Event – A threat event refers to any event during which a threat source, by means of a vulnerability, acts against an asset in a manner that has the potential to cause harm.

Threat Source – The agent or actor by which a vulnerability is compromised. This could be a malicious nation-state, an accidental insider, an environmental event, etc. Vulnerability – A weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. A vulnerability could also include any predisposing conditions.

Responsibilities

Chief Information Security Office (CISO) – Responsible for providing guidance and direction in the assessment, planning, and implementation of all security standards, practices, and commitments required. This individual is responsible for adherence to this standard.

Data/System Custodian – An individual or group within the University that is responsible for the maintenance and operations of the technology asset/system. The asset custodian should know the asset and technical operations very well and be able to advise on the technical impact of a compromised system. The asset custodian coordinates with data owners and system owners to ensure data is properly stored,

maintained, and protected. They are responsible for applying required security controls based on the classification, designated in GP-005-Data Security.

Note: Just like with owners, data and system custodians may be different groups or individuals. For instance, the System Custodian may be responsible for the administration of a database server, while the Data Custodian would be responsible for the data within the database itself.

Data/System/Asset Owner – The owner is usually a senior stakeholder of a University asset/system and is responsible for ensuring that technology functions meet University goals and adhere to University policies and standards. The asset owner is ultimately responsible for ensuring the University security policies are followed and that risks associated with the asset/system are identified and managed to an acceptable level. The owner is ultimately responsible for the data and information being collected and maintained by their department or division. The owner shall address the following:

Review and inventory — Review and inventory IT resources within their areas of responsibility
Assignment of data and or system classification labels — Assign classification based on the system or data type and potential impact level
Approval and Review of Access Rights and Permissions – Ensure that users, groups, and permissions are appropriate and limited to the least amount of privilege needed to perform necessary tasks
Risk Management – Identification and management of risk associated with the data or asset to an acceptable level.

Note: An asset may have separate data and system owners. For instance, the Registrar is the Data Owner for student data but may not be the System Owner for a specific system accessing or storing that data. The same may be true for data that could include financial, employee, healthcare, etc.

ITS Risk Management Function – An individual or group within the University responsible for the ITS risk management approach. They should serve as a bridge between the technical and business function during the risk assessment process and provide oversight of the risk assessment activities to ensure consistent risk-based decisions.

Office of Cybersecurity – An individual or group within the University responsible for the implementation and maintenance of cybersecurity controls in systems supporting

business activities. The Office of Cybersecurity should be able to advise the appropriate measures to address threats to the business.

Risk Approver – Senior stakeholder within the University with the responsibility and accountability to ensure risks are appropriately managed within the University’s tolerance level.

Practice

Risk Assessment Process

Risk assessment is about identifying risks that are specific to the environment and determining the level of identified risks. UTHSC follows the National Institute of Standards and Technology (NIST) Special Publication 800-30 Revision 1, Guide for Conducting Risk Assessments or the latest version of the 800-30. The general steps in a risk assessment are risk identification, risk analysis, risk evaluation, and risk response.

Step 1: Risk Identification

Task A: Identify Assets

The first task is to identify and create an inventory of all physical and logical assets that make up the system that is within the risk assessment scope. Each asset should be classified using the GP-002-Data & System Classification. Use this asset inventory to create a system diagram that provides a visual representation of the interconnectivity and communication paths between the assets that make up the system. The ITS Infrastructure team can provide templates to assist in creating system diagrams.

The authorization boundary defines the scope for a system to facilitate risk management and accountability. The system may be supported by one or more enabling systems that provide support during the system life cycle. Enabling systems are not contained within the authorization boundary of the system and do not

necessarily exist in the system’s environment of operation. An enabling system may provide common (i.e., inherited) controls for the system or may include any type of service or functionality used by the system such as identity and access management services, network services, or monitoring functionality. The connectivity (e.g., API) may need to be in the scope of the authorization boundary between the system and

the enabling system. Finally, there are other systems the system interacts with in the operational environment. The other systems are also outside of the authorization boundary and may be the beneficiaries of services provided by the system or may simply have some general interaction.

Figure 2 illustrates the conceptual view of the system and the relationships among the system, system elements, enabling systems, other systems, and the environment of operation.

Task B: Identify Threats

Figure 2

With the asset inventory list, system diagram, and network architecture diagram, identify the threat events that could exploit vulnerabilities for each asset.

There are many ways that threats and vulnerabilities can be identified for each system. One could start with a list of possible threats and assess each asset based on those possible threats. One could also start from a list of known vulnerabilities for

each asset and assess threats associated with those vulnerabilities. There are many possible approaches to threat identification, and all have different pros and cons. To follow a standardized approach, UTHSC leverages the NIST Risk Management Framework (RMF) to manage the risk lifecycle including the identification of threats. This process starts by classifying each asset which results in a security categorization level. Based on that security level and the asset type, a tailored set of applicable controls can be applied to the system/asset. The risk assessment is then conducted based on the maturity level implementation of those tailored controls. Controls that have not been adequately applied to a system or asset may represent risk to those assets.

The MITRE ATT&CK Framework is another helpful tool in identifying potential threats. It is a knowledge base of adversary tactics and techniques based on real- world observations and includes tactics such as initial access, lateral movement, and privilege escalation. This can be used in conjunction with the NIST RMF.

Task C: Construct Risk Scenarios

Constructing risk scenarios is the last task to complete the Risk Identification Step. This task aims to create “what could go wrong” scenarios that provide realistic and relatable view of risks based on the business context, system environment and pertinent threats.

A well-constructed risk scenario facilitates communication to stakeholders and allows for structured analysis of risks in subsequent steps. A risk scenario should articulate the following four (4) key elements:

Threat Source – The agent or actor by which a vulnerability is compromised.
Threat event – An attack event that has been identified in task B targeting an asset identified in task A.
Vulnerability – A weakness in the asset or processes supporting the asset that can be exploited by the identified threat event.
Consequence – The direct result of the threat event exploiting a vulnerability.

This is illustrated in the “Risk Scenario Model” diagrammed in Figure 3 below.

Figure 3

Some examples of well-constructed risk scenarios are illustrated below. Legend: Threat Source | Threat Event | Vulnerability | Consequence

A malicious outsider could steal a laptop that has not be encrypted or properly secured leading to a breach of student data.

A clinic employee with a publicly visible computer monitor without a privacy screen could accidentally leave a patient record pulled up when helping another patient, exposing patient data.

A cloud service provider that cannot provide disaster recovery testing assurance documentation for a critical service could suffer an unexpected outage resulting in a loss of critical services.

Step 2: Risk Analysis

The goal of risk analysis is to analyze the elements that make up each risk scenario to determine:

The likelihood of a risk scenario occurring; and
The impact (i.e., magnitude of harm) resulting from the occurrence of a risk scenario

Task A: Determine Likelihood

The historical or expected occurrence of an event has traditionally been used as a metric to measure the risk likelihood (e.g., Event is expected to occur once every year or has occurred once in the past year). However, the use of such a metric to measure cybersecurity risk likelihood may not be appropriate due to the dynamic nature of cybersecurity threats. A system that has not been compromised previously does not mean it would not be compromised in the future.

As general guidance, the likelihood of cybersecurity risks should be assessed from the perspective of threats and vulnerabilities. One method is to use a qualitative approach using a scale of 1-5 illustrated in Figure 4 below.

Figure 4

Another method to determine the cybersecurity risk likelihood is to use a semi- quantitative approach illustrated in Figure 5 and consider the following factors:

Discoverability – How easy would an adversary be able to discover the vulnerability of an asset? This is dependent on the availability of information about the vulnerability and the exposure of the vulnerable asset.
Exploitability – How easy would an adversary exploit the vulnerability of an asset? This is dependent on the access rights, complexity of tools, as well as technical skills required to carry out the attack.
Reproducibility – How easy would an adversary be able to reproduce the attack on the asset? This is dependent on the complexity of the exploit customization and the environmental conditions required to carry out the attack.

Figure 5

The following steps can be taken to derive the semi-quantitative likelihood score of a cybersecurity risk scenario:

Assign a score for each of the 3 likelihood factors (i.e., 1 – 5)
Average the score and round off to the nearest whole number
The final score will be the likelihood of the risk scenario; 5 being “ Almost Certain” and 1 being “Highly Unlikely”

Task B: Determine Impact

In general, the manifestation of a risk scenario can compromise the confidentiality, integrity and/or availability of assets (e.g., data, equipment, operations). Any compromise of the assets will translate to adverse impact at the following three (3) levels:

UTHSC Mission – The mission of the University of Tennessee Health Science Center is to improve the health and well-being of Tennesseans and the global community by fostering integrated, collaborative, and inclusive education, research, scientific discovery, clinical care, and public service.
UTHSC Department Objectives – The department objectives are defined by the department conducting the assessment.
UTHSC Obligations – UTHSC must protect our employee’s, student’s, and patient’s interests, data, privacy, and financial future against misuse of their financial, medical, or personal information.

Each risk scenario may be assessed to have different impact ratings in areas of confidentiality, integrity, and availability as well as other areas like brand, reputation, people, compliance, etc. as illustrated in Figures 6 through 9. The highest impact rating should be taken as the final “Impact” score.

Figure 6

Figure 7

Figure 8

Figure 9

Step 3: Risk Evaluation

Risk evaluation is about determining and understanding the significance of risk level, and comprises the following tasks:

Determine Risk Rating
Document risk

Task A: Determine risk rating

Risk is a function of the likelihood of a given threat source initiating a threat event by exploiting a potential vulnerability of an asset causing a resulting impact. This can be illustrated using a risk matrix by multiplying the Likelihood and Impact to calculate the Risk Rating.

Figure 10

Task B: Document Risk

A risk assessment is incomplete without documentation. The outputs from previous steps must be clearly documented in a Risk Register for communication to stakeholders. A Risk Register is a record of all the risk scenarios identified, including their determined risk level. The Risk Register is a living document to be regularly reviewed and updated to ensure that the University’s management has an up-to-date picture of the University’s cybersecurity risks when making risk-informed decisions. The Office of Cybersecurity maintains a Risk Register for use by University departments. Send an email to itsecurity@uthsc.edu for assistance documenting identified risks or accessing the Risk Register.

Having evaluated and documented the identified risks, the next step is to determine the appropriate risk response to keep identified risks within the University’s risk tolerance level.

Step 4: Risk Response

Risk appetite and tolerance:

The University of Tennessee Health Science Center has a low-risk appetite regarding cybersecurity-related risks impacting UTHSC’s mission. In the pursuit of fulfilling its mission, the University will tolerate medium cybersecurity-related risks with appropriate approvals and monitoring.

The University of Tennessee Health Science Center has no appetite for compliance- related technology risks and will adhere to all laws and regulations regarding its operating environments.

The University standard for risk response is one of three options:

Avoid – Risk avoidance means discontinuing an action/activity that exposes the University to the identified risk. This may appear extreme but may be the best course of action if the risk outweighs the benefits. Example: Not conducting online payment transactions is an example of avoiding the risk of attackers hijacking the transaction to make fraudulent payments.
Mitigate- Risk mitigation means putting in place measures to reduce the risk level. This can be achieved through the deployment of security controls. Example: Implementing a firewall to restrict network traffic is an example to mitigate the risk of a system communicating with malicious external servers. Minimum security controls by classification level and asset type are published to provide guidance on risk mitigation. See also, GP-005-Data Security for additional guidance.
Acknowledge- If a risk owner chooses not to avoid or mitigate the risk, they must officially acknowledge the risk. This is accomplished with the “Risk Awareness Form” process. The form must be acknowledged by an approved authority illustrated in Figure 11 below. If the risk cannot be mitigated within

the “Mitigation Timeframe (Figure 11),” a Security Exception or Exemption should be requested and a Risk Awareness Form should be signed.

If the risk is a result of a deviation from UTHSC standards, an exception must be requested as well. Requests for exceptions from security controls, UTHSC IT/InfoSec Standards, or Practices must be submitted in writing to the Office of Cybersecurity using TechConnect and the subsequent Security Exceptions and Exemptions to ITS Security Controls Request Form found therein. Identified risks using the Security Standards Exception/Exemption process must be periodically reviewed. The Security Exceptions and Exemptions to ITS Security Controls Request Form must be signed by an authorized signer with the appropriate level of authority indicated in Figure 11.

As general guidance, a security control is considered appropriate and relevant to a risk when it reduces risk likelihood or reduces risk impact and the control itself does not generate more risk than the risk it is implemented to protect against. Mitigation efforts must be prioritized based on the level of risk to the University.

Figure 11

Whichever risk response option is taken, senior management (with the appropriate level of authority and accountability) within the University must formally approve the selected risk response and monitor any remediation/mitigation activities.

References

GP-001.02-Security Exceptions and Exemptions to ITS Standards Practices & Controls
Security Exceptions and Exemptions to ITS Security Controls Request Form
GP-002-Data & System Classification
MITRE ATT&CK Framework
National Institute of Standards and Technology (NIST) Special Publication 800- 30 Revision 1, Guide for Conducting Risk Assessments or the latest version of the 800-30