Don't Be Ignorant of ISO/IEC 29147

ISO chiefly directs this standard to vendors. Those who may get vulnerability reports and publish advisories on their verification and remediation, for which they are responsible. Following ISO terms, the reporter (most often the finder) is the person or team that gives information on a potential issue to the vendor or coordinator. On the other hand, the latter acts as an intermediary if communication and negotiation between stakeholders require it. It is apt to note that, apart from users, coordinators and even vendors can act as reporters.

However, as the main focus of this post, let us mention some tips from ISO. These can serve as valuable support for those firms that want to set up or enhance their vulnerability disclosure policies and methods.

For the proper receipt of reports, as a priority, vendors should develop policies and a full program that must be visible and open to all potential reporters. It is ideal for a company to keep its IT systems under assessment through third-party vendors such as Fluid Attacks. But it is always prudent to have everything ready to receive reports from any other source. The lack of a vulnerability disclosure program can lead to reporters ending up publishing data without the vendor knowing about it ahead of time. Similar in a certain way to what occurred to the Colombian Foreign Ministry. However, when the issue is not already public, reporters should try to send sensitive vulnerability information confidentially to prevent attacks. It would also be great to give vendors enough time to fix the vulnerabilities before talking about them publicly.

It is clear that vendors can adhere to existing vulnerability disclosure policies. But they can also create requirements that apply to their staff, affiliates and outsiders. Among their particular policies, vendors should make public their intentions, expectations and responsibilities in relation to stakeholders. All this in an accurate and simple way that facilitates communication. Policies should contain information on preferred contact mechanisms and their security technology for confidentiality. They should also include details on the required content for every report, among other things.

The capabilities to take vulnerability reports, establish efficient working relationships and ensure all involved people’s safety adhere to the vendor’s preparation phase. The reporting mechanisms to be enabled to reporters could be, as usual, emails, issue tracking systems, and web forms. But all of them should be as protected and confidential as possible. In addition, to ease the next step of verifying the potential vulnerability, the vendor should ask reporters for some data: the affected product/service, type of weakness, cause, severity, impact, evidence, among others. Of course, the vendor needs to be aware that a report made by a person who found the vulnerability, e.g., by accident, is not going to include all that required data. Thus, that operation always depends on the reporter’s technical knowledge, and the vendor should be prepared for it.

Vendors may disseminate advisories related to vulnerability remediation either only to their users or to the wider public. Users should receive information on the affected products/services and the remediation achieved along with corresponding instructions. For example, users have to install from time to time updates or patches that constitute vulnerability fixing. Nevertheless, it is preferable to have automatic update deployment systems. In contrast, when a vulnerability is under exploitation and no remediation is available, vendors should inform users about the threat and temporary solutions and guidelines to reduce risks. Always bearing in mind this: if the data is public, it must avoid the exhibition of any specification advantageous to malicious hackers.