Secure Development Process

Developed with


Foundation Certificate in Cyber Security (FCCS)
Personnel Security
PREVIEW11m 23s

The course is part of this learning path

Start course

Course Description 

This course looks at the other facets of security that come into play when thinking about cyber security in generalStarting with physical and personnel security, it then moves into the secure development process, security best practice and ends with an introduction to security architecture.  


Learning Objectives 

The objectives of this course are to provide you with and understanding of: 

  • Physical security - lighting, CCTV, fencing, intrusion detection, screening, destruction, UPS and generators, access and control of entry 
  • People, employees, contractors, customers (resource, vulnerability, threat), recruitment, screening, Social Engineering, Common People Exploits, T&C's, in role, change in role, termination, insider threat, supply chain challenges 
  • Secure by Design, Secure Development Life Cycle (SDLC) 
  • Reduce the attack surface, defense in depth, test security, weaknesses and vulnerabilities, secure coding, learn from mistakes 
  • Security design architecture, enterprise design frameworks (TOGAF, ZACHMAN, SABSA), patterns (NCSC, Open Security Architecture) 


Intended Audience 

This course is ideal for members of cyber security management teams, IT managers, security and systems managers, information asset owners and employees with legal compliance responsibilities. It acts as a foundation for more advanced managerial or technical qualifications. 



There are no specific pre-requisites to study this course, however a basic knowledge of IT, an understanding of the general principles of information technology security, and awareness of the issues involved with security control activity would be advantageous. 



We welcome all feedback and suggestions - please contact us at if you are unsure about where to start or if would like help getting started. 



Welcome to this video on the Secure Development Process for systems. Over the next few minutes you’ll learn about why security needs to be baked in to your system development processes, and ways in which you can achieve this. We will focus on Security weaknesses and vulnerabilities; Security of code repositories; Improving the application development process; The SD3 model and Systems development lifecycle models. 


You are just as likely to bake in security flaws if you fail to bake security in during the system development process. Development of software, particularly complex software, has a large scope for errors. Such errors could include a failure to correctly handle input data, causing buffer overflows or other mis-operations. These are the types of exploits and vulnerabilities that attackers will pounce on. 


A Time of Check/Time of Use vulnerability can occur when an authorization check is made only at the very beginning of a process. Any subsequent revocation of authority can get bypassed as no further checks are made to confirm whether authority still exists. 


Development of complex software also has a large scope for deliberate malicious acts. If the software contains millions of lines of code, it can be very easy to insert malicious code that can provide a Trapdoor or Backdoor, providing access to ‘undocumented features’. 


The use of tools to analyze code can assist with spotting errors, but may not help so much in finding correct code that performs a malicious action. Code development requires a secure storage location. As with any other data storage requirement, there are standard security considerations to consider. 


The repository should be physically secure, as well as secure within the cyber realm.  


The data needs to be protected from damage or deletion, meaning that a system for creating backup copies of the data must exist. Access to the data needs to be strictly controlled so that unplanned or unauthorized alterations cannot be made, and all communications between the repository and the developers must be protected to prevent an attacker interfering with these. 


A security mindset must be endemic throughout the development process. 


The initial planning of any software development process must include an awareness of security, and this should guide the direction taken from the start. The security considerations do not stop after this initial phase. Security must be the highest priority throughout the whole of the development cycle, and even through the deployment phase where the software is being issued to a testing community for checking, or to the user community. 


All software development lifecycle models feature the concept of milestones – particular stages of development that are significant. These provide yet another opportunity to consider security. In summary, security considerations should be at the forefront throughout the entirety of the software development cycle. 


This diagram shows the SD3 Security Framework. 


Using this approach allows developers to consider security throughout the software development lifecycle. The initial phase is Secure by Design and relates to the actual design and initial development of the software. 


Secure by Default relates to designing the software to have the minimum possible exposure to generic threats that may already exist. Removing the need for the software to run using administrative privileges at all times will help ensure that it cannot be used as a pivot point by an attacker to gain administrative access to a system. 


Secure in Deployment shows that the responsibility for security does not end once the software has been issued for wider use. Users need to be given appropriate training in using the software securely, and documentation is needed to describe how the software actually works. 


Let’s expand on the first of the SD3 principles, secure by design. An easy win here is to ensure that the design team are given the correct training and have the correct attitude towards security. Security awareness should be second nature for them, and security should never be an afterthought or put into the ‘too difficult’ pile. 


Software should always aim to achieve its security goals, with these being regarded as a key feature rather than an unnecessary add-on. Define these security goals right at the start of the process to ensure you are always working towards them. 


Understanding the possible threats that could affect the software will help to steer the required security goals, ensuring that the development team can concentrate on the necessary security issues rather than working on mitigating irrelevant threats. 


This diagram gives a basic timeline for the secure development process, showing the stages where milestones and activities fit in. Note that many of the activities are not one-time efforts: Training, assessment, analysis, testing, verification and refinement are all on-going activities and will carry on even if the project has moved into the next phase. 


In order for security to be an integral part of the Systems Development Life Cycle (SDLC), you must first choose which SDLC model you will employ.The traditional model for the SDLC is the Waterfall, or its V-Shaped variant. This approach to systems development is very hierarchical, with clearly delineated phases. The results from each phase cascade down to the next. In the V-Shaped model, the testing of each phase is also included in the SDLC, with the results from each phase of testing feeding back up through the development phases until the final testing proves acceptance that the software matches the original requirements. 


The current fashion in systems development is to be Agile. In Agile, development phases are broken down into small blocks of work called sprints. The results of these sprints are discussed at Scrum meetings, where a Scrum master will pull together the disparate work streams, and keep the project on track. Agile is very flexible and allows for rapid proto-typing of systems without having to go through all of the hierarchical steps associated with Waterfall. This approach does have the benefit of producing systems in shorter timescales, but it can be easy to lose sight of security objectives when the system is undergoing rapid change. 


The Incremental SDLC works in similar ways to Agile, but is far more structured. The development process is broken up into small chunks, but each is actioned in order, and tested prior to moving on. The Spiral SDLC looks to combine the best of the Incremental and Agile approaches, with a high emphasis on risk analysis throughout. 


Next, let examine exactly why the SDLC is important to cyber and information security. 


Computer systems work because of the software that runs them – if the software is not secure, then those systems will also not be secure. Information on insecure systems isn’t secure.  This brings us back to the CIA triad. Insecure software will potentially impact on all three aspects of CIA.  


Improper development of software, with an over-emphasis on Availability for instance, could cause other elements of CIA to suffer. There are choices to be made with CIA – concentrating on one or two of the elements will always detract from the remaining. Security planning should aim for the three CIA considerations to intersect towards the middle of the triangle, as you can see in the diagram. 


There are various activities that could appear within the phases of the SDLC. 


In the initial phases it is important to ascertain broadly what the system is intended to achieve, generating a list of general requirements. 


During the development phase, the design team and other resources will be put in place; a design of the system will be produced; and the development work can begin. 


In the implementation phase, all of the functionality will be tested, including any security features, prior to the actual installation of the system across the organization. 


Even once the system is in everyday use, the SDLC still continues. Systems are rarely static and are usually undergoing constant tweaking and development. Some changes may be due to performance issues, or the emergence of a new requirement. In order to keep track of these changes, it is important to have thorough documentation, and a robust means of managing any changes to configuration. 


Finally, the SDLC must include consideration of what will happen to a system at the end of its useful life. You must be able to answer question like ‘Can the system be securely disposed of, and what will happen to the information stored on it?’ and ‘Can this information be easily transferred to any replacement system?’ 


This brings us to the end of this video.  





About the Author
Paul Andrews
Cyber Security Technical Consultant
Learning Paths

Paul began his career in digital forensics in 2001, joining the Kent Police Computer Crime Unit. In his time with the unit, he dealt with investigations covering the full range of criminality, from fraud to murder, preparing hundreds of expert witness reports and presenting his evidence at Magistrates, Family and Crown Courts. During his time with Kent, Paul gained an MSc in Forensic Computing and CyberCrime Investigation from University College Dublin.

On leaving Kent Police, Paul worked in the private sector, carrying on his digital forensics work but also expanding into eDiscovery work. He also worked for a company that developed forensic software, carrying out Research and Development work as well as training other forensic practitioners in web-browser forensics. Prior to joining QA, Paul worked at the Bank of England as a forensic investigator. Whilst with the Bank, Paul was trained in malware analysis, ethical hacking and incident response, and earned qualifications as a Certified Malware Investigator, Certified Security Testing Associate - Ethical Hacker and GIAC Certified Incident Handler. To assist with the teams malware analysis work, Paul learnt how to program in VB.Net and created a number of utilities to assist with the de-obfuscation and decoding of malware code.

Covered Topics