1、SummaryLooking beyond 0daysDriving patch adoptionHolistic lifecycle managementNormalizing transparencyVendors should disclose when their products are activelyexploitedMore transparency around patching metrics will diagnosewhether current approaches are workingSma?TransparencySuppo?ing researchersThe

2、 impo?ance of intent in legal frameworksAgainst gatekeepingEscaping the doom loop requires more strategic approachesThe industry needs to improve at pe?orming root causeanalysesFocus on the fundamentalsConclusion1SummaryAt Google,we work on security challenges across the full spectrum of cyber a?ack

3、s fromspam and other nuisances which a?ect billions of people,to sophisticated exploits developedby highly professional teams to target the worlds most high-risk users.We dont have theluxury of focusing on one or the other improving trust online requires that we buildmitigations that protect all our

4、 users.Too o?en,we see public debate around security?xate on high-end threats and zero-dayvulnerabilities,and not enough focus on the underlying conditions that enable them.ProjectZero,our vendor agnostic security research team that studies zero-day vulnerabilities inhardware and so?ware systems,is

5、focused on“making zero-day hard,”but we see a need todevelop new approaches to make all exploitation more di?cult.Doing so requires working witha broad set of stakeholders:industry,who develop the pla?orms and services that a?ackersseek to exploit;researchers,who not only?nd vulnerabilities but iden

6、tify and drive mitigationsthat can close o?entire avenues of a?ack;users,who unfo?unately still bear too high of aburden of security;and governments,who create incentive structures that shape the behaviorof all these other actors.When we look at the ecosystem,it is clear that there is impo?antwork s

7、till to do in pa?nership with these stakeholders.We see four areas for improvement:Looking beyond zero-days:While zero-days continue to pose serious risk to society,more focus is needed to drive down the impact of vulnerabilities that are alreadyknown.The industry tends to focus on patching zero-day

8、s,rather than staying currenton security updates as a whole.This practice can leave users open to harm andpotential known vulnerability exploitation.Normalizing transparency:Time and again,transparency about a?acks andvulnerabilities has proven essential to protecting users.More transparency aboutex

9、ploitation and patching is needed to protect users,understand whether currentdefenses are working and ensure that the defenses of tomorrow will at least nullify thea?acks of today.Suppo?ing researchers:While great strides have been made in recognizing(andprotecting)the contributions of researchers,t

10、his progress needs to be built upon.TheU.S.Justice Depa?ment has clari?ed their charging policies to recognize the positivecontributions of security researchers,and this approach should be spreadinternationally and at the state level.Escaping the doom loop:The endless cycle of vulnerability,followed

11、 by patch,followed by vulnerability,is exhausting defenders and users.More investment is needed2to drive fundamental advancements in so?ware security and speed thevulnerability-to-patch rate to escape this cycle.This paper covers our thoughts in all four areas.These arent just issues we are pointing

12、 out we are commi?ed to addressing them.Thats why we are announcing the following initiativestoday:Hacking Policy Council:For the?rst time,we are seeing laws(both passed andproposed)requiring the private disclosure of vulnerabilities to governments underce?ain circumstances.It is impo?ant that we ge

13、t these laws right.Thats why we arepleased to be founding members of the Hacking Policy Council,a group of like-mindedorganizations and leaders who will engage in focused advocacy to ensure new policiesand regulations suppo?best practices for vulnerability management and disclosure,and do not underm

14、ine our users security.Security Research Legal Defense Fund:Independent security researchers makeenormous contributions to security,including at Google,so protecting their ability todo their work is critical.We are proud to provide the seed funding to stand up a newlegal defense fund to protect good

15、-faith security researchers.“Good faith securityresearch”means accessing a computer solely for purposes of testing,investigation,orcorrection of a security?aw or vulnerability in a manner that avoids harm to individualsand the public.Unfo?unately,these researchers o?en still face legal threats when

16、theircontributions are unwelcome or misunderstood.Such threats can ignore theindividuals rights or misconstrue facts,creating a chilling e?ect on bene?cial securityresearch and vulnerability disclosure,especially for those without resources.TheSecurity Research Legal Defense Fund aims to help fund l

17、egal representation forpersons that face legal problems due to good faith security research and vulnerabilitydisclosure in cases that would advance cybersecurity for the public interest.Exploitation transparency:From time to time,vendors will release a?x withoutdisclosing that the vulnerability was

18、being actively exploited.Greater transparencyaround exploitation helps the industry be?er understand a?acker behavior,ultimatelyleading to be?er protections.We believe this transparency should become pa?of theindustrys standard vulnerability disclosure policies.We have always prioritizedtransparency

19、 when our products are exploited,but sta?ing today we will make this anexplicit pa?of our policy,commi?ing to publicly disclose when we have evidence thatvulnerabilities in any of our products have been exploited.3Looking beyond zero-daysThe life of a vulnerability doesnt end when the vendor release

20、s a?x.Over the years,industryand policymakers have grown too focused on zero-day vulnerabilities as a top source ofinsecurity in the ecosystem.We need to shi?to a more holistic approach to managingvulnerabilities focused on patching and so?ware lifecycle management.Driving patch adoptionZero-day vul

21、nerabilities continue to pose serious risk to the digital ecosystem,but the averageuser faces far more risk from known vulnerabilities that have not been patched.Whetheryoure an end user,an OEM,or a so?ware provider,e?ective and timely patch incorporation isessential to hardening your security postu

22、re.Ultimately,the pla?orm needs to release a?x toa?ected vulnerable pa?ies to limit a?ackers a?empting exploitation.Greater focus should beplaced on the way pla?orms make patches available to users,including frequency of patching;options and incentives for automated patching;whether standalone secur

23、ity?xes are o?ered(versus feature updates);or whether app updates can be decoupled from full system updatesfor mobile devices.Project Zero,a vendor agnostic security research team that sits withinGoogle and studies zero-day vulnerabilities in hardware and so?ware systems,has pioneeredpatch and discl

24、osure timelines for this very reason-for the immediate safety of users.Ease of patch adoption in enterprise is a pa?icularly understudied area of friction.Followingmany a?ack campaigns exploiting known,unpatched vulnerabilities,organizations are o?enchided for not applying patches in a timely manner

25、.While this may be true,we tend to overlooksome of the di?culties in patching.The industry should invest in making testing and applyingpatches easier for customers.Greater analysis of patch trends can help here.For example,thisweek we published a deep dive on Google Kubernetes Engine patching trends

26、 for GoogleCloud customers,generating new insights and recommendations on addressing frictionpoints.Holistic lifecycle managementA vulnerability disclosure policy is a sta?ing point for many companies,but we believe moreholistic policies to address product life cycles must become the norm.Products s

27、hould comewith policies about expected lifetime(including expiration dates)and suppo?and noti?cationmodels for downstream customers.For instance,the Android team ensures that downstreampa?ners(such as OEMs)have clear guidance on the security suppo?timelines for the coreAndroid OS(how long they can e

28、xpect to get security patches provided by Google)as well asthe Linux kernel(utilizing suppo?timelines for long term suppo?versions).We carefully selectthese to ensure that pa?ners have a guaranteed period of suppo?(minimum of 3.5 years)4from the launch of a speci?c version of the Android OS.Pixel al

29、so makes their speci?c updatecadence available for users.Normalizing transparencyTransparency has proven essential to protecting users from online threats.Greater scrutiny bythousands of eyes produces digital products and services that are more secure,reliable,andtrustwo?hy.Vendor transparency about

30、 vulnerabilities allows the development ofecosystem-wide mitigations and a shared view of a?ack trends.Vendors should disclose when their products are actively exploitedIf a vendor discovers a vulnerability being actively exploited(i.e.used by a?ackers to causeharm to users or organizations),it is n

31、ot enough to just?x the vulnerability.Vendors shouldmake users,supply chain pa?ners,and the community aware of the exploitation and notifyvictims in a timely manner through public disclosure and direct outreach where possible.Making users aware of exploitation is especially impo?ant and time-sensiti

32、ve when there aremitigations users can explicitly take to protect themselves against the threat,and thedisclosure itself does not give a?ackers a signi?cant advantage over defenders with respect tofu?her leveraging the vulnerability.Additional details of vulnerabilities and exploits should beshared

33、to improve researcher knowledge and defenses,weighing the balance of transparencyand defensive bene?t against the risk to users who are yet to patch.This is something weveprioritized at Google for years,and weve made it an explicit pa?of our vulnerability disclosurepolicy.More transparency around pa

34、tching metrics will diagnose whether currentapproaches are workingMore transparency from pla?orms around patch adoption metrics for users will help industryand policymakers understand the scope of the challenge and whether the industry is trulyimproving in this area.In enterprise se?ings,this should

35、 also include data around the amountof testing required for a given patch and rates of patch failures.Ideally,transparency wouldalso extend to governments as they balance o?ense vs.defense considerations.The U.S.Vulnerability Equities Process and the Australian Governments Responsible Release Princi

36、plesrepresent a positive step forward,but more data on outcomes could help fu?her its mission.Other countries should follow the U.S.s lead here but everyone should also improve upon it,such as by sharing the number of vulnerabilities disclosed versus those withheld fromdisclosure,or sharing more inf

37、ormation about exploitation trends in general.5Sma?TransparencyWhile transparency is in our DNA,our?rst principle is protecting users.We share informationto raise awareness of threats and vulnerabilities,but sometimes sharing can put users at riskand add noise to the system if not done though?ully.W

38、e have seen recent policy proposalsthat would force companies to over-repo?events(e.g.,repo?activities that provide no publicinterest bene?t,such as scanning activity against public websites),or require the privatedisclosure of vulnerabilities to governments before customers are noti?ed and prior to

39、 thedevelopment of mitigations.In the past,we have seen well-intentioned policies have theopposite e?ect new policies in this area must be evaluated against their impact on security.Suppo?ing researchersIndustry and government have come a long way in recognizing the impo?ant contributions ofsecurity

40、 researchers to protecting users,systems,and organizations,but there are still outliers.We continue to see problematic a?empts to criminalize or silence helpful research activities,ormodify global best practice for vulnerability disclosure,for instance by compelling researchersto disclose vulnerabil

41、ities to the government before the vendor of the a?ected product.The impo?ance of intent in legal frameworksIntent is impo?ant in these activities:testing a service to?nd vulnerabilities to contribute to avulnerability disclosure program is di?erent from testing to?nd vulnerabilities to exploit user

42、s.Legal frameworks that do not acknowledge the di?erence between research for defensivepurposes versus malicious activities risk signi?cantly chilling the former,which has become anessential component of the ecosystem.The United States has taken the lead in clarifying thatsecurity research should be

43、 suppo?ed,not prosecuted,and this approach should bereplicated elsewhere.Against gatekeepingWe believe anyone,regardless of background,should be able to contribute to vulnerabilityresearch.Ultimately,vulnerability repo?s are information;organizations should not limit theirability to receive useful i

44、nformation from the community.While repo?s should be treatedcautiously by the recipient organization,and bug bounty payments must follow all relevantlegal requirements(e.g.relating to sanctioned entities),we oppose any e?o?s to“gatekeep”who can pa?icipate in vulnerability disclosure programs(for ins

45、tance,by disallowing peoplewith criminal records).6Escaping the doom loop requires more strategicapproachesSecurity can seem hopeless and endless at times:Vulnerability followed by patch;threatfollowed by mitigation.Each new a?ack trend spurs new solutions in the cybersecurity productmarket but noth

46、ing seems to get be?er.We believe the best path out of this cycle ofinsecurity is not by bolting on new tools,but by focusing on the fundamentals of secureso?ware development,good patch hygiene,and designing for security and ease of patchingfrom the sta?.The industry needs to improve at pe?orming ro

47、ot cause analysesAt Google,we strive to eliminate entire classes of threats and vulnerabilities.This sta?s bype?orming root causes analyses of existing vulnerabilities to address the underlyingarchitectural issues that allow them to proliferate.Too o?en,we see vendors apply incomplete?xes for seriou

48、s vulnerabilities,addressing the symptoms of the issue without also treating thecause.This frequently leads to patch bypasses and waves of exploitation.For example,17 ofthe 40(42.5%)zero-days exploited in the wild which Project Zero analyzed in 2022 werevariants of previously known bugs.This issue c

49、omes down to either a)a failure to understandthe root cause of a given?aw,or b)a failure to prioritize truly?xing it.Focusing on root causeanalysis will enable industry,government,and end users to sta?rising above the exhaustinghamster wheel of vulnerability responses.Focus on the fundamentalsPolicy

50、maker and industry a?ention can at times be reactive,with emphasis on addressingthreats and vulnerabilities as they arise,rather than ensuring products are secure to sta?with.Fundamental so?ware security practices do not get the a?ention their impo?ance merits.E?o?s such as those by the U.K.National

51、 Cyber Security Centre,the U.S.National Institutes ofStandards and Technology(NIST)and the Cybersecurity and Infrastructure Security Agency(CISA)to de?ne and share examples of security best practices across the so?waredevelopment life cycle are a helpful step in this direction,but these e?o?s must b

52、e built upon.For example,a developer can follow all of NISTs Secure So?ware Development guidelineswithout ever considering whether to write their program using a modern,memory-safeprogramming language.As another example,So?ware Bill of Materials(SBoM)are a good sta?to understanding systemic dependen

53、cies and identifying insecure components but SBoMs inand of themselves do not improve security.SBoMs should be a natural output of more secureand audited so?ware build systems,and frameworks must be put in place to analyze SBoMs atscale.7Public/private pa?nerships are needed to develop?exible approa

54、ches to guide secureso?ware development that work for organizations of all sizes,and internationally.WithinGoogle,we continually update guidelines for developers to address evolving a?ackertechniques,such as the impo?ance of applying secure-by-design principles during all phasesof the so?ware develo

55、pment lifecycle,and our evolution towards Rust for new connecteddevices.ConclusionThough this paper references many challenges in the ecosystem,there is cause for optimism.E?o?s like those from CISA re?ect a growing desire to mitigate risk from both known andpreviously unknown vulnerabilities,and pr

56、ioritize so?ware security principles.Major pla?ormproviders have signi?cantly accelerated the rate at which they develop and deploy patches.We are con?dent that the commitments we are making today,combined with a focus on theareas laid out in this paper,can drive signi?cant improvements in vulnerability management,making the ecosystem safer for all users and organizations.8