Test-driven development (TDD)
Test-driven development (TDD) is a software development process where code-level testing, also known as unit testing, guides software design and implementation. It is based on the repetition of an extremely short development cycle: write a test, run tests, write code, run tests until it passes, refactor, then repeat.
TDD has the following steps:
- Add a test.
- Run all tests and see if the new test fail.
- Write the code.
- Run all the tests.
- Refactor the code.
This cycle of writing the test first, running the test, and then writing the code may seem strange at first glance. How do you know what test to write when you haven’t writ- ten the code yet? TDD uses unit tests as stepping stones for incremental design. Similar to how the requirements drive software design, by this philosophy the requirements drive the test design, which then acts as an incremental target state for small units of code to achieve.
When followed correctly, the benefits of TDD are significant. Throughout the development process, all code will have tests and will be tested. The body of tests created for TDD are run each time new tests and code are developed, acting like an incremental regression test. Contemplate the implications of this through a security lens. All code changes made with TDD are tested both for their own functionality as well as for the functionality of the whole codebase of which they are a part. This naturally leads to fewer flaws and defects in the software.
Tests can be added to verify code-level security controls. These security control tests and the results of their execution can be used as material for contributing to a security control verification process. By providing evidence of code-level control verification, TDD can benefit organizations with regulatory and compliance requirements for controls.
Because each code change in TDD is small, incremental, and tested, developers can produce higher-quality software code more quickly. TDD can help developers find defects, bugs, and vulnerabilities much earlier than they otherwise would. Despite the additional testing code to be written, TDD has a positive impact on development velocity.
TDD requires discipline, however. TDD requires up-front time and effort investments in additional test code writing, which can make development feel slow. Oversimplification of design can lead to significant refactoring requirements.
Tests become part of the maintenance overhead of a project. Poorly written tests, for example ones that include hard-coded error strings or are themselves prone to failure, are expensive to maintain. Tests need to be routinely evaluated for their correctness.
If the software design changes rapidly, you’ll need to keep adding and changing your tests. You could end up wasting a lot of time writing tests for features that are quickly dropped.
TDD is designed to work with small to large organizations. Exercising TDD on large, challenging systems requires a modular architecture, distinct components with published interfaces, and disciplined system layering with maximization of platform independence. These proven practices yield increased testability and facilitate the application of build and test automation.
TDD is a method that is sure to improve code quality. It requires up-front investment and discipline and doesn’t necessarily work for every type of project, but it is a methodology that can improve the quality and security of an organization’s software development practice.
lean software development
Building commercial software is an experience that is based on best guesses and one that is riddled with expensive mistakes. Agile methodologies were presented to improve this situation through empirical and adaptive means. One significant source of expensive mistakes in software development is waste. Building the wrong thing, basing the build on the wrong requirements, or producing something the market does not need or want are all wastes. Low-quality software engineering, done in haste or incompletely, is waste. Over- looking security as a necessary product capability is a waste that brings unknown future consequences and damages. Waste in software development needs to be eliminated. This is where lean software development works.
Lean software development has its roots in the lean manufacturing principles and practices of the Toyota Manufacturing Process. The principles and practices of the Toyota Manufacturing Process are based on eliminating three kinds of deterrents to an efficient production system: overburden, inconsistency, and waste.
Eliminating overburden is achieved by a realistic standardization of the workflow. Inconsistency in this system is eliminated by a “just-in-time” pull system for parts that stops manufacturing to fix defects in the process at the time of discovery. Waste is eliminated by recognizing it by type and efficiently dealing with it.
The waste of making defective products perhaps is the most harmful waste in soft- ware development. Not engineering security into the product is by outcome creating a defective product. Lean manufacturing principles and practices inspired lean software development to fix these wastes. Lean software development is an adaptation of that process with its principles and practices.
The lean software development principles are as follows:
- Eliminate waste.
- Amplify learning.
- Decide as late as possible.
- Deliver as quickly as possible.
- Empower the team.
- Build integrity in.
- See the whole.
Lean thinking has to be understood well by all members of a project before implementing in a concrete, real-life situation. “Think big, act small, fail fast, learn rapidly” are slogans that summarize lean principles along the whole software development process.
Only when all of the lean principles are implemented together, combined with strong “common sense” concerning the working environment and an emphasis on security, is there a basis for success in software development.
Success in lean software development depends on the team’s discipline and practices.
A great deal of responsibility and flexibility is given over to the team. The team must strive for technical and security excellence to achieve secure working software development. As a security professional, you need to focus the team on building the necessary security capabilities into the product.
Minimum viable product (MVP)
Minimum viable product (MVP) is a product and development style that produces just enough features to satisfy early customers and enough to provide feedback for directing future product development. The primary driver of MVP is to learn and adapt a product to meet market needs through small and incremental hypothesis testing and feedback on your product without fully developing it. This gets the right product feature set to market faster and cheaper, or not at all if the MVP shows no market interest. The process reduces wastes of time, money, and development effort on undesirable features. MVP is an iterative, data-driven approach that relies on many of the facilities of agile methods to produce, test, validate, and direct the minimum viable product.
Security must be a consideration in MVP. Security controls and secure coding practice may be overlooked in MVP for the sake of delivering customer-oriented features. As a security professional, it is crucial that you identify and communicate the necessary secure coding practices, security frameworks, and controls required for a safe and secure MVP. Don’t let MVP become “minimum viable functionality” without security.
When keeping security in mind as part of MVP, the MVP process becomes a security advantage. One of the MVP process’s security advantages is the adaptability it encourages. If there is an error or some development that does not meet a market need, it can be corrected quickly and at any time in the project.
Standards and Practices
A security professional should be familiar with the standards and practices that apply to securing the SDLC. There is a range of SDLC standards, each with its own set of phases.
Because of the variety of standards and their differences, there are a couple of things you should keep in mind. First, in relationship to the CISSP, you should know the vendor-neutral standards. As a security professional, you should know the general lifecycle phases that cover complete, end-to-end security of the SDLC. For this, consider using the standards guidance that best meets the needs of your organization.
The following sections explore ISO/IEC and NIST standards, as well as the process of the Microsoft Security Development Lifecycle (SDL).
ISO/IEC 27034:2011+, “Information Technology – Security Techniques – Application Security”
The ISO/IEC standards offer the security practitioner guidance on many aspects of information security. This standard, “ISO/IEC 27034:2011+ Information technology – Security techniques – Application security,” describes how to integrate application security into an SDLC. It presents a process-oriented approach intended to work generally with any SDLC methodology.
This standard has seven parts, each one addressing a particular aspect of application security. Part 1 of this standard, “Information technology – Security techniques – Application security – Overview and concepts,” sets the foundation for the standard and defines its overall use as general guidance for application security. Application security is described as a process that can be used to select, set, and manage controls to manage application risks. It defines terms and describes concepts, principles, and processes for subsequent parts of the standard.
Part 2 of this standard, “Information technology – Security techniques – Application security – Organization normative framework,” proposes a structure to maintain and orchestrate the elements of application security in a manner that enables an organization to best adapt it to their needs. This Organization Normative Framework (ONF) describes the processes required for application security and the relationships among these security processes. It is a guide for an organization to create and manage its own ONF. Its structure is best suited for organizations with a need for a more formalized application security management.
Part 3 of this standard, “Information technology – Security techniques – Application security – Application security management process,” describes an application security management process that uses the ONF to tailor security management for specific applications.
Part 4 of this standard is titled “ISO/IEC 27034-4 – Information technology – Security techniques – Application security – Application security validation (draft).” When this draft is complete, it will describe a validation and certification process for application security. The standard defines a concept called levels of trust to describe an application’s risk and control profile. In a validation and certification process, an application level of trust can be used to measure and compare an application’s risk and control requirements against an application’s actual risk and control profile as determined by an audit.
Part 5 of this standard, “ISO/IEC 27034-5:2017 – Information technology – Security techniques – Application security – Protocols and application security control data structure,” defines a data structure known as the Application Security Control (ASC). The ASC data structure serves as a basis for the description and communication of application security control components. This section also describes the Application Security Life Cycle Reference Model.
Part 6 of this standard, “ISO/IEC 27034-6:2016 – Information technology – Security techniques – Application security – Case studies,” gives examples on how to use Application Security Controls in the software development process.
Part 7 of this standard, “ISO/IEC 27034-7:2018 – Information technology – Security techniques – Application security – Assurance prediction framework,” focuses on a frame- work to determine what the standard calls the security predictability of an application based on various security-impacting aspects related to its realization and usage.
For more information on ISO/IEC 27034:2011+, “Information technology – Security techniques – Application security,” see http://iso27001security.com/html/27034.html.
ISO/IEC JTC 1/SC7, “Software and Systems Engineering Standards”
The SC7 is a standards subcommittee of the ISO/IEC Joint Technical Committee (JTC) whose focus is on software and systems engineering standards. The ISO/IEC JTC SC7 software and systems engineering standards are an integrated set of software and systems engineering standards that focus on process models and practices to support the full life- cycle of a system. As such, the SC7 set of standards can be considered a reference shelf of standards guidance for software and systems engineering. Some of the standards of inter- est to software security practitioners included in the SC7 domain are ISO/IEC ISO/IEC 12207, “Systems and software engineering – Software lifecycle processes,” 15288:2015, “Systems and Software Engineering – System Life Cycle Processes,” as well ISO/IEC TR 15504 “Information technology – Process assessment.”
ISO 12207-2017
ISO/IEC/IEEE 12207:2017, “Systems and software engineering – Software lifecycle processes,” establishes a common framework for software lifecycle processes. It applies to the full lifecycle of a software system. ISO 12207:2017 provides processes that can be used for defining, controlling, and improving software lifecycle processes within an organization or a project. It can be used by itself or in conjunction with ISO/IEC/IEEE 15288. It describes how to align the activities of participants of the SDLC, including developers, managers, architects, project management, and quality assurance. One of its main goals is to make possible effective communication among these stakeholders. Management and software lifecycle process leadership may refer to this standard for guidance on a framework of processes for a comprehensive organizational software development capability. The security practitioner would use this standard to frame the necessary security activities for each lifecycle, supporting, and organizational process.
ISO/IEC/IEEE 12207:2017 has three process groups:
- Primary lifecycle processes: Acquisition, Supply, Development, Operation, Maintenance, and Destruction
- Supporting lifecycle processes: Audit Process, Configuration Management, Joint Review Process, Documentation Process, Quality Assurance Process, Problem Solving Process, Verification Process, and Validation Process
- Organizational processes: Management Process, Infrastructure Management, Improvement Process, and Training Process
ISO/IEC/IEEE 15288:2015
ISO/IEC/IEEE 15288:2015, “Systems and Software Engineering – System Life Cycle Processes,” is an international standard that establishes a common framework of processes that describe the lifecycle of systems. This framework defines its processes by four different categories: technical, project, agreement, and enterprise. Management and systems process leadership would use this standard as a reference for a (or the) common systems engineering process framework. This standard can be used with ISO/IEC/IEEE 12207:2017, as software lifecycle processes are components of the system engineering lifecycle. A security practitioner would use this standard to understand the process life- cycle of developing complex systems as well as a reference to identify necessary security activities throughout the systems engineering lifecycle.
ISO/IEC TR 15504
ISO/IEC TR 15504, “Information technology – Process assessment,” is a set of standards that serve to describe a reference model for maturity models. This standard can be used as a reference to create or validate a maturity model used to evaluate the software and systems engineering lifecycle processes. The security practitioner can use it as a reference to ensure that consideration of the security activities are included in the capability and maturity assessment of security processes.
NIST SP800-64 Revision 2
NIST Special Publication 800-64, “Revision 2: Security Considerations in the System Development Life Cycle,” is a standard intended to guide the introduction of essential security services into the established system development lifecycle. Although this is a U.S. federal government standard, use of this special publication guidance has many benefits to any organization.
The standard establishes a baseline understanding of cybersecurity and the system development lifecycle. It uses a typical SDLC that includes five phases: initiation, development/acquisition, implementation/assessment, operations/maintenance, and disposal. It describes the major security activities and control gates that apply in general as well as to each SDLC phase.
NIST SP800-64 Revision 2 describes controls, processes, people, and other considerations that help integrate security into each phase of the SDLC. Security controls are assumed to align with the NIST SP800-53 standard. Included in this guidance are the roles and responsibilities of whom to involve in securing each phase.
The “Additional Security Considerations” section of the standard highlights security considerations for development scenarios, such as service-oriented architectures and virtualization, for which the approach to security integration varies somewhat from that of traditional system development efforts.
NIST SP800-64 Revision 2 recommends addressing security vulnerabilities early to lower costs and improve security posture. It also directs attention to areas where security services and strategies can be reused to improve security coverage and reduce development costs. The standard addresses the engineering challenges caused by mandatory security controls. Adding a security emphasis throughout the SDLC improves systems interoperability and integration that would otherwise be hampered by securing systems at various system levels. Comprehensive documentation of security decisions made during development, as well as other phases, improves security integration in the SDLC. Adding security to the SDLC ultimately improves organization and customer confidence.
To read the standard, see https://doi.org/10.6028/NIST.SP.800-64r2.
