DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to communication received on 08/01/2024. The applicant has submitted 20 claims for examination, all claims are currently pending.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to and abstract idea without significantly more. The claim(s) recites a system method and non-transitory CRM for assessing risk in a computing environment. Such corresponds to abstract idea in the multiple groups of recognized abstract ideas to include mathematical concepts, formulas and equation, mental processes(evaluation/judgment/opinion) and methos of organizing human activity(i.e. hedging/mitigating risk). The categorization toward a mathematical concept is based on the fact the claim mainly describe mathematical calculations of an overall risk score based on individual and composite risk factors. The claims comprises mostly calculations without much more. The categorization toward a mental process is based on the fact that the calculation of an overall risk based on composite and individual risk factors could describe for example human evaluating the risk of the wagering of an amount of money at t various casino games based on the factors such as house edge, wager level, bank roll. The categorization as a method of organizing human activity is based on the fact that the claims directing regard aspect of calculating risk values, which corresponds to human activities in risk management in financial transactions. This judicial exception is not integrated into a practical application because the claims do not recite limitation beyond the calculating of an overall risk score. The claims recite individual risk factors, composite risk factors for the calculation of an overall risk score and in subsequent dependent claims various weightings and formula for performing the calculations. However, the claims are not tied to specific implementation that with specific factors that would can be considered to integrate the judicial exception in to a practical application. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the claims do not recite anything beyond mere calculations. The independent claims do not recite any language beyond calculations and even the recitation of performing an action in response to the score meeting a threshold in claim 7, such an action is so generic that is does not amount to significantly more. The recitation of a first computing environment and the risk score being calculated for such a computing environment is again so general that it amounts to a simple linking of the claims to a computing environment. Thus, in consideration of the claims 1 19 and 20 and the dependent claims 2-18 the examiner conclude that the claims are directed to an abstract idea without significantly more.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mankovskii US 2016/0127407 and further in view of Albanese US 2024/0396930.
Regarding claims 1, 19 and 20, Mankovskii teaches a system, non-transitory CRM and a method comprising: accessing, by a Threat and Vulnerability Management Security System (TVMSS), a risk model specified for a first computing environment, the risk model including:
[0025] FIG. 1 illustrates an example computing environment in which a risk measurement framework can be deployed in accordance with the principles of the present disclosure. In the environment 100 an enterprise user 110 uses a network 102 to communicate with a variety of network endpoints that are external to the enterprise. One such example endpoint can be a cloud service provider 106 that provides cloud services such as, for example, SaaS. An enterprise typically includes a network traffic monitoring system 108 that is shown as a single element in FIG. 1. In practice, the monitoring system 108 can be distributed at different locations within the enterprise to monitor network traffic in either direction. One aspect of such monitoring systems 108 relates to threat detection, intrusion detection and the presence of malware or viruses within the enterprise network. Certain network attacks and security-related events have “signatures” that can be autonomously detected, analyzed, evaluated, and ranked. In this way, modern enterprise network monitoring systems 108 can detect network-based communications into or out of the enterprise network, categorize them based on a number of attributes such as originator IP address, destination IP address, network protocol, application-layer protocol, destination URI, etc. and possibly associate them with currently occurring, or previously occurring, security-related events or activity. As described more fully below, the capability of such network traffic monitoring systems can be utilized when calculating a shadow rank value in accordance with the principles of the present disclosure.
a set of individual risk factors(individual scores for a respective category, ¶6)
[0006] According to one aspect of the present disclosure, a method of determining potential harm associated with a network endpoint external to an enterprise includes receiving information about a network-based communication by a resource of the enterprise directed to the network endpoint external to the enterprise, and calculating a plurality of individual scores related to a risk associated with the network-based communication, wherein each individual score corresponds to a different category of risk. The method also includes receiving data specifying a policy related to rules defined by the enterprise regarding usage of cloud services; calculating a composite risk score related to the network-based communication, wherein the composite risk score is based on the individual scores and the policy; and notifying an entity of the enterprise about the composite risk score.
a set of composite risk factors(differing categories of risk, i.e. virus exposure, data exposure, ¶48)
[0048] In either alternative, the risk measurement system, in step 304, calculates a score related to a potential risk of harm by the communication. In particular, that calculated score is comprised of a plurality of individual scores each related to a different category of risk. As mentioned above, example categories of risk include security exposure, virus exposure, data exposure, phishing exposure, site authenticity, site usage within an enterprise, knowledge about previous usage of a site from within the enterprise, and whether or not approval of a site has previously been determined. Thus, an aggregation system acquires a number of individual scores and assembles them into a score reflecting the potential risk of harm.
a final composite function for computing an overall risk score for the first computing environment(simple average or weighted average math function used to calculate an overall risk score, ¶30)
[0030]…For example, the three values could be averaged together but that might “hide” a very serious data exposure risk if the risks of a virus attack and phishing attack are very low. Thus, another way to compute a security exposure risk value is to assign it to be the highest value of the three separate component values. There can also be a “weighting” system utilized with the three (or more) separate components where a respective weight can be assigned for each component or assigned to the internal elements that are part of calculating a component. For example, if a system being monitored only reads information, then a virus attack would have a higher relative importance than a phishing attack because that system only reads and does not respond to requests. Accordingly, a risk associated with a phishing attack could be weighted to reduce its effect on the overall score being viewed as a high risk and a risk associated with a virus attack could be weighted to increase its effect on the overall score being viewed as a high risk.
computing, by the TVMSS, the overall risk score for the first computing environment using the final composite function, wherein the final composite function uses at least two composite risk factor scores computed for at least two composite risk factors in the set of composite risk factors for computing the overall risk score(overall score calculated based on weight scores of composite scores across multiple categories of risk, ¶s30,49)
[0030] A security exposure calculator 122 can, for example, calculate a value indicative of the probability of various types of security-related exposures associated with a particular network communication with a service provider or a particular URI or site. Different security exposures can include, for example, probability of data exposure, probability of virus attack, and probability of a phishing attack. For example, using gmail as the enterprise mail system or storing data in cloud storage inherently include a risk of data exposure. Based on the reputation of a URI or known data leaks in the past, the security exposure calculator 122 can assign an initial probability value, or adjust a probability value, (e.g., a value between 0 and 1) that a data communication with a particular endpoint has a data exposure risk. The security exposure calculator 122 can also assign a similar probability value for each of the risk of a virus attack and the risk of a phishing attack. Again, the initial value may be based on an external data source such as AVG Threat Labs or, for example, by collecting sentiments about a company or service through social media analytics, and then adjusted based on past experience and activity captured by the enterprise's traffic monitoring system 108. Each of the three different security exposure risks can be treated separately or can be combined into a single security exposure value. For example, the three values could be averaged together but that might “hide” a very serious data exposure risk if the risks of a virus attack and phishing attack are very low. Thus, another way to compute a security exposure risk value is to assign it to be the highest value of the three separate component values. There can also be a “weighting” system utilized with the three (or more) separate components where a respective weight can be assigned for each component or assigned to the internal elements that are part of calculating a component. For example, if a system being monitored only reads information, then a virus attack would have a higher relative importance than a phishing attack because that system only reads and does not respond to requests. Accordingly, a risk associated with a phishing attack could be weighted to reduce its effect on the overall score being viewed as a high risk and a risk associated with a virus attack could be weighted to increase its effect on the overall score being viewed as a high risk.
[0049] However, each enterprise can have different tolerance to risk and can have different tolerances to each of the different categories of risk that are included in the assembled score. Accordingly, in step 306, a shadow rank calculation engine retrieves enterprise rules and policies related to enterprise acceptance of particular risks with relation to cloud service usage or other risks. Once the rules and policies have been retrieved, the shadow rank calculation engine calculates, in step 308, a composite risk score by applying the enterprise rules and policies to one or more of the individual scores related to the different categories of risk. The “composite” score may be designed to hide the details of the individual scores and the complexity of the rules and guidelines of the enterprise. For example, the individual scores may be a variety of different numerical values and/or Boolean values while the rules may be organized into various polices in complex hierarchical decision trees that allow detailed determination of potential harm. However, the composite score may be as simple as assigning a communication into one of three categories such as “high risk”, “medium risk”, and “low risk”. Additionally, the composite score can include a probability value (e.g. 66%) indicating a certainty that the categorization of the communication is accurate.
and outputting the overall risk score(score can be notified i.e. outputted to user, ¶43)
[0042] The shadow rank calculation engine 116 receives the risk values from the risk measurement system 120 and applies the rules from the policy database 114 to calculate a shadow rank for a particular URI or a particular network communication with a URI. While various and complex forms of a shadow rank can be envisioned, simplifying the value into categories of “high”, “medium”, or “low” risk (and possibly a probability indicative of the accuracy of categorization) is beneficial. Once the shadow rank calculation engine calculates the rank, that value can be forwarded using various notification systems 118 within the enterprise to one or more enterprise entities. For example, an e-mail reading client can provide a pop-up window on the enterprise user's computer informing them of a shadow rank of an e-mail message or can appear when a user hovers over a hyperlink in an e-mail client or web browser. The notification revealing the shadow rank can also be provided to the traffic monitoring system 108 so that statistics can be collected about communications with cloud service providers. From these statistics, further analysis can be made as to whether, or how well, enterprise policies and guidelines about allowed and forbidden communications are being followed. In certain instances, an intended network communication may have such a high risk of harm that some other system of the enterprise (e.g., firewall, etc.) can be alerted so as to block that communication. However, that functionality may typically be performed at a site-level (e.g., all communications to/from a particular site are blocked) rather than at a specific communication level (e.g., one user, but not other users of the enterprise, are blocked from communicating with a particular site).
Mankovskii teaches calculating individual risk and composite risk but does not specifically teach individual or composite risk factor functions. Mankovskii does not teach for each individual risk factor in the set of individual risk factors: an individual risk factor function associated with the individual risk factor used for computing an individual risk factor score for the individual risk factor;
and one or more input parameters used by the individual risk factor function for computing the individual risk factor score;
and for each composite risk factor in the set of composite risk factors: a composite risk factor function associated with the composite risk factor used for computing a composite risk factor score for the composite risk factor;
and at least two input parameters used by the composite risk factor function for computing the composite risk factor score;
receiving, by the TVMSS, a set of one or more inputs to the TVMSS; for each individual risk factor in the set of individual risk factors, computing, by the TVMSS, the individual risk factor score using the individual risk factor function associated with the individual risk factor, wherein the one or more input parameters used by the individual risk factor function include at least one first input from the set of one or more inputs to the TVMSS;
for each composite risk factor in the set of composite risk factors, computing, by the TVMSS, the composite risk factor score using the composite risk factor function associated with the composite risk factor.
Albanese in the same field of endeavor as the invention teaches a system for scoring vulnerabilities. Albanese teaches for each individual risk factor in the set of individual risk factors: an individual risk factor function associated with the individual risk factor used for computing an individual risk factor score for the individual risk factor(individual risk calculation based on an equation(function) for CVSS(common vulnerability) based risk calculation, ¶s6,14,15)
and one or more input parameters used by the individual risk factor function for computing the individual risk factor score(CVSS equation include variables(i.e. parameters) corresponding to characteristic of the attack, ¶s 6,14)
[0006] For example, MITRE and OWASP (Open Web Application Security Project) provide periodic rankings of software weaknesses and software vulnerability scoring systems. However, the rankings offer limited solutions because they abstract the details of individual vulnerabilities and reason for the vulnerabilities in terms of weaknesses, but provide only generic rankings that are not useful to understand the security posture of a specific system. For vulnerabilities, topological vulnerability analysis and numerous scoring and ranking systems have been developed, including multi-layer graph approaches to configuration analysis and optimization using vulnerability graphs and various scanning tools to identify the specific vulnerabilities that exist in each component of a distributed system. However, they do not aggregate the information at a higher level of abstraction, rendering it difficult for a security analyst to derive actionable intelligence from voluminous scanning reports. For example, the Common Vulnerability Scoring System (CVSS) often returns the same severity score and rank for a plurality of vulnerabilities, leaving the security personnel unable to differentiate severities between those vulnerabilities. Further, the rankings of common weaknesses are based on knowledge about all known vulnerabilities rather than the specific vulnerabilities that exist in the system being evaluated, resulting in overestimating or underestimating the true severity of the weaknesses. Furthermore, the scoring systems rely on predefined notions of risk and use fixed equations to compute numerical scores, and thus do not provide users with the flexibility to fine-tune such equations or consider new variables. For example, susceptibility of a vulnerability to becoming a target for exploitation by malicious users depends on a number of variables including features of the vulnerability itself and characteristics of potential attackers. Many of the existing approaches have focused on intrinsic features of vulnerabilities, but not extrinsic features such as the types, skills, and resources available to the potential attackers. As such, these approaches focus on scoring and comparing vulnerabilities for a fixed attack surface or model based on fixed equations and predefined security risks, thereby failing to provide a user the ability to modify or adjust the vulnerability assessment in accordance with the specific needs of the distributed system being protected.
[0014] In some example embodiments, the quality score improves based on an increase in a number of the plurality of variables used in the calculation of the customized metrics. In some example embodiments, the method further includes: adding one or more new variables to at least one of the first set X.sub.l.sup.↑, the second set X.sub.l.sup.↓, the third set X.sub.e.sup.↑ or the fourth set X.sub.e.sup.↓ based on a user selection in accordance with the priorities of the distributed system. In some example embodiments, the method further includes: calculating severity scores for the one or more vulnerabilities based on the customized metrics, quality scores of respective customized ranks, and deviations of each customized rank from an ideal scenario in which each vulnerability has a unique severity score; and outputting the severity scores, the quality scores, the deviations and cumulative number of vulnerabilities in each rank on a graphical user interface.
[0015] In some example embodiments, the likelihood of exploitation and the exposure factor are combined into a severity score that allows ranking of the one or more vulnerabilities, the severity score is defined as s(v)=ρ(v).Math.ef(v), the quality score is defined as Q(r)=e.sup.−γ.Math.δ(r), and the ideal scenario is defines as δ(r)=√{square root over (Σ.sub.i=1.sup.r(|CVE(r)|−1).sup.2/r)}
and for each composite risk factor in the set of composite risk factors: a composite risk factor function associated with the composite risk factor used for computing a composite risk factor score for the composite risk factor(equation for computing likelihood of vulnerability and severity, equation includes multiple variables for calculation of likelihood, ¶s15,48)
and at least two input parameters used by the composite risk factor function for computing the composite risk factor score(likelihood equation includes multiple variables part of equation, ¶s15,48)
[0015] In some example embodiments, the likelihood of exploitation and the exposure factor are combined into a severity score that allows ranking of the one or more vulnerabilities, the severity score is defined as s(v)=ρ(v).Math.ef(v), the quality score is defined as Q(r)=e.sup.−γ.Math.δ(r), and the ideal scenario is defines as δ(r)=√{square root over (Σ.sub.i=1.sup.r(|CVE(r)|−1).sup.2/r)},
where v is a vulnerability, ρ(v) is a likelihood of exploitation of the vulnerability, and ef(v) is an exposure factor of the exploitation of the vulnerability, γ is a tunable parameter and r is a rank, CVE denotes Common Vulnerability Exposures. In some example embodiments, the performing a prioritized remediation of a target vulnerability includes: prioritizing remediation of the one or more vulnerabilities based on the resources available for remediation and current needs of the distributed system; and determining the target vulnerability that poses a greatest risk to the distributed system. In some example embodiments, the types of potential attackers comprises attackers who are aware of only the CVSS scores, attackers who have access to a system component associated with the one or more vulnerabilities, and attackers who can perform reconnaissance on the distributed system and discover unpatched vulnerabilities.
[0048] Susceptibility of a vulnerability to becoming an exploitation target by malicious actors depends on a number of variables, including features of the vulnerability itself and characteristics of potential attackers. Unlike the conventional security systems that confine the users with the predefined metrics with predefined notions of risks in fixed attack surfaces, the cyber security framework 100 allows numerous variables to be considered and corresponsive weights to be used in situations involving different types of attackers, e.g., without limitations, ranging from attackers who are only aware of vulnerability's CVSS scores to adversaries that can perform reconnaissance on target systems and discover unpatched vulnerabilities. The cyber security framework 200 allows for the user to assess security risks using any variables that may affect the metrics. V denotes a set of all known vulnerabilities, X.sub.l denotes a set of variables that influence the likelihood (ρ(v)) and X.sub.e denotes a set of variables that influence the exposure factor (ef(v)). X.sub.l.sup.↑ and X.sub.l.sup.↓ denote the sets of variables that respectively contribute to increasing and decreasing the likelihood (ρ(v)) as their values increase. X.sub.e.sup.↑ and X.sub.e.sup.↓ denote the sets of variables that respectively contribute to increasing and decreasing the exposure factor (ef(v)) as their values increase. The X.sub.l.sup.↑, X.sub.l.sup.↓, X.sub.e.sup.↑ and X.sub.e.sup.↓ are defined by Equations 10-13, respectively, as follows:
receiving, by the TVMSS, a set of one or more inputs to the TVMSS; for each individual risk factor in the set of individual risk factors, computing, by the TVMSS, the individual risk factor score using the individual risk factor function associated with the individual risk factor, wherein the one or more input parameters used by the individual risk factor function include at least one first input from the set of one or more inputs to the TVMSS( calculation of composite score is based upon individual cvss severity equation varaiables( ie inputs) in combination with composite equation such a likeliness equation with variables(i.e. inputs), ¶22,59)
for each composite risk factor in the set of composite risk factors, computing, by the TVMSS, the composite risk factor score using the composite risk factor function associated with the composite risk factor(composite score such as exploitability score, impact score, likeliness score are calculated from respective equation from metrics values, metric values are inputted into the variables of the equations)
[0042] Importantly, since all the submetrics involved in their computation can assume one of only a few discrete values, the Impact and Exploitability scores will also have one of a limited number of discrete values. Thus, ranking thousands of vulnerabilities based on their CVSS scores is impractical. Further, as discussed with reference to the metrics customizer 240, while the cyber security framework 200 utilizes the CVSS Exploitability and Impact scores for determining the vulnerability scores, the cyber security framework 200 also allows the user to use any other cyber environmental variables and/or metrics (if defined by the user) as additional variables deemed appropriate for determining the vulnerability scores.
[0022] As shown in Table 6 of FIG. 4, the quality of the resulting ranking starts to improve as the combined effect of multiple variables allows to better discriminate between different vulnerabilities, although the ranking is still far from the ideal case. The top 10 values of the severity score now involve “only” 2430 CVEs, an order of magnitude less than the previous 2 scenarios. This scenario is directly comparable to a scenario in which CVSS Base Score is used to rank vulnerabilities. Although the severity score formula used is different from the CVSS Base Score formula, both are ultimately functions of two variables that can assume only a limited number of discrete values, 27 and 10 respectively, thus limiting their ability to provide a useful ranking of vulnerabilities.
[0059] In operation, the data ingestion device 210 receives security data from information sources. Based on the security data, the standard ranking device 222 provides standard security weakness rankings using standard metrics at predefined periodic intervals. In some example embodiments, the data ingestion device 210 may trigger the ranking device 220 to provide the rankings upon receipt of the security data. The user reviews the standard rankings and determines that one or more vulnerabilities exist in one or more system components of the distributed system 100. In some example embodiments, the cyber security framework 200 may determine that one or more vulnerabilities exist in one or more system components of the distributed system 100 based on the security data and the standard rankings and alert the user about the discovered one or more vulnerabilities. The user reviews the one or more vulnerabilities and customizes metrics for calculating a likelihood of exploitation of each vulnerability and an exposure factor associated with an exploited vulnerability by selecting variables based on a specific applicative domain of each vulnerability, resources and priorities of the distributed system 100 being protected and types of potential attackers. The cyber security framework 200 receives a user request for a customized ranking of the one or more vulnerabilities based on the customized metrics. The custom ranking device 224 receives the user request and triggers the metrics calculator 230 to calculate the customized metrics based on the one or more variables. The metrics calculator 230 calculates the customized metrics using the one or more variables, severity scores for the one or more vulnerabilities, customized ranks for the one or more vulnerabilities, and respective quality scores of the customized ranks. The custom ranking device 224 provides the customized ranking 225 via the graphical user interface 202. In some example embodiments, the custom ranking device 224 may provide the user the customized ranking 225 as well as at least one of respective vulnerability scores, a number of vulnerabilities sharing each vulnerability scores, cumulative number of vulnerabilities in each ranking, deviation of each rank from the ideal scenario or a quality score for each ranking. The user then reviews the customized ranking 225 and determines a target vulnerability that poses a greatest risk to the distributed system 100 being protected based on priorities and resources of the distributed system 100. The user then provides a user command to the cyber security system 200 to perform remediation of the target vulnerability. The target security risk remediation device 250 then performs the remediation of the target vulnerability.
It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to modify Mankovskii with the functions(i.e. equations) for calculating individual and composite risk factors as taught by Albanese. The reason for this modification would be to implement known methods for calculating network security risk provide an accurate assessment of security risk by incorporating multiple factors of risk.
Regarding claim 2, Albanese teaches wherein computing, for each composite risk factor in the set of composite risk factors, the composite risk factor score using the composite risk factor function associated with the composite risk factor comprises: for a first composite risk factor in the set of composite risk factors, using a first composite risk factor function associated with the first composite risk factor to compute a first composite risk factor score for the first composite risk factor, wherein using the first composite risk factor function comprises using at least two individual risk factor scores(composite factors are mapped to individual CVE values, ¶s38.43).
[0038] While FIG. 2 shows the data ingestion device 210 receiving the security data related to only the IDS rules, NVD and vulnerability scan data 308, that is for illustrative purposes only, and thus any other security data that a user deems appropriate may be obtained and/or utilized in determining security weaknesses and preforming prioritized remediation of the security weaknesses. As such, unlike the existing scoring approaches that require vulnerability assessment based on a predefined set of metrics (e.g., without limitation, Modified Attack Vector (MAV), Modified Privileges Required (MPR)), the cyber security framework 200 allows a user (e.g., without limitations, an administrator, security engineer, security personnel of the cyber security framework 200) to utilize any publicly or otherwise readily available security data that can be mapped to individual CVEs (e.g., without limitation, IDS rules, exploits) with minimal user effort. This in turn allows the user to include new and additional variables to be used in calculation of metrics including, e.g., without limitation, a likelihood (ρ(v)) of vulnerability exploitation and an exposure factor (ef(v)) of a system component to a vulnerability, thereby enabling the user to customize the metrics, refine vulnerability rankings and prioritize the vulnerabilities discovered based on the specific needs and resources of the distributed system 100.
[0043] As previously noted, CWE is a catalogue of weaknesses associated with software, hardware, etc. While a software weakness is not necessarily a vulnerability, but may become a vulnerability. MITRE provides Common Weakness Scoring System (CWSS), a mechanism for prioritizing software weaknesses that are present within software applications. The CWSS is organized into three metric groups: Base Finding, Attack Surface, and Environmental groups. Each group includes a plurality of metrics, also known as factors, that are used to compute a CWSS score for a weakness. Each CVE can be mapped to one or more CWE entries and each CWE entry may encompass numerous (sometimes hundreds) different vulnerabilities. The purpose of classifying CVEs into CWE is to provide an easy way to identify specific types of weaknesses and also understand the nature of vulnerabilities. A set of CVEs mapped to each CWE can be defined as follows:
Regarding claim 3, Albanese teaches wherein: the at least two individual risk factor scores include a first individual risk factor score and a second individual risk factor score; and the first composite risk factor function includes a first weight associated with the first individual risk factor score and a second weight associated with the second individual risk factor score, wherein the first weight controls a contribution of the first individual risk factor score to the computation of the first composite risk factor score and the second weight controls a contribution of the second individual risk factor score to the computation of the first composite risk factor score(computation of various factor includes weights of respective factors, ¶48)
[0048] Susceptibility of a vulnerability to becoming an exploitation target by malicious actors depends on a number of variables, including features of the vulnerability itself and characteristics of potential attackers. Unlike the conventional security systems that confine the users with the predefined metrics with predefined notions of risks in fixed attack surfaces, the cyber security framework 100 allows numerous variables to be considered and corresponsive weights to be used in situations involving different types of attackers, e.g., without limitations, ranging from attackers who are only aware of vulnerability's CVSS scores to adversaries that can perform reconnaissance on target systems and discover unpatched vulnerabilities. The cyber security framework 200 allows for the user to assess security risks using any variables that may affect the metrics. V denotes a set of all known vulnerabilities, X.sub.l denotes a set of variables that influence the likelihood (ρ(v)) and X.sub.e denotes a set of variables that influence the exposure factor (ef(v)). X.sub.l.sup.↑ and X.sub.l.sup.↓ denote the sets of variables that respectively contribute to increasing and decreasing the likelihood (ρ(v)) as their values increase. X.sub.e.sup.↑ and X.sub.e.sup.↓ denote the sets of variables that respectively contribute to increasing and decreasing the exposure factor (ef(v)) as their values increase. The X.sub.l.sup.↑, X.sub.l.sup.↓, X.sub.e.sup.↑ and X.sub.e.sup.↓ are defined by Equations 10-13, respectively, as follows:
Regarding claim 4, Albanese teaches wherein computing, for each composite risk factor in the set of composite risk factors, the composite risk factor score using the composite risk factor function associated with the composite risk factor comprises: for a first composite risk factor in the set of composite risk factors, using a first composite risk factor function associated with the first composite risk factor to compute a first composite risk factor score for the first composite risk factor, wherein using the first composite risk factor function comprises using at least two other composite risk factor scores computed for at least two other composite risk factors(vulnerability based on likelihood and exposure factor, ¶s 9, 10).
[0009] These needs, and others, are met by a method of performing prioritized remediation of security weaknesses in a distributed system. The method includes: obtaining cyber security data including at least vulnerability data and intrusion detection system (IDS) rules; outputting a standard security weakness ranking based on the cyber security data; determining that one or more vulnerabilities exist in one or more system components of the distributed system based on the standard security weakness ranking; customizing metrics for calculating a likelihood of exploitation of each vulnerability and an exposure factor associated with exploitation of each vulnerability based on a user input including at least one variable for use in the calculation, the at least one variable influencing the likelihood of exploitation or the exposure factor and capturing specific applicative domain of each vulnerability, priorities of the distributed system and/or types of potential attackers; calculating the customized metrics; outputting a customized ranking of the one or more vulnerabilities based on the calculated customized metrics; and performing a prioritized remediation of a target vulnerability selected by the user from the one or more vulnerabilities based on the customized ranking and specific needs and resources of the distributed system.
[0010] In some example embodiments, the at least one variable belongs to a first set X.sub.l.sup.↑ of variables that contribute to increasing the likelihood of exploitation as the value of the first set increases, a second set X.sub.l.sup.↓ that contribute to decreasing the likelihood of exploitation as the value of the second set increases, a third set X.sub.e.sup.↑ that contribute to increasing the exposure factor as the value of the third set increases, and a fourth set X.sub.e.sup.↓ that contribute to decreasing the exposure factor as the value of the fourth set increases. In some example embodiments, the first set, the second set, the third set and the fourth set of variables are defined, respectively, as follows:
Regarding claim 5, Albanese teaches The method of claim 4, wherein: the at least two composite risk factor scores include a second composite risk factor score and a third composite risk factor score; and the first composite risk factor function includes a first weight associated with the second composite risk factor score and a second weight associated with the third composite risk factor score, wherein the first weight controls a contribution of the second composite risk factor score to the computation of the first composite risk factor score and the second weight controls a contribution of the third composite risk factor score to the computation of the first composite risk factor score(composite factors such a likelihood and exposure are defined by equations with weighted variables, variables, ¶48)
[0048] Susceptibility of a vulnerability to becoming an exploitation target by malicious actors depends on a number of variables, including features of the vulnerability itself and characteristics of potential attackers. Unlike the conventional security systems that confine the users with the predefined metrics with predefined notions of risks in fixed attack surfaces, the cyber security framework 100 allows numerous variables to be considered and corresponsive weights to be used in situations involving different types of attackers, e.g., without limitations, ranging from attackers who are only aware of vulnerability's CVSS scores to adversaries that can perform reconnaissance on target systems and discover unpatched vulnerabilities. The cyber security framework 200 allows for the user to assess security risks using any variables that may affect the metrics. V denotes a set of all known vulnerabilities, X.sub.l denotes a set of variables that influence the likelihood (ρ(v)) and X.sub.e denotes a set of variables that influence the exposure factor (ef(v)). X.sub.l.sup.↑ and X.sub.l.sup.↓ denote the sets of variables that respectively contribute to increasing and decreasing the likelihood (ρ(v)) as their values increase. X.sub.e.sup.↑ and X.sub.e.sup.↓ denote the sets of variables that respectively contribute to increasing and decreasing the exposure factor (ef(v)) as their values increase. The X.sub.l.sup.↑, X.sub.l.sup.↓, X.sub.e.sup.↑ and X.sub.e.sup.↓ are defined by Equations 10-13, respectively, as follows:
Regarding claim 6, Mankovskii teaches wherein: the at least two composite risk factor scores include a first composite risk factor score and a second composite risk factor score; and the final composite function includes a first weight associated with the first composite risk factor score and a second weight associated with the second composite risk factor score, wherein the first weight controls a contribution of the first composite risk factor score to the computation of the overall risk score and the second weight controls a contribution of the second composite risk factor score to the computation of the overall risk score( different categories of security risk can be combined using weightings for each category to calculate the overall score, ¶30)
[0030] A security exposure calculator 122 can, for example, calculate a value indicative of the probability of various types of security-related exposures associated with a particular network communication with a service provider or a particular URI or site. Different security exposures can include, for example, probability of data exposure, probability of virus attack, and probability of a phishing attack. For example, using gmail as the enterprise mail system or storing data in cloud storage inherently include a risk of data exposure. Based on the reputation of a URI or known data leaks in the past, the security exposure calculator 122 can assign an initial probability value, or adjust a probability value, (e.g., a value between 0 and 1) that a data communication with a particular endpoint has a data exposure risk. The security exposure calculator 122 can also assign a similar probability value for each of the risk of a virus attack and the risk of a phishing attack. Again, the initial value may be based on an external data source such as AVG Threat Labs or, for example, by collecting sentiments about a company or service through social media analytics, and then adjusted based on past experience and activity captured by the enterprise's traffic monitoring system 108. Each of the three different security exposure risks can be treated separately or can be combined into a single security exposure value. For example, the three values could be averaged together but that might “hide” a very serious data exposure risk if the risks of a virus attack and phishing attack are very low. Thus, another way to compute a security exposure risk value is to assign it to be the highest value of the three separate component values. There can also be a “weighting” system utilized with the three (or more) separate components where a respective weight can be assigned for each component or assigned to the internal elements that are part of calculating a component. For example, if a system being monitored only reads information, then a virus attack would have a higher relative importance than a phishing attack because that system only reads and does not respond to requests. Accordingly, a risk associated with a phishing attack could be weighted to reduce its effect on the overall score being viewed as a high risk and a risk associated with a virus attack could be weighted to increase its effect on the overall score being viewed as a high risk.
Claims 7-10 are rejected under 35 U.S.C. 103 as being unpatentable over Mankovskii/Albanese as applied to claim 1 above, and further in view of Derevyanik US 2024/0362324.
Regarding claim 7 the combination of Mankovskii teaches calculating a overall risk score but does not a threshold with respect to the overall risk score. Thus, Mankovskii/Albanese do not teach determining a responsive action based upon the overall risk score exceeding a predetermined threshold. Derevyanik in the same field of endeavor as the invention teaches a system for security event detection. Derevyanik teaches calculating a overall risk score but does not a threshold with respect to the overall risk score.
[0025] The present application describes an RBA system that aggregates security events, and creates an alert narrative based on quantitative reasoning. RBA takes the aggregated security events, adds up the cumulative risk, and triggers an alert when the cumulative risk score surpasses a preset threshold. This can be done over several different time periods, including, but not limited to, 24 hours, seven days, or one month.
It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to modify Mankovskii/Albanese with thresholds that trigger notification actions as taught by Derevyanik. The reason for this modification would be to provide triggers for the overall risk score notifications of Mankoivskii.
Regarding claim 8, Mankovskii/Albanese does not teach wherein the receiving, the computing for each individual risk factor in the set of individual risk factors, the computing for each composite risk factor in the set of composite risk factors, and the computing of the overall risk score are performed periodically or in response to receiving information about a finding. Derevyanik in the same field of endeavor as the invention teaches a system for security event detection. Derevyanik teaches wherein the receiving, the computing for each individual risk factor in the set of individual risk factors, the computing for each composite risk factor in the set of composite risk factors, and the computing of the overall risk score are performed periodically or in response to receiving information about a finding(risk calculation can be triggered or run periodically, ¶188).
[0188] In one example, the risk-based alerting mechanism 804 operates as follows: every alert is a risk builder and in events of atomic detection, the detection threshold will surpass immediately off the trigger of one atomic detection (e.g., critical alerts=100). Otherwise, the risk-based alerting mechanism 804 looks for any breach of risk threshold. The risk-based alerting mechanism 804 can run every 15 minutes and will take the sum of the risk scores over the risk data model time period and trigger an event.
It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to modify Mankovskii/Albanese with thresholds that performs period risk evaluations as taught by Derevyanik. The reason for this modification would be to provide frequent detection and notification of security risks.
Regarding claim 9, Derevyanik teaches receiving a request to compute an aggregate risk score for a first time period for the first computing environment; identifying a plurality of overall risk scores computed for the first computing environment within the first time period, wherein the plurality of overall risk scores includes the overall risk score computed for the first computing environment; and computing the aggregate risk score based upon the identified plurality of overall risk scores(overall risk score(i.e. aggregate score) calculated with respect to a time interval, ¶s187,188).
[0187] The risk-based alerting mechanism 804 utilizes the above building blocks and accumulates risk score for each entity for a set amount of time (e.g., 24 hours), for each detection that is triggered for said entity. If the aggregated risk score is greater than the risk threshold then an alert is triggered. This risk aggregation will be stored in a risk data model, and risk scoring will be reset upon triaging of alerting.
[0188] In one example, the risk-based alerting mechanism 804 operates as follows: every alert is a risk builder and in events of atomic detection, the detection threshold will surpass immediately off the trigger of one atomic detection (e.g., critical alerts=100). Otherwise, the risk-based alerting mechanism 804 looks for any breach of risk threshold. The risk-based alerting mechanism 804 can run every 15 minutes and will take the sum of the risk scores over the risk data model time period and trigger an event.
Regarding claim 10, Mankovskii/Albanese do not teach receiving a request to compute an aggregate risk score for a particular computing environment; determining that the particular computing environment includes a plurality of computing environments, the plurality of computing environments including the first computing environment; identifying a plurality of overall risk scores computed for the plurality of computing environments; and computing the aggregate risk score for the particular computing environment based upon the plurality of overall risk scores. Derevyanik in the same field of endeavor as the invention teaches a system for security event detection. Derevyanik teaches receiving a request to compute an aggregate risk score for a particular computing environment; determining that the particular computing environment includes a plurality of computing environments, the plurality of computing environments including the first computing environment; identifying a plurality of overall risk scores computed for the plurality of computing environments; and computing the aggregate risk score for the particular computing environment based upon the plurality of overall risk scores(aggregate/total risk score calculated in different environments, ¶s 172,187).
[0172] In one example, the identity prioritization algorithm 604 first computes a total risk score based on the following parameter scalar values: the sum of the identity's risk score from the different environments with respect the maximum risk score: sum_risk_score=Σ(privilege*environment scalars), the probability of being an inactive employee if terminated, the probability of being a contract employee if on a contract, the probability of being a high profile employee if an executive. An example algorithm of the identity prioritization algorithm 604 is:
[0187] The risk-based alerting mechanism 804 utilizes the above building blocks and accumulates risk score for each entity for a set amount of time (e.g., 24 hours), for each detection that is triggered for said entity. If the aggregated risk score is greater than the risk threshold then an alert is triggered. This risk aggregation will be stored in a risk data model, and risk scoring will be reset upon triaging of alerting.
It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to modify Mankovskii/Albanese with thresholds that performs risk calculation in different environments as taught by Derevyanik. The reason for this modification would be to provide risk detection and notification that is comprehensive to function over different computing environments.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Mankovskii/Albanese/Derevyanik as applied to claim 10 above, and further in view of Bonfield 2025/0358307.
Regarding claim 11, Mankovskii/Albanese/Derevyanik do not teach wherein computing the aggregate risk score comprises: using a log weighted average of the plurality of overall risk scores for computing the aggregate risk score; and each term of the log weighted average includes a weight that increases exponentially in proportion to each respective overall risk score of the one or more overall risk scores. Bonfield in the same field of endeavor as the invention teaches a system for vulnerability risk scoring. Bonfield teaches wherein computing the aggregate risk score comprises: using a log weighted average of the plurality of overall risk scores for computing the aggregate risk score; and each term of the log weighted average includes a weight that increases exponentially in proportion to each respective overall risk score of the one or more overall risk scores.
[0081] The second level of risk in the proposed risk methodology consists of a host risk score (HRS). HRS may be calculated by aggregating vulnerability risk scores for all vulnerabilities detected on the host, layering on additional contextual information as available. The contextualized risk posed by a vulnerability to a host contained therein may be estimated by a vulnerability risk score (VRS). In embodiments, the VRS may be a combination of components and/or weights relevant for contextualizing risk from a vulnerability, such as a linear combination, non-linear combination, logarithmic combination, exponential combination, or other form of combination or any combination thereof.
It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to modify Mankovskii/Albanese/Derevyanik with exponentially weighted average function as taught Bonfield . The reason for this modification would be to implement a risk score calculation function using known math function such a exponentially weight averages
Claims 12-13, 15-16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mankovskii/Albanese as applied to claim 1 above, and further in view of Akella US 2021/0336982.
Regarding claim 12, Mankovskii/Albanese do not teach at least one second input of the set of one or more inputs corresponds to a finding; and computing the overall risk score comprises computing the overall risk score as a product of a first composite risk factor score and a second composite risk factor score, wherein: the first composite risk factor score is computed using a first composite risk factor function; the second composite risk factor score is computed using a second composite risk factor function; the first composite risk factor function comprises a first sum of a first nested composite risk factor score controlled by a first weight and a second nested composite risk factor score controlled by a second weight, wherein: the first nested composite risk factor score is based on a likelihood of the finding; and the second nested composite risk factor score is based on an impact of the finding; and the second composite risk factor function evaluates to 0 if the severity of the finding is 0 and 1 otherwise.
Akella in the same field of endeavor as the invention teaches a system for assessing risk in computing networks. Akella teaches at least one second input of the set of one or more inputs corresponds to a finding; and computing the overall risk score comprises computing the overall risk score as a product of a first composite risk factor score and a second composite risk factor score, wherein: the first composite risk factor score is computed using a first composite risk factor function; the second composite risk factor score is computed using a second composite risk factor function; the first composite risk factor function comprises a first sum of a first nested composite risk factor score controlled by a first weight and a second nested composite risk factor score controlled by a second weight, wherein: the first nested composite risk factor score is based on a likelihood of the finding; and the second nested composite risk factor score is based on an impact of the finding; and the second composite risk factor function evaluates to 0 if the severity of the finding is 0 and 1 otherwise.(risk computed as product of likelihood impact and severity, where weighted severity and impact includes impact subscores, ¶142-148)
[0142] Given n threat risk scores, overall risk score is calculated as:
total risk=(overall likelihood)×(overall severity)×(overall impact)
[0143] where each component is calculated as follows:
overall severity=max({severity.sub.1,severity.sub.2, . . . })
overall impact=mean({impact.sub.1,impact.sub.2, . . . })
overall likelihood=1−Π1−likelihood.sub.i
[0144] The above description of risk calculation may be applied to one or more interfaces associated with a computing device. When a computing device has several interfaces, threat risks from different interfaces may be combined to compute device level scores.
[0145] When a threat i exists for two interfaces in the same computing device, a combined risk of that threat is calculated as follows. A combined likelihood is calculated using an overall average daily occurrence:
[0146] A weighted severity is calculated as:
[00005]weightedseverityi:wsi=.Math.severityke-f(agek)+.Math.severityk′e-f(agek′).Math.e-f(agek)+.Math.e-f(agek′)
[0147] An associated impact either remains the same, or is recalculated based on a device hyper context. Then,
risk.sub.i=(likelihood.sub.i)(weightedseverity.sub.i)(impact.sub.i)
It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to modify Mankovskii/Albanese with overall risk score calculation that is a product of likeliness, impact and severity factors. The reason for this modification would be a simple substitution of a risk score with multiple factors(likelihood, severity…) as taught by Albanese with specific product based function as taught by Akella to achieve known result of an proper risk calculation
Regarding claim 13, Albanese further teaches wherein: at least one second input of the set of one or more inputs corresponds includes the Common Vulnerability Scoring System (CVSS) value of the finding or the Common Weakness Scoring System (CWSS) value of the finding; and the severity of the finding is based on the CVSS value of the finding or the CWSS value of the finding(severity based on cvss(common vulnerability) and cwe(common weakness) ¶6).
[0006] For example, MITRE and OWASP (Open Web Application Security Project) provide periodic rankings of software weaknesses and software vulnerability scoring systems. However, the rankings offer limited solutions because they abstract the details of individual vulnerabilities and reason for the vulnerabilities in terms of weaknesses, but provide only generic rankings that are not useful to understand the security posture of a specific system. For vulnerabilities, topological vulnerability analysis and numerous scoring and ranking systems have been developed, including multi-layer graph approaches to configuration analysis and optimization using vulnerability graphs and various scanning tools to identify the specific vulnerabilities that exist in each component of a distributed system. However, they do not aggregate the information at a higher level of abstraction, rendering it difficult for a security analyst to derive actionable intelligence from voluminous scanning reports. For example, the Common Vulnerability Scoring System (CVSS) often returns the same severity score and rank for a plurality of vulnerabilities, leaving the security personnel unable to differentiate severities between those vulnerabilities. Further, the rankings of common weaknesses are based on knowledge about all known vulnerabilities rather than the specific vulnerabilities that exist in the system being evaluated, resulting in overestimating or underestimating the true severity of the weaknesses. Furthermore, the scoring systems rely on predefined notions of risk and use fixed equations to compute numerical scores, and thus do not provide users with the flexibility to fine-tune such equations or consider new variables. For example, susceptibility of a vulnerability to becoming a target for exploitation by malicious users depends on a number of variables including features of the vulnerability itself and characteristics of potential attackers. Many of the existing approaches have focused on intrinsic features of vulnerabilities, but not extrinsic features such as the types, skills, and resources available to the potential attackers. As such, these approaches focus on scoring and comparing vulnerabilities for a fixed attack surface or model based on fixed equations and predefined security risks, thereby failing to provide a user the ability to modify or adjust the vulnerability assessment in accordance with the specific needs of the distributed system being protected.
[0020] In some example embodiments, the system further includes plugins structured to interface with an individual virtual scanner and Application Programming Interfaces structured to interface with third party applications. In some example embodiments, the data ingestion device is further structured to generate and/or ingest vulnerability scanning reports, and the metrics further comprises a common weaknesses score as defined as S(CWE.sub.i)=Σ.sub.vEC(CWE.sub.i.sub.)|I(v)|.Math.ρ(v).Math.ef(v), where v is a vulnerability, I(v) is a set of instances of the vulnerability v within the system, CWE.sub.i is a Common Weakness Enumeration weakness, C(CWE.sub.i) is a set of common vulnerabilities and explores (CVEs) mapped to CWE.sub.i, ρ(v) is the likelihood of exploitation of the vulnerability v and ef(v) is the exposure factor of the vulnerability v. In some example embodiments, the prioritized remediation of a target vulnerability is based at least in part on a prioritization of remediations of the one or more vulnerabilities based on the resources available for remediation and current needs of the distributed system and a determination that the target vulnerability that poses a greatest risk to the distributed system.
Regarding claim 15 Albanese teaches wherein the first nested composite risk factor score comprises a second sum of a third nested composite risk factor score controlled by a third weight and a fourth nested composite risk factor score controlled by a fourth weight divided by a third sum of the third weight and the fourth weight, wherein the third nested composite risk factor score is based on an exposure of the finding and the fourth nested composite risk factor score is based on an exploit probability of the finding(exposure based on probability of exploit, ¶s68,79).
[0068] One embodiment identifies a set of variables that represent relevant factors influencing an attacker's decision to exploit a given vulnerability. The set of variables can include and are not limited to a vulnerability's exploitability score (determined by a Common Vulnerability Scoring System (CVSS)); an amount of time elapsed since information about the vulnerability became public; and a number of known Intrusion Detection system (IDS) rules associated with the vulnerability.
where I denotes Impact scores which is defined in equation (2); E denotes exploitability scores defined in equation (3); and the function ƒ(I) is defined in equation (4). The impact score, I, quantifies the consequences of an exploit and the exploitability score indicates the ease with which a vulnerability can be exploited. The terms I.sub.C, I.sub.I, and I.sub.A in equation (2) represent confidentiality, integrity, and availability impact scores, respectively. The terms AC, A, and AV in equation (3) represent different exploitability metrics, namely, access complexity (AC), authentication (A), and access vector (AV), respectively.
[0079] FIG. 5 shows an exemplary portion of a SCIBORG multi-layer graph model illustrating likely attack paths, in accordance with an embodiment of the present application. The example shown in FIG. 5, illustrates possible multi-step attack paths taken by an attacker. For example, the enables edge 506 can indicate that the attacker may exploit a vulnerability, u (502), associated with a node 504 in the configuration subgraph of the multi-layer graph. Next, for each node in the vulnerability subgraph 508, the system can compute a probability distribution over outgoing enables edges, i.e., edges 510 and 512, from node 502. Each node in vulnerability subgraph 508 can be associated with an exploitation likelihood defined in equation (5). Further, the vulnerability likelihood at each node, i.e., defined by equation (5), includes the relevant variables that can influence the attacker's choice of vulnerabilities to exploit. Based on the vulnerability likelihood, the system can determine a probability label for corresponding enables edges. Specifically, the system may first normalize the likelihood values of enabled vulnerabilities and apply the normalized values to label the corresponding enables edges, i.e., edges 510 and 512. For example, given an enables edge 512 (which can be represented by e.sub.u.fwdarw.v=(u,v)), the probability of exploiting v (516) after u (502) has been exploited can be defined as
Regarding claim 16, Albanese teaches wherein: the third nested composite risk factor score based on the exposure of the finding comprises a fourth sum of a first individual risk factor score controlled by a first individual risk factor weight and a second individual risk factor score controlled by a second individual risk factor weight divided by a fifth sum of the first individual risk factor weight and the second individual risk factor weight, wherein the first individual risk factor score is based on the severity of the finding and the second individual risk factor score is based on a frequency of the finding; and the frequency of the finding is a quotient of a number of services in the first computing environment having a same finding and a total number of services in the first computing environment.
[0015] In some example embodiments, the likelihood of exploitation and the exposure factor are combined into a severity score that allows ranking of the one or more vulnerabilities, the severity score is defined as s(v)=ρ(v).Math.ef(v), the quality score is defined as Q(r)=e.sup.−γ.Math.δ(r), and the ideal scenario is defines as δ(r)=√{square root over (Σ.sub.i=1.sup.r(|CVE(r)|−1).sup.2/r)},
Regarding claim 18, Albanese teaches wherein: one or more inputs of the plurality of inputs correspond to a finding; and the final composite function is given by: Risk=fLikelihood⋅WL+fImpact⋅WI⋅fBooleanSeverity wherein: fLikelihood is a first composite risk factor score computed using a first composite risk factor function based on at least two composite risk factor scores, given by fExposure and fThreat; WL is a first weight that controls a first contribution of the first composite risk factor score; fImpact is a second composite risk factor score based on an impact of the finding; WI is a second weight that controls a second contribution of the second composite risk factor score; and fBooleanSeverity is a third composite risk factor score that can assume one of two possible values based on the severity of the finding(¶s 12 , 13, 40, 42 54).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Mankovskii/Albanese/Akella as applied to claim12 above, and further in view of Bogren US 2022/0232031.
Regarding claim 14, Mankovskii/Albanese/Akella do not teach wherein the second nested composite risk factor score based on the impact of the finding is computed using a second nested composite risk factor function that evaluates to a number determined according to a service tier associated with the finding. Bogren in the same field of endeavor as the invention teaches a system for cybersecurity risk evaluation. Bogren teaches wherein the second nested composite risk factor score based on the impact of the finding is computed using a second nested composite risk factor function that evaluates to a number determined according to a service tier associated with the finding(risk evaluation performed on multiple different service levels, ¶22).
[0022] Partner systems 150 may include one or more networks and/or network devices that collect data about individual enterprise networks 115. Partner systems 150 may provide the collected data to risk assessment system 130. According to an implementation, partner systems 150 may work with risk assessment system 130 to provide data for different service levels. According to one implementation, the service levels may build on each other. For example, an entry level (e.g., level 1) may provide an outside-in view that gathers data about a customer enterprise network 115 from public sources. A middle level (e.g., level 2) may additionally provide an inside-out view that searches internally (e.g., within enterprise network 115) for malware, unwanted programs, and dual usage tools within endpoints. A highest level (e.g., level 3) may further include an in-depth review of the security culture and processes (C&P) for the customer enterprise network 115. For example, C&P data may be collected based on user surveys and direct customer inquiries. According to another implementation, the service levels may be independent of each other (e.g., level 3 data may not build on level 2 data). In FIG. 1, three partner systems 150 are shown for simplicity. In practice, there may be more or fewer partner systems 150. In some implementations, one or all of partner systems 150 may be provided by or serviced by provider network 125.
It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to modify Mankovskii/Albanese/Akella with risk assessment according to differing service levels as taught by Bogren. The reason for this modification would be to provide risk assessment that is customized for different service levels.
Claims 17 is rejected under 35 U.S.C. 103 as being unpatentable over Mankovskii/Albanese/Akella as applied to claim15 above, and further in view of Roytman US 2024/0330481.
Regarding claim 17, Mankovskii/Albanese/Akella does not teach wherein the fourth nested composite risk factor score based on the exploit probability of the finding is determined based on a predicted exploit probability of the finding based on the Exploit Prediction Scoring System (EPSS). Roytman in the same field of endeavor as the invention teaches a system for threat intelligence. Roytman teaches wherein the fourth nested composite risk factor score based on the exploit probability of the finding is determined based on a predicted exploit probability of the finding based on the Exploit Prediction Scoring System (EPSS).
[0056] Generally, the threat intelligence 102 can include publicly available information regarding a vulnerability, such as a CVE description, vulnerability reports, and, when available, publicly available scores from service providers (e.g., scores for managed security service providers (MSSPs), such as the exploit prediction scoring system (EPSS). Additionally or alternatively, the threat intelligence 102 can include telemetry of one or more attacks on the vulnerability and source code or assembly code (e.g., source code of for the vulnerability and assembly code of the exploit from the one or more attacks).
It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to modify Mankovskii/Albanese/Akella with a EPSS system as taught by Roytman. The reason for this modification would be to implement a known equivalent of the system of Mankovskii that requires simple substitution with a know EPSS system that leads to predictable results.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise, can be reached on (571)272-3865. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2455
Prosecution Insights