If we ask any security or development professional if they think that performing security tests on their applications and/or code is important, the answer will be unanimous, a big YES !
So why do we still have so many applications that are still delivered with so many vulnerabilities if we have the notion that we need to perform the tests?
The answer is not so simple and we can put some pieces together and try to understand the whole set.
In these next two articles we will talk about security testing, and in this first article we will put some points that we understand as basic to understand the overall plan. We need to talk a little bit about concepts and then talk about what and how tests within the development process can happen.
So let’s get to it.
Speed Vs. Quality
To begin with, we can say that there are still development structures and processes that believe that security tests should only be carried out when the application is put into production. A more classic and very common concept in older development structures.
I will use Bruce Schneier’s words in his book Click here to Kill Everyone, where he puts the following text:
“Software is poorly written because, with few exceptions, the market does not reward good quality software,” and he continues “Price and speed are more important to the market than quality”.
We have seen that in recent years more and more development companies – internally or by virtue of their customers – have been demanded to deliver new software or even new features for their products faster and faster.
As we know, when we talk about security, when you choose speed something will be left behind, and what we’re seeing being left behind is security.
In 2000 Bruce Schneier already commented that “Security is a process, not a product”. I fully agree with him and have my own analogy. In my opinion, working safely is climbing an escalator backwards – if you stop to rest, you’ll come down and lose everything you’ve earned, that’s why the process view is so important.
Still, using Schneier and his book as an example, whose reading is highly recommended, we can say that defending software is a difficult task, because “The complexity of computerized systems means that attacking is easier than defending”. In other words – this part of the text itself already justifies that you should pay much more attention when it comes to security testing.
Some references
In this article, we want to talk a little about security testing, and to shed some light on this topic that is often left out and has its importance diminished.
So that this text is not only based on our knowledge, we will also bring some references and try to show how we do to help our customers with this topic. I believe this will make the understanding clearer.
However, why perform tests and, most importantly, why have a defined and structured testing process?
OWASP in its WSTG (OWASP Security Testing Guide) puts this as the reason why we have this process defined.
“In the security industry, people frequently test against a set of mental criteria that are neither well defined nor complete”.
I think they are correct, we tend to use a lot of our empirical knowledge, and so we do most things, that also includes performing tests, which fail in structure and often in basic concepts.
Also, testing and evaluating web applications is even more critical than for other software, since most companies have their business strongly based on this type of application.
When testing it?
We also commented above that the thought that web applications should be tested only when they are already finished and exposed to the Internet is still widely used, having the access of millions of users.
We do not think this way and we have a strong understanding that this is no longer correct to be used today, because besides being ineffective, it is one of the most costly models for companies, because it only begins to correct problems when they are already present in applications.
This fact itself is already impacting to the company, but if we imagine that correcting a vulnerability in an already operational application has even greater consequences, because new development efforts will be necessary, not counting the hours of planning and search for corrections.
It is undeniable that one of the best methods to prevent your applications from being put into production with vulnerabilities is that they are tested throughout the software development cycle (SDLC).
It is essential that companies look at their development process and see whether within their process safety concepts are part of the various stages of the process, if you don’t have it it’s time to rethink and restructure your development models.
What to test?
This is another issue that often arises, and it is a legitimate doubt, but first let us understand a concept.
Software development, like any process, is the combination of people, processes and technology. So, nothing is more fair than to have these three points as the basis for our testing.
Let’s keep talking about each of them.
People, Process and Technology.
We need to “test” people to know if they have the basic knowledge and conditions or even the basic knowledge to work and produce quality and safe software.
We need to think that security is everyone’s responsibility, developers, engineers, architects and even the “owners” of the product, who often don’t understand its importance in the process.
People are important, they are a fundamental part of the whole process and need to be looked at with this degree of importance. Therefore, having an education and training program is one of the first steps to ensure software security.
This is a very important point. An example of Microsoft’s development process is:
“Effective training will complement and re-enforce security policies, SDL practices, standards, and requirements of software security, and be guided by insights derived through data or newly available technical capabilities.
About the Process
A process needs to be evaluated. During the evaluation process, we can understand whether or not this process is being efficient and delivering what was actually thought.
Regarding security, the process needs to be evaluated to make sure it is appropriate to the policies and/or even the requirements determined by standards of what the company expects to follow. In addition, we need to assess whether people know how to follow or even execute the policies created for the process.
On technology, we need to make sure that the process is being effective in its implementation.
It makes no sense to have in our process a set of tools and technologies that are actually causing more loss than gains in their use, the evaluation of these technologies and how they are used is extremely important for the whole set to deliver its best.
By testing people, processes and technologies companies can identify problems that may later appear as problems and defects.
So, let’s follow and talk a little more about testing.
Basic Concepts
There are some misconceptions that we have observed when designing and structuring a testing process, and we need to talk about them.
There isn’t a “Silver Bullet” solution
It is common to find in several companies several tools, each with its own characteristics and specialties.
And it’s tempting to imagine that a tool, like a security scanner, has the power in its tests performed on our code to identify all the vulnerabilities that may exist.
However, the reality is quite different, and there is no such magic solution that will make your application or even your code safe just because these tools are being used.
We can’t discredit the tools, but we have to understand how they work and what their limitations are.
Application and code security evaluation software, although very useful at first, because it helps to identify the most common flaws and errors, shows itself to be inefficient or even with low results when it comes to in-depth evaluations. Moreover, in this aspect, many of them do not provide adequate testing coverage.
We have to remember that, as Bruce Schneier put it very well, “security is a process and not a product”.
Think strategically and not tactically
In the 1990s we had a very different process of correction than we have today. During this period, what we had was a correction process focused on correcting vulnerability when it presented itself, without worrying about the real source of the problem.
This “process” was known as patch-and-penetrate.
But we can’t put this as an error. After all, everything must be analyzed according to the scenario of that moment. For example: in the 90’s, failures in web applications were not so critical, since web applications were not even the focus of the time. After all, the focus was on infrastructure.
The issue with this kind of posture is that, even today, where large businesses are strongly based on web applications, we still find this kind of posture for corrections.
During the correction process of one, we need to identify the root cause of the problem, not simply apply a correction. After all, without knowing what led to this problem nothing will be solved in the right way.
At this point two points must be placed. The first shows that this subject has been raised for some time, for example in one of his publications again, Bruce Schneier introduces us to the term windows of exposure, term that he created to show a window, a period of time existing between the discovery of a flaw and its correction. The image below can help us to understand the concept.
What we have observed is that unfortunately the time between the vulnerability discovery and the fix has not followed the pace and speed with which applications are released and new features implemented, because as we commented there at the beginning, the market does not give premium for quality software.
To reduce and improve this view, it is critical that the SDLC process is reviewed and evaluated to see if all of the secure development concepts are being used and in their proper place and time.
With this kind of approach we are sure we will be able to reduce the amount of vulnerabilities. Putting security in the whole process, and increasingly at the beginning of the process, is truly the concept of Shift Left, not that of introducing more and more tools at the development stage, believing that these tools will solve the problem. The rest to us looks like a chicken flight.
SDLC
Developers can build an SDLC development process strongly based on policies, practices and best practice standards, not forgetting the tools that are important allies.
Considering the concept that the earlier the better, use Threat Modeling techniques, and other techniques that can help identify potential vulnerabilities.
Building an SDLC allows for a more comprehensive view of the entire process pipeline, allowing the development team to take a more holistic view.
The important thing is to understand that each of the phases has its own security principles and tests, which we will understand a little further on, the fact is that the earlier we worry about the security of the code, and consequently with testing, the more effective, both in process and in cost, the SDLC will become.
Understand that here there is no indication of use of one or the other model of SDLC, there are several, we use Microsoft because it is already incorporated in our process of validation and construction of SDLC, but you can choose another or even build yours, the important thing is to understand the concepts.
Another good alternative may be the use of the model developed by OWASP called SAMM, which today is in its version 2, and here in the blog we have a series of articles being created about this model.
But as we speak, there are others, it is enough that the concept of having safety tests in the early stages is maintained.
This principle takes us to another point.
Test early and test always
It is a basic principle, the sooner you can identify an error or even a flaw, but it will be cheaper to fix this flaw. It seems simple and logical but why do we still have so many development processes that don’t have this principle built in?
One of the gaps we realize is that the more training and education there is for developers and testers, the more awareness these teams have to put security testing more recursively and early in the process. So here’s our first point, invest in training and education, that will bring good efficiency gains within the process. We talked a little bit about that in one of our articles.
And not only that, with the trainings the participants of these teams themselves will develop a different mindset, looking more directly at the process as a whole realizing that they can contribute and change, but always keeping the same principles.
Consider automation
It is not difficult to identify that in the most modern methodologies, and here we will deal with DevSecOps, we cannot work in a scalable and efficient way without the use of tools.
And at this point we can’t be confused with the concept that there is no “silver bullet” aforementioned, the tools are important and have their place in the process, what we can’t do is deliver security only to them.
After this addendum, we have to try to integrate the necessary tools to help us identify the points of failure in our code earlier and earlier. For this we need to think about how and which test tools will be integrated to our CI/CD (Continuous Integration/Continuous Delivery) pipeline.
Get an overview of security project
It is inevitable, we need to understand beforehand what the security needs of this new application before we start building our code. These needs also apply to what requirements our application should meet.
Therefore, knowing and having the vision of which regulations, contracts or any other requirement is important and should be raised, only then can we create and plan tests that may guarantee these requirements.
However, care must be taken in this case. The goal is to understand what requirements the application must meet, it is not necessary to put more security than is necessary.
Putting complexity within the application can also be a problem, we have to seek to balance security with the complexity of the code, this will facilitate the tests to be performed, and bring fewer chances of errors.
Conclusion
After going through most of the concepts that we understood to be necessary, we believe that we are now more prepared to continue on the next topics, we will talk more specifically about testing.
We understand that all the concepts that have been placed here contribute directly to a good evaluation of an already existing testing process, and therefore we want to leave this article focused directly on that, and with this understanding we can take new topics to the reader, which will be placed in the next article.
So, see you then!
