Certification and safe development: in simple language

Eva Belyaeva, Security Vision

Introduction

Since we have already started this topic and told you about the SCA process, it's time to talk about how exactly the source code of applications and the applications themselves are tested from a security point of view. Like last time, this is an article for information security personnel who, for some reason, need to support the conversation about SSDL - secure development.

Where do we get our knowledge of what software and components are vulnerable? There are several ways. Firstly, you can always attract specialists from outside (or there are such enthusiasts) who will look for weaknesses in your products. Secondly, and this is already the default in many companies, software manufacturers themselves check it, test and maintain a register of vulnerabilities found along with the versions where it was found. Well, it is important to mention certification - this is an already debugged process with a detailed methodology of what steps need to be taken to test software for security parameters; even if you do not need the certificate itself, but the confidence that you have thoroughly checked your product for vulnerabilities, this will also come in handy.

All companies have a different process, and both steps and terminology do not always coincide. Therefore, it is so important to lead all this to a common denominator.

Regulatory documents

There are both open and closed documents describing the process and procedure for testing. Of course, we will not talk about closed documents, only we will go top-level through the steps of what is already standardized.

About the process

So, how do we test our product? Not only look for vulnerabilities in known databases, what can it contain, but also identify your own?

Let's define what we are looking for in general:

     ·     Actually, vulnerabilities. The first association for most specialists will be source code vulnerabilities, but that's not all: the configurations that come together and the architecture can also be vulnerable - what if the overall implementation approach was vulnerable?

     ·     Undeclared opportunities. Backdoors are not necessary, but in general everything that is not reflected in the documentation. Even if it is easier for administrators to fix the product, or if the developer has cut a couple of corners somewhere, this is a threat to the security of all software.

The types of checks that can help us also differ depending on the purpose and method of the check. Certification requires a set of checks, but in some companies sometimes one thing is carried out, and this does not always mean that testing is ineffective.

Consider the checks.

Researches

Architecture

As previously mentioned, it all starts with the product architecture; already she herself may be vulnerable.

Usually at this stage, the composition of the product modules is checked; depending on what is selected - monolith, microservices, something else - the further order of checks is determined.

You need to figure out how to manage the product, how it starts, what interfaces are available, etc. At this stage, the attack surface is also determined - what is available, for example, to the user, what he sees the interface, what he can do with your software.

And of course, at this stage, it is already possible to assess possible threats.

Statics

If you are interested in software testing as an information security specialist, then, perhaps, in the course of your work, you have already encountered code analyzers - software that will check the syntax and indicate possible vulnerabilities.

For a secure development specialist and/or developer, this looks like annotated code - the program says that, for example, SQL injection can be used in this part of the code, but this one speaks of a buffer overflow.

In general, the verdict of such an analyzer is often true. But you cannot fully trust the assessment of your code to the machine - all the same, a specialist must go through such markings to confirm or deny the verdict; the code analyzer, for example, may not be aware that the problem with the variable it pointed to is being solved further down the code, and the developer has taken into account possible problems.

If we talk about the methodological approach, not all code can be covered by such an analyzer. This may be a new programming language for which not everything is known yet.

Dynamics

Several checks can be attributed to dynamic code analysis, but we will talk about only one of them - fuzzing testing.

Unlike statics, which takes the text of the source code, fuzzing operates the application as if the user was working with it. This is a deliberate generalization, but, in fact, if you look at the results of such a study, the vulnerabilities found and their reproduction are very similar to this.

To conduct fuzzing, places are added to the program code to communicate with the product - the ability to receive or send something. And then the fuzzer begins to massively send data to these tie-ins. What is this data like? Most often, this is a semi-meaningful stream of what theoretically can enter - it can also be a file downloaded by the user in the web version of the application; and sending, within the application modules, status information of any internal entity.

The fact is that the fuzzer will modify this data stream using mutations, increase it or reduce it - in a word, check non-standard sending options.

In dynamic testing, the application is launched a huge number of times waiting for one such data stream to finally get a hang or application error.

Code review

An examination of the code is carried out after all stages of testing, when we have already understood which modules or components were not affected in the previous stages.

Roughly speaking, now is the time to close the gaps and assess whether the uncovered code is vulnerable, whether it is included in the attack surface.

It is not necessary to look only at the code that was not automatically checked; as we said earlier, relying entirely on automation will not work yet, and a specialist can check the entire application as a whole.

In addition, if the company has not yet built the appropriate processes, then all that remains is to manually check the product for vulnerabilities.

Community

In addition to the fact that the regulator and laboratories help with software testing as part of certification, there is also an SDL community: a team of initiative specialists who, among other things, study open source software and share the results of these studies.

Conclusion

Whatever you use on your path to safe development - it doesn't matter if you started this path for a certificate or in order to be confident in your product - you can always start small. It is not necessary to try to build the whole process from scratch at once - this is simply impossible due to the fact that everything is tied to the team, to the internal development processes that already exist.