A penetration test is a sanctioned assault on your organization’s electronic assets and data. If the attack is repelled, you win. If the attack successfully breaches your defenses, technically you also win – as you’ve now got the chance to fix those vulnerabilities before a real attacker tries their luck. Given the complexity of a modern enterprise, a pen test can evaluate a wide range of assets, networks, systems, and apps on premises, mobile, and in the cloud. Our focus here is preparing to pen test your organization’s web applications.  

Preparation is vital because security flaws can occur almost anywhere in a web app system. When DevOps releases five, ten, twenty or more new versions of code every day, the opportunities for mistakes are rampant. Typically, there are two kinds of mistakes. Technical flaws can enable a variety of attacks such as SQL injection and cross-site scripting (XSS). Business logic flaws can enable attacks such as entering a negative quantity into a web shopping cart. The most prevalent web app security risks are described in the OWASP Top 10. 

Preparation should identify all elements for pen testing and who is responsible for the creation, maintenance, operations, and security of each element. This post shares ideas to help security leaders prepare their organization for a pen test to evaluate web app security and guides remediation teams for immediate corrective actions. 

  

Checklist for a successful pen test 

A strategic approach to pen test preparation is using a checklist of fundamental themes you can tailor to your organization’s specific requirements. Themes should prepare teams with a big picture of the attack surface; this will accelerate understanding results of the pen test and how to implement corrective actions. Here are four themes to a pen test preparation framework. 

1. Specify web apps 

To understand your organization’s web app attack surface, start by cataloging all internet-facing web apps. Each one provides attackers with a potential starting place to breach your environment. Assume attackers will scan for all these apps and probe them for vulnerabilities. Useful information includes: 

• Description of the web app 
• Where it logically fits into a solution or system 
• Who writes and maintains the code 
• Where the web app is hosted and associated access controls 
• Admin interfaces 
• Sensitive data types and sources 
• Where sensitive data is processed, transmitted and/or stored 
• Sensitive functionality that may impact testing

2. Clarify top concerns 

While all web apps are potential targets for attack, some are more vital than others in terms of business and operational impact. To logically establish where teams should be most concerned about web app security, here are some points to consider: 

• Create a ranking scheme to identify web app priority (e.g., High, Medium, Low) 
• Identify a specific part or parts of high priority web apps that may pose vulnerabilities 

• Confirm that sensitive data used in the pre-production DevOps environment is protected by relevant security controls 
• Correlate potential points of issue with prevalent web app security risks such as the OWASP Top 10. For example, coding mistakes might trigger a SQL injection or cross-site scripting attack, but are unrelated to security misconfigurations pertaining to hosting and accessing the production web app 
• Estimate business and operational exposure if these risks are exploited by an attacker

3. Address compliance

Compliance with government and business regulations and related security frameworks is a major driver for securing web apps. Non-compliance can result in substantial fines and penalties. Fallout from breaches and security incidents can include additional costs such as judgments from lawsuits, lost business confidence, lower business valuation, and loss of customers. With the globalization of business activity, an entity in the EU may be subject to regulations in the US or even a state such as New York or California – and vice versa. Preparation for your organization’s pen test should specify which compliance frameworks may govern your web apps, such as: 

• International Standards Organization (ISO) 
• U.S. National Institute of Standards and Technology (NIST) 
• Payment Card Industry Data Security Standard (PCI DSS) 
• Service Organization Control Type 2 (SOC2) 
• U.S. Health Insurance Portability and Accountability Act (HIPAA) 
• CREST

4. Plan for reaction 

A pen test is not the kind of report you read, store, and forget about. The pen testing report’s primary objective is to show which web apps are weak and how to fix them. This means action is required immediately, so urgent vulnerabilities don’t plaguing a high priority web app or exposing sensitive data. Your teams should be ready to spring into action. Preparation includes some aspects of theme one, and pertains mainly to high priority web apps: 

• Identify who owns each web app 
• Identify who owns operational aspects of each web app, including deployment, access control, and data management 
• Identify who owns compliance for each web app 
• Ensure that all owners and remediation teams are aware of the pen test and ready to react when results are available 
• Ensure that remediation teams are ready to react if retesting shows issues are unresolved

Pen testing in agile environments

We noted that DevOps often releases many code iterations every day. As you prepare to audit web app security, consider a modern approach to pen testing designed for agile operations. Outpost24 created its pen testing as a service (PTaaS) to make web app auditing a cloud-native continuous process for the modern app development flow. 

Figure 1: Outpost24’s PTaaS platform

The most significant difference with traditional pen testing is the “result” is not a single point-in-time audit report. The PTaaS process occurs in a continuous sequence of audit events. This means vulnerabilities are reported immediately as they occur in the new production code. DevOps team members can chat directly with the Outpost24 PTaaS team for clarifications, and remediation actions can be validated immediately.  

Figure 2: Chat with Outpost24’s pen testers

This modern approach provides many benefits: 

Speed of delivery – Establishing PTaaS should not take months or weeks. You should look for initiation of testing within days. 

Collaboration – Your DevOps and SecOps organizations should be able to talk to the pen test team through the PTaaS portal for information on findings. Collaboration should be smooth and easy, not hard! 

Validation of findings – The persistent value of PTaaS is getting continuous validation of remediation after you implement recommendations of the report. PTaaS should provide unlimited verification requests because your code will never stop changing. 

Reporting to meet your needs – Getting PTaaS reports should not have the drama of waiting and hoping to (finally!) see results, which happens frequently with legacy pen testing. PTaaS should deliver reports when you need them. 

Better ROI – With the benefits of using a cloud-native approach to pen testing, PTaaS automation should deliver better ROI compared to legacy pen testing. 

See how a pen test can help your organization  

Now that you’re armed with a framework for pen testing preparation, we invite you to see how a penetration test works in action. Click here to schedule a demo or book a meeting to answer your questions. Cyber attackers are always looking for a way in; with pen testing by Outpost24, your organization can ensure robust web app security and compliance.