Presentation of Matrix Requirements and your position
Before we co-founded our German company, Matrix Requirements (matrixreq.com) in 2014, we were project managers in a medical devices company and it was clear to us that we needed a better tool to manage the traceability of the design. We built MatrixALM for ourselves and later on we created Matrix Requirements to launch our application independently.
Matrix Requirements team is 4 people which is quite honorable compared to our results so far: we have about 100 customers totaling about 700 users.
30% of our customers come from the US, about 30% from Germany and the remaining in rest of Europe, Israel, Australia, India, Canada.
My role in the team is more on the back-office, network, databases, Linux servers. Needless to say I’m very concerned about security.
What are the reasons that led you to embark in the bug bounty exercise ?
Even though we are quite small, we are certified ISO13485:2016 and on the way to be ISO27001, and this type of standards mandate that we study the risks of our processes. Of course one obvious risk in our type of business is the intrusion of our information systems.
We’ve had intrusion attempts in the past an we protected ourselves with quite elaborated active rules on our firewalls. We’ve had an audit from a group in KULeuven, and one of their recommendations was to go through a bug bounty exercise.
Why did you chose YesWeHack ?
We first asked a well known US bug bounty company but the pricing was out of reach for us. Then we discovered YesWeHack, through the OVH DLP accelerator (we are also members). We contacted them and found out quickly that their offer matched what we were looking for: a group of researchers that could investigate our security in BlackBox mode. In particular we wanted to be able to talk to the researchers in English and that is a given on that platform.
What are the results of your private phase ?
The private phase was achieved with a group of 10 researchers, and they came back with 5 vulnerabilities. Frankly, we were relieved that none of the reported vulnerabilities were severe, which confirmed that we already had quite a good security maturity.
Of course we can never rest in this field, but what were returned to us were subtle weaknesses that wouldn’t allow by themselves anyone to actually enter our site.
We rewarded the researchers anyway, understanding that sometime a combination of small weaknesses could lead to an actual attack vector. The exchange with the researchers were very fruitful and they gladly checked that our fixes were efficient as well.
That dialogue is really the positive aspect of the exercise: we forced ourselves to reply quickly to the remarks, and they were very quick to answer back and offer suggestions to solve the issues if needed.
What are you waiting from the public phase ?
Opening the bounty to all the ethical hackers on the platforms in YesWeHack should lead to much more return for us, and should help us solidify even more our application and its API. I hope nothing too bad will come out of it but of course I prefer hearing about it this way: we have to detect potential security issues as soon as possible.
A bug bounty program is a practical way to put your work to the test. We hope to learn a lot from this public phase – through ways that we wouldn’t have thought about ourselves.
Today more than ever (think Facebook, British Airways, …) we must stay humble and remember that ‘Security through obscurity’ doesn’t exist and it’s only by putting your cards on the table and be pro-active that you can ensure a decent level of security.