Implementing a Responsible Disclosure policy with PGP

by Justin Bull

I had the opportunity to help my employer, FreshBooks, implement a responsible disclosure policy. As it turns out, it's very difficult to offer a PGP key while maintaining trust, security, and convenience.

In this post I hope to outline the struggles, the roadblocks, and practical strategy surrounding PGP key management for a ~100 person company.

The Tweet that Started it All

It all started with the above tweet. One of my favourite security-conscious people I follow was complaining about the piss-poor state of secure responsible disclosure pages that vendors offer. It got me to thinking, "Gee whiz, does FreshBooks even have a responsible disclosure policy?" Not surprisingly the answer was no.

I decided that with FreshBooks growing bigger and more important every quarter, we owe it to our users to explicitly provide a mechanism of disclosure that researchers will be comfortable with. The more acceptable we are, the more likely they are to disclose vulnerabilities or exploits to us.

If we were going to do this, we were going to do it right. That means no plaintext pages, no insecure email communications, and no lack of common mechanisms that security researchers expect.

I don't want FreshBooks to be like that. We are going about this properly if we're going to do it at all.

The Policy

The page itself is a simple one.

Like most software companies, we explicitly state what we do & don't allow, how to go about it, where to report the vulnerability, and how they'd like their attribution (if at all).

The key components are:

  • How to report an issue
  • Permitted research: what's allowed and what's not (for example, banning Denial of Service testing)
  • Rewards (if applicable)
  • Researcher attribution

The initial idea was to offer a general security inbox security@freshbooks.com with a PGP key with fingerprint offered on the website and available on PGP key servers. If we were to do this right, it's quite a non-trivial option when the number of recipients for security@ is greater than one.

The PGP Encryption & Trust Strategy

Since we deal in customer financial data, I'd hope that any critical vulnerability gets to us securely. That means creating a strategy that people use… Both internally and externally. There's no use in designing a Fort Knox of a system if your co-workers won't bother to use it!

Above: Sketching out some of the PGP key ideas for the managers briefing.

There are a lot of ways to skin this cat, and I spent some time musing over the best options. Our systems administrator wanted to enforce that when a security team member leaves the company that we have a way to revoke their access. With a shared PGP keypair for a security@ mailbox, that's pretty hard to do.

The question is: when a team member departs the company, what prevents them from being malicious with the PGP key? They carry the trust and brand of FreshBooks Security Team <security@freshbooks.com>. Even if you had a revocation certificate handy, the departed could give away the PGP keypair to your competitor in way that you don't know about for months or years!

✗ Option 1: Shared key only

This is the most naïve implementation.

There is a single PGP key for the "FreshBooks Security Team" <security@freshbooks.com> that a researcher encrypt emails to & receive signed correspondence from.

All team members have a copy of the keypair on their workstations and all members have access to the security@ mailbox.

Advantages:

  1. Single point of contact for security researcher.
  2. Anyone on the team can decrypt and respond; potentially faster turnaround time.
  3. All correspondence can be encrypted and signed.

Disadvantages:

  1. No web of trust for the security researcher to trust the key.
  2. Risk of a fired, rogue employee secretly copying the private key before their departure and maliciously signing and/or decrypting messages.

✗ Option 2: Individual keys only

So it's the same physical setup as before but instead of a single PGP key available for security@freshbooks.com we publicly list a team of security officers all with their individuals keys (all of which are intersigned with one-another) and ask the researcher to multi-recipient encrypt their message. Further communication will happen on a per-individual basis.

Advantages:

  1. Web of Trust is (somewhat) maintained with the use of key servers and inter-personal key signing
  2. Revocation of key signatures strongly mitigates risk of a fired, rogue employee secretly copying their private key before their departure and maliciously signing and/or decrypting messages.
  3. All correspondence can be encrypted and signed.

Disadvantages:

  1. Many points of contact for security researcher. They have to choose who to send the report to or encrypt the same message for every recipient of security@freshbooks.com.
  2. Web page must be maintained with the member list of security@freshbooks.com (cumbersome)
  3. There's no concept of trust from security@freshbooks.com saying it trusts these individuals.

✓ Option 3: Shared key for receiving & individual keys for continued correspondence

Step 1:

Security researcher obtains a copy of our public key and sends an encrypted email to security@freshbooks.com

Step 2:

The encrypted email received by Team Lead, Alice, and Bob's inboxes. Since it's encrypted for security@freshbooks.com, Alice and Bob cannot read the email.

Step 3:

Team Lead, being the only owner of the 0x00DEADBEEF <security@freshbooks.com> PGP key, decrypts the message and forwards it, decrypted (or re-encrypted?), to the rest of the team. If the team lead is on vacation or away, have one of the team members respond to the email (signing their response with their personal key) saying that they'll get back to them ASAP once the employee with access to the security@freshbooks.com private key returns.

Step 4:

After the team meets, someone is assigned as the liaison or point of further contact between the team and the researcher. That team member continues to communicate with the researcher signing with their PGP key. That team member is responsible for keeping the rest of the team up-to-date.

When A Team Member Departs:

When a team member leaves the company they revoke their PGP key. In addition, the security@freshbooks.com key and other team members' keys revoke their signature against the departed's key. The keys are then exported and re-sent to the key servers, updating the trust model to exclude the departed team member.

This conveys to a researcher that the departed team member is to no longer be trusted. Any attempt by a departed team member to perform rogue actions (such as impersonation of the security team, selling their key to a competitor) will be thwarted by the trust model.

When The Team Lead Departs:

Similar to the above model but, in addition, the security@freshbooks.com key will also be revoked and re-generated to which a new Team Lead will own. Prior to revocation the old key will sign the new key and vice-versa showing that the newly generated key carries the trust of the old one. All team members will sign the new key and revoke their signatures on the old.

The public website's Responsible Disclosure policy page should be updated to point to the newly generate security@freshbooks.com key.

Advantages:

  1. Web of Trust is maintained with the use of key servers and inter-personal key signing
  2. Risk of a fired, rogue employee secretly copying the private key before their departure and maliciously signing and/or decrypting messages is strongly mitigated unless Team Lead becomes evil.
  3. All correspondence can be encrypted and signed.

Disadvantages:

  1. Potentially slower turnaround time for decrypting messages
  2. Team Lead is a single point of failure
  3. Main key revocation is tied with the departure of the Team Lead.
  4. Each email message has to be relayed to the rest of the team.

The Practical Pushback

This is obviously a fairly complicated structure, and many companies don't bother going through with the effort of implementing proper PGP key management. It's usually the big guns who have dedicated security departments who implement this mess.

Our head of Operations, upon being presented with this strategy, asked about encrypted web forms.

It's not a completely crazy to not offer emails with PGP and just opt for a web form. GitHub does it, after all and it appears there's a move to adopt forms:

My question, at this point, is now twofold:

  1. When we get the report, how do we continue secure communication?
  2. Using a web form could have unintended side-effects such as logging and caching somewhere along the line.

For now we're offering an encrypted web form and a single PGP security@freshbooks.com key that the head of Operations has access to. The web form, under the hood, sends an email to security team which is secured under STARTTLS.

In the next year, we'll move to the full PGP management structure outlined in Option 3.

The PGP Key Generation

So far, I've only described our management strategy when people join and leave the company. The are many ways to go about key generation and storage. Below is more-or-less our plan:

  • All keys should be 4096-bit RSA (sign) & RSA (encrypt) that expire every 5 years
  • Generate a key revocation file for the main key and store it on hard media, such as archival CD-ROM
  • Back up the main keypair's private key on archival media and securely store medium.
  • Randomly generate the passphrases using Diceware or similarly entropic, but human memorable, strategy
  • Encourage use of signing keys internally within the company, publishing the signed keys to a key server.
  • The private keys should only live on the workstations of the owners of said keys (which are protected behind Active Directory)

The State of The Union

At the time of this writing, most levels of management have approved my proposal and Responsible Disclosure policy draft. We're in the process of finalizing the team, defining an explicit response protocol (such as promising an initial response within 24 hours!), and defining internal changes that need to happen. The internal policy strives to conform to the RFPolicy v2.

It's exciting to see that with my persistence that FreshBooks realizes the importance of such a project.

I expect to see the policy and protocol live and ready to go in the near future.

Update!

The responsible disclosure policy is live and so far we've had two disclosures!

This post's header is by Brian Klug, titled Anonymous Hacker. Used under CC BY-NC 2.0.