Strategic Security Intelligence

Information Resource Guide

4.0 Risk Analysis

4.1 The 7 Processes

4.1.0 Process 1 - Define the Scope and Boundary, and Methodology

This process determines the direction that the risk management effort will take. It defines how much of the LAN (the boundary) and in how much detail (the scope) the risk management process should entail. The boundary will define those parts of the LAN that will be considered. The boundary may include the LAN as a whole or parts of the LAN, such as the data communications function, the server function, the applications, etc. Factors that determine the boundary may be based on LAN ownership, management or control. Placing the boundary around a part of the LAN controlled elsewhere may result in cooperation problems that may lead to inaccurate results. This problem stresses the need for cooperation among those involved with the ownership and management of the different parts of the LAN, as well as the applications and information processed on it.

The scope of the risk management effort must also be defined. The scope can be thought of as a logical outline showing, within the boundary, the depth of the risk management process. The scope distinguishes the different areas of the LAN (within the boundary) and the different levels of detail used during the risk management process. For example some areas may be considered at a higher or broader level, while other areas may be treated in depth and with a narrow focus.

For smaller LANs, the boundary may be the LAN as a whole, and the scope may define a consistent level of detail throughout the LAN. For larger LANs, an organization may decide to place the boundary around those areas that it controls and to define the scope to consider all areas within the boundary. However the focus on data communications, external connections, and certain applications might be more narrow. Changes in the LAN configuration, the addition of external connections, or updates or upgrades to LAN software or applications may influence the scope.

The appropriate risk management methodology for the LAN may have been determined prior to defining the boundary and scope. If the methodology has already been determined, then it may be useful to scrutinize the chosen methodology given the defined boundary and scope. If a methodology has not been chosen, the boundary and scope information may be useful in selecting a methodology that produces the most effective results.

4.1.0.1 Process 2 - Identify and Value Assets

Asset valuation identifies and assigns value to the assets of the LAN. All parts of the LAN have value although some assets are definitely more valuable than others. This step gives the first indication of those areas where focus should be placed. For LANs that produce large amounts of information that cannot be reasonably analyzed, initial screening may need to be done. Defining and valuing assets may allow the organization to initially decide those areas that can be filtered downward and those areas that should be flagged as a high priority.

Different methods can be used to identify and value assets. The risk methodology that an organization chooses may provide guidance in identifying assets and should provide a technique for valuing assets. Generally assets can be valued based on the impact and consequence to the organization. This would include not only the replacement cost of the asset, but also the effect on the organization if the asset is disclosed, modified, destroyed or misused in any other way.

Because the value of an asset should be based on more than just the replacement cost, valuing assets is one of the most subjective of the processes. However, if asset valuation is done with the goal of the process in mind, that is, to define assets in terms of a hierarchy of importance or criticality, the relativeness of the assets becomes more important than placing the "correct" value on them.

The risk assessment methodology should define the representation of the asset values. Purely quantitative methodologies such as FIPS 65 may use dollar values. However having to place a dollar value on some of the consequences that may occur in today’s environments may be sufficient to change the perception of the risk management process from being challenging to being unreasonable.

Many risk assessment methodologies in use today require asset valuation in more qualitative terms. While this type of valuation may be considered more subjective than a quantitative approach, if the scale used to value assets is utilized consistently throughout the risk management process, the results produced should be useful. Figure 4.2 shows one of the simplest methods for valuing assets. Throughout this discussion of the risk management process, a simple technique for valuing assets (as shown in Figure 4.2), determining risk measure, estimating safeguard cost, and determining risk mitigation will be presented. This technique is a simple, yet valid technique; it is being used here to show the relationship between the processes involved in risk management. The technique is not very granular and may not be appropriate for environments where replacement costs, sensitivities of information and consequences vary widely.

One of the implicit outcomes of this process is that a detailed configuration of the LAN, as well as its uses is produced. This configuration should indicate the hardware incorporated, major software applications used, significant information processed on the LAN, as well as how that information flows through the LAN. The degree of knowledge of the LAN configuration will depend on the defined boundary and scope. Figure 4.3 exemplifies some of the areas that should be included.

After the LAN configuration is completed, and the assets are determined and valued, the organization should have a reasonably correct view of what the LAN consists of and what areas of the LAN need to be protected.
 
 

4.1.0.2 Process 3 - Identify Threats and Determine Likelihood

The outcome of this process should be a strong indication of the adverse actions that could harm the LAN, the likelihood that these actions could occur, and the weaknesses of the LAN that can be exploited to cause the adverse action. To reach this outcome, threats and vulnerabilities need to be identified and the likelihood that a threat will occur needs to be determined.

Large amounts of information on various threats and vulnerabilities exist. The Reference and Further Reading Sections of this document provide some information on LAN threats and vulnerabilities. Some risk management methodologies also provide information on potential threats and vulnerabilities. User experience and LAN management experience also provide insight into threats and vulnerabilities.

The degree to which threats are considered will depend on the defined boundary and scope defined for the risk management process. A high level analysis may point to threats and vulnerabilities in general terms; a more focused analysis may tie a threat to a specific component or usage of the LAN. For example a high level analysis may indicate that the consequence due to loss of data confidentiality through disclosure of information on the LAN is too great a risk. A more narrowly focused analysis may indicate that the consequence due to disclosure of personnel data captured and read through LAN transmission is too great a risk. More than likely, the generality of the threats produced in the high level analysis, will, in the end, produce safeguard recommendations that will also be high level. This is acceptable if the risk assessment

was scoped at a high level. The more narrowly focused assessment will produce a safeguard that can specifically reduce a given risk, such as the disclosure of personnel data.

The threats and vulnerabilities introduced in Section 2 may be used as a starting point, with other sources included where appropriate. New threats and vulnerabilities should be addressed when they are encountered. Any asset of the LAN that was determined to be important enough (i.e., was not filtered through the screening process) should be examined to determine those threats that could potentially harm it. For more focused assessments, particular attention should be paid to detailing the ways that these threats could occur. For example, methods of attack that result in unauthorized access may be from a login session playback, password cracking, the attachment of unauthorized equipment to the LAN, etc. These specifics provide more information in determining LAN vulnerabilities and will provide more information for proposing safeguards.

This process may uncover some vulnerabilities that can be corrected by improving LAN management and operational controls immediately. These improved controls will usually reduce the risk of the threat by some degree, until such time that more thorough improvements are planned and implemented. For example, increasing the length and composition of the password for authentication may be one way to reduce a vulnerability to guessing passwords. Using more robust passwords is a measure that can be quickly implemented to increases the security of the LAN. Concurrently, the planning and implementation of a more advanced authentication mechanism can occur.

Existing LAN security controls should be analyzed to determine if they are currently providing adequate protection. These controls may be technical, procedural, etc. If a control is not providing adequate protection, it can be considered a vulnerability. For example, a LAN operating system may provide access control to the directory level, rather than the file level. For some users, the threat of compromise of information may be too great not to have file level protection. In this example, the lack of granularity in the access control could be considered a vulnerability.

As specific threats and related vulnerabilities are identified, a likelihood measure needs to be associated with the threat/vulnerability pair (i.e. What is the likelihood that a threat will be realized, given that the vulnerability is exploited?). The risk methodology chosen by the organization should provide the technique used to measure likelihood. Along with asset valuation, assigning likelihood measures can also be a subjective process. Threat data for traditional threats (mostly physical threats) does exist and may aid in determining likelihood. However experience regarding the technical aspects of the LAN and knowledge of operational aspects of the organization may prove more valuable to decide likelihood measure. Figure 4.4 defines a simple likelihood measure. This likelihood measure coincides with the asset valuation measure defined in Figure 4.1. Although the asset valuation and the likelihood measures provided in this example appear to be weighted equally for each threat/vulnerability pair, it is a user determination regarding which measure should be emphasized during the risk measurement process.

4.1.0.3 Process 4 - Measure Risk

In its broadest sense the risk measure can be considered the representation of the kinds of adverse actions that may happen to a system or organization and the degree of likelihood that these actions may occur. The outcome of this process should indicate to the organization the degree of risk associated with the defined assets. This outcome is important because it its the basis for making safeguard selection and risk mitigation decisions. There are many ways to measure and represent risk. [KATZ92] points out that depending on the particular methodology or approach, the measure could be defined in qualitative terms, quantitative terms, one dimensional, multidimensional, or some combination of these. The risk measure process should be consistent with (and more than likely defined by) the risk assessment methodology being used by the organization. Quantitative approaches are often associated with measuring risk in terms of dollar losses (e.g. FIPS 65). Qualitative approaches are often associated with measuring risk in terms of quality as indicated through a scale or ranking. One dimensional approaches consider only limited components (e.g. risk = magnitude of loss X frequency of loss). Multidimensional approaches consider additional components in the risk measurement such as reliability, safety, or performance. One of the most important aspects of risk measure is that the representation be understandable and meaningful to those who need to make the safeguard selection and risk mitigation decisions.

Figure 4.5 provides an example of a one dimensional approach for calculating risk. In this example, the levels of risk are now normalized (i.e. low, medium and high) and can be used to compare risks associated with each threat. The comparison of risk measures should factor in the criticality of the components used to determine the risk measure. For simple methodologies that only look at loss and likelihood, a risk measure that was derived from a high loss and low likelihood may result in the same risk measure as one that resulted from a low loss and high likelihood. In these cases, the user needs to decide which risk measure to consider more critical, even though the risk measures may be equal. In this case, a user may decide that the risk measure derived from the high loss is more critical than the risk measure derived from the high likelihood.

With a list of potential threats, vulnerabilities and related risks, an assessment of the current security situation for the LAN can be determined. Areas that have adequate protection will not surface as contributing to the risk of the LAN (since adequate protection should lead to low likelihood) whereas those areas that have weaker protection do surface as needing attention.

4.1.0.4 Process 5 - Select Appropriate Safeguards

The purpose of this process is to select appropriate safeguards. This process can be done using risk acceptance testing.

Risk acceptance testing is described by [KATZ92] as an activity that compares the current risk measure with acceptance criteria and results in a determination of whether the current risk level is acceptable. While effective security and cost considerations are important factors, there may be other factors to consider such as: organizational policy, legislation and regulation, safety and reliability requirements, performance requirements, and technical requirements.

The relationship between risk acceptance testing and safeguard selection can be iterative. Initially, the organization needs to order the different risk levels that were determined during the risk assessment. Along with this the organization needs to decide the amount of residual risk that it will be willing to accept after the selected safeguards are implemented. These initial risk acceptance decisions can be factored into the safeguard selection equation. When the properties of the candidate safeguards are known, the organization can reexamine the risk acceptance test measures and determine if the residual risk is achieved, or alter the risk acceptance decisions to reflect the known properties of the safeguards. For example there may be risks that are determined to be too high. However after reviewing the available safeguards, it may be realized that the currently offered solutions are very costly and cannot be easily implemented into the current configuration and network software. This may force the organization into either expending the resources to reduce the risk, or deciding through risk acceptance that the risk will have to be accepted because it is currently too costly to mitigate.

Many sources exist that can provide information on potential safeguards. The methodology discussed here defines safeguards in terms of security services and mechanisms. A security service is the sum of mechanisms, procedures, etc. that are implemented on the LAN to provide protection. The security services (and mechanisms) provided in Section 2 can be used as a starting point. The security services should be related to the threats defined in the risk assessment.

In most cases the need for a specific service should be readily apparent. If the risk acceptance results indicate that a risk is acceptable, (i.e., existing mechanisms are adequate) then there is no need to apply additional mechanisms to the service that already exists.

After the needed security services are determined, consider the list of security mechanisms for each service. For each security service selected, determine the candidate mechanisms that would best provide that service. Using the threat/vulnerability/risk relationships developed in the previous processes, choose those mechanisms that could potentially reduce or eliminate the vulnerability and thus reduce the risk of the threat. In many cases, a threat/vulnerability relationship will yield more than one candidate mechanism. For example the vulnerability of using weak passwords could be reduced by using a password generator mechanism, by using a token based mechanism, etc. Choosing the candidate mechanisms is a subjective process that will vary from one LAN implementation to another. Not every mechanism presented in Section 2 is feasible for use in every LAN. In order for this process to be beneficial, some filtering of the mechanisms presented needs to be made during this step.

Selecting appropriate safeguards is a subjective process. When considering the cost measure of the mechanism, it is important that the cost of the safeguard be related to the risk measure to determine if the safeguard will be cost-effective. The methodology chosen by the organization should provide a measure for representing costs that is consistent with the measures used for representing the other variables determined so far. Figure 4.6 shows a cost measure that is consistent with the other measuring examples presented. This cost measuring method, while appearing to only consider the cost of the safeguard, can have the other factors mentioned above factored in.

When a measure (or cost) is assigned to the safeguard, it can be compared to the other measures in the process. The safeguard measure can be compared to the risk measure (if it consists of one value, as shown in Figure 4.7) or the components of the risk measure. There are different ways to compare the safeguard measure to the risk measure. The risk management methodology chosen by the organization should provide a method to select those effective safeguards that will reduce the risk to the LAN to an acceptable level.

4.1.0.5 Process 6 - Implement And Test Safeguards

The implementation and testing of safeguards should be done in a structured manner. The goal of this process is to ensure that the safeguards are implemented correctly, are compatible with other LAN functionalities and safeguards, and provide expected protection. This process begins by developing a plan to implement the safeguards. This plan should consider factors such as available funding, users’ learning curve, etc. A testing schedule for each safeguard should be incorporated into this plan. This schedule should show how each safeguard interacts or effects other safeguards (or mechanisms of some other functionality). The expected results (or the assumption of no conflict) of the interaction should be detailed. It should be recognized that not only is it important that the safeguard perform functionally as expected and provide the expected protections, but that the safeguard does not contribute to the risk of the LAN through a conflict with some other safeguard or functionality.

Each safeguard should first be tested independently of other safeguards to ensure that it provides the expected protection. This may not be relevant to do if the safeguard is designed to interwork with other safeguards. After testing the safeguard independently, the safeguard should be tested with other safeguards to ensure that it does not disrupt the normal functioning of those existing safeguards. The implementation plan should account for all these tests and should reflect any problems or special conditions as a result of the testing.

4.1.0.6 Process 7 - Accept Residual Risk

After all safeguards are implemented, tested and found acceptable, the results of the risk acceptance test should be reexamined. The risk associated with the threat/vulnerability relationships should now be reduced to an acceptable level or eliminated. If this is not the case, then the decisions made in the previous steps should be reconsidered to determine what the proper protections should be.

4.2 RCMP Guide to Threat and Risk Assessment For Information Technology

4.2.1 Introduction

This guide is intended to assist practitioners in assessing the threats and risks to Information Technology (IT) assets held within their organizations, and in making recommendations related to IT security. The objective of a threat and risk assessment (TRA) is to involve the various players and gain their support, to enable management to make informed decisions about security and to recommend appropriate and cost-effective safeguards. An assessment of the adequacy of existing safeguards also forms part of the TRA process. Where this assessment indicates that safeguards are inadequate to offset vulnerabilities, additional safeguards are recommended. Also, where the TRA indicates that certain safeguards are no longer needed, the elimination of those safeguards is recommended. A TRA does not result in the selection of mechanisms of prevention, detection and response to reduce risks; instead, it simply indicates the areas where these mechanisms should be applied, and the priorities, which should be assigned to the development of such mechanisms. Within the context of risk management, the TRA will recommend how to minimize, avoid, and accept risk.

Planning for the TRA process encompasses establishing the scope of the project, determining the appropriate methodology, setting the time frame, identifying the key players and allocating resources to perform the assessment. Those involved in the TRA process must be cautioned to protect the sensitivity of working papers produced during the process. These working papers often contain information related to the vulnerability of systems and environments, and should be protected at a level commensurate with the most sensitive information available on those systems.

Consideration must be given to specific organizational characteristics that might indicate the need for a strengthened security profile. Such characteristics might include the organization's mandate, the location (i.e. remoteness) and the organization's composition in terms of environment ("hostile", public access) and resources.

4.2.2 Process

To conduct a TRA, the following four-step process is typically followed.
 

1. Preparation:	determining what to protect;
2. Threat Assessment:	determining what to protect against, consequences of a threat;
3. Risk Assessment:	determining whether existing or proposed safeguards are satisfactory; and
4. Recommendations:	identifying what should be done to reduce the risk to a level acceptable to senior management.

Each of these steps is described in detail in subsequent sections.

4.2.2.0 Preparation

Defining the Environment

1. Determining the Scope of the Threat and Risk Assessment


Prior to the actual conduct of the TRA, it is necessary to establish its scope, which will include the systems under consideration, the interconnectivity with other systems and the profile of the user community. The entire TRA process will often span a number of systems and environments. Thus, in determining the scope, care must be taken to ensure that priorities are set to determine an appropriate order of assessment, i.e. that areas of primary concern or sensitivity are assessed first.

2. Identifying Team Participants


Once the scope of the TRA has been established, the practitioner can establish a representative team of users of the system under consideration. For example, let us suppose that the system contains several applications used by a variety of groups within the institution. To provide a valid cross section of the information required to conduct the TRA, users, developers, and telecommunications and operations staff must be selected for the team. This team will (at a later step) provide the practitioner with the information required to identify known threats and their potential impact.

3. Determining Intrinsic Concerns


All organizations have certain security concerns that are directly related to the nature of their business. The practitioner should document these special concerns, as they will be instrumental in determining the appropriateness of existing security measures and in making recommendations for improvements.

4. Developing the Baseline

• The baseline provides a starting point for any measurement of progress.
• The environment is subject to continual change.

The practitioner must consider several aspects contributing to the worth of an asset including, but not limited to, the initial cost of the item. An asset may have an acquired value that far outweighs the initial cash outlay. Consider the example of the data collected by geologists during a summer survey of a remote northern area. The project objective may be to collect the data while the area is accessible and interpret and analyze the data over the winter months. The value could be considered to be equal to the cost of the survey in terms of scientists' time, support and travel costs. However, suppose the data is lost in September (therefore not available) and the area is inaccessible until spring. The geologists will have lost an entire year's work plus the cost of the initial survey in that the data must be gathered again the following summer. The asset value must be increased by the costs associated with an additional year's support, time and travel costs as well as any uniqueness in time, conditions and opportunity.

The question of using qualitative versus quantitative methods in the determination of asset value must also be addressed. When considering the acquired value of certain assets, it may be more meaningful (than assigning a dollar value) to establish the relative value of an asset within the context of the organizational objectives and mandate. This relative value can be expressed in terms of the confidentiality, integrity and availability requirements for that asset.

Confidentiality

Confidentiality is used in the context of sensitivity to disclosure. In some instances, the sensitivity involves a degree of time dependency. For example, some research is sensitive as data is being gathered and processed; but once published it becomes a matter of public record and therefore no longer possesses the same degree of confidentiality. In some instances, data may acquire a higher level of confidentiality when put together in an aggregate form; e.g. army movement logistics may be derived from an aggregate of supply data to individual units.

To assess the impact of loss of confidentiality, practitioners must relate the level of sensitivity of the data to the consequences of its untimely release. The data must be appropriately classified or designated according to the following levels:
 
 
 

UNCLASSIFIED OR UNDESIGNATED	basic information
DESIGNATED	varying levels, personal information, sensitive business information
CONFIDENTIAL	compromise could cause injury to the national interest
SECRET	compromise could cause serious injury to the national interest
TOP SECRET	compromise could cause exceptionally grave injury to the national interest

The confidentiality considerations checklist (Table 1) stipulates some questions to be answered in the assessment of the confidentiality requirements of the system or of the information it contains.

Integrity is used in the context of accuracy and completeness of the information accessible on the system and of the system itself. Where integrity requirements are high, as is the case with financial transactions in banking systems, the potential financial losses will indicate the appropriate levels of investment in safeguards.

The integrity considerations checklist (Table 2) stipulates some aspects to be addressed in the assessment of the integrity requirements of the system or of the information it contains.

The system, to be considered available, must be in place and useable for the intended purpose. While the complete loss of data processing capability is unlikely, it could occur. Unscheduled downtimes of varying degrees of severity are certain. The practitioner must assist the users in establishing how much they rely on the system's being available to provide the expected service. The users must clearly define for the systems staff the maximum acceptable levels of downtime. In this context, the term "availability" relates to continuity of service.

To the practitioner, establishing processing priority based on availability requirements often involves mediating between user groups and reaching agreement on the relative importance of applications to each group. The practitioner must also recognize that availability requirements often change during the lifespan of the application. The user community should document for the systems staff the impact of the loss of availability of the IT systems, support personnel and data.

Those services that are considered to be essential or mission-critical services must be identified. Such services have a high availability requirement and, as a result, special consideration must be given to the support resources and environmental aspects, which affect the provision of service.

The practitioner must determine all critical components involved in the provision of essential service that could be vulnerable to threats. These critical components are also considered to be "assets" for the purposes of the TRA.

The availability considerations checklist (Table 3) stipulates some aspects, which should be addressed in the assessment of the availability requirements.

The user representation for completing the statement of sensitivity could be one person or several, depending on the size and complexity of the application being assessed.

A separate statement of sensitivity is required for each major application used on the computer system or anticipated for installation. For example, payroll and inventory would each require a statement of sensitivity, even if they are to be run on the same system. The sensitivity-related valuation of assets is not necessarily linked to numerical values associated with initial or replacement costs; but rather is linked to a relative value associated with the application's requirements for confidentiality, integrity and availability.

4.2.2.1 Threat Assessment

The second step of the TRA process is the Threat Assessment. The threat concepts of class, likelihood, consequence, impact and exposure are highlighted. Specific threat events such as earthquakes, hacker attempts, virus attacks etc. fall into a particular threat class, depending on the nature of the compromise. Examples of threats within each class can be found in Figure 3.
 
 
 

THREAT CLASS	SAMPLE THREATS
DISCLOSURE	Compromising Emanations  Interception  Improper Maintenance Procedures  Hackers
INTERRUPTION	Earthquake  Fire  Flood  Malicious Code  Power Failure
MODIFICATION	Data Entry Errors  Hackers  Malicious Code
DESTRUCTION	Earthquake  Fire  Flood  Power Spikes
REMOVAL	Theft of Data  Theft of Systems

FIGURE 3 - Sample Threats

Description of Threat

The threats that may target the assets under consideration must be described by the practitioner. These threats may originate from either deliberate or accidental events.

Classes of Threats

The practitioner will classify the threats into one of the five main classes of threats: disclosure, interruption, modification, destruction and removal or loss.

Disclosure

Assets that have a high confidentiality requirement are sensitive to disclosure. This class of threats compromises sensitive assets through unauthorized disclosure of the sensitive information.

Interruption

Interruption relates primarily to service assets. Interruption impacts the availability of the asset or service. A power outage is an example of a threat, which falls into the interruption class.
 
 

Modification

The primary impact of this class of threats is on the integrity requirement. Recall that integrity, as defined in the GSP, includes both accuracy and completeness of the information. A hacker attempt would fall into this class of threat if changes were made.

Destruction

A threat, which destroys the asset, falls into the destruction class. Assets that have a high availability requirement are particularly sensitive to destruction. Threats such as earthquake, flood, fire and vandalism are within the destruction class.

Removal or Loss

When an asset is subject to theft or has been misplaced or lost, the impact is primarily on the confidentiality and availability of the asset. Portable computers or laptops are particularly vulnerable to the threat of removal or loss.

Likelihood levels of low, medium and high are used according to the following definitions (Source: Government of Canada Security Policy):

• Not Applicable may be used to indicate that a threat is considered not to be relevant to the situation under review.
• Low means there is no history and the threat is considered unlikely to occur.
• Medium means there is some history and an assessment that the threat may occur.
• High means there is a significant history and an assessment that the threat is quite likely to occur.

Once the assets are listed and the threats are categorized according to the five major classes, the practitioner must assess the impact of a threat occurring in the absence of any safeguards. In order to assess the impact, the practitioner must be able to understand and describe the business of the organization. The practitioner must consider what the effect would be on the work being done, on the organization itself, and on those elements of the business that rely on the information or service provided by the specific asset under threat.

During this process, the practitioner seeks to answer the question "What is the consequence of each particular threat?" This consequence is related to the losses or other consequences (both real and perceived) which could result from a specific threat being successful.

The Government of Canada Security policy identifies an impact- reporting mechanism based on an injury assessment. In the case of classified or designated assets or information, group impact into levels of less serious injury, serious injury and exceptionally grave injury. Consequences could be expressed in such terms as "loss of trust", "loss of privacy", "loss of asset" or "loss of service". The practitioner could add other similarly phrased consequences as needed.

The mapping of the consequence onto one of the three impact ratings (exceptionally grave, serious, less serious) would vary according to departmental priorities. For example, in one department a loss of trust might be regarded as serious injury in terms of impact, while in another department, the same loss of trust might be considered to be exceptionally grave injury. The impact assessment allows the practitioner to determine the impact to the organization in terms of the real and perceived costs associated with the loss of confidentiality, integrity, and availability.

The identification of exposure allows the organization to rank the risk scenario according to the likelihood and impact, and thus assign a priority.

This general exposure rating for data and assets is outlined in Table 4 where impact takes precedence over likelihood. This table provides a means of prioritizing the impact through a rating that considers only the likelihood of a particular threat and the associated impact on the organization should the threat materialize. Table 4 does not consider the safeguards employed to counterbalance a particular threat.
 

		IMPACT (INJURY)
		Exceptionally Grave	Serious	Less Serious
Likeli-hood		9	8	5
	MEDIUM	7	6	3
	LOW	4	2	1

TABLE 4 - Exposure Ratings for Data and Assets

Summarizing Threat Assessment

1. Describing threats in terms of who, how and when.
2. Establishing into which threat class a threat falls.
3. Determining the threat likelihood.
4. Determining the consequences on the business operations should a threat be successful.
5. Assessing the impact of the consequences as less serious, serious or exceptionally grave injury.
6. Assigning an exposure rating to each threat, in terms of the relative severity to the organization.
7. Prioritising the impacts/likelihood pairs, according to the ratings determined in (f).

TABLE 5 - Generic Threat Assessment

4.2.2.2 Risk Assessment

Risk assessment is necessary to determine risk assumed by the organization where existing or proposed safeguards are deemed inadequate to protect the asset against an identified threat. Where existing safeguards are not adequate, a vulnerability is noted and analyzed.

Risk assessment is "an evaluation of the chance of vulnerabilities being exploited, based on the effectiveness of existing or proposed security safeguards".

This definition leads the risk assessment process into an evaluation of the vulnerabilities and the likelihood that a vulnerability would be exploited by a threat in the presence of either existing or proposed security measures.

Evaluating Existing Safeguards

Determining what existing safeguards could counter the identified threats is the next logical step in the process of TRA. Once the existing safeguards are grouped on a per-threat basis, the practitioner can assess the security posture of the business or facility relative to each threat, and determine whether any residual vulnerability or weakness exists.

Vulnerabilities

Attention should be paid to times during which the asset is most vulnerable, for example, during periods of public access and unrestricted access or while in transit. In some instances, an asset has an associated time sensitivity. For example, the information may be sensitive while under review or development (e.g. budget) and then may lose its sensitivity upon release to the public.

There are three possible security posture scenarios in the threat and safeguards environment. The first is identified in Figure 2 as an equilibrium state. This state of equilibrium is the most desirable security posture. In this environment, threats are identified and appropriate safeguards are in place to reduce the associated risks to a level, which is acceptable to the organization's senior management.

The second security posture, which an organization might experience, is referred to as a vulnerable state (Figure 3), since the threats outweigh the safeguards. The insecurity produced can result in a variety of IT - related losses, which compromise the confidentiality, integrity and availability of the information.

The third security posture is referred to as an excessive state (Figure 4) since the safeguards employed exceed the threats. The result is an overspending in the area of security measures, which is not commensurate with the threat; and thus is not justifiable.

When it is determined that the security posture matches Figure 3 - Vulnerable, the practitioner must consider the possibility that a vulnerability would be exploited. This depends on a number of factors, some of which were explored in the Threat Assessment:

• likelihood of threat,
• possible motive for exploiting the vulnerability,
• value of the asset to the organization and to the threat agent, and
• effort required to exploit the vulnerability.

Risk

Risk is defined as, "the chance of vulnerabilities being exploited".

The level of risk existing in the organization can be categorized as:

• high: requiring immediate attention and safeguard implementation,
• medium: requiring attention and safeguard implementation in the near future, or
• low: requiring some attention and consideration for safeguard implementation as good business practice.

Summarizing Risk Assessment

Risk Assessment as described in this section encompasses:

• examining existing safeguards,
• establishing vulnerabilities, and
• determining the level of risk based on a number of factors.

TABLE 6 - Generic Risk Assessment

4.2.2.3 Recommendations

The closing phase of the TRA process includes the proposal of recommendations. These recommendations are intended to improve the security posture of the organization through risk reduction, provide considerations for business recovery activities should a threat cause damage, and identify implementation constraints. Once safeguards that would augment the existing safeguards and improve the security profile are proposed, the risk posture can be re-evaluated as low, medium or high.

Proposed Safeguards

At this point in the process, the practitioner has analyzed the nature of the threats, the impact of successful threats, and the organization's vulnerability to these threats and has subsequently judged the risk to be low, medium, or high. Where the practitioner perceives that the risk can be reduced, appropriate recommendations are made. The practitioner may recommend a number of scenarios, each with an associated effect and cost, from which senior management will make an appropriate selection.

Where the assessment of threats and associated risks leads to specific recommendations, the practitioner must also consider the feasibility of such recommendations.

Projected Risk

In some instances, proposed safeguards will reduce or eliminate some, but not all, risks. For such instances, the resulting projected risk should be documented and signed off by senior management. For example, the initial risk assessment indicated a high risk situation, and several safeguards were recommended by the TRA team. In the presence of these additional safeguards, the risk is re-evaluated as being moderate to low. Thus the priority level of this scenario is reduced but not eliminated, and senior management should acknowledge and accept or reject the projected risk levels. Rejecting the risk implies that other safeguards must be sought to further reduce or eliminate the risk.

Ranking of the implemented safeguards can be accomplished in a number of ways, for example:

• Refer to the impact-rating column of the threat assessment phase
• Compare the change in risk level before a proposed safeguard is implemented, in the risk assessment phase risk column to after, in the recommendations phase risk column.

Overall Assessment of Safeguards

Safeguards and associated risk should be evaluated based on the following categories:

• completely satisfactory;
• satisfactory in most aspects;
• needs improvement.

The practitioner establishes the appropriateness and interdependencies of safeguards, and answers such questions as: Are safeguards in conflict? Does one safeguard offset the usefulness of another? Does the safeguard overcompensate the threat? What threats have not been fully compensated for? What is the risk that vulnerabilities which are not fully compensated for are likely to be exploited and by whom?

4.2.3 Updates

The TRA is considered to be a vital, living document, which is essential to meeting the security objectives of the organization. The TRA must be updated at least annually, or whenever an occurrence reveals a deficiency in the existing assessment. The TRA should also be updated whenever changes are planned to the systems or environments in which the IT processing occurs, which could create new risks or redundant safeguards.

Regular Review

Regular reviews allow the practitioner to revisit the TRA document and assess whether the IT security requirements within the organization have changed. These regular reviews are necessary in light of both the dynamics of the technologies in place to support IT and the dynamics of technologies available to threat agents to help them attack the IT systems of the organization.

Systems Changes

Changes to systems can greatly impact the security profile; therefore, every change must be assessed. The TRA document provides the practitioner with a baseline against which the effects of these changes can be measured. Examples of changes include the move of an organization from stand-alone PCs to a Local Area Network environment, the introduction of new applications to existing systems, the introduction of Wide Area Network capability to existing IT environments, a change in communications links or protocols used to move information between departmental units, or a change in the level of the most sensitive information on the system.

Threat Profile Changes

Changes in the threat profile will also have a potential impact on the TRA. For example, when threat agent motivation diminishes or the effort expended by the threat agent increases, the threat from that source may be reduced. Since changes in the threat profile do not always follow a cyclical pattern, the practitioner must stay in touch with the current threat levels and update the TRA accordingly.

4.2.4 Advice and Guidance

Threats

Sources of historical threat information vary, depending on the type of information sought. For threat information based on events that have already occurred within the organization, the practitioner should consult the Departmental Security Officer. For threat information related to investigations under the Criminal Code of Canada involving IT assets, the practitioner should consult the OIC, Information Technology (IT) Security Branch of the RCMP. Where threat information relates to COMSEC, the practitioner should consult the Communications Security Establishment. The Canadian Security Intelligence Service (CSIS) provides threat information and advice on threat assessment when requested.

TRA Process

Advice and guidance on the TRA process as described in this document are available through the OIC,IT Security Branch of the RCMP.
 
 

4.2.5 Glossary of Terms

1. Analyse: to study or determine the nature and relationship of the parts.
2. Assess: to evaluate the extent to which certain factors (Threats, Vulnerabilities and Risks) affect the IT environment.
3. Asset: any item that has value.
4. Availability: the condition of being usable on demand to support business functions.
5. Compromise: unauthorized disclosure, destruction, removal, modification or interruption.
6. Confidentiality: the sensitivity of information or assets to unauthorized disclosure, recorded as classification or designation, each of which implies a degree of injury should unauthorized disclosure occur.
7. Consequence: outcome, effect.
8. Critical: crucial, decisive.
9. Equilibrium: a state of balance existing between two or more opposing forces.
10. Evaluate: to determine the amount or worth of, or to appraise.
11. Exposure: the state of being vulnerable to criticism or attack.
12. Impact: effect of one thing on another.
13. Information technology: The scientific, technological and engineering disciplines and the management technologies used in information handling, communication and processing; the fields of electronic data processing, telecommunications, networks, and their convergence in systems; applications and associated software and equipment together with their interaction with humans and machines.
14. Intangible: incapable of being perceived by touch.
15. Integrity: the accuracy and completeness of information and assets and the authenticity of transactions.
16. Likelihood: the state or quality of being probable, probability.
17. Practitioner: one who practises within an area of expertise.
18. Process: a series of continuous actions to bring about a result.
19. Qualitative: of or pertaining to quality, describable.
20. Quantitative: of or pertaining to quantity, measurable.
21. Risk assessment: an evaluation of the chance of vulnerabilities being exploited, based on the effectiveness of existing or proposed safeguards.
22. Safeguards: actions or measures taken to offset a particular security concern or threat.
23. Security baseline: an established security profile or posture, which has been determined at an established point in time.
24. Tangible: perceptible by touch.
25. Threat assessment: an evaluation of the nature, likelihood and consequence of acts or events that could place sensitive information and assets as risk.
26. Threat: any potential event or act that could cause one or more of the following to occur: unauthorized disclosure, destruction, removal, modification or interruption of sensitive information, assets or services, or injury to people. A threat may be deliberate or accidental.

4.1 Guideline for the Analysis Local Area Network Security., Federal Information Processing Standards Publication 191, November 1994. Chapter 3.4.