Which factor is most important when determining the level of risk your organization is willing to accept?

Risk Determination

Risk determination assesses threats and vulnerabilities to consider the likelihood that known threat sources will be able to exploit identified vulnerabilities to cause one or more adverse events and the consequences if such events occur. Depending on the type of threat under analysis and the nature of the risk assessment being performed, likelihood and impact may be determined using relative ratings or quantitative estimates. Many factors contribute to likelihood, including some that are difficult to measure accurately, such as ease of exploitation, skill level or sophistication of adversaries, visibility of the organization, and attractiveness of the organization or its assets to attack [51]. Accurate quantitative risk determination requires sufficient historical observations or other evidence to support calculation of probabilities, and also requires impact to be expressed in numeric terms, such as dollar values. Organizations may characterize the nature and severity of adverse impacts according to what aspect of security is impacted, the extent of disruption to operations, the resources lost, or the consequences to mission execution or organizational stakeholders. Whether stated in absolute or relative terms, determinations of risk enable risk managers to compare and prioritize risk—within a specific information system or operational context or across the organization—and represent key inputs to risk response decisions.

Risk Determination

The Risk Determination section is the final output based on the results of the Impact Analysis and Likelihood Analysis. The final output that is represented in this section is the Risk Score. Since the risk score is computed for all threat and vulnerability pairs for all systems, it is not feasible to put all of the results in the body of the report. As with Impact and Likelihood analysis, the results for this section are better represented in an Appendix. In our case this is a spreadsheet containing the risk computation. As with the previous section we encourage you to provide an example within the body of the report and will provide an example below. It is also a good idea to present some form of aggregate results since the full risk scores cannot be easily presented. The presentation of the aggregate results could be a summation table of all the risk scores as seen in the example below. All of the content for this section can be derived from the data analysis activities covered in Chapter 4. What follows is a template that can be used for this section:

Risk Determination provides a quantitative risk value representing the systems exposure to a threat exploiting a particular vulnerability after current controls have been considered. This quantitative value is in the form of a Risk Score. A risk score basically follows the following formula:

•

RISK= IMPACT x LIKELIHOOD

The computation for the risk value is a fairly straightforward multiplication of the Impact and Likelihood scores. This computation was performed for all threat and vulnerability pairs for all systems that were in scope for this assessment. An example of what this looks like for one of the hypothetical in scope systems is captured below:

Application: Hospital Information System
Threat (Agent and Action)	Vulnerability	Impact Score	Likelihood Score	Risk Score
Users	Eavesdropping and Interception of data	Lack of transmission encryption leading to interception of unencrypted data	5	2	10
External Intruders, Malicious Insiders, Malicious Code	System intrusion and unauthorized system access	Possible Weak Passwords due to lack of password complexity controls	5	2	10
Users	Denial of user actions or activity	Untraceable user actions due to generic accounts	5	2	10
Malicious Insider, Users	Unchecked data alteration	Lack of logging and monitoring controls	5	3	15
Non-Specific, Natural	Loss of power	Lack of redundant power supply	5	2	10
Natural	Equipment damage or destruction due to natural causes (fire, water, etc.)	Lack of environmental controls	5	1	5

The following risk categorization table was then used to categorize the distinct system risk scores into risk classification “buckets” of High, Moderate, or Low Risk:

Based on the categorization efforts using the Impact versus Likelihood table above, the following table is an example of high risk items for a system are identified:

For all system risk scores and risk classifications please refer to the Data Collection and Computation matrix in the Appendices of this report.

Based on the risk scores, what follows are aggregate views resulting from the risk determination phase. This table presents a ranking of applications based on their aggregate risk scores (sum of all risk scores for all threat and vulnerability pairs). In theory, the higher the aggregate risk score, the greater the risk to the system.

Risk Rank	Application	Aggregate Risk Score
1	HIS	60
2	HR Payroll	50
3	Cardio Research DB	47
4	Email	46
5	Imaging	45

The following table provides a breakdown of the risk scores per system based on each threat and vulnerability pair. The higher the score for each listed system the greater the risk of the threat exploiting the vulnerability.

Threat Agent	Threat Action	Vulnerability	HIS	Cardio Research	HR Payroll	Email	Imaging	Aggregate Score
Users	Eavesdropping and Interception of data	Lack of transmission encryption leading to interception of unencrypted data	10	9	10	15	15	59
External Intruders, Malicious Insiders, Malicious Code	System intrusion and unauthorized system access	Possible Weak Passwords due to lack of password complexity controls	10	12	15	10	10	57
Malicious Insider, Users	Unchecked data alteration	Lack of logging and monitoring controls	15	10	5	9	5	44
Users	Denial of user actions or activity	Untraceable user actions due to generic accounts	10	10	10	6	5	41
Non-Specific, Natural	Loss of power	Lack of redundant power supply	10	3	5	3	5	26
Natural	Equipment damage or destruction due to natural causes (fire, water, etc.)	Lack of environmental controls	5	3	5	3	5	21

Finally based on the aggregation and categorization effort in the previous tables, the following table identifies the high risk systems for each of the risks represented by a threat and vulnerability pair:

Threat Agent	Threat Action	Vulnerability	Score	High Risk Systems
Users	Eavesdropping and Interception of data	Lack of transmission encryption leading to interception of unencrypted data	59	Imaging, Email
External Intruders, Malicious Insiders, Malicious Code	System intrusion and unauthorized system access	Possible weak Passwords due to lack of password complexity controls	57	HR Payroll
Malicious Insider, Users	Unchecked data alteration	Lack of logging and monitoring controls	44	HIS
Users	Denial of user actions or activity	Untraceable user actions due to generic accounts	41	None
Non-Specific, Natural	Loss of power	Lack of redundant power supply	26	None
Natural	Equipment damage or destruction due to natural causes (fire, water, etc.)	Lack of environmental controls	21	None

As seen in the template, the structure of the Risk Determination section follows a very similar pattern as the three intermediary sections (Impact, Likelihood, and Control Analysis) whereby the full results are referenced in a container as it is not feasible to put everything in the body of the report. A key differentiator is that by virtue of it being the final stage of the computation, there are certain aggregate tables that can be presented.

Certainty, Uncertainty, and Probability

Risk management decision-making relies on risk determinations produced through the supporting processes of risk identification and assessment. Organizations need to consider the accuracy and confidence level associated with risk determinations as well as the extent to which risk determinations reflect the complete set of outcomes that could occur. Decision-making is the easiest for risk supported by complete information, including a comprehensive understanding of the possible outcomes and the probability associated with each. When operating under certainty, organizational leaders can objectively compare each outcome and alternative courses of action and make a clear risk-based decision about the preferred choice for the organization. Conditions of certainty are rare in risk management, particularly with respect to information security risk sources where the rapid pace of technological change and frequent emergence of new threats and zero-day exploits make it infeasible to identify all possible events and potential adverse outcomes. Even organizations practicing comprehensive risk management need to work under the assumption that the information supporting their determinations of risk is incomplete and that they may not be aware of all potential sources of risk relevant to the organization. Some theories of risk management and organizational behavior distinguish between risk and uncertainty based on an organization’s ability to assign a probability to each possible outcome. From this perspective organizational risk is the set of all outcomes with calculable frequency distributions, while uncertainty exists either when probabilities cannot be determined for different outcomes or when the set of all possible outcomes is unknown [9].

In many established risk management models, including those contained in international standards [10] and in NIST guidance, uncertainty due to incomplete information about the likelihood or impact of an event or its consequences is a contributing factor to risk and, more importantly, to organizational risk management decisions. Organizations need to understand the uncertainty associated with risk determinations to make properly informed risk-based decisions. Organizations may define their risk tolerance—an essential criterion in all risk-based decisions—not just in terms of the relative level of risk they are willing to accept, but also in terms of how much uncertainty they can accommodate in risk determinations. Where risk tolerance is usually expressed in terms of qualitative risk levels, tolerance for uncertainty may be stated in terms of the confidence afforded by the quality, completeness, and integrity of the information used to determine risk. Organizational decision-makers should acknowledge the uncertainty inherent in managing many types of risk and incorporate practices for responding to risk in the face of uncertainty in their risk management strategies.

Risk Assessment Report

The security assessment report includes detailed findings from the security control assessment, but it does not contain information on threats to the system or its operating environment or on the likelihood of those threats occurring or the impact to the organization should they occur. These risk determinations are typically addressed instead in a risk assessment report, produced as the result of a formal risk assessment process such as that described in Special Publication 800-30, Guide for Conducting Risk Assessments[45]. Risk assessments may be conducted prior to or after the security control assessment is performed with the results documented in a risk assessment report that informs the process of determining what action to take (if any) to remediate weaknesses or deficiencies identified in the security assessment report. (More detailed information on conducting risk assessments appears in Chapter 13.)

Provide a Framework for Security

A security program provides us with a framework in which we can approach the security for our organization and assets. Without a formal plan, our results are likely to be sporadic and vary greatly as one person or another who is involved in the effort applies his/her own interpretation on what the desired result and path to get there actually is. Where a formal security program gives us the equivalent of a GPS-based set of directions and a dynamically updating map on how to get there from where we are now, the lack of such a plan gives us directions relayed via the telephone by someone who is not clear on where we are starting from.

Phase 1: Initiation Phase

In the initiation phase, the system development team met to define how the system would function, the types of data that would be processed or transmitted by the system, and how that data would transition through the system. This phase consisted of three major tasks: preparation; notification and resource identification; and security plan analysis, update, and acceptance.

Preparation ensured that the system was prepared for security certification and accreditation and that the system documentation was correct. Characterization of the system was also evaluated in the preparation phase to ensure that the risk assessment matched with the characterization of the system. Evaluation of the system and system data types resulted in security categorization, threat identification, vulnerability identification, security control identification, and residual risk determination; each of these processes was reviewed as part of the C&A preparation. A major deliverable at this point was the system security plan (SSP) and related security documentation.

Identification and notification of resources was the next step in phase 1. This consisted of notifying all concerned agency officials of the system’s need for C&A; determining the resources that were required to complete the C&A process; and preparing a plan for completing the C&A process that included schedules, key milestones, and deliverables.

It was important at this point to determine who would be assigned to the required positions for various areas of system security and responsibility. These roles included the authorizing official (AO), the certification agent (CA), the user representative (UR), and others responsible for security certification and accreditation support. These additional roles included, but were not limited to, system administrators, data owners, information system security officers (ISSO) or information assurance security officers (IASO), information security managers (ISM), information assurance managers (IAM), and system assessors. Following the identification of key individuals, it was important to determine the level of effort that would be required to complete the system C&A; time, special equipment or tools, and required individual and collective skillsets had to be determined. Three key factors helped determine the level of effort required to complete the C&A process for the system: the size and complexity of the system, the required security controls, and the specific techniques and procedures that would be required to assess the effectiveness of the security controls according to NIST SP 800-53A.

The final task in phase 1 of the C&A process was to analyze, update, and approve the system security plan (SSP). This task required an independent assessor to evaluate the quality and completeness of the SSP. Once the independent assessor evaluated the plan and made corrections or suggestions, the system’s security professionals would update the plan accordingly. The final step in this phase was to submit the plan to the system’s AO or the AO’s designated representative for approval. Once this step was completed, the process could move to the next phase.

Security Authorization Process

The security authorization process is the most involved step in the NIST RMF (Step 5) because it requires the direct or indirect input from each of the previous steps in the NIST RMF (categorization, security control selection, security control implementation, and security control assessment) to make the authorization decision. This process begins with the assembly of the authorization package, where the key and supporting documents needed to make the authorization decision are prepared. After the security authorization package has been assembled, the determination of risk involves an analysis of information gathered from across the organization to provide the authorizing official with enough credible information to support a risk-based decision.

The authorization package includes both key and supporting documents.121Figure 5.13 illustrates the three key minimum documents that are required by the authorizing official: security plan, SAR, and POA&Ms. These three documents are considered the most accurate representation of the security state of the information system and are based on information derived from activities performed throughout the execution of the NIST RMF.

For security controls inherited in whole or in part by another organization (common control provider) or an external service provider, security risk–related information122 may be shared with the authorizing official to supplement the authorization package and assist in making an authorization decision. For all of the key documents included in the authorization package, the owner of the information system or provider of common controls generally has the responsibility of the packaging and submitting the security authorization package.

Risk determination is a critical activity in the authorization process that involves reviewing the documents in the security authorization package. During this activity, the authorizing official will likely place significant importance on the security assessment report [22], but will also use information gathered through other risk management activities to understand the organization’s overall risk exposure123 from operating the information system. In addition, the authorizing official will likely rely upon additional input from the other parts of the organization such as the organization’s risk executive124 and other organizational assessments of risk to assist in making the final determination, in addition to the documents in the security authorization package. “The information system-related security risk information derived from the execution of the NIST RMF is available to the risk executive (function) for use in formulating and updating the organization-wide risk management strategy” [3].

The risk determination concludes in a final determination of an authorization decision as defined in Table 5.10. The authorization decision is achieved through a balance of the security considerations identified through the execution of the NIST RMF, with mission and operational needs for the information system [3]. The security considerations are based on the contents of the authorization package, input from the risk executive, and any other supporting information as determined by the authorizing official.

Table 5.10. Authorization Decisions [3]

After the final authorization decision has been made, the decision is communicated to the system owner or common controls provider. The authorization decision document includes not only the authorization decision, but may also include any applicable terms and conditions125 and a termination date. As an alternative, instead of establishing a termination date (time-drive reauthorizations126), the organization could also require the implementation of a continuous monitoring program (event-driven reauthorization127) that provides the capability to continuously make risk determinations and acceptance. For example, “if the maximum authorization period for an information system is three years, then an organization establishes a continuous monitoring strategy for assessing a subset of the security controls employed within and inherited by the system during the authorization period. This strategy allows all security controls designated in the respective security plans to be assessed at least one time by the end of the three-year period” [3].

Note

As discussed in OMB Memorandum 11-33, FY 2011 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management, OMB waived the requirements for a reauthorization every three years.

20. Is a security reauthorization still required every three years or when an information system has undergone significant change as stated in OMB Circular A 130?128

No. Rather than enforcing a static, three-year reauthorization process, agencies are expected to conduct ongoing authorizations of information systems through the implementation of continuous monitoring programs. Continuous monitoring programs thus fulfill the three year security reauthorization requirement, so a separate re-authorization process is not necessary. In an effort to implement a more dynamic, risk-based security authorization process, agencies should follow the guidance in NIST Special Publication 800-37, Revision 1. Agencies should develop and implement continuous monitoring strategies for all information systems. Agency officials should monitor the security state of their information systems on an ongoing basis with a frequency sufficient to make ongoing risk-based decisions on whether to continue to operate the systems within their organizations. Continuous monitoring programs and strategies should address: (i) the effectiveness of deployed security controls; (ii) changes to information systems and the environments in which those systems operate; and (iii) compliance to federal legislation, directives, policies, standards, and guidance with regard to information security and risk management. Agencies will be required to report the security state of their information systems and results of their ongoing authorizations through CyberScope in accordance with the data feeds defined by DHS.

For an ongoing authorization to be successful,129 the continuous monitoring program needs to integrate information security and risk management into the organization’s SDLC. The continuous monitoring NIST RMF (Step 6) is aligned with the NIST SDLC operations and maintenance (O&M) phase. The application of configuration management and control policies and procedures identifies changes to the information system, and any automated tools and techniques employed ensures security controls are continuously assessed for effectiveness. In addition, the use of automation also supports the concept of “near real-time” ongoing authorizations.130

If a management-driven continuous monitoring strategy is applied during the continuous monitoring step, the authorization decision can be streamlined. For example, if reauthorization actions result in either a time-driven (termination date) or event-driven (significant change131) trigger, and information produced as a result of the ongoing assessment activities continued to demonstrate the effectiveness of the security controls, the only action required for reauthorization might include making updates to the original authorization package and resubmission to the authorizing official for risk acceptance.

7.2.1 Human Error/Human Failure

Based on the results summarized in Ref. [5], human error is a deviation of human performance from that planned, demanded or given by an ideal standard. For the majority of the twentieth century the view of most organizations regarding human error consisted of a statement that blame for an incident/accident was assigned to the worker whose actions were tied up with the given incident/accident – e.g. the human who operated the system at the time at which the incident happened. At present it is possible to trace an opposite trend. The human is considered as a thinking being who is “left at the mercy” of a range of designated, organizational, and momentary factors that can lead to behavior that the external observer can comprehend (even though often in an unqualified way) as human error. It is not so simple to determine whether the error was really caused by human error, and whether the individual concerned was forced to act according to the conditions. It requires much experience in a given field to evaluate what happened, how it happened, and mainly what was the real cause of the incident/accident.

From a management viewpoint, the failure/malfunction is the result of a process consisting of the following:

Initiation (false operation, mistakes, violation of rules, ignorance)

Contributing effects (incorrect organization, inaccurate decisions)

Spreading of defects leading to the accident (organizational nonfunctionality).

Because the influence of the style of management and decision-making is important, we speak of a so-called organizational accident in the form of the Reason Model[5] (Figure 7.1).

Safe (including dependable) system behavior arises from a condition that technical workers (operation, maintenance workers) always follow according to the requisite procedures (the procedure is formed from correct tasks/operations performed correctly). As the Reason Model shows, so-called risky operations always occur (Figure 7.2).

Therefore, in risk determination it is necessary in the context of process analysis to understand the motivation of the intended acts of both terrorists and the insiders (actual employees). Among the insider’s motives are the following:

Inconvenient security procedures (for a safe human life they must be skipped)

Inconvenient plans (for a safe human life the modus operandi solutions must be used)

Poor perception of security risks

Insufficient responsibility

Stress and management attitude or financial profit.

The insider’s motivation is directly related to a safety culture.

We separate the human factor in the sense of human error (human failure) into the intentional and unintentional. Human errors originate in both:

The performance of activities, where their sources are routine behavior, not respecting the operational and security codes, default, omission, bad state of health, bad conditions in the workplace, etc.

The management process, where their sources are ignorance, not respecting the correct, technical, economic, and social aspects, arrogance, etc.

From the analysis of big technological accidents (e.g. Bhopal 1984, Seveso 1976, Chernobyl 1986, Mexico City 1984, Toulouse 2001, Enschede 2000, Buncefield 2005, Lvov 2007, Mexico Bay 2010, etc.)[8], it follows that the damage caused by human errors in management is as a rule far greater than the damage caused during the performance of activities and, therefore, in connection with the human factor, the emphasis is always on the level of safety management.

The results of research into the human factor[9–12] show the following:

For human error analysis, the procedure evaluating human reliability and consequences of its failure, “HRA – Human Reliability Assessment”, is suitable. For analysis of the influence of the human factor, the simple model SHEL (Software, Hardware, Environment, Liveware) is appropriate:

Software – poor understanding of the procedures, poorly written manuals, incorrect check lists, etc.

Hardware – inconvenient equipment, insufficient maintenance, etc.

Environment – poor working surroundings and conditions.

Liveware – relations in the workplace, motivation, insufficient self-assertiveness.

The analysis of human reliability usually starts from human error assessment. For the compilation of its models, net models are often used, i.e. Bayesian, Petri, and other nets. Different scenarios of human error occurrence and consequential impacts are identified, and the occurrence of the probability of human error in real conditions is determined. To the system of systems[3], which is the human system model, is added an additional system, namely a social one. Occasionally, the fuzzy Bayesian model is used to consider the vagueness of the data.

In emergency situations it is important for people to be self-reliant and to get themselves and others to a safe place. This self-reliance increases if humans know the content of warning instructions and if they know how to behave. The effectiveness of warning instructions is influenced by many factors – personal characteristics, form of information processing by a responsible person, social influences, indirect information, etc.

In a system’s vulnerability, the vulnerability that represents humans, i.e. the social system, also contributes.

The result of an examination of incidents and accidents in the context of “the error of the named real person (employee at the equipment, pilot, driver, etc.)” does not help the prevention of incidents and accidents, because it only shows where in the system the error happened, not why it happened there. The error caused by a human in the complex system might be as follows:

Caused by a poor design/proposal

Stimulated by inaccurate training, poorly processed operating procedures, imperfect concepts or eventually by the unfit processing of the operating procedures or manuals.

Such results then allow us to conceal the other basic causes of the incident or accident that must be considered in the prevention of further incidents and accidents.

Reduction of risks in the framework of safety management[13] covers several spheres:

Process safety

Protection of health and safety of an employee (work safety)

Reduction of impacts on the environment[14].

The analysis of the impact of management on the safety of an enterprise/plant/organization/land (further only as “organization”) must therefore emerge from the model of an organizational accident. An organizational accident consists of three basic elements: organizational processes, conditions that caused the origination of errors or violation of rules, and errors and/or violation of rules[15].

Organizational processes include four processes that are part of each technical or technological organization: projection and construction, building, operation, and maintenance. All processes are built as three interconnected activities: assignment of targets in the framework of the economic and social situation of the organization, setup of organization for the realization of determined long-term strategic goals, and management of operational activities.

Each of these processes and activities forms a separate, general type of failure scenario:

Determination of targets – contradictory targets

Organization – disproportionate arrangement (setup)

Management – bad communication, bad planning, inappropriate inspection and monitoring

Projection and construction – faulty projection

Operation – bad operational procedures, bad training and education

Maintenance – bad maintenance plan, bad maintenance procedures.

The conditions that cause the origination of errors are: insufficient training for the task; lack of time; bad separation of signal from noise; misapprehension between designer and user; irreversibility of errors; congestion of information; negative conversion between tasks (bad handover of tasks); bad perception (underestimation) of risk; bad backward link from system; lack of experience; bad instructions and procedures; insufficient check-up; unsuitable education of the person for a given task; unfriendly atmosphere; and dullness and boredom.

Conditions that cause the violation of provisions and rules are: lack of safety culture in an organization; conflicts among management workers and employees; bad morale; bad supervision and check-up; norms and standards permitting the violation of rules; bad perception of the sources of risk; perceptible lack of solicitude and interest by management workers; low pride at own work; a dab hand approach to work that encourages risks; belief that nothing bad can happen; low self-respect; recognized weakness; perceptible tolerance of the violation of rules; double-dealing, ambiguous or obviously meaningless rules; age and gender – young men execute the violation of the rules.

Dangerous pursuance can be split into errors and violation of provisions/rules:

Errors that are a consequence of problems in information processing may be comprehended in relation to the cognitional functions of an individual. They may be reduced by training, improvement of the workplace, interface, better information, etc.

The violations of provisions/rules that are based on motivation. These are social phenomena and they can only be understood in the context of a given organization. The violation can be removed by a change of approach, persuasion, norms, standards, moral and safety culture.

How to avert human failures is fundamentally important. In agreement with research results[9–13,16–18] it is possible to avert human failures of activities and management if:

For management of professional problems only professionals with the capability to lead the working team are authorized (they know how to explain, know how to support, to avert bullying, etc.).

Qualified management of processes that are the result of organization is introduced.

Conditions for qualified work are created.

Sufficient education of workers and the offer of help in the solution of complex tasks are provided.

The motivation and stimulation of workers as regards the adherence of operations and security provisions are ensured.

There is in-depth supervision of processes and their interconnections to projects and furthermore also programs that professionally and directly avert intentional and unpremeditated errors.

As was shown above, the biggest errors originate from human errors in management. Figure 7.3, adapted from Ref. [19], shows the well-known reality that cogitative management workers, while deciding the solution to a problem that is uncertain, adjudicate in their own interests if the probability of success is 0.6 (i.e. failure probability is 0.4), only in the case of losses connected with a decision (i.e. rights of recovery for a decision in their own interests, if the expected result does not materialize) are low, and with the increase in losses they are more prudent.

Among management workers two extreme categories are found:

Gamblers who adjudicate in their own interests, even though possible losses are great

Prudent humans who adjudicate in their own interests even though possible losses are low.

The gamblers occasionally make a huge profit.

The moral principles of human society conforming to UN principles[20] state that gambling with human lives and health is inadmissible, i.e. risk here is not permitted (tolerated). This finding might be the main principle in the selection of personnel for activities on which human lives depend, either directly (drivers, pilots, and the like) and indirectly (managerial workers in enterprises and other organizations who adjudicate the activities and measures that are directly connected with unacceptable risk for persons, property, and other basic protected assets).

Finding the right analysis tools

There are several risk analysis tools available that will help you through the process. And since CMS does not prescribe a specific tool or outline specific instructions on how to conduct the analysis, you have to choose one that best suits your needs, depending on the size of your organization, the sophistication of your record keeping system, and the expertise of your staff.

Several toolkits, guidelines, and risk analysis vendors are worth considering. If you conclude that the risk analysis process is beyond the expertise of your staff, you can hire firms such as Coalfire, Principle Logic, or several other reputable vendors. For detailed guidelines on performing a risk analysis, the first source to review is the National Institute of Standards and Technology (NIST), part of the US Department of Commerce. NIST publishes Guide for Conducting Risk Assessments [8].

Herzig, Walsh, and Gallagher also describe a detailed risk analysis process in their guide to healthcare security [9]. Their approach includes (1) creating an inventory of applications and systems, (2) identifying threats, (3) determining what safeguards are currently in place to deal with those threats, (4) identifying vulnerabilities, and (5) estimating the likelihood that each threat will materialize. The remaining steps include an impact analysis, a risk determination that includes a numerical score, advice on how to mitigate the risks you spot, and a final documentation phase.

Their risk score plots the potential impact of a risk against the likelihood of it occurring to generate a number from 1 to 9—referred to as the OCTAVE approach—which can then be used to help you determine how much time and resources you want to devote to fixing the problem.

As I have mentioned previously, HHS and the Office of Civil Rights place a great deal of emphasis on documenting the results of your risk analysis. Herzig et al’s recommendations on the final documentation are worth a closer look. They suggest creating three types of documents: Risk profiles, a risk analysis report, and a risk remediation report. One especially valuable feature of their risk analysis report is its mitigate/transfer/accept option. This lets the organization make a list of potential safeguards or “controls,” designate the amount of resources needed to put them in place, and decide whether to install the control (ie, mitigate the risk), pass on the responsibility to someone else (eg, transfer the risk to a cybersecurity insurance firm for example), or just accept the risk without doing anything.

The purpose of these documents, as well as those generated by several other risk analysis tools, is to prove to government auditors that you have taken your responsibility to protect patient information seriously and have made a reasonable effort to adhere to the HIPAA privacy and security rules. The authorities do not expect you to create an impenetrable fortress, but neither do they want a simple checklist completed.

HIMSS also provides resources to help providers perform a risk analysis [10]. Its risk assessment toolkit includes white papers, best practices, and a variety of other resources to help providers manage the process. I have featured one of its tools below, which uses the example of a small medical practice to keep things simple. Also keep in mind that the description given subsequently only covers a portion of the assessment process. Since the primary audience for this book is executives and other decision makers and not security specialists or compliance officers, my purpose is not to provide a detailed how-to guide but a general overview that will allow you to provide direction to those who are responsible for actually doing the analysis.

HIMSS provides the tool/sample analysis as an Excel file and assumes the practice has five employees, including a physician, biller, nurse—who doubles as practice manager—and two administrative assistants. It also assumes you have an in-house server with an EHR system and practice management software, as well as a cloud-based email system and a laptop to run EKGs.

The sample analysis contains cells that allow the practice to plug in its threats and vulnerabilities, and the nature of the risk each vulnerability presents. It also asks you to estimate the risk level for each vulnerability as low, medium, or high, and requires you to list the likely impact of each threat and what existing safeguards are in place to prevent a mishap. So, for example, one of the vulnerabilities listed is a missing policy and procedures manual that outlines the practice’s security plan. Without a manual, the practice has no clear cut direction from the physician owner defining best practices. That is a serious deficiency in the mind of any competent auditor.

One of the threats described in this Excel file is from an employee who wants to steal sensitive data or simply does not know enough about basic security to take reasonable precautions. Without specific policies that tell staffers not to write system passwords on Post-its that are pasted next to their workstations, for instance, the physician owner will be held responsible when a CMS auditor shows up and spots this obvious mistake.

Similarly, without a written policy that instructs staffers not to click on hyperlinks in suspicious emails, it is that much easier for an outsider to trick them into logging into a malicious web site that can track their keystrokes or plant some other type of malware on your server.

Another vulnerability in the HIMSS sample risk analysis is described as: “Unauthorized access of data transmitted over the Internet (eg, remote access use by employees/contractors or transmitting data to business associates)”. In this sample analysis, the likelihood of a data breach resulting from this specific vulnerability is listed as low because the practice was smart enough to only allow remote access to its server through an encrypted virtual private network or VPN. It also explains that transmissions from their business associate use a secure socket layer or SSL encrypted web browser.

Speaking of business associates, in 2013, HHS updated the privacy and security protections originally incorporated in HIPAA, which was introduced in 1996. Back then, the primary focus had been on medical practices, hospitals, health plans, and a variety of health professionals. The more recent Omnibus Rule, which is based on statutory changes under the HITECH Act, put a great deal more emphasis on the responsibilities of vendors, contractors, and subcontractors working with these organizations and clinicians. These business associates (BAs) are now required to do a risk analysis as well, and healthcare organizations have to take into account their relationships with their BAs when they do their own risk analysis, as you will learn subsequently.

Creating an Information Systems Risk Program

The objectives of any information risk program should introduce the organization to a range of risk assessment models and give management something to use immediately. Some of the key skills that should be transferred to management in a risk program include the following key areas which have been defined to be the core components of a risk management process:

Be able to competently conduct an information security risk assessment

Have a basic understanding and the required knowledge to perform asset identification and classification for a basic organization

Perform threat identification and understand how to classify threats

Perform vulnerability identification and classification based on the organization's profile

Perform a control analysis for a selected organization

Understand how to perform a likelihood determination using both quantitative and qualitative methods

Be able to conduct an impact analysis, based on business and management requirements

Use the knowledge of processes above in order to complete a risk determination for an organization

Identify control recommendations for the organization and understand the various types of control and implementation programs available

Develop skills to enable the auditor to effectively document the results of the above processes

Identify pertinent standards and regulations and their relevance to information security management

Describe legal and public relations implications of security and privacy issues

As such, completion of the program should develop the knowledge necessary to allow it to:

Identify critical information assets within an organization that they are familiar with

Identify and specify security controls for a variety of systems

Specify effective monitoring controls and understand how these might be implemented within an organization

The Assessment Process

The following diagram illustrates the four-phase approach to performing a Threat and Risk Assessment.

Figure 20.7. Risk Assessment Methodology

Phase 1 - Preparation and Identification

Current Business Practices

The first step in performing a Threat and Risk Assessment is to define the business practices that are required by the organization to accomplish corporate goals. The current business practices of the organization are documented by analyzing the organization's mission statement, corporate plan, type of clients, and the services that it provides.

The Future

It is critical that the organization's future business practices and corporate goals are considered throughout the Threat and Risk Assessment process. The plans of the organization must be documented at the start to avoid any possible oversight, preventing the assessment from becoming obsolete within a short period of time.

Identification of Information Assets

The organization's information assets should be identified to determine what has to be protected. This requires producing an inventory of all information systems and their assets. Each list typically includes the following information:

▪

System owner

▪

System location

▪

Nature of business

▪

Type of information processed

▪

Purpose or application of the system

▪

System configuration

▪

User community

▪

Any known inherent strengths or weaknesses of the system

Information Value

After an inventory of information assets has been produced, a Statement of Sensitivity is documented for each asset. This step documents the asset's value to the organization and should reflect its criticality. The statement is produced by analyzing the system and the data it processes with regard to integrity, confidentially and availability requirements.

Threat Assessment

The next step is to identify all threats and threat sources to the organization's information assets and assign a classification that reflects the probability of its occurrence. The five levels of threat classification are defined as follows:

▪

Low: no past history and the threat is unlikely to occur

▪

Low Plus: no past history and the threat could occur

▪

Medium: some past history and the threat could occur

▪

Medium Plus: some past history and the threat is likely to occur

▪

High: significant past history and the threat is likely to occur

Phase 2 - Security Architecture Analysis

Required Security Architecture

The information gathered in phase I is used to document the business requirements for security within the organization. The key security strategies are identified that will enable the organization to effectively protect its information assets.

Each pre-determined threat to the information assets is matched with an effective safeguard or safeguards. A safeguard is described as a number of Security Enforcing Functions (SEFs); associated mechanisms that perform that function are the Security Mechanisms (SM). The process of identifying the required SEFs and the associated mechanisms gives the organization a security architecture baseline to work from.

Identification of Current Security Architecture

The organization's current security architecture is documented to identify existing Security Enforcing Functions (SEF) and Security Mechanisms (SM). These safeguards and any existing policy or doctrine are identified so as to produce the current security baseline. This enables identification of differences between the current and required security baselines.

Phase 3 - Risk Assessment

Gap Analysis

A gap analysis is performed to highlight any differences between the organization's current security architecture and the required security architecture, determined in phase II of the assessment. The output from this analysis will give the reviewer an indication of the residual risk.

Risk Assessment

After the gap analysis has been performed the determined residual risk has to be assessed. This assessment produces a level of risk that is measured by the probability of compromise to the confidentiality, integrity or availability of the designated information system and the data processed on it. Determining the level of risk is completed by comparing the relationship between the threats associated to the residual risks and known vulnerabilities or weaknesses.

Phase 4 - Recommendations

Known Deficiencies

When the assessment of the systems safeguards indicates that they are not able to effectively counter known threats, additional safeguards will be recommended so as to reduce the risk to an acceptable level. The reviewer should also recommend the type of safeguard required, its priority, and suggested schedule of implementation.

Risk Management Plan

The Threat and Risk Assessment process provides the system manager with an appreciation of the status of the safeguards protecting information assets within her organization. An assessment of the adequacy of existing safeguards is performed so as to provide recommendations to assist the system manager in making an informed decision as to which risks the organization should manage or accept.

The level of acceptable risk is a managerial decision that should be based on the information and recommendations provided in the Threat and Risk Assessment.

Assessment and Conclusion

This methodology has been successful in providing assessments for organizations by producing relevant results. This is achieved by considering the business value of information and the business practices of the organization.

The four-phase approach provides a logical progression that enables the client to trace through the results from each phase to see how the recommendations were obtained.