/oct 25, 2016

The Importance of Manual Penetration Testing

By Willa Riggins

What vulnerability did you deploy today? You’ve run your static and dynamic scans, implemented a secure development lifecycle, and made security job one -- but how sure are you? Some security testing just can’t be automated. In the end, the only way to know for sure is to perform a manual penetration test.

Why use Manual Penetration Testing

Traditionally, MPT on its own can be expensive and does not scale in the way that automated scans do. However, automation alone is not enough to ensure an application is thoroughly tested from a security perspective. Some flaws, such as CSRF (Cross-Site Request Forgery) and business logic vulnerabilities, require a human to be in the loop to exploit and verify the vulnerability. Only MPT can provide positive identification and manual validation of these vulnerabilities. Any flaw where a real, human judgment call is needed is where MPT truly shines.

How often should an organization perform MPT on an application?

Depending on your risk management program and deployment, you should schedule a MPT annually for each application. This is at a minimum and is a very important part of the SDLC. Your application’s specific regulatory and compliance requirements may dictate even more frequent testing.  One of the best use cases for MPT is to use it as the final “check” after developers have completed remediating flaws found through  static and dynamic scans. This use case can easily be built into any SDLC that your company may be using.

Penetration Testing Challenges

Traditionally the way organizations have approached MPT is to scope out a full comprehensive MPT engagement which can take weeks of manual work.  This approach results in a more expensive engagement so more organizations are relying on automated scans.  Unfortunately this approach results in third party penetration testing firms that provide lower quality (aka: cheap) penetration tests. The problem with this approach is that many customers often confuse Penetration testing with “Vulnerability Assessments”.  Vulnerability Assessments are automated scans (i.e. Veracode’s SAST/DAST) which only detect known categories of vulnerabilities.  Penetration tests, on the other hand, detect and exploit known vulnerabilities and those without known signatures. Some penetration testing firms purposely sell a “Vulnerability Assessment” and label it a “Penetration Test”. This type of testing results in a vastly different engagement and always unhappy customers.

What you should expect from your MPT company

First, leverage static, dynamic, and software composition analysis (SCA) technologies to find known vulnerabilities, so the manual penetration testers can “focus” manual efforts on very specific areas of the application that automation may not fully cover or where false positives are more commonly reported. This approach yields higher fidelity results with a quick turnaround allowing your team to remediate flaws and get back to business in record time.

Before an MPT engagement begins the MPT team should work with you to document your specific needs and concerns, record and test logistics information, as well as discuss any scoping questions or concerns before the test is scheduled. Every application is different, and it is essential for the MPT team to understand all the nooks and crannies to ensure the right level of assurance and due diligence is given to each and every test they perform.

When it is time for your test to start a member of the team should reach out to you confirm the testing dates and rules of engagement, and provide you with a direct communication channel to the individual performing your test. If there are any issues or concerns you’ll always know who to contact. That’s the advantage of MPT -- real people with their hands on keyboard. 

Related Posts

By Willa Riggins

Willa Riggins is a technical subject matter expert with over 10 years of experience across the application development, information security, and communications domains. She is experienced with the entire software development lifecycle from several viewpoints due to prior work as system engineer, software engineer, security engineer and customer for several software, technical documentation, and communications projects.