Description

Live Session
Module 11
CS642
Innovative Solutions in
Software Security
Instructor Name
Module 11 Learning Outcomes
1. Explain the impact of organizational culture on
security.
2. Implement Development Ops within an
organization.
3. Discuss development security operations
maturity models.
CS642 Innovative Solutions in Software Security
Module 11 Assignment Requirements
• Discussion Board
o Discuss the
DevSecOps Maturity Models and their
impact on an organization’s security posture.
• Lab
o Identifying Malware Attacks and Preventive
Security Measures.
o4.5.1 -Identifying security apps available for
Android
o5.4.1 – Dos Attack using Smurf Attack
CS642 Innovative Solutions in Software Security
DevSecOps Cycle
CS642 Innovative Solutions in Software Security
Transforming to a DevSecOps Culture
• Capgemini states that transforming to DevSecOps is rooted in four
guiding principles:
• Educate –
• Embed security into the design and cultivate a collaborative,
“security-enabling business” mindset.
• Automate –
• Automate the SDLC pipeline and its security at every
opportunity.
• Monitor –
• Take a risk-based approach to code review, application testing,
and monitoring.
• Iterate –
• Strive for continuous secure improvements through achievable
iterations.
•
Merkow, Mark. Secure, Resilient, and Agile Software Development . CRC Press. Kindle Edition.
CS642 Innovative Solutions in Software Security
SANS Institute – CALMS
• Culture — People come first
• Automation — Rely on tools for efficiency +
repeatability
• Lean — Apply Lean engineering practices to
continuously improve
• Measurement — Use data to drive
decisions and improvements
• Sharing — Share ideas, information and
goals across organizational silos
https://www.sans.org/blog/your-secure-devops-questions-answered/
CS642 Innovative Solutions in Software Security
Five Key Characteristics Required for DevOps
Culture
• Push change from the top.
• Reimagine trust.
• Design for autonomy and empowerment.
• Crave improvement through testing.
• Measure and reward the result, not process
compliance.
CS642 Innovative Solutions in Software Security
• In the de-facto Bible for DevOps, The DevOps
Handbook,Kim et al. note that all DevOps patterns are
derived from The Three Ways5 to frame processes,
procedures, practices, and prescriptive advice.
The 3 Ways
That Make
DevOps
Work
• The First Way emphasizes the performance of the
entire system, as opposed to the performance of a
specific silo of work or department;
CS642 Innovative Solutions in Software Security
• The Second Way is about creating the right-to-left
feedback loops.
The 3 Ways
That Make
DevOps
Work
CS642 Innovative Solutions in Software Security
• The Third Way is about creating a culture that fosters two
things:
• Continual experimentation, taking risks, and learning from failure
• Understanding that repetition and practice is the prerequisite to
mastery
The 3 Ways
That Make
DevOps
Work
CS642 Innovative Solutions in Software Security
The Three Ways Applied to AppSec
“How to Navigate the Intersection of DevOps and Security,”
• Integrating security into defect tracking and postmortems
• Track security issues in the same work-tracking systems that your
development and operations teams already use to ensure security visibility
and prioritization.
• Integrating security controls into shared source code repositories and
services
• All teams should share a source code repository containing securityapproved libraries that fulfill specific security objectives.
• Integrating security into your deployment pipeline
• Automate as many security tests as possible, when possible, to run alongside
other automated tests in your deployment pipeline.
• Ensuring the security of the application
• As you automate your tests, generate tests to run continuously in your
deployment pipeline, instead of performing unit or functional tests manually.
CS642 Innovative Solutions in Software Security
The Three Ways Applied to AppSec
• Ensuring the security of the application
• As you automate your tests, generate tests to run
continuously in your deployment pipeline, instead of
performing unit or functional tests manually.
• Ensuring the security of the software supply chain
• Up to 90% of modern applications are constructed from
open source components, making them a fundamental
part of the software supply chain today.
• When using open source components and libraries,
DevOps teams must consider that applications inherit
both the functionality of open source code and any
security vulnerabilities it contains.
CS642 Innovative Solutions in Software Security
SANS Institute –SecDevOps Toolchain
• Details the sets of open source tools that apply to these activities:
• Pre-commit
• Activities before code is checked in to version control
• Commit (continuous integration)
• Fast, automated security checks during build and continuous
integration steps
• Acceptance (continuous delivery)
• Automated security acceptance, functional testing, and deep outof-band scanning during continuous delivery
• Production (continuous deployment)
• Security checks before, during, and after code is deployed to
production
• Operations
• Continuous security monitoring, testing, audit, and compliance
checking
CS642 Innovative Solutions in Software Security
OWASP’s
DevSecOps
Maturity Model
• 16 Dimensions of DevSecOps
measured across four levels
• Build
• Deployment
• Education and guidance
• Culture and org
• Process
• Monitoring
• Logging
• Infrastructure hardening
• Patch management
• Dynamic depth for application
• Static depth for applications
• Test-intensity
• Consolidation
• Application tests
• Dynamic depth for
infrastructure
• Static depth for infrastructure
https://owasp.org/www-project-devsecops-maturity-model/
CS642 Innovative Solutions in Software Security
OWASP’s DevSecOps Maturity Model
•The four maturity levels are:
•Level 1: Basic understanding of security
practices
•Level 2: Understanding of security practices
•Level 3: High understanding of security
practices
•Level 4: Advanced understanding of
security practices at scale
CS642 Innovative Solutions in Software Security
OWASP’s DevSecOps Studio
• DevSecOps Studio11 is a virtual environment to learn and teach
DevSecOps concepts.
• The project is a free and open software to help more people learn
about DevSecOps.
• The studio aims to help you to set up a reproducible DevSecOps Lab
environment for learning and testing different tools in an
experimental environment.
CS642 Innovative Solutions in Software Security
https://owasp.org
DevSecOps Studio
• Makes it easy to set up the environment for
training/demos
• Is mostly automatic
• Teaches Security as Code, Compliance as Code, and
Infrastructure as Code
• Has built-in support for CI/CD pipeline
• Security tools can be added as jobs to DevSecOps
Studio
CS642 Innovative Solutions in Software Security
Chapter Summary
• In this chapter we:
• Explored the roots of DevOps and DevOps implementation techniques
• Examined DevOps controls, tools and processes to used to transform into
DevSecOps
• Learned about OWASP DevSecOps Maturity Model and DevSecOps Studio
CS642 Innovative Solutions in Software Security
Questions
Take advantage of this opportunity
to seek further clarification.
CS642 Innovative Solutions in Software Security
Next Live Session
•
•
CS642 Innovative Solutions in Software Security
This concludes our live session.
Thank you for your attendance!
SECURE, RESILIENT, AND AGILE
SOFTWARE DEVELOPMENT
SECURE, RESILIENT, AND AGILE
SOFTWARE DEVELOPMENT
Mark S. Merkow, CISSP, CISM, CSSLP
Boca Raton London New York
CRC Press is an imprint of the
Taylor & Francis Group, an informa business
AN AUERBACH BOOK
CRC Press
Taylor & Francis Group
6000 Broken Sound Parkway NW, Suite 300
Boca Raton, FL 33487-2742
© 2020 by Taylor & Francis Group
CRC Press is an imprint of Taylor & Francis Group, an Informa business
No claim to original U.S. Government works
Printed on acid-free paper
International Standard Book Number-13: 978-0-367-33259-4 (Hardback)
This book contains information obtained from authentic and highly regarded sources. Reasonable efforts
have been made to publish reliable data and information, but the author and publisher cannot assume
responsibility for the validity of all materials or the consequences of their use. The authors and publishers
have attempted to trace the copyright holders of all material reproduced in this publication and apologize to
copyright holders if permission to publish in this form has not been obtained. If any copyright material has
not been acknowledged please write and let us know so we may rectify in any future reprint.
Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented,
including photocopying, microfilming, and recording, or in any information storage or retrieval system,
without written permission from the publishers.
For permission to photocopy or use material electronically from this work, please access www.copyright.
com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood
Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and
registration for a variety of users. For organizations that have been granted a photocopy license by the CCC,
a separate system of payment has been arranged.
Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used
only for identification and explanation without intent to infringe.
Visit the Taylor & Francis Web site at
http://www.taylorandfrancis.com
and the CRC Press Web site at
http://www.crcpress.com
Trademarks Used in This Publication
Adobe® is a registered trademark of Adobe, Inc., in San Jose, CA.
Alert Logic® is a registered trademark of Alert Logic Inc., in Houston, TX
Amazon Web Services® is a registered trademark of Amazon Technologies, Inc., in Seattle, WA.
AppScan® and IBM® are registered trademarks of International Business Machines Corporation,
in Armonk, NY.
Atlassian® and Jira® are registered trademarks of Atlassian Pty Ltd., Sydney, Australia.
Azure® is a registered trademark of Microsoft Corporation, in Redmond, WA (on hold pending
further action as of 2019/09).
Barracuda® is a registered trademark of Barracuda Networks Inc., in Campbell, CA.
Cigital® is a registered trademark of Synopsys, Inc., in Mountain View, CA.
Citrix® is a registered trademark of Citrix Systems, Inc.
Contrast Security® is a registered trademark of Contrast Security, Inc., in Los Altos, CA.
CSSLP® and (ISC)2® are registered trademarks of International Information Systems Security
Certification Consortium, Inc., in Clearwater, FL.
CVE® is a registered trademark and CWE™ is a trademark of MITRE Corporation, in McLean,
VA.
Dell® and Dell® EMC® are registered trademarks of Dell Inc. or its subsidiaries.
Ethereum® is a registered trademark of Stiftung Ethereum (Foundation Ethereum).
F5 Silverline® is a registered trademark of F5 Networks Inc., in Seattle, WA.
Fortify® is a registered trademark of EntIT Software LLC, in Sunnyvale, CA.
GCP® is a registered trademark and Google™ is a trademark of Google, Inc., in Mountain View,
CA.
ImmuniWeb® is a globally registered trademark owned by High Tech Bridge SA, in Geneva,
Switzerland.
Imperva® is a registered trademark of Imperva Inc. in Redwood City, CA.
ISACA® is a registered trademark of Information Systems Audit and Control Association, Inc.,
in Schaumburg, IL.
IriusRisk® is a registered trademark of Continuum Security, SL, in Spain.
Jama Connect™ is a trademark of Jama Software, in Portland, OR.
Kubernetes® is a registered trademark of The Linux Foundation, in San Francisco, CA.
LinkedIn® is a registered trademark of LinkedIn Corporation, in Sunnyvale, CA.
Microsoft® is a registered trademark of Microsoft Corporation, in Redmond, WA.
NICERC™ is a trademark of National Integrated Cyber Education Research Center, in Bossier
City, LA.
Offensive Security® is a registered trademark of Offensive Security Limited, in George Town,
Grand Cayman.
OWASP is designated as non-final office action issued (clarification needed as of 2019/09).
Qualys® is a registered trademark of Qualys Inc., in Foster City, CA.
Radware® is a registered trademark of Radware, in Mahwah, NJ.
ScienceSoft® is a registered trademark of ScienceSoft USA Corporation, in McKinney, TX.
SonarQube™ is a trademark of SonarSource SA, in Switzerland.
Sonatype® is a trademark of Sonatype Inc., in Fulton, MD.
Synopsys® and Synopsys Coverity® are registered trademarks of Synopsys, Inc., in the U.S. and/
or other countries.
ThreatModeler® is a registered trademark of ThreatModeler Software, Inc., in Jersey City, NJ.
Wallarm® is a registered trademark of Wallarm Inc., in San Francisco, CA.
Dedication
This book is dedicated to the next generation of application security
professionals to help alleviate the struggle to reverse the curses
of defective software, no matter where it shows up.
vii
Contents
Dedication
vii
Contents
ix
Preface
xvii
About the Author
xxi
Chapter 1: Today’s Software Development Practices Shatter
Old Security Practices
1.1
Over the Waterfall
1.2 What Is Agile?
1.3 Shift Left!
1.4
Principles First!
1.5 Summary
References
Chapter 2: Deconstructing Agile and Scrum
2.1
The Goals of Agile and Scrum
2.2 Agile/Scrum Terminology
2.3 Agile/Scrum Roles
2.4 Unwinding Sprint Loops
2.5 Development and Operations Teams Get Married
2.6 Summary
References
1
2
3
3
6
7
7
9
9
11
11
13
15
18
18
ix
x
Secure, Resilient, and Agile Software Development
Chapter 3: Learning Is FUNdamental!
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
Education Provides Context and Context Is Key
Principles for Software Security Education
Getting People’s Attention
Awareness versus Education
Moving into the Education Phase
Strategies for Rolling Out Training
Encouraging Training Engagement and Completion
Measuring Success
Keeping the Drumbeat Alive
Create and Mature a Security Champion Network
A Checklist for Establishing a Software Security
Education, Training, and Awareness Program
3.12 Summary
References
Chapter 4: Product Backlog Development—Building
Security In
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
Chapter Overview
Functional versus Nonfunctional Requirements
Testing NFRs
Families of Nonfunctional Requirements
4.4.1 Availability
Capacity
Efficiency
Interoperability
Manageability
4.8.1 Cohesion
4.8.2 Coupling
Maintainability
Performance
Portability
Privacy
Recoverability
Reliability
Scalability
Security
Serviceability/Supportability
21
22
22
24
25
26
27
29
29
30
31
31
32
32
35
35
36
37
39
39
41
41
42
42
42
43
43
44
44
45
46
47
48
48
50
Contents
4.18 Characteristics of Good Requirements
4.19 Eliciting Nonfunctional Requirements
4.20 NFRs as Acceptance Criteria and Definition of Done
4.21 Summary
References
Chapter 5: Secure Design Considerations
5.1
5.2
5.3
5.4
Chapter Overview
Essential Concepts
The Security Perimeter
Attack Surface
5.4.1 Mapping the Attack Surface
5.4.2 Side Channel Attacks
5.5 Application Security and Resilience Principles
5.5.1 Practice 1: Apply Defense in Depth
5.5.2 Practice 2: Use a Positive Security Model
5.5.3 Practice 3: Fail Securely
5.5.4 Practice 4: Run with Least Privilege
5.5.5 Practice 5: Avoid Security by Obscurity
5.5.6 Practice 6: Keep Security Simple
5.5.7 Practice 7: Detect Intrusions
5.5.8 Practice 8: Don’t Trust Infrastructure
5.5.9 Practice 9: Don’t Trust Services
5.5.10 Practice 10: Establish Secure Defaults
5.6 Mapping Best Practices to Nonfunctional
Requirements (NFRs) as Acceptance Criteria
5.7 Summary
References
Chapter 6: Security in the Design Sprint
6.1
6.2
6.3
6.4
6.5
6.6
Chapter Overview
Design Phase Recommendations
Modeling Misuse Cases
Conduct Security Design and Architecture Reviews
in Design Sprint
Perform Threat and Application Risk Modeling
6.5.1 Brainstorming Threats
Risk Analysis and Assessment
xi
51
51
53
54
54
57
57
58
58
60
60
61
62
62
63
65
66
66
67
68
68
69
69
69
70
71
73
73
73
74
75
76
77
79
xii Secure, Resilient, and Agile Software Development
6.6.1 Damage Potential
6.6.2 Reproducibility
6.6.3 Exploitability
6.6.4 Affected Users
6.6.5 Discoverability
6.7 Don’t Forget These Risks!
6.8 Rules of Thumb for Defect Removal or Mitigation
6.9
Further Needs for Information Assurance
6.10 Countering Threats through Proactive Controls
6.11 Architecture and Design Review Checklist
6.12 Summary
References
Chapter 7: Defensive Programming
7.1
7.2
7.3
Chapter Overview
The Evolution of Attacks
Threat and Vulnerability Taxonomies
7.3.1 MITRE’s Common Weaknesses Enumeration
(CWE™ )
7.3.2 OWASP Top 10—2017
7.4
Failure to Sanitize Inputs is the Scourge of
Software Development
7.5
Input Validation and Handling
7.5.1 Client-Side vs. Server-Side Validation
7.5.2 Input Sanitization
7.5.3 Canonicalization
7.6
Common Examples of Attacks Due to Improper
Input Handling
7.6.1 Buffer Overflow
7.6.2 OS Commanding
7.7
Best Practices in Validating Input Data
7.7.1 Exact Match Validation
7.7.2 Exact Match Validation Example
7.7.3 Known Good Validation
7.7.4 Known Bad Validation
7.7.5 Handling Bad Input
7.8
OWASP’s Secure Coding Practices
7.9
Summary
References
79
80
80
80
80
81
82
82
84
84
88
88
89
89
90
91
91
92
94
95
98
98
99
100
100
100
101
101
101
102
103
104
105
105
105
Contents
Chapter 8: Testing Part 1: Static Code Analysis
8.1
8.2
8.3
Chapter Overview
Fixing Early versus Fixing Later
Testing Phases
8.3.1 Unit Testing
8.3.2 Manual Source Code Reviews
8.4 Static Source Code Analysis
8.5 Automated Reviews Compared with Manual
Reviews
8.6 Peeking Inside SAST Tools
8.7 SAST Policies
8.8 Using SAST in Development Sprints
8.9
Software Composition Analysis (SCA)
8.10 SAST is NOT for the Faint of Heart!
8.11 Commercial and Free SAST Tools
8.12 Summary
References
Chapter 9: Testing Part 2: Penetration Testing/
Dynamic Analysis/IAST/RASP
9.1
9.2
9.3
Chapter Overview
Penetration (Pen) Testing
Open Source Security Testing Methodology
Manual (OSSTMM)
9.4
OWASP’s ASVS
9.5
Penetration Testing Tools
9.6
Automated Pen Testing with Black Box Scanners
9.7
Deployment Strategies
9.7.1 Developer Testing
9.7.2 Centralized Quality Assurance Testing
9.8
Gray Box Testing
9.9
Limitations and Constraints of Pen Testing
9.10 Interactive Application Security Testing (IAST)
9.11 Runtime Application Self-Protection (RASP)
9.12 Summary
References
Chapter 10: Securing DevOps
10.1
Overview
xiii
107
107
107
108
109
109
112
113
114
119
119
121
124
124
125
125
127
127
128
128
129
131
131
133
133
134
134
134
135
136
136
137
139
139
xiv
Secure, Resilient, and Agile Software Development
10.2 Challenges When Moving to a DevOps World
10.2.1 Changing the Business Culture
10.3 The Three Ways That Make DevOps Work
10.4 The Three Ways Applied to AppSec
10.5 OWASP’s DevSecOps Maturity Model
10.6 OWASP’s DevSecOps Studio
10.7 Summary
References
Chapter 11: Metrics and Models for AppSec Maturity
11.1 Chapter Overview
11.2 Maturity Models for Security and Resilience
11.3 Software Assurance Maturity Model—OpenSAMM
11.3.1 OpenSAMM Business Functions
11.3.2 Core Practice Areas
11.4 Levels of Maturity
11.4.1 Objective
11.4.2 Activities
11.4.3 Results
11.4.4 Success Metrics
11.4.5 Costs
11.4.6 Personnel
11.4.7 Related Levels
11.4.8 Assurance
11.5 Using OpenSAMM to Assess Maturity Levels
11.6 The Building Security In Maturity Model (BSIMM)
11.7 BSIMM Organization
11.8 BSIMM Software Security Framework
11.8.1 Governance
11.8.2 Intelligence
11.8.3 SSDL Touchpoints
11.8.4 Deployment
11.9 BSIMM’s 12 Practice Areas
11.10 Measuring Results with BSIMM
11.11 The BSIMM Community
11.12 Conducting a BSIMM Assessment
11.13 Summary
References
139
141
143
145
147
148
148
149
151
151
152
152
154
155
156
156
157
157
157
157
157
158
158
158
163
163
164
164
164
166
167
167
167
167
171
171
172
Contents
Chapter 12: Frontiers for AppSec
12.1
Internet of Things (IoT)
12.1.1 The Industry Responds
12.1.2 The Government Responds
12.2 Blockchain
12.2.1 Security Risks with Blockchain
Implementations
12.2.2 Securing the Chain
12.3 Microservices and APIs
12.4 Containers
12.4.1 Container Security Issues
12.4.2 NIST to the Rescue Again!
12.5 Autonomous Vehicles
12.6 Web Application Firewalls (WAFs)
12.7 Machine Learning/Artificial Intelligence
12.8 Big Data
12.8.1 Vulnerability to Fake Data Generation
12.8.2 Potential Presence of Untrusted Mappers
12.8.3 Lack of Cryptographic Protection
12.8.4 Possibility of Sensitive Information Mining
12.8.5 Problems with Granularity of Access Controls
12.8.6 Data Provenance Difficulties
12.8.7 High Speed of NoSQL Databases’ Evolution
and Lack of Security Focus
12.8.8 Absent Security Audits
12.9 Summary
References
Chapter 13: AppSec Is a Marathon—Not a Sprint!
13.1 Hit the Road
13.2 Getting Involved with OWASP
13.3 Certified Secure Software Lifecycle Professional
(CSSLP®)
13.3.1 Why Obtain the CSSLP?
13.4 Higher Education
13.5 Conclusion
References
xv
173
173
174
175
175
176
177
178
180
180
181
182
183
183
185
185
186
186
186
186
187
187
187
187
188
191
192
192
193
194
194
194
196
xvi
Secure, Resilient, and Agile Software Development
Appendix A: Sample Acceptance Criteria for
Security Controls
197
Appendix B: Resources for AppSec
203
Training
Cyber Ranges
Requirements Management Tools
Threat Modeling
Static Code Scanners: Open Source
Static Code Scanners: Commercial
Dynamic Code Scanners: Open Source
Dynamic Code Scanners: Commercial
Maturity Models
Software Composition Analysis
IAST Tools
API Security Testing
Runtime Application Self-Protection (RASP)
Web Application Firewalls (WAFs)
Browser-centric Protection
Index
203
204
204
204
205
206
206
207
207
207
208
208
208
209
209
211
Preface
This book was written from the perspective of someone who began his software
security career in 2005, long before we knew much about it. Making all the
rookie mistakes one tends to make without any useful guidance quickly turns
what’s supposed to be a helpful process into one that creates endless chaos and
lots of angry people. After a few rounds of these rookie mistakes, it finally
dawned on me that we’re going about it all wrong. Software security is actually a
human factor issue, not a technical or process issue alone. Throwing technology
into an environment that expects people to deal with it but failing to prepare
them technically and psychologically with the knowledge and skills needed is a
certain recipe for bad results.
Think of this book as a collection of best practices and effective implementation recommendations that are proven to work. I’ve taken the boring details of
software security theory out of the discussion as much as possible to concentrate
on practical applied software security for practical people.
This is as much a book for your personal benefit as it is for your organization’s benefit. Professionals who are skilled in secure and resilient software
development and related tasks are in tremendous and growing demand, and
the market will remain that way for the foreseeable future. As you integrate
these ideas into your daily duties, your value increases to your company, your
management, your community, and your industry.
Secure, Resilient, and Agile Software Development was written with the following people in mind:
• AppSec architects and program managers in information security organizations
• Enterprise architecture teams with application development focus
• Scrum teams
○ Scrum masters
○ Engineers/developers
xvii
xviii
Secure, Resilient, and Agile Software Development
○ Analysts
○ Architects
○ Testers
•
•
•
•
•
•
DevOps teams
Product owners and their management
Project managers
Application security auditors
Agile coaches and trainers
Instructors and trainers in academia and private organizations
How This Book Is Organized
• Chapter 1 brings the state of software development up to date after the tsunami
of changes that have flipped software development and application security
practices on their head since 2010, when I co-authored Secure and Resilient Software: Requirements, Test Cases, and Testing Methods.
• Chapter 2 takes a detailed look at the Agile and Scrum software development
methodology to explore how security controls need to change in light of an
entirely new paradigm on how software is developed and how software is used.
• Chapter 3 focuses on ways to educate everyone who has a hand in any software
development project with appropriate and practical skills to Build Security In.
We look at ways of influencing development teams to espouse software security
in their day-to-day activities, establishing a role-based curriculum for everyone,
suggestions on how to roll out training, and ways to “keep the drumbeat alive”
all year long through outreach and events.
• Chapters 4 looks at the specification steps of new or altered software with ways
to incorporate security controls and other nonfunctional requirements (NRFs)
into user stories that bring to life the concepts of “shift left” and Building Security In. This chapter examines 15 families of nonfunctional requirements and 11
families of application security controls.
• Chapter 5 moves into foundational and fundamental principles for secure application design. It covers important concepts, techniques, and design goals to meet
well-understood acceptance criteria on features an application must implement.
• Chapter 6 examines how the design sprint is adapted for proper consideration of
security and other NFRs and ways to conduct threat modeling, application risk
analysis, and practical remediation while the design is still malleable.
• Chapter 7 on defensive programming includes information on the Common
Weaknesses Enumeration (CWE™), the OWASP Top 10 (2017), and some ways
to address the fundamental scourge of application security vulnerabilities—failure
to sanitize inputs.
• Chapter 8 is focused on white box application analysis with sprint-based activities to improve security and quality of an application under development. Static
code analysis is covered in depth for context on what these tools do and the
assumptions they use for operating.
Preface xix
• Chapter 9 looks at black box or grey box analysis techniques and tools for testing
a running version of an application for software or quality shortcomings.
• Chapter 10 is focused on techniques and activities to help transform the DevOps
process into a DevSecOps process with appropriate controls, metrics, and monitoring processes.
• Chapter 11 looks at two popular software maturity and metrics models for helping you determine the effectiveness and maturity of your secure development
program.
• Chapter 12 takes a survey of the frontier in which software use is expanding.
It covers topics including the Internet of Things (IoT), AI, machine learning,
blockchains, microservices, APIs, containers, and more.
• Chapter 13 closes the book with a call to action to help you gain access to education, certification programs, and industry initiatives to which you can contribute.
Each chapter logically builds on prior chapters to help you paint a complete
picture of what’s required for secure, resilient, and Agile application software
as you learn how to implement environment-specific, effective controls and
management processes that will make you the envy of your peers!
About the Author
Mark S. Merkow, CISSP, CISM, CSSLP, works at WageWorks in Tempe,
Arizona, leading application security architecture and engineering efforts in the
office of the CISO. Mark has over 40 years of experience in IT in a variety
of roles, including application development, systems analysis and design, security engineering, and security management. Mark holds a Master of Science
in Decision and Information Systems from Arizona State University (ASU),
a Master of Education in Distance Education from ASU, and a Bachelor of
Science in Computer Information Systems from ASU. In addition to his day
job, Mark engages in a number of extracurricular activities, including consulting, course development, online course instruction, and book writing.
Mark has authored or co-authored 17 books on IT and has been a contributing editor to four others. Mark remains very active in the information security
community, working in a variety of volunteer roles for the Phoenix Chapter
of (ISC)2®, ISACA®, and OWASP. You can find Mark’s LinkedIn® profile at:
linkedin.com/in/markmerkow
xxi
Chapter 1
Today’s Software
Development Practices
Shatter Old Security
Practices
In the decade since Secure and Resilient Software: Requirements, Test Cases, and
Testing Methods1 was published, the world of software development has flipped
on its head, shed practices from the past, brought about countless changes,
and revolutionized how software is designed, developed, maintained, operated, and managed.
These changes crept in slowly at first, then gained momentum and have
since overtaken most of what we “know” about software development and the
security tried-and-true methods that we’ve relied on and implemented over the
years. Involvement from application security (appsec) professionals—if they
happened at all—happened WAY too late, before executive decisions were
already made to supplant old practices and the ink was already dried on contracts with companies hired to make the change.
This late (or nonexistent) involvement in planning how to address security
hobbles appsec practitioners who are forced to bargain, barter, or somehow convince development teams that they simply cannot ignore security. Compound
this problem with the nonstop pace of change, and appsec professionals must
abandon old “ways” and try to adapt controls to a moving target. Furthermore,
the risks with all-new attack surfaces (such as autonomous vehicles), reliance on
1
2 Secure, Resilient, and Agile Software Development
the Internet of Things (IoT), and software that comes to life with kinetic activity can place actual human lives in real danger of injury or death.
Although we may have less work on our hands to convince people that
insecure software is a clear and present danger, appsec professionals have to
work much harder to get everyone on board to apply best practices that we are
confident will work.
A decade ago, we were striving to help appsec professionals to convince
development organizations to—minimally—address software security in every
phase of development, and for the most part over the decade, we saw that far
more attention is being paid to appsec within the software development lifecycle
(SDLC), but now we’re forced to adapt how we do things to new processes that
may be resistant to any changes that slow things down, while the risks and
impacts of defective software increase exponentially.
Here’s the definition of software resilience that we’ll use throughout the
book. This definition is an adaptation of the National Infrastructure Advisory
Council (NIAC) definition of infrastructure resilience:
Software resilience is the ability to reduce the magnitude and/or duration of
disruptive events. The effectiveness of a resilient application or infrastructure
software depends upon its ability to anticipate, absorb, adapt to, and/or
rapidly recover from a potentially disruptive event.2
In this chapter, we’re going to survey this new landscape for these changes to
update our own models on how to adapt to the Brave New World and maintain
software security, resilience, and agility.
1.1 Over the Waterfall
New paradigms have rapidly replaced the Waterfall model of software development that we’ve used since the beginning of the software age. Agile and Scrum
SDLCs have all but displaced the rigorous (and sometime onerous) activities,
and most certainly displaced the notion of “phase containment,” which appsec
professionals have counted on as a reliable means to prevent defects from creeping into subsequent phases.
This new landscape includes Agile/Scrum, DevOps, continuous integration/
deployment (CI/CD), and the newest revolution working its way in, site reliability engineering (SRE). To adapt to these changes, we need to understand
how the rigor we’ve put into Waterfall-based projects and processes has been
swept away by the tsunami of change that demands more software, faster and
cheaper.
Today’s Software Development Practices Shatter Old Security Practices 3
Changes in the software development paradigm forces change in the software security paradigm, which MUST work hand-in-hand with what development teams are expected to do. While we typically had a shot at inspecting
software for security issues at the end of the development cycle (because of
phase containment), this control point no longer exists. The new paradigm we