 |
| Software Security: Building Security In |
By Gary McGraw
Published by AWP
Series: Addison-Wesley Software Security Series
ISBN: 0321356705
Published: 2/2/2006
Copyright 2006
Pages:448; Edition: 1
Click here for more info, or to buy the book!
The Software Security Library Boxed Set
By Gary McGraw/John Viega/ Greg Hoglund
Published by AWP
ISBN: 0321418700
Published: 2/10/2006
Copyright 2006; Pages: 1392;
Edition: 1
You can buy the box set here! |
|
|
|
|
In this excerpt from Chapter 5 of Software Security: Building Security In, author Gary McGraw reviews basic approaches to risk analysis and defines their shared concepts.
An in-depth analysis of all existing risk analysis approaches is beyond the
scope of this book; instead, I summarize basic approaches, common features,
strengths, weaknesses, and relative advantages and disadvantages.
As a corpus, "traditional" methodologies are varied and view risk from
different perspectives. Examples of basic approaches include the following:
Financial loss methodologies that seek to provide a loss figure to be
balanced against the cost of implementing various controls
Mathematically derived "risk ratings" that equate risk to arbitrary ratings
for threat, probability, and impact
Qualitative assessment techniques that base risk assessment on anecdotal
or knowledge-driven factors
Each basic approach has its merits, but even when approaches differ in
the details, almost all of them share some common concepts that are valuable
and should be considered in any risk analysis. These commonalities can
be captured in a set of basic definitions.
Asset: The object of protection efforts. This may be variously defined as
a system component, data, or even a complete system.
Risk: The probability that an asset will suffer an event of a given
negative impact. Various factors determine this calculation: the ease of
executing an attack, the motivation and resources of an attacker, the
existence of vulnerabilities in a system, and the cost or impact in a particular
business context. Risk = probability × impact.
Threat: The actor or agent who is the source of danger. Within information
security, this is invariably the danger posed by a malicious agent
(e.g., fraudster, attacker, malicious hacker) for a variety of motivations
(e.g., financial gain, prestige). Threats carry out attacks on the security
of the system (e.g., SQL injection, TCP/IP SYN attacks, buffer over-
flows, denial of service). Unfortunately, Microsoft has been misusing the
term threat as a substitute for risk. This has led to some confusion in the
commercial security space. (See the next box, On Threat Modeling versus
Risk Analysis: Microsoft Redefines Terms.)
Vulnerability: For a threat to be effective, it must act against a vulnerability
in the system. In general, a vulnerability is a defect or weakness in
system security procedures, design, implementation, or internal controls
that can be exercised and result in a security breach or a violation of
security policy. A vulnerability may exist in one or more of the components
making up a system. (Note that the components in question are
not necessarily involved with security functionality.) Vulnerability
data for a given software system are most often compiled from a combination
of OS-level and application-level vulnerability test results
(often automated by a "scanner," such as Nessus, Nikto, or Sanctum's
Appscan), code reviews, and higher-level architectural reviews. In software,
vulnerabilities stem from defects and come in two basic flavors:
flaws are design-level problems leading to security risk, and bugs are
implementation-level problems leading to security risk. Automated
source code analysis tools tend to focus on bugs. Human expertise is
required to uncover flaws.
|
| More information |
Download Chapter 5, "Architectural Risk Analysis," to learn how to reduce design flaws.
Visit our Resource Center for the latest news and expert advice on managing risk in the enterprise. |
|
|
|
|
Countermeasures or safeguards: The management, operational, and
technical controls prescribed for an information system which, taken
together, adequately protect the confidentiality, integrity, and availability
of the system and its information. For every risk, controls may be put
in place that either prevent or (at a minimum) detect the risk when it
triggers.
Impact: The impact on the organization using the software, were the
risk to be realized. This can be monetary or tied to reputation, or
may result from the breach of a law, regulation, or contract. Without
a quantification of impact, technical vulnerability is hard to deal
with -- especially when it comes to mitigation activities. (See the discussion
of the "techno-gibberish problem" in Chapter 2.)
Probability The likelihood that a given event will be triggered. This
quantity is often expressed as a percentile, though in most cases calculation
of probability is extremely rough. I like to use three simple buckets:
high (H), medium (M), and low (L). Geeks have an unnatural propensity
to use numbers even when they're not all that useful. Watch out for that
when it comes to probability and risk. Some organizations have five,
seven, or even ten risk categories (instead of three). Others use exact
thresholds (70%) and pretend-precision numbers, such as 68.5%, and
end up arguing about decimals. Simple categories and buckets seem to
work best, and they emerge from the soup of risks almost automatically
anyway.
Using these basic definitions, risk analysis approaches diverge on how to
arrive at particular values for these attributes. A number of methods calculate
a nominal value for an information asset and attempt to determine risk
as a function of loss and event probability. Some methods use checklists of
risk categories, threats, and attacks to ascertain risk.
Download the rest of Chapter 5 from Software Security: Building Security In
