Monday, January 12, 2015

A Call for Better Vulnerability Response

Microsoft forced a self-serving vulnerability disclosure policy on the industry 10 years ago, but cries foul when Google does the same today.

Ten years ago, Microsoft dominated the cybersecurity industry. It employed, directly or through consultancies, the largest chunk of security experts. The ability to grant or withhold business meant influencing those consulting companies -- Microsoft didn't even have to explicitly ask for consulting companies to fire Microsoft critics for that to happen. Every product company depended upon Microsoft's goodwill in order to develop security products for Windows, engineering and marketing help that could be withheld on a whim.

This meant, among other things, that Microsoft dictated the "industry standard" of how security problems ("vulnerabilities") were reported. Cybersecurity researchers who found such bugs were expected to tell the vendor in secret, and give the vendor as much time as they needed in order to fix the bug. Microsoft sometimes sat on bugs for years before fixing them, relying upon their ability to blacklist researchers to keep them quiet. Security researchers who didn't toe the line found bad things happening to them.

I experienced this personally. We found a bug in a product called TippingPoint that allowed us to decrypt their "signatures", which we planned to release at the BlackHat hacker convention, after giving the vendor months to fix the bug. According to rumors, Microsoft had a secret program with TippingPoint with special signatures designed to track down cybercriminals. Microsoft was afraid that if we disclosed how to decrypt those signatures, that their program would be found out.

Microsoft contacted our former employer, ISS, which sent us legal threats. Microsoft sent FBI agents to threaten us in the name of national security. A Microsoft consultant told the BlackHat organizer, Jeff Moss, that our research was made up, that it didn't work, so I had to sit down with Jeff at the start of the conference to prove it worked before I was allowed to speak.

My point is that a decade ago in the cybersecurity industry, Microsoft dictated terms.

Today, the proverbial shoe is on the other foot. Microsoft's products are now legacy, so Windows security is becoming as relevant as IBM mainframe security. Today's cybersecurity researchers care about Apple, Google Chrome, Android, and the cloud. Microsoft is powerless to threaten the industry. It's now Google who sets the industry's standard for reporting vulnerabilities. Their policy is that after 90 days, vulnerabilities will be reported regardless if the vendor has fixed the bug. This applies even to Google itself when researchers find bugs in products like Chrome.

This is a nasty trick, of course. Google uses modern "agile" processes to develop software. That means that after making a change, the new software is tested automatically and shipped to customers within 24 hours. Microsoft is still mired in antiquated 1980s development processes, so that it takes three months and expensive manual testing before a change is ready for release. Google's standard doesn't affect everyone equally -- it hits old vendors like Microsoft the hardest.

We saw the effect this last week, where after notifying Microsoft of a bug 90 days ago, Google dumped the 0day (the information hackers need to exploit the bug) on the Internet before Microsoft could release a fix.

I enjoyed reading Microsoft's official response to this event, full of high-minded rhetoric why Google is bad, and why Microsoft should be given more time to fix bugs. It's just whining -- Microsoft's alternative disclosure policy is even more self-serving than Google's. They are upset over their inability to adapt and fix bugs in a timely fashion. They resent how Google exploits its unfair advantage. Since Microsoft can't change their development, they try to change public opinion to force Google to change.

But Google is right. Since we can't make perfect software, we must make fast and frequent fixes the standard. Nobody should be in the business of providing "secure" software that can't turn around bugs quickly. Rather than 90 days being too short, it's really too long. Microsoft either needs to move forward with the times and adopt "agile" methodologies, or just accept its role of milking legacy for the next few decades as IBM does with mainframes.

4 comments:

  1. "policy is fairly simple, we provide vendors with information about the flaw, and after 15 days communicate the vulnerability information to CERT. CERT has a fixed 45-day disclosure that results in the report-to-advisory period taking approximately 60 days. As a courtesy, I usually wait 30 days from the release of the advisory to adding the exploit to the Metasploit Framework."

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete
  3. I liked most of your article. I would even suggest that the 90 day delay is overly generous. I would rather have the information of all the unpatched vulnerabilities that exist in my systems, then take make an informed decision to continue using those systems or not. For Google to extend its time beyond 90 days would be irresponsible to the general public, IMHO.

    However, your depiction of "agile" is a little bit overstated. Microsoft *does* do agile, and is doing more. However, a 24 hour continuous deployment cycle can be unrealistic, especially with acceptance and performance tests that may take more than 24 hours to complete!

    In the agile teams I've worked on, we release a fully tested product version at the end of every sprint (2-4 weeks). That 24 hour cycle of CD works great for websites, but testing operating systems is vastly more complex and time consuming; a 24 hour cycle just isn't realistic, IMHO.

    ReplyDelete
  4. "Google uses modern "agile" processes to develop software. That means that after making a change, the new software is tested automatically and shipped to customers within 24 hours. Microsoft is still mired in antiquated 1980s development processes, so that it takes three months and expensive manual testing before a change is ready for release. Google's standard doesn't affect everyone equally -- it hits old vendors like Microsoft the hardest."

    Man, what BS! Where do you get this stuff?

    ReplyDelete

Note: Only a member of this blog may post a comment.