Security researchers at heart
FireEye was founded with a mission to discover the exploits that were taking advantage of vulnerabilities and bypassing traditional defenses. When we discover an attack, we leverage that information in our threat prevention platform so all of our customers are protected. We then work with the impacted vendors whose products are exposed to make sure all of their customers are protected prior to any public announcements. Once the vendor is able to distribute an update, we make the details of the attack public, so the entire security community can benefit from the research and defend themselves. This is the essence of the coordinated disclosure. Our own goals as security researchers remain the same – to protect our customers and the community against evil.
Over the last two years, our own research team has discovered many zero-day attacks in the wild, protecting our customers as well as the customers of the biggest software vendors in the world. We have and will continue to demonstrate our commitment to the community and work with others in a responsible manner in the same way we expect others to work with us.
How we engage with research community
Vulnerability notifications from the research community are a welcome complement to our own threat research and engineering teams working constantly to improve our products. FireEye has a dedicated site that describes how to notify us of any security issue, and where researchers can submit those issues directly to our security team via [email protected]
We take product security vulnerabilities very seriously and actively respond to any product security issues or concerns that are formally reported to FireEye. As a matter of process, we ask for industry standard responsible and safe disclosure practices for any product vulnerabilities. Our goal is to open and maintain lines of communication, transparency, and engage in a dialogue that will help us protect our customers while we develop fixes and give them some time to patch their systems. We ask that the researcher refrain from publicly disclosing anything about the issue during that coordination period – which can vary depending on the severity of the issue and impact to our customers. Our customers have varying patch cycles, so while we encourage them to patch their systems quickly, we also understand implementation times may fluctuate.
Once the patch is available, we will provide proper credit where credit is due in the release notes on any issues that have been identified by the researcher that were not previously known. This is the same process we follow when we report a vulnerability to another vendor. To date, we have not had any divergence from that process and where researchers have responsibly worked with us, we have provided credit.
To bug bounty or not to bug bounty
This process recently faced a challenge, beginning with a very vocal researcher publically releasing the details of a vulnerability in a FireEye product. This was reported to FireEye via public notification on September 7, 2015, without prior specifics of the vulnerabilities. Based on the information published, the vulnerability impacted legacy versions of our HX products, which could potentially impact less than .005% of our customers. But, if you were following the news, you might have the impression that this issue had broad implications for the FireEye products, in reality this was NOT the case.
We have reached out to Mr. Hermansen about this issue, and we have engaged with him in the past. However he’s insisted that FireEye institute a bug bounty program before he will share the details of his research. Currently, FireEye doesn’t have a bug bounty in place, and as we look at our immediate security industry peer group, none of these companies have a publically stated program either.
We have considered a bug bounty program but as with all things, there are trade-offs that make it more complicated than simply writing a check. For example, once a program is in place, more researchers will submit potential vulnerability, drawing security and engineering resources away from their current work. More of these submitted vulnerabilities will be false positives and once a vulnerability is discovered, how should a reward be priced? Is $10,000 an appropriate price for a vulnerability that impacts .005% of our customers? How can we ensure a researcher feels rewarded for his work if our perception of the impact varies?
For the time being we have decided against a formal bug bounty program, but like any good security program, we will test and evaluate continuously.
Protecting our customers with every available tool - and a little background on a (non) lawsuit
You may have seen some headlines later in the week that FireEye sued a research group, ERNW, in response to a vulnerability disclosure. These reports are flat out wrong and we wanted to clarify how this was handled.
FireEye cooperated with ERNW on the public release of the vulnerabilities, giving them credit. In addition to this, ERNW decided to release its own report on the vulnerabilities. We asked to review the report and coordinate with them on the release. During this review, we called out that the report contained sensitive FireEye intellectual property and trade secrets and asked that this information be removed.
FireEye made multiple requests that ERNW remove the sensitive information from the report, yet ERNW continued to produce drafts that included it. At the same time, ERNW published abstracts about two talks they planned to give in Singapore and London about the report. While we wanted to continue to focus only on the specifics of the vulnerabilities, at this point we were unclear whether ERNW understood our significant concerns. We then asked to meet with them face-to-face in Las Vegas to see if we could arrive at a mutually-agreed upon report.
Unfortunately, at this point we had no assurance that ERNW would not publish or disclose orally the contents of the drafts. In order to protect our company and our customers, we sent a warning letter asking them to voluntarily remove the sensitive information only, not the vulnerability information.
ERNW refused to sign the warning letter. We asked them repeatedly and when ERNW continued to refuse these requests, the German courts granted an injunction to prevent the release of that sensitive information. Injunctive relief was necessary to give FireEye the assurance that the sensitive information would not be published. The interim injunction was served on ERNW on September 2, 2015, while ERNW and FireEye continued to work on a draft of the report focused only on the vulnerabilities. We mutually agreed on a final version of the report for publication on September 8, 2015.
It is important to note that FireEye did not seek to deny ERNW from disclosing the vulnerabilities themselves. In fact, FireEye cooperated with ERNW on this matter and ultimately approved their published report on the vulnerabilities.
It is unfortunate that we could not come to an agreement with ERNW without the use of an injunction. Our commitment continues to be to our customers, and very rarely does that include using a legal outlet to ensure they remain secure.
Let’s Keep Talking
It would be easy to get the impression from a few headlines this week that we do not want to engage with security researchers. Nothing could be further from the truth. We are active across the research community and appreciate the feedback to improve our products. Please continue to reach out and we will keep the conversation going.