Development life cycle

There are four stages to the development life cycle, each with their own range of tasks that need to be completed in order to produce a secure and efficient end product.  

Before we delve in, think about the development life cycle of a product you like or know. What kind of stages do you think it had to go through before it was deemed 'ready' for market?

Figure 1: Development life cycle

System design and security  

The first stage in any development life cycle is design, but before you put pen to paper, you should consult with stakeholders to ensure the end-product will meet the business and security needs it’s designed for. It’s worth noting that most of the security requirements will originate from the development technologies being used, and the environment the system will run in. 

Outlining the business and security needs upfront gives you the principles to build a great solution and the testing boundaries for your system design. Comparing the solution against the business needs in early testing will confirm that it delivers according to the original specified requirements. This will also help to reduce changes later on in the process when it’s harder to redesign.

These requirements should examine questions such as:

• What type of data will the system handle?
• How sensitive is it?
• Who will need access to it?
• Does it need to be encrypted?
• What laws and regulations apply?

Defining these questions early on will go a long way to ensuring the finished product meets expectations.

Changes may be reduced, but it’s inevitable that some change requests will arise. At this point you must emphasise that changing user requirements can lead to security concerns.

Any changes need to be agreed through the change control and stakeholder management processes with the Information Security Manager closely involved. 

The Information Security Manager is a crucial player throughout the entire development life cycle, and will be responsible for:  

• Securing comprehensive security tests during the testing phase.  
• Ensuring the developers and project managers don’t skip security features due to cost or complexity without notifying and getting sign-off from the stakeholders.   
• Monitoring the end-to-end development processes and encouraging developers to adopt a ‘Secure by Design’ approach to coding, including appropriate methods for validation, backup and restoration of data.
• Meeting the legal, auditing and accounting requirements relating to the product being secure and compliant.  

Development release process 

Once development is complete, the development release process is activated. This controls how and when your solution can move from the development to test environment.  

Note that various documents accompany each release package, including:   

• Installation instructions 
• The application resource specification 
• The test plans 

The process runs like this: 

• After the paperwork, i.e., the installation instructions, is validated by the testing team, the tester will install the application and the system testing process can begin.  Defects are recorded and returned to the developer for fixing and re-testing. 
• Once the testing is complete, the test report details all the tests that have been carried out and states whether the system passed or failed.  This report is a useful blueprint to use as your checklist of areas to improve. Be sure to share it amongst the relevant team members involved in development when the test cycle begins again. 

Now, it's time to take a look at testing in more detail.  

Acceptance testing  

Once your system is developed, it’s time for user acceptance testing (UAT). This normally consists of functionality testing, user testing, where users run typical workflow tests to ensure they can perform their jobs confidently, and finally, accreditation testing.

Irrespective of whether the new system is a commercial off-the-shelf solution (CoTS), one that was bought from an external vendor, like Microsoft or Adobe, or developed in-house, the acceptance process is still required.

The underlying infrastructure and functionality of the product should be validated against the CIA Triad criteria of confidentiality, integrity and availability. This is a fundamental risk management process and should be carried out by the Information Security Team during the early design phase.

The amount of testing time and effort should be defined by the initial product risk assessment, also created as part of the system design phase. For example, if the product has an initial software assurance rating of EAL4+, it can be trusted more than an open-source application downloaded from a website, and therefore needs less testing time.

System testing

All new systems contain defects, it’s simply not realistic to expect the system to be error-free straight from the developers. The purpose of the testing and validation stages of deployment are designed to find these errors and fix them prior to release, and to provide assurance that the software works correctly. The testing process is decided in advance to ensure that most effort is assigned to the most critical elements of the system, the test report is a checklist of things to improve.

By ensuring the development, test and live environments are physically separated, the system can be tested without exposing the live operational environment to malware or bugs during the development process. However, if the development environment is built on virtualised servers and workstations, it’s easy to roll back or rebuild it if things go wrong, which is something worth remembering if bugs do slip through.   

The test environment is where test users, penetration testers and system administrators validate that the development requirements have been met, and that the system is secure. As much as possible, it should be a replica of the production environment and be maintained as close as possible to the final build. If budget permits, it should also replicate the production system network topology.   

Some organisations also run an additional staging environment which is completely representative of the user environment. This enables 100% accurate like-for-like testing before the system is deployed.

One thing to remember about test environments is that, while they’re vital to a smooth and secure deployment, they can sap resources. The more development and testing environments you have, the more management time, IT and maintenance costs (as well as patching and update work) you will require.

So, the decision on the types of testing environments must involve stakeholders and appropriate business managers.

What’s next? 

Remember the list of steps you thought were included in the development life cycle? Was there anything included here that you hadn’t thought of? If so, make a note so you can plug that knowledge gap and take your new tools forward with you.  

Now you know more about the four main stages to the development life cycle, next up you’ll learn about third-party product risks. We mentioned Microsoft and Adobe briefly here, so let’s build on that knowledge now.