Prelude

The information that follows describes a generic method for risk/threat assessments that has been adopted to enable individuals and organizations to perform their own threat/risk mitigation evaluations.

Introduction

The development of strategies to reduce the risk/threat of terrorism, or other threats, involves a process in which the cost to mitigate is measured against savings in risk reduction.

When we apply this process to the fight against terrorism, we must consider the proposed risk reduction measure's potential impact with respect to the rights of the people.  The basic building block of any group is the individual.  The rights that are accorded the least, affect the nature of the society that can be created.  Whenever we need to constrain the rights accorded to any individual, we not only affect the capacity of that individual, but also our own capacity.  The develop of an anti-terrorism policy that degrades any individual's rights, indirectly acts to limit our own capacity, can cause and create injustice, and can also serve to assist terrorists in achieving their goal.
 

Basic Premises
Mitigating risk/threat is an essential function carried out by all people.

Risk is the likelihood of a given threat attacking a particular vulnerability and the resulting impact.

The goal of risk management is to enable individuals and organizations to isolate separate risks and to identify potential mitigation options.

The process of identifying risks is an objective and subjective process, that also involves group discussions to determine risks based on potential threats, the consequences of those threats, and the techniques to mitigate them.

These discussions are directed towards the selection of security controls based on cost, threat, and the degree of risk reduction.

This knowledge is a means for individuals and organizations to make informed decisions, to justify expenditures, as part of a cost effective risk/threat management budget.

Risk Management

Risk management is part of the common sense that we employ on a daily basis.  Individuals and organizations balance the cost of a protective measure against risk that is mitigated.

Minimizing risk is the fundamental reason why individuals and organizations carry out security measures.  All security related activities are a part of risk management. Risk management decisions are involved in the entire life cycle..

The Risk Management Cycle has Five Phases.

Risk management is a process applied to a system.  We can think of a system as we would a life.

The first stage involves the recognition of the need for the creation of the system; and, determinations are made with respect to the purpose of the system.

The second stage involves the purchase or development of the system.

The third stage involves the installation and testing of the system.

The forth stage involves the operation of the system.  In this stage, the system does its work.

The final stage involves the decommissioning of the system

There are Six Key Roles

Senior Managers
The Senior Managers play the legislative role, for they are responsible for decisions with respect to spending levels.  They must see that system security costs merit the benefit and make decisions as to permissible levels of risk.

System Operators
The Operator of the System plays the executive role, for he or she is accountable for achieving the mission.   Because they are responsible for establishing for what makes an acceptable level of risk, it is critical that they understand risk management.

System Owner
The System Owner plays the judicial role, for the system owner is responsible for changes made to the system.  The system owner has to sign off on the work before fundamental changes can be made to the system. The system owner must therefore understand the role risk management plays in overall system effectiveness.

Senior Security Officers
Senior Security Officers  are responsible for the day to day security of the system. In this role, these individuals will select appropriate controls and discuss the capabilities of the controls. They also arrange training to familiarize personnel with security requirements and rules of behavior necessary to protect the system.

System Administrators
System Administrators need to adjust lifecycle activities as new components are added to a system, or the existing infrastructure is reconfigured for optimal performance. Changes to the system often impact security. System administrators need to be aware of how changes will affect the security of the organization.

End Users
The people / employees are the end users of the system. Their use of the system according to appropriate guidelines and rules of behavior is critical to protecting an organization’s mission.  It is essential that they understand the potential risks and their role in the risk management process.

Risk Assessment

Risk assessment is a process for individuals or organizations to use, in determine the level of acceptable risk.

The goal of this process is the determination of levels of risk, whether additional security controls should be implemented to further reduce risk, the appropriate level of residual risk and a whether this risk is at an acceptable level.

Risk is a function of the likelihood of a hazardous event times the impact of the event. To determine likelihood, threats to the system are analyzed in conjunction with the vulnerabilities present.

Vulnerability analysis involves an understanding of the nature of the system, and of the likelihood of threats/impacts.

Threats are examined on the basis of their likelihood.
Impacts are evaluated on the basis of their scope.

Threat analysis involves source identification, vulnerability analysis and control analysis.

These three processes represent independent areas for studies, however control analysis depends on the other two study areas for information.

Impact analysis, determines the scope of risk.

This process generates a result that can be explained by the formula:

All proposals to mitigate risk are evaluated by:

System Characterization

Each system can be characterized, and this characterization establishes the scope of the risk management effort.  Characterization provides essential information that enables us to define the risks.

Characterization is necessary so that everyone involved can understand the mission, how the system operates, and the nature of the potential impacts to the system.

Characterization involves a study of the boundaries of the system, where the boundaries of the system connect to other systems, the flows between these connections, and the resources and the people that constitutes the system.

Formally this includes the following information to be collected about each system.
this includes:

· The organization’s mission
· The processes performed by the system
· The functional requirements of the system
· Users of the system
· All applicable system security policies governing the system (agency policies, Federal,
State and local requirements, law)
· Security system
· The operating environment of the system
· The facilities where the system is contained
· The information requirements of the system
· The flows pertaining to the system.

The system description should also include any assumptions made, as well as, all sources of
information used to develop the description. Assumptions may be necessary, if the documentation is silent on a given topic, or if the discussion is incomplete. These might include assumptions about security provided by the underlying infrastructure or about future plans for the system.

Threat-source:
Either:

The intentional and methodological exploitation of a vulnerability or

The situation and method that may accidentally trigger a vulnerability.

Threat Analysis
Threat is expressed as a function of the likelihood that a given threat-source will successfully exploit a given vulnerability. A vulnerability is a weakness that can be accidentally triggered or intentionally exploited. Without a vulnerability that can be exercised, a threat-source does not present a risk. In determining likelihood, one must consider threat-sources, vulnerabilities, and existing controls.

Threat-Source Identification
The goal in this step is to identify and develop a list of potential threat-sources: natural, human, and environmental. A threat-source is defined as any circumstance or event with the potential to cause harm to a system.

In assessing threat-sources, it is important to ensure appropriate natural and environmental threats to the system are considered. Many times these can be overlooked and cause as much, or more, damage as manmade threats.  These threats are highly dependent on the location of the system.
Manmade threat-sources can either be intentional - a deliberate attack - or unintentional.

A deliberate attack can be either:

• A malicious attempt to gain unauthorized access to compromise system security or
• A benign, but nonetheless purposeful attempt to circumvent security.

Common Threat-Source

· Natural Threats—floods, earthquakes, tornadoes, landslides, avalanches, electrical storms, and other events.

· Human Threats—unintentional acts or deliberate actions

· Environmental Threats—long-term power failure, pollution, chemicals, liquid leakage. [In order for a human to be a valid threat-source, motivation and the resources to carry out the attack must be present.]

Known threats can be obtained from many government and private sector organizations.
Intrusion detection systems are becoming more prevalent and government and industry organizations continue collecting more data on security events, thereby improving ability to realistically assess threats. These sources include—

· Intelligence agencies
· Federal Computer Incident Response Center (FedCIRC)
· Mass media, particularly web-based resources
· Other sources

Vulnerability Analysis
The goal in this step is to develop a list of the system flaws or weaknesses that could be exercised by the potential threat-sources. This step systematically evaluates the technical and non-technical weaknesses associated with the system. This information is collected via site surveys, interviews with personnel responsible for the system, network-scanning tools, and available system and organizational documentation. Other industry sources (e.g., vendor Web pages) are helpful in identifying vulnerabilities that may be applicable to specific systems.  The specific types of vulnerabilities, and the methodology needed to determine whether they are present, will usually vary depending on the nature of the system and whether the system is in the design phase or has already been implemented.

If the system has not yet been designed, then the search for vulnerabilities focuses on security policies, procedures, and system requirement definitions. If the system is being implemented, the vulnerability identification would expand to include more specific information such as design documentation. If the system is operational, then the vulnerability identification methodology would include determining and analyzing whether the security features implemented or security controls used to mitigate the risk are applicable and effective.

Some proactive methods used to collect vulnerability information are—

· Automated vulnerability scanning
· Network mapping
· Security testing and evaluation
· Penetration testing.

· Previous risk assessment
· Audit reports, security review reports, and system test and evaluation reports
· Vulnerabilities lists
· Security advisories
· Vendor advisories
· System software security analyses
· System anomaly reports.

Typically, the system security requirements are presented in matrix form, where an explanation can be included that describes how the system’s design or implementation, does or does not satisfy the specific security control requirement. Security controls for the system can be extrapolated from the following sources:

· Security policies and guidelines
· System operating procedures
· System security specifications
· Industry standards and good practices

Technical Controls are those safeguards incorporated into the system.

• Typical technical controls are access control mechanisms, detection, identification, authorization, audit, and intrusion detection systems.

Operational Controls are those operational procedures and personnel and physical security measures established to provide an acceptable level of protection.

• Typical operation controls include background investigations, security awareness and training, disaster recovery, contingency, emergency plans, as well as reviews and audits.

Management Controls are those security measures that focus on the management of the system and the management of risk.

• Management controls are those security measures that focus on the management of the system and the management of risk. This includes assessments of security reviews, risk assessments, and rules of behavior.

A simple way to describe likelihood is that a vulnerability may be: high, moderate, or low.

High
The threat-source is highly motivated and sufficiently capable and countermeasures to prevent the vulnerability from being exercised are ineffective.

Moderate
The threat-source is motivated and sufficiently capable, but countermeasures are in place that will impede successful exercise of the vulnerability.
or
The threat-source lacks specific motivation to exercise this vulnerability or is only marginally capable of doing so.

Low
The threat-source lacks motivation or capability or controls are in place to prevent, or at least significantly impede, the vulnerability from being exercised.

Loss of Integrity. Integrity is lost if unauthorized changes are made to data or systems, whether these changes are intentional or accidental. Loss of systems or data integrity may cause impacts similar to those due to the loss of availability. Additionally, if the loss of systems or data integrity is not discovered, continued use of the corrupted system or data could cause future problems. Also, violation of integrity:

• may be a first step toward achieving a successful attack against availability or confidentiality and
• reduces the assurance of the system.

Loss of Confidentiality. Confidentiality refers to the protection both of the user and the system from unauthorized distribution. The impact of unauthorized distribution can range from  benign harm, through jeopardizing national security, to death.

Loss of Accountability. Accountability refers to the ability to trace the actions of an individual user. The accountability supports non-repudiation, deterrence, fault isolation, intrusion detection and prevention, and after action recovery and legal security.  Loss of accountability impacts the ability to perform these functions.  Reducing the system’s accountability is a frequent part of violating: integrity, confidentiality, and availability.

Loss of Assurance. Assurance is the grounds for confidence that the other four security goals (integrity, availability, confidentiality, and accountability) have been adequately met, by  implementation. Loss of assurance implies that there is not sufficient protection against unintentional user, the existence of adequate resistance to intentional penetration, or by-pass.  Disasters that result are grounds for the reduction confidence in the system.

Some impacts can be measured quantitatively in lost revenue, costs of repairing the systems, or costs in terms of levels of effort required to correct problems caused by a successful exploitation.

Other intangible impacts (e.g., loss in public confidence, credibility) cannot be measured in specific units, but can be qualified in terms of high, moderate, and low. Because of the generic nature of this discussion, this guide uses the qualitative categories – critical, high, moderate, and low.
 
 

Definitions
Critical Impact
Threat results in unavailability, modification, disclosure, or destruction of system assets or loss of system services that is unacceptable, resulting in disastrous national impact or likely deaths.

High Impact
These threats result in unavailability, modification, disclosure, or destruction of system assets or loss of system services, that is unacceptable, due to the resulting significant degradation of mission or possible injury to persons.

Moderate Impact
Threat results are discernible, but recoverable: unavailability, modification, disclosure, or destruction of system assets, or loss of system services; resulting in transitory, yet important mission impact but no injury to persons.

Low Impact
Threat results in unavailability, modification, disclosure, or destruction of system services that does not cause a significant mission impact nor injury to persons.
 
 

Consideration should be given to the advantages and disadvantages of a quantitative versus qualitative assessment. The advantage of the qualitative impact analysis is that it provides a relative prioritization of the risks and identifies immediate areas for improvement against the vulnerabilities. The disadvantage of the qualitative impact analysis is that it does not provide specific quantifiable measurements of the magnitudes of impact, therefore making the cost-benefit analysis of any recommended controls difficult at best.

On the other hand, the advantage of a quantitative impact analysis is that it provides a measurement of the magnitude that can be used in the cost-benefit analysis of recommended controls. The disadvantage is that depending on the units in which the measurement is expressed, the meaning of a quantitative impact analysis may be unclear, requiring that the result be interpreted in a qualitative manner. Additionally, if the quantitative values are the result of subjective judgments (frequently the case), then the use of quantitative methods may just hide the fact that the results are actually qualitative. Factors that assist in quantifying the magnitude of impact may include, but are not limited to—

· An estimation of the frequency of the threat-source exercising the vulnerability over a specified time period (e.g., 1 year)
· An approximate cost for each occurrence of the threat-source exercising the vulnerability.  A weighted factor based on a subjective analysis of the relative priority of a specific threat exploiting a specific vulnerability.

Assessment of Risk
In the initiation phase, a criticality assessment should be conducted.  In this step owners define how the system relates to mission accomplishment. In addition, potential threats and vulnerabilities can be identified. These activities will be useful in the next two phases, development and acquisition, and implementation.

In the development and acquisition phase, a risk assessment may be conducted to ensure that the overall system design and architecture, including controls, provides a security capability commensurate with the acceptable risk levels. As detailed in the process description above, the mission(s) that will be supported by the system, and how a security breach of the system might impact the mission(s) are important considerations. Addressing risk while the system is in the design phase allows performance and cost trades for the security features of the system to be made deliberately and with fewer constraints than is typical in subsequent phases.

In the implementation phase, a risk assessment is conducted when new controls or system components have been added.

For example, an analysis might be conducted after the addition of a remote access terminal. Performing a risk assessment then would allow administrators to determine how the support of external connections might impact the mission.

Finally, risk analyses are considered essential during the operations and maintenance phase - in anticipation of the occurrence of an event, or even after the occurrence of an event, to analyze vulnerabilities and recommend controls.

A risk assessment would be appropriate if, for example, a server inside the firewall boundary were to experience a penetration. The analysis would seek to retrace the events leading up to the penetration, to determine the penetration technique and its effects on the server. Once the vulnerabilities and threats have been identified, controls can be recommended to sufficiently reduce the risk in the future.
 
 

The goal is to protect a system with cost-effective and feasible security controls that are applicable to the system environment and supportive of mission accomplishment.

For each control that is proposed, the cost versus the benefit method should be taken into account. This section will identify the various points at which mitigation of risk can be performed. Afterwards, the necessity of conducting a cost-benefit analysis for each proposed control will be covered.

Risk Mitigation Approaches
To mitigate risk, organizations usually consider implementing a blend of the following three
approaches:

· Prevent: Eliminate the threat by removing the flaw or weakness or the ability to exercise it.
· Limit: Implement controls that constrain the impact of a threat without the need to take additional actions.
· Detect and Respond: Implementing measures to detect the exercise of a vulnerability and take action to mitigate adverse outcomes.

· Threats that would result in little impact to the mission should be a low priority to mitigate.
· Threats that result in the potential for significant mission impact should be given priority for mitigation.
· The devices and applications used to implement controls may be from many different sources.
· The "best of breed" approach brings together various components from different vendors, along with administrative measures, with the idea of each contributing in its own, specialized way.

Overview of Risk Mitigation
To mitigate risk we locate flaws and weaknesses.  Flaws and weaknesses are identified; and if they are exploitable, a determination is made. These determinations fix the systems vulnerabilities.

However, to be exploited, there must be an actor with the capacity and the intent to attack the systems vulnerabilities. In determining the likelihood of such an attack consideration must be given to the cost vs. the gain to the attacker.  If it is determined that the gains from the attack exceed their costs, a determination is made that the level of risk exceeds the loss anticipation threshold, and a decision is made that a unacceptable risk/threat exists:

• If a flaw exists, techniques are implemented to reduce the likelihood of the flaw.
• If a flaw is exploitable, apply layered protections, architectural designs, and administrative controls to prevent exploitability.
• If the attacker’s cost is less than the gain, apply protections to increase the attacker’s cost.
• If the risk of the loss too great, apply design principles, architectural designs, and administrative protections to limit the extent of the attack, thereby reducing loss.

Recognizing which risks each security control is targeting, and the degree of protection that can be reasonably expected, are essential to the cost-effective protection of the mission.

Technical Security Controls
Technical means of risk mitigation can be tailored to protect against given types of threats. These may range from simple to complex measures, and typically involve system architectures, engineering disciplines, and security packages involving a mix of hardware and software – all working together towards securing vital functions and critical data.

Technical controls can be grouped into one of the following three major categories, according to primary purpose:

Controls to Prevent. These controls focus on preventing a security breach from occurring
Controls to Support. These controls are generic and underlie most information technology security capabilities.
Controls to Detect and Recover. The controls in this category focus on the detection and recovery from a security breach.

Supporting Controls:
Supporting controls are, by their very nature, pervasive and interrelated with many other controls. The supporting controls are:

· Identification (and naming)  -- In order to implement many of the other controls, it is essential that both subjects and objects be identifiable. This control provides the capability to uniquely identify users, processes, and information resources.
· Key management -- Keys giving access must be securely managed.
· Security administration -- The security features of the system need to be administered in order to meet the needs of a specific installation and to account for changes in the operational environment:  This control provides this needed administration.
· System protections -- Underlying the various security functional capabilities is a base of confidence in the technical implementation. This represents the quality of the implementation from both the perspective of the design processes used and the manner in which the implementation was accomplished.Some examples of system protections are:

residual information protection (also known as object reuse), least privilege, process separation, modularity, layering, and minimization of what needs to be trusted.

Prevention Controls:
These controls can prevent the security breach from ever happening.

· Protected communications -- In a distributed system, the ability to accomplish security objectives is highly dependent on trustworthy communications. The protected communications control ensures the integrity, availability, and confidentiality of information. It is the rare situation where all three elements are not essential requirements, with confidentiality being needed at least for authentication information.
· Authentication -- It is often extremely important to ensure that a claimed identity is valid. The authentication control provides the means to verify the identity of a subject.
· Authorization -- The authorization control enables specification and subsequent management of the allowed actions for a given system.
· Access control enforcement -- When the subject requesting access has been validated for access to particular processes, it is still necessary to enforce the defined security policy. The access control enforcement control provides this enforcement, and frequently the enforcement mechanisms are distributed throughout the system. It is not only the correctness of the access control decision, but also the strength of the access control enforcement that determines the level of security obtained.
· Non-repudiation  -- System accountability depends upon the ability to ensure that senders cannot deny sending information and that receivers cannot deny receiving it. Non-repudiation is a control that spans prevention and detection. This control has been placed into the prevention category because the mechanisms implemented prevent the ability to successfully repudiate an action. As a result, this control is typically performed at the point of transmission or reception, rather than later.
· Transaction privacy -- Both government and private systems are increasingly required to maintain the privacy of individuals using these systems. The transaction privacy control protects against loss of privacy with respect to transactions being performed by an individual.

· Audit  -- The auditing of security relevant events is a key element for after-the-fact detection of and recovery from security breaches.
· Intrusion detection and containment -- It is essential to detect insecure situations in order to respond in a timely manner. Also, it is of little use to detect a security breach if no effective response can be initiated. The intrusion detection and containment control provides these two capabilities.
· Proof of Wholeness  -- In order to determine that integrity has been compromised, the ability must exist to detect when information or system state is potentially corrupted. The proof of wholeness control provides this ability.
· Restore ‘secure’ state  -- When a security breach occurs, the system must be able to return to a state that is known to be secure. That is the purpose for this service.

System Security Plan
There should be a System Security Plan for each general support system and major application. The plan should document system identification, system type, sensitivity levels and security controls.  Recommendations from the risk assessment performed as a part of this guide should be included in the system security plan.

Security procedures ensure that the processes vital to the successful fulfillment of organizational goals and missions are performed in line with a base set of requirements. This both provides for an environment that reduces the chance of a security breach and ensures that in the event of an incident, there will be a means to trace the chain of occurrences back to the origin of the problem for future reference.

An example of procedural controls is:

Procedures that regulate user access by defining levels of authorized access and associating each user with one or more of these levels. For example, regular users will typically be authorized significantly less access than supervisors or system administrators.  This procedural control is typically enforced by a combination of technical and non-technical mechanisms. The user’s level of access will also typically be documented in authorization memorandums used to verify their identity and the authenticity of their user profile.  (For systems relying on passwords for access control, procedures should be in place setting standards for password generation, control, and use.)

If standard procedures are commonly followed, it will be easier to retrace the events leading to a security incident and possibly even the source of the trouble. In addition, repeatable, procedural controls, boost efficiency and help achieve a controlled environment that is less susceptible to threats.

Security Education
One of the most effective measures to improve an organization’s information security posture is a security education, awareness, and training program. The level of training depends on the degree of responsibility and interaction the person has with the system. The more interaction the individual has, with the security-related issues, the more comprehensive is the training need.

Virus protection
Virus protection is important due to the ability of malicious code to cripple everyday operations. While virus-detection mechanisms are technical controls, the effectiveness of such mechanisms is largely determined by the related operational controls.

To be effective, virus detection software must be running on all machines and be applied to all the vectors for virus infection such as email, network downloads, and floppy disk transfers. It is important that upgrades of scanning software definition files be performs frequently, on all copies of the scanners to ensure that new viruses are detected.

External Storage
External storage media should be considered in the security procedures of any organization. It can be a source for unauthorized dissemination, if not physically protected, or properly disposed..  Also, careful records of storage requirements will aid in deterring theft and/or of illegal duplication.

System Maintenance
The maintenance of any system is vital to its successful operation. However, this process may subject system components to tampering, damage, or theft if not carried out according to specific guidelines. Thus, system maintenance must be scheduled and documented and the personnel who carry it out must be monitored. Additionally, change control and configuration management are essential.

Contingency Planning
A contingency plan allows organizations to fulfill mission objectives regardless of problems that may occur. Such plans provide for enhanced system resilience via means such as pre-planned rerouting of critical functions, alternate facilities for system operations, and personnel replacement.

Incident Response Plan
An incident response plan ensures that for a wide variety of potential security breaches, there is an applicable, known, and rehearsed procedure to follow in response to each type of breach.

Personnel Security Controls
Limiting personnel authorized to use a system is important. Background checks are one example of such controls and can be extremely helpful in determining if an individual might be a threat to the organization’s mission.

Physical Security Controls
Physical security controls are the third important category of controls that should be employed to mitigate risk to the system. They are the measures put in place to protect information and information systems from compromise, theft, or damage by any of the potential threats.

One type of physical controls is physical barriers such guards, fences, locks, and segmented
work areas. Another is the issuance and wearing of badges.

Physical controls such as protective equipment are especially important in mitigating against
non-manmade threats, such as fire, flood, earthquakes, etc. Examples of protective equipment that can be installed are voltage regulating transformers, uninterruptible power supplies, and on-site power generators.

Cost-Benefit Analysis.
It is not usually feasible to implement all possible controls. To determine which ones are required and appropriate for a specific organization, a cost-benefit analysis for each proposed control should be conducted. The cost-benefit analysis can be qualitative or quantitative. Its purpose is to demonstrate that the costs of implementing the controls can be justified by the reduction in the level of risk. In other words, the organization may not want to spend $10,000 to control to a $200 risk.

The first step in the cost-benefit analysis is to identify the benefits of the controls (increase in mission effectiveness) relative to the cost of implementation and operation of the control. Organizations can analyze the extent of reduction in the level of risk generated by the controls in terms of the two parameters that define the level of risk to the mission: likelihood and impact.

The impact parameter is mission-based and cannot usually be negotiated. However, if cost-effective controls do not exist, then risk mitigation is possible only by modifying the role the system plays in support of the mission. When cost-effective controls can be implemented their purpose is to reduce the likelihood of occurrence or the impact, should a security breach occur, or both. This is accomplished by achieving one or more of the following:

· Eliminate some of the flaws and weakness, therefore reducing the number of possible threat-source/vulnerability pairs
· Add a targeted control. For example, a vulnerability that requires physical access to the system remains uncorrected, but administrative controls are implemented to make physical access harder to achieve.
· Reduce the magnitude of the impact of successful exercise of a vulnerability by either limiting the extent of a vulnerability or modifying the nature of the relationship between the system and the organization’s mission.

For example, consider the need to enforce correct entry of security parameters. A technical control may be more complex and expensive than a procedural one, but is likely to be more effective since the enforcement is automated. On the other hand, a procedural control might be accomplished via a simple memorandum to all concerned individuals and an amendment to the security guidelines for the organization. However, trying to ensure that users consistently follow this memorandum is a much tougher task.

After identifying appropriate controls and determining their benefits, the organization will need to determine the associated costs. The costs of implementing controls may include, but are not limited to, the following:

· Capital costs
· Hardware and software purchases
· Reduced operational effectiveness, if system performance or functionality may be reduced for increased security
· Costs of implementing additional policies and procedures
· Costs of hiring additional personnel to implement proposed policies, procedures, or services.
· Training costs

Finally, the organization will then need to assess the benefits of the controls to the organization in terms of maintaining an acceptable mission posture. Just as there is a cost to implement a needed control, there is a cost for not implementing it. Relating the result of not implementing the control to the organizational mission serves to determine whether it is feasible to forego its implementation. As the amount of acceptable risk is a management decision, the mission process owner must determine what constitutes an acceptable level of mission risk. Once a range of operationally feasible risk levels are created, the control’s impact may then be assessed and either included or excluded, depending on the outcome. This range will vary from one organization to the next, but the calculation of the risk present based upon the controls employed will generally be made as follows:

· If control would reduce risk more than needed, then see if a less expensive alternative exists.
· If control would cost more than the risk reduction provided, then find something else.
· If control does not reduce risk enough, then look for more controls or a different control.
· If control provides enough risk reduction and is cost-effective, then use it.

It is important to note that the cost to implement a control is often more tangible than the cost of not implementing it. This makes the mission process owner even more critical in the decision whether to implement control measures. It is often only the process owner who can make a determination as to the relative measures of these two, often very different, ‘costs’.

Residual Risk
Few, if any, systems will ever be completely risk free; every system will have some degree of
residual risk. It is the process owner’s responsibility to make the final decision about the degree of risk they are willing to accept. This decision should be based on the cost-benefit analysis, as well as the risk assessment.

This process results in a formal approval for the system to become operational or, if it is already on line, to remain so.

Risk Mitigation Activities
Risk mitigation activities generally begin in development and acquisition, when technical, management, and operational security controls for the system are defined. As described above, the controls that are selected should address specific, identified vulnerabilities, or specific identified threat-sources, thereby reducing the overall threat faced by the system. In this phase technical controls are designed into the system. Industry and government alike agree that the beginning of the system life cycle is the best time to address security to ensure cost effective, interoperable solutions.

In the implementation phase, the controls are integrated into the existing system. In the operation and maintenance phase, the controls are put to the test, keeping unwanted and unauthorized incidents from occurring. New controls may be put into place during this phase in response to any number of changes - threats may increase, the criticality of the system to the organization may change, and new vulnerabilities might be discovered.

The Final Phase
In the final phase, disposal, the network components are destroyed according to commonly accepted practices, and degaussing and other measures used to keep sensitive residual data from falling into the wrong hands.

Evaluation And Assessment
The results of a risk assessment are only the beginning of an ongoing process aimed at reducing the possibility of, or degree to which, the mission operations will be adversely affected by a security event.  Most organizations will continually need to update its assessments as components are changed, and applications replaced.

In addition, personnel changes will occur and adherence to security policies is likely to change over time. The existence of these variables means that new risks will periodically surface and risks previously mitigated will again become a concern. Thus, the risk management process is ongoing and evolving. There should be a specific schedule, but the process should also be flexible enough to allow changes where warranted. As a rule of thumb, the analysis is usually repeated within 24 months or less. However, certain instances will require an immediate analysis. These include the installation of new equipment, or upgrading of software applications.  From time to time, new employees or the assignment of employees from within the organization to new roles will warrant examination as well.

Periodic reassessments are necessary to maintain an accurate picture of the system’s security posture. As these results are reported, changes in policy should be made to better address the weak points in the existing security program.

Document the Results
The results of a risk assessment need to be documenting in a report or briefing format. The results should be of sufficient detail to allow the organization’s management to make informed decisions on the appropriate actions to take in response to the identified risks to their mission. One must try to make comments as specific as possible, especially when recommending controls and remedies.

Also, diagrammatic explanations are useful in the implementation of the security controls for less familiar individuals. Above all, one must keep in mind the feasibility of recommendations given the resources available and the risks present.
 
 

Introduction
Begin with a brief description of the team and the analysis process. Reserve greater detail for scope statement below.

Purpose
To protect the accuracy, confidentiality and availability of data or functions and assure that safe and consistently correct procedures are being employed to conduct the work of the organization.

Scope
Describe the elements of the network, its architecture, the system components, users, field site locations (if any), and any other details about the system to be considered in the analysis. Use diagrams here, as they will assist others in understanding the scope of the project.

Risk Assessment Approach
Include in the description whether the organization's approach is to perform an analysis after an event has taken place or if the analysis is considering the likelihood of an event taking place in the future.

System Characterization
This is where system resources and information that constitute the system and its boundaries are identified in order to provide the foundation for the remaining steps in the risk assessment process. One must use the system characterization statement to give readers a detailed view of the hardware, software and setup examined. This section should describe the relationship between IT components and the organization’s mission processes.

Threat Statement
Identifies and explains the existing threats (threat-source/vulnerability pairs) to the system and outlines them specifically in terms of potential problems.

Findings
Each finding must include:

· A discussion of the threat-source and vulnerability pair
· Identification of existing mitigating security controls
· Impact analysis discussion
· Risk rating
· Recommended controls
· Appendices incl. System diagram, etc.

US Anti-terrorism Threat/Risk Policy
Mitigating Risk/Threat of Terrorism and Other Risks
The risk/threat of bioterrorism -- Small Pox as a Weapon of Mass Destruction
The Disaster Center

Christopher Effgen
host@disastercenter.com
January 21, 2002