Sign In

Insights

Interview with a Penetration Tester

We are often asked for advice on how best to prepare for a penetration test. I sat down with Adrian (we’ve disguised his real name to protect his inbox), Sr. Pen Tester at Strike Graph, to get the insider scoop on the pen testing process. Adrian is an extremely valuable, albeit modest, member of the Strike Graph team. Though he would much sooner open up about his sweet dogs or his love of camping, he is highly decorated with a panoply of impressive certifications and accomplishments. Adrian is a CSSLP, has a Masters in Software Engineering, and has so many technical certifications we had to cap the list at seven during our interview. 

His original career goal was to become an application architect, but throughout his career he discovered a theme of security gaps in the IT programs of some of the major corporations he worked for. Over the years Adrian developed and honed his security skills, and added GWAPT - GIAC Web Application Penetration Tester  to his already bountiful collection. We are incredibly fortunate to have him as our resident pen tester (aka “ethical hacker”) here at Strike Graph. He was kind enough to share his insights on penetration testing, and how best to prepare your organization for one.

Q: When does an organization need to get a pen test, and how often should they renew it?

A: An organization should get a pen test every time their solution architecture changes, when they add new components or services, or when there is a change in their data management system. Basically, organizations should get a pen test every time their app changes. There are other instances when a pen test might be necessary. For example, when you’re starting a new business, or when you’re getting audited to pursue a SOC 2 attestation. Generally organizations need a pen test about once a year.

Q: What steps should an organization follow to prepare for their pen test?

A: It’s honestly not very difficult to prepare for a pen test. Your tester is trained to think from the perspective of an attacker, so all you need to do is prepare your documents and let them do the heavy lifting. If you don’t have one already, you may need to prepare an Incident Response Plan. Other than that, be ready to provide your pen tester with the following:

  • Your organization’s legal name
  • An internal understanding of your application’s architecture, including:
      • Infrastructure
      • Services
      • Data Storage
  • Roles, and types of users your application supports
  • Connectivity to your application: is the application accessible from the Internet? Do you need to use a VPN to access it?
  • A map, or other indication, of your application’s high usage times throughout the day
  • Identify key technology stakeholders that need to be available during the pen test
  • Access to your organizations Incident Response Plan (this is not mandatory, it can be very helpful)
  • Having monitoring tools in place is also not mandatory, but can be helpful

Q: Does the organization need a retest if the pen tester reported any findings?

A: Yes, you’ll need a retest once you’ve done your best to remediate any findings. This is the best way to ensure that your system is truly secure. If no "critical", or high-risk vulnerabilities are discovered, then it’s possible to delay the re-test.

Q: In your experience as a pen tester, what are the most common mistakes that organizations make?

A: The most common mistakes I see people make are around logic flaws. A logic flaw is a term we use to denote when a company takes a business centric approach to their product, rather than a holistic approach that includes security. By focusing on your business goals, you can unknowingly enable an attacker to do something nefarious because you’re not thinking about the architecture from a security perspective. My suggestion to organizations that want to reevaluate their architecture through the lens of security is to implement security by design principles or threat modeling

I also see repetitive errors in SQL injections and Cross-site Scripting. Recently, I’ve seen an increase in organizations making mistakes using GraphQL. GraphQL has features that enable introspection query, meaning anyone with access to that technology can access the schema of your database through the API. It’s the equivalent of “peeping behind the scenes” of your database.

Q: What’s your favorite part of the penetration testing process?

A: I enjoy performing the vulnerability test, and subsequent exploitation. This is where I get to really dive in and see how deep I can go trying to discover and exploit vulnerabilities. When I’m authorized to do exploits, I like to attempt to get a dump of the database. This is my personal favorite part of the process. Also, I get a big kick out of phishing attacks. This is the part where you can interact with, and play mind games with the users. It’s arguably the most comical aspect of penetration testing. 

Q: Any last words of advice for organizations that need a pen test?

A: My advice is that you should get used to getting regular pen tests. Because if you don't hire a professional, a hacker will find the vulnerabilities first.

 

 


Your blog post content here…

Jordan Bellman
Jordan is a member of the Strike Graph Customer Success Team. She is passionate about easing her customers' stress and confusion by helping them navigate their compliance journeys with ease. She has a background in literature and Human Resources, and in her free time she loves to cook, read, and hike with her dog.

Learn how you can leverage Strike Graph for your cybersecurity needs