The difference between vulnerability scanning and penetration testing
In today’s digital world, it is increasingly important to ensure that your company’s aggregated information cannot be found and taken by others. Therefore, you should continuously work for better security by running tests to find out if there are vulnerabilities. We know information security can be tricky so in this article I will explain the difference between vulnerability scanning and penetration testing. I hope it gives you a better understanding of the tests and their importance to your business.
Vulnerability scanning is fully automated, you only add which assets are to be scanned. You tell the system what to look for and then everything happens automatically. By regularly doing vulnerability scans, you have a decent overview of your maturity level, for example at each release. If you release every week, it may be wise to invest in a dynamic or static vulnerability tool.
In vulnerability scanning, the system actively looks for configuration flaws or vulnerabilities based on deficiencies or actual errors in software, server, client, switch, router, etcetera. Often, it’s a fundamental problem in the code, either you have done something unknowingly or you have omitted something, e.g., in the configuration.
The biggest advantage of an automated scan is that you can find many of the low-hanging fruits such as broken authentication, cross-site scripting (XSS) or other types of injections. Which is a good start.
Penetration testing, also called pen testing, is manual work. Here you go deeper than just checking the existing vulnerabilities. With a pen test, you get further into the system to see connections and gain a deeper understanding of the business logic. When you understand the mindset of development and solution sets, you will probably find additional flaws because the human factor can never be ignored. We know that people make mistakes when it comes to installing, developing, and managing systems. This information could never be retrieved by an automated scanning tool because it lacks the rational thinking that we humans have.
An example of this is access control. An automated web application scanning tool cannot distinguish whether the data it can access is considered a security breach or not, if a ‘standard user’ can access information that only an administrator should be able to access then you have poor access controls. A human can determine this by analyzing the data and what is happening.
A short story of a real case:
“One of our previous assignments we did pen testing on an web application accessible on the Internet and we found a number of vulnerabilities, including unauthenticated SQL injection. The vulnerability allowed data from the database to be read, such as users and hashes After deeper analysis it turned out that the hashes were tampered with and once we understood how, we were able to crack the passwords, log into the web application and upload files and execute code on their web server.
From the web server we got full access to the entire production network, which enabled access by the domain controllers. One of these had several vulnerabilities and despite being replaced with a new domain controller and domain, this was still used for the older domain. The old and new domains had two-way trust, which means that regardless of whether you have an account in one domain, you have access to resources in the other. Due to a combination of poor configuration, outright errors in software, lack of logical separation between externally exposed and internal systems, as well as the customer not fully decommissioning the legacy domain, we were able to get this far into the company’s network and systems.”
If you only had done a vulnerability scan on the application and not penetration testing, at best you would have found that there was an SQL injection but not the remaining flaws.
Recurring problems we can see in companies
A common problem within companies is that they only see these tests as part of a process based on requirements such as PCI-DSS or GDPR. Once the company has overcome its red (high-risk) and purple (critical) markings in its report, they see the job as done. It is not considered as important what you do with the results, the focus is on checking off the requirements.
There is a danger in simply doing a vulnerability scan or pen testing with a kind of ‘check box approach’. The fact is that in many of the cases the environments usually look the same the year after and the same vulnerabilities and configuration errors still exist. The same tests are run showing the same vulnerabilities, which means that the maturity level increases by 0%. As in the example of the web application above – had the company only done the tests without acting on the results, it could have ended badly.
Better communication and understanding of the tests and results could solve this problem. Security is not easy to understand which makes it even more important to really make sure to go through reports properly and get help clarifying the content. If you do not understand the meaning of the results, it is difficult to take action.
The risk of not doing a vulnerability scan or penetration testing
If you don’t have a clear picture of what security looks like in your various systems, you also don’t know what vulnerabilities exist and how far into the systems an outsider can get. As long as that picture is unclear, there is always a risk you may be exposed to infringement. This in turn can cause extremely costly losses for you as a business. Not only in terms of money but also in reputation and work to repair the damage. Do you really dare to take that risk?
To sum up
To make it simple, you can think of vulnerability scanning as the first level and penetration testing as the next. The scan is the precursor to pen testing without the human aspect of it all. It serves as a foundation and brings out the existing known vulnerabilities. After the groundwork, you need to look deeper to understand how developers and the administration set up the systems, see connections and ensure that you have no hidden doors in.
If your security work today is deficient and you do not have control over what you expose to the internet, you run a higher risk of people with the intention of taking control of your infrastructure or taking your data gaining unauthorized access. Therefore, it’s important to carry out tests on an ongoing basis and act based on the results of the tests. Stop seeing it as a requirement that must be implemented and start seeing it as a long-term effort towards a safer system and environment.
As we said, we know it can be difficult to get a handle on everything when it comes to IT security. That’s why we’ve set up a webinar focusing on application security where we will delve into key areas such as how to bring security into the development process, what the most common attacks are and when to choose open source. Register to join by clicking on the picture.
About the author
Mattias Döj is very easy-going guy and appreciates meeting and including new people. During his time in IT security, he has worked globally and traveled the world to perform a variety of penetration tests.
How to think and work with application security
Most of us understand that security is important but don’t really know how and where to start. In this webinar, we will talk about application security with a focus on bringing security into the development process, the common attacks, etc.
We are a team who are all interested in penetration testing, development, love to take on new challenges and have a good sense of humor and laughter. Whether you’re a senior or junior doesn’t matter to us, we in the team will help and lift each other to be the best we can be, as soon as possible.