Create Secure Channels for Reporting
Whether you are a vendor or a coordinator, you need to have open channels for communication with vulnerability finders and reporters. Secure communications can be nuanced to maintain in operation, so we have compiled some advice about establishing and maintaining this capability.
Web Forms and Portals
Most vulnerability reports have a similar structure, making a web form a preferable method for receiving vulnerability reports for many organizations.
Focus on Encrypted Transport and Strong Authentication
If you're starting a new CVD program, we recommend focusing on encrypted transport and strong authentication. Don't build a new process around PGP / GnuPG and email. Some vendors choose to offer a web form specifically for receiving reports of security-related issues. Such forms can then deliver the report directly to your security or engineering team.
Have a Dedicated Form for Security Reports
The CERT/CC discourages reliance on general "Contact Us" web forms that pass through an organization's communications or customer support teams. Many finders will balk at having to get past these nontechnical interfaces into the vendor. In addition, security messages often must be triaged and processed differently than other incoming contacts.
To secure your web form, you will need to enable HTTPS and TLS, and obtain a TLS certificate from a Certificate Authority (CA). A free option is Let's Encrypt, maintained by the Internet Security Research Group (ISRG).
Coordination tools like VINCE or coordination platforms can be a good choice, or you can make use of a third-party bug bounty or coordination platform.
Do you need a login to report?
TLS ensures that the transmission is secure, but does not authenticate who sent the report. If this is a requirement, you may also need to implement login accounts on your web form with adequate authentication mechanisms such as two-factor or X.509 certificates. However, this setup increases the complexity for reporters to provide information to you, and as a result is rare in practice and likely unnecessary. Once set up, an HTTPS web form provides an easy-to-use way for reporters to contact you with vulnerability reports and other information.
However, a problem does come up: how do you acknowledge receipt of the report and continue the conversation?
Possibilities include the following:
-
Echoing back the message in a confirmation email. The reporter knows you received the text, but now the text was sent in plain text email for everyone to read. It is unlikely you want to do this.
-
Send a brief thank you message, but without details. The reporter can now be assured that the report was received. But what if you have a follow up question for the reporter? It's likely you will need to send an email, which will require encryption to keep the details of the question and answer secure.
-
Send a brief thank you message, and ask the reporter to log in to a portal to view the message conversation. This resolves the issue of two-way secure communications, but now you need to establish a public-facing portal and manage portal credentials. This raises additional operational considerations, for example those below:
-
user account management and password changes
-
two-factor authentication or X.509 as possible requirement to ensure user identity
-
Portal credential maintenance introduces more complications, and for many vendors may not be worth the effort. Another disadvantage of using a portal is that vendors and organizations may be unwilling to create accounts on another vendor's portal. This may discourage multi-party communication and coordination, effectively preventing a vendor or reporter from participating in multi-party CVD.
CVD Platforms and Turnkey Services
CVD Platform Providers
Some popular CVD platform providers include:
A number of third-party CVD platforms now exist to facilitate communication between vendors and reporters. Although they are often referred to as bug bounty platforms, the bounty aspect is in fact optional—vendors can use CVD platforms to receive reports without needing to compensate reporters unless they choose to do so.
CVD platforms provide a secure communications channel (HTTPS) for reporters to communicate with vendors. These platforms generally allow two-way communications, making it easy for ongoing discussion between vendor and reporter. This channel is usually hosted by a third party in a software-as-a-service model, which may be important to some organizations that are not able to maintain their own infrastructure due to resource constraints. Of course, having vulnerability information hosted on third-party infrastructure may also present a data privacy risk to some organizations, so it is important to consult internal policies before determining if a CVD platform fits your organization's needs and requirements.
DoD's Vulnerability Disclosure Program
The U.S. Department of Defense (DoD) has a Vulnerability Disclosure Program (VDP) that uses a CVD platform to receive reports from security researchers. The DoD VDP is a public program that allows security researchers to report vulnerabilities in DoD websites and systems. The DoD VDP is a good example of a CVD platform that is used to facilitate communication between reporters and vendors, even without an explicit bug bounty program. Reporters to the DoD VDP are not compensated monetarily for their reports, but they are able to gain recognition and reputation points within the CVD platform that can lead to future opportunities for paid work.
CVD Platforms and Account Creation
An important note regarding these platforms is that the CVD platform by its nature requires a login. As explained previoiusly, requiring an account may discourage some reporters or other organizations from joining the platform, locking them out of discussion. Organizations should consider whether the benefits of using a CVD service outweigh this concern.
Email is a simple, tried-and-true method of communication over the Internet. Simply because everyone has access to it, email is likely to remain a common way of receiving vulnerability reports and communications.
Email is the Universal CVD API
In our experience, email is still a very common way to receive
vulnerability reports. It serves as a sort of universal API for CVD,
regardless of what other tools might be in use.
For this reason, the CERT/CC recommends that vendors establish a specific
and well-publicized email alias such as security@example.com solely
for receipt of vulnerability reports, even if they have other
communication channels available.
Email is Insecure by Default
Email by itself is not a secure medium. We recommend that emails containing sensitive information be encrypted [2]. This includes emails containing information about unpatched or otherwise sensitive vulnerabilities.
Avoid Using Personal Email Addresses for Security Contact
Because of the potential for organizational changes like
employee promotions and turnover, having an individual's email address
as a security point of contact is generally discouraged. A better
solution is to establish an email account specifically for vulnerability
reports and CVD activity. Many vendors choose to reserve an email
address like security@example.com or psirt@example.com for
this purpose.
Make Your Security Contact Information Easy to Find
The CERT/CC recommends that vendors make their security contact information easy to find, for example on the Contact Us page of their website.
Ideally, an Internet search for <vendorname> report vulnerability
should lead to that contact information. The security email account
should be an alias that is forwarded to or shared by one or more people.
This way, multiple team members can check the incoming mail and cover
for each other when team members are out of the office. Even if the
security team is only one person, having an alias makes it easier to
adapt should that person leave the organization; to the outside world,
no contact information needs to change.
The IETF's RFC 2350{:target="blank"} _Expectations for Computer Security Incident Response (aka BCP-21) suggests you include contact information as part of your overall CSIRT disclosure policy and process publication. RFC 9116{:target="blank"} _A File Format to Aid in Security Vulnerability Disclosure See the security.txt site for more.
Email is No Substitute for a Case Tracking System
Although receiving information via email is convenient, it is not a very good mechanism for tracking multiple cases at once. Rather than sending security emails to individual mailboxes, vendors, coordinators, and even large-scale reporters should consider setting up a web-based case tracking system instead. That way, received emails can automatically generate new cases or augment existing ones, which can then be assigned to team members and tracked as necessary. More on this topic can be found in Case Tracking.
Managing Email Encryption
Although we primarily recommend web-based case tracking systems for managing communications in CVD, email encryption can still be useful for securing sensitive information in transit.
Since email is an insecure communications channel by default, many vendors, reporters, and coordinators prefer to use encrypted mail instead. Although x.509 encrypted mail exists, we have found PGP-compatible tools such as GnuPG to be more widely used by CVD participants. Vendors are encouraged to create and publish a PGP key affiliated with the security email alias to allow the confidentiality of sensitive reports to be maintained in transit.
A common choice used to be Thunderbird with Enigmail, but Thunderbird is no longer supported by the Enigmail project. Alternative mail clients for Enigmail include SeaMonkey, Epyrus and Postbox.
Other open source solutions such as Outlook with gpg4win, or KMail with KGpg and/or Kleopatra and proprietary solutions such as PGP Encryption Desktop also exist. A collection of email encryption tools can be found on OpenPGP's website.
How Our Approach has Changed
The CERT/CC has used email as the primary means of communication for many years. However, as our operations have scaled up, we have found that email is not always the best way to manage multiple cases simultaneously. We have since developed a web-based case tracking system called VINCE to help us manage our cases more effectively.
While email still has its place in our CVD operations, we have found that PGP / GnuPG is overly complicated for many of the folks we need to coordinate with, reporters and vendors alike.
What happened to PGP/GnuPG?
PGP / GnuPG, never popular outside of the infosec community, has been falling out of favor in the past decade. Some notable commentary includes: What's the Matter with PGP?, GnuPG and Me, and I’m throwing in the towel on PGP, and I work in security.
PGP and GnuPG are highly prone to user error, and the consequences of those errors can be severe (e.g., sending a private key to the wrong person). The tools are also difficult to manage at scale.
Encrypted email was intended for one-to-one communication, but in CVD, we often have teams of people from different organizations working together. In this scenario, the team often has a single key. Everyone outside the team encrypts to that one key, but on the receiving side, the email is often decrypted and forwarded as plain text within the team (e.g., posted to a case tracking system). For all practical purposes, the email encryption is just serving as transport encryption rather than end-to-end from sender mail client to receiver mail client. But other technology like StartTLS already enables transport encryption, and that is usually configured by mail server administrators who are more likely to get it right than individual users. It's not clear that the additional complexity adds much value.
Finally, there is the question of what the threat model is. In other words, who are you trying to protect against? A highly skilled adversary can likely get access to the key material itself, or to the contents of the email in plain text before encryption or after decryption. A less skilled adversary might be able to intercept the mail in transit, but if you're using StartTLS, that's already encrypted in transit.