How to Ensure App Security with Secure SDLC Implementation

Let’s have a closer look at these measures and process adjustments you should make for Secure Software Development Lifecycle (Secure SDLC).

Over the past few years, many companies from various sectors, including retail, media, healthcare, automotive, finance, aviation, real estate, etc. have been affected by security incidents or data breaches. The vulnerabilities in applications and environmental configuration are among the major factors resulting in the success of cyberattacks.

Against the background of the cyber incidents boom, the question arises – what should a company change in existing software development and maintenance processes so that the software it creates and operates is strengthened against potential attacks?

Penetration Testing – is it enough to ensure your software system is secure?

The first thing that comes to mind regarding safeguarding software security is penetration testing.

A penetration test (pentest) is an authorized technical assessment aimed at verifying a software solution’s security and is performed using the tools, techniques, and processes a real-world attacker would normally implement to achieve a specific malicious goal (e.g., steal or modify confidential data). Penetration testers typically assess the existing application, endpoints, environment configuration & security controls and identify security gaps. As a result, you get a penetration test report that highlights security gaps and provides recommendations about additional security measures required to ensure that the network and data are intact.

In a nutshell, the whole process includes:

• Analyzing potential threats, defining pentest goals, and activity planning.
• Gathering information about target systems through various techniques including open-source intelligence (OSINT).
• Vulnerability analysis aimed at identifying potential security weaknesses that could be used to achieve pentest goals.
• The exploitation phase when the pentesters validate and exploit the vulnerabilities they had identified earlier.
• Post-exploitation phase to maintain persistent access to the system and to identify new potential attack vectors.
• Results analysis and a final report including the findings and recommendations on how to mitigate identified vulnerabilities and protect your system.

Penetration testing has been very popular lately as it allows your business to reveal system vulnerabilities, identify high-risk weaknesses, prioritize threats and get valuable recommendations on removing them. Despite the obvious advantages of penetration testing, it also has a number of drawbacks:

Pentest itself can’t make your app secure. Testing is only the first step in improving your app security. You would also need to implement the recommendations provided. This means that if you run penetration testing right before the app release, you may simply run out of time to fix the problems discovered. Especially if they require substantial changes to the system.

High Costs. This is regarding both the testing itself and the fixing of the issues identified. It is important to understand that there are not so many skilled pen testers who can thoroughly check your application, find and exploit even the smallest vulnerabilities in it. It doesn’t matter whether you hire such specialists to your team or outsource the task to an external offensive security services provider, the costs will still be high. Another cost driver is the investment required to fix the issues identified. Quite often those fixes may require deeper changes in your solution (even at the architecture level) driving substantial costs as you may identify them late in the development lifecycle.

Challenge of maintaining continuous security. Penetration testing allows you to identify vulnerabilities in the here-and-now state of the system, but cannot ensure your next release will be free from them. Thus, you will either need to conduct pentests before each release (which may turn out to be quite expensive) or add other security activities that will allow you to find or even prevent the emergence of vulnerabilities before the penetration test.

Penetration testing is crucial, but not a panacea. It is important to incorporate security into every phase of the software development lifecycle in order to identify and fix potential vulnerabilities at earlier stages and at lower costs.

Penetration testing is still essential, but if you put it first in the chain of your cybersecurity activities, you will receive obvious recommendations (e.g. “Introduce patching throughout your system” in the final report. Penetration testing’s major value lies in identifying unique security issues that are not obvious and cannot be detected by other tools (e.g. Broken Access Control, Authentication and Session Management process, Business Logic Abuse, etc.). So, it makes sense to run the testing when your organization’s security is already regarded as being reliable, has already gone through at least basic vulnerability assessments and all the common vulnerabilities have already been fixed.

We usually recommend running penetration tests for companies that are already using secure SDLC before the major release or at least once per year, hence it is best suited for those organizations that are confident in the security of their application and want to double-check it.

What is secure SDLC and why does it matter?

The secure development lifecycle is about integrating different security practices (like security testing, environment hardening, threat modeling, etc.) into an existing software development lifecycle. The right combination of different security practices at various stages of software development allows you to get a product with a predictable level of security.

Some of the main benefits of the SSDLC approach are:

• Your software is more secure because security stays in focus throughout the entire life cycle.
• All interested parties are aware of security considerations.
• You discover security issues early on, even before they are incorporated into your code.
• You reduce your costs with early detection and elimination of vulnerabilities.
• You minimize the overall internal business risks for your company.

There are several secure SDLC frameworks and standards that can be used to embed security practices in the software development lifecycle. For example, ISO 27034, BSIMM (Building Security in Maturity Model), OWASP SAMM (Software Assurance Maturity Model by OWASP), and others.

The one we prefer at Sigma Software is OWASP SAMM. First of all, it is an open framework with an open community that helps it evolve (new supporting materials, insights & guides are added frequently). Secondly, this framework is technology, process, and organization agnostic and provides clear pathways for improving maturity levels. It is very flexible, supports all software development methodologies, and can be tailored to each project’s specific need.

Whether you’re a small software startup or a large enterprise with multiple teams and functions involved in the development process, SAMM can be adapted to fit your needs and implemented in a manner that is as least disruptive as possible.

More about OWASP SAMM

OWASP SDLC is based on 15 core security practices grouped into 5 business functions covering all the major aspects of the software development lifecycle (Governance, Design, Implementation, Verification, and Operations) as shown in Figure 1.

Figure 1: the updated SAMM version 2 model

Each security practice includes a set of activities, divided into 2 parallel streams that unite activities aimed at a specific goal thus harmonizing and connecting activities inside the practice. You can perform activities from only one stream, but it will be more effective if practices from both streams are performed simultaneously because they will complement each other.

Activities inside each stream have 3 levels of maturity ( Level 1, Level 2, Level 3). The maturity level depends on what practices you already have in place. Lower maturity activities are easier to implement and are less formal with the complexity and formality level rising as you move to the higher levels.

It is worth starting the implementation of SDLC with an assessment of the current maturity level of your security practices. To do this you can apply a checklist for self-assessment, for example, you can use the Toolbox spreadsheet or SAMM 2.0 calculator.

Once you understand your degree of maturity, it is worth choosing the main focus areas based on your company’s business needs.

After that, you should decide on a set of activities that need to be implemented, breaking them down into several stages in order not to simplify the implementation process.

We recommend not trying to implement all the practices in parallel, but focusing on practices from one of the business functions first (e.g. “Design” & “Verification” and “Education & Guidance”, etc.). It is also important to understand that the coverage of practices is more important here than the level. So, it is better to have more practices implemented at Level 1 than only one but at Level 3. It is worth starting with the introduction of Level 1 first and gradually increasing the maturity along the way.

We also advise performing assessments regularly even if not all practices have yet been implemented – just to understand how you are progressing and make sure your plans correlate to the business goals and priorities that may change over time.

Pentest as a part of Security Testing in OWASP SAMM

As you can see in Figure 1, Penetration testing (Deep Understanding stream) is an important part of secure SDLC, but still only one activity inside the Security Testing practice that should also be appended by the “Scalable baseline” stream, which uses automated tools to find vulnerabilities before penetration testing.

There is a wide variety of tools for finding vulnerabilities in the application and its source code. You can use Static Application Security Testing tools a.k.a SAST. Software Composition Analysis (SCA) tools to identify vulnerabilities at the stage when the developer only creates the code or commits it to the project repository. It will help you detect publicly disclosed vulnerabilities contained within a project’s dependencies.

There are also tools for dynamic automated testing of an already created application and tools that combine static and dynamic approaches. Different tools will have different efficiency and cost.  Please note that using automated tools almost always leads to false-positive findings.

Incorporating security into every phase of the SDLC

Implementing any Secure SDLC framework throughout your software development and operations cycle is no small task. If you do not feel ready for a full switch to Secure SDLC, we still advise you to at least pay attention to the following aspects:

• Security Training for Development Teams (Education & Guidance practice) – knowing common vulnerabilities and how to mitigate such problems for your product will allow you to avoid a number of security issues and come to final testing with a minimum number of potential vulnerabilities.
• Threat Modeling (Threat Assessment practice) – is a risk-based approach to designing secure systems, based on defining threats in order to come up with measures to mitigate them. This activity allows you to identify, evaluate, and manage system threats, architectural design flaws, and recommended security controls. Regular threat modeling during the design phase or product changes, ensures that the planned implementation is secure and important security measures are not forgotten.
• Security Requirements – focus on security requirements that are crucial in the context of software security. The presence of such requirements before the development of a specific product functionality helps to avoid problems with implementation and subsequent testing. For specific examples that might help as a baseline, you can adopt requirements from OWASP Application Security Verification Standard. If you have a mobile application, you can use Mobile ASVS for mobile apps.

It is important to remember that security-related activities should not end after the completion of the development phase – security should be an inevitable part of the operation phase as well. At this point, we advise you to pay attention to things like Environment Hardening (Environment Management practice) – you can use vendor-specific guidelines or CIS and STIG benchmarks. You will need to set up the process and select the appropriate tool for Security Incident and Event Management (Incident Management practice). With the growth and development of your business, we recommend gradually increasing the maturity levels of your security practices or to even start building your Security Operation Center either on your own or with companies that provide SOC-as-a-Service.

Moving to a More Secure Future

Implementing security in SDLC enables businesses to streamline the development process by addressing the root causes of security issues as early as possible.

If you need more advice or help with implementing secure SDLC or would like to run penetration testing on your software solution, feel free to contact us today and check our Cybersecurity consulting services. Our security teams will provide advice on the best models and help to ensure the security of your product.

• #Establishing Quality Process
• #Information Security