Pen Testing, (short for Penetration testing), is a manual security review of your applications, and it's an important factor in effective cybersecurity. Application security testing can be automated, but automated procedures cannot find every vulnerability in your software. Some industry compliance regulations require penetration testing. If you are about to have your first penetration test on your software, you can expect your application testing to follow several phases.
Why Have an Application Penetration Tested?
Before you start a penetration test, you might wonder why you even need one. Several automated solutions will scan your software for vulnerabilities, and static application security testing (SAST) tools will scan code as it's being developed. With these tools available, you might think your software is free from vulnerabilities, but SAST and other cybersecurity testing tools can't account for sophisticated attacks exploiting business logic.
Penetration testing adds another layer of security to your application. It's performed by a white-hat hacker with several years of experience in the industry. A penetration tester might be a researcher or even an executive who wants to practice skills during off-peak business hours. All white-hat hackers have their own background and experience, so most businesses find a company with penetration testing services. The company finds the hackers, and you can simply help get the process started.
For some strict compliance regulations, having your application penetration testing is a requirement. Most companies that store customer data must be compliant with several regulatory standards, and a penetration test ensures that application vulnerabilities are not the source of a severe data breach, which can lead to hefty fines, litigation, and brand reputation damage. For example, it's important for banks and insurance companies to have their applications penetration tested to protect customers' sensitive information.
Phase 1 - Discovery
For an attacker, the first phase is reconnaissance of the target organization. An attacker reads social media and reviews information on the organization's public-facing website. A white-hat hacker does the same, only the information comes directly from administrators and organization stakeholders.
The discovery call is a time for the tester to get to know your organization, its goals, and the purpose of the application. Testers also need to know the scope of the project. Your application might have several moving parts, and only a few need to be tested. The tester must know what parts of the application are in scope and must be tested. Scoping out a project is important to avoid wasting time on unnecessary testing, causing delays in the estimated time of completion, and increasing costs.
Phase 2 - Automated Scanning
Even white-hat hackers have tools used by blackhat hackers. Scanning tools simulate the same methods that a blackhat hacker would use to find vulnerabilities in your software. The scripts could be custom-built by the penetration tester, or the scripts could be common ones open on darknet markets. The goal is to emulate a real-world attack to find vulnerabilities.
The scans used in a manual penetration test are called dynamic application security testing (DAST). Most of these tools are available for purchase, so the organization can have them on hand for future feature releases and additional application deployments. Performing basic scans is always recommended because it will find basic vulnerabilities and alert developers.
If critical security flaws are found in this phase, the penetration tester will alert the organization so that they can remediate them quickly. Critical flaws are usually low-level easily found issues that could disclose your data to the public.
Phase 3 - Manual Exploits
Not every vulnerability can be found using automated scanning methods. After automated scans are completed, the next step is to find exploits by manipulating business logic. For example, a white-hat hacker might exploit business logic to inject malicious code into your application, which is then rendered to the user. This exploit is called reflected cross-site-scripting (XSS), and it's a way for attackers to steal sessions, cookies, and other valuable information.
A penetration tester has numerous ways to find and exploit software vulnerabilities, and the methods used depend on the application, how it's built, and the penetration tester's own technique. The tester might have a team member to help so that they can pool their experience together to find as many vulnerabilities as possible.
Phase 4 - Analysis and Reporting
All issues are documented and reported, and a proof of concept (PoC) is provided to you so that you can reproduce the issue. The report will list all issues found and their risk values so that you can prioritize issues. An issue with a low-risk value is not as critical to business continuity as a critical or high-risk issue. The penetration tester will go over the findings and explain them to you so that you understand the exploit and what's possible should an attacker find the vulnerability.
Phase 5 - Remediation and Re-Testing
After you get the penetration tester's report, you must remediate the issues. It can take weeks to go through all of them. Some issues might be an overhaul of the application, which could take several months. Developers might push back on some issues or put them aside for future releases. In some cases, the cost of remediation is more than the cost of absorbing the risk, so it makes good business sense to leave it.
After you remediate all issues, you send it back to the penetration tester to re-review all issues. The tester will perform the same scans and exploits that were performed the first time to determine if the issue was properly patched. If not, the issue is marked as unresolved. The penetration tester will also go through the software again to find any new vulnerabilities. It's possible that remediation introduces new vulnerabilities, so the software must be tested again. The process then continues until issues are resolved.
Conclusion
Having an application penetration tested greatly reduces the risk of a data breach due to your application's vulnerabilities. It's a long process but well worth the effort, especially if your application stores sensitive information. A good penetration tester will find vulnerabilities, but you can also use scanning tools to find common issues in your application before and after it's been tested.
Final Note
Envative has had independent Pen Testing of custom software applications performed by 3rd parties that specialize in exposing software security vulnerabilities. Our applications passed all such testing with flying colors.
If you are looking to implement a custom web, mobile and/or IoT enabled application for your business, please reach out to me to discuss. We'd love to help.
Tagged as: Software Development, software testing
About the Author:
Marc Mastrella is Business Relationship Manager at Envative. He regularly engages with potential clients to discuss how software can solve real-life problems within organizations. He connects those pursuing a software solution for their business or looking to bring a mobile app/IoT idea to life with the talented developers at Envative for brainstorming and consultation. Marc sees first-hand what a difference the right technology can do for a business and does all he can to help make the process easy.