Social Network For Security Executives: Network, Learn & Collaborate
Bug bounty programs are quite common these days with several of the biggest names in the industry have launched various avatars of the program. I have been asked by a few security managers and managements about should they launch a bug bounty program. Definitely bug bounty program has the advantage of crowd sourcing. However an organization should be mature and prepared enough to launch such a program. Here are some questions which shall tell you if you are prepared or not. You are ready only if all the answers to the questions are “Yes”.
( Read More: 16 Application Security Trends That You Can’t Ignore In 2016 )
Bug bounty should be adopted not as the first step but as one of the last few steps in your application security testing. If you are not secure enough and have not done the home work, it will just open an ugly face you do not want to show. Also this will expose you to unnecessary risks apart from losing a lot of money since there will be too many vulnerabilities for which you will have to pay.
Do you test your app during every release? If not your organization maturity in terms of application security testing is not enough to expose yourself to the hackers (both blackhat and whitehat) around the world.
You should ideally have a define application security management program in place. How do you test, remediate, manage and respond to vulnerabilities? Is it adhoc? Do you have a written process? Do you have an organization structure with right team, defined KRA/KPIs and management process in relation to Application Security Management?
It is bad situation to have a vulnerability reported to you but you are not able to close it fast enough. There will be several persons who will report the same vulnerability and you might have the policy to pay the one who does it first. So if your closing time is not fast enough, you have the risk of denying “bounty” to more number of persons and hence creating more number of dissatisfied souls.
Do make sure to check your customer SLAs before you expose yourself to bug bounty. Do you have a multi-tenant system? What are the bindings and the rights which are there with you or your customers? What are the SLAs and terms you have with your internal customers?
You need to check with your Chief Risk Officer or CFO or whoever who manages the Risk Management Program. Bug bounty shall definitely have implications on your organizational risk and hence it should be routed through the proper channel to measure the acceptance of the risk.
You should calculate the financial ROI before you jump in. How many vulnerabilities do you expect to be discovered? What is the amount of money you need to pay? What will be the cost of discovering the same vulnerabilities using other models like internal testing or testing through a known vendor? Does it make financial sense to launch such a program? If yes, what should be the right payout for each vulnerability?
Make sure that you create a detailed written document of the program, policies and procedures. Please get it vetted by a few pair of extra eyes. It is even better to get some feedback from somebody who did it before. Suppose the program does not work, do you have a failover and exit strategy?
You should ideally have a single owner with the right set of KRAs and KPIs defined for him/her. Also, make sure that the person is provided with the right amount of organization support to make the program successful.
Bug bounty will be successful if you have the reach and access to the right set of audience. Have you identified the channels for reach out/ marketing? You need to have a sustained program to make it work.
Bug bounty can work if executed right. If your organization is not geared up for bug bounty you can definitely work with the more traditional means like using various solutions from consultants, in-house teams or even the emerging cloud based testing solutions.