TL;DR
Penetration testing (pentesting) is a structured, ethical hacking exercise that simulates real-world cyberattacks to expose security vulnerabilities before malicious actors can exploit them. A successful pentest moves through three stages: pre-engagement, engagement, and post-engagement. They can employ multiple methods (black box, white box, grey box, etc.) across attack vectors like phishing, brute-force, and denial-of-service (DDoS). Organizations should schedule tests based on their risk profile, budget, and regulatory requirements, and should always include web application firewalls (WAFs) in scope for a complete security picture.
What is penetration testing?
Penetration testing is a form of ethical hacking. When the process is complete, you'll identify weak spots in your plans. Reporting helps you patch them before true hackers find them first.
At the end of a successful hack, you'll know so much about your company's security system. You'll see where the gaps are, you'll understand how employees helped or harmed the effort, and you'll know how long it took you to spot the problem.
But at the end of a hack, you lost something. You may have been forced to pay a ransom to wrest control away from the hacker. And you may have lost the trust of customers too.
What if you could learn while losing nothing?
Why is pentesting now common across industries?
At one point, pentesting was the province of highly regulated industries. If you worked for a government agency, a utility, or a financial institution, you ran pretesting to comply with regulations. But now, plenty of companies run tests like this, as the threat of cyber attacks touches almost all market sectors.
What are the stages of a pentest?
A hacker can jump into action with almost no preparation or planning. Pentesting is different. Projects should move through a predictable series of steps, with plenty of collaboration and conversation along the way.
The Payment Card Industry (PCI) Security Standards Council recognizes three critical pentesting stages:
- Pre-engagement
- Engagement
- Post-engagement
We'll walk through them one by one.
What happens during the pre-engagement stage?
Whether you're using an in-house team or hiring a consultant, you must have a conversation before the work begins. You'll discuss:
- The scope. What components should be included in the test?
- Documentation. How will the work be recorded for future study?
- Rules. When should the work start and stop? How far should the hacker dig before stopping? Will sensitive data be shown?
Your conversation can be short or long, depending on all of the aspects you need to cover. Ensure someone takes detailed notes, as you'll refer to this agreement as the project moves forward.
What happens during the engagement stage?
At this stage, your team begins to dig into the details of your system and look for vulnerabilities.
As experts explain, a pentest isn't exhaustive. You may have vulnerabilities that just don't come up during the process. But your hacking team should work hard here to break through your defenses. The goal is to determine just how far a hacker can get into your servers without your detection.
A pentesting team typically looks over:
- Application layers.
- Network layers.
- Segmentation.
If sensitive data is exposed, the team should notify you immediately. And anything that the team ruins or changes during the test should be cleaned up when the work is done.
What happens during the post-engagement stage?
At the end of a test, you should have a report ready for deep analysis. Use that as feedback to help guide changes in your security systems.
The feedback you get should be about exploited vulnerabilities. In other words, it's not helpful to get reports about the clever or interesting things the hacker found out about your systems. Everything in the report should be both applicable and usable.
What attack vectors does a pentest cover?
Your hacking team could poke at almost any part of your security system as the work unfolds. But the International Council of E-Commerce Consultants (EC-Council) suggests that most focus on just seven different attack vectors.
- Cross-site scripting: A hacker impersonates a user to test the security of a web-based application.
- Brute-force attack: A hacker tries hundreds or thousands of username/password combinations in an attempt to gain access.
- Backdoor shell attack: A hacker uses malware to attempt entry, even though that person shouldn't be allowed in.
- Man-in-the-middle attack: The hacker attempts to gain access to server traffic to modify packets before they're delivered.
- Buffer overflow attack: The team attempts to flood a buffer with so much data that it fails, and the hacker gains access to memory.
- Phishing attack: The hacker attempts to entice employees and users into giving up sensitive data, which can be used to gain access.
- Distributed denial of service: The hacker floods the server with so many requests that it fails to respond to legitimate requests.
Any of these hacks could cause hundreds of thousands of dollars of damage. Spot them during penetration testing, and you could save your company both money and hassle.
How often should you schedule a pentest?
Just as no two systems are the same, no two pentesting schedules are alike. Your schedule should be customized to meet your company's specific goals and regulatory environment.
If you're not required to test on a set schedule due to a government or local mandate, create your schedule by considering your:
- Risk. Do you have very enticing data that almost anyone would want? Would you consider your company a high-value target?
- Coverage. Has your company been part of a local news cycle for some reason? Are you involved in something controversial?
- Type. Do you use open-source software? Or have you made big changes to your infrastructure lately?
How does budget affect your pentesting frequency?
Examine your budget too. A pentest can be expensive, especially if the team finds major problems that you must fix immediately. If your budget is quite small, you may need to expand the time between tests to avoid spending more than you have.
What are the most common pentesting tools?
Most pentesting teams use programs to enhance their work. They work quickly, allowing the team to find vulnerabilities without spending a lot of time writing code.
Well-known testing tools include:
Every team has a favorite program, and some bloggers do too. Since some are free, it pays to mix and match until you find one that works well for your system and expertise.
Are there specialized tools for government or enterprise use?
If you work within the government sector, you might be eligible to use tools developed by official agencies. For example, the Office of the Chief Information Officer of the Department of the Interior performs pentesting.
Some companies also offer pentesting software as a service. Contract with them, and they'll handle your work from end to end.
What pentesting strategies and methods are available?
During your pentest planning steps, you'll face an important decision. What sort of relationship should you have with the testing team? And how much should they know before they get started? Answer this question by choosing a method.
These pentesting types are recognized by the EC-Council:
| Method | Description |
|---|---|
| Black box | A tester knows nothing about your system before the work begins; closely simulates a real-time attack. |
| White box | A tester knows all about your system, including infrastructure and protocols. |
| Grey box | A tester knows a bit, but not everything, about your system before the work begins. |
| Targeted | Your information technology (IT) team and designated testers work together to examine just one part of your system. |
| External | Only visible servers or assets are included in the testing. |
| Internal | Only items an authorized user can access are included in this test. |
You may find one method that works well for your company, and you may use that same system each time you perform pentesting. But it's reasonable to switch up methods based on your current risks.
How does penetration testing apply to web application firewalls?
You've designed an app to serve your customers, and it runs on data you've protected with a digital firewall. Should pentesting extend here too?
Should you include your WAF in penetration testing?
While web application firewalls (WAF) do offer robust security, studies suggest that about 65 percent of companies have attacks that bypass the WAF altogether.
Eliminate the WAF from your testing, and you could be missing out on a significant security issue. But you'll need to approach the problem carefully.
How should you approach WAF testing?
To perform some types of penetration testing, vendors might ask you to turn off the WAF. A simulation like this helps you understand if the app itself is vulnerable to hacking if the system goes down or you're dealing with a disgruntled insider.
But you should ask the vendor to look over the WAF too, just to ensure that it is working as designed and offering protections that are hard to bypass.
Multiple pentests like this give you a complete picture of the security environment of your app, and that could be critical for your users.
Get the help you need with Okta
Our solutions can help you prepare an effective pentest. And if you've been through the process and realized that you have plenty of gaps to fill, we can help with that as well.
We'd love to tell you more about how our solutions work and how they can help you.
Frequently asked questions
What is the difference between black box and white box penetration testing?
In black box testing, the tester has no prior knowledge of your system and the test closely mirrors a real-world attack. In white box testing, the tester has full visibility into your infrastructure and protocols, allowing for a more thorough and targeted examination.
How often should a company perform penetration testing?
There is no universal schedule — frequency depends on your risk profile, whether you handle high-value data, recent infrastructure changes, and your regulatory environment. Budget constraints may also require extending the time between tests.
Is a penetration test the same as a vulnerability scan?
No. A pentest is not exhaustive and is distinct from a full vulnerability scan. The goal of a pentest is to determine how far a simulated attacker can penetrate your defenses, not to catalog every possible weakness in your system.
Should web application firewalls (WAF) be included in penetration testing?
Yes. Studies suggest that around 65 percent of companies experience attacks that bypass their web application firewall (WAF) entirely. Testing both with and without the WAF active gives you a complete picture of your application's security posture.
What should a post-engagement penetration test report include?
The report should focus exclusively on exploited vulnerabilities — findings that are both applicable and actionable. Reports about interesting but non-exploitable discoveries are considered unhelpful and should be excluded.
What are the most common attack vectors tested during a pentest?
Common attack vectors include cross-site scripting, brute-force attacks, backdoor shell attacks, man-in-the-middle attacks, buffer overflow attacks, phishing, and distributed denial-of-service (DDoS) attacks.
References
A Guide for Running an Effective Penetration Testing Program. (April 2017). CREST.
PCI Data Security Standard (PCI DSS), Version 1.1. (September 2017). PCI Security Standards Council.
IT Security Procedural Guide: Conducting Penetration Test Exercises. (July 2020). GSA.
10 Tips for a Successful Penetration Testing Program. (November 2010). CSO.
What Is Penetration Testing? EC-Council.
Why, When, and How Often Should You Pen Test? (August 2018). Security Intelligence.
How Often Should I Schedule a Penetration Test? (January 2017). IT Governance.
Home. Hashcat.
Home. Kali.
Home. Metasploit.
Home. NMap.
Penetration Testing. U.S. Department of the Interior.
The State of Web Application Firewalls. (July 2019). Ponemon Sullivan Privacy Report.
Pentesting Stages
A hacker can jump into action with almost no preparation or planning. Pentesting is different. Projects should move through a predictable series of steps, with plenty of collaboration and conversation along the way.
The PCI Security Standards Council recognizes three critical pentesting stages:
- Pre-engagement
- Engagement
- Post-engagement
We'll walk through them one by one.
Pre-Engagement
Whether you're using an in-house team or hiring a consultant, you must have a conversation before the work begins. You'll discuss:
- The scope. What components should be included in the test?
- Documentation. How will the work be recorded for future study?
- Rules. When should the work start and stop? How far should the hacker dig before stopping? Will sensitive data be shown?
Your conversation can be short or long, depending on all of the aspects you need to cover. Ensure someone takes detailed notes, as you'll refer to this agreement as the project moves forward.
Engagement
At this stage, your team begins to dig into the details of your system and look for vulnerabilities.
As experts explain, a pentest isn't exhaustive. You may have vulnerabilities that just don't come up during the process. But your hacking team should work hard here to break through your defenses. The goal is to determine just how far a hacker can get into your servers without your detection.
A pentesting team typically looks over:
- Application layers.
- Network layers.
- Segmentation.
If sensitive data is exposed, the team should notify you immediately. And anything that the team ruins or changes during the test should be cleaned up when the work is done.
Post-Engagement
At the end of a test, you should have a report ready for deep analysis. Use that as feedback to help guide changes in your security systems.
The feedback you get should be about exploited vulnerabilities. In other words, it's not helpful to get reports about the clever or interesting things the hacker found out about your systems. Everything in the report should be both applicable and usable.
Common Attack Vectors in a Pen Test
Your hacking team could poke at almost any part of your security system as the work unfolds. But the EC-Council suggests that most focus on just seven different attack vectors.
- Cross-site scripting: A hacker impersonates a user to test the security of a web-based application.
- Brute-force attack: A hacker tries hundreds or thousands of username/password combinations in an attempt to gain access.
- Backdoor shell attack: A hacker uses malware to attempt entry, even though that person shouldn't be allowed in.
- Man-in-the-middle attack: The hacker attempts to gain access to server traffic to modify packets before they're delivered.
- Buffer overflow attack: The team attempts to flood a buffer with so much data that it fails, and the hacker gains access to memory.
- Phishing attack: The hacker attempts to entice employees and users into giving up sensitive data, which can be used to gain access.
- Distributed denial of service: The hacker floods the server with so many requests that it fails to respond to legitimate requests.
Any of these hacks could cause hundreds of thousands of dollars of damage. Spot them during penetration testing, and you could save your company both money and hassle.
Set a Pentesting Schedule
Just as no two systems are the same, no two pentesting schedules are alike. Your schedule should be customized to meet your company's specific goals and regulatory environment.
If you're not required to test on a set schedule due to a government or local mandate, create your schedule by considering your:
- Risk. Do you have very enticing data that almost anyone would want? Would you consider your company a high-value target?
- Coverage. Has your company been part of a local news cycle for some reason? Are you involved in something controversial?
- Type. Do you use open-source software? Or have you made big changes to your infrastructure lately?
Examine your budget too. A pentest can be expensive, especially if the team finds major problems that you must fix immediately. If your budget is quite small, you may need to expand the time between tests to avoid spending more than you have.
Common Pentesting Tools
Most pentesting teams use programs to enhance their work. They work quickly, allowing the team to find vulnerabilities without spending a lot of time writing code.
Well-known testing tools include:
Every team has a favorite program, and some bloggers do too. Since some are free, it pays to mix and match until you find one that works well for your system and expertise.
If you work within the government sector, you might be eligible to use tools developed by official agencies. For example, the Office of the Chief Information Officer of the Department of the Interior performs pentesting.
Some companies also offer pentesting software as a service. Contract with them, and they'll handle your work from end to end.
Test Strategies & Methods
During your pentest planning steps, you'll face an important decision. What sort of relationship should you have with the testing team? And how much should they know before they get started? Answer this question by choosing a method.
These pentesting types are recognized by the EC-Council:
- Black box: A tester knows nothing about your system before the work begins. In some cases, most people within the organization have no idea that the test is happening. This form of testing is very similar to a real-time attack.
- White box: A tester knows all about your system, including your infrastructure and protocols. Your entire team may know about the test, or you could exclude some people from that knowledge.
- Grey box: A tester knows a bit, but not everything, about your system before the work begins.
- Targeted: Your IT team and designated testers work together to look over just one part of your system.
- External: Only visible servers or assets are included in the testing.
- Internal: Only items an authorized user can access are included in this test.
You may find one method that works well for your company, and you may use that same system each time you perform pentesting. But it's reasonable to switch up methods based on your current risks.
Penetration Testing & Web Application Firewalls
You've designed an app to serve your customers, and it runs on data you've protected with a digital firewall. Should pentesting extend here too?
While web application firewalls (WAF) do offer robust security, studies suggest that about 65 percent of companies have attacks that bypass the WAF altogether.
Eliminate the WAF from your testing, and you could be missing out on a significant security issue. But you'll need to approach the problem carefully.
To perform some types of penetration testing, vendors might ask you to turn off the WAF. A simulation like this helps you understand if the app itself is vulnerable to hacking if the system goes down or you're dealing with a disgruntled insider.
But you should ask the vendor to look over the WAF too, just to ensure that it is working as designed and offering protections that are hard to bypass.
Multiple pentests like this give you a complete picture of the security environment of your app, and that could be critical for your users.
Get the Help You Need With Okta
Our solutions can help you prepare an effective pentest. And if you've been through the process and realized that you have plenty of gaps to fill, we can help with that as well.
We'd love to tell you more about how our solutions work and how they can help you.
References
A Guide for Running an Effective Penetration Testing Program. (April 2017). CREST.
PCI Data Security Standard (PCI DSS), Version 1.1. (September 2017). PCI Security Standards Council.
IT Security Procedural Guide: Conducting Penetration Test Exercises. (July 2020). GSA.
10 Tips for a Successful Penetration Testing Program. (November 2010). CSO.
What Is Penetration Testing? EC-Council.
Why, When, and How Often Should You Pen Test? (August 2018). Security Intelligence.
How Often Should I Schedule a Penetration Test? (January 2017). IT Governance.
Home. Hashcat.
Home. Kali.
Home. Metasploit.
Home. NMap.
Penetration Testing. U.S. Department of the Interior.
The State of Web Application Firewalls. (July 2019). Ponemon Sullivan Privacy Report.
