Secure Software Development Life Cycle.

A year of security.

It’s been a while since, here at Imagicle, we started a path to improve the security of our applications. About a year after the first article on OWASP 10, we see how the situation has evolved and what were the first steps that led to the creation of our personal framework for the development of secure software.

In the aforementioned article, in addition to some examples of vulnerabilities, my colleague Matteo had illustrated the best practices adopted internally to improve the process of developing secure software, which can be summarized as follows:

– Hack yourself: think like a possible attacker to prevent threats;

– Spread knowledge: spreading knowledge and culture about safety to increase general awareness, in addition to studying and staying up to date;

– Analyze: use a web scanner to identify possible vulnerabilities.

About a year later, we understood that the skills gained would allow us to improve further, evolving our continuous Integration system by adding a set of tests dedicated to safety.

Getting started with OWASP Web Security Test Guide.

In the field of security, there are several organizations and communities. The reference point that we have chosen as the development team is the OWASP. The Open Web Application Security Project is a nonprofit organization that works to improve software security. It’s a very active community, which produces and makes available for free articles, documentation, and tools that can be useful to increase the security of web applications.

In the previous article, we talked about what is probably their best-known project: the OWASP Top 10 Web Application Security Risks, a list of the main vulnerabilities commonly found in web applications.

This time we refer to the Web Security Testing Guide, another of their works, which has been used as a guide to creating our own secure software development cycle. The WSTG explains the importance of safety tests and offers an example of how they can be integrated into a development cycle.

It also provides an overview of some techniques that can be helpful during application development. Such techniques can be grouped into four categories:

Revisions: that is, all those activities that have the purpose of reviewing and controlling the decisions taken in the analysis phase, for example to check the architecture chosen to implement a new feature, or if the documentation prepared contains guidelines regarding any standards of security to be adopted.
Threat Modeling: groups all those techniques that encourage the investigation of the application from the attacker’s point of view. These techniques allow us to identify possible vulnerabilities that can be exploited, while proposing the creation of strategies and solutions to solve and mitigate critical issues.
Code review: typically automatic processes, through which the application’s source code is scanned in search of possible security vulnerabilities.
Penetration Testing: defined as the art of testing the security of an application without knowing its internal functioning. It can be automated through the use of software or performed manually. Often, those who perform these tests are able to access the application as if they were a normal user.

As we said, our goal is to make the UCX Suite even more secure. Therefore, we decided to start the process by identifying and resolving the vulnerabilities indicated in the OWASP Top 10. Being an existing product (and not to be developed from 0) we started by testing the current state of the application; so we decided to start with some Penetration Testing techniques, which, specifically:

allow you to test only the exposed code;
are performed at the end of the SDLC, so they are easily integrated into our Continuous Integration system.

The WSTG recommends a balanced approach when creating your own safety test program, and we are aware that intervening only at the end of the development cycle is not the solution to all possible vulnerabilities; this is, in fact, the starting point for building our SSDLC (Secure Software Development Life Cycle) staff.

Clearly, this “framework” will be subject to continuous improvements and evolutions to fill any gaps, such as the introduction of software for analyzing the source code.

Designing a Secure Software Development Life Cycle.

But now let’s see how we made it all work within Jenkins, our Continuous Integration system.

As can be seen from the diagram, three nodes are involved in the process:

M: Jenkins’ master node;
K: a new machine on which we have installed our web scanner and will be our slave node where the job that governs the scan will be performed;
V: another Jenkins slave node where the setup and teardown jobs that will be discussed later will be performed.

Furthermore, within V, we prepared a snapshot of a virtual machine with an Imagicle UCX Suite configured and pre-populated with data to facilitate the work of the “spiders” in finding the pages to be scanned for vulnerabilities.

Let’s see how the complete cycle works. First, the master node starts the job dedicated to safety tests, which, in turn, starts the setup job. Then, the latter updates the virtual machine that will be used for testing.

Now:

the previously prepared snapshot is restored;
all Windows Updates are made with the necessary restarts;
the installation of the latest package created by the master branch of our repository is launched;
once the installation is successfully completed, the setup job communicates the IP address of the web portal.

At this point, the security test job knows the IP address, and through the REST services exposed by the web scanner, the scanning starts by sending a payload with the necessary information (IP address, configurations to be used, any exclusions).

The scan consists of two stages:

a first phase of “discovery” of the web pages;
a second phase in which the pages found are tested to check for any vulnerabilities.

As soon as the scan finishes, the security job marks the current build consistent with the scan result:

SUCCESS, if no vulnerabilities of the configured severity and confidence have been detected;
FAILURE, if vulnerabilities have been detected.

The process ends by starting the teardown job which takes care of turning off the virtual machine just under test. In addition, information about the scan that has just finished is archived. This way, you can review any details of the vulnerabilities found.

The cycle described lasts about 5 hours and on average, about 150 thousand requests are sent to the suite.

On the R&D side, this integration has allowed us first of all to obtain a considerable saving of time. Now it is Jenkins who takes care of all the time-consuming activities: updating the environment, starting the scan and producing the results. This allows developers to focus on more important activities such as analysis and development. Furthermore, if potential vulnerabilities are detected by the security scan, the time saved can be invested in studying and solving the critical issues found.

Automated scanning has a number of benefits compared to a manual scan:

duplication of tests performed is avoided;
the application is tested for a greater number of vulnerabilities;
a test standard is created, regardless of the user’s ability.

All this translates into a saving of resources, as well as ensuring that the application is tested for all critical issues covered by the web scanner.

Last benefit, the daily scan allows us to highlight possible regressions or problems related to the latest developments so that we can immediately intervene on the problem and solve it.

Overall, these operations allow us to release an even more stable and secure Imagicle UCX Suite, contributing to the satisfaction of the end customer.

Conclusions.

To date, the Test Suite has been in operation for a few months and after a short settling period, where we have improved the configurations used for the scans, we can draw the first conclusions.

Clearly this is not the solution to all possible security vulnerabilities and we are aware that there is no silver bullet for solving the problem of insecure software. As the WSTG states, it would be nice for a scanner to find all possible problems, but at the moment this scenario is quite utopian. These tools try to simulate a user’s behavior but have limitations. The tests that highlight possible vulnerabilities are performed on a single page and do not support complex logic, such as that of using a page A to exploit a vulnerability present on page B. The use of automatic tools is still useful as a first step.

In our case, this process has allowed us, first of all, to identify a series of vulnerabilities that we have been able to solve; secondly, through the generation of daily reports, we are able to outline a trend of the situation and keep an eye on it.

Solving the critical issues found has certainly improved our knowledge and understanding of the exploit mechanisms, an experience that has been useful in identifying some attack variants on other pages of the suite that had not been scanned before.

All this has favored an increasing attention in approaching and evaluating the problem from the point of view of safety, also in the design phase of the new features.

This is the real starting point for our Secure Software Development Life Cycle. Always keeping in mind that security is a process made up of different actors and components, we will continue to evolve and improve it according to the Imagicle philosophy.

#stayimagicle