Penetration test

How long does a penetration test typically take?

The duration of a penetration test can range from one week to five weeks, but on average, it takes around 2-3 weeks. However, the exact timeframe depends on the scope and complexity of the work. Feel free to reach out to us, and we will provide a more accurate estimation based on your specific requirements.

What factors have the most impact on the price of a penetration test?

Naturally, the amount of work and its complexity are the main factors. It’s important for us to accurately assess the effort required, as that will result in a lower price. Here are some tips to help you save:

• Provide precise information about “live” systems (IP with have open TCP/UDP ports. If you provide a range of addresses, some of which are not in use, you’ll end up paying for “dead” IPs where there’s nothing to test, but the contract has already been signed.
• The type of penetration test chosen also affects the price. The cheapest and fastest option is Grey Box, as it doesn’t require an additional external reconnaissance phase like Black Box testing. With Grey Box, you simply provide us with a list of systems and access, and we’ll test them. White Box testing is more expensive and time-consuming because it involves a wider range of checks, including interviews and system configuration analysis.
• Assessing the complexity of the work will help determine the cost. For example, testing an online banking system is much more complex than testing a basic informational website on shared hosting.
• Testing a system with authorized access requires more resources from the testers as it involves additional checks. Clearly specify the interfaces that should be thoroughly tested with authorized access. For example, testing a product without authentication requires minimal checks compared to testing a product with authentication, which expands the scope of work to include authorization, session management, error handling, data validation, assessment of business logic, and other tasks that are not possible to fully conduct without authentication.

By considering these factors and providing comprehensive information about the systems to be tested, you can help us accurately estimate the effort and minimize the price.

Which methodology do we use?

Over the years, we have explored various widely recognized methodologies and distilled what works best for us. Our methodology incorporates elements from the following esteemed best practices:

• Several hands-on penetration testing guides:
  • NIST 800-115
  • Penetration Testing Framework
  • The Penetration Testing Execution Standard
• OWASP Web Security Testing Guide: Utilized for comprehensive auditing of web applications.
• OWASP Mobile Application Security Testing Guide: Employed for meticulous auditing of mobile applications.
• PCI Penetration Testing Guide: Mandatory guidance for testing cardholder data environments.
• Open Source Security Testing Methodology Manual (OSSTMM): Although an older practice, it offers valuable insights into organizing and managing the penetration testing process, team collaboration, and more.
• Other methodologies specific to testing particular systems and frameworks.

All these methodologies share common principles and follow a structured approach. However, depending on the specific penetration test, we apply relevant elements accordingly.

What are the stages of the project?

• Sign the contract & NDA
• Approve the test plan and methodology.
• Start – passive information gathering and documentation study.
• Active reconnaissance.
• Identification of vulnerabilities (automated scanning and manual assessment).
• Verification of each vulnerability.
• Risk assessment, threat profiling, report writing.
• Report presentation.
• Re-verification after mitigating vulnerabilities.

How secure is the testing procedure for our environment?

Our goal isn’t to give your systems a bad day with a Denial of Service, but it’s important to understand that we actively attempt to push the systems beyond their usual functioning boundaries.

Now, if we’re venturing into the realm of production environments and dealing with critical systems, fear not! We have a bag of tricks to keep things in check:

• Risky business like vulnerability scanning and exploitation will only happen after mutually agreeing with you on the perfect timing. You can choose a maintenance window, for example, during weekends or nighttime, to minimize the risk for your customers.
• Manual checks will be handled with the grace of a tightrope walker, and our scanners will be configured to tiptoe around your systems like a ninja on a moonlit mission.
• We will establish an incident escalation procedure in coordination with you, ensuring that you are prepared to respond promptly if any incidents occur. It’s rare, but let’s face it, life is full of surprises.
• And don’t forget your system backups, always better to have them on standby.

Another option is testing in an environment identical to the production environment.

What tools do we use?

We utilize both paid and free tools for vulnerability scanning, research, and analysis. Additionally, we employ manual testing, search in public exploit and vulnerability databases.

• Web scanners: BurpSuite & Acunetix.
• Network scanners: Nexpose & Nessus.
• All tools included in the Kali Linux distribution, including Nmap and Metasploit.
• Exploits found in internet databases such as ExploitDatabase, CVE Details, 0day.today, as well as on GitHub.
• Mannually created tools and exploits.

Which model to use: Black box, Grey Box, or White Box?

Here are a few considerations to help you determine the best option for you:

Cost and Duration: The most cost-effective and quickest option is Grey Box testing. In Grey Box, the team doesn’t need to conduct an additional phase of external reconnaissance like in Black Box. You simply provide a list of systems and access, and we will test them. White Box testing is more expensive and time-consuming because it involves a broader range of assessments, including interviews and system configuration research.

Understanding Developer Mistakes or System Security: If you want to understand the vulnerabilities that developers may have introduced in your custom-developed product or assess the overall security of the system itself, Grey Box testing is a better choice. Provide access to the tested systems and add ethical hackers to the security exception lists. This way, they will test the end system rather than the protective measures.

Assessing Internet-Facing Threats: If you want to understand what a real attacker from the Internet can do, Black Box testing is the preferred option. We will conduct independent reconnaissance and coordinate with you to finalize the system list. Keep in mind that in this case, we are testing the security systems like WAF\IPS while the underlying system may still have vulnerabilities.
Want to be absolutely confident? To leave no stone unturned choose White Box approach.

Beyond Black Box, Grey Box, and White Box: You’re not limited to these terms. We can simulate any specific threat actors, such as:

• An Internet attacker with limited knowledge.
• A regular employee with system or network access.
• A guest who connected to the network.
• A partner who gained access through a VPN.
• A compromised developer’s laptop.
• Any other scenario you can think of.

We can tailor our testing to simulate these specific threats in any combination.

Do you perform automated testing or manual testing?

Penetration testing is not just vulnerability scanning; a significant portion of the work is done manually. Vulnerability scanning provides input for manual checks, and the scanner is just one of the tools we use.

We also offer a separate service for vulnerability scanning, which is much simpler.
To reduce False-negatives during automated vulnerability assessment phase we double-check result with second scanner.