| 4 min read
Without a doubt, the recent events in relation to the infringement of privacy, such as the theft of personal information from celebrities, the Sony, Target, and Equifax hacks, and the big ransomware that affected Telefónica, make us reflect on how organizations protect their information.
In an economy greatly influenced by the digital era, where technology platforms are increasingly integrated into businesses and where changes and time-to-market have to be faster and faster, cybersecurity risks for companies are growing. Even more so when they focus only on meeting required security standards rather than actually being conscious of what is happening and what they are protecting themselves from.
In a rush to feel secure at a very low cost, many companies incur great risks by running "good security tests." They believe that these cheap assessments are enough to prove that they are secure, that they can meet the business needs and that it's fitting to release their software to production.
It's here where the so-called "lamers" come into play, who are essentially individuals or organizations that not only claim to have a certain expertise that they don't actually possess but also are not willing to learn. Technological societies come to call them out and label them as incompetent. In layman's terms, a lamer is someone who has below-average knowledge, some tools at their disposal and, obviously, knows how to google.
But, what does a lamer have to do with your company's sense of security?
Security testing is among the processes and controls companies implement to protect themselves. Organizations believe they are meeting the required security testing standards when they implement specific tools that perform vulnerability scans to comply with what their security areas require from the development teams to approve each software release. However, if the difference between vulnerability scanning and ethical hacking or pentesting is unclear, it can create a false sense of security, putting organizations at risk.
A vulnerability scan or analysis is a test performed by an automated tool to verify whether the ToE (target of evaluation) has known vulnerabilities previously reported in a central database such as the CVE (Common Vulnerabilities and Exposures). This implies that vulnerability scanning alone is not capable of discovering zero-day vulnerabilities. Anyone (a lamer) is capable of running an automated tool. However, the most challenging work comes afterward, analyzing the results and discarding the false positives (close to 35% of what is reported).
A vulnerability scan usually identifies exposed services with default passwords, weak authentication controls, outdated software, missing patches, etc. Security tests based on automated tools (vulnerability scanning with selective exploitation) cannot detect architectural design and implementation flaws from the attacker's point of view. Therefore, the vulnerability exploitation some vendors can make from these tests is based solely on the results obtained by the scanners and not on the attackers' cunning and ability to interpret the environment.
SQL injection exploit by acuberos.
Unlike vulnerability scanning, pentesting aims to simulate a real attack scenario to evaluate the performance of implemented security controls and the potential impacts on a company's systems and assets. Pen testing allows vulnerabilities to be correlated, which is how an attacker would seek to cause the greatest possible damage to a company. Since teams of developers may constantly be modifying an organization's systems, it is advisable to perform continuous pentesting so that they can deploy significantly more secure versions than they would otherwise.
Example of vulnerability correlation for attacks.
One of the most critical factors that ethical hacking aims to avoid is the potential effects of exploiting vulnerabilities. This can be achieved by executing ethical hacking with 100% coverage, in other words, by thoroughly evaluating the target.
The only way to determine the assessment coverage is to delimit the test to be performed properly. There must be a standard measure for this, so we propose to delimit ethical hacking by a known and previously set scope.
The way to achieve this is to normalize the factors on which the tests are based. Thus, if we are going to perform application security testing, we must determine the number of input fields. If we are going to execute infrastructure security testing, we must establish the number of open ports. Finally, if we are going to run source code analysis, we need to define the number of lines of code.
Once the above scopes are clearly defined, we can feel confident that everything related to the targets will be adequately evaluated. This differs from testing with automated tools, which are bounded based on execution time and only exploit a portion of the reported vulnerabilities.
Next up, a table that helps us synthesize all the items previously described:
Pentesting vs. vulnerability scanning
| Criteria | Pentesting (Fluid Attacks) | Vulnerability scanning (others) |
|---|---|---|
| Method | Hybrid (automated tools + expert intelligence) | Static (automated tools) |
| Model | Red teaming | Vulnerability analysis with selective exploitation |
| Coverage | Variable | Variable |
| Scope definition | Based on open TCP ports, visible or invisible form input fields and application headers | Based on IP/hosts and URLs |
| Professional profile | OSCP, OSWP, CEH | CEH |
| Retest | Yes | No |
| Exploitation | 100% | Variable |
| False positives | No | Yes (~20%) |
| Creation of own exploits | Yes | No |
| Zero-day vulnerabilities | Yes | No |
| Finding types | Of a specific business impact: insecure programming practices and alignment with security standards or regulations | Based on signatures and syntax |
| Leaks | 0% of the target of evaluation | ~65% of the target of evaluation |
| Type of evidence | Images, GIFs or short videos | Automated tool output and images |
| Deliverables | Exploit evidence and high-level remediation suggestions | Summary report |
Fortunately, when pentesting is done with Fluid Attacks, our skilled engineers can easily create their own exploits thanks to their programming expertise. In many cases, this allows them to exploit zero-day vulnerabilities and report them asap so that companies can implement the necessary security controls quickly. In addition, by continuously performing penetration tests, security responsibilities do not slow down the speed of software development in organizations. In short, pentesting, within a vulnerability management strategy, is a very beneficial technique for improving the detection of security issues in IT systems.
From now on, when it is necessary to perform security tests because the organization or current regulations require it, ask yourself, do I want to protect myself against a lamer or a hacker?
Share
Recommended blog posts
You might be interested in the following related posts.
