DOC

# Risk Management for IT Security

By Alexander Sanchez,2014-02-25 20:44
6 views 0
Risk Management for IT Security

CS 564 Software Requirements Engineering Lecture 11

Professor Larry Bernstein

End Game:

November 30: Lecture 11

December 7: Lecture 12

December 14: Final Exam

Please study all handouts as they supplement the material in the

prerelease of the textbook I gave you.

Risk Analysis

Risk evaluation with discounted cash flow analysis

Condier this product with three phases: :

Phase 1: R&D, \$18M / year for 2 years, probability of success at the end : 60%

Phase 2: Market Development, \$10M / year for 2 years starting second year

Phase 3: Sales, 3 possible scenarios, starting year 4:

1. \$24M / year for 20 years (probability : .3)

2. \$12M / year for 10 years (probability : .5)

3. Abandon product (probability : .2)

Cash flow for this product :

Year 1 : -\$18M

Year 2 : -\$28M

Year 3 : .6 * -\$10M

Year 4-13 : (.6 * .3 * \$24M) + (.6 * .5 * \$12M) Year 14-23 : .6 * .3 * \$24M

To discount the cash flow, compute today‘s value of future moneys by using this formula

nNPV = CF / (1+IR)

NPV = Net Present Value

CF = Cash Flow

IR = Interest Rate (3% for example)

N = number of years

Example :

Year 2 : Cash flow is -\$28M, Discounted cash flow at 3% interest rate is : -\$26.39M

To get an idea of what the project is worth one should discount cash flows for each year

Rate of return = Net Profits / Net Costs (should be at least 10%)

How do we estimate future sales?

What products will take off ?

A blend of sales and R&D talent should be used :

R&D favors disruptive changes but may be too disruptive

Sales favors continuous improvement but may miss big new opportunities

Example :

―A tape recorder that does not record‖

What became known as ―walkman‖ has been at first snubbed by Sony‘s salespeople who did not see its potential, while R&D people were able to imagine new uses for the product and push to finally make it happen.

Other factors increasing risk

1. Excessive Schedule Pressure (65% of projects)

2. Management Malpractice

4. Poor cost Estimates

5. Silver Bullet Syndrome

6. Creping Features

7. Quality

8. Size

Risk Do’s and Don’t

Don‘t overestimate the risks : too much contingency planning

Don‘t underestimate the risks : leads to panic management later

Don‘t look for scapegoats

Do deal only with the top 10 priorities, as they get solved add to the list.

Quantitative Computation

P(E) = m/n

P = Probability

m = favorable events

n = total events

Risk = 1-P(E)

Risk Exposure = Risk * Costs

stThe Spiral Model requires a risk analysis after the prototype (1 cycle).

Risk Management for IT Security

Rick Kazman, Dan Port, Information Technology Management, University of Hawaii

David Klappholz, Computer Science, Stevens Institute of Technology

1. Introduction

1.1 Security Risk Assessment

1.2 IT Security Risk Control

1.3 Risk Management in Practice

2. Risk Assessment Methodologies

2.1 OCTAVE

2.2 SRMD

2.3 FRAP

2.4 Quantitative Versus Qualitative Approaches 3. Management of Information Security Standards

3.1 TCSEC, ITSEC, CTCPEC, Common Criteria, and ISO 15408

3.2 BS 7799, ISO 17799, and ISO TR 13335 (GMITS)

3.3 HIPAA

3.4 SSE-CMM, and ISO/IEC 21827

3.5 NIST Guidance Documents

4. Risk Models

4.1 Definitions

4.2 Strategic Risk Models

4.3 Strategic Risk Management Methods

4.4 The Need for Strategic Risk Management Methods 5. Practical Strategic Risk Models

5.1 Multi-technique Strategic Methods

5.2 Strategic Decision Making and Competing Risks

5.3 Risk of Delay

5.4 Balancing Competing Risks for Strategic Planning

5.5 Unsuitable Sweet Spots

6. Practical Risk Exposure Estimation

6.1 Qualitative Methods

6.2 Empirical approaches

6.3 Pitfalls to Avoid

7. Summary

Key words: risk, security risk, risk assessment, risk control, risk management, risk

exposure, strategic methods

Abstract: Dealing with risk is critical to the success of any engineering or business endeavor. Considering

the nature of IT and considering recent events, this is especially true in the case of risks to IT security. We

define the various notions associated with the assessment and management of risk in general and of IT

security risk in particular, and provide both concrete examples of IT security risks and categorizations of

well-known risks. We also review the various IT guidelines and standards that have IT security risk as major

components. Finally, we detail approaches to dealing with IT security risk, with an emphasis on strategic

approaches.

1. INTRODUCTION

According to [Carr93], risks must be managed, and risk management must be part of any mature organization‘s overall management practices and management structure. The

primary activities identified by [Carr93] for managing risk are:

Identify: risks must first be identified before they can be managed.

Analyze: risks must be analyzed so that management can make prudent decisions

Plan: for information about a risk to be turned into action, a detailed plan,

outlining both present and potential future actions, must be created. These actions

may mitigate the risk, avoid the risk, or even accept the risk.

Track: risks, whether they have been acted upon or not, must be tracked, so that

management can continue to exercise diligence.

Control: even if a risk has been identified and addressed, it must be continually

controlled, to monitor for any deviations.

The key activity tying all of these together is assessment. Assessment is considered

central to the risk management process, underlying all of the other activities.

For the purposes of exposition, we will follow the generic risk taxonomy shown in Figure 11 [Boehm91]. In this taxonomy the activity of risk management has two major sub-activities: risk assessment and risk control. Risk assessment is further divided into risk

identification, risk analysis, and risk prioritization. Risk control is divided into risk

management planning, risk resolution, and risk monitoring. While we will broadly

discuss several areas of risk management, our focus in this chapter is primarily on risk assessment, as it applies to IT security. Assessment is the starting point and forms the fundamental basis for all risk management activities. Many risk assessment methods and techniques have directly analogous application to risk control. In such cases we will note this is the case without elaboration.

The terminology used in the field of risk management varies somewhat among the different business and engineering areas in which it is used (e.g. see [Carr93, Hall98, Boehm91]). It even varies among writers in the field of IT security risk management. The generic risk management concepts that we have just introduced were created for software development (of which security is one attribute). The reader familiar with other works on IT security risk management should have little trouble seeing the direct

1 In Figure 1, for application to security the examples listed for Risk Analysis might include ―Security Models, Threat Analysis, and Vulnerability Factor Analysis.

applications. In this section we will define terms informally with examples; in later sections, we will formalize these definitions.

Although most people are unaware that they‘re doing it, we all engage in risk management on a daily basis. Consider, as an example, a decision, on the way out the door, on whether to stuff an umbrella into an uncomfortably heavy bag that will be taken 2on a thirty-minute train ride, followed by a ten-minute walk to the office. The decision

is based on a quick, often almost unconscious, assessment of the risks involved and a decision on how to control them.

*

Figure 1: Boehm’s Risk Management Taxonomy

On the one hand, there‘s the probability that the rain predicted by the TV forecaster will actually materialize, that it will be in progress during the drive to the train station and/or during the walk, and, if all goes as badly as it might, of the damage it would cause, from the point of view of both walking in drenched clothing and, possibly, losing work time during the drying-out period. Balanced against all of this, on the other hand, is the discomfort of carrying the extra weight, of the possibility of the precariously-situated umbrella‘s dropping out of the bag and, as it did last week, causing a spillage of hot

2 This example, as well as a number of others in this section, is taken, albeit with considerably more detail, from [NIST].

carry-out coffee during the effort to pick it up. An additional consideration is the probability that carrying the umbrella will solve the problem, a consideration that depends upon the expected strength of prevailing winds; if the wind proves to be too strong, the umbrella will provide no relief from the rain. An alternative possibility to consider, assuming it‘s an option, is to work at home all morning and to go to the office only after the rain, or its un-materialized threat, has abated.

1.1 Security Risk Assessment

In its typical definition, IT security involves protection of the confidentiality, integrity,

and availability of data/information critical to the success of a business or government organization. Naturally, it also involves protection, from injury and death, of the people involved in dealing with that information. The following are examples of consequences that can result from materialization of risks in the areas of confidentiality, integrity, and availability:

loss of confidentiality:

o personal embarrassment resulting from theft and publication of personal

financial, health, or other data, and possible prosecution and fine for

individuals and the organization responsible for maintaining

confidentiality

o corporate loss of earnings resulting from theft of pre-patent technical data

o loss of life of a covert intelligence agent resulting from theft and

loss of integrity:

o personal embarrassment and, possibly, fine and imprisonment resulting

from insertion into database of false financial data implicating the subject

in fraud or embezzlement

o loss of corporate auditors‘ ability to detect embezzlement, and attendant

loss of funds, resulting from deliberate corruption of financial data by

embezzler

o loss of life resulting from changes to database indicating that subject is a

covert agent when s/he isn‘t

loss of availability:

o personal embarrassment resulting from inability to keep appointments

resulting from temporary inability to use electronic calendar

o temporary inability of corporation to issue weekly pay checks to

employees, with attendant anger and loss of productivity, resulting from

temporary unavailability of hours-worked data

o loss of initiative, armaments, and lives resulting from battlefield

commander‘s inability to connect to field-support database

The terms threat, threat source, vulnerability, impact, and risk exposure are in common

use in the field of IT security risk assessment. Their application to the trip-to-work scenario is as follows:

the threat, or threat source, is the onset of rain, at a sufficiently strong level,

during an exposed part of the trip to work

the vulnerability is the fact that the person involved will get drenched if the threat

materializes and the person has no form of shelter (e.g. an umbrella)

the impact is the damage, measured in terms of discomfort and, possibly, of loss

of productivity or even health, that will occur if the threat materializes

the risk exposure is an assessment, on either a numerical, perhaps monetary, scale

or an ordinal scale e.g., low, medium, or high of the expected magnitude of

the loss given the threat, the vulnerability to it, and its impact, should it threat

materialize. In this example the risk exposure might change if the person is

wearing a water-resistant coat.

The first step in risk assessment is risk identification, i.e., identification of potential

threats, of vulnerabilities to those threats, and of impacts that would result should they materialize all of which we‘ve already done for the scenario under discussion.

In the trip-to-work scenario, we are concerned with such intangibles as the threat of rain, the vulnerability of getting drenched, and the impact of discomfort and with such tangibles as umbrellas. In the field of IT security, we are concerned with systems that store, process, and transmit data/information. Information systems are sometimes localized, and sometimes widely distributed; they involve computer hardware and software, as well as other physical and human assets. Tangibles include the various sorts

of equipment and media, and the sites in which they and staff are housed. Intangibles include such notions as organizational reputation, opportunity or loss of same, productivity or loss of same, etc.

Threat sources are of at least three varieties: natural, human, and environmental. Examples are:

natural: electrical storms, monsoons, hurricanes, tornadoes, floods, avalanches,

volcanic eruptions,

human: incorrect data entry (unintentional), forgetting to lock door (unintentional),

failure to unlock door to enable confederate to enter after hours (intentional),

denial of service attack (intentional), creation and propagation of viruses

(intentional),

environmental: failure of roof or wall due to use of bad construction materials,

seepage of toxic chemicals through ceiling, power outage.

Vulnerabilities have various sources, including technical failings such as those reported 3in the public and professional presses on a daily basis. Fred Cohen provides an excellent,

extensive taxonomy of threats and vulnerabilities in his Security Database [Cohen04].

3 A compilation of technical threats may be found at http//:icat.nist.gov or http://www.cert.org

One unique aspect of this database is that the threats (or causes) are cross-referenced against the attack mechanisms to provide a linkage between the cause and the mechanisms used. The attack mechanisms are also cross-referenced against the defence mechanisms to indicate which mechanisms might be effective in some circumstances against those attack mechanisms.

The second step in risk assessment is risk analysis, i.e., estimation and calculation of the

risk likelihoods (i.e. probabilities), magnitudes, impacts and dependencies. This is easy in the case of monetary impacts arising from threat-vulnerability pairs whose probability of materializing can reasonably be computed, but considerably harder in most other cases. Special care must be taken when assigning the likelihoods as the quality of the whole risk assessment is strongly dependent on the accuracy and realism of the assigned probabilities.

The final step in risk assessment is risk prioritization, that is prioritizing all risks with respect to the organization‘s relative exposures to them. It is typically necessary to utilize techniques that enable risk comparison such as calculating risk exposure in terms of

potential loss. In the trip-to-work scenario, risks other than the one discussed above might include the risks associated with not buckling the seat belt during the drive to the station, the risk of an accident during the drive, the risk of missing the train, etc. A meticulous person, one who always leaves the house earlier than necessary and who is very conscious of taking safety precautions will likely rate these new risks as having far lower exposures than the rain risk: a less meticulous person might do otherwise. In a highly-simplified version of a business situation, three threats might be volcanic eruption, late delivery of raw materials, and embezzlement. An organization located in Chicago would likely assign a lower priority to volcanic eruption than would one in south-western Washington; an organization whose suppliers have never before been late would likely assign a lower priority to late delivery than would an organization using a supplier for the first time. Be aware that there may be threats or vulnerabilities you may not have included in your analysis. For this reason, you should draw upon the experiences of others to help building a library of threats and vulnerabilities.

1.2 IT Security Risk Control

During the risk control phase of the risk management process, we are concerned with safeguards, also known as controls. Safeguards fit into at least three categories:

technical, management, and operational, with examples as follows:

technical: authentication (prevention), authorization (prevention), access control

(prevention), intrusion detection (detection), audit (detection), automatic backup

(recovery), etc.

management: assignment of guards to critical venues (prevention), institution of

user account initiation and termination procedures (prevention), institution of

need-to-know data access policy (prevention), institution of periodic risk re-

assessment policy (prevention), institution of organization-wide security training

(prevention and detection), etc.

administrators and/or service personnel (prevention), bolt desktop PC‘s to desks

(prevention), screen outsiders before permitting entry (prevention), set up and

monitor motion alarms, sensors, and closed circuit TV (detection of physical

threat), set up and monitor smoke detectors, gas detectors, fire alarms (detection

of environmental threats)

In the trip-to-work scenario, the safeguard that we have considered has a (fairly low-tech) technical component, i.e., the umbrella, and an operational component, i.e., carrying the umbrella. An alternative operational safeguard would be to work at home all morning, if that‘s an option, and to go to the office only after the rain, or the threat of rain, has abated.

During the risk control phase of the risk management process, we

consider alternative individual safeguards and/or complexes of safeguards that

might be used to eliminate/reduce/mitigate exposures to the various identified,

analyzed, and prioritized threats (risk management planning)

perform the cost-benefit analysis required to decide which specific safeguards to

employ and institute the relevant safeguards (risk resolution)

institute a process for the continuous monitoring of the IT security situation to

detect and resolve problems, as they arise, and to decide, where and when

necessary, to update or change the system of safeguards (risk monitoring) In business and government organizations, there may be many alternative possible safeguards, including different vendors‘ hardware and/or software solutions to a particular threat or cluster of threats, alternative management or procedural safeguards, and alternative combinations of technical, management, and procedural safeguards. Complicating matters is the likelihood that different combinations of safeguards address different, overlapping, clusters of threats.

Risk resolution begins with the cost-benefit analysis of the various possible safeguards and controls in lowering, to an acceptable level, the assessed risk exposures resulting from the various identified threats, vulnerabilities, and the attendant impacts. Just as we had to consider threats, vulnerabilities, and impacts during risk assessment, we must consider safeguards, their costs, and their efficacies during risk resolution. In the trip-to-work scenario, the marginal cost of the technical component of the umbrella-carrying safeguard is likely nil as most people already own umbrellas; the operational cost is the discomfort of carrying a heavier bag. Even in this simple example, the safeguard‘s

efficacy must be considered. For example, if the wind proves to be too strong, the umbrella will not effectively reduce the exposure.

1.3 Risk Management in Practice

The potential consequences of the materialization of a significant threat to a business or government organization, and the obvious fact that risk management can greatly reduce those consequences makes it eminently clear that no such organization can afford not to engage in a serious risk management effort. The smaller the organization and the simpler the threats, the less formal the organization‘s risk management effort need be. For the

small organization, e.g., a single retail store belonging to a family, very informal risk

management may suffice. In many situations legal statutes and acquisition policies give an organization no choice see Section 3 of this chapter. The Hawthorne Principle states that productivity increases as a result of simply paying attention to workers‘ environments. It is likely, by analogy, that a simple concern with risk management produces significant, though certainly not optimal, results.

On the other hand, it should also be clear that risk management is rarely easy. In the case of the rare threat-vulnerability pair whose probability can easily be assigned a numerical value, whose impact can be assigned a precise monetary value, and for which there exists a safeguard whose cost and efficacy can be pinned down numerically, there is no problem. In other cases, those in which one or more of the parameters can, at best be placed on an ordinal scale, matters are more complicated and approximate methods must be used. Consider, as examples the quantification of the impact of:

personal embarrassment resulting from: theft and publication of personal financial,

health, or other data; insertion into database of false financial data implicating the

subject in fraud or embezzlement; inability to keep appointments resulting from

temporary inability to use electronic calendar

corporate loss of earnings resulting from theft of pre-patent technical data

loss of corporate auditors‘ ability to detect embezzlement, and attendant loss of

funds, resulting from deliberate corruption of financial data by embezzler

temporary inability of corporation to issue weekly pay checks to employees, with

attendant anger and loss of productivity, resulting from temporary unavailability

of hours-worked data

loss of life: of covert intelligence agent resulting from theft and revelation of

name and address resulting from changes to database indicating that subject is a

covert agent when s/he isn‘t; resulting from battlefield commander‘s inability to

connect to field-support database.

To aid in the identification and management of risks, a number of risk management methods and risk taxonomies have been created. The SEI‘s risk taxonomy, for example,

divides risk into three classes: product engineering, development environment, and program constraints. The first level of decomposition of each of these classes is given in Figure 2.

A. Product Engineering B. Development Environment C. Program Constraints

Report this document

For any questions or suggestions please email
cust-service@docsford.com