security@ Is a Two-way Street

More and more companies are embracing the benefits of maintaining a dedicated security team to not only help manage internal processes such as a systems development life cycle (SDLC) that may focus on security, but to also manage vulnerability reports from external parties. Some companies choose to implement bug bounty programs, and some do not. The manner in which they implement such programs, and their choice in methods of rewarding researchers is only the start. There are additional considerations that security teams must keep in mind, that may have negative consequences. Unfortunately, many companies that are considered to have mature security programs do not grasp this. Worse, it is clear there is a negative impact, but it cannot be measured.

Security teams that handle incoming vulnerability reports (e.g. security@company email addresses) do it because it benefits them. Any other benefits to the researchers reporting issues are a part of doing business so to speak. For some of these teams, anything beyond that has no apparent value to them and without knowing it, they begin to burn bridges. This primarily comes in the form of external parties asking the security teams for information. They aren’t necessarily offering much, or anything, but asking for something in return. Giving out additional information about vulnerabilities goes against almost every principal of a security team. In many cases this is a good move and prudent. In a few cases, this is not the right move, only giving out information that does not compromise security, rather it enhances security in the long run. Short-sighted security teams do not see this long game, even when the long game is only a move or two out.

Some of the common questions a security team may receive, that should not go unanswered, or require a customer / license number to have the conversation:

  • Clarification over a confusing or duplicate CVE assignment
  • Reporting that a security patch does not work
  • Asking about contradictory information regarding which versions are vulnerable
  • Questions about if a given vulnerability affects other very similar products/OSs

These types of questions, especially when sent from a security provider of any sort (i.e. software or service), are asked to benefit mutual customers. Even if the security team isn’t immediately aware of that, any mail asking for clarity or help with making your products installed on their systems more secure should not go unanswered.

Along the same vein, acknowledging such emails and saying you will follow-up after doing research, only to never reply again or give a definitive answer, isn’t helpful. When researchers email with such questions, it is critical to remember that these may be the same people sending you vulnerability reports. They often work with you to help your product security, give you the time you need to provide mitigation, and ultimately work for a single mention at the bottom of an advisory.

The next time your security team receives the type of email listed above and you don’t respond in a helpful matter, ask yourself one question; why should they continue to help you by reporting vulnerabilities, when you don’t help them achieve better security for your mutual customer’s systems?

This blog was inspired by hundreds of emails sent over the last decade to vendor security teams, trying to clear up confusion in published advisories, and better understand why security patches are not working as advertised. This problem is not limited to new or smaller security teams either! Some of the biggest companies have failed to provide such help in the past. For a few, it is rare and understandable due to the workload. For others, who never reply to such questions but happily take in vulnerability reports, they have already alienated some researchers without realizing it. That works against the entire purpose of the security team and trying to make software more secure.


Leave a Reply

%d bloggers like this: