Using Strike for penetration testing at Kinde

Penetration (pen) tests are an important part of protecting your organization’s information and systems. A pen test goes beyond automated vulnerability scanning by having an experienced security professional probe and test your systems looking for weaknesses, using the same techniques and tools that malicious attackers would use. The result is a clearer picture of how secure your systems are and valuable insights into how to better protect them.

What better way to feel secure than to pay a professional hacker to attack you?

While the benefits are clear, there are complexities and costs involved in pen tests. That’s why planning is crucial to ensure the cost to benefit is favourable for your business.

While this post focuses on one vendor that we’ve worked with, it doesn’t mean they are the right choice for you. We believe pen tests are great value and want to share our positive experience. We might even change vendors if our own requirements change. So while this is a success story for us, always do your own due diligence.

The most common reasons for needing a pen test is to fulfil a prospective customer’s due diligence requests and compliance requirements.

Customers may request a pen test report as evidence that a vendor takes their security seriously. They want to review the testing methodology, any findings, and validate that vulnerabilities have been remediated. Independent testing also adds a level of trust because you are not just taking a business’s word for it that they are secure.

Compliance frameworks like PCI-DSS require a pen test to be run annually or after significant changes when your company is handling card data. Requirement 11.4 states that external and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weakness are corrected. And while ISO 27001, specifically Annex A 8.8 management of technical vulnerabilities, doesn’t require a pen test, they recommend that planned tests are run by competent and authorized persons to support the identification of vulnerabilities.

Every pen test vendor will do things their own way, but all tend to follow a few common themes with the goal to surface any vulnerabilities before an attacker finds them.

Pen tests are usually split into a 4 high level phases, and some may have more depending on how large the scope and test will end up being.

• Planning - Where the scope of the test, rules of engagement, key contacts, goals, time of day, or anything else that needs to be prepared prior to testing
• Testing - The pen tester will use the information provided and test the security controls of your systems
• Remediation - Any vulnerabilities found need to be remediated or fixed
• Retesting - A retest will be performed by the pen tester to check that your changes closed the vulnerabilities

There are three methodologies to help scope a pen test, which is completely up to you to decide and may be influenced by how mature your systems are or whether the test needs to be done on production.

• Black box - On the outside with limited or no prior information and is trying to break in
• Grey box - Provided with some level of access, such as basic user accounts or a specific system to target
• White box - Provided with lots of internal information such as documentation or admin level test accounts

And then there’s a few types of pen tests that will be determined by your own security goals or compliance requirements.

• Network - Scans for vulnerabilities in your network or infrastructure, which can be done both externally from the public internet or internally inside a private network
• Web application - Scans for vulnerabilities with your application architecture and data flows, which also simulates how a user would access your web application and can surface data leaks
• Mobile application - Specifically targets mobile apps and how they interact with the device and your systems

Pen tests have always been integral to our security to ensure there aren’t vulnerabilities in our product. During our due diligence process, we scanned a number of providers, both old and new, in trying to find a partner that suited our specific needs.

It felt modern and suited to the way we do business.

Strike jumped out because of their modern approach to security testing overall, which includes pen tests, automated vulnerability scanning, and cloud posture scanning. Tests could be organised, planned, and launched from their web dashboard without a long sales cycle. Results and commentary from the tester would be immediately available for our review while the test was ongoing.

If you want to check them out, sign up for free and play in their dashboard to get comfortable with the questions and layout.

While the remainder of this article speaks to our specific experience with Strike, most penetration testers will offer a similar high level process and can be used interchangeably depending on what you think is best for your business.

Setting up a pen test in the Strike dashboard was really easy. First, we loaded our account with funds, which translated into testing hours.

Once we allocated the hours, we created a new pen test project and filled in details about what we want tested. It also provided a place where we could provide the tester with information in advance such as technical diagrams or instructions on how to access certain systems.

All the topics, such as targets, scoping, time of day, credential usage, etc are captured in their web portal. Easy.

For our test, we requested that the pen tester (they use the term “Striker”) spend about half their time focused on a specific part of our authentication flows and provided instructions on how the technology works. The remaining time was to test anything they felt relevant with our main production endpoints.

A pen tester was ready the following week, but we could have had them sooner if we’d requested urgent testing. A brief intro was made with the team over email and a Slack channel was created for collaboration. I’ve redacted out the sensitive information in the following screenshots.

Our pen tester started with high level recon of our endpoints and any open source intelligence. We followed this up with a video call to demo one of our test systems and answer questions over a screen share. After this, all regular communication was done over Slack. They provided daily progress updates throughout the week detailing what they tested for, screenshots showing their positive or negative outcomes, and some commentary about what they were going to try next.

We loved the regular updates and the level of detail, because it let us provide instant feedback or immediate insight to why our system responds in a certain way. We knew the pen testers would be more effective if they had fast feedback and inside information.

When the test was completed, the pen tester entered in their final update and then a report was automatically generated for everyone’s review.

None of the information in it was a surprise because we’ve been watching the updates and commenting throughout the week. They had also already prioritized the findings and had answered our questions as we went, so there wasn’t much need to have a closing meeting either.

Depending how a pen test goes, findings can be shocking and even disastrous for a business. But it is always better to know about a vulnerability and fix it sooner, rather than being maliciously attacked and fixing too late.

While our experience has been positive, feel free to contact us with questions about Strike. You can also request to review our results report as part of your own due diligence. In the meantime, here’s our general security information for Kinde.