book

Security Development Lifecycle

by Michael Howard, Steve Lipner

June 2006

Intermediate to advanced

352 pages

11h 27m

English

Microsoft Press

Read now

Unlock full access

The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software
Foreword
Introduction
Why Should You Read This Book?Organization of This BookPart I, “The Need for the SDL”Part II, “The Security Development Lifecycle Process”Part III, “SDL Reference Material”The Future Evolution of the SDLWhat’s on the Companion Disc?System RequirementsAcknowledgmentsReferences
Bibliography
I. The Need for the SDL
1. Enough Is Enough: The Threats Have Changed
Worlds of Security and Privacy CollideAnother Factor That Influences Security: ReliabilityIt’s Really About QualityWhy Major Software Vendors Should Create More Secure SoftwareA Challenge to Large ISVsWhy In-House Software Developers Should Create More Secure SoftwareWhy Small Software Developers Should Create More Secure SoftwareSummaryReferences
Bibliography
2. Current Software Development Methods Fail to Produce Secure Software
“Given enough eyeballs, all bugs are shallow”Incentive to Review CodeUnderstanding Security BugsCritical Mass“Many Eyeballs” Misses the Point AltogetherProprietary Software Development MethodsCMMI, TSP, and PSPAgile Development MethodsCommon CriteriaSummaryReferences
Bibliography
3. A Short History of the SDL at Microsoft
First StepsNew Threats, New ResponsesWindows 2000 and the Secure Windows InitiativeSeeking Scalability: Through Windows XPSecurity Pushes and Final Security ReviewsFormalizing the Security Development LifecycleA Continuing ChallengeReferences

Bibliography
4. SDL for Management
Commitment for SuccessCommitment at MicrosoftIs the SDL Necessary for You?Effective CommitmentMake a StatementBe VisibleProvide ResourcesStop ProductsManaging the SDLResourcesFactors That Affect the Cost of SDLRules of ThumbIs the Project on Track?SummaryReferences
Bibliography
II. The Security Development Lifecycle Process
5. Stage 0: Education and Awareness
A Short History of Security Education at MicrosoftOngoing EducationTypes of Training DeliveryExercises and LabsTracking Attendance and ComplianceOther Compliance IdeasMeasuring KnowledgeImplementing Your Own In-House TrainingCreating Education Materials “On a Budget”Key Success Factors and MetricsSummaryReferences
Bibliography
6. Stage 1: Project Inception
Determine Whether the Application Is Covered by SDLAssign the Security AdvisorAct as a Point of Contact Between the Development Team and the Security TeamHolding an SDL Kick-Off Meeting for the Development TeamHolding Design and Threat Model Reviews with the Development TeamAnalyzing and Triaging Security-Related and Privacy-Related BugsActing as a Security Sounding Board for the Development TeamPreparing the Development Team for the Final Security ReviewWorking with the Reactive Security TeamBuild the Security Leadership TeamMake Sure the Bug-Tracking Process Includes Security and Privacy Bug FieldsDetermine the “Bug Bar”SummaryReferences
Bibliography
7. Stage 2: Define and Follow Design Best Practices
Common Secure-Design PrinciplesAttack Surface Analysis and Attack Surface ReductionStep 1: Is This Feature Really That Important?Step 2: Who Needs Access to the Functionality and from Where?Step 3: Reduce PrivilegeServices and Low PrivilegeMore Attack Surface ElementsUDP vs. TCPWeak Permissions vs. Strong Permissions.NET Code vs. ActiveX CodeActiveX “Safe for Scripting”ActiveX SiteLocked ControlsManaged Code AllowPartiallyTrustedCallers AttributeSummaryReferences
Bibliography
8. Stage 3: Product Risk Assessment
Security Risk AssessmentSetup QuestionsAttack Surface QuestionsMobile-Code QuestionsSecurity Feature–Related QuestionsGeneral QuestionsAnalyzing the QuestionnairePrivacy Impact RatingPrivacy Ranking 1Privacy Ranking 2Privacy Ranking 3Pulling It All TogetherSummaryReferences
Bibliography
9. Stage 4: Risk Analysis
Threat-Modeling ArtifactsWhat to ModelBuilding the Threat ModelThe Threat-Modeling Process1. Define Use Scenarios2. Gather a List of External Dependencies3. Define Security Assumptions4. Create External Security NotesPet Shop 4.0 External DependenciesPet Shop 4.0 Security AssumptionsPet Shop 4.0 External Security InformationWhat Is Modeled and What Do You Depend On?5. Create One or More DFDs of the Application Being Modeled6. Determine Threat TypesSpoofing IdentityTamperingRepudiationInformation DisclosureDenial of ServiceElevation of Privilege7. Identify Threats to the System8. Determine Risk9. Plan MitigationsDo NothingRemove the FeatureTurn Off the FeatureWarn the UserCounter the Threat with Technology(1.0→4.2→1.0) Data Flow from Pet Shop User to Web Application and Back(4.7.10) Audit Log Data Store(4.7.1) Order Processor ProcessUsing a Threat Model to Aid Code ReviewUsing a Threat Model to Aid TestingKey Success Factors and MetricsSummaryReferences
Bibliography
10. Stage 5: Creating Security Documents, Tools, and Best Practices for Customers
Why Documentation and Tools?Creating Prescriptive Security Best Practice DocumentationSetup DocumentationMainline Product Use DocumentationHelp DocumentationDeveloper DocumentationCreating ToolsSummaryReferences
Bibliography
11. Stage 6: Secure Coding Policies
Use the Latest Compiler and Supporting Tool VersionsUse Defenses Added by the CompilerBuffer Security Check: /GSSafe Exception Handling: /SAFESEHCompatibility with Data Execution Prevention: /NXCOMPATUse Source-Code Analysis ToolsSource-Code Analysis Tool TrapsBenefits of Source-Code Analysis ToolsDo Not Use Banned FunctionsReduce Potentially Exploitable Coding Constructs or DesignsUse a Secure Coding ChecklistSummaryReferences
Bibliography
12. Stage 7: Secure Testing Policies
Fuzz TestingFuzzing File FormatsA generic file-fuzzing processIdentify all valid file formatsCollect a library of valid filesMalform a fileConsume the file and observe the applicationFuzzing Network ProtocolsCreate bogus packetsRecord-fuzz-replay packetsMalforming packets on the flyMiscellaneous FuzzingFixing Bugs Found Through Fuzz TestingPenetration TestingRun-Time VerificationReviewing and Updating Threat Models if NeededReevaluating the Attack Surface of the SoftwareSummaryReferences
Bibliography
13. Stage 8: The Security Push
Preparing for the Security PushPush DurationTrainingCode ReviewsExecutable-File OwnersThreat Model UpdatesSecurity TestingAttack-Surface ScrubDocumentation ScrubAre We Done Yet?SummaryReferences
Bibliography
14. Stage 9: The Final Security Review
Product Team CoordinationThreat Models ReviewUnfixed Security Bugs ReviewTools-Use ValidationAfter the Final Security Review Is CompletedHandling ExceptionsSummary
15. Stage 10: Security Response Planning
Why Prepare to Respond?Your Development Team Will Make MistakesNew Kinds of Vulnerabilities Will AppearRules Will ChangePreparing to RespondBuilding a Security Response CenterWhich Vulnerabilities Will You Respond To?Where Do Vulnerability Reports Come From?Security Response ProcessVulnerability reportingTriagingCreating the fixSecurity fixes and regressionsSecurity fixes for multiple product versions and localesManaging the security researcher relationshipTestingContent creationSecurity advisoriesPress outreachUpdate releaseLessons learnedEmergency Response ProcessWatch phaseAlert and Mobilize phaseAssess and Stabilize phaseResolve phaseSecurity Response and the Development TeamCreate Your Response TeamSupport Your Entire ProductSupport All Your CustomersMake Your Product UpdatableFind the Vulnerabilities Before the Researchers DoSummaryReferences
Bibliography
16. Stage 11: Product Release
References
Bibliography
17. Stage 12: Security Response Execution
Following Your PlanStay CoolTake Your TimeWatch for Events That Might Change Your PlansFollow Your PlanMaking It Up as You GoKnow Who to CallBe Able to Build an UpdateBe Able to Install an UpdateKnow the Priorities When Inventing Your ProcessKnowing What to SkipSummaryReferences
Bibliography
III. SDL Reference Material
18. Integrating SDL with Agile Methods
Using SDL Practices with Agile MethodsSecurity EducationProject InceptionEstablishing and Following Design Best PracticesRisk AnalysisCreating Security Documents, Tools, and Best Practices for CustomersSecure Coding and Testing PoliciesSecurity PushFinal Security ReviewProduct ReleaseSecurity Response ExecutionAugmenting Agile Methods with SDL PracticesUser StoriesSmall Releases and IterationsMoving People AroundSimplicitySpike SolutionsRefactoringConstant Customer AvailabilityCoding to StandardsCoding the Unit Test FirstPair ProgrammingIntegrating OftenLeaving Optimization Until LastWhen a Bug Is Found, a Test Is CreatedSummaryReferences
Bibliography
19. SDL Banned Function Calls
The Banned APIsBanned String Copy Functions and ReplacementsBanned String Concatenation Functions and ReplacementsBanned sprintf Functions and ReplacementsBanned “n” sprintf Functions and ReplacementsBanned Variable Argument sprintf Functions and ReplacementsBanned Variable Argument “n” sprintf Functions and ReplacementsBanned “n” String Copy Functions and ReplacementsBanned “n” String Concatenation Functions and ReplacementsBanned String Tokenizing Functions and ReplacementsBanned Makepath Functions and ReplacementsBanned Splitpath Functions and ReplacementsBanned scanf Functions and ReplacementsBanned “n” scanf Functions and ReplacementsBanned Numeric Conversion Functions and ReplacementsBanned gets Functions and ReplacementsBanned IsBad* Functions and ReplacementsBanned OEM Conversion Functions and ReplacementsBanned Stack Dynamic Memory Allocation Functions and ReplacementsBanned String Length Functions and ReplacementsWhy the “n” Functions Are BannedImportant CaveatChoosing StrSafe vs. Safe CRTUsing StrSafeStrSafe ExampleUsing Safe CRTSafe CRT ExampleOther ReplacementsTools SupportROI and Cost ImpactMetrics and GoalsReferences
Bibliography
20. SDL Minimum Cryptographic Standards
High-Level Cryptographic RequirementsCryptographic Technologies vs. Low-Level Cryptographic AlgorithmsUse Cryptographic LibrariesCryptographic AgilityDefault to Secure Cryptographic AlgorithmsCryptographic Algorithm UsageSymmetric Block Ciphers and Key LengthsSymmetric Stream Ciphers and Key LengthsSymmetric Algorithm ModesAsymmetric Algorithms and Key LengthsHash FunctionsMessage Authentication CodesData Storage and Random Number GenerationStoring Private Keys and Sensitive DataGenerating Random Numbers and Cryptographic KeysGenerating Random Numbers and Cryptographic Keys from Passwords or Other KeysReferences
Bibliography
21. SDL-Required Tools and Compiler Options
Required ToolsPREfastFxCopApplication VerifierMinimum Compiler and Build Tool VersionsUnmanaged Compiler FlagsReferences
Bibliography
22. Threat Tree Patterns
Spoofing an External Entity or a ProcessTampering with a ProcessTampering with a Data FlowTampering with a Data StoreRepudiationInformation Disclosure of a ProcessInformation Disclosure of a Data FlowInformation Disclosure of a Data StoreDenial of Service Against a ProcessDenial of Service Against a Data FlowDenial of Service Against a Data StoreElevation of PrivilegeReferences
Bibliography
Appendix
Index
About the Authors
Copyright

Content preview from Security Development Lifecycle

Chapter 12. Stage 7: Secure Testing Policies

In this chapter:

Fuzz Testing

Penetration Testing

Run-Time Verification

Reviewing and Updating Threat Models if Needed

Reevaluating the Attack Surface of the Software

You can’t test quality into a product, and you also can’t test security into it. If the product is written in an insecure manner, uses many insecure coding practices, or has a large attack surface, no amount of testing is going to make the product secure.

That said, you should provide a testing “sanity check” of the code before release. Testing is, of course, a necessary task, and anecdotal evidence indicates that as product groups at Microsoft release a subsequent product version covered by Security Development Lifecycle (SDL), engineers tend ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 0735622140Errata Page

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Security Development Lifecycle

by Michael Howard, Steve Lipner

Chapter 12. Stage 7: Secure Testing Policies

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.