Disclosure Policy

Introduction

Releasing vulnerability information is an all-time discussed topic with many different attitudes. Every policy has advantages and disadvantages, but I like CERT’s 45-day policy. So I have adopted their policy with minor changes and used it for my disclosure process.

Summary

The advisory will be immediately published using the Full-Disclosure mailing list either when:

  • The 14-day initial deadline ends: The vendor does not respond to any initial notifications or acknowledge the vulnerability.
  • The 45-day final deadline ends.
  • The vendor releases an official update.
  • A third party publishes an advisory on the same issue.
  • The vendor hasn’t responded to multiple previous coordination attempts.

Assignment Process

Every new disclosure will be assigned an official CVE identifier (as per MITRE).

Notification Process

In this phase, the vendor will be initially notified about the vulnerability. The notification might already include the vulnerability details. However, this ultimately depends on the contact possibilities offered by the vendor. It usually contains a preset disclosure date, which is set 14 days after the first notification.

Disclosure Process

If the vendor doesn’t respond to the notification(s) or doesn’t acknowledge the vulnerability once the 14-day deadline ends, the vulnerability will be disclosed immediately. I decided to take this strict first deadline for a straightforward reason: In 95% of my previous coordination attempts, a vendor who did not respond within the first 14 days likely won’t respond at all.

If the vendor responds, the initial deadline can be extended to the 45-day final deadline when the vendor provides a good reasoning for it. While working on the issue until the final deadline, I expect regular status updates on the report (at least every two weeks). If there is none, the vulnerability will be made public after 45 days, regardless of its state.

However, the deadline might be further extended if the vendor has a very good explanation, the vulnerability affects a wide range of users or systems, or the vulnerability is hard to patch (i.e. manual firmware upgrades are required).

As soon as the initial or final deadline ends, the vulnerability details will be made public depending on the relationship between RCE Security and the vendor (e.g., previously negotiated NDA due to active contracts). The primary places for public disclosure are this blog and the Full-Disclosure mailing list.

Since I believe in maximum transparency and effective ways for administrators and penetration testers to test vulnerable systems, I will also publish either a Proof-of-Concept or an exploit alongside a blog article.