John Jackson - Corporate Cybersecurity

IoT is a large attack vector. The security of Internet-connected devices may be up to a dedicated team, such as an edge team, or may fall into the purview of a security operations team. Nonetheless, the exploitation of IoT devices is an important consideration for application security as these devices might directly connect to or host enterprise applications.

Vulnerability management processes are complex, and when teams are dedicated to such efforts, the attack surface does end up reduced. However, knowing how the processes are coordinated for resolution is necessary for application security managers. For example, if a security researcher abuses a server identified from the web application because it’s out of date, the vulnerability management team will have to assist, and knowing what type of collaboration will need to occur is quite important.

Even though application security isn’t responsible for the security of servers, pivots can take place and a researcher may report an exploit to the application security team that involves a server. Application security managers will have to know what the coordination efforts look like to resolve the problem. In addition, collaborating with nonsecurity-oriented teams may prove challenging so it’s best to develop effective security practices before issues are identified.

On some occasions, a vulnerability will end up requiring the attention of many teams. Stressing the importance of security being a team fight, even for nonsecurity-based teams, will be the smoking gun of application security. The sooner teams understand that remediating vulnerabilities must be a priority, the easier collaboration will be.

Transparent communication between application security and the legal department is necessary in the event that application security needs coverage should communications go awry with a security researcher or a threat actor is identified. Application security managers should attempt to build rapport with the legal department immediately.

Identifying enterprise regulations for the escalation of any identified vulnerabilities is a requirement. For example, the legal department will advise in the event that PII is accessed by a security researcher or an unauthorized threat actor.

If no communications have occurred between the legal department and the application security team, confusion may occur if an application security manager asks for guidance on a possible threat or breach scenario. A weak rapport between application security and the legal department could result in advice that includes threatening a security researcher. Application security managers should make an honest effort to explain to the legal department what bug bounty programs do and how they assist – given that they are not familiar with such processes.

Asking employees on the communications team if they have dealt with security research is important. If the team has dealt with a security researcher reporting through social media, identify how the communication was carried out. Explaining the importance of adequate and cordial collaboration with a researcher is essential.

Knowing how teams that manage social media intend to deal with a researcher who discloses a vulnerability publicly or through direct message is a key piece of information to have. Application security managers should redefine expectations with the teams to enable a direct line between the application security and communications team.

The importance of asking questions as a manager is to ensure that the enterprise is prepared for all of the vectors of risk before establishing a bug bounty program within the organization. Forging alliances and receiving answers to questions may not be the sole responsibility of management. Application security managers should discuss the risk assessment measures with engineers on the team and other employees in various security departments that may be able to achieve answers, or may even have answers already.

An engineer’s primary responsibility is to assist management in determining all of the vulnerabilities and risks that could be directly related to or impact the application security team. It never hurts to ask questions, and arguably some of the best engineers will want to know everything about the process – just as management will. Many engineers that may come across this book will be in a position other than application security and may not be ready to take on the responsibility of a bug bounty program without a manager. If that’s the case, it’s crucial to review the management section and get a thorough grasp of vulnerability management and how it pertains to application security.

Engineers should care about the passion for the craft and the great contributions that researchers will put forward. Even if a security engineer has management who has put a substantial amount of effort into knowing the entire enterprise layout and application security responsibilities, they should aspire to ingest all of that information. There’s not a day that goes by in day-to-day responsibilities in which a security engineer does not need to be familiar with the various enterprise teams and vulnerability remediation best practices.

Bug bounty programs are an amazing security tool. A good program can provide valuable insight and help enterprises continuously test their assets. It’s important to note that the effectiveness of a program can only be as good as the program manager who configures it. Future program managers should identify telltale signs that their organization may not be ready to start a bug bounty program. As already stated, close communication between the various teams and a precise definition of expectations are essential when setting up a bug bounty program.

Going through the various risk assessment and information gathering processes to define the enterprise security stance is not an option: it’s a requirement. Enterprises cannot build a house without a foundation, and avoiding any advance risk-assessment exercises will undoubtedly result in the shoddiest of bug bounty programs. While a bug bounty program can be a useful way to identify vulnerabilities, it isn’t the be all and end all, and engineers or managers who go through the process of attempting to set up a program without first evaluating the other aspects of security might burn their enterprise. Recovering is possible, but it would be better to carefully prepare and evaluate security gaps before launching a program. Even a limited bug bounty program can result in frustrated security researchers if communication gaps are not filled in before inviting researchers to participate in a program.