What is SDL?

Software Development Lifecycle, also known as SDL, is a structured process allowing to build software that:

• is more secure,
• adheres to all compliance requirements,
• is of the best standard,
• meets all business and customers’ expectations.

Simply put, SDL is what ensures software that is being developed is of the highest quality.

Stages of SDL

SDL is not a one-time event but rather a long-term process with a final goal of optimising software security from the earliest moments of its development process. It includes security consulting, continuous pen testing (throughout the development cycle and after the implementation) and keeping security of products and architecture always updated to protect your organisation and customers.

SDL practices we follow

Knowing how much it matters, at Future Processing we take SDL extremely seriously.

SDL practices we follow include:

• providing training,
• performing threat modeling,
• defining metrics and compliance reporting,
• performing Dynamic Analysis Security Testing (DAST),
• establishing design requirements,
• defining and using cryptography standards,
• using approved tools,
• performing penetration testing,
• defining security requirements,
• managing the security risk of using third-party components,
• performing Static Analysis Security Testing (SAST),
• establishing a standard incident response process.

For more information on Future Processing’s approach to SDL practices, please visit our website.

Threat modeling

A core element of SDL practices that should be used in all environments with a significant security risk is called threat modeling. Let’s look at it in more detail.

What is threat modeling?

When designing a new system or process, one of the most important things to do is to consider the potential hazards the product is exposed to. Thanks to threat modeling, you can identify potential threats to the designed solution from the very beginning, saving time and effort linked to leaving them unaddressed and planning the delivery of the product taking those requirements into consideration.

By going through the threat modeling process when developing a new system, you can create a list of security requirements. In the case of an existing system, going through the threat modeling allows you to identify threats, assess which ones seem to be the most harmful and take action to eliminate or reduce them.

When do you need threat modeling?

Potential threats or security gaps can be identified at a very early stage of system or application design, even before the beginning of creating the code. This is why it is so crucial to start threat modeling process early on. Thanks to such an approach, one can detect design flaws which could be costly to fix at later stages. Threat modeling is then being used throughout the whole delivery process, allowing for identifying potential threats at all times.

But it doesn’t stop there. After the product was deployed, it is recommended to periodically perform the process to identify current and potentially new threats along with the improvements that are introduced.

How do we perform threat modeling?

At a very high level, threat modeling can be understood as answering to four fundamental questions:

What are we building / working on and how do we do it?

The first step of the threat modeling process is to understand how the application works and how its individual components are integrated. Software architects and other technical personnel involved in the process identify key components that need protection. At this stage, data flow diagrams (DFDs) are created, useful in the further process of threat modeling.

It is also important to remember that every technology / architecture will have a different impact on the threat modeling.

What can go wrong?

Using hazard classification methodology such as STRIDE or PASTA, we identify the hazards to which our product is exposed. Using classification of threats, we build diagrams showing attacks on the application or system. The so-called Attack Trees illustrate potential attacks to which the application or system we are developing is exposed.

What are we going to do about it?

Based on the Attack Trees, we look at individual threats, assess them and take appropriate action. Depending on our assessment, a risk related to a specific vulnerability can be accepted, eliminated by introducing changes in the code or configuration, or limited by implementing additional defence mechanisms.

Did we do a good enough job?

In case of every threat modeling process, it is worth analysing our results and asking ourselves whether we see any room for improvement. We ponder on the recommendations given to the development team – were they specific enough? Did we miss any key system due to the lack of involvement of a person familiar with a given technology? Taking care of security is a continuous process, so getting the right answers to those questions is always of paramount importance.

In the face of always growing security threats, it is important to treat threat modeling not as a nice-to-have but rather as an integral part of every standard software development process. To speak about it in more detail, do get in touch with our team.