《云安全联盟（CSA）：2024年漏洞数据关键问题研究报告（英文版）（27页）.pdf》由会员分享，可在线阅读，更多相关《云安全联盟（CSA）：2024年漏洞数据关键问题研究报告（英文版）（27页）.pdf（27页珍藏版）》请在三个皮匠报告上搜索。

1、Top Concerns withVulnerability DataThe permanent and official location for the Vulnerability Data Working Group ishttps:/cloudsecurityalliance.org/research/working-groups/vulnerability-data 2024 Cloud Security Alliance All Rights Reserved.You may download,store,display on yourcomputer,view,print,and

2、 link to the Cloud Security Alliance at https:/cloudsecurityalliance.org subject tothe following:(a)the draft may be used solely for your personal,informational,noncommercial use;(b)the draft may not be modified or altered in any way;(c)the draft may not be redistributed;and(d)thetrademark,copyright

3、 or other notices may not be removed.You may quote portions of the draft aspermitted by the Fair Use provisions of the United States Copyright Act,provided that you attribute theportions to the Cloud Security Alliance.Copyright 2024,Cloud Security Alliance.All rights reserved.2AcknowledgmentsLead Au

4、thorsAbhineeth PasamAhaan SinhaReviewersAlan Curran MScAnita WhitbyCharan AkiriClifton FernandesDebrup GhoshEdward NewmanGene SchankJames Morgan-JonesMallika GunturuMark SzalkiewiczMeghana ParwateMichael RozaPrateek MittalRahul KalvaRajashekar YasaniRhitvik SinhaShruti DhumakSudheer VallandasVani Mu

5、rthyCSA Global StaffJosh BukerStephen LumpeKurt Seifried Copyright 2024,Cloud Security Alliance.All rights reserved.3Table of ContentsAcknowledgments.3Table of Contents.4Introduction.5Role of Vulnerability Data.5Current State of Vulnerability Data.6Identifying the Current Challenges.6CVE.6Data Quali

6、ty and Fidelity.6Perverse Incentives to not Create CVEs.7Finding Relevant Vulnerability Data.7Notifying Project Maintainers.8Lack of Interoperability.8Resolving Disputes.9Complexity of Reporting Vulnerabilities.9Increasing Number of CVEs Every Year.10CVSS.11Disadvantages of CVSS.12Inability to Prior

7、itize Risk.12Static Scoring System.13User Stories.13cURL.13Custom Solutions.14Alternatives to CVSS.15EPSS.15SSVC.16VPR.16Threat Modeling Frameworks.18What Is Threat Modeling?.18STRIDE.18LINDDUN.19PASTA.19VAST.20TRIKE.20DREAD.21Future Directions and Emerging Trends.23Big Data Problems and Scale Issue

8、s.23The Role of Artificial Intelligence and Machine Learning.24Conclusion.25References.26 Copyright 2024,Cloud Security Alliance.All rights reserved.4IntroductionRole of Vulnerability DataThe field of cybersecurity is vast and diverse.There are hundreds of sub-fields and specializations withincybers

9、ecurity that aim to solve a variety of problems.However,one field serves as the backbone for theentire industry:Vulnerability Management.This pertains to storing and managing the data associatedwith numerous exploits and vulnerabilities discovered across digital systems,as well as detecting andremed

10、iating these vulnerabilities.Without effective vulnerability management,we cannot keep up withthe latest exploit discoveries and the efforts to fix them.In the 1990s,the cybersecurity industry faced this exact problem as consumers adopted moretechnology,and exploiting these systems became more commo

11、n.In response to the rising need for a wayto track vulnerabilities,the MITRE Corporation created the Common Vulnerabilities and Exposures(CVE)program,which assigned an identifier to each discovered vulnerability,essentially standardizing thevulnerability documentation process.As vulnerabilities beca

12、me more common alongside the rise ofconsumer technology,the CVE program also grew until it hit a roadblock:There were simply too manyvulnerabilities.There needed to be a way to prioritize them,as some are more dangerous than others,andnot every vulnerability needs direct attention.To do this,the Com

13、mon Vulnerability Scoring System(CVSS)was created,where each CVE was given a score from 0 to 10,with 10 being the most severe.Thisscore is determined based on several factors,such as Access Vectors and Access Complexity,amongothers.Today,the industry still uses these core systems(CVE,CVSS,etc.)even

14、though the systems themselveshavent seen nearly as much change as the overall field of cybersecurity.This has led to growing pains asthe increasing complexity and scale of modern cybersecurity challenges have outpaced the capabilities ofthese core systems.Many organizations have large,diverse,and in

15、creasingly complex technology stacks.This makes itchallenging to prioritize the remediation of multiple systems with high or critical CVE scores on a rollingbasis.This is especially difficult when considering their impact within each organizations unique context,and even more challenging when consid

16、ering a systems differing criticality within that organization.Thecurrent CVE scoring system,while useful for assessing the severity of vulnerabilities in isolation,oftenlacks the granularity needed for organizations to make informed prioritization decisions.It does notaccount for factors,such as th

17、e criticality of the affected systems to the business,compensating controlsalready in place,or the likelihood of exploitation within the organizations specific environment.This leadsto a one-size-fits-all approach,where vulnerabilities are assigned a high severity based on genericcriteria,rather tha

18、n tailored to the organizations operational risks,making effective prioritization moredifficult.This can potentially lead organizations to prioritize badly,often focusing efforts on vulnerabilitieswith the highest CVSS,rather than the vulnerability that poses the most risk to their specific organiza

19、tion.Copyright 2024,Cloud Security Alliance.All rights reserved.5Current State of Vulnerability DataToday,professionals across the industry have called for improvements in the current system ofvulnerability data,especially due to the recent instability in the National Vulnerability Database(NVD).Sin

20、ce 2017,the NVD has seen over 133,000 CVEs reported,while the number of CVE NumberingAuthorities(CNAs)hasnt matched this growth,creating a large bottleneck.While some of this growth hascome from more technology being used,a lot of it also comes from exploiting glaring weaknesses withinour current vu

21、lnerability systems(CVE,CVSS,etc.).In fact,due to this high number of CVE reports,theNVD temporarily stopped publishing CVEs in 2024,as they lacked the required resources.Additionally,many aspects of CVEs simply cannot keep up with the increasing complexity of vulnerabilities beingdiscovered and the

22、 methods being used to prioritize them.The glaring problems with our current vulnerability data systems need to be addressed,and the first stepin that is bringing awareness to these concerns.That is exactly what this paper aims to achieve.We will begoing over the main problems and concerns of the cu

23、rrent landscape of vulnerability data and potentialsolutions to fix them.Identifying the Current ChallengesCVEWhile the Common Vulnerabilities and Exposures(CVE)system has undergone revisions,it has largely notbeen able to keep up with the rapidly growing cybersecurity scene.While the limited granul

24、arity and slowassignment process mightve worked with fewer vulnerabilities in the past,many aspects of CVEs havebecome pain points in the vulnerability data space and must be addressed.Well be going over variouschallenges that CVE faces in the current landscape.Data Quality and FidelityIn a perfect

25、world,each CVE would contain all of its metadata and detailed descriptions of thevulnerability.However,this is not the case for most of the CVEs coming out right now.Many CVEs lackimportant metadata information,such as specific impact details,impacted libraries,and other dataessential for addressing

26、 these vulnerabilities.Impact details,in particular,are especially important.If professionals dont know exactly how avulnerability can affect their organization or what the severity of its exploits are,it becomes much harderto discern prioritization levels.Additionally,many CVEs dont have data on wh

27、at libraries or softwareversions are affected,which further increases the workload for security teams and developers around theworld.Additionally,impact details dont paint the same story for every organization.The impact of avulnerability may be high,but if the affected system within the organizatio

28、n is segregated fromproduction systems,then the actual impact for the organization could be low.Copyright 2024,Cloud Security Alliance.All rights reserved.6This data disparity also affects antivirus and Security Information and Event Management(SIEM)software,which rely on platforms data to notify us

29、ers of potential security vulnerabilities in their systems.While CVSS will be discussed later in this paper,it is important to recognize the inconsistencies in currentvulnerability severity score assignments.This results in cybersecurity team confusion with prioritization,adding to the current CVE q

30、uality and fidelity issues.Moreover,many CVEs have outdated information,which can be especially detrimental.This is evidencedwith the Heartbleed bug,where the CVEs initial medium-severity score wasnt updated to reflect itsdanger in the real world,and its impact on internet security.Cases like these,

31、where information isoutdated or simply not updated,leave machines vulnerable,as CVEs are being prioritized incorrectly dueto poor data.Perverse Incentives to not Create CVEsWhile many companies submit most vulnerabilities they find as CVEs,there are incentives for companiesto maliciously hide some v

32、ulnerabilities.Organizations may not have the resources to fix the vulnerability,especially if backporting is required.Addressing widespread vulnerabilities can be resource-intensive forcompanies,as patches will have to be created for various versions and may even have to be backportedfor older vers

33、ions.As a result,addressing vulnerabilities is often at the bottom of a companys priority listsince resources could be directed toward initiatives that directly grow and benefit the company.If the vulnerability isnt published,it can be quietly fixed without the publics knowledge.This also meansthe c

34、ompanys image would be protected,which avoids stock price fluctuations or dismay amonginvestors.Finding Relevant Vulnerability DataWith new CVEs being published daily,it becomes increasingly difficult to efficiently search through thisdata,and therefore tools need to be created to address this.The f

35、irst problem is the overall scope of datain the field.With thousands of vulnerabilities reported each year,organizations find it harder to prioritizethem and determine whether they pose a threat.Numerous vulnerability management software tools have come to the market to address this,but theseoften s

36、truggle with slow scanning speeds and false positives,which can be detrimental to organizations.This exposes a significant problem with vulnerability data that will only continue to worsen as more CVEsare created.Additionally,project owners also struggle with not being able to find relevant vulnerab

37、ility data.Often,theowner of a project is left in the dark about CVEs being published that pertain to their project,leading toincorrect information within the CVE when it is initially published.This means that until the CVE is updated,incorrect information is shared with the entire world.This is ahu

38、ge problem as it adds unnecessary complexity and difficulty for vulnerability management teams,whothen have to verify the information in CVEs.Its also a headache for project maintainers,who could face Copyright 2024,Cloud Security Alliance.All rights reserved.7bad press and additional work if a CVE

39、contains wrong information about a vulnerability,making it seemmore threatening than it is.All of these are important points to address to make vulnerability data more complete,accurate,andhelpful.Notifying Project MaintainersContacting a project maintainer who needs to be notified of a potential vu

40、lnerability,is often acomplicated process.There are thousands of projects for which CVEs are being published,but someproject maintainers arent contacted in a timely manner,therefore vulnerabilities take a while to bepatched.Likewise,this is also very problematic for projects that are no longer being

41、 maintained actively.Its essential to create a system where project maintainers can be reliably contacted so that CVEs relatedto their projects can be addressed promptly.Usually,projects will have either a security.md or security.txtfile which details processes to submit vulnerabilities.However,this

42、 isnt something a lot of repositoriescurrently have,which means many maintainers are largely unreachable.Lack of InteroperabilityCurrently,there is a vast number of vulnerability databases and sources that largely dont work together,increasing the complexity of vulnerability management for organizat

43、ions.The first part of this problem isthe wide array of data formats that different vulnerability databases use.Formats such as CVE,GitHubAdvisory Database(GHSA),and Open Source Vulnerabilities(OSV)each use different structures thatcant be easily transformed or standardized among each other.This cre

44、ates disparities between different vulnerability databases in terms of the information they hold,leading to different views of the same vulnerability across databases.The databases themselves are alsovery fragmented in the vulnerability space.Some examples of these databases are MITREs CVE database,

45、the NVD,and CISAs Vulnrichmentprogram.Each of these databases operates independently,performing its analysis of the data.Thismakes it harder for vulnerability management teams to consolidate information about a vulnerability intoone source.Another tool being fragmented is application programming int

46、erfaces(APIs).Because these databasesdont work together and have disparities in data,multiple APIs are required to keep track of vulnerabilitiesacross all the databases.This puts a lot of work on vulnerability management teams,as they have tointegrate and maintain numerous APIs rather than just one,

47、which would be possible if these databaseswere interoperable.This also incurs extra operational costs related to building and maintaining these integrations.Despite theprevalence of this problem,very little progress has been made by the major vulnerability databases toaddress it.This is largely due

48、to the existing culture of resistance against standardization within thesecompanies.Copyright 2024,Cloud Security Alliance.All rights reserved.8Even though open-source standards exist,most vulnerability data companies reject them in favor ofproprietary systems.There needs to be a major culture shift

49、 in the vulnerability data field towardcollaboration and standardization to create a solution for this problem.Resolving DisputesWhen a CVE is published with incorrect information,the process to dispute it lacks transparency,meaningfalse information could potentially spread until the dispute is reso

50、lved.This often happens when avulnerability is published with inaccurate severity data,prompting the project maintainer to dispute it.However,while a CVE is under dispute,it remains in the database,meaning many teams who use APIs totrack vulnerabilities may never know that the information in the CVE

51、 could be false.Additionally,the dispute process is slow and tedious.First,there is no unified dispute form that notifies alldatabases.For example,if a vulnerability contains incorrect information in both its CVE and OSV entries,two separate dispute processes will need to be initiated.MITRE does hav

52、e a form to dispute CVEs,butthe process can take months of back and forth and,in the end,MITRE may disagree with the dispute.Moreover,there should be transparency in disputes,where the public knows exactly what part of a CVE isbeing disputed and why.Due to MITREs control,there is no guarantee that a

53、ll aspects of a CVE will beshown to the public.This reveals another glaring weak point:the lack of multiple perspectives.The originaldesign of the CVE system intended for there to be only one correct stance on a vulnerability.However,with the increasing complexity of vulnerabilities,there is often d

54、iscourse within the vulnerability datacommunity.CVEs cannot reflect this discourse due to their limited scope and descriptions,meaning only oneviewpoint is ever shared.Most of the time,the viewpoint being shared will be that of the CVE NumberingAuthorities(CNAs),meaning they control the narrative of

55、 their own products vulnerabilities.This isproblematic,as it keeps the community out of the process of vulnerability data and detracts from apotentially more complete picture of vulnerabilities.Complexity of Reporting VulnerabilitiesMost of the time,the CVE submission process is filled with confusio

56、n and complexity,hence discouragingpotential submitters.There are three major stakeholders in this process:the originator,the CVE partner,and the CNA.However,from identification to formal recognition as a CVE,the process is usually painfullylong and ambiguous in many cases.Heres an overview of the C

57、VE submission process:Initial Reporter:The person finding the vulnerability and trying to disclose it to be categorizedas a CVE.Choosing a CVE Partner:Next,the reporter has to identify which CVE partner they would beusing.That might be very puzzling since there are hundreds of them,each with a CNA s

58、cope.The Copyright 2024,Cloud Security Alliance.All rights reserved.9scoping for some,such as CISA,is very broad,while for others like Microsoft,it covers only theirproducts.Means of Submission:The means vary depending on the partner.Microsoft and CISA have aform to report vulnerabilities.Most of th

59、em provide an email address for submissions but do notindicate what information they require to process it.In many cases,this lack of instruction,coupled with slow responses,leads to an extended email chain between the reporter and the CVEpartner.CVE ID Reservation and Publication:After the submissi

60、on is made,the CNA obtains a CVE IDand then publishes it.This process can take several weeks or even months,where communicationwith the initial reporter often breaks down,leaving them uncertain as to what has happened totheir CVE.Potential Rejection:If the CNA decides that the CVE is out of scope or

61、 doesnt meet its criteria,the reporter will have to either submit directly to MITRE or drop the process altogether.Submissions directly to MITRE also would be a lengthy process,since the publication timelinevaries drastically with changes in the CVSS score.Lack of Feedback:There is no feedback or ra

62、ting system for CVEs that could help reportersunderstand what makes a good CVE submission,resulting in lower-quality CVEs.Overall,the system of vulnerability reporting is inconsistent and complicated.The complexity actuallydeters submissions and negatively impacts the quality and effectiveness of th

63、e CVE process.Handling False or Low-Quality ReportsWith the recent surge in CVE submissions,there has been a growing problem of false or low-quality databeing submitted with these CVEs.First,its important to identify that getting a CVE published is a hugeaccomplishment for an individual,and often a

64、desirable accomplishment.This means that people arewilling to submit low-quality or even false CVEs just to add it to their resume.Another reason forlow-quality CVEs is because of CVE misuse.One example of this is engineers using CVEs to backportpatches.Many companies dont prioritize patches for old

65、er,stable kernel versions as backporting requiresa lot of work.To circumvent this,engineers will submit these patches as CVEs,which,once published,willjump to the top of the organizations priority list,as its a security issue.Increasing Number of CVEs Every YearAnother significant challenge facing t

66、he CVE ecosystem is the sheer volume of vulnerabilities beingdiscovered and reported each year.According to the official CVE database,the number of reported CVEshas been rising consistently:1999:321 CVEs2010:4,639 CVEs2020:18,375 CVEs2023:28,961 CVEs2024(As of Q2):20,413 CVEs Copyright 2024,Cloud Se

67、curity Alliance.All rights reserved.10This continuous growth exacerbates several existing issues within the CVE system:Data Quality and Overload:The more CVEs are published,the harder it becomes to ensureeach entry is accurate,detailed,and actionable.The rise in CVE submissions puts pressure on thes

68、ystem,leading to incomplete or low-quality reports.Prioritization Difficulties:With thousands of new vulnerabilities each year,it becomesincreasingly difficult for organizations to prioritize remediation efforts effectively.The existingCVSS scoring system,while helpful,is not sufficient on its own t

69、o deal with the volume andcomplexity of modern vulnerabilities.Strain on Notification and Dispute Processes:As more vulnerabilities are identified,thealready slow and opaque processes for notifying project maintainers and resolving disputesbecome even more strained.This contributes to longer delays

70、in patches being developed anddeployed.CVSSWhen analyzing the severity of vulnerabilities,it is crucial to consider scoring systems that weigh thevulnerability threat levels.One example of this is a framework known as Common Vulnerability ScoringSystem(CVSS),which is one of the most widely used seve

71、rity scoring systems.Base Metrics:These metrics evaluate the characteristics of a vulnerability that are consistentthroughout time.It takes into account factors like how a vulnerability can be exploited,howcomplex the process of the exploitation is,and the privileges required for someone tosuccessfu

72、lly attack that system.Temporal Metrics:Temporal metrics measure vulnerabilities impact over time.More specificallyit analyzes any new information or recent problems relating to that exploit when accounting forthis metric.Some key factors that the temporal metrics evaluate are how long the exploit h

73、asbeen out,how much of the exploit has been resolved,how much of it is still a threat to systems,and finally the credibility of the reports that talk about these vulnerabilities.Environmental Metrics:Environmental metrics take a look into the severity of a vulnerabilityacross multiple different envi

74、ronments.Some factors that it takes into consideration would be thepotential loss that would happen in different systems when the vulnerability is exploited,thetarget distribution or proportion of vulnerable systems in the environment,and impact subscoremodifiers,which are the specific security requ

75、irements for each system.Impact Metrics:This metric is responsible for examining the consequences that a vulnerabilitymay have on a given system.It does this by analyzing the 3 fundamental principles ofcybersecurity:confidentiality,integrity,and availability.By analyzing all these factors it allows

76、thescoring system to not just evaluate the exploitability but predict the effects the exploitation of avulnerability could have on a system,in the future.By emphasizing these four main metrics,CVSS comes out with a severity score ranging between 0-10.Over the years,this severity assessment framework

77、 has become the gold standard,with many frameworks Copyright 2024,Cloud Security Alliance.All rights reserved.11that commonly categorize and identify new vulnerabilities implementing it into their system.This can beseen in examples,such as NVD and CVE-based frameworks that utilize CVSS scores as a w

78、ay todetermine the severity of every vulnerability they discover and categorize.However,CVSS containsglaring disadvantages in its framework that have been overlooked because there are little to noalternatives that aim to build and improve on the CVSS framework,leading to its continued perception ast

79、he standard of severity scoring systems.Disadvantages of CVSSInability to Prioritize RiskSome of the noted criticisms against the CVSS framework are its extensive misuse for prioritizingvulnerabilities and associated risk assessments despite being a rather ill-suited framework for assessingthe actua

80、l risk or impact of a given CVE.A variety of research underlines that the CVSS cannot prioritizeelements,such as material consequences on business if the vulnerability gets exploited,the likelihood ofthat exploit being used,and how publicly available it is.Although CVSS includes temporal metrics lik

81、eExploit Code Maturity to address these issues,these metrics are often underutilized or fail to capture thereal-world likelihood of exploitation.More commonly,high CVSS scores appear to indicate higherexploitability,but this will not always be the case.Many lower-scoring vulnerabilities can still le

82、ad tosignificant levels of exploitability.Additionally,the risk that a vulnerability poses to a system whenexploited by an adversary is largely variable;this is another aspect that the scoring mechanism of CVSS,which is primarily quantitative,fails to capture satisfactorily.In general,the CVSS frame

83、work is notefficient in ranking the real risk that a vulnerability poses to a system,as it doesnt consider a wide rangeof risk-related factors when determining the severity rating.Limited Awareness of ContextAlthough CVSS is a framework using a range of factors to determine the severity score assign

84、ed to aCVE,the limited context-awareness makes it unable to understand the nuance when assigning a severityscore.Looking much deeper into this issue reveals many factors that CVSS does not consider.One ofthese critical limitations lies in the fact that the CVSS cannot understand the threat that a vu

85、lnerabilityposes in various environments.In other words,even though a given vulnerability might be quite effectiveand exploitative within a system,the case could be different altogether in another environment.However,because a universal severity score is assigned to it,CVSS makes it appear that the

86、vulnerability of asystem would be consistent across all systems.However,building onto this lack of context exposes yetanother failing of the CVSS framework,which is vulnerability chaining.This is when more than one kind ofvulnerability is exploited in harmony to take advantage of a system.However,CV

87、SS fails to handle thisbecause,instead of discussing how easy chaining a vulnerability might be and its consequences incoordination with other vulnerabilities,it tends to analyze metrics related to the vulnerability itself.Thislack of context is not confined to one sector but leads to the misapplica

88、tion of company resources acrossother sectors.Each different sector has different requirements for what they consider severe,so it gets especiallydangerous to implement a one-score-fits-all approach as a business that may not particularly be Copyright 2024,Cloud Security Alliance.All rights reserved

89、.12threatened by that vulnerability will use resources to prevent it just because it has a high CVSS score.Webexploitation is the last example of a lack of context.Speaking about a web browser or plugin,usually thereare two types of spaces:a user space and an admin one.The effect of a vulnerability

90、in these two spaces,and its consequences,may vary considerably from one to the other.Extra context is thus crucial in thespace to form two clear scores for each.Examples abound,such as those listed above,which do notconsider adequate context that may be necessary for a score to effectively be determ

91、ined.Static Scoring SystemAnother major weakness of the CVSS framework is its static scoring.CVSS statically assigns a base scoreto a vulnerability within a short period after its discovery,based on various factors.The base score issupposedly indicative of the vulnerabilitys severity.The problem wit

92、h this system is that,in most cases,the base score rarely is updated after the initial assignment.Therefore,the score becomes static andreflects no change whatsoever in vulnerability impact or threat level over time.Researchers at Tenable(a cyber exposure company)have also pointed out how a static s

93、coring system isinefficient.Their findings indicated that 56%of vulnerabilities rated as high or critical scores rangingbetween 7.0 and 10.0 were rated accordingly regardless of current exploitation conditions or actual threatseverity.This is because preliminary evaluations were incorrect and furthe

94、r corrections never followed.Thus,theimmutable nature of the CVSS scoring system can lead to an inefficient distribution of resources in whichcompanies could likely waste effort on vulnerabilities that may have been in a state of decay.Due to such issues,CVSS v4.0 has been developed,which can apply

95、a more flexible scoring scheme.Thisnew version addressed some weaknesses from previous versions,as it contributes beyond the rigid staticbase score.Despite this,earlier versions of CVSS remain plagued with issues of static scoring,thereforesignifying that there is still a need for complementary meth

96、ods and enhancements towards thecontinuously evolving nature of vulnerabilities.User StoriesNow that weve identified the exact challenges we currently face in vulnerability data,lets go over thereal-world impacts weve seen from these problem areas.This section will detail real-life examples of theco

97、ncerns that currently lie with vulnerability data and the repercussions theyve had.cURLIn 2023,Daniel Stenberg,the creator of Client for URL(cURL),encountered a series of issues with theCVE and CVSS systems that highlight many of the challenges weve discussed.The controversy centersaround CVE-2020-1

98、9909,an integer overflow bug that was reported with an alarmingly high 9.8/10 CVSSscore.Copyright 2024,Cloud Security Alliance.All rights reserved.13First,lets examine the bug itself.Initially reported on HackerOne by Jason Lee,it was discovered that the“-retry-delay”option in cURL was susceptible t

99、o an integer overflow.The issue arose because thisoption takes user input and multiplies it by 1000 to convert it from seconds to milliseconds.On a 64-bitmachine,an input of“18446744073709552”would cause an integer overflow,resulting in the retryoccurring after a few seconds rather than waiting infi

100、nitely.This was identified as a bug with no securityexploit and was promptly fixed in cURL version 7.66.0 in September 2019.Later in August 2023,when the cURL team was surprised to learn that a CVE had been published for avulnerability in cURL despite the issue being resolved years earlier.Adding to

101、 the confusion was the CVEID,which included 2020,even though it was published in 2023.Upon investigation,the team discoveredthat the CVE was related to the integer overflow bug fixed in 2019,yet it was assigned a 9.8 severity scorefor what was simply a bug.This situation underscores the limitations

102、of the CVSS scoring system,particularly its lack of context.Theminimal communication between CVE authorities and project maintainers further exacerbates the issue.When Daniel Stenberg requested that MITRE reject the CVE,they refused,highlighting the problem ofhaving only one perspective available fo

103、r a CVE.Although the NVD eventually rescored the CVE to a 3.3,the incident exposed several flaws in the current vulnerability data system.One significant problem is how little information is required to get a CVE published.In this case,the CVEwas reported anonymously with minimal details about the a

104、ctual vulnerability.This lack of information isespecially problematic for severe CVEs,as it provides insufficient context for understanding the threat.The situation also illustrates how much power is centralized within a few organizations in the vulnerabilityspace.If MITRE refuses to modify or take

105、down a CVE,there are few,if any,options for recourse.Thishighlights the CVE systems inability to present multiple perspectives on a vulnerability,a change thatcould have prevented the entire situation.Finally,the incident reveals the limited research that goes intopublishing CVEs;a simple Google sea

106、rch would have shown that this vulnerability was merely a bug.Custom SolutionsDue to the aforementioned problems with CVEs,many companies have turned to creating customsolutions that cater specifically to their needs.One such example is the Ruby Advisory Database,acomprehensive list of all security

107、vulnerabilities in Ruby libraries.Hosted publicly on GitHub,this databaseallows anyone to contribute,immediately addressing one of the main issues with CVE.Additionally,itprovides detailed,Ruby-specific information,such as patched versions,unaffected versions,and relatedvulnerabilities.This ensures

108、that the security teams have all the necessary details to effectively addressthe vulnerabilities.The vulnerabilities often come with thorough descriptions covering their type,workarounds,and impacts.Moreover,the database integrates with tools like Bundler Audit,enablingautomatic vulnerability detect

109、ion for developers using Ruby.Another alternative to CVE is the Vulnerability Database(VDB)from VulnDB.While it uses CVE as a datasource,it enhances it with additional information,including vulnerabilities that dont have a CVE.One ofits key improvements is the CVSS Meta Temp Score,which builds on th

110、e CVSS score by incorporatingfactors such as disclosure,exploitability,and available countermeasures.This score is much moreeffective and addresses many of the shortcomings of the CVSS system.VulnDB also estimates themonetary resources needed to exploit a particular vulnerability and assigns a Cyber

111、 Threat Intelligence Copyright 2024,Cloud Security Alliance.All rights reserved.14(CTI)score,which measures the vulnerabilitys current relevance in the security community.The databaseprovides in-depth descriptions,exploit details,and a discussion section for each vulnerability,allowingusers to share

112、 their perspectives and findings.Each VDB is continuously updated as new informationemerges,and the database is rich with high-quality metadata and linked sources.Overall,VDB effectivelybuilds on CVE and demonstrates that a more robust vulnerability identification system is possible.The final custom

113、 solution well discuss is the GitHub Advisory Database(GHSA)which is a repository ofexisting CVEs and GitHub security advisories for open-source software.One of its strengths is itsintegration with GitHub,allowing it to link directly to specific commits or pull requests that address thevulnerability

114、.It also integrates with tools like Dependabot,enabling developers to quickly identifyvulnerabilities in their repositories.Furthermore,GHSA allows project maintainers to provide directfeedback on entries,ensuring their accuracy.All of these custom solutions build extensively on CVE,offering clear e

115、xamples of how CVE could address its current shortcomings.Alternatives to CVSSEPSSThe Exploit Prediction Scoring System(EPSS)is a data-driven framework designed to predict theprobability of a vulnerability being exploited in the wild within the first 12 months after public disclosure.Unlike the Comm

116、on Vulnerability Scoring System(CVSS),which primarily focuses on the severity ofvulnerabilities,EPSS uses logistic regression to model the likelihood of exploitation based on empiricaldata.The framework leverages publicly available data,including vulnerability characteristics and observedexploitatio

117、n patterns,to generate a score that reflects the threat level.EPSS offers several advantages over CVSS.First,it provides a more accurate and actionable approach toprioritizing remediation efforts by focusing on the likelihood of exploitation rather than just the severity ofthe vulnerability.This all

118、ows organizations to allocate resources more efficiently,ensuring that high-riskvulnerabilities are addressed first.Second,EPSS is transparent and simple to implement,using onlyelementary functions and readily available data.This makes it accessible to a wide range of users withoutthe need for speci

119、alized tools or software.Third,the model requires only a handful of inputs to generate aprediction,which further simplifies its application in real-world scenarios.When comparing the precision rates of both CVSS v3.1 and EPSS,CVSS was shown to have a 5.7%precision rate and a recall rate of 34%for sc

120、ores of 8.8 and above,while EPSS had a 19.9%precision rateand a recall rate of 72.4%at a threshold of 0.149 and higher(Weinberg,2024).Additionally,EPSS hasbeen shown to significantly reduce the level of effort required to patch vulnerabilities compared toCVSS-based strategies,with an 85%reduction in

121、 effort for vulnerabilities with a high EPSS score.Copyright 2024,Cloud Security Alliance.All rights reserved.15SSVCThe Stakeholder-Specific Vulnerability Categorization(SSVC)framework employs decision trees to guidestakeholders in vulnerability managementsuch as patch developers,patch appliers,andc

122、oordinatorsthrough a structured decision-making process tailored to their specific roles.Each treeoutlines critical elements,potential decision values,and anticipated outcomes,allowing stakeholders tonavigate key decision points like exploitation status,technical impact,safety impact,and mission imp

123、act.By categorizing stakeholders and providing distinct decision trees for each group,the framework ensuresthat decisions are relevant and actionable.Additionally,SSVC supports iterative improvement through feedback from pilot studies,leading toenhancements in clarity and usability.By integrating co

124、ntext-specific information directly into thedecision-making process,the framework enables a better understanding of the implications of eachdecision,ultimately facilitating more informed and nuanced vulnerability prioritization across diversestakeholder needs.Unlike CVSSs numerical scoring,SSVC emph

125、asizes qualitative inputs,enhancingcontextual relevance and allowing for decisions that reflect the priorities of different stakeholders.Thetransparency of the decision tree-based model builds trust among users when it comes to the severityscore rating itself.Moreover,SSVCs flexibility enables it to

126、 adapt to new evidence and changingenvironments,addressing a significant problem in CVSSs priority system.Pilot studies showed positive outcomes,indicating that the framework is particularly beneficial forstraightforward decisions like exploitation status.Based on these findings,the framework has un

127、dergoneimprovements,enhancing clarity and usability.Ultimately,SSVC represents a significant advancement invulnerability prioritization by providing a structured process that addresses the limitations of CVSS.Withits focus on qualitative decision-making,contextual information,and transparent methodo

128、logy,SSVCholds promise for improving vulnerability management practices across various groups.VPRThe Vulnerability Prioritization System(VPR)is a new vulnerability scoring framework developed byTenable,a cybersecurity solution provider.VPR enhances vulnerability remediation by combiningtechnical imp

129、act and threat intelligence to provide a comprehensive risk assessment.The technicalimpact measures the potential effects on confidentiality,integrity,and availability if a vulnerability isexploited,similar to the CVSS v3 impact subscore.The threat component reflects recent and potentialfuture threa

130、t activities,including public proof-of-concept research,social media reports,exploit codeemergence,dark web references,and malware detections.This integration of real-time threat intelligence allows VPR to identify vulnerabilities that are actively orlikely to be exploited,offering a significant adv

131、antage over CVSS,which focuses solely on technicalseverity.VPRs dynamic scoring,which is continuously updated with the latest threat data,ensuresrelevant and up-to-date prioritization.This approach addresses the challenge of CVSS,oftencategorizing many vulnerabilities as high or critical,making prio

132、ritization difficult.By narrowing the list tothe most critical vulnerabilities,VPR enables organizations to focus on the most pressing threats.Copyright 2024,Cloud Security Alliance.All rights reserved.16A study by Carnegie Mellon University highlighted CVSSs limitations in effective vulnerabilitypr

133、ioritization,noting that CVSS rated over 9,400 vulnerabilities as 9.0 or higher(Aboud,2020).Incontrast,VPRs threat-informed scoring system significantly reduces the number of critical vulnerabilities,allowing for more focused remediation efforts.This makes VPR a more dynamic and effective tool forma

134、naging and mitigating cybersecurity risks.Comparison of CVSS AlternativesCVSS AlternativesComparisonEPSSEPSSs main focus is predicting the likelihood of vulnerabilityexploitation using logistic regression over 12 months.In contrast SSVCuses more qualitative decision-making,not relying on statistical

135、predictions.Finally,VPR uses technical impact and real-time threatintelligence while making decisions which differs from EPSSsemphasis on probability of exploit prediction,highlighting its morepredictive approach.SSVCSSVC utilizes decision tree models that use qualitative data to helpguide holders w

136、ith vulnerability management.It differs fromsomething like EPSS which provides one predictive score and also thefact that it utilizes qualitative inputs and adapts to feedback.Furthermore,when compared to VPR which focuses on technicalimpact and threat intelligence,SSVC prioritizes stakeholder-speci

137、ficneeds.VPRVPR combines the technical impact that a vulnerability has inconjunction with real-time threat intelligence meaning that it iscontinuously updating.In comparison to EPSS,which predictsexploitation likelihood with a more static but predictive score,VPR is amore dynamic approach that emplo

138、ys threat data over time.Finally,unlike SSVC,which emphasizes qualitative decision-makingspecifically for stakeholders,VPR integrates quantitative threat datafor risk prioritization.Copyright 2024,Cloud Security Alliance.All rights reserved.17Threat Modeling FrameworksWhat Is Threat Modeling?The thr

139、eat modeling framework is a structured process used to identify and address security threats thatcould be exploited.It involves analyzing a system from the point of view of a threat actor,identifying whoa threat actor could be,their potential motivations,and the resources available to them that they

140、 can useto exploit a system.This allows organizations to build security measures accordingly to prevent suchissues from happening beforehand.However,to establish effective threat modeling it is important to havestructured frameworks which can systematically identify,assess,and mitigate any potential

141、 threats withina system.This is where the role of catered threat modeling frameworks comes in.Considering threatmodeling is crucial when discussing the Common Vulnerability Scoring System(CVSS)because itprovides a comprehensive understanding of potential threats,which is essential for accurately ass

142、essingand prioritizing vulnerabilities.Throughout this section,we will be delving into a plethora of threatmodeling frameworks that are essential to combat and prevent vulnerabilities from happening in the firstplace.STRIDEThe STRIDE framework,developed by Microsoft,is a threat modeling tool designe

143、d to identify andcategorize security threats in software systems.STRIDE stands for Spoofing,Tampering,Repudiation,Information Disclosure,Denial of Service,and Elevation of Privilege,each representing a different type ofthreat:Spoofing:When someone impersonates an authorized identity to gain access t

144、o a systemTampering:Unauthorized modification of data within a systemRepudiation:Denying actions or events that have occurredInformation Disclosure:Eavesdropping on channels that contain sensitive informationDenial of Service:Disrupting the availability of a systemElevation of Privilege:Escalating p

145、ermissions to a higher levelTo effectively use STRIDE,security teams create a model of the system using data flow diagrams,andthen analyze each component or interaction using the categories provided by STRIDE.These often helpin finding vulnerabilities during the design phase meaning that there can b

146、e more proactive mitigationmeasures being put in place to address these issues.For example,if a database is exposed to threats liketampering or information disclosure there can be encryption added to that information to prevent issuesfrom being exploited in the future.STRIDE is used across a variety

147、 of industries and phases particularly across cloud computingenvironments or systems that are in more early stages of development.It is better suited to addressconcerns before they happen rather than after or when they exploit a system.Copyright 2024,Cloud Security Alliance.All rights reserved.18LIN

148、DDUNThe LINDDUN framework is a privacy threat modeling methodology developed by experts at KU Leuven,designed to systematically identify and mitigate privacy threats in software architectures.LINDDUNstands for Linkability,Identifiability,Non-repudiation,Detectability,Disclosure of information,Unawar

149、eness,and Non-compliance,which are the key privacy threat types it addresses:Linkability:The ability to link two or more separate pieces of information about an individualIdentifiability:The ability to identify an individual from a set of dataNon-Repudiation:Ensuring that a party cannot deny the aut

150、henticity of their actionsDetectability:The ability to detect the presence of an individuals dataDisclosure of Information:Removing authorized access to sensitive informationUnawareness:Users are unaware of how their data is being usedNon-Compliance:Failure to comply with privacy regulations and pol

151、iciesThe framework involves creating a model of the system,typically using Data-Flow Diagrams(DFDs),andthen systematically analyzing each component and interaction for potential privacy threats using thecategories in the LINDDUN framework.This is facilitated by LINDDUNs extensive catalog of privacyt

152、hreat types,threat trees,and mapping tables,which guide the analyst in identifying and addressingprivacy issues.In addition to the original LINDDUN framework,there are more advanced versions,such as LINDDUN GO,LINDDUN PRO,and LINDDUN MAESTRO.These versions aim to cater to different levels of experti

153、sespecifically in the private threat modeling sector and offer complexity far above original models ofLINDDUN.LINDDUN GO is at the lowest level offering a more streamlined and user-friendly approach,utilizing redesigned threat cards to simplify the analysis process.LINDDUN PRO offers a morecomprehen

154、sive and systematic analysis,which is more suitable for advanced users who want more indepth privacy assessments.Finally,LINDDUN MAESTRO has tools and automation for the largest scaleand most complex threat modeling.These frameworks are used at the industrial level to ensure that allthreats are addr

155、essed during the design and development of software systems.This highlights howLINDDUN is accessible at all levels from a single user to an entire industry,showing its versatility in thethreat modeling landscape.PASTAThe Process for Attack Simulation and Threat Analysis(PASTA)framework is a risk-cen

156、tric methodologydesigned to identify and mitigate security threats through seven stages.It begins with defining businessobjectives,where critical assets and security goals are identified to align efforts with organizationalpriorities.The second stage,defining the technical scope,involves mapping the

157、 systems architecture,boundaries,and data flows to understand potential entry points for threats.Application decomposition,the third stage,breaks down the system into smaller components,identifying trust boundaries andcreating data flow diagrams to pinpoint attack surfaces.In the fourth stage,potent

158、ial threats areenumerated,and prioritized based on their impact,and adversary profiles are developed.The fifth stage,vulnerability and weakness analysis,uses tools like static and dynamic analysis to identify specificvulnerabilities and weaknesses,mapping them to potential threats.Attack modeling,th

159、e sixth stage,Copyright 2024,Cloud Security Alliance.All rights reserved.19simulates potential attacks to assess their feasibility and impact,developing detailed scenarios andconducting simulations.Finally,risk and impact analysis evaluates the overall risk to the organization,prioritizing mitigatio

160、n strategies and reassessing the business impact of remaining risks.Some scenarios where PASTA is particularly useful are when organizations need to protect sensitive dataor business functions.For instance,it is often applied to secure web applications that handle types ofconsumer information,ensuri

161、ng compliance with data protection regulations.In addition,PASTA can beused when identifying and mitigating risks in transactions where integrity and confidentiality areparamount.However,it is not only limited to these two fields.PASTA has reach in industries like finance,business,and even healthcar

162、e applications.By integrating PASTA into these security practices,organizations can address potential threats more proactively and ensure greater resilience.VASTThe Visual,Agile,Simple Threat(VAST)modeling framework is a modern threat modeling methodologydesigned to address the issues of large-scale

163、 enterprise systems by emphasizing scalability,automation,and integration.It uses process flow diagrams to visually represent system architecture,data flows,andtrust boundaries,making threat identification more intuitive.VAST is designed to integrate into Agiledevelopment processes,ensuring continuo

164、us threat modeling that evolves with the system.It aims tosimplify the process,making it accessible to a broader range of stakeholders.Some of the areas where VAST is being employed is in large scale organizations,where it is important tohave a more complex and scalable framework that are more in-de

165、pth then other opposing models.Additionally it focuses on stakeholders specifically.Although it can be used to address specific users,where VAST really shines is its ability to help stakeholders or corporations with high-level threat modeling.Finally VAST works well with automated tools and DevOps w

166、orkflows which makes it better for systemsthat require real time threat modeling updates.All these uses of VAST highlight that it is particularlyeffective in environments where organizations want to proactively identify and mitigate potential securitythreats throughout the development life cycle.TRI

167、KEThe TRIKE framework is an open-source threat modeling methodology focused on security auditing froma risk management perspective.It involves creating threat models to describe the security characteristicsof an application or IT system.TRIKE consists of three versions:the first version introduced t

168、he basicconcepts,the second version added automatic threat generation,and the third version incorporatedattack trees for more detailed analysis.The framework includes a requirements model,which definessecurity requirements by identifying assets,actors,and actions,and mapping them to security goals;a

169、nimplementation model,which maps out the system architecture by detailing data flows,trust boundaries,and components;and a risk model,which assesses and prioritizes risks by evaluating the likelihood andimpact of threats and determining appropriate countermeasures.When delving into some of the appli

170、cations of the TRIKE framework,we can see that it is primarilyengaged with security auditing and modeling from a risk based perspective.It helps organizations,Copyright 2024,Cloud Security Alliance.All rights reserved.20similarly to other threat models,identify and evaluate potential cyber threats t

171、o their systems or networksby generating threat models.These models have been valuable for creating risk registries,allowing formore targeted mitigation strategies for specific risks.Additionally,its collaborative nature facilitatescoordination among stakeholders,which is a trait that it shares with

172、 a framework like VAST.Through thesevarious use cases TRIKE has cemented itself as a model that is widely employed in the field of threatmodeling.DREADThe DREAD risk assessment model addresses the impact that a vulnerability can have on a system.This isdone through the careful analysis of five categ

173、ories:Damage,Reproducibility,Exploitability,AffectedUsers,and Discoverability.Damage:What would be the impact to a system if that vulnerability were to be exploited?Reproducibility:How easy is it to perform this attack multiple times?Exploitability:What is the ease of launching an attack through thi

174、s vulnerability?Affected Users:Who is being impacted and how many people are being impacted?Discoverability:How easy is it to discover the threat to the system?Although DREAD is a much older and inconsistent framework when compared to other existingalternatives to talk about,it is an important frame

175、work to talk about due to the fact that it is a muchsimpler approach to threat management that many of the previous frameworks lack which make it muchmore accessible to corporations that are not as well versed in the field of cybersecurity.Additionally,itprovides a particular emphasis on risk manage

176、ment which highlights how much of an impact is beingmade on a system or potential damage.This approach is vital and often overlooked with other similarthreat modeling frameworks.However,the DREAD framework does have its own set of concerns.One such problem is the subjectivityof DREADs metrics.This i

177、s due to the fact that the metrics of DREAD are in the hands of humaninfluence meaning that most of the assessment is done manually.This implies that there is an inherentbias in how a person assesses metrics through the guise of DREAD showing that a persons perspectivesof certain vulnerabilities cou

178、ld lead to different assessments being made creating inaccuracy.Despitethese issues,it is still important to consider DREAD as an alternative as it provides a great base forseverity scoring and has a lot of features that make it a beneficial framework today.Copyright 2024,Cloud Security Alliance.All

179、 rights reserved.21Comparison of Threat Modeling FrameworksThreat modeling frameworksComparisonSTRIDESTRIDE offers a variety of benefits compared to otherframeworks like LINDDUN,PASTA,VAST,and TRIKE.Forexample,STRIDE focuses primarily on common securitythreats and provides a high-level overview of t

180、he threatlandscape due to its broad categories,unlike otherframeworks that might concentrate on specific types ofvulnerabilities.LINDDUNLINDDUNs extensive catalog of privacy threat types,threat trees,and mapping tables,guide the analyst inidentifying and addressing privacy issues.In contrast,otherme

181、thods like STRIDE and PASTA primarily address securityconcerns,with STRIDE focusing on security threats andPASTA emphasizing security aspects.PASTACompared to other frameworks like STRIDE,which focuseson specific threat categories,and VAST,which emphasizesscalability and integration for more large-s

182、cale enterprises,PASTA offers a more holistic and business-orientedapproach as shown by its business-centric process.Itsability to simulate real-world attacks and involve bothtechnical and business stakeholders ensures that securitymeasures are aligned with the objectives of the businessthat utilize

183、s it.VASTCompared to other frameworks like LINDDUN,STRIDE,and PASTA,VAST is unique in its scalability andautomation,making it suitable for large enterprises.Itautomates much of the threat modeling process,reducingtime and effort,and integrates seamlessly with existingdevelopment and security process

184、es.VAST is particularlyuseful for securing web applications,auditing IT systems,and developing secure software,ensuring that security isintegrated into the software development lifecycle fromthe beginning.Therefore by focusing on scalability,automation,and integration,VAST provides an approachto thr

185、eat modeling that is very valuable for largecorporations.TRIKECompared to other frameworks like LINDDUN,STRIDE,and PASTA,TRIKE is unique in its risk-based approach,focusing on the highest risks first and automating much of Copyright 2024,Cloud Security Alliance.All rights reserved.22the threat gener

186、ation processes.TRIKE is also suitable forvarious use cases,such as the security of web andIT-based systems,and aiding in the development of securesoftware.Finally,TRIKE ensures that countermeasures areappropriate for the identified threats,making it a valuabletool for security professionals.DREADCo

187、mpared to other frameworks like LINDDUN or PASTA,DREAD offers a unique perspective on threat modeling byfocusing on quantifying and prioritizing security threatsthrough qualitative based approaches.While additionalframeworks like STRIDE categorize threats into specifictypes and VAST emphasizes scala

188、bility and automation forlarge enterprise,DREAD is a more simple and focusedapproach to threat modeling.This makes DREADparticularly useful for organizations who may not be asknowledgeable about the world of cybersecurity nor as bigscale as large corporations but are still looking for aneffective fr

189、amework to address vulnerabilities.Future Directions and Emerging TrendsThe landscape of vulnerability data is constantly changing alongside the rise of new technologies.Itsimportant to identify these and analyze how theyll affect the vulnerability data space in the coming years.Big Data Problems an

190、d Scale IssuesAs more people around the globe have become accustomed to the world of technology,globalization andthe rapid increase of new technologies have become more prevalent than ever.Although this can bebeneficial as more users get access to a repository of information all through the tap of a

191、 device,this alsomakes way for the discovery of new vulnerabilities that can be exploited.Industry projections estimate asharp increase in CVE creation,with 500 predicted to be released each week by 2025.On top of this,withthe growth of new technology,the variety of unique software flaws has increas

192、ed from 20 to 130 permonth which is a growth of 650%.However,in response to this,the number of vendors publishing theirfirst CVE has increased by 13%from last year.Additionally,databases from the Cybersecurity andInfrastructure Security Agency(CISA)known vulnerability list have been growing by the m

193、onth at anexponential rate.All this accentuates the underlying scale issues that plague many of these vulnerabilitydatabases leading to issues with large amounts of data scale.To combat these challenges,severalsolutions have been implemented.Automation and AI are being leveraged to efficiently manag

194、e andprioritize vulnerabilities.Enhanced collaboration between vendors,security researchers,and organizationshelps in quicker identification and mitigation.Improved vulnerability management tools,regular updates Copyright 2024,Cloud Security Alliance.All rights reserved.23and patching,security aware

195、ness programs,and bug bounty initiatives also play crucial roles.Additionally,stricter government and industry regulations ensure adherence to best practices in cybersecurity.The Role of Artificial Intelligence and MachineLearningWith the recent rise in popularity of artificial intelligence(AI)and m

196、achine learning(ML),manyimplementations are being developed for vulnerability data.First,lets examine how AI can be used invulnerability scoring.Today,a major problem with vulnerability scoring is that the scores arentcontext-aware.As weve mentioned previously,this means vulnerabilities are rated in

197、correctly and giveunnecessary work to security teams.Using context-aware scoring is clearly superior in terms of efficiencyand accuracy,but they are resource-intensive.Research needs to be done for every single vulnerability todetermine its context and its score.With more vulnerabilities coming out

198、today than ever before,manuallycreating context-aware scores is not feasible for the future.However,this is where AI can help.AI has access to a large amount of historical data which can be used in part to determine a vulnerabilityscore.Using machine learning algorithms,new vulnerabilities can be co

199、mpared to those of previousvulnerabilities,and similarities can be detected.However,each new vulnerability has its unique propertiesmeaning historical data cant be the only source for a score.This is where natural language processing(NLP)can help.Traditional sentiment analysis methods can be tasked

200、with reviewing data scraped fromonline forums,social media,and other places of discussion to determine what the community consensusis on a vulnerability.While it may not be possible to get a perfect context-based score through this,it willmake the job of all reviewers easier as they will spend less

201、time researching and getting sources directly.One thing that needs to be noted with this,is that using historical data will also encompass historicalCVSS scoring,which may lead to skewed AI results due to the static nature of previous CVSS versions.Small Large Language Models(LLMs),order of GPT-2,fi

202、ne-tuned on code/CVEs are excellent atvulnerability detection,something emerging startups,such as Binarly,have already started testing.GitHubs code scanning feature also employs a machine learning algorithm that alerts a projectmaintainer if theres a possible vulnerability in their pull requests.Goi

203、ng further,integrating ML security tooling into an organizations systems,such as ConfigurationManagement Databases(CMDBs),with full context of the vulnerabilities position in a network withvisibility of the compensating controls and criticality of the system to the organization,would provideanother

204、layer of context to help organizations prioritize patching efforts for at risk systems.Copyright 2024,Cloud Security Alliance.All rights reserved.24ConclusionThe rapidly evolving landscape of cybersecurity demands innovative solutions to address the challengesin vulnerability data management.Traditi

205、onal systems like CVE and CVSS face limitations in data quality,scalability,and adaptability.By integrating AI and ML technologies,we can enhance vulnerability scoring,reporting,and management processes.AI-driven tools can automate and enrich vulnerability data,improve interoperability among databas

206、es,and provide dynamic,context-aware assessments.ML modelsenable proactive threat detection and prioritization,reducing the burden on security teams andenhancing organizational resilience.Embracing AI and ML in vulnerability data management is essential tokeep pace with the increasing complexity and

207、 volume of vulnerabilities.Collaborative efforts amongstakeholders,combined with technological advancements,will pave the way for more effectivecybersecurity strategies in the future.Copyright 2024,Cloud Security Alliance.All rights reserved.25ReferencesAboud,J.(2020,April 27).Why you need to stop u

208、sing CVSS for vulnerability prioritization.Tenable.https:/ 23).Benefits of pasta threat modeling and its 7 steps.VerSprite.https:/ Vulnrichment.(n.d.).CISA Vulnerability enrichment.https:/ vulnerability scoring system SIG.FIRST.(n.d.).https:/www.first.org/cvss/CVE Metrics.(n.d.).CVE Metrics at https

209、:/www.cve.org/About/MetricsExploit prediction scoring system(EPSS).FIRST.(n.d.-b).https:/www.first.org/epss/researchGitHub.(n.d.).GitHub advisory database.https:/ machine learning to find security vulnerabilities.https:/github.blog/security/vulnerability-research/leveraging-machine-learning-find-sec

210、urity-vulnerabilities/HackerOne.(n.d.).Report#661847.https:/ 2.5:Pasta Threat Modeling Methodology.https:/research.cs.wisc.edu/mist/SoftwareSecurityCourse/Chapters/2_5-PASTA-ThreatModeling.pdfJacobs,J.,Romanosky,S.,Suciu,O.,Edwards,B.,&Sarabi,A.(n.d.).Enhancing vulnerability prioritization:Data-driv

211、en exploit.https:/arxiv.org/pdf/2302.14172.pdfJacobs,J.,Romanosky,S.,Edwards,B.,Adjerid,I.,&Roytman,M.(2021).Exploit prediction scoringsystem(EPSS).Digital Threats:Research and Practice,2(3),117.https:/doi.org/10.1145/3436242Jayaraman,N.(2023,December 15).Trike threat modeling:Definition,stages,and

212、benefits:EC-Council.Cybersecurity Exchange.https:/www.eccouncil.org/cybersecurity-exchange/threat-intelligence/trike-threat-modeling-methodology/Jegeib.(2022,August 25).Threats-microsoft threat modeling tool-azure.Threats-Microsoft ThreatModeling Tool-Azure|Microsoft Learn.https:/ advisory database.

213、https:/ Copyright 2024,Cloud Security Alliance.All rights reserved.26Shick,D.(2018b,December 5).Towards improving CVSS.SEI Blog.https:/insights.sei.cmu.edu/cert/2018/12/towards-improving-cvss.htmlSpring,J.M.,Householder,A.,Hatleback,E.,Manion,A.,&Shick,D.(n.d.).Prioritizing vulnerabilityresponse:A s

214、takeholder-specific.https:/insights.sei.cmu.edu/documents/583/2019_019_001_636391.pdfStakeholder-specific vulnerability categorization(SSVC):CISA.Cybersecurity and Infrastructure SecurityAgency CISA.(n.d.).https:/www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvcStenberg,D.(2023,Aug

215、ust 26).CVE-2020-19909 is everything that is wrong with CVEs.https:/daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-everything-that-is-wrong-with-cves/Stenberg,D.(2024,February 21).Disputed,not rejected.https:/daniel.haxx.se/blog/2024/02/21/disputed-not-rejected/VulnDB.(n.d.).Vulnerability database

216、.https:/ 6).EPSS:The ultimate guide.Vulcan Cyber.https:/vulcan.io/blog/thinking-of-using-epss-heres-what-you-need-to-know/What is threat modeling and how does it work?.Synopsys.(n.d.).https:/ is VPR and how is it different from CVSS?.Tenable.(2023,October 31).https:/ Foundation.(2024,September 22).S

217、tride model.Wikipedia.https:/en.wikipedia.org/wiki/STRIDE_modelWikimedia Foundation.(2024a,September 5).Threat model.Wikipedia.https:/en.wikipedia.org/wiki/Threat_model#VASTWuyts,K.,Sion,L.,&Joosen,W.(n.d.).Linddun go:A lightweight approach to privacy threat.https:/sion.info/assets/pdf/publications/WuytsIWPE2020.pdf Copyright 2024,Cloud Security Alliance.All rights reserved.27