How The Secure Software Development Lifecycle (Sdlc) Can Transform Your Business

INTRODUCTION

If you haven’t already realised, we live in a digital age with 10 billion active Internet of Things (IoT) devices reported worldwide, larger than the population of the world itself. With the growth of capabilities such as 5G, artificial intelligence and machine learning, software development has become one of the most prevalent and staple parts of society.

However, with great power comes great responsibility and whilst these fancy software solutions provide excellent functionality and enrichment to daily operations and activities, they are not without security vulnerabilities. With the damage that a data breach can cause to an organisation highlighted in last week’s article, this week we are going to focus on how implementing security throughout your entire development process through SDLC can benefit your organisation both in the immediate and long term.

At DigiF9 we provide website and application development, as well as visual identity and marketing services to our customers. On top of this, with our years of experience in the security sector, we incorporate security into all our operations to ensure that it is not simply an afterthought. Contact us today at sales@digif9.co.uk for a completely bespoke proposal for your bespoke solution!

WHAT IS THE SDLC

The Secure Software Development Lifecycle (SDLC) is a robust process that defines security best practices that organisations should use when developing an application, from start to finish. In software development, teams may use different models, such as Waterfall, Iterative or Agile, however all models will generally follow these phases;

1. Planning & Requirements
2. Architecture & Design
3. Test Planning
4. Coding
5. Code Testing & Results
6. Release & Maintenance

In a traditional scenario, it is logical to conduct testing once the application has been completely developed and is ready for release. These final safety checks follow a similar methodology to Quality Control (QC) in a factory process, a highly reactive process to identify and correct defects in finished products.

There are some issues with that approach, namely that incidents can go unnoticed throughout the development process and when discovered at this late stage, create a significant challenge for the organisation who may have key target date for release from both a financial and reputational perspective. This then leads to issues potentially not being picked up or simply being ignored to comply with the release dates. SDLC follows a similar methodology to Quality Assurance (QA) – which differs from QC in that it is far more proactive and aims to prevent defects throughout the entire process, in order to give the organisation more time to correct them. It also places the responsibility on all staff to maintain these quality standards, as opposed to only the test team in a QC approach.

SDLC PHASES

So where do we get started?

An organisation looking to implement an SDLC can either add in security related activities to their existing development process or choose to redefine this process if it is not adhering to security best practices. The seven phases typically involved in a SDLC are as follows;

1. Concept
2. Planning
3. Design & Development
4. Testing
5. Release
6. Sustain
7. Disposal

There are several SDLC related activities that can be conducted at each stage, to ensure that security is embedded throughout the process.

Concept
At this stage, the software development is purely a concept, either thought out by the development team’s organisation or by a client. This will involve a high-level overview of what the aims of the software will be, primarily from a functionality perspective. Therefore, the SDLC activity here is Discovery and Preparation from a security perspective. Through security training, employees can identify immediate challenges and concerns that need to be addressed from a security perspective, such as data protection requirements, or key regulatory standards to comply with.

Planning
Here, the development team move away from the initial concept into detailed planning for how the development will take place, deciding on key functionality aspects such as what environment and programming languages to use, any third-party software to bring onboard and estimating timescales. From a security perspective there are three key aspects to focus on – conducting a security gap analysis to identify aspects from the previous stage that require more focus, performing a review of third-party software to be used to ensure it is secure, and threat modelling to identify the different attack methods and motivations to be aware of and build protection against.

Design & Development
At this stage, the development team get into full swing, producing designs, code, and features to demonstrate progress so far. Rather than waiting for the development to commence before conducting security assessments, SDLC recommends implementing testing at this stage, using themes from the threat modelling exercises to conduct security testing including vulnerability scanning and code reviews, to reduce the security overhead at the testing stage.

Testing
In a scenario where an organisation has not included any security related activities up to this point, they are likely to identify a wealth of security related findings. As discussed previously this creates a significant operational overhead, as well as a time-based challenge with target delivery dates defined at Stage 2. However, if security has been considered and embedded throughout, the organisation has taken care of the low hanging fruit, and can focus on more sophisticated testing methods, to provide a greater level of confidence in security.

Release
SDLC also places security requirements at stages after Testing, highlighting that the work is not done yet, and security needs to be considered and reviewed on an ongoing basis. At this stage it is recommended to perform final security checks, tests, and data privacy reviews to ensure that the software is ready for release. Once it is, a comprehensive list of components should be maintained in a clear repository, including all third-party components so that teams are fully aware of what components need to be updated and fixed, when related security issues are found with these components.

Sustain
Similarly, once the software is in production teams will typically look for ways to enhance the functionality and user experience over time. Therefore, security should be treated with the same focus, with periodic internal and third-party security reviews conducted, including vulnerability scans and in-depth penetration tests to identify and correct vulnerabilities on a continual basis.

SDLC CONSIDERATIONS

All sounds simple right?

When looking to implement the SDLC, an organisation should consider the following aspects which form a significant part of the different phases.

The Discovery Phase
The goal at this phase should be to determine security objectives that are required by the software, what the possible threats are and what regulations should be and need to be adhered to. Having a clear view of these aspects before project commence allows the organisation to accurately define release dates in respect of these aspects.

Security Baselines
Whatever environment is used for development, whether a virtual machine on a computer, an on-premises server or a cloud-based approach, an organisation should define rigid security baselines to prevent vulnerable environments from the get go. These baselines prevent users manually creating and defining environments to create software within – not only does this save time and administrative effort but it reduces human error from a security perspective.

Security Training & Awareness
Security awareness training is used to develop a culture where security is seen as a significant challenge by all staff, not just those involved in the security team. Therefore, the intended audience should be company wide. By highlighting the consequences of actions, and mechanisms to prevent these consequences coming to light, organisations can instil security focus in all employees which can help to reduce errors, in turn reducing the number of issues that require fixing after the software has been developed.

Threat Modelling
The most effective threat modelling approaches take the mindset of the attacker – truly understanding what an attacker would look to gain from attacking the software and how they could approach this. Security teams should use historical incidents for similar software, potential previous successful or unsuccessful attacks on the organisation and industry best practice knowledge to build out robust scenario planning, and ensure that each use-case is tested fully.

Third-Party Software
Third-party and open-source software is hugely popular, as it can significantly reduce the development times and ultimately the cost of a project, however these components are not under your organisation’s control. Updates and patches are at the discretion of the creator, so you should be wary of placing full trust in these components. A continual third-party review process should be carried out to provide a high level of confidence.

Security Design & Peer Review
We are all creatures of habit and ultimately self-criticism can be a difficult exercise. That is why it is essential that peer reviews are conducted to gain another perspective. Typically, this should involve someone not directly on the project, either an internal source or an external provider. This way a fresh set of eyes may identify issues that have previously gone under the radar. Ensure that all reviews and security tests are well documented to prevent doubling of effort.

Security Testing
There is no silver bullet when it comes to proper security testing, however best practices involve a combination of five different types of tests to ensure that the software is secure for release. It is important to be aware of these different types, particularly if using a third-party provider to conduct testing, ensuring that each of these aspects is covered.

1. Static Analysis
   Analysing the software without execution, focussing on the source code and components.
2. Dynamic Analysis
   Executing the software to identify runtime issues, infrastructure flaws and patch errors.
3. Vulnerability Scanning
   Injecting malicious inputs against running software to see how it reacts to it.
4. Fuzzing
   Providing invalid random or unexpected data to a program to identify bugs commonly missed.
5. Third-Party Penetration Testing
   Simulating an attack to discover coding or configuration flaws and identify exploitable vulnerabilities.

MAIN BENEFITS OF THE SDLC

This sounds like a lot of effort…

By implementing the SDLC, an organisation can gain more confidence in its security practices. The following are clear benefits that this can bring in turn;

1. Reduces The Number Of Issues Discovered Later On
   By implementing the SDLC throughout the process, an organisation does not first hear about security issues when the application has been developed. This prevents a scenario where several issues are discovered in bulk at this late stage and difficult decisions have to be made.
2. Provides More Accurate Release Dates
   Whilst the SDLC adds in additional activities at each stage, including security from the project start means that project estimates are far more accurate, as proper consideration is made for all security activity throughout the project. This makes the release dates more accurate and in turn keeps stakeholders happy.
3. Increases The Overall Security Posture & Culture
   With security awareness made company wide, the overall focus and discipline of the organisation should improve. This helps across multiple areas, not just with software development, including greater awareness from phishing and social engineering attacks, which can prove particularly costly to an organisation.
4. Reduces The Chances Of A Costly Delay
   When a significant number of issues are identified just before the intended release date, panic stations are reached. Either an organisation will have to deploy vulnerable software to meet these deadlines, or push them back which in turn can be a costly activity. By managing this process throughout the chances of this are significantly reduced.
5. Provides Greater Confidence To Stakeholders
   Organisation stakeholders including customers, employees, shareholders, senior business leaders want one thing – business continuity. Whilst security may not be directly at the forefront of their mindset, any threat to business continuity – whether it is affecting ability to make revenue, damaging a reputation, or incurring financial penalties, all of these stakeholders will be concerned in this event. Incorporating security throughout the process and communicating that to stakeholders provides them with confidence in that business continuity.

MAIN CHALLENGES OF THE SDLC

All these benefits and no drawbacks? Sign me up!

I’ll hold my hands up and admit as a security professional I may be a tad bias here, so it is important to also highlight the challenges that the SDLC can bring into place for an organisation. These include;

1. Potential Resourcing Challenges
   An SDLC works perfectly for a large organisation that has a large number of staff available – dedicated resources that can complete each stage. Smaller organisations are unlikely to have that luxury and instead may find that staff are multi-disciplined and double up on activities. This can create a resourcing challenge if the same staff are responsible for both developing and testing the software, so the SDLC should be fine-tuned to each company’s setup, as opposed to being used as an out of the box solution.
2. Potential Cost
   Naturally the SDLC does involve more resources, so either one of three situations occurs – an organisation hires more staff to complete these, multi-disciplined staff complete these increasing their overall workload, or they outsource some of the activities to a third party. This will either likely lead to an increase in cost from the traditional approach which can sometimes put off companies from implementing this.
3. Requires Buy-In From Different Stakeholders
   SDLC and Quality Assurance are processes and ultimately a process is only ever as good as the people implementing it. Adding security activities at each stage is only effective if you have buy-in from the staff conducting those activities, ensuring that they are robust with their findings and addressing them. Furthermore, with the potential financial cost that comes into place, buy-in is required from senior leadership making this process dependent on multiple stakeholders from a company backing it.

CONCLUSION

Overall, whilst the SDLC is not an out of the box solution and does require fine-tuning to a company’s development approach, from a security perspective it is a no brainer. Whilst buy-in from stakeholders is required for it to be effective, as discussed previously, all stakeholders for a company primarily want one unified thing – for a company to remain healthy and in business. Communicating and highlighting to these stakeholders that security threats have the potential to ruin profitability and revenue generation, and ultimately destroy the reputation of an organisation is a key way to do this.

At DigiF9 we provide website and application development, as well as visual identity and marketing services to our customers. On top of this, with our years of experience in the security sector, we incorporate security into all of our operations to ensure that it is not simply an afterthought. Contact us today at sales@digif9.co.uk for a completely bespoke proposal for your bespoke solution!