Eschelbeck cited as an example of Google security team’s speed and agility the discovery of a serious buffer overflow condition in the widely used Linux glibc library. Multiple teams were scrambled and worked in parallel streams. Google’s signal team monitored the infrastructure for an attack. Researchers proved the flaw could be exploited while other researchers sought yet undetected variants. In parallel Google engineers worked with engineers at Redhat to create a patch and test it. Finally the last step was to notify the Linux community of the risk of the glibc exploit and the availability of a patch.
Eschelbeck said that his greatest responsibility is to continue to conduct research and innovate to build better security and privacy into products. It is the same innovation model used in self driving cars and the novel project loon internet access network suspended from balloons applied to privacy and security.
An example of the innovation commitment is Project Zero. A zero-day exploit is one discovered by bad actors, criminals and nation states that has never been used before to breach sovereign or enterprise security. Such an exploit is undetectable because it doesn’t have a known signature for which signal teams can be on the alert. Google formed a full-time team dedicated to detecting yet undetected vulnerabilities, not only in Google software but any software used by its users. He also said that funding the security research community and participating in related open source communities was important.
Eschelbeck’s team also works with all the product teams to advise them on building secure software and to scrutinize code prior to release. They can veto a release if they perceive the potential for an exploit. Living in the fishbowl, there is no difference in the impact to users’ trust of a small or large breach.
One of his constant worries is how to validate what is delivered from outside by Google’s global hardware supply chain. Like most platform companies such as Facebook and Amazon, Google assembles its computing infrastructure from commodity hardware components. As more companies grow into large platform companies and adopt similar commodity hardware infrastructures, the attack plane becomes larger and riskier and validation becomes a bigger problem.
It could be speculated that the security team might produce a security as a service product or perhaps Eschelbeck was empathizing about the plight of small and midsized business as he pondered out loud how they can survive without Google’s scale and a CSO organization.
CSOs would be wise to follow Eschelbeck and Google because the company’s infrastructure is years ahead of most enterprises and has the engineering resources and scale to illuminate pending threats and evolving defenses.
Sign up for CIO Asia eNewsletters.