Secure Development - Lifecycle Models

In this article, we cover the lifecycle models used by project management to direct the development process.

Established engineering disciplines (such as electrical or mechanical) often state that software engineering is not an engineering discipline at all.

They contend that software engineering is a combination of chaotic processes that sometimes manages to create a workable solution. It might not be fair to compare age-old disciplines to those of an industry that’s only a few decades old.

However, the adoption of formalized lifecycle management processes in software development can help to mature the application engineering discipline. Stakeholders often employ project management to implement those lifecycle models and keep development projects on target towards a refined product.

workplace

Development frameworks have several activities in common. The names are not necessarily consistent in each model, but the following core activities are essential to the sound development of a system:

Conceptual Definition

This phase of development involves creating the basic concept statement for a system or application. In this very high-level contract, all interested stakeholders agree to the purpose of a project as well as the general requirements.

During all phases of the development process, the concept statement should be referred to in order to avoid getting lost in the details.

Functional Requirements

Once all stakeholders have agreed on the concept, it’s time to start the functional requirement phase. Specific functionalities are listed and how deliverables from the development phase meet these requirements. The three major characteristics of a functional requirement are:

Input The data provided to a function

Behavior The business logic describing what actions the system should take in response to the input

Output The data provided from a function

It’s again very important that all stakeholders agree on the functional requirements document before progressing. The document is used as a checklist to ensure all functional requirements in the testing and evaluation stages.

Security Requirements

Organizations have to ensure that adequate security controls are designed into every system. It’s therefore essential to have the definition of such control specifications in the product development lifecycle.

With the conceptual definition and the functional requirements, the security engineers can analyze the system from their perspective.

Threat modeling on public entry points and the trust boundaries is a great practice to surface the risks to the system. The product team can then mitigate those threats by implementing appropriate measures.

All too often, systems are designed without security planning, and then developers try to retrofit the system with security enhancements. These afterthought improvements do often not fully integrate with the system’s design and can leave gaping vulnerabilities.

Security requirements have to be revisited whenever a significant change is made to the design specifications.

Design Review

With the functional and security specifications, the system designers can start doing their thing. The designers determine exactly how the various parts of the system will interoperate and how the system structure will be laid out.

Once the formal design document is finished, a review meeting will usually be held where all stakeholders ensure that everyone is in agreement with the desired functionality and security.

Code Review

With the blessing of the stakeholders, the software developers can start writing code. Code reviews at various milestones throughout the coding process will ensure that flaws in the code or problems with the data flow are avoided.

Code reviews are an instrumental tool in ensuring that the code produced by development teams perform according to specifications.

Acceptance Testing

Once the developer wrote the final lines of code and declares the system as complete (is a system ever complete?), it’s time to begin the acceptance testing phase.

Initial testing should seek for obvious errors and as the testing progresses more detailed input is provided to simulate predefined scenarios. A copy of the test plan and the results has to be kept for future review.

Once this phase is complete, the application can be deployed

Maintenance and Change Management

With the system being operational, a range of maintenance tasks is required to ensure stable operation in the face of real user traffic. At this point, the operations team will ensure the observability and reliability of the application and support the developers in optimizing the product.

Once in production, any changes to the code are handled by a formalized change management process to ensure availability, confidentiality, and integrity.

Lifecycle Models in Detail

In the following sections, we’ll take a look at several specific software development lifecycles. All these frameworks are meant to improve the resulting products.

Waterfall Model

Developed in the 1970s this model seeks to view the development lifecycle as a series of sequential activities. Traditionally the framework has six stages of development.

System Requirements & Software Requirements -> Analysis -> Design -> Code & Debug -> Testing -> Operations & Maintenance

The modern approach of the waterfall model also allows returning to previous phases to correct defects. This framework was one of the first comprehensive attempts to structure the development process.

Waterfall Summary

Spiral Model

This alternative lifecycle model allows for multiple iterations of the waterfall process. Each loop of the spiral results in the development of a new system prototype. This metamodel provides a solution for the major criticism of the waterfall model - it allows developers to return to the planning stages as requirements change.

Agile Software Development

Agile software development has seen increasing adoption in the last years. The framework is not built on a rigid model but rather emphasizes certain principles.

Individuals and interaction over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Agile software development was initially seen as best suitable for non-critical product development and excluded from use in domains such as medical devices, financial, nuclear systems, and avionics, etc.

However, there have been initiatives to adopt agile to match key concerns in the following areas:

Quality Assurance Systematic and inherent quality management underpinning a controlled professional process and reliability and correctness of product

Safety and security Formal planning and risk management to mitigate safety risks for users and securely protecting users from unintentional and malicious misuse

Traceability Documentation providing auditable evidence of regulatory compliance and facilitating traceability and investigation of problems

Recap

Management models in application development support the software industry to mature and close the gap with established engineering disciplines. It’s important to constantly verify the adequacy of a framework to prevent failure in meeting business requirements.

The involvement of security experts during the phases of the lifecycle will support the creation of a product that has security embedded.