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 email@example.com for a completely bespoke proposal for your bespoke solution!
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;
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.
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;
There are several SDLC related activities that can be conducted at each stage, to ensure that security is embedded throughout the process.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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;
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;
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 firstname.lastname@example.org for a completely bespoke proposal for your bespoke solution!