Uncoordinated Vulnerabilities Disclosure is a serious problem. Yet, we must understand why, and all the points that lead to it before we fight it. Let’s start at the beginning:
What is Vulnerability Disclosure?
It is the practice of reporting security flaws in the software or hardware of a computer or program. Your IT team or other parties can reveal the vulnerabilities to the parties responsible for the systems. This includes internal and external developers that work with vulnerable systems. Usually, developers wait until fixing the failure before making the vulnerability public. However, if someone alien to the project could find that fault. In these cases, they may threaten to disclose this information without your consent. That’s uncoordinated vulnerability disclosure.
The disclosure of a vulnerability and how to do it can be a controversial issue. Many providers prefer to keep the vulnerability secret until they have a patch ready. Investigators and security professionals prefer to make disclosures public as soon as possible. Opinions vary according to the stakeholders and their priorities:
- System developers or manufacturers prefer disclosing vulnerabilities only between them or after fixing.
- Users of the products or services prefer to repair their systems as quickly as possible. Yet, third parties can exploit a vulnerability before they begin to fix it. In these cases, they prefer to disclose publicly to find other ways to mitigate the threat.
- Finally, there are security researchers who discover vulnerabilities. In general, they prefer to repair vulnerabilities and publish the details they discovered. The latter is to strengthen the security of the systems.
Types of vulnerability disclosure
There are different types of disclosure of vulnerabilities. Each of them will vary depending on the business environment.
Self-disclosure
Self-disclosure occurs when, as a manufacturer, you discover failures and make them public. This process is usually done while publishing fixes or other corrections. It is usually the most common process and valued by the users of your market.
Third-Party Disclosure
It occurs when the disclosure is not found by the owners or authors of the hardware or systems. They are usually performed by security researchers who inform manufacturers. However, it can also involve universities or services outside the company. This process is common in large companies or large online services.
Supplier Disclosure
It occurs when researchers report vulnerabilities only to providers to develop patches. It’s rare that after the discovery disclosure ends up releasing the public. If it occurs, it’s usually the least amount of information possible to reduce risks.
Full disclosure
This type occurs when a vulnerability is released, often as soon after knowing the details of the vulnerability. One place where this occurs in video games. Failures in the system or the controls spread through the web. In more serious companies it can become a strong security flaw if they are not corrected in time.
Uncoordinated Vulnerabilities Disclosure
It is in this last group that uncoordinated vulnerability disclosure enters. This happens when an outsider reveals information without time to react. There are several ways to deal with this problem, and here we will name the most important ones.
Imagine this situation. One day, you receive an email from an unknown third party, which reads as follows:
I found this fault in your code. Fix it in a certain time, or I’ll disclose it to the public.
It is a serious threat, as it puts the credibility and, above all, the security of your business at risk. What to do then? The best solution would be to fix the problem and hope that such a situation does not happen again. But what if you don’t know what the problem is? What if the person returns with another fault, or does it affect your code before you can act?
First, you have to make sure your team is aware of the error. They will want it solved as soon as possible because other parts of the code could be in danger. An example is a Cross-site Scripting (XSS) vulnerability. In a web application, it can be used to attack other people who use your domain. This generates false confidence through social engineering.
What to do?
- The first thing is to delegate responsibilities. Select a technical employee, from your IT security team. Hold him accountable for further communication about vulnerability disclosure. Get in touch with who gave the alert and make sure the selected representative is courteous.
- Make sure your employees know how to scale up possible security problems.
- Don’t ignore those reports. It is best to teach employees in public roles how to handle safety reports. They should also know who to send them without bypassing regular consultations.
- Keep your team updated. Contact them immediately to confirm they received the report and are investigating it. Give them estimates of the time in which you intend to finish the investigation.
- Usually, non-malicious hackers follow responsible disclosure practices. They provide you with a specific time frame to correct the vulnerability. If they have not specified that period, ask them about your preference if necessary.
The best way to prevent these cases is to use an automated web vulnerability scanner. In the case of Acunetix they have AcuSensor. This provides extra information on where the error is in the byte code or the source code. You can also scan vulnerabilities from both the network and the web.
If you want to know more about SecrityCenter CV and your SSL certification, you can contact us. We will help you with all the information you need, as we offer the best tools on the market. Our team is here to advise you and provide you with a more efficient IT environment.
