...
Step 1: Determine Risk Assessment Scope and Establish Team
Some institutional, state, or federal laws and regulations specify the scope of a required risk assessment (e.g., HIPAA defines the scope as the assessment of the potential risks and vulnerabilities of electronic PHI that is electronically transmitted and stored by the covered entity.)
Others limit the scope of the risk assessment based upon the level of risk affecting IT and information assets (e.g., risk assessments conducted annually for high risk items and bi-annually for medium or low risk items.) The scope of a risk assessment will also include an analysis of how information is accessed, processed, and/or transmitted in business processes.
Before starting the risk assessment, develop a brief description of each technology or information asset’s purpose, functionality, location, data and information criticality and sensitivity. Identify individuals using asset(s) and authentication procedures to gain access to the asset(s).
Determine what changes were made to the asset since the last risk assessment and identify from the documentation its technical components such as software, hardware, databases, and network technology.
The risk assessment team should include individuals from business units/data owners with expertise in business operations and processes as well as information security and information technology staff.
Step 2: Identify and Evaluate Threats
A threat is something or someone that can intentionally or accidentally exploit a specific vulnerability. Generally, there are three general types of threats:
- Natural – floods, earthquakes, tornadoes, etc.
- Human
- Malicious – deliberate actions such as network attacks, unauthorized access, malware upload, etc.
- Non Malicious – unintentional acts such as data entry errors, accidental deletions, etc.
- Environmental – power failure, water damage, heat, etc.
Step 3: Identify and Evaluate Vulnerabilities
A vulnerability is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised – accidentally triggered or intentionally exploited – and result in a security breach or a violation of the system’s security policy. Generally, vulnerabilities can be divided as they relate to:
- Staff / Outsiders
- Facilities and equipment
- Applications
- Communications
- Software and operating systems
Step 4: Evaluate Controls Currently in Place and Identify Gaps
Controls are information security countermeasures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. Measures considered should combine technical, operational, and management controls to ensure adequate security.
Most institutions have already implemented numerous countermeasures to address security threats. Considering the threats and vulnerabilities identified, evaluate if countermeasures currently implemented mitigate or eliminate the likelihood of occurrence of a threat’s exercising a vulnerability.
When unacceptable gaps are found because there is a difference between the asset’s minimum security requirements and the countermeasures in place, there are two possible courses of action. If there are additional controls that are feasible and can be implemented in a reasonable time, then recommendations for addressing those gaps are developed. Otherwise, the management must consider accepting or transferring the risk exposure.
Step 5: Determine Threat Likelihood of Occurrence
The following categories describe the likelihood that a potential vulnerability could be exercised by a given threat:
| Likelihood | Score | Description |
|---|---|---|
| Frequent | 5 | Possibility of repeated incidents |
| Probable | 4 | Possibility of isolated incidents |
| Occasional | 3 | Possibility of occurring sometime |
| Remote | 2 | Not likely to occur |
| Improbable | 1 | Practically impossible |
Example: Flood may be considered to have a Remote likelihood of occurring. Thus the Likelihood Score for Flood is 2.
Step 6: Determine Threat Impact Severity
The adverse impact of a successful threat exercise of a vulnerability can be described in terms of loss or degradation of the confidentiality, integrity, and availability of data. The following describes each impact.
- Loss of Confidentiality: Unauthorized, unanticipated, or unintentional disclosure of confidential data. Such disclosure could result in loss of public confidence, embarrassment, or legal action against System Administration.
- Loss of Integrity: Unauthorized, unanticipated, or unintentional destruction or changes made to data or IT system by either malicious or non-malicious acts. If loss of integrity is not corrected, continued used of corrupted data could result in inaccuracy, fraud, or erroneous decisions.
- Loss of Availability: Data is unavailable to its users impeding the performance of their functions.
The following categories describe the adverse impact of a successful threat exercise of a vulnerability and/or the level of skill required to successfully exploit it:
Severity | Score | Description |
|---|---|---|
High | 4 | Elevated potential for loss; requires only some skill to exploit |
Moderate | 3 | Moderate potential for loss; intermediate skills required to exploit |
Low | 2 | Some potential for loss; requires a high level of skill to exploit |
Insignificant or N/A | 1 | No real potential for loss; requires a very high level of skill to exploit |
Example:
Type of Threat | Impact Severity to | Severity Score | ||
|---|---|---|---|---|
Confidentiality | Integrity | Availability | ||
Natural | ||||
Flood | 1 | 2 | 4 | 2.33 |
Step 7: Determine Risk
To quantify the risk, the numeric values added to each threat are rated based on the following factors:
- Severity of the threat.
- Likelihood of the threat.
Severity Level | Likelihood of Occurrence | ||||
|---|---|---|---|---|---|
Frequent | Probable | Occasional | Remote | Improbable | |
High | |||||
Moderate | |||||
Low | |||||
Insignificant | |||||
Undesirable risk and counter measures should be implemented or improved as soon as possible | |
Undesirable risk and counter measures should be implemented or improved in a reasonable amount of time | |
Acceptable risk and existing counter measures are likely adequate. Management review required. | |
Acceptable risk and existing counter measures are adequate. Management review not required. |
Example: The threat of Flood has a Likelihood of Occurrence of Remote (score of 2) and a Severity Level of Some (score of 2.33). The intersection of both values indicates that that Flood is an acceptable risk and the existing counter measures are likely adequate.
Step 8: Summarize Results and Propose Additional Controls (Risk Treatment Process)
Considering countermeasures currently in place, propose a list of additional controls that could mitigate or eliminate the identified risks as required by security requirements. The goal is to reduce the level of risk to the IT asset to an acceptable level. Consider the following when proposing additional controls:
- Legislation and regulation requirements
- Impact on institutional technology infrastructure and operations
- Benefit derived from implementation
- Total cost of implementation
A cost-benefit analysis may be required to determine which controls are required and appropriate and to ensure that the costs of implementing the controls are justified by the corresponding level of risk reduction.
Step 9: Develop Action Plan
The action plan lists the controls selected to reduce risks and vulnerabilities to a reasonable and appropriate level. A cost-benefit analysis may be required as the basis for the selection of these additional controls.
The action plan prioritizes the implementation actions and projects the start and target completion dates. The action plan summary contains, at least, the following information:
- Selected controls (determined on the basis of feasibility, effectiveness, benefit to the institution, and cost)
- Prioritization
- Required resources for implementing the selected controls
- Responsible Party
- Start date for implementation
- Target completion date for implementation
- Operations and Maintenance requirements.
Step 10: Determine Residual Risk
The reduced level of institutional risk achieved by selecting and implementing additional controls is defined by an associated reduction in the number of flaws or errors, threat likelihood, or magnitude of impact.
Residual risk is the risk remaining after the implementation of the selected controls.
In practice, no information technology system or business process involving information handling is risk-free, and even with additional controls, it may not be possible to completely mitigate levels of risk. This is a normal condition.
As stated at the beginning of this document, the intent of this process is to implement security measures sufficient to reduce risks and vulnerabilities to an acceptable level. If the residual risk affects only the business/data owner department, then the business/data owner department manager is responsible for deciding if the residual risk level is acceptable. If the residual risk affects multiple institutional departments or the institution’s network infrastructure, then the responsibility for accepting the residual risk is shared among executive officers (e.g., department head, CISO or CIO).
Documentation of residual risk contains, at least, the following information:
- A list of controls not considered reasonable or selected for implementation because of adverse impact on institutional technology infrastructure and operations, limited benefit derived from implementation, or cost of implementation.
- For each threat type:
- Vulnerability description
- Residual risk severity level
- Impact severity level
Finally see Taking Risk Assessment from Project to Process: A Novel Approach, a presentation from the 2010 Security Professionals Conference that highlights an approach to risk assessment that is cost-effective, standardized, and simple to deploy.
Additionally, Verizon publishes an annual Data Breach Investigations Report (DBIR), which can be useful for focusing on known threat vectors. Also, several institutions are taking a more proactive approach, partnering with key stakeholders to introduce risk assessments into the project life cycle as early as possible.
...
- Cyber Insurance is one way to reduce risks. However, if interested in this coverage, ask about the terms and conditions and review them carefully for potential exclusions. Most Cyber Insurance policies will not pay benefits if the insurance company determines that information affected during a data breach incident was not encrypted at rest. Additionally, they will scrutinize the protection applied to IT infrastructure where the information was stored to assess levels of protection and can deny the claim if they consider it inadequate or not meeting their standards. This coverage can be very expensive and conducting extensive research is warranted. Also take a look at the EDUCAUSE Cyber Insurance resource page and this informative article from the Wall Street Journal.
- Developing processes similar to The Standard for Personal Digital Identity Levels of Assurance can potentially assist with risk mitigation (see Identity Assurance at Virginia Tech).
Top of page
| Anchor | ||||
|---|---|---|---|---|
|
Resources
| Panel | ||||
|---|---|---|---|---|
| ||||
EDUCAUSE Resources
Initiatives, Collaborations, & Other Resources
|
...
| Anchor | ||||
|---|---|---|---|---|
|
Standards
ISO 31000:2009 | 800-30: Risk Management Guide for Information Technology Systems | APO12.01 | PCI DSS, v3.0, released November 2013, is a standard for assisting with compliance with the Payment Card Industry Data Security Standard (PCI DSS). | ID.RA-1 | 45 CFR 164.308(a) |
Top of page
...
Questions or comments? 
Contact us.
...