Corporate Cybersecurity. John Jackson

reshape the landscape of hacking. As a community, we cannot let the fear of hacking prevail as the action of shaming individuals that care about the security of an organization ends up causing more harm than good. Reshaping the world will take the cooperation and understanding of all individuals involved in the process. In addition, enterprises should maintain a neutral state of mind. Security researchers hack for various reasons: money, credibility, press, portfolio building, or fun. The reason vulnerability research is conducted should hardly matter: the only responsibility of the enterprise is to provide a safe environment and to patch the vulnerabilities. Fear of the press, while a legitimate concern, can be redirected into positive energy that rewards and values the researchers. If the organization engages openly with the researcher, it could well result in a positive outcome, in terms of media spin or as a learning outcome.

      1.12 Taking Action

It shouldn’t come as a surprise that word of mouth is a powerful tool. The enterprise space is ever-expansive and companies will constantly compete to be better than their competition. As a society, the establishment of honest programs and disclosure processes can influence the entire enterprise space. Here are some ways program managers or potential program managers can help assist researchers and the security research space.

      1.12.1 Get to Know Security Researchers

      Be involved in the community aspect of research. Whether reading publications on CVEs (common vulnerabilities and exposures) or bug writeups, participating in Twitter conversations, or connecting with hackers on LinkedIn, it’s important to understand all aspects of the landscape.

      1.12.2 Fair and Just Resolution

      Running a program isn’t the final solution. Managing an enterprise 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).

Part 2 Evaluating Programs

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