book

Application Security Program Handbook

by Derek Fisher

January 2023

Intermediate to advanced

296 pages

10h 8m

English

Manning Publications

Read now

Unlock full access

forewordprefaceacknowledgmentsabout this bookWho should read this bookHow this book is organized: A road mapDefining application securityDeveloping the application security programDeliver and measureliveBook discussion forumabout the authorabout the cover illustration
1.1 The role of an application security program1.1.1 Software from concept to production1.1.2 Where does application security fit?1.2 The current state of application security1.3 Why building security in is challenging1.3.1 Trying to protect at runtime1.3.2 Getting output from tools is not enough1.3.3 Sifting signal from noise in security tools1.4 Shifting right vs. shifting left in development1.4.1 Shifting right in the development life cycle1.4.2 Shifting right fails1.4.3 Shifting left in the development life cycle1.4.4 Shifting left fails1.5 Is going left better than going right?1.6 Application security needs you!1.6.1 Democratizing application security1.6.2 Users will be users1.7 Examples of failing to secure the software1.7.1 SolarWinds1.7.2 Accellion1.7.3 Fake softwareSummary
2.1 The CIA triad2.2 Confidentiality2.2.1 Data protection policy2.2.2 Data at rest2.2.3 Applying encryption2.2.4 Data in transit2.2.5 Encryption prior to transmission2.2.6 Data in use2.2.7 Not so confidential2.2.8 Do I even need this?2.3 Availability2.3.1 DoS and DDoS2.3.2 Accidental outage2.3.3 The role of ransomware2.3.4 Casino betting offline2.3.5 Health organizations are still fair game2.3.6 Building in resiliency2.4 Integrity2.4.1 Integrity starts with access2.4.2 The role of version control2.4.3 Data validation2.4.4 Data replication2.4.5 Data checks2.5 Authentication and authorization2.5.1 Authentication2.5.2 Authorization2.6 Adversaries2.6.1 Script kiddies2.6.2 Insider2.6.3 Cybercriminal2.6.4 Hacktivist and terrorist2.6.5 Advanced persistent threat2.6.6 Why do we care?2.7 Measuring risk2.7.1 Remediate, mitigate, accept2.7.2 Identify the risk2.7.3 Estimating likelihood2.7.4 Estimating impact2.7.5 Risk severity2.7.6 Risk example2.7.7 Other methodologiesSummary
3.1 Threat modeling3.1.1 Basic threat modeling terminology3.1.2 Manual threat modeling3.1.3 Starting the manual process3.1.4 Threat modeling with linking bank accounts3.1.5 What to do with the found threats3.1.6 Threat modeling using a tool3.2 Security analysis tools3.2.1 Static application security testing3.2.2 Tools in the development environment3.2.3 Dynamic application security testing3.2.4 Software composition analysis3.3 Penetration testing3.4 Run-time protection tools3.5 Vulnerability collection and prioritization3.5.1 Integrating with defect tracking3.5.2 Prioritizing vulnerabilities3.5.3 Closing vulnerabilities3.6 Bug bounty and vulnerability disclosure program3.6.1 Vulnerability disclosure program3.6.2 Bug bounty program3.6.3 Third-party help with vulnerabilities3.7 Putting it togetherSummary

4.1 Security in DevOps4.1.1 DevOps pipelines4.2 DevOps isn’t the only game in town4.2.1 Waterfall4.2.2 Agile4.2.3 Lean4.2.4 DevOps supports security better4.2.5 DevSecOps example4.3 Application security tooling in the pipeline4.3.1 Threat modeling in DevSecOps4.3.2 SAST in DevSecOps4.3.3 DAST and IAST in DevSecOps4.3.4 SCA in DevSecOps4.3.5 Run-time protection in DevSecOps4.3.6 Security orchestration4.3.7 Security education4.4 Feedback loopSummary
5.1 Security is everyone’s problem5.1.1 Structure of an application security team5.1.2 Just hire more application security people5.1.3 How to close the gap5.2 Security education5.2.1 Raising the security IQ5.2.2 Microlearning and just-in-time training5.2.3 It’s more than just training5.3 Standards, requirements, and reference architecture5.3.1 Creating and driving standards5.3.2 Creating reference architecture5.3.3 Bringing requirements into the organization5.4 Maturity models5.4.1 OWASP SAMM5.4.2 Building Security in Maturity Model5.4.3 Addressing your security immaturity5.5 Decentralized application security5.5.1 Security champions program5.5.2 Leveraging the decentralized modelSummary
6.1 Managing risk during development6.1.1 Defining and reducing risk6.1.2 Define the application risk6.1.3 Release-by-risk6.2 Enablement instead of gates6.2.1 Automate the release-by-risk6.2.2 Removing the barriers by adding guardrails6.3 Bridging engineering and security through services6.3.1 The application security-as-a-service ecosystem6.3.2 Services requested through tickets6.3.3 Ambient application securitySummary
7.1 Getting the current security posture7.1.1 Going on tour7.1.2 What tools exist?7.1.3 What vulnerabilities do you have?7.1.4 What additional information is available?7.2 Understanding the organization’s security goals7.2.1 The organization’s goals7.2.2 The application security goals7.2.3 Aligning the business and security goals7.3 Identifying the gaps7.3.1 Finding the immediate gaps7.3.2 Input into the gap analysis7.3.3 What to do with the gap analysis7.4 Sample application security roadmap7.4.1 Secure engineering education7.4.2 Educating the application security team7.4.3 Application security tools roadmap7.4.4 Aligning engineering and security roadmaps7.4.5 Building for the futureSummary
8.1 What to measure8.1.1 Measuring the effectiveness of your tools8.1.2 Tuning the tools based on feedback8.1.3 Measuring the effectiveness of your processes8.1.4 Measuring the mean time to remediate8.1.5 Optimizing the mean time to remediate8.2 Gathering effectiveness with KPIs8.2.1 Building the KPIs8.2.2 Setting KPI targets8.2.3 Driving change based on KPIs8.3 Getting feedback8.3.1 Getting feedback from conversations8.3.2 Getting feedback from surveys8.4 Security scorecard8.4.1 Preparing for the scorecard8.4.2 Weighting the scores for the scorecard8.4.3 Creating the scorecardSummary
9.1 Keeping ahead of the attacker9.1.1 MITRE ATT&CK9.1.2 Cyber Kill Chain9.2 Threat catalogs9.2.1 Applying the OWASP Top Ten9.2.2 Applying the MITRE CWE Top 259.3 Staying ahead of engineering9.3.1 Keeping up with the coding languages9.3.2 Keeping up with the technology changes9.3.3 When hiring and training aren’t enough9.4 Stop chasing the shiny new tool9.4.1 Use a capability matrix9.4.2 Managing the tool and vendor9.4.3 Buy the shiny new tool9.5 Preparing for the worstSummary
Chapter 1EXERCISE 1.1EXERCISE 1.2EXERCISE 1.3Chapter 2EXERCISE 2.1EXERCISE 2.2Chapter 3EXERCISE 3.1EXERCISE 3.2EXERCISE 3.3EXERCISE 3.4Chapter 5EXERCISE 5.1EXERCISE 5.2EXERCISE 5.3Chapter 6EXERCISE 6.1EXERCISE 6.2Chapter 7EXERCISE 7.1Chapter 8EXERCISE 8.1EXERCISE 8.2EXERCISE 8.3

Content preview from Application Security Program Handbook

front matter

foreword

I am a big fan of analogies as an interesting way to describe technical concepts like application security. I find it a straightforward way to get everyone on the same page and get to that “Aha, I get it” moment. I came up with a brand-new analogy for this book’s foreword: application security is like the game Stratego. Stratego is a board game where the goal is to protect your hypothetical country’s flag from your competitor with different types of defenses and strategies. It is up to you to define and design the proper protections for your flag. There is no right or wrong way to protect your flag, but there are good and not-so-good ways. Just like application security programs that ensure the security of your applications, ...