Pentesting

Penetration testing (or pentesting, for short) is a way to assess the security posture of a product or service, and is ideally done before launch, but after major feature development has been completed.

It involves hacking the system under test from the perspective of an attacker, targeting the scenarios that a company is most worried about. For example, pentesting can uncover vulnerabilities that would lead to unauthorized access, data loss, IP loss, privacy concerns, and bad press.

Read on to learn about what this process could look like for you, when to pentest, how to prepare, what to expect, and why you can trust Lightfoot Labs to test your products.

Not ready for a full pentest? A Security Review is a lighter way to find your biggest risks first.

What I Test

What to Expect Before, During, and After a Pentest

Overall, a pentesting engagement timeline looks like this: scoping, testing, and report sharing afterwards.

#1: Scoping

With an NDA in place, we’ll discuss the specifics of what you need tested, and areas of greatest concern.

We’ll also discuss what is in scope. Scope can be tricky when there are multiple business entities involved. If you have a third-party integration or an externally managed service (such as a cloud backend), we’ll need to check on legal permissions first, or exclude that service from testing. It is illegal to hack into anything you don’t have permission for, and I take that very seriously.

After a meeting with stakeholders and technical experts on the project, you’ll receive a proposal that outlines areas to be tested, timeline and duration, pre-requisites, and cost.

#2: Testing

During the test, you can expect regular updates at a cadence that makes sense for the length of the testing engagement (typically weekly meetings). These updates will discuss what has been tested thus far, any blockers, and what areas are remaining.

If any severe vulnerabilities are found, they will be reported immediately such that the engineering team can begin on remediations right away.

#3: After Testing

The testing will culminate in a report that covers all issues found. For each issue, there will be a description, severity and impact ratings, a proof-of-concept or screenshot, and fixes/mitigations.

The report will also include things that were tested and found to be secure. This lets you know what areas are well-defended, and provides awareness around what methods or attacks were used.

Lastly, the report will cover any other high-level mitigations and recommendations, and will have a summary page appropriate for non-technical reviewers.

This report will be shared with your team, and a follow-up meeting can be arranged for questions and clarifications. I can also stay involved through remediation: reviewing proposed fixes with your engineers and retesting to confirm issues are closed. If a finding affects other vendors or customers, I can help coordinate disclosure.

What You Need to Provide

• The product or service to be tested. In the case of physical products this will likely mean two products, one of which can be physically torn down for hardware reverse engineering efforts. In the case of a system that includes a cloud backend, or a website service under test, a staging or testing environment should be provided so that there’s no disruption to “real” data.
• Any related tools for using the system under test. In the case of a physical product this might be a wiring harness or adapter. In the case of a website or cloud service this may be account credentials or other access.
• Documentation or guidance on how to use the product or service as a normal user, to reduce time spent during setup and maximize testing time.
• A point of contact to ask technical questions and to report any technical issues to.
• Other “insider” information as deemed appropriate based on the level of white box vs black box testing you’d like to do.

A word about white box vs black box testing

White box testing refers to testing where all information is given to the tester. This includes account credentials, documentation for both regular users and engineers, a list of endpoints, source code, etc.

Black box testing, on the other hand, is where a tester has no previous information about the system under test, except maybe what areas are explicitly in or out of scope to avoid legal concerns.

Gray box testing is somewhere in the middle.

Why would you choose one vs the other? Black box testing is thought to be the most realistic from the perspective of an attacker who has no insider information and wants to do harm in your system.

However, an attacker has theoretically unlimited time to attack a system, whereas pentesting engagements are limited in time and schedule. This means that white vs black box testing is a trade-off between time/cost and “realistic” scenarios.

Providing more information up front in the form of a user account, documentation, endpoints, or even source code can allow testing to be more in-depth and you get more bang for your buck, so to speak.

Any good pentester will present white or gray box findings within the context of provided information. For example, they won’t say “you have problem XYZ” without mentioning the likely steps that an attacker would need to take in order to even know about that feature or path in the first place.

Why Lightfoot Labs?

I’ve spent 12 years on both sides of the process: designing hardware, writing firmware and software, and testing embedded products for security. I specialize in embedded pentesting, with experience in heavy trucking, automotive, IoT, and consumer products, and I do ongoing independent security research. If you need testing outside those areas, I may still be able to help, or I’ll refer you to someone in my network.

Your company can trust me to deliver useful results in a pragmatic and empathetic way. My focus is on making your products more secure while educating your technical team, so they’re better equipped to secure what they build next.