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.
2.8.2 What Criteria Are/Will Be Set Out for the Escalation of Issues?
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.
2.8.3 Does the Legal Department Understand the Necessity of Bug Bounty Program Management?
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.
2.9 Communications Team
2.9.1 Has the Communications Team Dealt with Security Researchers Before? Is the Importance Understood?
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.
2.9.2 Was the Communications Team Informed of Bug Bounty Program Expectations?
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.
2.10 Engineers
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.
2.11 Program Readiness
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.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
