program requires collaboration and fair resolution processes. Ensuring that the program stays ethical and cares about the security researchers is a key part of spreading the positive aspects of bug bounty programs.
1.12.3 Managing Disclosure
While not recommended until a program is more established, eventually enterprises should strive to help researchers disclose their findings to the public when patched, if they wish to do so. Research disclosure helps inspire new generations of hackers and also receives enterprise, and potentially media, attention. Nonetheless, within a program security researchers should maintain the ability to disclose in any circumstance if the information is redacted enough or if a CVE exists on an enterprise product/there’s user or customer PII exposure that needs to go public.
1.12.4 Corrections
Program managers should strive to speak highly of researchers and the great work that is provided as a service. “Hackers” aren’t malicious by default, and program managers receive first-hand experience of ethical behavior. When hackers are called malicious, program managers should strive to set the record straight and describe the differences between an ethical hacker (security researcher) and a malicious hacker (threat actor).
1.12.5 Specific Community Involvement
Joining the movement for better disclosure is the first step to a greater collaboration between researchers and programs. Casey Ellis built a one-of-a-kind community named Disclose as a way for companies to participate in the conversation. (https://disclose.io).
2 Assessing Current Vulnerability Management Processes
2.1 Who Runs a Bug Bounty Program?
Ultimately, who would be responsible for starting a bug bounty program? Ideally, a bug bounty program manager should be whoever does the day-to-day work in coordinated application or web application security measures.
Not every engineer has the dilemma of figuring out their role in the vulnerability management process. If an engineer is hired as an application security engineer, it’s a given that they will have to be responsible for monitoring and triaging any application vulnerabilities as they pertain to mobile or web applications. It’s important to understand that engineers who have the sole responsibility of vulnerability management typically focus on network vulnerabilities. It would be unusual to see a security engineer on the vulnerability management team identify, remediate, or manage application vulnerabilities.
The ideal situation is one in which an application security manager and at least one application security or general security engineer set up and manage a bug bounty program. However, this isn’t always the case. Therefore, it’s important to have the tools to know what to do if it’s your responsibility to establish a program.
2.2 Determining Security Posture
The most difficult part of the entire process of executing a bug bounty program for an enterprise is evaluating the risk and risk mitigation programs. While a reader may not be a compliance expert, or an endpoint detection and response engineer, determining which role that will have to be played in the vulnerability management process is nonnegotiable. The position that an engineer was hired to fill at the company will directly assist one in understanding what specific expectations lie ahead.
“Security posture” is a flexible term. Truthfully, it would be impossible to recommend an in-depth and thorough analysis without understanding what type of business use case is in play. Risk analysis requires visualizing how all of the parts of a security team come together, and rationally determining how it plays into application security. As a rule of thumb, it can be evaluated from the perspective of management or engineering. While there are many other aspects and subcategories of information security, a fair baseline will be starting with understanding some of the core differences in responsibility as they pertain to management and engineering:
2.3 Management
It wouldn’t be absurd to suggest that an application security manager is typically responsible for evaluating the connections between the product and the application security team, and other departments in the organization. It’s the manager’s job to choose the right personnel to ensure the successful day-to-day operation of the enterprise. After operational pace is established, a manager has to determine which appropriate remediation steps need to occur before creating a bug bounty program. In the application security realm, vulnerability remediation communication occurs between a wide range of groups. As a baseline here are some of the teams that a manager will have to collaborate with.
2.3.1 Software Engineering Teams
Responsible for the development of the applications that will be subject to testing when a bug bounty program is established.
2.3.2 Security Departments (Security Operations, Fraud Prevention, Governance/Risk/Compliance, Edge Controls, Vulnerability Management, Endpoint Detection, and Response)
The various subteams that make up the root of security, subject to be vastly different based on the structure of the organization.
2.3.3 Infrastructure Teams
Responsible for the backbone of the organization that is meant for hosting applications and various assets that both stakeholders and users/customers operate.
2.3.4 Legal Department
Application security managers may have to communicate with the legal department if malicious activity is noted. Therefore, managers should have close relationships with legal representatives.
2.3.5 Communications Team
Depending on the structure of the organization, social media marketing may be up to the communications or marketing teams. Researchers may reach out via social media to disclose vulnerabilities and application security managers should be aware of this, and adequately prepare the responsible team.
2.4 Important Questions
It’s crucial to keep in mind that the answers to some of the questions covered in this section may be trivial. If known, that’s absolutely fantastic! When the answers are not known, future program managers may be able to find out without disrupting the team or space. Managers should make an effort to be cordial and responsive to concerns or pushback. It’s always better to know than to assume: operating in a presumptuous way can open the door to security issues or ineffective vulnerability management processes. In reality, the questions that proceed are to be used as a baseline and not as a full representation of an enterprise risk management guide.
During the processes of identifying risk, application security managers will find that many other questions arise – that’s great! Ask them! Operating in a way that creates a dialogue between the various teams and application security is a great first step toward building rapport and trust. Maintaining trust is an essential part of securing the organization, as it is impossible to remediate vulnerabilities if other teams do not trust
