Don’t Be Ignorant of ISO/IEC 29147

If you go and look at my last post, you’ll
see what happened not long ago to the Colombian Foreign Ministry and its
digital visa platform. At that time, I referred to a “thoughtless
vulnerability reporting.” This was attributed both to the user who
identified the weakness in that platform and to the group of journalists
who published it on social networks. However, before finding out the
details of that event and reflecting on it, I was asked to review
something else. I mean something I mentioned in brief in that post but
judiciously posed to the reader as a possible forthcoming topic I would
cover here: ISO/IEC 29147:2018.

As shared on their site, ISO
(the International Organization for Standardization) “is an independent,
non-governmental international organization.” “[It] brings together
experts to share knowledge and develop voluntary, consensus-based,
market relevant International Standards that support innovation and
provide solutions to global challenges.” In their standards
list, the
number 35 stands for the ‘Information
technology‘ group. Among 15 different
subgroups, 35.030 corresponds to the ‘IT Security (including
encryption).’ There, we find the
ISO/IEC 29147:2018,
‘Information technology -Security techniques- Vulnerability disclosure.’
In this post, I will introduce you to what the experts in this standard
have to offer.

Overview

This standard takes as its main subject Vulnerability Disclosure.
i.e., in a nutshell, the act of informing stakeholders about an IT
system’s vulnerability. You likely know that a vulnerability could be
described as a security weakness in a system that could compromise some
assets and operations when exploited by attackers. Factors such as the
origin, severity, and impact generated by a vulnerability are variable
characteristics. Nevertheless, when a person finds a vulnerability, at
least at first, what matters most is not its specific features. What is
vital is the mere fact of reporting it. From an ethical conduct stance,
everyone should report any identified vulnerability either we are paid
for it or not. This would be to our benefit and that of others.

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.

The procedures of receiving reports and distributing remediation
advisories are only two parts of a broader process. Some of the other
steps involve different International Standards, e.g., the
ISO/IEC 30111 for
vulnerability handling methods,
which I talk about in another blog post.
In broad terms, we could describe that process as follows: First, a
reporter contacts a vendor about a potential vulnerability. Then, the
vendor verifies the issue and, if dealing with a genuine exposure,
develops and implements remediation. In the end, the vendor publishes a
related advisory to all stakeholders.

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.

Preparation

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.

Policies

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.

Receiving reports

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.

On the other hand, prepared and capable vendors should regularly monitor
their reporting mechanisms, communications on reports already received,
and internal channels and public sources for possible vulnerability
reports. Vendors should be ready to give quick but at the same time
meaningful responses to reporters. (Caution: frustrated reporters
may choose to release data wherever they feel inclined to do so.) Next,
a reporter has the right to be informed of the following: whether the
vulnerability has begun to be under investigation, whether more
information is required in their report, or whether it is currently
irrelevant. In those cases where reports lead to research, the
previously mentioned vulnerability handling
processes kick off, and the
vendors build and test remediations about which they should later
distribute advisories. Certainly, they should not forget to keep
reporters up to date.

Distributing remediation advisories

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.

A quote to remember

“[…​] Vulnerability disclosure helps users protect their systems and
data, prioritize defensive investments, and […​] make better risk
decisions.” ISO/IEC 29147:2018

PS: Many major details are missing in this blog post. If you are
really curious about vulnerability disclosure, we recommend that you
read the full text of
ISO/IEC 29147:2018.

*** This is a Security Bloggers Network syndicated blog from Fluid Attacks RSS Feed authored by Felipe Ruiz. Read the original post at: https://fluidattacks.com/blog/iso-iec-29147/