Fortinet Acquires Next DLP Strengthens its Top-Tier Unified SASE Solution Read the release

Internal security

Header 1

Trust Portal

For more information about our security practises, documents and certifications. Check out our trust portal at: https://trust.nextdlp.com/

Reporting & support for a suspected security vulnerability

Anyone experiencing a Next DLP product security issue is strongly encouraged to contact the Next DLP PSIRT via security@nextdlp.com. Next DLP welcomes reports from customers, vendors, security researchers, industry organizations, and other stakeholders. Please contact the Next DLP PSIRT via security@nextdlp.com. Support requests will be acknowledged within 48 hours.

General security-related queries
For general security questions, please contact support@nextdlp.com.

Responsible disclosure policy

How to report a security vulnerability?

If you believe you’ve found a security vulnerability in one of our products or platforms please send it to us by emailing security@nextdlp.com.

  • Please include the following details with your report:
    Description of the location and potential impact of the vulnerability
  • A detailed description of the steps required to reproduce the vulnerability (POC scripts, screenshots, and compressed screen captures are all helpful to us)
  • If you require credit on any vulnerability announcement

Guidelines for security researchers

Next DLP takes the security of our customers and its relationship with the security research community seriously. This document outlines what can be expected from Next DLP when a vulnerability is reported and what Next DLP considers to be acceptable for researchers in the process of testing.

We require that all researchers:

  • Perform research only within the scope set out below.
  • Use the identified communication channels to report vulnerability information to us.
  • Keep information about any vulnerabilities you’ve discovered confidential between yourself and Next DLP until we’ve had 90 days to resolve the issue.

 

If you follow these guidelines when reporting an issue to us, we commit to:

  • Not pursue or support any legal action related to your research.
  • Work with you to understand and resolve the issue quickly (including an initial confirmation of your report within 72 hours of submission).
  • Recognize your contribution on any vulnerability
    announcement or CVE. Anonymity will be respected if requested.

Scope

Legally acquired versions of Next DLP software running in a deployment for which the researcher has the rights, or explicit permission, to test are in scope. Security researchers may be provided with trial versions of software for experimentation.

Out of scope

Any services hosted by 3rd party providers and services are excluded from scope. In the interest of the safety of our users, staff, the Internet at large and you as a security researcher, the following test types are excluded from scope:

  • Findings from physical testing such as office access (e.g. open doors, tailgating)
  • Findings derived primarily from social engineering (e.g. phishing, vishing)
  • Findings from applications or systems not listed in the ‘Scope’ section
  • Network level Denial of Service (DoS/DDoS) vulnerabilities

Things we do not want to receive:

  • Personally identifiable information (PII)
  • Credit card holder data

Vulnerability disclosure policy

Next DLP is committed to resolving vulnerabilities to meet the needs of its customers and the broader technology community. This document describes Next DLP's policy for receiving reports related to potential security vulnerabilities in its products and services and the company’s standard practice with regards to informing customers of verified vulnerabilities.

When to contact the Product Security
Incident Response Team (PSIRT)

Contact the Next DLP Product Security Incident Response Team (PSIRT) by sending an email to security@nextdlp.com in the following situations:

  • You have identified a potential security vulnerability with one of our products.
  • You have identified a potential security vulnerability with one of our services.
  • After your incident report is received, the appropriate personnel will contact you to follow-up.

The security@nextdlp.com  email address is intended ONLY for the purposes of reporting product or service security vulnerabilities. It is not for technical support information on our products or services. All content other than that specific to security vulnerabilities in our products or services will be dropped. For technical and customer support inquiries, please contact support@nextdlp.com. Next DLP attempts to acknowledge receipt to all submitted reports within 48 hours.

Receiving security information from Next DLP

Technical security information about our products and services is distributed through several channels.

  • Next DLP distributes information to customers about security vulnerabilities via nextdlp.com. In most cases, we will issue a notice when we have identified a practical workaround or fix for the particular security vulnerability though there can be instances when we issue a notice in the absence of a workaround when the vulnerability has become widely known to the security community. As each security vulnerability case is different, we can take alternative actions in connection with issuing security notices. Next DLP can determine to accelerate or delay the release of a notice or not issue a notice at all. Next DLP  does not guarantee that security notices will be issued for any or all security issues customers can consider significant or that notices will be issued on any specific timetable.
  • Security-related information can also be distributed by Next DLP to public newsgroups or electronic mailing lists. This is done on an ad hoc basis, depending on how Next DLP perceives the relevance of each notice to each particular forum
  • Next DLP works with the formal incident response community to distribute information. Security notices may be distributed by regional CSERT at the same time that they are sent through company information distribution channels.

All aspects of this process are subject to change without notice, as well as to case-by-case exceptions. No particular level of response is guaranteed for any specific issue or class of issues.

 Disclaimer

Use of the information constitutes acceptance for use in an AS IS condition. There are no express or implied warranties or assurances with regard to this information. Neither the author nor the publisher accepts any liability whatsoever for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.

Internal process

Overview

  • Vulnerability reports can originate with customers or from internal processes
  • Triage identifies (potential) security issues. Turn around in 48 hours
  • Non-issues are communicated to the reporter. Invitation for more information. Process starts again if the report is resubmitted
  • If the issue is already public or is being exploited in the wild, then draft a security advisory and publish before a fix is ready
  • Developer planning (assigning tasks etc)
  • Process forks into two paths:
    • Mitigation (writing a fix)
    • Reproduction of the issue (make tests) and search for similar issues (systematic failures)
  • Process joins with code and tests in CI
  • Release follows confirmation of fix
  • Security advisory published (or updated)

At any point in the process, PSIRT can choose to issue or update a security advisory if the issue becomes public.


Confidentiality

All public communication on the subject of security vulnerabilities is via PSIRT through agreed channels.

Triage

Issues which impact (in a way which can be used by an attacker) the Confidentiality, Integrity or Availability (CIA) of installations are considered to be security issues. At this point severity is not considered: if it impacts one of CIA, then it’s a security issue.

Security issues are prioritized by severity using CVSSv3 scoring:

  • Vulnerabilities are labeled “Low” severity if they have a CVSS base score of 0.0-3.9.
  • Vulnerabilities will be labeled “Medium” severity if they have a base CVSS score of 4.0-6.9.
  • Vulnerabilities will be labeled “High” severity if they have a CVSS base score of 7.0-8.9.
  • Vulnerabilities will be labeled “Critical” severity if they have a CVSS base score of 9.0-10.0.

These map to turnaround times as follows:

  • Low: next maintenance release
  • Medium/High: maintenance release with seven days
  • Critical: 48 hours for patch/mitigation

PSIRT can raise the priority to Critical in response to exploitation in the wild, public disclosure, etc.

Internal security