To homepage

Responsible Disclosure

Share this page

MEN09515

Responsible disclosure

We make every effort to keep our systems secure. Still find a problem in our security?Please report it so we can fix it right away. We call this reporting a vulnerability disclosure (also known as coordinated vulnerability disclosure and responsible disclosure).

How do you report a problem?

  • Send it to security@noordgastransport.nl. Can't mail it?
  • Then call us at: +31 85 208 75 01.
  • Give us as much information as possible; that will help us reproduce and solve the problem. Provide us with a detailed description with IP addresses, logs, screenshots, etc.

Give us your contact information, a phone number or a mailing address. This enables us to reach you if we want to know more

What should you pay attention to?

  • Don't tell anyone else about it.
  • Destroy data you have obtained.
  • Do not go further than necessary to prove the problem.
  • Do not abuse the security breach or we will be forced to file a report.

What can you report?

Examples of reportable vulnerabilities:

  • Remote Code Execution
  • Cross Site Scripting (XSS) vulnerabilities
  • Cross Site Request Forgery (CSRF) vulnerabilities
  • SQL injection vulnerabilities
  • Vulnerabilities related to encryption
  • Unintended publication of sensitive data
  • Security misconfiguration

Unauthorized access to data

What you don't have to report (out of scope):

  • Social engineering, including phishing, pretexting, baiting and similar techniques.
  • Resource attrition and (Distributed) Denial of Service attacks.
  • Physical attacks or unauthorized in-person access.
  • Situations that are not reproducible or whose impact has not been demonstrated to be reproducible.
  • Vulnerabilities that have not been validated with a second method or tool (e.g., tool A detects vulnerability, tool B does not).

  • Cosmetic issues, such as layout differences between browsers (e.g. doesn't look right in browser A). Report this via webmaster@noordgastransport.nl if necessary.
  • User behaviour, such as leaving workstation unattended, clicking on links or using key combinations.
  • Simple listings of ports, services or version numbers without further context or abuse scenario.
  • Public files or directories that do not contain confidential information and should be publicly available.
  • Missing HTTP-only or Secure flags on cookies that do not contain sensitive information.
  • TLS/SSL configuration issues with no working proof-of-concept or no demonstrable impact (e.g. SSL Forward Secrecy disabled).
  • HTTP security headers that are missing, such as X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, Content-Security-Policy, or Strict-Transport-Security.
  • OPTIONS HTTP method available without evidence of abuse.
  • URL redirects to legitimate and valid pages.
  • Clickjacking or content spoofing with no obvious security impact.
  • Local content spoofing or text injection on error pages (such as 404s) without sensitive interaction.
  • Host Header Injection with no evidence of abuse.
  • Missing or incorrect SPF, DKIM, DMARC or CAA DNS records without demonstrable impact.
  • Fingerprinting or version information of public services without known vulnerability or exploitability.
  • Outdated software versions without publicly known exploits or without working exploitation in context of our system.
  • Issues that occur only when using outdated or unpatched browsers or platforms on the user side.
  • Absence of hardening or security best practices without direct vulnerability (e.g. xmlrpc.php on WordPress, absence of rate-limiting).
  • Issues requiring improbable or unrealistic user interaction.
  • Cross-site Request Forgery (CSRF) with minimal or no security impact.
  • Services running at external third parties; reports for these should go through their own responsible disclosure process.
  • Information from data breaches at external parties, such as email addresses found through public breaches.
  • Vulnerabilities for which patches are available for less than 14 days.
  • Known problems with protocols or technologies not in our management domain (e.g. ARP, HL7).

    Duplicates of previously reported vulnerabilities; in this case, we handle only the first report.

Known problems

There are also problems that are already known to us and that we are working on or recognize as accepted risks. We do not name these problems on the website. However, our support team is aware of them and will indicate them. As a result, the issue will not be addressed.

Security.txt

With the publication of RFC 9116 earlier this year, a unified way is now available for organizations to publish their vulnerability disclosure policies and contacts. To that end, a text format was devised that is readable by both machines and humans and published on the website in the security.txt file. Our security.txt file can be found here: https://www.noordgastransport.nl/.well-known/security.txt.

Agree?

By submitting you’re finding to Noordgastransport, you acknowledge that you have read and agree to our terms and conditions. You also represent to us that you are the sole creator of the submission and hereby grant us permission to use, reproduce, copy, modify and dispose of your submission in any manner we determine. You also agree that you may not use your submission for marketing or financing purposes or as a reference in any personal or professional presentation, documentation or other material and that you may not use in any way (either on the Internet or through any other means of communication) our trade name, company name, logo or trademark