Large databreach, how to minimize online vulnerabilities, and improve responsetime

Last week I found a data breach in a large companies website, exposing over 2 million customer records (name, address, email, phone number)
It’s always a though choice, do I call it in and risk getting sued, or leave it? Since this was quite a big leak, which I more or less stumbled upon (think in the lines of ‘this looks odd, what happens if I try and change this’) , I just went ahead and stated my intensions very clearly in my messages, and hoped they would see it would benefit them to use my report, and fix the problem as soon as possible.

At first I had a hard time coming into contact with the right person (it was a saturday evening), on monday (after sending, twitter, facebook, linkedin messages)
I decided to just use the websites product support form and hope the support emloyee would understand this is a priority case, and send me to the correct department.

My first mail was really basic with not much information, only stating I found a databreach and wanted to receive the correct contact information.
Luckily I got an almost instant response, telling me he understood the severity of the situation, and asking for more information so he could forward it to the right people, and keep me updated in the process.

The webservice stayed up for about 2 more days, but then they took it offline, and informed me they will put it back up after the issue has been resolved.

They have informed me a couple of times about the progress, through mail and phone which I really appreciate, it feels good to be able to help out.
They scanned their access logs, and luckily I was the first and only person who has gotten access to their system, but as a result they will start scanning all their web services, and I think it will be a top priority in the future, which is a good thing.

This case, and previous cases I came across gave me some insights that companies can consider to improve their online security:

1. Take your customer data security seriously
   data leaks are very common these days, lots of companies have lots of data, and dozens of different web applications running to serve their customers, map out your different webservices, and try to pinpoint any old services, or externally built APIs, and start working down the map:
   • USE HTTPS please, i still come accross a lot of http apis (for mobile phone apps, and other applications).
     but keep in mind, https traffic can also be monitored and your api calls will still be visible, don’t think switching to https will solve all your problems.. You still need to secure your apis in the same ways.
   • Document the API, if no documentation has been made, you need to know exactly what data is available, and why.
   • is user authentication and authorization in place in all the public accessible endpoints (api keys, or any other authentication scheme)
   • If non available hire a security engineer to see if your apis can be abused, or vulnerabilities exist.
2. Dedicate at least half a day a week on trying to find frontend & api vulnerabilities
   In my opinion a friday afternoon is perfect for these kinds of things.
   Developers worked all week, creating new functionality and fixing bugs, while productivity on normal everyday work will be lower on a friday, having developers read and test other developers work, trying to break the functionality to see if it is secure will spark new motivation, and is a great way to improve team spirit and coding standards. And if some time is left, going through existing functionality is a big plus.
3. Have a responsible disclosure policy, with a direct contact emailaddress.
   I know philips and sony have a detailed explanation on how you need to report vulnerabilities:
   Philips Responsible Disclosure
   Sony Responsible Disclosure
   They have a direct contact address for reporting vulnerabilities, which shows they take security issues seriously. Adding this to your site will give the person who found a vulnerability the confidence to send you  a report. And it will decrease your responsetime, since in my above example I had to message multiple times before getting forwarded to the right departement.
4. Have the proper procedures in place before the first report comes in
   • Who will receive and classify the report?
     
   • Who is is in the critical issue response team, what are the next steps?
   • Who handles updating the reporter, and what’s the response time?
   • etc..
5. Consider signing up for hackerone or another bug bounty program
   Hackerone is a great platform for security engineers and companies to hunt down bugs on your website and receive a thank you or a bounty (depending on the severity.) You can add guidelines and provide the scope of where the engineers may try to find bugs on your site (like: no bruteforcing, frontend only, dont delete data etc..) and you will receive valuable information on your sites security, with the added benefit that the people are reporting it to you, instead of malicious users exploiting your website, and stealing your data.
6.  Logging data
   The company I reported to had extensive logs in place, so they could assure no customerdata has been accessed before me. I would even consider parsing logs with anomaly detection algorithms to detect malicious requests as quickly as possible.

This is not a complete list, but will get the ball rolling for you, I hope to add more in the future, any input is always welcome.

Vulnerabilities can be found in any piece of software, no matter the size of the company, I won’t pretend I never made or will make coding mistakes, but if you implement some of the ideas from the list above, it will minimize your companies vulnerabilities drastically.

if I had to choose only one from the list, I think I would go with number 2.
Having other colleague developers read your code, and test your commit, they will look at your project from a very different angle, and because they look at the project with fresh eyes, they will spot mistakes more quickly.