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 Telefonica, make us reflect about how organizations protect their information.
All of this in addition to an economy that is overturned by the digital era, where technological platforms are increasingly more immersed in the business core and where all changes or the time to market has to be faster and faster every time, increases the risks that a company is exposed to, even more so when the company looks to protect itself only to meet required standards and not actually being conscious of what is going on or what they are protecting themselves against.
In the rush to feel secure at a very low cost, many companies incur in great risks when executing "security testing" so that they can show that they are "secure", that they can meet the business needs and that it is appropriate for them to make a release to a productive environment and expose their information.
It is here where the so called “Lamers” come into play, they are simply people or organizations that not only claim to have a certain technical skill set that they do not actually posses but also are not willing to learn. Technological societies come to call them out and render them as incompetent. In layman’s terms, a Lamer is someone who has a below average knowledge, some tools at their disposal and obviously, knows how to google.
But, what does a Lamer have to do with the sense of security your company has?
Amongst the processes and controls implemented by companies to protect themselves are Security Tests. Organizations consider they are meeting the required standards for Security Tests when they implement a specific software (Appliance) to execute a vulnerability analysis with the sole purpose of meeting what the security area inside the company is requiring from the production or development team in order to approve a release. However, if the difference between a vulnerability analysis and an Ethical Hacking (Pentesting) is not clear, it can create a great uncertainty and a false sense of security, therefore putting the organization at risk.
A vulnerability analysis is a test performed by an automated tool to verify if the ToE (Target of Evaluation) has known vulnerabilities that are reported in a central database such as the CVE (Common Vulnerabilities and Exposures). This implies that a Vulnerability Analysis alone is not capable of discovering ZERO DAY vulnerabilities. Anyone (Lamer) is capable of running an automated tool but the hardest work comes afterwards, analyzing the results and discarding the false positives (close to 35% of what is reported).
A Vulnerability Analysis usually identifies exposed services without any authentication, default passwords, outdated software, missing patches. etc.
A security test that is based on automated tools (Vulnerability Analysis with selective exploitation), does not allow, from the attacker’s perspective, to identify architectural design and implementation flaws for a specific solution. If there is any supplier that actually exploit the vulnerabilities, this is done based on the results obtained from the automated tool and not based on the attacker’s malice and capacity to interpret the environment.
Figure 1. SQL injection exploit by [email protected]
Unlike a vulnerability analysis, Pentesting (Ethical Hacking), aims to simulate a real attack scenario and procedure in order to compromise the company’s information. Security tests look to assess the effectiveness of the implemented controls, whether it be relevant to the infrastructure or the application. As developers make constant improvements to these systems, continuous pentesting is advised, as it allows them to deploy significantly more secure versions than they otherwise would. Moreover, pen testing allows for a correlation of vulnerabilities which is actually the way a real attacker would look to cause as much damage as possible to the company.
Diagram
Figure 2. Vulnerability correlation of findings
One of the most critical factors that Ethical Hacking aims to avoid is the Vulnerability Yield. This can minimized by executing an Ethical Hacking with 100% coverage, in other words, when 100% of the target scope is evaluated.
The only way which the coverage can be determined is by properly delimiting the test that wants to be done. There has to be a standard measurement for this, which is why we propose to delimit Ethical Hacking by a known and previously set scope.
The way to achieve this is by normalizing the drivers by which tests are dimensioned. When we are talking about a security test that evaluates an Application, the number of input fields in the system must be determined. On the other hand, if we are talking about an Infrastructure security test, the amount of open ports must be determined. And finally, if we are executing Source Code Analysis, the number of lines of code is what we need.
Once all of the above scopes are clear, one can be at ease knowing that everything immersed in the technology in mention will be properly evaluated, as opposed to tests that are delimited based on time of execution with automated tools and that only exploit a percentage of the vulnerabilities reported by the tool.
Up next a table that will help us synthesize all the items described above:
Comparative table Pentesting Vs Vulnerability Analysis
Aspect | Pentesting (Fluid Attacks) | Vulnerability Analysis (Others) |
---|---|---|
Revision Method | Hybrid (Automated tools + manual expert revision) | Static (Automated tools only) |
Model | RedTeam | Vulnerability Analysis with selective exploitation |
Coverage | Variable Coverage | Variable Coverage |
Scope Definition | Based on open TCP ports and visible or invisible form input fields, application headers | Based on IP/Host to test 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, alignment with security standards and regulations | Based on signatures. Syntax |
Leaks (Yield) | 0% of the target of evaluation | ~65% of the target of evaluation |
Type of Evidences | Images, GIF or short video | Automated tool output, Images |
Deliverables | Exploit Evidence. High-level remediation suggestions | Summary report |
Fortunately,
when a Pentest
is done with Fluid Attacks
,
our engineers are fully capable of creating their own exploits
due to the emphasis they have on programming.
This allows them,
on many occasions,
to exploit ZERO DAY vulnerabilities
and report them as soon as possible
so as to allow companies to implement the necessary controls in time.
Further,
with continuous penetration testing,
security can run alongside development without hindering its speed.
Pentesting is then a valuable technique
to enhance the discovery of security issues
in the vulnerability management
process.
From now on, when a security test needs to be performed because the organization or the 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.