A vulnerability assessment (or ‘vulnerability scan’) is designed to give a quick look at potential vulnerabilities and uses primarily automated scanning tools to perform the testing. While this has its place and should be done regularly, this is less thorough than a penetration test.
Penetration testing uses many of the same tools and techniques as a vulnerability scan to begin with, but leverages expert security analysis to look much deeper, identifying security risks that automated tools and casual technologists would miss.
For example, a vulnerability scan of a web application may identify no major risks, since a cloud-based WAF is protecting it from attacks. A thorough penetration test may identify the direct IP address of the server, bypassing the WAF and uncovering many serious vulnerabilities underneath.
Costs are given as fixed-bid quotes, based on the size and complexity of the target scope. Assessing a simple WordPress site may be less than $5,000, whereas a complex, custom-build SaaS application can be upwards of $50,000, depending on specific needs. Scope and associated costs are determined through pre-sale scoping discussions.
Assessment time frames are based on the scope and size of the engagement. Assessing a simple WordPress site may be only a few days (including reporting), whereas a large eCommerce site may be a month or more to complete. Multiple consultants can often be assigned to a larger engagement when audit or other deadlines need to be met.
Rhino Security Labs utilizes the rigorous Penetration Testing Execution Standard (PTES) methodology for all penetration testing engagements. While the execution details are customized to the needs of each client, this roadmap ensures each security assessment follows a repeatable and methodical approach.
1. Scoping – Rhino Security Labs works with the client to identify key scoping and assessment details, including systems/applications in scope and any assessment credentials that will be provided.
2. Intelligence Gathering – Using a range of Open Source Intelligence (OSINT) sources and reconnaissance techniques, assessors identify any information on the client which could be useful in a security context.
While often ignored by security firms, we believe this provides the basis for the rest of the engagement and is the most important component.
3. Mapping and Service Identification – Once passive intelligence has been gathered, a more proactive mapping process begins, identifying service versions, subdomains, hidden directories and files, operating systems, and other technical details of the scoped environment.
4. Vulnerability Analysis – Leveraging the previous information, vulnerability analysis identifies weaknesses in legacy software, misconfigurations, information leakages, weak passwords, and other security issues.
5. Exploitation – The exploitation phase utilizes the vulnerabilities previously identified to gain additional information or access on the client organization.
6. Post Exploitation and Pivoting – After initial exploitation and an ingress point has been established, the object shifts to privilege escalation and pivoting.
7. Reporting and Debrief – With the technical assessment complete, focus turns to full documentation and reporting of the engagement, which is then presented to the client prior to the closeout debrief.
Vulnerability risks take into account a range of quantitative values for analysis, and are presented in Rhino Security Labs reports as Potential Impact, Exploitation Likelihood, and Total Risk. These three components provide a comprehensive view of each vulnerability and how it should be remediated– a low risk to all company users should be treated differently than a critical risk to one isolated server, even if Total Risk is the same.
For more details on our risk ratings systems, view a sample penetration testing report here.
Denial of Service (DoS) and similar attacks which affect the usability and uptime of the client resources are not exploited to prevent any adverse effects from the testing. However, in very rare cases, there are impacts to legacy applications or servers. While testing against production systems is recommended for accurate representation of security risks, please let us know if you have any legacy systems or are concerned about the impact to specific servers.