Data security officers typically look for security risks by monitoring reports from automated security systems, listening to employees’ reports of security issues, and/or auditing IT systems. Some security officers, however, rely on a somewhat unusual source – the public. They look to clients, customers, consumers, academics, researchers, amateur hackers, and not-so-amateur hackers to bring security vulnerabilities to their attention. Like many industries that have embraced crowdsourcing, the idea is that the more people that are involved in finding bugs and security flaws the better a company can make its security.
There is a great deal of debate about the merits of listening to the security concerns of people outside of an organization. On one end of the spectrum, some organizations refuse to discuss any aspect of their security with the public. On the other end of the spectrum, organizations proactively encourage the public to report security vulnerabilities by paying well-meaning hackers (usually called “white hat hackers” or “independent researchers”) to report problems. While these organizations view “bounty” programs as commonsense crowdsourcing, others view the concept of paying someone who has hacked a company’s system as extortion.
As more companies move to establish bounty programs third parties have begun to offer platforms or frameworks to help organize the programs. Some frameworks provide a forum in which companies can communicate with hackers, a method to facilitate payments to hackers, and guidelines for hackers to follow when identifying vulnerabilities and reporting them to participating companies. Other platforms promote invitation-only communities to test a company’s security. For many companies this provides a middle ground that permits them to take advantage of crowd sourcing without inviting the world to test their gates.
The following provides a snapshot of information on bounty programs as well as a checklist for organizations that are considering starting a program, or are evaluating the structure of their existing program.
What to think about when considering a bounty program:
If you do not enact a bounty program:
- What are the practical implications if the organization views the unauthorized access to its network by a white-hat or grey hat hacker as “unauthorized?”
- What are the practical implications if a “white hat” hacker tries to breach your security with no guidelines on how they should act?
- Is there a risk that individuals who know of a security vulnerability may provide that information to bad actors instead of providing it, first, to you?
- Is there a risk that individuals who know of a security vulnerability may provide that information to the media or to regulators instead of providing it, first, to you?
- Would the organization view every unsolicited request for payment by a hacker as extortion?
If you do enact a bounty program:
- Will you be encouraging more breaches to your system?
- Do you have confidence that you can track / monitor successful participants?
- Will all of your systems be “in scope” for the bounty program?
- Should certain forms of attack be prohibited (e.g. denial of service attacks)?
- Will employees be eligible to participate?
- Will the program be focused on weaknesses to the security of sensitive personal information, to the performance of IT infrastructure, or to both?
- Will you proactively disclose the level of compensation that a participant should expect?
- What conditions of confidentiality will you impose on participants?
- How can you avoid the unintentional access or acquisition of sensitive personal information?
- Will you utilize a third party that manages, hosts, or provides a framework for your program?