Can you describe dailymotion and the role you have within the organization?
Since 2005, dailymotion has been pioneering video streaming and delivery and is now making its comeback as a major video destination platform. I’m dailymotion’s CISO.
What is dailymotion’s history in terms of coordinated vulnerability disclosure and what milestones have you been through?
When we saw our first user notification *on Facebook*, we realized that we were lacking a proper channel for our users and the security community to notify us of potential issues.
For our users, we created a security category on our support portal, with instructions for the support team as to how to route these specific inquiries. For the security researchers, we had a email@example.com address created.
This went a long way and we had some surprisingly interesting notifications from the users, the InfoSec community and academia.
Since we later introduced a private bug bounty program, we were able to use it to reward these spontaneous notifications.
This didn’t really prevent the occasional researcher from tweeting about an issue before they even gave us a head’s up, but it really helped us build a strong experience on vulnerability disclosure that turned out to be very useful when writing our disclosure policy, that we published at the same time as we opened the bug bounty to the public.
We have made this disclosure policy available in our “security.txt” file, an draft internet standard aiming at facilitating the disclosure of security issues.
You have recently opened up your bug bounty program to the public, what’s your feedback?
We feel it’s doing great! We are still in this initial phase where most hunters are chasing the low hanging fruit and are competing to be the first to report them. It puts a lot of pressure on our security team to triage the massive amount of submissions and coordinate fixes as quickly as possible to avoid frustrations related to duplicates.
We’re happy to see more experienced hunters starting to focus on the business logic bugs that require more time to get acquainted with the product, but also are more likely to yield high value bugs. Like the hunters, these are the bugs we find most exciting!
We are also starting to see “specialized” hunters that have developed a vertical expertise on some of the technologies in use at dailymotion (Kubernetes, GraphQL, Oauth, etc.) and are able to dig very deep to uncover complex implementation bugs that may have otherwise been missed.
At an operational level, how has the program been perceived by developers?
We have quarterly planning day sessions where every team share their roadmap for the coming quarter and list the dependencies that will weigh on other teams. We have used this opportunity to announce the launch of the program so that the teams can forecast their workload accordingly.
In parallel, they are already used to the security team routing bugs to the appropriate teams, agreeing on a mitigation strategy, priority level and then signing off on the correction. After an audit, or when we broaden the scope of the bounty, we just batch the issues by team and have a weekly follow up meeting; rather than dealing with them on a case by case basis like we usually do.
Generally speaking, this is not so different from the way we treat any other bug, except that we tend to fix bugs coming from the bug bounty faster that those that would come from an internal audit.
What impact does the bounty program have on team resources? How do you adjust to deal with this?
It’s a lot of work, especially when around the program milestones.
For the workload there are several levers you can tweak to have a smoother ramp up: the assets that you include in your scope, the amount of the rewards, the number of hunters that you invite to your program. For two years we have been fine-tuning these parameters so that the program stays active whilst not exceeding our operating budget or our workload capabilities.
Regarding the expertise, we are a tech company and have a dedicated security team. In this respect we are able to internally evaluate the technical impact associated with each submission and translate it into a business risk.
What is your feedback regarding the communication with hunters through the platform?
In most cases everything goes well. On isolated occasions we would have hunters disregarding the program’s rules or communication issues with hunters that would disagree with risk rating associated to their submission.
We’re doing our best to treat the hunters fairly in the judgement calls we make, and we are asking a second opinion to YesWeHack in the few cases where we have a dispute on a reward. We have tried our best to ensure the rules are as comprehensive and as clear as possible to manage the community’s expectations and as far as possible we try to stand by these rules whilst staying open to discussion.