Every job carries some risks of making mistakes, and building and developing a network is no exception. The result of these mistakes is commonly known as a bug. Furthermore, a vulnerability is the result of a bug that can be exploited. By exploiting vulnerabilities, hackers can force software to do things that it was not designed to do or remotely access private networks and install malware or malicious code.
According to the NVD database, there were 18,362 vulnerabilities published in 2020, which is a higher number of vulnerabilities published in 2019 and 2018. As a result, there is a greater need for companies having a crowdsourcing security platform to use the assistance of white hackers in identifying critical vulnerabilities.
The Vulnerability Disclosure Debate: What Is It?
For many years the vulnerability disclosure debate has been a hot topic among the realm of cyber security. The vulnerability disclosure debate focuses on how researchers should act after discovering a security vulnerability and how vendors should handle it, or in other words, how the vulnerability should be disclosed after it is discovered. Basically, vulnerability disclosure refers to the act of reporting a bug discovered by a security researcher to the vendor. In reality, the process is much more complex than it appears. Vulnerabilities can be disclosed in a number of different ways.
In the vulnerability disclosure debate the need for a policy is very tangible. Vulnerability Disclosure Philosophy (VDP) is a guideline which specifies how the vulnerabilities that have been discovered and reported to the vendor as certified bugs, should be disclosed. V.D.P should be a previously established and understandable instruction in order to prevent any kind of possible conflicts between the researcher and the vendor. The whole vulnerability disclosure process as well as payment is usually included. Before disclosing vulnerabilities, vendors should develop a policy.
The terms and guidelines of Vulnerability Disclosure Philosophy state that both parties involved in Bug Bounty programs should respect the terms and guidelines and make the program a good experience for the researcher as well as the vendor.
Vendor and Researcher Responsibilities
In accordance with this guideline, vendors and researchers each have their own responsibilities, making it possible for these groups to work together effectively.
As a researcher, you should ensure that you respect the privacy of the online business, that you don’t in any way gain unauthorized access, and you don’t damage its structure by trying to find potential vulnerabilities. Any unwanted database damage will be prevented by this method.
Similarly, the vendor’s security team must do everything they can to resolve the issue as quickly as possible and in a transparent manner, make the reward public, and reward the bounty when they do.
Generally, the process for discovering vulnerabilities and disclosing them may differ in each individual security company. For example, SecureBug terms and conditions clearly describe how a vulnerability should be reported along with all the requirements for a disclosure, such as a contact mechanism. For more information about our platform policies, please click here.
How to Disclose: Responsible or Full?
Reporting vulnerabilities has been the subject of debate for years. As noted before, there are different approaches to reporting a discovered vulnerability to the vendor. Full disclosure and responsible disclosure are the two most common models.
Full Disclosure
Full disclosure is the disclosure of all details of a vulnerability discovered. This includes: how it was found, what software product is affected, and sometimes how to exploit it and how to protect your network from being exploited. The disclosure of this type of data must be done as soon as possible.
Full disclosure is not without its critics. Advocates of this method believe that it is advantageous because it alerts the community as soon as a software vulnerability exists, even before the fix is ready, so users can protect themselves by deactivating the affected software before it can be exploited. The other advantage of this method is motivating vendors to quickly patch the bug as well as users to patch and update their systems.
There are arguments against the full disclosure, however. The arguments against this method align with those in favor of it. Some people worry that publishing data before fixing a flaw can increase the risk of exploitation of the user system. Another disadvantage of responsible disclosure is that while vendors have the capability and know-how to get rid of the bug quickly, can all users also update their systems as soon as possible? There is no doubt that this is one of the most debated topics regarding full vulnerability disclosure.
Responsible Disclosure
In addition to vulnerability disclosures, responsible disclosure is also possible. Most of the time ethical hackers are the ones who find the vulnerabilities and the company’s security teams are responsible for remediation. Developers often require time in order to accomplish that.
A responsible disclosure is when the hacker who discovered the vulnerability first notified the vendor privately. It is usual for hackers to give vendors enough time to remediate or patch the vulnerabilities, as well as to update their software. Only when it is clear that fixes, patches, and updates have been implemented throughout the supply chain, should the finder make public the findings. A significant number of business owners and security engineers prefer to disclose in a responsible manner. Bugs often have an expiration point for patches, and if the problem cannot be fixed before that time, the vulnerability is disclosed.
As a general rule, both researchers and vendors in vulnerability disclosures primarily set goals for reducing information system risk, preventing malicious activity, and informing customers about vulnerabilities. The major differences are how, when, and whom to disclose.
SecureBug, the first proactive cybersecurity solution provider of the Scandinavian region, uses a pay per vulnerability model to help your company be as secure as possible. Register your company here!
