Ask HN: Best practices for purchasing a Pen Test? | Hacker News Reader

Ask HN: Best practices for purchasing a Pen Test?

7 pointsjustinram116 comments

Hello,

I'm currently the Tech Lead / CTO at a small 20-person startup that has seen quite a bit of growth this year.

We store quite a bit of contact information (names, phone numbers, email addresses), and have quite a few <18 year old users (we are a high school fundraising platform). We'd like to make sure we are doing our best to keep that information protected.

I think our biggest concern at the moment is a data leak.

We would eventually like to move towards SOC2 (likely through Vanta), so I'm not sure if there is a way to "kill 2 birds with one stone" here.

I inherited this project from a contracting shop, and although I'm feeling fairly comfortable with it at this point, I'm very much in a "I don't know what I don't know" situation.

Any specific recommendations for things to look for or things to avoid? Are most companies the same in that they're just going to run a set of automated scripts against your services?

Thanks for any help!

I can only speak to a very specific example that I setup and ran at my last job for a SOC 2 annual pen test. We used a service called Cobalt Core (not affiliated), but they're kind of like UpWork for pen testers.

Aside from that, I'd imagine the general process is very similar. You define your parameters on what they're looking for, where to look for it, and what not to do. First thing I'd say is to make sure you have an isolated staging environment for them that they can attack without you disturbing them or them disturbing you.

If there are any parts of your code base that you're specifically concerned about, ask them to focus there! The goal of a pentest is to find what's broken (which it seems you're already on board with). An old CEO of mine wanted us to pass the pentest, not actually gain value from it... Take advantage of the fact they have people who know more than you and I (hopefully) to try and compromise the application.

They should give a nice write up with details on what they found and I've had a good experience asking them questions about solutions and future prevention.

I'm sure quality varies, but I wouldn't be surprised if the majority of what gets done for the average pentest are the same list of scripts that try to abuse Django admin and such, so I can't really speak to other qualities. Lots of injection focused attacks, but can't hurt for them to try.

You're better off doing a private bug bounty through bug crowd or hackerone.

Pentests are point in time assessments. Usually with one to two testers, with limited scopes of expertise.

Bug bounties can bring in hundreds of testers with a wide breadth of expertise that continuously test.

This has been my experience as well. Our pentesters didn't really find anything. It really felt like box ticking. The deluge of people from hackerone found all sorts of little gaps they missed.

In the beginning we got a lot of false positives. Things like people creating two accounts and giving them both access to the same resource (a common task in our platform), and filing that as a bug. Probably half of our reports were like this, the other half were real bugs.

Over time the reports have dropped off, but still trickle in every now and again.

I definitely think the bug bounty was much more effective than the pentest at discovering vulnerabilities.

Can you provide some detail on (fixed/ongoing) cost associated with a hackerOne bug bounty program? Is this financially feasible for a small company?

I don't have visibility into all of the costs associated. We use the bug bounty product they offer, and we define how much we pay for various types of bugs, and what targets are in scope. You can also remove products from being in scope, so you have a few levers to pull to control costs.

How do you deal with testers who try to report non-issues or really minor issues and expect to be paid big bounties for it?

Reply on news.ycombinator.com