1. Objective

This policy is intended to discipline the disclosure process of security vulnerabilities.

2. Scope

The policy covers vulnerabilities identified in any technology, including technologies developed by Tempest.

3. Princípios

This policy aims to meet a set of principles that Tempest considers to be values that are intrinsic ​​to the process of vulnerabilities discovery and disclosure. They are:

  1. 3.1. At Tempest, the search for vulnerabilities is driven by the desire to bring more security to its customers and the society as a whole.
  2. 3.2. Entities should seek dialogue to responsibly disclose vulnerabilities.
  3. 3.3. Resources and efforts to find vulnerabilities need to be commensurate with proving that the vulnerability exists.
  4. 3.4. Defining the rules for coordinated disclosure of vulnerabilities balances the relations between entities and protects researchers.
  5. 3.5. Full disclosure of vulnerabilities to the manufacturer is guided by the benefit to society in conditions in which there is imminent danger of its exploitation. This type of disclosure can only occur in situations in which all attempts at communication or consensus between the parties have been exhausted by the deadline set forth in item 7.1.7 below.

4. Definitions

Vulnerability– A set of conditions or behaviours that make it possible to violate an explicit or implicit security policy. Vulnerabilities may be caused by software defects, configuration or design decisions, unexpected system interactions, or changes in the environment. Successful exploitation of a vulnerability has technical and risk impacts. Vulnerabilities may arise in information processing systems as early as in the design phase and as late as in system deployment.

Risk– A measurement of the extent to which an entity is threatened by a potential circumstance or event, and it is typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurred; and (ii) the probability of occurrence.

Potential Impact– The loss of confidentiality, integrity or availability that can be expected to have a limited, severe or catastrophic adverse effect on operations and organizational assets or individuals.

CVSS– Acronym for Common Vulnerability Scoring System. This is a way to identify the key characteristics of a vulnerability and grade it according to its severity, which can help organizations prioritize vulnerability remediation activities according to their potential impact and risk.

CVD– Acronym for Coordinated Vulnerability Disclosure. It is a process for reducing the advantage of opponents while mitigating an information security vulnerability. CVD is a process, not an event. Releasing a patch or publishing a document are important events within the process, but they do not define it.

5. Roles and Responsibilities

Because it is a coordinated process, CVD can involve multiple organizations, such as companies, foundations, government agencies, and individuals, who may assume various specific roles and responsibilities in the process. Tempest could, for example, assume the role of rapporteur finder and coordinator for the vulnerabilities it finds. Additionally it can also assume the role of manufacturer and deployer for the vulnerabilities found in its technologies.

Finder– individual or organization that finds the vulnerability, which is often a security researcher or pentester who is motivated by the technical challenge or recognition that the disclosure of the vulnerability may offer. Eventually, companies or the manufacturer itself performs this role institutionally.

Reporter-individual or organization that reports the vulnerability to the manufacturer. In many cases this role is performed by the Finder. Eventually, the role can be performed by a company that mediates communication between the manufacturer and the Finder, charging a fee on the reward tied to the responsible disclosure of the problem.

Manufacturer– It can be acompany, a non-profit organization, a government agency, an individual, or a group of individuals that creates, develops, and / or maintains technologies. In CVD this is the entity responsible for evaluating Finder-submitted documentation, planning and developing fixes, and making them available to Deployers.

Deployer– Individual or organization with the role of planning, testing, and implementing vulnerability fixes.

Coordinator– Individual or area in an organization that manages the vulnerability remediation identification cycle in the CVD process. Eventually the process may require the coordination of activities between multiple companies, which entails a coordinator for any case. At Tempest, employees with the Research Advisor badge hold this role.

6. Fases do CVD

Discovery– the moment in which the vulnerability is identified. This can happen accidentally or within the scope of a search.

Reporting– the moment at which the Finder and/or the Reporter documents the discovery of the vulnerability in a vulnerability advisory.

Validation and Sorting– the moment in which the manufacturer validates the accuracy of the documentation and prioritizes this correction over other possible similar activities.

Remediation– the activity of developing a fix for the problem and testing it.

Deployment– The phase where the Deployer plans, tests, and implements the fix in their own environment.

7. Guidelines

With the following guidelines, Tempest seeks to apply a set of general rules for addressing vulnerabilities, not only those identified in its solutions but also those found in various technologies.

This initiative is based on internationally recognized practices and is intended to contribute to the safety of all, as detailed in section 3 “principles” of this document. Therefore, Tempest complies with the guidelines of this policy and expects other organizations to comply with it as well.

7.1. Coordinator Guidelines
  1. 7.1.1. The coordinator must act on the principles of this policy;
  2. 7.1.2. The coordinator operates as a project manager, resolving conflicts and clearing the communication channels between all parties;
  3. 7.1.3. All communication between the Coordinator and the parties must take place through encrypted channels;
  4. 7.1.4. In situations where the vulnerability involves multiple manufacturers, representatives of all involved organizations should elect an exclusive project coordinator;
  5. 7.1.5. Details of the disclosure will be negotiated by the coordinator with all parties. If multiple organizations are involved, the disclosure can only happen when they all agree.
  6. 7.1.6. The coordinator should negotiate with the manufacturer a deadline for disclosing the vulnerability, which should, in principle, not exceed 90 days from the first communication between the parts.
  7. 7.1.7. Cases in which there is no cooperation from the manufacturer, or the manufacturer does not consider the situation as a vulnerability, should be referred to the coordinator’s director so that the publication be deliberated with the management.
7.2. Finder Guidelines
  1. 7.2.1. The Finder should initially report the vulnerability to its coordinator in case there is a person with this role.
  2. 7.2.2. The Finder is responsible for its actions and should be aware that reporting the vulnerability does not absolve it from a criminal investigation if the vulnerability is used for criminal purposes;
  3. 7.2.3. The Finder should report the vulnerability as soon as possible to minimize the risk of malicious exploitation;
  4. 7.2.4. All Finder communication with all parts must preferably take place over encrypted channels;
  5. 7.2.5. In the absence of the Reporter, the Finder should report the vulnerability following the criteria defined in section 7.3 below;
  6. 7.2.6. The Finder’s actions must be proportionate to prove that the vulnerability exists, avoiding
    1. Using social engineering to gain access to the system;
    2. Creating a backdoor on the system to demonstrate the vulnerability as this could lead to additional damage or unnecessary risk;
    3. Using the vulnerability longer than necessary to establish its existence;
    4. Copying, modifying or deleting data in the system;
    5. Enumerating or making lists of system directories;
    6. Modifying the system;
    7. Gaining access to the system repeatedly;
    8. Sharing access to the system with others;
    9. Using brute force techniques to gain access to the system.
7.3. Reporter Guidelines
  1. 7.3.1. The Reporter should build the Vulnerability Advisory with the following vulnerability information:
    1. Document version;
    2. Date of first advisory version and current version;
    3. CVSS of the vulnerability and its description;
    4. Which technology is vulnerable;
    5. Which version – or versions – are vulnerable;
    6. What is the type of vulnerability;
    7. What is the potential impact of successfully exploiting the vulnerability;
    8. What are the adverse situations of unsuccessful exploitation of the vulnerability. Example: cases where exploit execution results in error but causes denial of service on target;
    9. Description of the required resources and pre-existing conditions for the attack to occur.
    10. Possible bypass solutions that prevent exploitation of the vulnerability.
    11. Technical evidence proving that the vulnerability is exploitable.
  2. 7.3.2. All communication of the Reporter with the parts must happen through encrypted channels.
7.4. Manufacturer Guidelines
  1. 7.4.1. The manufacturer is committed to maintaining channels for Finders and Reporters to communicate with the company on vulnerabilities in its products.
  2. 7.4.2. The manufacturer agrees not to set limits for communication about vulnerabilities;
  3. 7.4.3 The manufacturer must have qualified personnel to respond to any communication about vulnerabilities in its products;
  4. 7.4.4. The company should ensure that, upon notification of a vulnerability advisory, it will be sent as soon as possible to the group that is most able to respond;
  5. 7.4.5. The group responsible for handling the vulnerability advisory shall send an acknowledgement to the Finder and / or reporter as soon as it receives the document, preferably digitally signed;
  6. 7.4.6. The manufacturer should provide a fix for the vulnerability within 90 days;
  7. 7.4.7. The time to submit a correction may be reduced or increased according to the criticality and / or complexity of the problem;
  8. 7.4.8. The manufacturer shall inform the Finder, the Reporter and / or the Coordinator about the status of each remediation activity;
  9. 7.4.9. The manufacturer may choose to subsidize Finder for discovering the vulnerability;
  10. 7.4.10. The manufacturer may opt to disclose the vulnerability in advance to its partners or interest groups;
  11. 7.4.11. The initiative to offer a reward for reporting vulnerabilities is unique to the organization, which can determine the conditions for this in a public policy.
  12. 7.4.12. By accepting the terms of the coordinated vulnerability disclosure policy, the manufacturer declines to take legal action against researchers who discovered the vulnerability, unless a criminal investigation proves that they used the vulnerability for criminal purposes.

8. References

Software Vulnerability Disclosure in Europe:Technology, Policies and Legal Challenges.CEPS Task Force. Junho de 2018.

The CERT® Guide to Coordinated Vulnerability Disclosure. CERT Division. Carnegie Mellon University. August 2017.

NIST Special Publication 800-30: Guide for Conducting Risk Assessments.National Institute of Standards and Technology. September 2012.

NIST Special Publication 800-53: Security and Privacy Controls for Federal Information Systems and Organizations. National Institute of Standards and Technology. April 2013.

FIPS PUB 200: Minimum Security Requirements for Federal Information and Information Systems.National Institute of Standards and Technology. 9 March 2006.

Economics of vulnerability disclosure. ENISA. December 2018.