Here are my disclosure processes and guidelines.

This is for those discoveries which seem to just fall in my lap while causally using and/or seeing a product. My disclosure process is an attempt to do the right thing when this happens.

Note: NDA-protected discoveries (ex. through a client engagement) would not be subject to this.

My Philosophy:

• Definitions/Notes:
  • Owner = the creator of the vulnerable software, hardware, or process (ex. a software vendor)
  • Customer = the purchaser and/or user of the owner’s software/hardware/process (ex. a user of said software)
  • The owner may / may not be the same person/entity
  • Public disclosure = my blog, Twitter, etc.
• I do my best to stick to my self-imposed ethical boundaries
• Give the software/hardware owner reasonable time to react to the disclosure:
  • If the owner requests more time, give more time, within reason.
  • 90+ days, unless it’s a very unique situation, is not reasonable.
  • 180+ days is not acceptable.
• Disclose in as safe and fair manner as possible, understanding no disclosure process is perfect.
• Attempt to give multiple actionable mitigations with every disclosure.
• Avoid giving a customer details of the owner’s vulnerability, unless it is a last resort.
• If the owner agrees, and after addressing any concerns, publicly release a version of the disclosure they are comfortable with.
• In some cases, publicly disclose the details as soon as possible, as to provide the community with awareness and knowledge.
  • Avoid script-kiddie-level copy/paste exploit code as much as possible with public disclosures.
  • Give the owner an opportunity to send their comments for consideration to be included along with the public disclosure (ex. “We do not feel this is an issue because…” or “Customers can protect themselves by…”).

My [Pausable] Timeclock:

I’m not obligating myself to every detail of this timeline, but strive to follow it just as written.

• Overview
  • Timeclock is pausable at any time:
    • if I think a unique circumstance justifies
    • if the owner maintains an open line of communication
• Day 0:
  • Ensure all PoC code/data is cleaned-up ASAP.
  • Identify the owner of the vulnerability.
  • Contact the owner with a basic, “I found a vulnerability and need to know the best/safest way to report it” email.
    • search site for “disclosure|bug bounty” information
    • look for /.well-known/security.txt
    • email: security@, abuse@, noc@, plus any other listed “support” addresses
  • Begin creating the full disclosure report, with screenshots, reproducibility, recommendations, etc.
• Day 2/3:
  • If the owner has not replied after 48-72 hours:
    • look for and utilize alternate forms of contact with an even more basic, “I sent an email, please get back with me” message.
      • Facebook, Twitter, LinkedIn, etc.
      • Phone
  • Attempt to have the full report complete and ready for release to the owner.
• Day 7:
  • If disclosure is for an “attack vector,” as opposed to an oversight/vulnerability, publicly disclose.
  • If it’s a vulnerability, and the owner still has not replied to the initial email:
    • Find a responsible customer of the owner’s product (should the two be different).
    • Send a very general, “There’s a vulnerability with X.  Please help me get in contact with the owner.”  Do not disclose the details to the customer.
    • Email the owner again.  If applicable, inform them which customer you contacted and the disclosure timeline.
• Day 14, 21, 28:
  • Repeat Day 7’s steps.
  • If applicable:
    • Choose a different customer each time.
    • Increase the amount of detail given to the customer about the vulnerability in an attempt to get traction on the issue.
• Day 30:
  • Publish the full disclosure report that would have been sent to the owner, after additional obfuscation.
  • Inform the owner, and cease additional communication attempts.