Fortinet Security Vulnerability Policy

Overview

As a leading vendor in the cyber security space, Fortinet secures the largest enterprise, service provider, and government organizations around the world.  As such, it is essential that our products adhere to the highest security assurance standards and are developed with security at the forefront of the products development lifecycle.

Fortinet Product Security Assurance Policy and Information Security Management System are based on recognized industry standards including ISO/IEC 29147:2018 for Vulnerability Disclosure, ISO_IEC_30111_2019 for Vulnerability Handling Processes, and best practice recommendations from FIRST (Forum of Incident Response and Security Teams) for best practice recommendations.

Fortinet Product and Corporate Security Incident Response Team Missions

 Fortinet PSIRT and CSIRT teams work with Fortinet customers, independent security researchers, consultants, industry organizations, and other vendors to accomplish their missions.

Fortinet Product Security Incident Response Team (PSIRT)

The Fortinet Product Security Incident Response Team (PSIRT) is responsible for maintaining security standards for Fortinet products by training teams in secure coding practice, testing product security, and responding to Fortinet product security incidents. Fortinet PSIRT is a dedicated, global team that manages the receipt, investigation, and public reporting of information about security vulnerabilities and issues related to Fortinet products and services.  Fortinet defines a security vulnerability as an unintended weakness in a product that could allow an attacker to compromise the integrity, availability, or confidentiality of the product.   Fortinet PSIRT works with Fortinet customers, independent security researchers, consultants, industry organizations, and other vendors to accomplish its PSIRT Mission.

Commitment to Product Security and Integrity at Fortinet

Fortinet product development practices specifically prohibit any intentional behaviors or product features that are designed to allow unauthorized device or network access, exposure of sensitive device information, or a bypass of security features or restrictions.

Vulnerabilities in Fortinet PSIRT scope include any design or implementation issue that substantially affects the confidentiality or integrity of the product and/or impacts user security is likely to be in scope of PSIRT. Common examples include:

• Undisclosed device access methods or "backdoors"
• Hardcoded or undocumented account credentials
• Undocumented traffic diversion
• Cross-site scripting
• Cross-site request forgery
• Mixed-content scripts
• Authentication or authorization flaws
• Server-side code execution bugs
• Bypass of security feature (Bypass of AV/IPS engine)

Fortinet considers such product behaviors to be serious vulnerabilities.  Fortinet will address any issues of these nature with the highest priority and encourages all parties to report suspected vulnerabilities to the Fortinet PSIRT for immediate investigation.  Internal and external reports of these vulnerabilities will be managed and disclosed under the terms of the Fortinet Security Vulnerability Policy.

Fortinet Corporate Security Incident Response Team (CSIRT)

As an industry leader in network security, the security of Fortinet’s own IT infrastructure is essential to our success. The Fortinet Corporate Security Incident Response Team (CSIRT) is responsible for maintaining high standards for the security of our network, business applications and data. The CISRT team works diligently to respond to security issues in Fortinet network infrastructure, web and mobile applications. Vulnerabilities in Fortinet-cloud services, network infrastructure and applications are part of Fortinet CSIRT scope. The following vulnerability categories are considered out of scope of CSIRT Responsible Disclosure Program (unless a proven high impact is demonstrated) and will not be eligible for credit on our researcher list: 

• Network-level Denial of Service (DoS/DDoS) vulnerabilities.
• Reports that have not been validated from automated web vulnerability scanners and SSL/TLS scanners or port scanners.
• Low severity, low impact security issues that can be detected by automated scanners.
• Any kind of physical intrusion or social engineering attempts.
• Any low impact issues related to session management (i.e. concurrent sessions, session expiration, session refresh on password reset/change log out, etc.)
• Missing X-Frame-Options header (Clickjacking/UI Redressing).
• User, account or id enumeration via brute-force
• Client-side application/browser autocomplete or saved credentials
• Verbose error pages without proof of exploitability or obtaining sensitive information
• Lack of SSL/TLS or SSL/TLS best practices that do not contain a fully functional proof of concept.
• SSL/TLS mixed content issues, (unless it leaks sensitive information like cookies, credentials)
• Cross-site Request Forgery (CSRF) with low security impact (logout CSRF, etc.)
• Missing Cookie flags or Missing/Enabled HTTP Headers/Methods (unless it leads directly to a security vulnerability)
• Low impact Stack trace disclosures, Information disclosures and banner grabbing issues (Software and Server version disclosure etc.)
• Exposed login pages
• Vulnerabilities affecting only outdated user agents or application versions
• Directory listings (unless it reveals sensitive and useful information)
• Incomplete or missing SPF/DMARC/DKIM records
• Password/credential strength issues including length, lockouts, or lack of brute-force/rate limiting protections
• Self-XSS
• Unchained open redirects
• IIS Tilde File and Directory Disclosure (unless it reveals sensitive and useful information)
• Low impact Content Spoofing issues
• UI and UX bugs (including spelling mistakes)
• Open redirect using Host header

Reporting a Suspected Security Vulnerability

Individuals or organizations that suspect a security issue are strongly encouraged to contact the Fortinet.  Fortinet welcomes reports from independent researchers, industry organizations, vendors, customers, and other sources concerned with product or network security. The minimal data needed for reporting a security issue is a description of the potential vulnerability.

Please contact the Fortinet Incident Response teams via the web form here by selecting the appropriate vulnerability category.

Support requests that are received via email are typically acknowledged within 24 business hours. Ongoing status on reported issues will be determined as needed.

Further communications with the reporter may be via email. The Fortinet PSIRT supports encrypted messages via PGP/GNU Privacy Guard (GPG). The Fortinet PSIRT public key (key ID 0xC7A59F07) is available at https://www.fortiguard.com/pgpkey.

Responsible disclosure process

Fortinet recognizes and appreciates the important role played by independent security researchers and our customers in collaborating to keep our product ecosystem secure.  We request that vulnerability reporters follow the processes below for reporting a vulnerability.

When Fortinet PSIRT receives a security vulnerability report, it will be investigated as quickly as possible to identify the risk and prioritize based on the potential severity of the vulnerability and other factors.  Ultimately, the resolution of a reported incident may require upgrades to products that are under active support from Fortinet.

The following graphic illustrates the Fortinet PSIRT process at a high level and provides an overview of the vulnerability lifecycle, disclosure, and resolution process.

Throughout the investigative process, the Fortinet strives to work collaboratively with the source of the report (incident reporter) to confirm the nature of the vulnerability, gather required technical information, and ascertain appropriate remedial action.  When the initial investigation is complete, results will be delivered to the incident reporter along with a plan for resolution and public disclosure.  If the incident reporter disagrees with the conclusion, the Fortinet PSIRT will make every effort to address those concerns.

During any investigation, the Fortinet PSIRT manages all sensitive information on a highly confidential basis.  Internal distribution is limited to those individuals who have a legitimate need to know and can actively assist in the resolution. Similarly we ask incident reporters to:

• Maintain strict confidentiality until complete resolutions are available for customers and have been published on the Fortinet website through the appropriate coordinated disclosure or Fortinet have notified you that the issue has been mitigated.  We take the security of our customers and infrastructure very seriously, however some may take longer than others to resolve.
• Provide full details of the security issue including steps to reproduce and the details of the system where the tests were conducted and a clearly defined impact.
• Refrain from accessing any non-public data. If a vulnerability provides unintended access to data.
  • limit the amount of data you access to the absolute minimum required for effectively demonstrating a Proof of Concept, and
  • cease testing and submit a report immediately if you encounter any user data during testing, such as and without limitation, Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or proprietary information;

We also request that reporters DO NOT:

• Cause potential or actual damage to Fortinet, systems, or applications.
• Use an exploit to view unauthorized data or corrupt data.
• Engage in disruptive testing including but not limited to DoS, fuzzing, automated scanning of cloud services, or any action that could impact the confidentiality, integrity, or availability of information and systems.
• Engage in social engineering (e.g. phishing, vishing, smishing)  of Fortinet employees or customers.

With the agreement of the incident reporter, the Fortinet PSIRT may acknowledge the reporter's contribution during the public disclosure of the vulnerability.

Fortinet works with MITRE for issuance of a Common Vulnerabilities and Exposure ID where required and will publish the details of the vulnerability once resolved.  Fortinet will work with third party organizations including, but not limited to CERT/CC for coordinated industry disclosure for vulnerabilities reported to Fortinet that may impact multiple vendors (for example, a generic protocol issue).  In those situations, the Fortinet will either assist the incident reporter in contacting the coordination center or may do so on that individual's behalf.

Fortinet will coordinate with the incident reporter to determine the frequency of status updates of the incident and documentation updates.

In the event Fortinet becomes aware of a vulnerability that does not affect a Fortinet product, but does involve another vendor's product, Fortinet may report the issue upstream.

Fortinet does not have a bug bounty program.

Threat Risk Assessment and SLAs

Fortinet categorizes threats according to the Mitre Common Weakness Enumeration (CWE) language.

Fortinet uses version 3.1 of the Common Vulnerability Scoring System (CVSS) as part of its standard process of evaluating reported potential vulnerabilities in Fortinet products. The CVSS model uses three distinct measurements or scores that include Base, Temporal, and Environmental calculations which the Fortinet PSIRT uses to assign a severity level.

Issues with an informational vulnerability category are typically published as a bug in the release notes and not as part of a PSIRT Security Advisory.

Fortinet reserves the right to deviate from these guidelines in specific cases if additional factors are not properly captured in the CVSS score.

If there is a security issue with a third-party software component that is used in a Fortinet product, Fortinet typically uses the CVSS score provided by the third party. In some cases, Fortinet may adjust the CVSS score to reflect the usage of the component and/or impact to the Fortinet product.

More information about CVSS scoring can be found at http://www.first.org/cvss/

* Note that for Enhanced Tech products with a rapid release cycle, and where upgrade options are available, this may be limited to the previous 4 minor versions or limited based on the known number of active instances.

Communications Plan

If one or more of the following conditions exist, Fortinet will publicly disclose Fortinet Security Advisories:

• The Fortinet PSIRT has completed the incident response process and determined that enough software patches or workarounds exist to address the vulnerability, Full/public disclosure of the vulnerability has or is going to been made. All vulnerabilities up to and including High Severity are published on the first Tuesday of the month and a Monthly Advisory notice sent. Critical vulnerabilities will be published via an Out of cycle PSIRT advisory as necessary.
• If Fortinet PSIRT has observed active exploitation of a vulnerability that could lead to increased risk for Fortinet customers, Fortinet may accelerate the publication of a security announcement describing the vulnerability via an Out of Cycle Advisory that may or may not include a complete set of patches or workarounds
• There is the potential for increased public awareness of a vulnerability affecting Fortinet products that could lead to increased risk for Fortinet customers. For this condition, Fortinet will accelerate the publication of an Out of Cycle Advisory describing the vulnerability that may or may not include a complete set of patches or workarounds.
• Fortinet reserves the right to deviate from this policy on an exceptional basis.

There are several ways to stay connected and receive the latest security vulnerability information from Fortinet. Review the following table, and subsequent summaries, to determine the appropriate option.

Safe Harbor

We will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this Policy.

Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. We cannot and do not authorize security research in the name of other entities. Please refer to that third party's bug bounty policy, if they have one, or contact the third party either directly or through a legal representative before initiating any testing on that third party or their services. If legal action is initiated by a third party against you and you have complied with this Policy, we will take reasonable steps to make it known that your actions were conducted in compliance with this Policy. While we consider submitted reports to be confidential documents, please be aware that a court could, despite our objections, order us to share report-related information with a third party. For clarity, this policy and any actions taken hereunder are not, and should not be understood as, any agreement on our part to defend, indemnify, or otherwise protect you from any third-party action based on your actions.

You are expected, as always, to comply with all applicable laws and regulations.

Please contact us or submit a report to us before engaging in conduct that may be inconsistent with or unaddressed by this policy. We reserve the sole right to make the determination of whether a violation of this policy is accidental or in good faith, and proactive contact to us before engaging in any action is a significant factor in that decision.

Public Relations or Press Queries

For any questions regarding a vulnerability in a Fortinet product please contact [email protected].