Software Development Methodologies

Note the emphasis in this definition on this being a managed set of activities. As with any human or organizational activity (including information security projects!), software development must balance satisfying those needs against the time available for development, and the money and other resources that the development requires.

Many different such methodologies have been created and adopted for widespread use, only to either fall out of favor in the marketplace or give birth to a next-generation vision of the next "best" methodology.

All systems, large or small, have a lifecycle of their own. This lifecycle starts with the first conceptual notions about the need, and runs through design and build, into deployment and operational use, and finally ends when the system is withdrawn from operational use and retired, disposed of, or just abandoned.

Security has the opportunity to be present throughout. Security can and should have a vital role to play in the choice of formal management methodology, and then move into the details of each step of each phase of the operational use of that methodology.

Organizations need to choose methodologies carefully, as the model chosen should be based on the requirements of the organization.

As with any other project, understanding the requirements ahead of time is paramount for the success of the project itself. For example, some models work better with long-term, complex projects, while others are more suited for short-term projects.

However, the key point is not that a formalized SDLC needs to be utilized, but that the entire development process needs to involve security.

The best security is always what is designed into the system, not what is added later. From that perspective, the number and nature of the phases of any given methodology aren't of primary importance.

Fast, Lean Development Methods

In this model, an application is built from already existing and tested components.

The reuse model is best suited for projects using object-oriented development because objects can be created, exported, reused, or modified as required.

From a security perspective, the components would then be chosen based on the known effectiveness of the security characteristics.

Reuse is perhaps the most widely used approach to developing software, although it is often the most poorly managed one as well.

Spiral method

A nested version of the original waterfall method, the development of each phase is carefully designed using the waterfall model, but the distinguishing feature of the spiral model is that in each phase we add four sub-stages, based on what is known as the Deming Cycle: Plan, Do, Check, Act (PDCA). Specifically, a risk assessment review (Check) is done at each phase.

The estimated costs to complete and the schedules are revised each time the risk assessment is performed. We can consider this model to be an improvement of the waterfall methodology based on being able to address, at each phase, the results of the risk sub-phase assessment. At this point, a decision is made to continue or cancel the project.

Prototyping

In prototyping, the objective is to build a simplified version of the entire application, release it for review, and use the feedback from the stakeholders to review to build a second, much better version. This is repeated until the owner and stakeholders are satisfied with the final product.

Prototyping is broken down into a step-bystep process that includes initial concept, design and implementation of initial prototype, refining the prototype until acceptable to the owner, and complete and release final version.

Modified prototype model (MPM)

A refined form of the above prototyping methodology that is ideal for web application development, MPM allows for the basic functionality of a desired system or component to be formally deployed in a quick time frame. The maintenance phase is set to begin after the deployment.

The goal is to have the process be flexible enough so that the application is not based on the state of the organization at any given time. As the organization grows and the environment changes, the application evolves with it rather than being frozen in time.

Cleanroom

This methodology is focused on controlling and, at best, avoiding defects and bugs in the software. The emphasis is to write the code correctly the first time rather than trying to find the problems once they are already there and trying to address them later.

Essentially, cleanroom software development focuses on defect prevention rather than defect removal. To allow this to happen, more time is spent in the early phases, focusing heavily on the assumption that the time spent in other phases, such as testing, is theoretically reduced.

The basic premise, therefore, is that quality is achieved through proper design rather than testing and remediation later.

In terms of security, the same pattern applies, if risk considerations are addressed up front, security becomes an integral part of the system as a design rather than adding it later. This is always preferred as far as security is concerned. Security should always be designed into the system based on requirements rather than being retrofitted later.

Extreme programming

This discipline of software development is based on having several values and characteristics of software development. The values are simplicity, communication, and feedback all combined into the process. Despite the name, extreme programming is an attempt to use a structured approach to software development, relying on subprojects of limited and defined scope and developers always working in pairs. The team produces the software in a series of small, fully integrated releases that are supposed to fulfill the owner-defined needs.

Agile development

As development teams grow and as the set of users and managers they must interact with grows), it becomes harder to deal with changing or evolving requirements and deliver responsive, resilient systems and applications. Agile development focuses on small team environments and focuses on collaborative, iterative learning, building, testing, and deployment of capabilities to operational use.

This implies that the owners need to be involved in defining the needs in the first place. It makes sense, as well, to involve security in defining those needs ahead of the developers programming the requirements. As we have mentioned earlier, this model relies on simplicity of the process, communication between all involved stakeholders, including security, and feedback to ensure requirements are addressed properly.

Agile development follows patterns of activities such as "scrum," "sprint," or "safe" to manage change and develop and deploy working, reliable, and verifiable function.

Agile development, as with other development methods, can be a great way to deal with security considerations long as the agile team works with information security experts effectively.

Devops

As the two words combined imply, DevOps is a combining of development and operations. DevOps typically also involves the quality assurance processes of the organization. DevOps can be summarized as an approach based on lean and agile principles in which business owners and the development, operations, and quality assurance departments collaborate and work together to deliver software in a continuous manner that enables the business to more quickly react to market opportunities and reduce the time to include customer feedback into products that need to be developed.

At the same time that DevOps was beginning to be explored, popularized, and put into practice, development organizations that needed to answer more stringent security and safety requirements through the software systems that they built pushed for a different approach. SecOps was coined as a term to take the lessons learned from the classic waterfall model's approach and integrate security activities into every step of the process.

But security-conscious systems users and their developers saw that DevOps had prioritized the rapid delivery of new versions of the software baseline over anything else; security, safety, and resilient operational characteristics would often take a lower priority in DevOps approaches.

SecOps might deliver more secure code, by dealing with security requirements at every stage of its process model, but it took longer to do so.

DevSecOps merges these two process models, in effect moving the leverage that security requirements can have on the project to the left on the timeline. This provides for earlier opportunities, at each turn of the DevSecOps development cycle, to ensure that the highest priority security needs are being addressed in the product that will be delivered to operational (or production) use by that cycle's overall efforts.

Key to the DevSecOps model is making the development team, which should have security members in it, responsible for security testing and for resolution of security issues found during development and testing.