Bug Bounty? A Bug Bounty program is a crowdsourcing initiative wherein ethical hackers are rewarded by companies for finding and reporting vulnerabilities.

In the ever-evolving landscape of cybersecurity, the banking and public sectors have increasingly embraced various vulnerability disclosure initiatives. Reflecting on Wavestone’s 2021 report, it’s crucial to understand the three key approaches that shaped the previous research:

• Vulnerability Report Channels (VRCs): These are the first step toward a bug bounty program, a web page providing basic instructions to hackers and a reporting channel.
• Vulnerability Disclosure Policies (VDPs): These policies outline how an organization receives and responds to disclosed vulnerabilities from external parties. The existence of a VDP implies the presence of a VRC as part of its framework.
• Bug Bounty Programs (BBPs): An advanced form of VDPs, and alongside the policy, BBPs offer financial rewards for reporting security vulnerabilities, incentivizing the discovery and disclosure of security issues. It can be accessible to anyone (public) or a small number of hackers (private).

These initiatives are not just procedural but bring significant benefits. They enable earlier detection of vulnerabilities, foster a culture of transparency and continuous improvement, and leverage the global cybersecurity community’s expertise to enhance security measures. By incentivizing ethical hacking, organizations can stay one step ahead of potential threats, protecting their data and systems more effectively.

Overview of Research

This study, leveraging data up to Q3 2023, examines the adoption and impact of these cybersecurity measures in the banking and public sectors. The research methodology involves a thorough analysis of current trends, regulatory landscapes, and the effectiveness of BBPs in enhancing digital security.

Banking sector insights

The banking sector, serving as the backbone of the global financial system, has shown a remarkable transformation in its approach to cybersecurity. The analysis of the world’s top 100 banks between 2020 and 2023 reveals significant developments in the adoption of cybersecurity measures. Here are some key insights:

• Increase of VRCs and VDPs: There was a marked increase in the implementation of VRCs and VDPs, by 2023, 34% of the top 100 banks had at least one active VRC, and 26% had implemented a VDP.
• Geographical Trends:
  • Dominance in Europe and North America: Banks located in the United States and European countries demonstrated higher adoption rates of VRCs and VDPs. Delving deeper into the continent analysis, Figure 1 shows that North America, with 72% of banks implementing VRCs against Europe’s 49%, continues to be ahead in adopting cybersecurity initiatives.

• • Asia and South America: Despite managing 46% of the assets across 43 banks, only one implemented a VDP, indicating a slower pace of adopting for these kinds of programs.
• Stale number of Public BBPs: The data showed a stagnation in the number of public BBPs, with only 5% of the banks operating a public BBP as of 2023. This suggests a cautious approach towards publicly inviting vulnerability disclosures.
• Notable Countries: The Netherlands stands out with a 100% adoption rate of vulnerability disclosure programs among its top banks. This demonstrates a strong national commitment to cybersecurity.
• Platform Utilization: Most banks preferred developing in-house programs for vulnerability disclosure, with a few opting for external platforms like BugCrowd, Synack, and HackerOne.

Luxembourg: A Case Study

Luxembourg’s banking sector case study focused on 5 retail and 17 private banks, provides a snapshot of current cybersecurity practices:

• Overall low Adoption Rates: Only a minority of the 22 banks have embraced structured cybersecurity programs. Specifically, only 7 out of 22 banks have established VRCs, including only 5 banks which adopted VDPs and just 1 bank which implemented a Public BBP.
• External hacker Interest: Some banks received external reports through OpenBugBounty.org, demonstrating hackers’ interest in showing vulnerabilities, despite not having a formal active program.
• Overall Trend: The sector shows a need for more consistent adoption of structured cybersecurity strategies, especially considering the high stakes in private banking.

Public Sector Analysis and Regulation

The public sector’s approach to cybersecurity, especially within the EU27, shows a complex and evolving landscape. Key aspects of this analysis include:

• Growth in Coordinated Vulnerability Disclosure (CVD): Compared with ENISA’s 2021 study, there has been a significant increase in the adoption of active CVD policies. The number of EU27 Member States with active CVD has risen from 4 to 11, indicating a growing emphasis on structured cybersecurity strategies.
• The UK’s Proactive Stance: Despite being outside the EU27, the United Kingdom has made remarkable efforts in implementing active CVD. This highlights the UK’s commitment to maintaining robust cybersecurity standards.

Conclusion and Future Outlook

As the digital world advances, the significance of vulnerability disclosure programs is increasingly clear. They represent not just a trend, but a fundamental shift in how organizations approach cybersecurity:

• The Rise of Vulnerability Disclosure: A dynamic and rapidly expanding area, these programs are becoming essential in the banking and public sectors.
• European Regulatory Momentum: With the EU’s NIS2 directive and forthcoming legislations like the CRA, there is a robust push for national CVD policies and organizational VDPs/BBPs.

At Wavestone, we understand the importance of staying ahead in this evolving scenario. We are here to help you navigate these changes effectively. Reach out to us for expert guidance in strengthening your cybersecurity position.

Cet article Bug Bounty: Insight and benchmark on the banking and public sectors 2024 est apparu en premier sur RiskInsight.

To fight this growing threat on equal terms, incident response teams – Security Operations Centres (SOCs) and Computer Security Incident Response Team (CSIRTs) – can benefit from a wide range of automated security tools. A type of solutions gradually gaining more attention are Security Orchestration, Automation and Response (SOAR) platforms. These tools combine together incident response, orchestration and automation, and threat intelligence platform management capabilities.

Notwithstanding the ultimate benefits, introducing any automated tool in existing incident response processes is no easy task. It presents new challenges to the teams, especially to define what tasks and decisions should be automated and which require human expertise instead.

This article aims to present an overview of SOAR platforms and provide best practices and recommendations on how to address some challenges faced by incident response teams as they approach SOAR solutions. First, it breaks down the potential uses of SOAR platforms in support of all incident response phases. Then, it dives deeper into some of the considerations and decisions that teams have to make, offering concrete recommendations as well. Last, it briefly looks into the of role of humans as opposed to AI-enhanced platforms.

Supporting the incident response process

Bringing together all security tools, a SOAR platform can work as the conductor of the security ecosystem in an organisation, streamlining the incident response process. It can indeed support and facilitate all key phases of the incident response, including triage and prequalification, investigation and analysis, and last response and remediation.

Figure 1 – High level SOAR integration model

During the triage and prequalification phase, a SOAR platform can collect alerts coming from specialized incident detection tools, like Security Information and Event Management (SIEM) tools. While this is a consolidated activity run by well-established tools, two major issues remain, concerning false positives detection and threat prioritisation based on contextual information.

This is where SOAR platforms can be helpful, by automatically enriching incidents, filtering out false positives and then highlighting critical security incidents. On one hand, relevant Indicators of Compromise (IoCs) can be automatically from reputable sources, such as cyber threat intelligence (CTI) providers offering highly tailored data from recent breaches occurred to similar organisations. On the other hand, internal knowledge can be ingested as well, drawing from predefined assets classification or machine-readable business impact analysis (BIA) results. This enables analysts to save time and directly tackle critical incidents, having all the information needed to focus on incident response.

In the incident investigation and qualification phase, a CSIRT can benefit from SOAR support by automating basic use cases management. While the first phase concerned more automated actions triggered from systems alerts, for instance CTI enrichment based on SIEM alerts, in the investigation phase the value added of a SOAR platform consists mostly of supporting the team’s analysis. For example, when a phishing email is reported, the SOAR platform can facilitate the collection of information needed to perform the investigation and qualification of the incident, thus making it more efficient. However, the expert’s assessment can hardly be automated for more complex tasks, like thorough analysis and qualification of complex incidents.

The response and remediation phase remains the most complicated to automate, due to both the nature of the actions required and the risk of negatively impacting the business if a remediation is executed poorly. Automating a response action must allow to capitalise on the efficiency gains, while keeping into consideration the cost-benefits assessment. 

SOAR platforms therefore can significantly facilitate the work of cybersecurity analysts, who do not have to process every incident, from tool to tool, manually, at each step of the incident response process, but can rather rely on automated tasks involving several security tools working together. After seeing different possible applications, the following question concerns how to choose what to automate.

Deciding when to automate based on the low-regret impact principle

For each IR task, there exist three different approaches for SOAR platforms:

• Full automation,
• Semi automation,
• No automation.

In full automation cases, multiple steps are pre-defined and automated in sequence, based on pre-set triggers or manual activation. Simple use cases, like the previously mentioned phishing emails, can build on full automation and provide substantial benefits to minimise time-consuming and repetitive tasks.

In semi automation cases, some steps – e.g., initial analysis, evidence collection, or information enrichment – are automated to enable the analyst to choose the best course of action. This might indeed be the most common usage of SOAR platform at the moment.

Last, some situations just do not allow for automation and will continue to require and be performed by human operators.

As IR teams explore the functionalities and potential of SOAR platforms, it is common to wonder how to choose what use cases can and should be automated. Besides a feasibility assessment, a fundamental driver to adopt is the low-regret impact principle. Considering that security is always a supporting function of business objectives, a careful risk-analysis is needed when there is the risk to affect business units or services. A benefit-versus-regret assessment leads organisations to change their perspective on the problem by making them choose when certain actions can be automated instead of whether they can be automated.

To provide a more sophisticated and realistic picture, two observations are in order. First, this choice is usually non-binary (e.g., high-regret vs. low-regret), since there should be growing levels of risks and reasonable confidence, based on an organisation’s risk appetite. Regret is better quantified on a scale. Second, such cost-benefit analysis is necessarily contextual, meaning that it has to take into account the situational conditions in which it is taken. During an ongoing crisis, automated actions might become more or less appealing, given the evolving risk calculation.

In concrete, actions with very little chance to disrupt business operations are to be considered low-regret actions, allowing for greater automation. Actions with the potential to cause widespread or impactful disruptions when carried out incorrectly can be assessed as medium-regret actions, requiring human confirmation to complete the workflow. Finally, actions that would disrupt business activities in an unacceptable way (e.g., disruption of highly-critical assets) are seen as high-regret actions, discouraging automation. Nevertheless, in particular circumstances, such scale can be revised and adapted.

Adopting a progressive approach

Once the basic concepts about SOAR solutions are defined, IR teams face another major challenge related to change management. Switching from manual playbooks to automated workflows entails a burdensome process that require careful prioritisation. An increasing degree of automation can be reached through a gradual and progressive approach.

Simple tasks that are time-consuming and present a low-regret risk can be automated first, reducing the low added-value workload of IR analysts and increasing their efficiency. This can be set up quickly, given the technical feasibility of such actions (e.g., existing API). In addition, standardising tasks can accelerate further automation stages by making them reusable in different playbooks or branches. Indeed, it is better to start automating easy playbooks’ branches, like clearing-out false positive, before extending the automation to the whole playbook where all possibilities of an alert have to be considered.

AI supporting humans’ activities

Some SOAR solutions rely on and benefit from Artificial Intelligence (AI), whereby a machine learning (ML) model can be trained on specific data fed to it. For example, a dataset of phishing emails classified according to different values (e.g., legitimate, malicious, spam) can train the ML model.

AI-enhanced SOAR solutions can help to quickly resolve simple incidents or easily identify automatable actions, yet the human reasoning will better contextualise choices based on business and operational considerations. Ultimately, no automated solution can work without the intervention and supervision of analysts yet. Instead, AI is mostly meant to perform a specialized single task efficiently by processing large amounts of data. This highly improves the team’s efficiency, working alongside humans, rather than replacing them.

Conclusion

All considered, SOAR platforms are powerful tools. While they can support IR teams throughout all stages of their everyday work, including information collection, analysis and active response, it should be emphasised that SOARs are not magic tools capable of solving all issues and problems teams face today. On the contrary, purchases not followed by well-defined implementation projects will likely result in ineffective outcomes and low returns on investments. On the technical side, SOARs cannot perform tasks that backend systems do not allow; on the organisational side, they will always rely on well-established, standardised, and tested processes and procedures. As organisations evaluate their adoption and consequently navigate the steps to integrate them and capitalise on their potential, driving principles like low-regret impact and a progressive approach determine the ultimate result and benefits teams are aiming to gain.

Thanks to Fabien Leclerc for the research and writing support

Cet article Improving Incident Response through Automation: An overview of SOAR platforms est apparu en premier sur RiskInsight.

What is a bug bounty and what is it used for?

Mere buzzwords a few years ago, bug bounty programmes and vulnerability disclosure initiatives have since permeated the cyber-related vocabularies of a wide range of organisations, whether it be digital giants, top investment banks, or government bodies. The basic principle is the following: companies provide a financial incentive or reward for well-intentioned hackers to find and report vulnerabilities discovered in their assets. The catch is that the company behind the initiative sets a fixed window of opportunity for hackers to discover and fix these vulnerabilities. Wavestone has studied the adoption of these initiatives within the banking sector and the good practices to be drawn from such initiatives.

3 levels of maturity: Reporting Channel, Vulnerability Disclosure Policy and Bug Bounty Programmes

When it comes to vulnerability disclosure, the initiatives are various and the terminology is broad, whether it is Coordinated Vulnerability Disclosure, Responsible Vulnerability Disclosure or Vulnerability Disclosure Policy. All of these initiatives aim at providing researchers with a safe way to report vulnerabilities, yet the level of detail regarding the reporting process, rules for searching for vulnerabilities and the expectations of the organisation in question varies greatly from one programme to another. In the light of these observations, we identified 3 levels of maturity as follows: Reporting Channel, Vulnerability Disclosure Policy (VDP) and Bug Bounty Programmes (BBP).

The first level of maturity, Reporting Channel, generally consists of a simple web page providing very basic instructions and a dedicated channel to report vulnerabilities. This first step toward vulnerability disclosure acts as a safety net in case someone discovers a vulnerability, but it doesn’t actively attract hackers, particularly due to the lack of monetary incentive. Reporting Channel is the second most common type of initiative, accounting for 28% of the identified initiatives.

The second level of maturity, Vulnerability Disclosure Policies, also takes the format of a dedicated web page but this time with much more detail. It contains advanced information on reporting processes, the assets in scope, and the preferences, rules and exceptions for vulnerability researching. Furthermore, in most cases (90%), information regarding the expectations that hackers may have after submitting a report in terms of both service-level agreements (SLAs) and public recognition for their work are outlined. In many of these initiatives (77%), companies commit to providing hackers with safe harbour and not pursuing legal action against hackers if they follow the rules and act in good faith. This kind of initiative can be managed internally or by a third-party platform (HackerOne, BugCrowd, Synack…) that will communicate with hackers and oversee bug triage.

Finally, Bug Bounty Programmes represent the highest level of maturity, as it features the same level of information as Vulnerability Disclosure Policy but this time, hackers are financially rewarded for reporting vulnerabilities. This aims to attract talented hackers and make bug bounties a fully-fledged tool in banks’ cyber-ecosystems. Third-party platforms can either manage these programmes or set up private programmes to which only vetted hackers will have access (following a background and skills check). In many cases, private programmes are used as a steppingstone to bug bounty, allowing companies to gain experience with the concept before moving on to a public programme. They also make it possible to implement advanced security features (full research monitoring through VPNs, Non-Disclosure Agreements, advanced vetting, on-location research…) which make it easier to comply with the security and confidentiality standards that are common in the banking sector.

The banking industry is not outdistanced by other industries

These initiatives were implemented by 18% of the studied banks, which is 2.5 times higher than the average reported in the Forbes Global 2000. Therefore, it can be said that the banking sector has well-integrated vulnerability disclosure processes as part of its cyber ecosystem, with the banking and insurance sector ranking in 3rd position in terms of number of programmes for Internet and online services and computer software. However, it is not the most attractive from a financial point of view, ranking in 12th place in terms of the average remuneration for a critical vulnerability, with blockchains and crypto currencies offering an average remuneration that is almost 3 times higher (source: HackerOne’s Hacker Powered Security Report 2019).

Western banks are more confident about engaging in vulnerability disclosure processes

Although the adoption of vulnerability disclosure processes in the banking sector seems to be global, this research found that initiatives are mainly adopted by European and American banks with some specificities. These observations can be explained by several factors.

In the US, vulnerability disclosure has long been part of the culture of tech industry giants such as Google and Facebook which, among other companies, launched their own programmes before 2012. The US are also home to players that now rank among the world’s leading bug bounty platforms, including BugCrowd (2011), HackerOne (2012) and Synack (2013). It is therefore not a surprise to see that these platforms are managing most of the American banks’ vulnerability disclosure programmes.

In Europe, the situation is different and there are fewer key players. After several major cyber incidents, the Netherlands was the first country in Europe to launch a national initiative by publishing the Guidelines for Coordinated Vulnerability Disclosure (2013) – a collaborative effort between the Dutch Government’s National Cyber Security Centrum (NCSC) and various private sector companies. Today, nearly 70% of the major Dutch banks have a self-managed bug bounty programme and the country has played a key role in the construction of EU guidelines on the subject matter. It is also regularly referred to as an example to be followed by several European authorities. Other initiatives and platforms have also emerged elsewhere in Europe, such as YesWeHack, Intigriti, HackenProof, Yogosha, etc. However, it is difficult to precisely assess the emergence of bug bounty programmes across Europe, as more than half of them are private and lack publicly available information for the purpose of confidentiality.

In Asia, banks are less proactive on vulnerability disclosure on account of reservations about private programmes and other cultural factors. However, the last few years have seen growing initiatives from both Asian technology giants and government institutions, notably in Singapore and Japan. This is not surprising, as many government institutions have launched this type of initiative in the past (for example, Hack The Pentagon in the USA or the recent StopCovid application’s bug bounty that is managed by YesWeHack in France).

Getting into vulnerability disclosure will require truly effective preparation

With many success stories and a growing number of companies from all sectors launching vulnerability disclosure programmes, it is tempting to follow the trend. However, to ensure the success of this type of initiative, it is crucial to address a few points. First, a vulnerability or bug bounty disclosure programme should be part of a global cyber security approach and be complementary to more traditional measures such as regular code reviews, security by design and security/pentest audits. Reporting bugs and flaws is only the first step of the process. The company must then have the in-house skills to analyse the provided reports and remediate the vulnerabilities as soon as possible. Second, to avoid wasting both the hackers’ and the company’s time, the scope of the programme must be carefully designed in order to maximize its effectiveness and prevent intrusion on unwanted assets. The same rules apply when it comes to the rules for searching and reporting. Finally, it is crucial to address hackers’ motivations to ensure the success of a bug bounty programme. Expectations for submitting a report must be clearly specified and address the process, response time and reward. Constant communication with the hacker community as well as an evolution of the programme or the rewards are some key elements that can ensure the sustainability of the programme and the motivation of hackers, thus contributing to the programme’s success.

The image of hackers is still often associated with criminal actions…

When it comes to bug bounty, one of the main concerns is security, with organisations questioning whether exposing their platforms to hackers might lead to exploitation of any discovered vulnerabilities through the sale of user data or the vulnerabilities themselves directly on the black market.

These fears are partly justified, as user data can now easily be sold on the black market: credit cards, passports, medical records or authentication information can be sold for less than EUR 15 and targeted phishing using this information can generate even more profit. A critical flaw can also be exploited and result in a much larger cyber-attack, as demonstrated by the havoc wreaked by cryptolockers in recent years. However, these incidents are rarely linked to bug bounty programmes, as malicious hackers do not wait for organisations to launch bug bounty programmes in order to attack them. Rather, these attacks can occur at any time.

Secondly, different skills and levels of preparation are required to find vulnerabilities and exploit them.

Finally, money is the primary motivation for hackers participating in these programmes in less than 15% of cases, according to HackerOne. For the majority of hackers, hacking is a passion and they are mostly looking for challenges and opportunities to improve their skills and make the web more secure – in this case, financial rewards are just a small bonus and getting on the wrong side of the law is not worth it.

Vulnerability Disclosure Policy: a first step to improve cyber security

Vulnerability disclosure and bug bounty initiatives are now a mainstream topic in the cyber security field, and the banking sector is no exception. Although bug bounty programmes are not miracle solutions and some effort is required in order to ensure that they are really effective, implementing a Vulnerability Disclosure Policy appears to add a great additional layer of security for a low investment. We can therefore only recommend implementing such a policy as soon as an organisation’s cyber maturity allows for it.

Cet article Bug Bounty: insight and benchmark on the banking industry 2021 est apparu en premier sur RiskInsight.