検索対象: Software security. building security in
36 C わ 4 1 Defining 4 D な じ ゅ 〃 れ e of saltzer and Schroeder [ 1975 ] ) and rules (identified and captured in static analysis t001S such as lTS4 [Viega et al. 2000a ] ) are fairly well understood. Knowledge catalogs only more recently identified include guidelines (often built into prescriptive frameworks for technologies such as . NET and J2EE)' attack patterns [Hoglund and McGraw 2004 ] , and historical risks. TO- gether, these various knowledge catalogs provide a basic foundation for a unified knowledge architecture supporting SOft 、 securlty. Software security knowledge can be successfully applied at various stages throughout the entire SDLC. One effective way t0 apply such knowl- edge is through the use Of software security touchpoints. For example' rules are extremely useful for StatiC analysis and COde actlvitles. Figure 1 ー 12 ShOWS an enhanced versl()n Of the software security touch- points diagram introduced in Figure 1 ー 9. ln Figure 1 ー 12 , I identify those activities and artifacts most clearly impacted bY the knowledge catalogs briefly mentioned above. More informatlon about these catalogs can be found in Chapter 11. Awareness Of the software security pr()blem is growmg among researchers and S01 れ e security practitioners. ト10 、 the most important audience has in some sense experienced the least eXPOSUre¯fOr the most part, SOftware architects, developers and testers remain blithely unaware of the problem. One obvious way t0 spread software security knowledge iS tO traln software development staff critical software securlty issues. The most effective form Of training begins with a description Of the problem and demonstrates its impact and importance. During the Windows security push in February and March 2002 , Microsoft provided basic aware- ness training tO all Of its developers. Many Other organizations have ongo- lng SOftware security tralmng programs. Beyond more advanced software security training should Offer coverage Of security engi- neering, design principles and guidelines implementation design flaws' analysis techniques, and security testing. special tracks should be made avail- able tO quality assurance personnel' especially those whO carry out testing. Of course, the best training programs will Offer extenswe and detailed coverage Of the touchpoints covered in this bOOk. putting the touchpoints intO practice requires cultural change' and that means training. Assembling a complete SOftware security program at the enterprise level is the subject Of Chapter 10. The good news is that the three pillars 0f software security¯risk manage- ment, touchpoints, and knowledge—can be applied in a sensible' evolution- ary manner no matter what your existing SOftware development approach is.
Chapter 2 , A Risk Management Framework, describes my philosophy 0f risk management and hOW tO put it 1ntO practice. AII t00 Often in computer security, risk management is paid only lip service•We know we re SUPPOSed to be doing it, but nobody ever says how. Chapter 2 fixes that. A continuous risk management framework encompasses identifying' rank- ing, and keeping track 0f risks throughout software development. OnlY bY pract1Cing risk management and factormg in critical business informatl()n about impact will software security begin tO enjOY the business relevance it deserves. part Ⅱ of this book, seven Touchpoints for S0ftware SecuritY, is devoted tO software security best practices. The touchpoints are one Of the three pil- lars Of software security. Attaining software security may not be but it doesn't have t0 be a burden. BY describing a manageably small set 0f touch- points based around the software artifacts you already produce' I avoid reli- gious warfare over process and get on with the business Of software security. You don't have tO adopt all seven touchpoints tO begin tO build security in (though doing so is highly recommended). The figure on the inside front cover Of the bOOk shows the seven touchpoints ordered according tO ef- fectiveness and importance. The touchpoints are designed t0 6 Ⅱ the gap between the state Of the art and the state Of the practice—something that can be done only through the common adoption Of best practices. Touchpoints are a mix Of destructlve and constructive actiV1tieS. 、 D ビ - s な 〃 じ 〃 レ ビ 4 じ 〃 レ ″ s are about attackS' exploits and breaking software. These kinds of things are represented by the black hat (offense). CO な 怩 ac 〃 レ ″ S are about design, defense, and functionality. These are represented by the white hat (defense). B0th hats are necessary. Chapter 3 , lntroduction t0 S0ftware Security TouchP0ints, provides a flyover Of the touchpoints and discusses the critical idea Of pushing security as early into the software lifecycle as possible (mostly t0 save money). I also discuss whO should practice software security and hOW tO build a software securlty group. Chapter 4 , C0de Review with a TOOI, is about one 0f the two most important software security best practices. Though not all software projects produce specifications, or even properly document requirementS' they all produce COde. Bugs (simple implementation errors in COde) are responsible for 50 % of all software security problems, so finding and fixing security- critical bugs at the code level is essential. Automated code IS a white hat (constructive) activity informed by a black hat history 0f known defects and exploits. The idea is t0 avoid implementation problems while we build
Ku 川 わ 4 坦 ( So ″ ル 4 S “ 〃 行 丿 229 Although test planning and execution are generally performed by QA and development groups, testing represents another opportunity for infosec tO have a positive lmpact. Testing—especially risk-based test- mg—not only must cover functionality but also should closely emulate the steps that an attacker will take when breaking a target system. Highly realistic scenarios (). g. , the security analog tO real user) are much more useful than arbitrary pretend 。 。 attacks. ' ' Standard testing orgamza- tions, if they are effective at all, are most effective at designing and per- forming tests based around functional specifications. Desigmng risk-based test scenarlos IS a rather substantial departure from the status quo and one that should benefit from the experience base Of security incident handlers. ln this case, infosec professionals whO are good at thinking like bad guys are the most valuable resources. The key to risk- based testing is tO understand hOW bad guys work and what that means for the system under test. ・ 1 川 々 川 ビ 〃 〃 0 〃 : COde Re レ 曜 The design-centnc actlvities described earlier focus on architectural flaws built into software design. They completely overlook, however, implementation bugs that may well be introduced during coding. lmple- mentation bugs are bOth numerous and common (just like real bugs in the VirginIa countryside) and include nasty creatures like the notorious buffer overflow, which owes lts existence tO the use ()r mlsuse) Of vul- nerable APIs (). g. , gets(), strcpy(), and so on in C) (see Chapter4). COde review processes, bOth manual and (even more important) autO- mated with a static analysis tOOl, attempt tO identify security bugs prior tO the software's release. By its very nature, COde revlew requires knowledge Of COde. An infosec practltioner with little expenence writing and compiling SOft- ware is going tO be Of little use during a COde review. If you know what it means for a variable tO be declared in a header or an argument t0 a method t0 be static/final, staring at lines 0f code all day isn't going to help. Because of this, the code review step is best left in the hands of the members of the development organization, especially if they are armed with a modern source COde analysis tOOl. With the exceptlon Of information security people wh0 are highly experienced in programmmg languages and code-level vulnerability resolution, there is no natural fit for network security expertise during the COde review phase. ThiS may come as a great surprise tO those organizations currently attempting tO impose software security on their enterprises through the infosec
84 0 SECURITY REQUIREMENTS 0 ABUSE CAS E 5 REQUIREMENTS AND USE CASES C わ 4 邵 3 な 0 は わ 〃 SO ″ 曜 4 立 砒 り 肪 〃 訪 々 0 な 0 EXTERNAL REVIEW CODE REVIEW ( T00L5 ) CODE PENETRATION TESTINC. RISK ANALYSIS ARCHITECTURE AND DESICN 0 RISK-BASED SECURITY T E 5T5 TEST PLANS RISK ANALYSIS TEST RESULTS TESTS AND SECURITY OPERATIONS FEEDBACK FROM THE FIELD 日 gu 祀 ヨ ー 1 Lightweight software security best practices called t0 リ c わ PO ⅲ な are applied t0 various software artifacts. The best practices are numbered according tO effectiveness and importance. NOte that by referring on ツ tO software artifactS' we can avoid battles over any particular process. intO requirements, architecture, COding' measure- ment, and maintenance. AIthough the artifacts are laid out according t0 something that 100kS like a traditional waterfall model in the picture, most organizations fOllOW an iterative approach today, which means that touchpoints will be cycled through more than once as the software evolves. ln any by focusing on the artifacts 、 can avoid broader process lSSues (including the ever- present warfare surrounding WhiCh software process is the true way and the light). As I discuss in chapter 1 , the software security touchpoints are designed tO be process agnostic. That is, the touchpoints can be applied no matter which software process you use t0 build your software. As long as you are producing some minimal set Of software artifacts (and every project should at least be producing code! ) , you can apply the touchpoints. I used tO present the software security touchpoints in order from left tO right. Although that works OK, a better pedagogical approach is t0 order the touchpoints by their natural utility and present them in some sort Of ranking. some touchpoints are by their very nature more powerful than others, and you should adopt the most powerful ones first.
28 C わ 叩 1 Defining 4 D な じ ゅ 〃 れ AS practitloners become aware Of SOftware importancg they are lncreasingly adopting and evolving a set Of best practices tO address the problem. Microsoft has carried out a noteworthy effort under its Trustwor- thy Computing lnitiative [Walsh 2003 ; Howard and Lipner 2003 ]. (See the next box, Microsoft's Trustworthy Computing lnitiative. ) Most approaches in practice tOday encompass training for developers testers and architects; analysis and auditing Of software artifacts; and security engineering. ln the fight for better software, treating the disease itself (poorly designed and implemented software) is better than taking an aspirin tO stop the symp- toms. There's no substitute for working software security as deeply into the development process as possible and taking advantage 0f the engineering lessons software practitioners have learned years. Figure 1 ー 9 specifies the 50 〃 ル 4 sec 〃 り じ わ 々 0 な (a set Of best prac- tices) that I cover in this bOOk and ShOWS hOW software practitloners can apply the touchpoints tO the vanous software artifacts produced during software development. These best practices first appeared as a set in 2004 in IEEE 立 り び p 0 magazine [McGraw 2004 ]. Since then' they have been adopted (and in some cases adapted) bY the U. S. government in the National cyber security Task Force report [Davis et al. 2004 ] , by Cigital' by the U. S. Department of Homeland SecuritY' and by Ernst and Young. ln var- ious chapters ahead, l'll detail these best practices (see Part Ⅱ ). SECURITY REQUIREMENTS ABUSE CASES REQUIREMENTS AND USE CASES E><TERNÄL REVIEW CODE ~ REVIEW ( T00L5 ) CODE PENETRATION TESTINC RISK ANALYSIS ARCHITECTURE AND DESICN RISK-BASED SECURITY TE 5T5 TEST PLANS Ⅲ 5 K ANALYSIS TEST RESULTS TESTS AND SECURITY 0 P E RATI 0 N 5 FEEDBACK FROM THE FIELD Figure 1 ー 9 S0ftware security best practices applied tO various software artifacts. AIthough in this picture the artifacts are laid out according tO a traditional waterfall mode し most organizations fOllOW an iterative app 「 oach today which means that best practices will be cycled through more than once as the software evolves.
94 C わ 3 な 0 け わ 〃 SO ″ ル 4 立 じ / 肪 〃 訪 々 0 な risk-based security testing married with penetratlon testing' security ments analysis with abuse case development' COde with penetration testing, and architectural risk analysis with risk-based testing. be afraid tO experlment with combinations. The touchpoints are teased apart and presented separately mostly for pedagogical reasons. Touchpoints as Best Practices As noted earlier, the software security field is a relatively new one. The first books and academic classes on the t0Pic appeared in 2001 , demonstrating hOW recently developers, architects, and computer scientists have started systematically studying how t0 build secure software. The field's recent appearance is one reason why best practices are neither widely adopted nor ln some cases obvious. The good news is that technologists and commercial vendors all ac- knowledge that the software security problem exists. The bad news is that we have barely begun tO instantlate solutions; moreoveg many prOPOSed solutions are impotent. NOt surprisinglY' early commercial solutions tO the software security problem tend tO take an operational stance¯that they focus on solving the software security problem through late lifecycle activi- ties such as firewalling ()t the application level)' penetration testing' and patch management. Because security has tended tO be operational in nature (especially in the corporate world' where IT security revolves around the proper placement and monitoring Of network security apparatus)' this oper- ational tack is only natural. This leads t0 a bifurcatlon 0f approaches when it comes tO SOft 、 intO application security and software security. The core of the problem is that building systems t0 be secure cannot be accomplished by using an operations mindset. lnstead' we must revisit all phases Of system development and make sure that security is present ln each Of them. ・ when it comes tO software' this means taking a close 100k over all software artifacts. This is a far cry from black box testlng. Best practices are usually described as those practices expounded bY experts and adopted by practitioners. AS a group' the tOUChPOints vary in terms Of adoption. ・ 病, ・ hile almost every organization worried about security makes use Of penetratlon testing, very few venture intO the murky area Of abuse case development. Though I understand that the utility and rate 0f adoption varies among the touchpoints in this bOOk' I am comfortable call- ing them all best practices.
TO 〃 c わ 々 0 な ー 0 Success Touchpoints to Su ( ( e55 7 03 As I have said before, software security is not security software. security functionality alone will not make software secure. The touchpoints outlined here reinforce and flesh out that perspective by emphasizing the kinds of assurance act1Vities necessary t0 build security in. TO attaln software secu- rity, software projects must apply the touchpoints throughout the software lifecycle, practicing security assurance as they go. The touchpoints 1 have identified take into account both security mechanisms (such as access con_ trol) and design for security (such as robust design that makes software attacks difficult). These encompass both black hat and white hat activities. Sometimes the areas overlap, but often they don't. They are, however, closely aligned. One central goal of this book is to describe the best practices overviewed in this chapter in more detail. Touchpoints are one Of the three pillars Of SOftware security. As the connectedness, complexity, and extensibility Of modern SOftware continue t0 lmpact software security in a negative ℃ must begin to grapple with the problem in a more reasonable fashion than simply spray painting cryptography on our code. lntegrating a decent set of best practices into the software development lifecycle is an excellent way to do this. PIaying the game of software security requires both good offense and good defense ()n other words, two hats), and for that reason the touch- points use bOth constructive and destructive approaches. Although software security as a field has much maturing to do, it already has a lot to offer to those practitloners interested in striking at the heart of security problems.
Appendix D Glossary 393 cause 50 % 0f software security problems. See Chapter 1. FIaw—A design-level or architectural software defect. High-level defects securlty C01 れ pronuse. Exp10it—A script or plan that executes against a vulnerabilitY' leading t0 only tO surface in a fielded system with consequence. defects. A defect is a problem that may lie dormant in software for years Defect—Both implementation vulnerabilities and design vulnerabilities are COTS—CommerciaI off-the-shelf software. can be easily discovered and remedied. See Chapter 1. simple implementatlon errors. Bugs are implementation-level problems that by many software practitloners, I reserve use Of the term tO encompass fairly code but never be executed. Though the term わ 〃 g is applied quite generally Bug—A bug is an implementation-level software problem. Bugs may exist in level description of a set 0f software attacks. See Chapter 8. Attack pattern—Like a design pattern, only applicable t0 attacks. A high- field. documents, test plans, test results, executables and feedback from the artifacts including reqmrements, use cases, design software security best practices meant tO be applied tO common software ated in the course 0f building software. The touchpoints in this b00k are Artifact ( お 々 “ 〃 software artifact)—Those documents and objects cre- world. I provide this small glossary t0 pin things down a bit more. number Of terms in this bOOk are used very loosely out there in the
工 X レ 〃 i security touchpoints intO action. applicable throughout the software development lifecycle when you put the attack patterns, and historical risks. These knowledge catalogs are directly ful tO practitioners: prmciples guidelines explOitS' pillars. This chapter presents a taxonomy 0f seven knowledge catalogs use- Chapter 11 , Knowledge for software securitY' describes one 0f the three with the software security touchpoints. is the result Of combining your existing approach tO software development rity programs. A completely integrated secure Development Lifecycle (SDL) Of expenence at Cigital' helping large companies implement software secu- zooming down the highway' but it な possible. This chapter draws on years IS running 100 miles an hour is like fixing your engine while your car is adopting software securlty touchpoints in a development organization that oriented 0f the chapters in SO ″ ル 4 立 り . There is little doubt that in a large organization. Because Of Chapter 10 is the 1 れ ost business- approach t0 the kind 0f cultural change required t0 adopt software security Chapter 10 , An Enterprise software security Program' describes an programs. Of essential software security knowledge and Of large-scale software security part lll, Software security Grows Up, contains a far-ranging treatment to-day tactics carried out by ops people are largely defensive. essential tO security, Of course' but in terms Of building security the day- a white hat activity, but it is only very weakly constructive. Operations is that might otherwise be missing from the development team. Operations is carrylng out the touchpoints, providing and security wisdom tions, describes hO 、 network securlty professionals can get involved in ing network security. Chapter 9 , S0ftware SecuritY Meets Security Opera- Software security can benefit greatly from experience gained bY practic- both black and white hats, the black hat is predominant. drives the remaimng portion. Although abuse cases clearly involve a mix of centage 0f the abuse cases. Black hat thinking in the form Of attack patterns security reqmrements, which are a necessary foundation for a goodly per- selves driven by the two threads. White hat thinking (constructive) drives hat (destructive) activities. That would be wrong. Abuse cases are them- are tricky. You might guess by the name that abuse cases involve only black process iS introduced tO adoption Of cases easier. cases known attack patterns and alSO thinking about anti-requirements. A simple activity. Abuse case development is based on understanding and applying
268 C わ 4 催 月 KnowIedge So ″ ル 4 尾 立 砒 り TabIe 11 ー 1 A Bird's-Eye View of Software Security Knowledge Catalogs KnowIedge ( at 09 Exp10its Description An exploit is a particular instance Of an attack on a computer system that leverages a specific vulnerability 0 「 set 0f vulnerabilities. SampIe High-LeveI Schema ・ Exp10it code ・ Exposure type Motivation Preconditions Description ・ Title on) version ′ and SO application, language, (platform, OS ′ description ・ Context vulnerabilities ・ Related ・ BIocking 50 tion ReIevant 50 [ ( Artifacts ・ FieIded system ・ Penetration tests Security KnowIedge and the Touchpoints Software security knowledge can be successfully applied at various stages throughout the entire SDLC. One effective way to apply such knowledge is through the use Of software security best practices such as the touchpoints. For example, rules are extremely useful for Stat1C analysis and COde inspec- tlon act1V1t1es. Software security best practices and their associated knowledge catalogs can be applied regardless of the base software process being followed. Soft- ware development processes as diverse as the waterfall model, RUP, XP, Agile, spiral development, and CMMi (and any number of other processes) involve the creation Of a common set Of software artifacts (the most C01 れ 一 mon artifact being code). Figure 11 ー 2 shows an enhanced version of the touchpoints diagram that serves as the backbone of this book. ln the figure, I identify those activities and artifacts most clearly impacted by the knowl- edge catalogs described here. The box Two ExampIe Catalog Entries: A Principle and a Rule (see page 270 ) and the preceding Table 11 ー 1 provide an overview of each of the knowledge catalogs. Principles, given their philosophicallevel of abstrac- tion, bring significant value t0 early-lifecycle activities including the defini- t10n Of security requtrements, performance Of software architecture riSk