Information Resource Guide |
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
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.
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.
Defining the Environment
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.
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.
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.
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.
CONFIDENTIALITY
CONSIDERATIONS
CHECKLIST |
|
Is the information sensitive in the national interest, i.e. classified? | |
Is the information personal? | |
What is the consequence of loss of confidentiality of this information? |
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.
INTEGRITY
CONSIDERATIONS
CHECKLIST |
|
Impact of inaccurate data. | |
Impact of incomplete data. |
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.
AVAILABILITY CONSIDERATIONS CHECKLIST | |
Changes in availability requirements within the system's life cycle | |
Documented impact of loss of availability | |
Documented maximum acceptable periods of downtime |
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.
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 |
|
INTERRUPTION |
|
MODIFICATION |
|
DESTRUCTION |
|
REMOVAL |
|
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):
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.
|
||||
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TABLE 4 - Exposure Ratings for Data and Assets
Summarizing Threat Assessment
ASSET | THREAT ASSESSMENT | |||||
AGENT/
EVENT |
CLASS
OF
THREAT |
LIKELIHOOD OF OCCURRENCE | CONSEQUENCE OF OCCURRENCE | IMPACT
(INJURY) |
EXPOSURE
RATING |
|
Describe the Asset. | Describe the threat event. | Disclosure
Interruption Modification Destruction Removal |
Low
Medium High |
List the consequences to the organization of the threat occurring. | Exceptionally grave, serious, less serious. | Numerical Value
1 to 9 |
TABLE 5 - Generic Threat 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:
Risk
Risk is defined as, "the chance of vulnerabilities being exploited".
The level of risk existing in the organization can be categorized as:
Summarizing Risk Assessment
Risk Assessment as described in this section encompasses:
ASSET | THREAT | Risk Assessment | ||
Existing Safeguards |
Vulnerability | RISK | ||
Describe the Asset | Describe the specific threat against it | Describe existing safeguards to protect the asset against the threat | Describe any vulnerabilities that may be observed | Establish risk level |
TABLE 6 - Generic Risk Assessment
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:
Overall Assessment of Safeguards
Safeguards and associated risk should be evaluated based on the following categories:
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?
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.
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.1 Guideline for the Analysis Local Area Network Security., Federal Information Processing Standards Publication 191, November 1994. Chapter 3.4.
Area Networks, Architectures and Implementations, Prentice Hall,
1989.
[BARK89] Barkley, John F., and K. Olsen; Introduction to Heterogenous
Computing Environments, NIST Special Publication 500-176,
November, 1989.
[NCSC87] A Guide to Understanding Discretionary Access Control in Trusted
Systems, NCSC-TG-003, Version 1, September 30, 1987
[NCSL90] National Computer Systems Laboratory (NCSL) Bulletin, Data
Encryption Standard, June, 1990.
[SMID88] Smid, Miles, E. Barker, D. Balenson, and M. Haykin; Message
Authentication Code (MAC) Validation System: Requirements and
Procedures, NIST Special Publication 500-156, May, 1988.
[OLDE92] Oldehoeft, Arthur E.; Foundations of a Security Policy for Use of
the National Research and Educational Network, NIST Interagency
Report, NISTIR 4734, February 1992.
[COMM91] U.S. Department of Commerce Information Technology
Management Handbook, Attachment 13-D: Malicious Software
Policy and Guidelines, November 8, 1991.
[WACK89] Wack, John P., and L. Carnahan; Computer Viruses and Related
Threats: A Management Guide, NIST Special Publication 500-166,
August 1989.
[X9F292] Information Security Guideline for Financial Institutions, X9/TG-5,
Accredited Committee X9F2, March 1992.
[BJUL93] National Computer Systems Laboratory (NCSL) Bulletin, Connecting to the
Internet: Security Considerations, July 1993.
[BNOV91] National Computer Systems Laboratory (NCSL) Bulletin, Advanced
Authentication Technology, November 1991.
[KLEIN] Daniel V. Klein, "Foiling the Cracker: A Survey of, and Improvements to,
Password Security", Software Engineering Institute. (This work was sponsored in
part by the Department of Defense.)
[GILB89] Gilbert, Irene; Guide for Selecting Automated Risk Analysis Tools,
NIST Special Publication 500-174, October, 1989.
[KATZ92] Katzke, Stuart W. ,Phd., "A Framework for Computer Security Risk
Management", NIST, October, 1992.
[NCSC85] Department of Defense Password Management Guideline, National Computer Security Center, April, 1985.
[NIST85] Federal Information Processing Standard (FIPS PUB) 112, Password Usage, May,1985.
[ROBA91] Roback Edward, NIST Coordinator, Glossary of Computer Security Terminology,NISTIR 4659, September, 1991.
[TODD89] Todd, Mary Anne and Constance Guitian, Computer Security Training Guidelines,NIST Special Publication 500-172, November, 1989.
[STIE85] Steinauer, Dennis D.; Security of Personal Computer Systems: A
Management Guide, NBS Special Publication 500-120, January,
1985.
[WACK91] Wack, John P.; Establishing a Computer Security Incident
Response Capability (CSIRC), NIST Special Publication 800-3,
November, 1991.
[NIST74] Federal Information Processing Standard (FIPS PUB) 31,
Guidelines for Automatic Data Processing Physical Security and
Risk Management, June, 1974.