Introduction
New startups, especially those in the B2B space, should conduct yearly penetration tests once their MVP is built and has been validated. This is often a requirement for enterprise customers, and can be crucial for compliance standards like SOC 2 and ISO 27001.
At DemoHop, our ideal customers from the get-go were Fortune 500 companies, so we knew from the beginning penetration testing was going to be a requirement for us. Here I’ll break down our experience to help you navigate your own startup’s first penetration test.
Step 1: Make a plan
The first step is to make a rough plan. This should include things like scope, timeline, and budget.
Scope
Typically for early-stage startups, applications and infrastructure are relatively simple. Your first pen test will likely focus on your application, APIs, cloud infrastructure, and/or internal networks. Pen testing firms may also ask which end user roles you want in scope. You’ll have to identify and define a scope for what makes sense to you based on your circumstances and budget.
Timeline
In general, you should expect the pen testing process to take around 3 months end to end. However, this can extend longer if:
- Your chosen firm can’t start for a while.
- Your architecture is complex.
- A lot of vulnerabilities are discovered.
- It will take a long time to fix said vulnerabilities.
Budget
For an early-stage startup, costs should typically fall in the $7,500-$15,000 range. This should directly correlate to your scope size, so if your scope is large this could be higher.
Step 2: Shop for estimates/quotes
This step will feel very familiar if you’re a home owner! 😀 Just like you would for getting any house work done, shop for 3-5 quotes. Even the process is similar – do some Google searching for pen test firms, reach out to them via their form or email on their website, and schedule consultation calls with each of them.
The call is straightforward: they’ll want you to describe your application at a high level, ask roughly what you want in scope, your ideal timeline, and ideal budget. You’ll want to ask them things like:
- Can you describe your testing methodology?
- What does the overall process look like end to end?
- What’s your balance between white, gray, and black box testing?
- What’s your balance between automated vs. manual testing?
- Is my desired timeline feasible and when can your team start?
- Can you send an example final report so I can get an idea of what to expect?
After the call, usually within a couple days, they’ll send you a statement of work (SOW) along with a price. Then simply compare the estimates you receive and pick one!
Step 3: Kickoff
This step’s typically very quick and easy. Often it’s just a quick kickoff call to reiterate the plan. Sometimes the firm’s testers will need access to things, user roles provisioned for their emails, their IP addresses whitelisted on things like firewalls or rate limiting policies, etc.
Speaking of access, you should have the testers perform their testing in a non-prod environment when possible. This may sound obvious but it’s important. Their testing will likely include things that could disrupt a production environment (like a denial-of-service test), and you do not want real end users impacted.
Step 4: Testing phase
This is the main phase of the overall process. Here is where the firm’s testers will try their hardest to find security vulnerabilities in your system. For a web application, for example, they’ll likely test at least the following:
- Unnecessary pages exposed
- Exposed sensitive information on public sources
- Injection (SQL, command, LDAP, etc.)
- Cross-site scripting (XSS)
- Cross-site request forgery (CSRF)
- Path traversal
- XML external entity (XXE) injection
- Server-side request forgery (SSRF)
- Broken authentication
- Session management vulnerabilities
- Insecure direct object references (IDOR)
- Unrestricted file upload
- Client-side template injection
- Server-side template injection
- Race conditions
- OAuth vulnerabilities
- Improper input validation
- Remote file inclusion (RFI)
- Local file inclusion (LFI)
- Security misconfiguration
- Improper authorization
- Sensitive data exposure
- Insecure deserialization
- Using components with known vulnerabilities
- Memory corruption / buffer overflow
- HTTP header injection
- Business logic errors
- Clickjacking
- SSL/TLS weaknesses
- Improper error handling
- Password complexity weaknesses
If this is your application’s first pen test, don’t be surprised if many vulnerabilities are found. They’ll likely categorize them as Critical, High, Medium, Low, and Informational. Ideally your firm will also include a description, steps to reproduce, remediation recommendations, and resources to learn more for each finding. Luckily, even if your first pen test has many findings, subsequent pen tests in the following years should be much better.
Step 5: Remediation testing phase
Once the initial testing phase is completed, your pen test firm should issue a report to you will a full breakdown of everything.
Now the ball’s in your court to fix the discovered vulnerabilities. Typically, firms include a 90-120 day “remediation” period where your team will fix each vulnerability then the firm will re-test to make sure the finding has been fixed.
At DemoHop, since we prioritize security so much, we’ve always asked firms to notify us immediately if any vulnerabilities have been discovered. We want to fix issues ASAP, so we don’t want to wait for the initial testing phase to finish before we learn about findings. In fact, in our last pen test, our team was fixing findings at the same time the pen test firm was doing their initial testing phase. This was beneficial because 1. we fixed issues immediately, and 2. the entire process went faster because we were all working in parallel.
Step 6: The final report
Finally, once all testing has concluded, your pen test firm will issue a final report to you. This is a very comprehensive document that outlines everything. Typically a table of contents will include:
- Summary of work performed
- Testing methodology
- Executive summary
- Remediation testing summary
- Findings (each discovered vulnerability will have its own section)
- Conclusion
If you’re selling to enterprises, they will often require to see this. It’s helpful to have a “trust” page on your website where potential customers can request access to this document. For example, we at DemoHop have ours at https://trust.demohop.com, and those under an NDA can request access to our latest pen test report there:
What's next?
One great thing about doing a pen test is you and your team will likely learn a lot of new security best practices that you weren’t already familiar with. Having these in mind will make all future development easier and more secure.
You’ll likely have to do annual pen tests, especially if you sell to enterprise customers or have any compliance requirements. Luckily, the first pen test is the hardest one, and it should get easier every year going forward.
Now that you have a completed pen test, go share it with your customers under NDA to show the strength of your systems!
