Analysis

TECH Talk Q&A: Penetration Testing

Stroz Friedberg is a specialized risk management firm built to help clients solve the complex challenges prevalent in today’s digital, connected, and regulated business world

We have collected and summarized some of the top questions we received from our recent webinar, “Modern approaches to Penetration Testing“, discussing traditional Black-Box Penetration Testing and Hybrid Security Assessments.

For more on this topic watch the full webinar here.

1) Is “Hybrid Security Assessment” just a fancy name for Grey-box or White-box assessments?

The name is not important. The main point is that Hybrid Security Assessments offer a flexible approach that can be tailored to specific security requirements. This means that although there are many items that would be very useful to have access to, they are not all a necessity to conduct a Hybrid Security Assessment.

For example: Having source code is great, however, in cases where we do not have access to source code, we have used information such as Code Analysis results from a security code scanner to tailor the security test cases.

The bottom line is that information is the key to a successful pentest; the more information provided to our team, the better the results that can be provided to the client.

2) Wouldn’t a “Hybrid Security Assessment” require more time and effort than a black-box pentest?

No. Hybrid Assessments actually minimize the time required to generate specific security test cases. This enables the pentester to maximize their time and effort, within the given constraints, to provide the best security assurance for the client.

For example: In most cases, to find a possible SQL injection, it is much quicker to observe a dynamic SQL query within a source code file than to inject SQL payloads into a web form. Also, if there are weak application blacklists functionality added to the application as part of a security bug fix, then it is much easier and faster to observe this in code, generate a test case to bypass it and confirm it via dynamic testing. Bypassing such applications blacklists would have taken a pentester trial and error to send multiple payloads, then derive the blacklist that could be implemented and figure out SQL payloads that would bypass such checks.

3) Many consider it risky to run pentests in production and request to conduct a pentest in a test environment. How can we get assurance that such tests are effective and applicable for production?

The ideal scenario is to ensure that the test environment is an exact replica of the production environment – but in reality this is not often the case. Some of the ways in which we test for this is to validate the security issues found in the test environment in the production environment as well. Another way is to perform a configuration and deployment review (CDR) of the production environment as part of the pentest conducted on the test environment. Please contact us if you would like additional information about what can be covered as part of the CDR.

4) Source code is considered to be confidential information. How do you ensure such data is handled securely?

Our team ensures that all sensitive data such as source code or any other data that the client considers to be confidential is secured, both at rest and in transit. We are happy to discuss the specific requirements, security procedures as well as any additional controls the client wishes to put in place.

5) What is the difference between traditional Penetration Testing and Red Teaming?

On the face of it, Red Teaming and ‘traditional’ penetration testing might look alike on some aspects, but they have many fundamental differences.

  • Red Team is ‘depth’ driven – how far into an organization can you infiltrate. It will commonly exploit some vulnerabilities to achieve the objective, but it will be done mainly through a single attack path. Red teaming is not attempting to utilize all possible attack vectors to achieve the objective. Penetration testing is often regarding a ‘coverage first’ exercise, in that as many vulnerabilities as possible are identified but not necessarily exploited.
  • Because of the goal, the Red Team needs a broad scope. There shouldn’t limitations on what can be attacked, otherwise some attack paths may not be possible, potentially giving a false sense of security. A regular penetration test will be limited in scope. Only specific URLs or servers that can be targeted.
  • The Red Team is often going in ‘blind’, having to perform some initial reconnaissance. Penetration testing can be black-box, but most of the time there will be at least information about what the technology is in use and potentially documentation as well etc.
  • Red Teaming is using a “low and slow” approach. Trying to remain as stealthy as possible. We do not usually perform port scanning or other noisy attacks which are typically used in a penetration test.
  • During Red Teaming you might end up using a wide variety of techniques and attacks, such as social engineering or network poisoning which may not be an option during a normal penetration test.
  • Finally, there is also fundamental difference in the fact that the Red Team is procured at the C-suite level or by the legal counsel, whereas penetration tests are usually requested by project teams.

 

Commentary, new discoveries, and innovative ideas
right to your inbox.
Stroz Friedberg

Sorry! You are using an older browser which is not supported by this website.

Please download one of these free browsers to enjoy all our website has to offer:
Firefox, Chrome or Internet Explorer.