CS 564 Software Requirements Engineering – Lecture 11
Professor Larry Bernstein
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 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
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
and add them together.
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
―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
3. Inaccurate and Inadequate Metrics
4. Poor cost Estimates
5. Silver Bullet Syndrome
6. Creping Features
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.
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.1 Security Risk Assessment
1.2 IT Security Risk Control
1.3 Risk Management in Practice
2. Risk Assessment Methodologies
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.4 SSE-CMM, and ISO/IEC 21827
3.5 NIST Guidance Documents
4. Risk Models
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
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
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
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
revelation of name and address
； 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
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,
； 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
； 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
； 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.
； operational: secure network hardware from access to any but authorized network
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