Curious about how to stay up to speed with Penetration Testing? We’ve gathered 10 useful…
What is penetration testing?
A penetration test, or pentest, is a process where a benign ethical hacker conducts scans, probes and attacks on a network or application to uncover vulnerabilities. This doesn’t need to be a painful and arduous process.
In many ways, it’s like going to the doctor. You need a checkup, we all do. The frequency of the checkup will vary from person to person depending on health, age, medical history and much more. A pentest can be very similar in the sense that there is a third-party team of hackers or individual hacker performing an assessment on your network or application in order to determine its current security posture. The process of a pentest is not to be mistaken with a cybersecurity posture assessment.
Penetration testing is as mandatory as going to the doctor – we all need it to maintain a healthy state.
What to know before conducting a pentest
The first things you need to consider when preparing your company for a pentest are:
- What kind of test do we need? A black, grey or white box penetration test?
- How long and often will I need to complete this test?
- What are the key takeaways and findings from the pentest outcome?
This is what I’m discussing today; a sort of crash course on what we love to do for a living – penetration tests.
What are black/grey/white box penetration tests?
Black Box Pentest
A black box penetration test approach is performed on a network or application without any additional knowledge of the target and organization itself. This is often used to emulate the behavior of what a real outside attacker could accomplish by targeting someone.
The test is completed from an external perspective which will require the ethical hacking team to use various information gathering techniques to perform a better-targeted attack. Since there is limited information, the external attack surface may be limited and difficult for a tester to get into depending on vulnerability exposure.
Compared to grey box and white box pentests, a black box pentest often takes the most amount of time to accomplish and is likely to be the most expensive type of test.
Grey Box Pentest
A grey box penetration test is somewhat in between a black and white box test. In this case, an assessment team will have partial knowledge of the network’s or applications’ inner-workings.
This means that testers may still be given credentials, application walkthroughs and diagrams to perform the penetration test. However, the limitation is that testers won’t have full knowledge of the scope (e.g. versions, applications used) and are often limited to a low-level privileged account. This can often be used to demonstrate potential privilege escalation attacks from inside a network or application.
A grey box test will still require the assessment team to perform some reconnaissance and scanning/ enumeration steps in order to gather information on the target(s) before moving onto the execution phase. This can be beneficial by being somewhat of a black box test but with account credentials to increase the knowledge and attack surface of the assessment. This is why it’s called a grey box test – it includes parts of a black box test (external) as well as a white box test (credentials and limited knowledge).
White Box Pentest
This approach will be the exact opposite of a black box test, meaning that the assessment team will have knowledge of the internal structure of a network or application in order to better uncover potential vulnerabilities. This type of test is often called a glass box test due to the full visibility that the testers will have. With further knowledge of the targets in scope (e.g. specific versions, applications, code), a tester can better perform a targeted attack and more easily discover vulnerabilities or configuration flaws based on this information. Due to the low-level access and knowledge a tester will be given, it is often beneficial to work with a developer and an application security team member to better aid and guide the testers and answer any questions they may have.
Additionally, it may require less of the reconnaissance and scanning/ enumeration phase since a lot of this information is already pre-determined.
Generally, this results in a much quicker and cheaper test.
A white box pentest is often used to emulate an internal attacker within the organization. This may be someone such as a disgruntled employee or an outside user or attacker who has already gained a foothold in the target.
How long should a pentest take?
Depending on the scope of the pentest engagement, which is determined in the Statement of Work (SOW) or Request for Proposal (RFP) phases, the duration of a pentest can vary greatly.
Here, we’ll focus on the duration and frequency for both a network and an application pentest below.
Any small to medium-sized web application can typically be assessed in 5 business days.
Smaller applications can be even less depending on attack surface of the application (e.g. how many pages, if there’s a login functionality, different levels of accounts, admin features). These are things which are determined in the scoping meetings to figure out how long the assessment should take. A medium-sized application can usually be scoped at 5 days for one to two testers, however, if there are various features which require more time, then this would increase the days required to perform the pentest.
Larger applications can take multiple weeks in some cases, which can be split up by application functionalities at a higher level. For example, the payment and account functionalities can be 5 days, and the pre-authentication pages (before login) can be another 3 to 5 days if the app is large enough. Anything larger than this can be broken down into multiple assessments and conducted separately to keep the scope from growing too large and taking too long.
Network/ Infrastructure Pentest
A smaller internal network (10 to 50 hosts) can typically be completed within 2 to 5 business days, depending on the required granularity of the assessment. If you want a tester to have more time to potentially uncover more vulnerabilities on a smaller network, then 5 days should be more than enough to do so.
Any more than that should lead you to re-scoping and considering using another vendor. An external network may be about the same time frame, except they would ideally have less of an attack surface, therefore requiring less time for an assessment.
A larger network on the other hand (50 to 1,000+ hosts) could take anywhere between one, two or three weeks (depending on how many testers are involved). A tester will typically use automated scanning tools to uncover potential vulnerabilities on a large network and then attempt to exploit them individually. For a larger company this can take weeks in some cases. For an actual pentest, the vulnerabilities would be manually tested and exploited to confirm their validity. The end result will be a report with little to no false positives (a test result which incorrectly indicates that a particular finding is present). Since these reports can range from dozens to hundreds of pages, it can be easier to breakdown the tests in phases to create smaller target lists which will decrease the execution time of each assessment. For example, this can be done on targets which were involved in a major change to the network, on apps which contained a vulnerability and lead to a breach, or on separate units within the company.
When to perform a penetration test
The “when” and “how often” questions are often miscalculated or unknown to anyone who doesn’t have any experience with a pentest. Regardless of what you decide, it’s not good idea to wait until it’s too late to finally conduct a pentest after a leak or attack has already occurred. Of course, it’s better to be preventative than reactive, which is why I’ve covered the common scenarios below around when to start thinking about a pentest.
- Application launches: When an application is being built and is in pre-release, companies should conduct a pentest to uncover any vulnerabilities before being pushed to production. Time should be allotted to fix any of the vulnerabilities during the development phases and not during the production phase when it’s often too costly to fix uncovered vulnerabilities. Penetration testing should be integrated into the Software Development Lifecycle (SDLC) process.
- Major changes or updates: Any changes to a network or an application should trigger a new pentest. This can include anything such as adding new infrastructure or applications to the network, making major code updates or even relocating offices.
- Compliance regulations: Do you require to abide by any compliance standard? Do you have data which falls under any these requirements? Is there credit card data being hosted somewhere? These are some of the simple questions you need to ask yourself when determining how often to conduct a pentest. Various compliance frameworks may require pentests at different times which have varying frequencies you will need to determine. Some of the common regulations requiring regular penetration testing include PCI DSS (version 3.2), ISO 27001, HIPAA, NIST and Sarbanes-Oxley.
How often should penetration testing be done?
Generally, it is safe to say that a penetration test should be conducted at least once a year. However, a biannual assessment or even quarterly is much more expected if it’s within budget. Vulnerabilities and attacks are evolving so fast that it becomes imperative to have continuous assessments built into standard processes to stay on top of these changes.
Common vulnerabilities uncovered with pentests
There are hundreds of thousands of vulnerabilities out there, which covers a very broad range of categories.
Listed below are some of the common issues that are repeatedly-found “in the wild”. This list has been broken down into infrastructure (network) and application vulnerabilities for simplicity purposes.
- Password attacks and default passwords
- Operating system attacks – OS workstation security (Windows, Linux, etc.)
- Application level attacks – Vulnerable software
- Misconfiguration issues – Insufficient security configurations
- Injection attacks – Exploiting injection flaws such as SQL, NoSQL, LDAP, etc.
- Cross-Site Scripting (XSS) – Targeting scripts executed on the client side
- Authentication issues – Attacks around authentication and session management
- Authorization issues – Accessing or abusing functionality which doesn’t enforce proper access controls
- Misconfiguration issues – Exposed application components which are improperly configured
- Vulnerable components – Using software, libraries and frameworks which have known vulnerabilities
Each pentest conducted is going to be different depending on your selected vendor, time frame, scope and attack surface.
Before even making that first step, it’s important to know the various types of pentests so your organization can determine what will best suit your needs. A white box assessment can be standard in the industry but maybe your organization is trying to emulate a hacker or a disgruntled employee and is better suited for a black or grey box assessment.
It’s also imperative to understand the different business requirements you may have such as compliance regulations or new application launches. This will help determine when and how often to conduct a pentest.
Once everything has been completed, you will be left with some dignity (hopefully) and a full vulnerability report. These results can be used to identify the gaping issues and determine where the points of focus should be in the short, medium and long term.
When it comes to fixing your vulnerabilities, keep in mind that some issues are more important than others, and most of us don’t have unlimited resources to fix everything immediately. Focus on what’s critical to your business first and attend to the smaller issues after. This will help ensure you’re not the next big leak in the news cycles.
And of course, good luck!