Risk Analysis
in Software Design
Risk analysis is often viewed as a “black art”—part fortune telling, part mathematics. Successful risk analysis, however, is nothing more than a busi- ness-level decision-support tool: it’s a way of gath- ering the requisite data to make a good judgment call based on
resources, a system’s existing vul- nerabilities, and the cost or impact in a particular business context.
Copyright By PowCoder代写 加微信 powcoder
• The threat, or danger source, is in- variably the danger a malicious agent poses and that agent’s moti- vations (financial gain, prestige, and so on). Threats manifest themselves as direct attacks on system security.
• A vulnerability is a defect or weak- ness in system security procedure, design, implementation, or inter- nal control that an attacker can compromise. It can exist in one or more of the components making up a system, even if those compo- nents aren’t necessarily involved with security functionality. A given system’s vulnerability data are usu- ally compiled from a combination of OS- and application-level vul- nerability test results, code reviews, and higher-level architectural re- views. Software vulnerabilities come in two basic flavors: flaws (design-level problems) or bugs (implementation-level problems). Automated scanners tend to focus on bugs, since human expertise is required for uncovering flaws.
• Countermeasures or safeguards are the management, operational, and technical controls prescribed for an information system that, taken to- gether, adequately protect the sys- tem’s confidentiality, integrity, and availability as well as its informa- tion. For every risk, a designer can put controls in place that either prevent or (at a minimum) detect the risk when it triggers.
• The impact on the organization, were the risk to be realized, can be monetary or tied to reputation, or it might result in the breach of a law, regulation, or contract. With-
DENIS VERDON
Fidelity National Financial
GARY MCGRAW Cigital
knowledge about vulnerabilities, threats, impacts, and probability.
Established risk-analysis method- ologies possess distinct advantages and disadvantages, but almost all of them share some good principles as well as limitations when applied to modern software design. What sepa- rates a great software risk assessment from a merely mediocre one is its ability to apply classic risk definitions to software design and then generate accurate mitigation requirements. A high-level approach to iterative risk analysis should be deeply integrated throughout the software develop- ment life cycle.1 In case you’re keep- ing track, Figure 1 shows you where we are in our series of articles about software security’s place in the soft- ware development life cycle.
Traditional terminology
Example risk-analysis methodolo- gies for software usually fall into two basic categories: commercial (in- cluding Microsoft’s STRIDE, Sun’s ACSM/SAR, Insight’s CRAMM, and Cigital’s SQM) and standards- based (from the National Institute of Standards and Technology’s ASSET or the Software Engineering Insti- tute’s OCTAVE). An in-depth analysis of all existing methodologies is beyond our scope, but we’ll look at
basic approaches, common features, strengths, weaknesses, and relative advantages and disadvantages.
As a corpus, traditional method- ologies are varied and view risk from different perspectives. Examples of basic approaches include
• financial loss methodologies that seek to provide a loss figure to bal- ance against the cost of imple- menting various controls;
• mathematically derived “risk rat- ings” that equate risk with arbi- trary ratings for threat, probability, and impact; and
• qualitative assessment techniques that base risk assessment on anec- dotal or knowledge-driven factors.
Each basic approach has distinctly different merits, but they almost all share some valuable concepts that should be considered in any risk analysis. We can capture these com- monalities in a set of basic definitions:
• The asset, or object of the protec- tion efforts, can be a system com- ponent, data, or even a complete system.
• Risk, the probability that an asset will suffer an event of a given nega- tive impact, is determined from var- ious factors: the ease of executing an attack, the attacker’s motivation and
PUBLISHED BY THE IEEE COMPUTER SOCIETY s 1540-7993/04/$20.00 © 2004 IEEE s IEEE SECURITY & PRIVACY
Building Security In
Editor: Graw,
Security requirements
Abuse cases
Requirements and use cases
Risk analysis
External review
Risk-based security tests
Test plans
Static analysis (tools)
Penetration testing
Risk analysis
Test results
Security breaks
Field feedback
tography to an application server via native APIs without the aid of dedi- cated hardware acceleration might be cheap in the short term, for example, but if it results in a significant loss in transaction volume throughput, a bet- ter ROI might come from investing up front in crypto acceleration hard- ware. Interested organizations should adopt the risk-calculation methodol- ogy that best reflects their needs.
Common themes
Most risk-analysis process descrip- tions emphasize identification, rank- ing, and mitigation as continuous processes and not just a single step to be completed at one stage of the de- velopment life cycle. Risk-analysis results and risk categories tie in with both requirements (early in the life cycle) and testing (where developers can use results to define and plan par- ticular tests).
Because it’s a specialized subject, risk analysis is not always best per- formed solely by the design team. Rigorous risk analysis relies heavily on an understanding of business im- pacts, which requires an understand- ing of laws and regulations as well as the business model supported by the software. Developers and designers build up certain assumptions regard- ing their system and the risks it faces; at a minimum, risk and security spe- cialists should assist in challenging those assumptions against generally accepted best practice. They’re in a better position to assume nothing.
Putting the right people together for an analysis is important: consider the risk team very carefully. Knowl- edge and experience cannot be overemphasized because risk analysis is not a science, and broad knowl- edge of vulnerabilities, bugs, flaws, and threats is a critical success factor.
A prototypical analysis involves several major activities that often in- clude several basic substeps:
• Learn as much as possible about the analysis target. (Substeps include reading and understanding specifi-
Figure 1. The software development life cycle. Throughout this series, we’ll focus on specific parts of the cycle; here, we’re examining risk analysis.
out a quantification of impact, technical vulnerability is hard to handle—especially when it comes to mitigation activities.
• Probability is the likelihood that a given event will be triggered. It is often expressed as a percentile, al- though in most cases, probability calculation is extremely rough.
Although they start with these basic definitions, risk methodolo- gies usually diverge on how to arrive at specific values. Many methods calculate a nominal value for an in- formation asset, for example, and at- tempt to determine risk as a func- tion of loss and event probability. Others rely on checklists of threats and vulnerabilities to determine a basic risk measurement.
Example of
a risk calculation
One classic risk-analysis method ex- presses risk as a financial loss, or an- nualized loss expectancy, based on the following equation:
ALE = SLE × ARO,
where SLE is the single loss ex- pectancy and ARO is the annualized rate of occurrence (or the predicted frequency of a loss event happening).
Let’s consider an Internet-based equities trading application with a vulnerability that could result in unauthorized access (the implication being that unauthorized stock trades can be made). Assume a risk analysis
determines that middle- and back- office procedures will catch and negate any malicious transaction such that the loss associated with the event is simply the cost of backing out of the trade. We’ll assign a cost of $150 for any such event, so SLE = $150. With an ARO of just 100 such events per year, the cost to the com- pany (or ALE) will be $15,000.
The resulting dollar figure pro- vides no more than a rough yard- stick, albeit a useful one, for deter- mining whether to invest in fixing the vulnerability. Of course, for our fictional equities trading company, a $15,000 annual loss might not be worth getting out of bed for (typi- cally, a proprietary trading com- pany’s intraday market risk dwarfs such an annual loss figure).
Other methods take a more qual- itative route. In the case of a Web server providing a company’s face to the world, the Web site’s defacement might be difficult to quantify as a fi- nancial loss (although some studies indicate a link simply between secu- rity events and negative stock-price movements2). When “intangible as- sets” are involved (such as reputa- tion), qualitative risk assessment might be a more appropriate way to capture the loss.
Regardless of the technique used, most practitioners advocate a return- on-investment study to determine whether a given countermeasure is cost-effective for achieving the desired security goal. Adding applied cryp-
80 IEEE SECURITY & PRIVACY s JULY/AUGUST 2004
Building Security In
cations, architecture documents, and other design materials; dis- cussing and brainstorming with the group; determining system bound- ary and data sensitivity/criticality; playing with the software if it exists in an executable form; studying the code and other software artifacts; and identifying threats and agreeing on relevant sources of threat.)
• Discuss security issues surrounding the software. (Substeps include ar- guing about how the product works and determining areas of disagreement; identifying possible vulnerabilities, sometimes by using tools or lists of common vulnera- bilities; mapping out exploits and discussing possible fixes; and gain- ing an understanding of current and planned security controls.)
• Determine the probability of compromise. (Substeps include mapping out attack scenarios for vulnerability exploitation and bal- ancing controls against threat ca- pacity to determine likelihood.)
• Perform impact analysis. (Substeps include determining the impact on asset and business goals and consid- eringtheimpactonsecurity.)
• Rank risks.
• Develop a mitigation strategy. (A
substep is recommending counter-
measures to mitigate risks.)
• Report findings. (Substeps include carefully describing major and minor risks while paying close at- tention to impact, and providing basic information about where to spend limited mitigation resources.)
The sidebar on Cigital’s solution shows one commercial example that follows this basic approach.
Knowledge requirement
Design-level analysis is knowledge intensive. Microsoft’s STRIDE model, for example, involves the un- derstanding and application of sev- eral threat categories during analy-
sis.3 Similarly, Cigital’s SQM approach uses attack patterns4 and
exploit graphs to understand attack resistance, knowledge of design principles for ambiguity analysis,5 and knowledge regarding com- monly used frameworks (.NET and J2EE being two examples) and soft- ware components.
A central activity in design-level risk analysis is building up a consis- tent view of the target system at a rea- sonably high level. The idea is to see the forest, not get lost in the trees. The most appropriate level for this description is the typical whiteboard view of boxes and arrows describing the interaction of various critical de- sign components. The nature of soft- ware systems leads many developers and analysts to assume (incorrectly) that a code-level description of soft- ware is sufficient for spotting design problems. Although this might occa- sionally be true, it does not generally hold. Extreme programming’s claim that “the code is the design” repre- sents one radical end of this approach. Without a whiteboard level of de-
scription, an architectural risk analy- sis is likely to overlook important risks related to flaws.
Risk analysis
and requirements
Previous articles in this series con- sider security requirements defini- tions and discuss abuse cases as a method for generating require- ments. In the purest sense, risk analy- sis begins at this point: design re- quirements should take into account the risks you’re trying to counter. Let’s look at three approaches to in- terjecting a risk-based philosophy into the requirements phase (note that the requirements systems based on UML tend to focus more atten- tion on security functionality than they do on misuse and abuse cases):
• SecureUML (www.informatik. uni-freiburg.de/~tolo/pubs/ secuml_uml2002.pdf ) is a method- ology for modeling access-control policies and their integration into
Cigital’s approach
Figure A illustrates Cigital’s continuous risk-analysis process, which loops constantly and at many levels of description through several phases. In Cigital’s approach, business goals determine risks, risks drive methods, methods yield measurement, measurement drives decision
support, and decision support drives fix/rework and application quality.
1 Understand the business
Identify the business risks
Artifact analysis Artifact analysis
Business context
Technical Measure expertise and report
Identify the technical risks
Artifact analysis
4 Synthesize
and prioritize the risks
Define the
risk mitigation strategy
Validation loop
Validate the artifacts
the artifacts
Initiate process improvement
Figure A. Cigital’s risk-management framework. Many aspects of frameworks such as this can be automated—for example, risk storage, business risk to technical risk mapping, and the display of status over time.
www.computer.org/security/ s IEEE SECURITY & PRIVACY 81
Building Security In
model-driven software develop- ment. SecureUML is based on role- based access control and models security requirements for well- behaved applications in predictable environments.
• UMLsec (www4.in.tum.de/ ~umlsec/) is an extension to UML that enables the modeling of security-related features such as confidentiality and access control.
• and – dahl6 attempt to model abuse cases as a way of understanding how ap- plications might respond to threats in a less controllable environment; they describe functions that the system should not allow.
A key variable in the risk equa- tion is impact. Business impacts gen- erally boil down into three broad categories:
• federal or state laws and regulations (including the Gramm-Leach- Bliley Act, HIPAA, and the much- cited California Senate Bill 1386);
• financial or commercial considera- tions (such as revenue protection, control over high-value intellec- tual property, and preservation of brand and reputation); and
• contractual considerations (in- cluding service-level agreements and liability avoidance).
The first step to risk analysis at the re- quirements stage is to break down re- quirements into three simple cate- gories: must haves, important to haves, and nice but unnecessary. Unless you’re running an illegal operation, you should always class laws and regu- lations into the first category—these requirements should be instantly mandatory and not subject to further risk analysis (although an ROI study can help you select the most cost-ef- fective mitigations). If the law requires you to protect private information, for example, this requirement is compul- sory and should not be subject to a risk-based decision. Why? Because the government has the power to put
you out of business, which is the mother of all risks (if you want to test government regulators on this one, go right ahead).
You’re then left with risk im- pacts—the ones that have as variables potential impact and probability— that must be managed in other ways. Examples of mitigations range from technical protections and controls to business decisions for living with the risk. At the initial requirements defi- nition stage, you might be able to make some assumptions regarding which controls are necessary.
Evenly applying these simple ideas will put you ahead of most ap- plication developers. As you move toward the design and build stages, risk analysis should begin to test your first assumptions from the require- ments stage by testing the threats and vulnerabilities inherent in the design.
Limitations
Traditional risk-analysis output is difficult to apply directly to modern software design. Even assuming a high level of confidence in the ability to predict the dollar loss for a given event and performing Monte Carlo distribution analysis of prior events to derive a statistically sound proba- bility distribution for future events, there’s still a large gap between an ALE’s raw dollar figure (as discussed earlier) and a detailed software secu- rity mitigation definition.
A more worrying concern is that traditional risk-analysis techniques do not necessarily provide an easy guide (not to mention an exhaustive list) of all potential vulnerabilities and threats to consider at a compo- nent/environment level. This is why a large knowledge base and lots of experience is invaluable.
The thorny knowledge problem arises in part because modern appli- cations, including Web services ap- plications, are designed to span mul- tiple boundaries of trust. The vulnerability of—and threat to—any given component varies with the platform on which that component
exists (think C# on a Windows .NET server versus J2EE on Tom- cat/Apache/Linux) and the envi- ronment in which it lives (think se- cure DMZ versus directly exposed LAN). However, few traditional methodologies adequately address the contextual variability of risk given changes in the core environ- ment. This is a fatal flaw when con- sidering highly distributed applica- tions or Web services.
In modern frameworks such as .NET and J2EE, security methods exist at almost every layer, yet too many applications today rely on a “re- active” protection infrastructure that only provides protection at the net- work transport layer. This is too often summed up by saying, “We’re secure because we use SSL and implement firewalls,” which opens the door to all sorts of problems such as those engen- dered by port 80 attacks, SQL injec- tion, class spoofing, and method overwriting (to name just a few).
One approach to overcoming these problems is to start looking at software risk analysis on a compo- nent-by-component, tier-by-tier, and environment-by-environment level and then apply the principles of measuring threats, vulnerabilities, and impacts at each level.
A practical approach
At the design stage, any risk-analysis process should be tailored to soft- ware design. Recall that the object of this exercise is to determine specific vulnerabilities and threats that exist for the software and assess their im- pact. A functional decomposition of the application into major compo- nents, processes, data stores, and data communication flows, mapped against the environments across which the software will be deployed, allows for a desktop review of threats and potential vulnerabilities. We cannot overemphasize the impor- tance of using a forest-level view of a system during risk analysis. Some sort of high-level system model
82 IEEE SECURITY & PRIVACY s JULY/AUGUST 2004
Building Security In
(from a whiteboard with boxes and arrows to a formally specified math- ematical model) makes risk analysis at the architectural level possible.
Although we could contemplate using modeling languages such as UMLSec to attempt to model threats, even the most rudimentary analysis approaches can yield meaningful re- sults. Consider Figure 2, which shows a simple four-tier deployment design pattern for a s
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com