QIWI Security Development Lifecycle

At a certain point in the life of almost every FINTECH company, the time comes when the number of applications for internal development begins to exceed the number of developers, the business wants more new features, and Bug Bounty continues to turn in more and more new vulnerabilities ...

But at the same time, there is a need to quickly release high-quality and secure software, and not extinguish fires from detected security errors with version rollbacks and night hotfixes.

When the IB team consists of a couple of people, it seems that it will always be like this, but we decided to squeeze the most positive out of the situation and once and for all “check” our applications.

Where to begin? Our plan was simple:

To streamline the processes of formulation, execution and release of tasks, without becoming a stick in the wheels of development.
To fasten fashionable security scanners.
Open a couple dozen applications.
Lie back in your chair, watching how it all works.

Processes

The templates of the development processes of the “ Software Development Lifecycle” have long been written, there is even GOST and ISO. But about the patterns of building "safe" development in our country a couple of years ago almost was not heard.

At first, the engine behind the idea of safe development was Microsoft. In the terminology of the Redmod giant, the Security Development Lifecycle is a process that helps developers build safer applications for a minimum of time, following certain rules of software design and development.

How to come to this? In the general concept, SDLC is a closed loop of processes, for example, like that of Microsoft . For ourselves, we have identified the following steps of the processes:

Initially, the task looked like this, that it was necessary to complete some items from this template to the existing development cycle.

Namely, we have a well-established cycle over the years, according to which the task came from one of the divisions (business, analytics) got to the developers, then tested. In case of detection of functional bugs, it was returned to development, transferred to admins and ultimately poured into battle.

At the time of the launch of QSDLC, we had:

Annual trainings for developers;
Build-system and an established deployment system with the possibility of version rollbacks;
As far as possible - testing of applications coming out in release;
HackerOne program;

So following the pattern, we covered 3 important points.

For a small number of releases these steps would be enough. But in our case, it was necessary to refine the processes of setting tasks and automate security tests.

Problem Statement and Design

Some security bugs can be fixed at the initial design stage of the application. They may arise due to fundamentally flawed logic circuits or the introduction of unreliable mechanisms.

For ourselves, we have highlighted the main points for which the IB-analytics of tasks is required:

work with third-party services, data exchange with partners / clients,
work with third-party code, its introduction into the system,
lowering the level of service privacy,
work with personal data of users,
new for the service / feature system that is not basic.

The costs for this stage are small, but it allows

to secure separate parts of the system in the bud,
save time and effort on reworking and catching bugs,
increase awareness of information security not only developers, but also analysts and product managers.

Automation

Dast

He is Dynamic Application Security Testing . And strange as it may sound, for web applications we just took Burp Suite because He was already a well-known and indispensable tool in his work. In addition, the scanner has an excellent API for refinement under our Wishlist. Maybe someone will say that this is all-only a desktop tool for pentester, but in fact it can also cover the requirements of the enterprise.

In the context of the SDLC, this is:

Scheduled and event scans (new releases);
Initial assessment of the application;
Spot scan, random fuzzing and application load;
Thanks to the open API, it can be added to each specific project, complete control over the tool;

What a dynamic scan cannot qualitatively cover is finding all input points in the application (they later solved the problem by proxying traffic on the final test nodes and QA autotests, but it would not save them from some unforeseen scenarios).

What DAST cannot cover in principle:

Finding second-order vulnerabilities (not 100% coverage);
Difficult to separate modified and unchanged input points. Accordingly, the scan passes through the entire application, because of which the scan time can be very long;
Danger of distortion of product data in the case of scanning on combat projects.

SAST

The best automation option at the time seemed to be SAST, Static Application Security Testing - static scanning of application source codes for potential vulnerabilities.

The scanner builds graphs of software calls, analyzing input and output points, intermediate calls to various modules of the system (database, services) and data types coming from the external environment (user input, samples from the database).

According to this data and the knowledge of anti-patterns and bad practices in the scanner, the sast-tool finds potential security errors.

How the SAST scanner is fundamentally different from DAST and better in the SDLC bundle:

You can hang up the launch of the scan on commit-hook in the version control system and specify which branches of the repository should be scanned;
In contrast to DAST, it is not necessary to wait for a calculation in the test / combat environment of the working application;
Equally well suited for scanning all platforms (web, desktop, mobile);
You can scan the application iteratively - see through only the modified call graphs. Scanning time is greatly reduced without loss of code coverage.

But in addition to the positive aspects of the introduction of scanners, I had to face a lot of pitfalls.

SDLC implies a continuous development life cycle

A common item related to any type of scanner.

The scanner is just a tool, and it needs to be launched at the right moment, preferably hanging on some events in time. In addition, in SAST, in order for the scan to go through all the project data and its dependencies, you need to collect the code for all project dependencies. And not all scanners can do it themselves. And it would be great to monitor the appearance of new positives for subsequent scans, receive mailings about them, hang tags in build systems about clean builds and assemblies containing bugs.

As a result, we made a separate service for connecting scanners to SDLC, which deals with all integration problems.

In general, this is a hook to a new build in TeamCity, information about which from one of the agents is sent to the service of the control center. He does a number of manipulations with source codes, sends them to the scanner and starts monitoring.

Abundance of projects, initial scan

To start convenient iterative scans, you need a starting point to send - with which subsequent scans can be compared, and only indicate errors that appeared with the current iteration.

Initially, you will have to view all the responses that appear in the report. Depending on the specifics of the project / language, there will be a lot of False Positive. And until the point signatures of the application are specified, the scanner will state that the abstract combination of setName – getName methods in the class describing the model is Reflected XSS.

Also, custom logic should be described for all home-made projects. If you write your frameworks, you will have to write your own search rules. During the implementation of the scanner, we have collected more than a hundred of such rules for different languages and projects.

And you need to accept the fact that the tool does not support all languages and frameworks, at least for the time being