Figure 2.13 Scrum software development methodology.
The Secure Development Lifecycle 55
represented. In contrast to traditional planned or predictive methodolo-
gies, this concept facilitates the ability to handle churn resulting from
customers that change the requirements during project development. The
basic unit of development for Scrum is called a “sprint,” and a sprint
can last from one week to one month. Each sprint is time-boxed so that
finished portions of a product are completed on time. A prioritized list
of requirements is derived from the product backlog, and if they are not
completed during the sprint, they are left out and returned to the product
backlog. The team demonstrates the software after each sprint is com-
pleted. Generally accepted value-added attributes of Scrum include its
use of adaptive planning; that it requires feedback from working soft-
ware early during the first sprint (typically two weeks) and often; that it
stresses the maximization of good change such as focusing on maximiz-
ing learning throughout the project; that it puts most responsibility on
small, dedicated tight-thinking adaptive teams that plan and re-plan their
own work; that it has strong and frequent controls; optimizes business
value, time to market, and quality; and supports realization of value ear-
lier, potentially after every sprint.
2.10.2.2 Lean Development
In our experience, for those of you who have recently moved from or
are in the process of moving from a Waterfall methodology for software
development, Scrum is the most likely variant of Agile that you will
encounter. Lean (see Figure 2.14) is another methodology that is gaining
Figure 2.14 Lean software development methodology.
Plan
Build
Plan
Build
Plan
Build
Plan
Build
Plan
Build
Plan
Build
Plan
Build
Plan
Build
Test
Review
Test
Review
Test
Review
Test
Review
Test
Review
Test
Review
Test
Review
Test
Review
56 Core Software Security
popularity and is thus worth mentioning. Unfortunately, there are many
definitions of Lean, and it is a methodology that is evolving in many
directions. Although Lean is similar to Scrum in that it focuses on fea-
tures rather than groups of features, it takes this idea one step further in
that, in its simplest form, you select, plan, develop, test, and deploy one
feature before you select, plan, develop, test, and deploy the next feature.
The objective is to further isolate risk to the level of an individual fea-
ture. This isolation has the advantage of focusing on eliminating “waste”
when possible and doing nothing unless it is absolutely necessary or rel-
evant. Lean development can be summarized by seven principles based on
Lean manufacturing principle concepts: (1) eliminate waste, (3) amplify
learning, (3) decide as late as possible, (4) deliver as fast as possible, (5)
empower the team, (6) build integrity in, and (7) see the whole. One of
the key elements of Lean development is to provide a model where you
can see the whole, even when your developers are scattered across mul-
tiple locations and contractors. Although still considered related to Agile
by many in the community, Lean software development has evolved into
a related discipline rather than a specific subset of Agile.
2.3 Chapter Summary
In this chapter we described the importance and applicability of the SDL
and its relation and inclusion into the SDLC. Throughout the discus-
sion, we highlighted the models, methodologies, tools, human talent, and
metrics for managing and overcoming the challenges to make software
secure. Our SDL process encompasses a series of security-focused activi-
ties and best practices at each of the phases of our SDL. These activities
and best practices include the development of threat models during soft-
ware design, the use of static analysis code-scanning tools during imple-
mentation, and the conduct of code reviews, security testing, and metrics.
Lastly, we discussed our model for mapping the SDL to the SDLC and
the various popular software methodologies to which we will apply the
elements and best practices of our SDL in Chapter 9. In the next chapter,
we will start the process of walking through each step of our SDL model
and show that incremental implementation of the elements the SDL will
yield incremental improvements in an overall holistic approach to soft-
ware security.
The Secure Development Lifecycle 57
References
1. Microsoft Corporation (2012), Graphic for Microsoft SDL. Retrieved from http://
www.microsoft.com/security/sdl/discover/default.aspx.
2. Addison-Wesley (2012), Software Security Series. Graphic for “Build Security
in for Seven Touchpoints for Software Security.” Retrieved from http://www.
buildsecurityin.com/concepts/touchpoints.
3. OWASP (2012), OWASP: The Open Web Application Security Project—
Security Code Review in the SDLC, Secure Code Review Process—
Operational Process. Retrieved from https://www.owasp.org/index.php/
Security_Code_Review_in_the_SDLC.
4. Cisco Systems (2012), Cisco Secure Development Lifecycle (CSDL) Graphics.
Retrieved from http://www.cisco.com/web/about/security/cspo/csdl/index.html.
5. Microsoft Corporation (2012). Microsoft Security Development Lifecycle: The
SDL Optimization Model Graphic. Retrieved from http://www.microsoft.com/
security/sdl/learn/assess.aspx.
6. Microsoft Corporation (2012), “Microsoft SDL Optimization Model.”
Retrieved from http://www.microsoft.com/download/en/details.aspx?displaylang
=en&id=2830.
7. Bsimm.com (2012), Building Security in Maturity Model.pdf. Graphic for the
BSIMM Software Security Framework (SSF), p. 24. Retrieved from bsimm.com/
download/dl.php.
8. OWASP (2012), “Software Assurance Maturity Model (SAMM).”
Retrieved from https://www.owasp.org/index.php/Software_Assurance_Maturity_
Model_(SAMM).
9. Businesswire.com (2012), “BSIMM4 Release Expands Software Security
Measurement Tool and Describes New Activities.” Retrieved from http://
www.businesswire.com/news/home/20120918005298/en/BSIMM4-Release-
Expands-Software-Security-Measurement-Tool.
10. Ibid.
11. OWASP (2012), “Software Assurance Maturity Model (SAMM).”
Retrieved from https://www.owasp.org/index.php/Software_Assurance_Maturity_
Model_(SAMM).
12. ISO (2013), “ISO/IEC 27034-1:201: Information Technology—Security
Techniques—Application Security—Part 1: Overview and Concepts.” Retrieved
from http://www.iso.org/iso/catalogue_detail.htm?csnumber=44378.
13. Pickel, J. (May 2013), “ISO/IEC 27034—Why, What, and How.” PowerPoint
presentation at the 2013 Microsoft Software Development Conference, delivered
on ebruary 25, 2013, San Francisco, CA.
14. Ashord, W. (May 13, 2013), “Microsoft Declares Conformance with ISO 27034.”
Computer Weekly.Com. Retrieved from http://www.computerweekly.com/
news/2240184149/Microsoft-declares-conformance-with-ISO-27034-1.
15. SAFECode (2012), SAFECode “About Us” webpage. Retrieved from http://www.
safecode.org/about_us.php.
58 Core Software Security
16. SAFECode (2011), Fundamental Practices for Secure Software Development, 2nd
ed., A Guide to the Most Effective Secure Development Practices in Use Today,
February 8, 2011. Retrieved from www.safecode.org/publications/SAFECode_
Dev_Practices0211.pdf.
17. U.S. Department of Homeland Security (2012), “Build Security In.” Retrieved
from https://buildsecurityin.us-cert.gov/bsi/home.html.
18. U.S. Department of Homeland Security (2012), “Background: Department
of Homeland Security (DHS) National Cyber Security Division’s (NCSD).”
Retrieved from https://buildsecurityin.us-cert.gov/swa/cwe/background.html.
19. U.S. Department of Homeland Security (2012), “Software Assurance:
Community Resources and Information Clearinghouse.” Retrieved from https://
buildsecurityin.us-cert.gov/swa/cwe.
20. U.S. National Institute of Standards and Technology (2012), “Introduction to
SAMATE.” Retrieved from http://samate.nist.gov/index.php/Introduction_to_
SAMATE.html.
21. U.S. National Institute of Standards and Technology (2008), NIST Special
Publication 800-64, Revision 2: Security Considerations in the System Development
Life Cycle, October 2008. Retrieved from http://csrc.nist.gov/publications/
nistpubs/800-64-Rev2/SP800-64-Revision2.pdf.
22. U.S. National Institute of Standards and Technology (2012), National Vulnerability
Database, Version 2.2. Retrieved from http://nvd.nist.gov.
23. U.S. National Institute of Standards and Technology (2012), “NVD Common
Vulnerability Scoring System Support v2.” Retrieved from http://nvd.nist.gov/
cvss.cfm?version=2.
24. MITRE Corporation (2012), Common Vulnerabilities and Exposures (CVE)
homepage. Retrieved from http://cve.mitre.org.
25. MITRE Corporation (2012), “CVE Frequently Asked Questions.” Retrieved from
http://cve.mitre.org/about/faqs.html.
26. SANS Institute (2012), “Twenty Critical Security Controls for Effective Cyber
Defense: Consensus Audit Guidelines.” Retrieved from http://www.sans.org/
critical-security-controls.
27. MITRE Corporation (2012), “CVE-Compatible Products and Services.” Retrieved
from http://cve.mitre.org/compatible/compatible.html.
28. MITRE Corporation (2012), “CVE Frequently Asked Questions.” Retrieved from
http://cve.mitre.org/about/faqs.html.
29. U.S. Department of Defense Cyber Security and Information Systems Information
Analysis Center (CSIAC) (2012), CSIAC webpage. Retrieved from https://www.
thecsiac.com/group/csiac.
30. Goertzel, K., et al., for Department of Homeland Security and Department of
Defense Data and Analysis Center for Software (2008), Enhancing the Development
Life Cycle to Produce Secure Software: A Reference Guidebook on Software Assurance,
Version 2, October 2008. Retrieved from https://www.thedacs.com/techs/
enhanced_life_cycles.
31. Goertzel, K., et al. (2008), Software Security Assurance: State-of-the-Art Report
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.