Euro Security Watch with Mathew J. Schwartz

Google's Psychological Patch Warfare

'Project Zero' Rewrites Vulnerability Disclosure Norms
Google's Psychological Patch Warfare

Psychologically speaking, nothing beats the power of a well-timed deadline.

See Also: Live Webinar | Compliance and Cyber Resilience: Empowering Teams to Meet Security Standards

Take Google's "Project Zero" bug hunting team, which has been finding new vulnerabilities in software, alerting vendors and giving them 90 days to release a related patch. After that deadline, the software vulnerability is automatically made public.

Love it or hate it, Google has rewritten the vulnerability eradication norms, and undercut bug eradication timelines that could stretch to six months, a year or even more. Now, when Microsoft pushes a patch to market that took 12 months to prepare - for example, its February 2015 fix for a serious Active Directory flaw - the question is: What took you so long?

There's clever psychological work at play here. Guardian columnist Oliver Burkeman, author of The Antidote: Happiness for People Who Can't Stand Positive Thinking, tells me that what Google is doing with Project Zero appears to employ two different psychological concepts: anchoring, in which we use a first piece of information on which to base further decisions; and framing, which posits that how something gets defined influences how we will then think about it. Both of these concepts, he says, center on "the ways in which we make judgments and decisions (about what might be possible in a given timeframe, for example) based on the ways the issues are presented to us."

Burkeman also cites the work of Nobel laureate Daniel Kahneman and Amos Tversky. In a 1979 paper, they identified what's known as the planning fallacy, which posits that we're horrible at predicting how long a given project will take, and inevitably underestimate related costs and risks. Blame it on our innate, optimistic biases. And to counter such tendencies, Burkeman describes how some time management experts recommend people plan projects that last for 12 weeks.

Furthermore, bugs do not represent some existential "tree falls in a forest" quandary - do they exist before being publicly disclosed? Fixing serious flaws fast is essential, because any bug found by a white hat hacker might already have been discovered by crimeware toolkit builders, to say nothing of intelligence agencies, foreign and domestic. In other words, any unpatched zero-day vulnerability may already be getting actively exploited.

Cold, Hard Deadlines

Enter Project Zero. By articulating the terms of the bug-patching deadline - and abiding by those deadlines itself - Google has now anchored and framed related discussions. And in the past, Microsoft managers might have been able to say, "We have a lot of bugs to fix this month, let's punt a few of these patches out another 30 days." Now, however, the clock is ticking.

"If you're a proponent, you'll argue that Google is trying to squeeze us all, including itself, to get more real-worldly at fixing things," says Paul Ducklin, a security researcher at anti-virus vendor Sophos, in a blog post. "Nothing like a bit of no-nonsense, non-negotiable pressure to focus your mind, and to weed out those companies that tend to sweep vulnerabilities under the carpet to avoid the effort of fixing them."

Microsoft Cries Foul

But Google has taken some flak for being a "zero-day dropping machine." Microsoft in particular cried foul. In the case of one flaw, for example, it had included a fix in its regularly scheduled and well-documented January 2015 monthly patch release. But that fix happened to be scheduled for shortly after the automatic 90-day Project Zero deadline expired.

That's an interesting reversal. For years, Microsoft called the bug fix shots, and it reportedly wasn't afraid to use its muscle if researchers didn't abide by its "don't say anything publicly until we get around to patching the bug" approach.

Google's move has also focused attention on the company's approach to running Android as an open source project, with the result that equipment manufacturers and carriers - not Google - are responsible for patching the vast majority of Android smartphones and tablets. And security experts say many of them never do get patched.

Google Throws Vendors a Bone

In response to related criticism, however, Google in February updated its bug-disclosure deadlines. Now, it's added two weeks of "wiggle room" if vendors request it. If deadlines fall on a weekend or holiday, Google will automatically extend the deadline. And Google notes that it reserves the right to delay - or advance - deadlines based on "extreme circumstances."

Again, however, this shows anchoring and framing at work. Google didn't ask the world: "How long should vendors get to patch bugs?" Instead, it gave them 90 days, and later threw in a couple of weeks. The end result is the same: It's rewritten the rules of the patch game. Now, everyone needs to patch bugs more quickly, or else they're going to look like they're IT dinosaurs, leaving customers' information security at risk.

Call it anchoring, framing or a calculated attempt to eradicate software vendors' bug repair planning fallacies. And regardless of whether you think it's an altruistic move, or a bareknuckle one, or maybe both, who can argue with the benefits of our having to put up with unpatched bugs - and related cybercrime risks - for less time?



About the Author

Mathew J. Schwartz

Mathew J. Schwartz

Executive Editor, DataBreachToday & Europe, ISMG

Schwartz is an award-winning journalist with two decades of experience in magazines, newspapers and electronic media. He has covered the information security and privacy sector throughout his career. Before joining Information Security Media Group in 2014, where he now serves as the executive editor, DataBreachToday and for European news coverage, Schwartz was the information security beat reporter for InformationWeek and a frequent contributor to DarkReading, among other publications. He lives in Scotland.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.com, you agree to our use of cookies.