If you run an exchange, it’s frighteningly easy to screw up and lose everyone’s money. One way involves finances – making poor financial decisions or taking risks with customer funds. Another way to lose everyone’s money is to suffer a huge hack. The only way to prevent the second fate is security discipline and layer upon layer of defenses.

Paradigm is not a traditional exchange, and we do not hold customer money. Buyers and sellers meet on Paradigm and then settle trades on a different exchange. But even though we don’t actually hold customer money, we still run a marketplace where that money swirls around, so to speak. Therefore, the security of our infrastructure and code must still be our top priority.

‍

There are many aspects to that security. We use strong authentication to make certain that employees and customers are who they say they are. Authorization and the principle of least privilege minimize the set of people that can see and break things. Encryption can keep data in transit and at rest safe from those who might want to see it. Audit trails leave behind a record of who did what. Monitoring makes sure that bad stuff isn’t going on under our noses.

Beyond that, the code we write has to be secure. It’s no good having a secure infrastructure if we’re going to run code on it that has gaping holes. We have processes in place for this, too – source control systems, code review, training, static code analysis, and more. But engineers are fallible, third party code we rely on is fallible, and sometimes different systems interact in unexpected ways to create insecurities.

Therefore, testing for security issues is critical. In the spring of this year we used a well-regarded independent penetration testing firm (the “pen testers”) to find security vulnerabilities in our product. The way that works is we give the pen testers accounts, an environment to play on, a basic architecture diagram, and then they go off and hack on us. We came out of the experience reasonably well – they found some issues and we fixed them.

Taking this testing to the next level means making pen testing continuous over time – and by inviting anyone in the world to come and hack on our product. This is the role of a bug bounty program. A bug bounty program is just what it sounds like – we invite hackers to attack our product and then pay them a bounty for each security vulnerability that they find.

‍

We could attempt to set up this program ourselves in-house – define the program, tell people about it, review submissions, reward hackers – but it’s a fair amount of work, and we frankly would not attract that many hackers. Instead, it’s a far better plan to get someone else with a large stable of hackers and the infrastructure to run a bug bounty program to do it for us. After researching our alternatives, we chose HackerOne to run our program. They have really good infrastructure and the largest pool of ready-to-go hackers out there.

We launched an invitation-only program with them in late August of this year and have had very positive results. They manage the hacker invitations, the vulnerability reports, deciding on report severity, and handling the money. We just have to fix things! Like the pen testers, they’re finding real issues and we’re fixing those issues.

Comparing a pen test to a bug bounty is an interesting exercise. Penetration testers are great. They are professionals and they are very good at what they do. However, there are some drawbacks to using them. With a pen tester you pay a set amount of money up front, no matter how many issues they find. And you get maybe two or three people who go over your product very carefully. In a bug bounty, by contrast, you only pay-per-issue, and the variety of people and approaches employed is far more diverse. We’ve been impressed.

If you’re a hacker, you too can submit any vulnerability you find in our product to our Bug Bounty page. You can also contact us at security@paradigm.co. And if you’re interested in working at a company where security really matters, have a look at our careers page.

Article by

Mike Yoder

Principal Engineer