How many steps are there in a secure development lifecycle?

For many years ago, cyber security was considered as a final product or job that you add when the application functionalities are correctly working. However, today the game has changed and it is becoming a part of the Development lifecycle. Now how many steps are there in a secure development lifecycle?

The number of steps in a secure development lifecycle is between 5 to 9 steps depending on the number of steps in the used software development lifecycle.

I have worked with many big application development companies to integrate the cyber security aspects in their development lifecycle. Therefore, I am making this blog post to explain this process in detail with some realistic examples to better understand the process. So, if you are interested in knowing more about that, just keep reading J…

Before we start digging deeper in this subject let me first explain, why companies has started to get more and more interested by implementing an SSDLC (secure software development life cycle).

Due to the growth number of features the modern applications offer to client, the number of vulnerabilities has also grown rapidly in parallel. This growth in number of features has also led to the increase the complexity of created applications. Therefore, the old solutions of taking security as a final product is not giving a good results and it is even making vulnerability fixing a very time consuming and expensive task.

Therefore, to solve this problem, companies have started to integrate cybersecurity in every step of their SDLC. This way when a vulnerability is discovered at a certain level of the process, then going back and fixing it becomes easy and reduces the time and the cost.

In this blog post I will focus on the steps of an SSDLC that is based on a 6 steps SDLC, because it is the most standard one. However, you should know that the same work should be made for any kind of SDLC.

Step 1: Secure requirements definition

The first step in any development life cycle is the requirement definition. In this step, the project manager gets in touch with the client to get as much information as possible to better understand what he needs. You may think that at this stage, security is not an important thing and nothing can be done.

Trust me, this is the most important stage where cybersecurity aspects need to be addressed and discussed with the client. The discussion of these elements with your client will help you manage the development time and the cost of the development. More security usually means more coding and more time.

For example, you could discuss with your client the possibility to implement two-factor authentication. I mean there are many security systems that you can discuss with your clients at the beginning to be able to add this from the start.

I remember once, that even a client that wants to develop an application has required at this stage that the development team of his service provider, should be educated to the top 10 OWASP vulnerabilities. Therefore, this stage could have a huge impact on the development flow.

You should know that this step will influence the whole following steps. In addition, a good knowledge of the project security aspects at this point will facilitate the design step and give you a detailed view of the project requirements.

Step 2: Secure Design

Designing the app functionalities is a very important step in the process of developing applications. Therefore, many actions and high-level tasks should be performed and discussed at this stage to reduce the risk of potential attacks.

At this step, the first action to do is to analyze the attack surface. By analyzing the attack surface of your app you will be able to identify what parts of the application are critical, and which need defense-in-depth protection. In addition, a good attack surface analysis will give you a high-level view of which part of the application should be tested against security vulnerabilities.

Application security architects and penetration tests usually perform this step but developers should be part of the job to give their functional point of view as they know the requirement better than everyone.

Here is some examples of what we call an attack surface:

• The interface paths
• The forms
• The application HTTP headers
• API calls and interactions
• Local storage
• …

Note:

To better list all your possible attack surfaces, you can group these entry/exit points by category. For example:

• Admin interfaces
• Customer interfaces
• Transaction interfaces
• …

The second action performed in this step is threat modeling. According to Microsoft SDL guidelines, Threat modeling is the process of identifying and prioritizing possible risks and security mitigations in order to safeguard valuable assets such as secret data or intellectual property.

In other words, treat modeling will help you identify the design issues that require mitigation earlier in the development process to reduce the cost and the fixing time.

I highly recommended following the treat modeling system presented here as it is well written and updated all the time by treat modeling experts.

In general, when you decide to perform a treat modeling you should ask yourself the following questions:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

Step 3: Secure Development

You need to know that most cybersecurity infiltrations happen using one of the following two techniques. The first one is by using social engineering, and the second one is by exploiting a vulnerability in the source code of the company router or firewall. If you deeply analyze both techniques, you will see that both of them are related to human mistakes.

Therefore, at the development stage or even before starting the whole SDL process you should educate your developers about the possible vulnerabilities (mistakes) that they may do in a source code. Some companies like Microsoft have added this step at the very beginning of the SDL process, and train the development team to not do those kinds of vulnerabilities and to be able to find them if there are any.

Training your development team in how to write secure code, is a very important task to be able to reduce the number of vulnerabilities discovered at the end of the development process. This means, reducing the time and the cost of the fixing task, which gets higher each time the vulnerability is discovered in a late stage.

Even with training your development teams, they remain human beings, so they will always make mistakes by forgetting things for example. Therefore, it is very recommended that you use some tools that will help him remember the best practices that he learned.

In general, those tools use pattern-based detection to find the vulnerable code while your developer is typing and can be installed as plugins in the IDE your developers are using. Here is a list of such tools:

• Android Lint
• CodeDX
• Findbugs
• SonarLint
• Veracode
• …

At this stage, many people may forget something very important, and this is due to the nature of new development technologies. In modern application development technologies, developers are using what we call libraries and plugins. As a consequence of this new way of development, the risk of making a vulnerable app due to using a vulnerable library is getting high. Therefore, every development team should have a tool that checks either the library is vulnerable or not before using it in the code. Here is a list of such tools:

• OWASP Dependency Check
• Debricked
• Snyk
• …

Step 4: Secure Testing

In the testing phase, no other new tasks that you already know about are needed to test the security of the app. Barley everything we do to test the application functionalities will be also performed here but with a security focus.

Testing the security of an application can be performed in two ways, Static and Dynamic tests. I personally recommended doing both, as you will see in the following paragraphs because they complete each other. In addition, both techniques can be partially automated to eliminate some obvious vulnerabilities in the source code.

In the static tests, the penetration tester or the application security tries to analyze the application source code to find vulnerabilities. At this level, the tester has a deep understanding of the application parts and source code and could get access to any information he wants about the app functionalities. This deep knowledge helps the tester to focus his testing time on the higher-risk parts of the source code.

However, this technique could be very time-consuming and could miss some vulnerabilities related to some environment parameters. In addition, with the increase of the applications complexity, this static approach is getting even harder and need the use of sophisticate tool to help the testers.

Here is some tools that can be used to perform a static analysis against your app:

• Veracode
• AppScan
• SonarQube
• Rips
• …

After performing the static tests on the source code, you will have to do a dynamic test against the app. A dynamic test is just another way to call a gray box penetration test if both manual and automatic tests are performed. Therefore, the same tasks you perform on a gray box penetration test will be done here. However, the only difference here is that in most cases the tester is an internal person (in most cases).

The dynamic tests give really good results and could be used to validate the vulnerabilities discovered in the static tests. However, performing a dynamic pentest is not always possible at this stage of the development process as it could not be possible to run the application.

Here is a list of automated tools to perform a dynamic analysis:

• Accunetix
• BurpSuite
• Netsparker
• Nessus
• …

Step 5: Secure Implementation

Now that the app is fully developed, the next is to deploy it. Deploying an application in a production environment or in a test environment hidden from the public could generate many vulnerabilities. One of the most common vulnerabilities that can be detected due to the deployment is using default credentials to log in to the app or the database.

In addition, most of these deployment vulnerabilities could be found at the test time but they are considered acceptable at the development phase. Trust me this kind of vulnerability happens all the time, and could lead to many serious data breaches.

Secure implementation is not only related to the application installation, but also to the environment where the application will be implemented. A vulnerable environment is another way to infiltrate the app.

A vulnerable environment is usually due to a bad configuration that does not take into consideration the security best practices or an outdated system.  Therefore, a full environment check should be performed to ensure that everything is updated and well configured before the app implementation.

Actually, the secure implementation process does not stop at this level. At this level, the security architect and or the secure development expert should work together with the Security operation center (SOC) team to write an incident response plan. In addition, a final penetration test should be performed against the application to ensure that everything is well made and that no implementation-based vulnerability is detected.

Step 6: Secure Maintenance

You should know that vulnerabilities are discovered in many source codes around the world and one of your libraries or even development technology could be one of them. Therefore, checking the application at the development phase or at the end of the development process is not enough. A full security check should be performed periodically.

Most popular and known standards around the globe, recommend performing a penetration test against an application 2 times per year, especially for banking apps.

In addition, a static and dynamic security analysis should be performed whenever a new update is performed on the app. Moreover, even the environment where the application is deployed should be checked against known vulnerabilities to ensure no vulnerability is left.