Systems, methods, and storage media that compute a frequency of network risk loss within a computing system

Abstract

Systems, methods, and storage media for determining the probability of network risk-related losses within a computing system comprised of one or more computing elements are disclosed. Exemplary implementations may: assess vulnerability by determining an exposure window of the computing element based on the number of discrete times within a given time frame in which the computing element is vulnerable; determine the frequency of contact between the computing element and threat actors; normalize the exposure window and the contact frequency; calculate the frequency of loss events by dividing the normalized exposure window by the normalized contact frequency; and repeat these steps for multiple elements. When combined with liability data implied by the magnitude of losses describing these events, organizations can prioritize elements based on loss exposure and take action to prevent loss exposure.

Description

Technical Field

[0001] This disclosure relates to systems, methods, and storage media for calculating the frequency of network risk-related losses within a computing system consisting of one or more computing elements referred to herein as “assets”. Background Technology

[0002] The cyber risk environment is complex and dynamic, and the resources available for managing it are limited. An inevitable implication is that organizations must prioritize the many cyber-related risks they face in order to address them pragmatically. Once prioritization is established, organizations can estimate and compare the cost-benefit claims of many available risk mitigation options. The first step in prioritization requires measuring the frequency of cyber-related loss events.

[0003] For example, suppose an enterprise may have one thousand assets within its cybersecurity environment, and the vulnerabilities of these systems are likely to be estimated daily using common scanning techniques (such as QUALYS™). Assets can be computing systems, applications, computing environments, or computing devices. Furthermore, suppose QUALYS reports a total of 3,457 vulnerabilities in these assets on a given day, and one-third of those vulnerabilities are rated as critical or very high using a scoring system called the Common Vulnerability Scoring System (CVSS) or some derivative thereof.

[0004] CVSS is a known mechanism for generating numerical scores that reflect the severity of vulnerabilities. These numerical scores can then be transformed into qualitative representations such as low, medium, high, and severe. However, known CVSS models are inaccurate (e.g., they ignore the frequency side of the risk equation, they use complex mathematics on ordinal scales, etc.), meaning these tools are unreliable for determining the frequency of losses from these events. Without the ability to prioritize mitigation attempts based on frequency, the enterprise in this example would be forced to attempt to fix more than a thousand vulnerability conditions. Addressing so many vulnerabilities in a timely manner is impractical, especially given the highly dynamic nature of the cybersecurity threat environment.

[0005] Because empirical data related to loss event frequency (LEF) is typically scarce and difficult to obtain for most network-related loss events, analysts must estimate the frequency based on a manual decomposition of underlying factors. This estimation can then be applied within the Information Risk Factors Analysis (FAIR) model, a common ontology and methodology for quantifying and managing network risk from a financial perspective.

[0006] When using the FAIR model, determining LEF reduces to estimating the frequency of loss events (TEF) and vulnerability, which is further decomposed into contact frequency and probability of action (under TEF) and threat capability and difficulty (under vulnerability).Figure 1 This is a diagram of a relevant part of the FAIR ontology. However, the difficulty in reliably estimating threat capabilities and complexity reduces the reliability of some analyses. Furthermore, many organizations must prioritize hundreds or even thousands of vulnerability conditions (e.g., lack of software patches), which cannot be reasonably accomplished through manual analysis methods. Therefore, the current state of threat analysis methods, and consequently, the state of responding to cyber threats, is extremely cumbersome and inefficient. Summary of the Invention

[0007] One aspect of this disclosure relates to a system configured to prioritize network risks within one or more computing systems comprising computing elements. The system may include one or more hardware processors configured with machine-readable instructions. The processors may be configured to assess vulnerability by determining an exposure window of the computing element based on the number of discrete times within a given time frame in which the computing element is vulnerable. The processors may be configured to determine the frequency of contact between the computing element and threat actors. The processors may be configured to normalize the exposure window and the contact frequency. The processors may be configured to calculate the vulnerability exposure factor (LEF) by dividing the normalized exposure window by the normalized contact frequency. The processors may be configured to repeat the above operations for multiple elements. When combined with loss magnitude data (not part of this disclosure), the processors may be configured to prioritize the elements based on threat loss frequency, and when combined with loss magnitude data, to prioritize the elements based on loss exposure.

[0008] Another aspect of this disclosure relates to a method for prioritizing network risks within a computing system comprising one or more computing elements. The method may include assessing vulnerability by determining an exposure window of the computing element based on the number of discrete times within a given time frame in which the computing element is vulnerable. The method may include determining the frequency of contact between the computing element and threat actors. The method may include normalizing the exposure window and the contact frequency. The method may include calculating the LEF (Leakage Effect Factor) by dividing the normalized exposure window by the normalized contact frequency. The method may include repeating the above steps for multiple elements. When combined with loss magnitude data, the method may include prioritizing the elements based on the frequency of loss events.

[0009] Another aspect of this disclosure relates to a non-transitory computer-readable storage medium containing instructions executable by one or more processors to perform a method for prioritizing network risks within one or more computing systems comprised of computing elements. The method may include assessing vulnerability by determining an exposure window of the computing element based on the number of discrete times within a given time frame in which the computing element is in a vulnerable state. The method may include determining the frequency of contact between the computing element and threat actors. The method may include normalizing the exposure window and the contact frequency. The method may include calculating the LEF (Leakage Event Frequency) by dividing the normalized exposure window by the normalized contact frequency. The method may include repeating the above steps for multiple elements. When combined with loss magnitude data, the method may include prioritizing the elements based on the frequency of loss events.

[0010] These and other features and characteristics of the invention, as well as the operational methods and functions of related elements of the structure, and the combination of parts and manufacturing economies of scale, will become clearer when considered in conjunction with the accompanying drawings, all of which form part of this specification, wherein similar reference numerals denote corresponding parts in the various figures. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to be a definition of limitation of the invention. As used herein, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” include plural references. Attached Figure Description

[0011] Figure 1 This is an illustration of the FAIR itself.

[0012] Figure 2 This illustrates a system configured to prioritize network risks within one or more computing systems, according to one or more embodiments.

[0013] Figure 3 A method for prioritizing network risks within one or more computing systems is illustrated according to one or more embodiments. Detailed Implementation

[0014] A careful examination of how the threat environment operates reveals that threat actors can be categorized into two broad groups: 1) threat actors who are opportunistic and will attack any vulnerable organization, and 2) threat actors who carefully select their targets based on one or more value-related criteria. The phrase "threat environment" refers to a set of threats potentially faced by a particular computing system. Opportunistic threat actors typically search the internet for exploitable vulnerabilities (e.g., missing patches, blank passwords, etc.). Other threat actors carefully select their targets and continuously monitor and probe the attack surface of their targets (e.g., internet-facing systems, applications, end-users, etc.) until an exploitable vulnerability is identified. In both cases, no actual attack (exploitation attempt) occurs until an exploitable vulnerability is discovered.

[0015] Given this understanding, the estimated LEF can be derived from the following two parameters: 1) the frequency and duration of the vulnerability, hereinafter referred to as the "exposure window," as it represents the time window during which the threat actor exploits the vulnerability; and 2) the frequency of threat actor contact. When mathematically combined (as described below), these two values ​​can be used to obtain the probability that a threat actor will contact and exploit the vulnerability, resulting in a loss event. This provides the basis for the expected LEF.

[0016] This concept can be applied as an extension of the FAIR model, eliminating the need to use threat capability and difficulty to estimate vulnerabilities. Furthermore, the action probability branch in the FAIR model can be simplified by assuming that a threat actor (opportunistic and selective) encountering a vulnerable situation has a 100% probability of exploiting that vulnerability. In many organizations, it is common to provide cybersecurity telemetry sources for these individual parameters (exposure frequency, vulnerability frequency, and vulnerability duration). However, these values ​​are not used in the manner described in this paper to measure the LEF component of an organization's network-related loss exposure.

[0017] Some examples of this type of data source include:

[0018] Antivirus technology

[0019] Configuration management tools

[0020] Vulnerability scanning tools

[0021] Common threat-related data sources

[0022] Firewall logs

[0023] • Intrusion detection and SIEM logs

[0024] Application logs

[0025] The availability of empirical vulnerability and threat data enables data-driven and automated analysis of the LEF components exposed by network losses, improving the reliability and efficiency of network risk analysis. The disclosed embodiments provide a simpler and more reliable method for achieving LEF estimation automatically using empirical data. This, in turn, enables rapid risk-based prioritization of vulnerability states. The embodiments disclosed herein eliminate the need for independent threat estimation capabilities and complexity by simplifying the use of security telemetry.

[0026] Figure 2 A system 200 according to one or more embodiments is illustrated, configured to prioritize network risks within one or more computing systems comprised of computing elements. In some embodiments, system 200 may include one or more servers 202. Servers 202 may be configured to communicate with one or more client computing platforms 204 according to a client / server architecture and / or other architectures. Client computing platforms 204 may be configured to communicate with other client computing platforms via servers 202 and / or according to a peer-to-peer architecture and / or other architectures. Users may access system 200 via client computing platforms 204.

[0027] Server 202 can be configured by machine-readable instructions 206. Machine-readable instructions 206 may include one or more instruction modules. Instruction modules may include computer program modules. Instruction modules may include vulnerability assessment module 208, frequency determination module 210, exposure window normalization module 212, loss event frequency calculation module 214, step repetition module 220, component prioritization module 222, network risk prevention activity implementation module 224, and / or other instruction modules.

[0028] Vulnerability assessment module 208 can be configured to assess vulnerability by determining the exposure window of a computing element based on the number of discrete times within a given time frame in which the computing element is in a vulnerable state. Vulnerability assessment may include using zero-day exploitation information to determine the exposure window.

[0029] Frequency determination module 210 can be configured to determine the frequency of contact between the computing element and threat actors. Contact frequency and LEF are expressed as ranges, and calculating the frequency of loss events may include applying a stochastic process. Determining the frequency may include determining the location of the element in the threat environment (e.g., whether it is directly facing the internet or protected within an isolated subnetwork), and the data indicating the contact frequency is determined based on that location. In some embodiments, assessing vulnerability may include determining between exploitable and unexploitable vulnerable states and using only exploitable vulnerable states to determine the number of discrete times.

[0030] Exposure window normalization module 212 can be configured to normalize the exposure window and contact frequency. Exposure window normalization can be performed as part of vulnerability assessment, and contact frequency normalization can be performed as part of frequency determination. Exposure window normalization may include setting the discrete time to a day and the given time frame to a year, and contact frequency normalization is performed by determining the average contact interval time, expressed as the number of days in a year and the number of days in a year divided by the number of contacts in a year.

[0031] The step repetition module 220 can be configured to repeat the above steps for multiple computing assets. The component prioritization module 222 can be configured to prioritize assets based on loss exposure. The network risk prevention activity implementation module 224 can be configured to implement network risk prevention activities based on asset prioritization.

[0032] In some embodiments, server 202, client computing platform 204, and / or external resource 226 may be operatively linked via one or more electronic communication links. For example, such electronic communication links may be established at least partially via networks such as the Internet and / or other networks. It should be understood that this is not intended to be limiting, and the scope of this disclosure includes embodiments in which server 202, client computing platform 204, and / or external resource 226 may be operatively linked via some other communication medium.

[0033] A given client computing platform 204 may include one or more processors configured to execute computer program modules. These computer program modules may be configured to enable an expert or user associated with the given client computing platform 204 to interface with system 200 and / or external resources 226, and / or provide other functionalities applicable herein to the client computing platform 204. As a non-limiting example, a given client computing platform 204 may include a desktop computer, laptop computer, handheld computer, tablet computing platform, netbook, smartphone, game console, and / or other computing platform.

[0034] External resource 226 may include information sources outside of system 200, external entities participating in system 200, and / or other resources. In some embodiments, some or all of the functionality attributed herein to external resource 226 may be provided by resources included in system 200.

[0035] Server 202 may include electronic storage device 228, one or more processors 230 and / or other components. Server 202 may include communication lines or ports to enable information exchange with networks and / or other computing platforms. Figure 2The illustration of server 202 is not intended to be limiting. Server 202 may include multiple hardware, software, and / or firmware components that work together to provide the functionality attributed to server 202 herein. For example, server 202 may be implemented by a computing platform cloud that operates as server 202.

[0036] Electronic storage device 228 may include a non-transitory storage medium that stores information electronically. The electronic storage medium of electronic storage device 228 may include one or both of system storage devices that are integrated with server 202 (i.e., substantially non-removable) and / or removable storage devices that are removably connected to server 202 via, for example, a port (e.g., USB port, FireWire port, etc.) or a drive (e.g., disk drive, etc.). Electronic storage device 228 may include one or more of optically readable storage media (e.g., optical disc, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard disk drive, floppy disk drive, etc.), charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drive, etc.), and / or other electronically readable storage media. Electronic storage device 228 may include one or more virtual storage resources (e.g., cloud storage, virtual private networks, and / or other virtual storage resources). Electronic storage device 228 may store software algorithms, information determined by processor 230, information received from server 202, information received from client computing platform 204, and / or other information that enables server 202 to operate as described herein.

[0037] Processor 230 may be configured to provide information processing capabilities within server 202. Therefore, processor 230 may include one or more of the following: a digital processor, an analog processor, digital circuitry designed for processing information, analog circuitry designed for processing information, a state machine, and / or other mechanisms for electronically processing information. Although processor 230 is... Figure 2 The processor 230 is shown as a single entity, but this is for illustrative purposes only. In some embodiments, the processor 230 may include multiple processing units. These processing units may be physically located within the same device, or the processor 230 may represent the processing capabilities of multiple devices operating cooperatively. The processor 230 may be configured to execute modules and / or other modules: software; hardware; firmware; some combination of software, hardware, and / or firmware; and / or other mechanisms for configuring processing capabilities on the processor 230. As used herein, the term "module" may refer to any component or set of components that performs the functions belonging to the module. This may include one or more physical processors, processor-readable instructions, circuitry, hardware, storage media, or any other component during the execution of processor-readable instructions.

[0038] It should be understood that, although the module is Figure 2The implementation is shown as being within a single processing unit, but in embodiments where processor 230 includes multiple processing units, one or more modules may be implemented remotely from other modules. The descriptions of the functionality provided by the different modules below are for illustrative purposes and are not intended to be limiting, as any of the modules may provide more or less functionality than described. For example, one or more modules may be eliminated, and some or all of their functionality may be provided by other modules. As another example, processor 230 may be configured to execute one or more additional modules that perform some or all of the functionality attributed to one of the described modules.

[0039] Figure 3 A method 300 for prioritizing network risks within one or more computing systems composed of computing elements, according to one or more embodiments, is illustrated. The operation of method 300 presented below is intended to be illustrative. In some embodiments, method 300 may be performed using one or more additional operations not described and / or without one or more of the operations discussed. Additionally, in Figure 3 The order of operations of method 300 shown and described below is not intended to be limiting.

[0040] In some embodiments, method 300 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, digital circuitry designed for processing information, analog circuitry designed for processing information, a state machine, and / or other mechanisms for electronically processing information). The one or more processing devices may include some or all of one or more means that perform the operations of method 300 in response to instructions electronically stored on an electronic storage medium. The one or more processing devices may include one or more means configured by hardware, firmware, and / or software to specifically design for performing one or more of the operations of method 300.

[0041] Operation 302 may include assessing vulnerability by determining the exposure window of a computing element based on the number of discrete times within a given time frame in which the computing element is in a vulnerable state. According to one or more embodiments, operation 302 may be executed by one or more hardware processors configured with machine-readable instructions, including modules identical or similar to vulnerability assessment module 208.

[0042] Operation 304 may include determining the frequency of contact between the computing element and the threat actor. According to one or more embodiments, operation 304 may be executed by one or more hardware processors configured with machine-readable instructions, including modules identical or similar to the frequency determination module 210.

[0043] Operation 306 may include normalizing the exposure window and contact frequency. According to one or more embodiments, operation 306 may be executed by one or more hardware processors configured with machine-readable instructions, which include modules that are the same as or similar to the exposure window normalization module 212.

[0044] Operation 308 may include calculating the loss event frequency by dividing the normalized exposure window by the normalized contact frequency. According to one or more embodiments, operation 308 may be executed by one or more hardware processors configured with machine-readable instructions, including modules identical or similar to the loss event frequency determination module 210.

[0045] Operation 314 may include repeating the above operations for multiple assets. According to one or more embodiments, operation 314 may be executed by one or more hardware processors configured with machine-readable instructions, which include modules that are the same as or similar to the step repeating module 220.

[0046] Operation 316 may include prioritizing components based on the frequency of loss events, and, when combined with loss magnitude data, prioritizing components based on loss exposure. According to one or more embodiments, operation 316 may be executed by one or more hardware processors configured with machine-readable instructions, including modules identical or similar to component prioritization module 222.

[0047] The modules and corresponding operations mentioned above are described in more detail below. Determining the probability that contact with a threat party in a given year will coincide with an exposure window may include determining how many days in a year the system is vulnerable, i.e., its overall exposure window. This is obtained from a vulnerability data source that indicates how frequently vulnerability situations occur and how long they last. For example, if available security telemetry indicates that the system experiences an average of three vulnerability situations per year, and that these situations last an average of seven days, then the asset is at risk of exposure for an average of twenty-one days per year. It should be noted that because the risk environment is dynamic, the values ​​used in this analysis should be ranges rather than discrete values, and the underlying analysis should utilize stochastic processes such as Monte Carlo methods to account for measurement uncertainties.

[0048] The Mean Time Interval Between Exposures (MTBC) with the threat actor is determined from system logs containing evidence of threat scanning / probing. Mathematically, this can be obtained by dividing the number of days in a year by the exposure frequency (e.g., an exposure frequency of 5 yields an MTBC of 73 days). The LEF is determined by dividing the exposure window by the MTBC. Using values ​​from the first two examples yields a LEF of 0.29. In other words, in this example, the probability of a loss event is slightly less than once every three years.

[0049] While the underlying premises and mathematics upon which the embodiments rely are relatively simple, practical embodiments are more challenging. This is due to several reasons:

[0050] • Vulnerability-related data is often very noisy. In other words, much of the vulnerability data relates to control flaws that are actually unexploitable. This means that the embodiments disclosed herein will distinguish between vulnerabilities that may be exploitable and those that are not.

[0051] • Network-related assets will exist in various threat environments with different exposure frequencies (e.g., internet-facing and non-internet-facing). This means that implementations will be able to determine the location of systems / applications / etc. within the threat environment and thus which exposure frequency data applies.

[0052] • Because many technologies have some history regarding the frequency of new zero-day exploits by various threat groups, the implementation will be able to track, analyze, and integrate this data point to determine the frequency of vulnerability situations.

[0053] • The threat and control environments evolve, meaning that empirical data may not provide a fully reliable representation of how things will unfold in the future. Therefore, implementations will be able to capture and extrapolate trends from the data applied to the analysis.

[0054] The disclosed embodiments also allow subject matter experts to adjust the data. This enables manual "what-if" analysis to examine when and where an organization might be sensitive (or resilient) to changes in the threat or control environment. The embodiments allow for automated sensitivity analysis, enabling large-scale exploration of an organization's cyber risk environment to quickly explore the problem space and identify opportunities to optimize mitigation efforts and build a highly resilient environment. To enable prioritization of vulnerability states based on loss exposure, the solutions using the embodiments described herein also integrate value / responsibility data (e.g., from an asset management database) that provides the magnitude of network loss exposure.

[0055] The following describes an example use case. Imagine a company called ABC Inc. with one thousand systems in its cybersecurity environment, and the vulnerabilities of these systems are estimated daily using common scanning techniques (e.g., the QUALYS™ cloud platform). Furthermore, suppose QUALYS reports a total of 3,457 vulnerabilities in these systems on a given day, with one-third of those vulnerabilities rated as critical or very high using the CVSS scoring system discussed above. Unable to prioritize its mitigation efforts based on loss exposure, ABC Inc. would be forced to attempt to remediate over one thousand vulnerabilities. Most organizations cannot address so many vulnerabilities in a timely manner, especially given the highly dynamic nature of the environment. This necessitates either: a) performing time-consuming manual analysis, or b) using a near-random method to select vulnerabilities to remediate. In either case, ABC Inc. would suffer a longer loss exposure window than necessary or optimal, and threat prevention would be at best suboptimal.

[0056] Instead, suppose ABC Inc. is using the embodiments disclosed herein. To perform a loss exposure-based analysis of its environment, the embodiments will receive data from the following sources:

[0057] • QUALYS data on the vulnerability types, their frequency, and duration for each system (this data enables the implementation to determine which vulnerabilities are exploitable for each system and the exposure window for each system).

[0058] • Network IP address data for each system (this data enables the implementation to determine which threat environment each system is exposed to (e.g., internet-facing, internal only, connected to a third party, etc.) and thus which exposure frequency data (in the next section) applies to which systems).

[0059] • Data from threat detection technologies in the relevant threat environment that provide empirical data related to contact frequency (e.g., from Security Information and Incident Management (SIEM) providers); and

[0060] • Data from ABC Inc.’s asset management database, which contains information about the value / liability characteristics of each system (this information is used to obtain the loss magnitude component based on loss exposure analysis).

[0061] As a result of this analysis, ABC Inc. was able to identify which systems represented the greatest potential for loss, which in this example boiled down to 50 systems requiring immediate remediation and 250 systems requiring near-term attention. ABC Inc. also conducted sensitivity analyses on a dozen or so systems that would fall into the "Immediate Remediation" category if specific changes related to these technologies occurred in the relevant threat environment (e.g., a new zero-day exploit). Based on this result, these systems were placed at the end of the "Immediate Remediation" queue. This leads to more effective risk reduction activities.

[0062] As described above, the embodiments disclosed herein eliminate the need for independent threat estimation capabilities and difficulties by simplifying the use of security telemetry in known methods, such as FAIR analysis. Examples of mathematical formulas that can be used to implement the above calculations are described below. The embodiments disclosed herein can be considered as an objective, model-based method for measuring LEF. The model processes the inputs to measure LEF. The mathematical model is described below using a β-PERT distribution. All inputs are preferably taken as minimum, most probable, maximum, and λ (confidence) values ​​to create a β-PERT distribution, which will be described immediately below.

[0063] For parameters a > 0, b > 0, c > 0, λ > 0, the probability density function can be calculated using the following formula:

[0064]

[0065] in i Distribution type:

[0066]

[0067] and

[0068]

[0069] The PERT distribution consists of a minimum value. a Most likely value b and maximum value c definition.

[0070]

[0071] make This is a β-PERT distribution based on the function input, where x is the parameter, a > 0; b > 0; c > 0; λ > 0. A more detailed description of the input to the computational model is given below. Note that the units of the values ​​described below (such as days) are merely illustrative, and any convenient units can be used.

[0072] 1. Annual Threat Behavior Scan Rate -

[0073] 2. Annual Asset Vulnerability Opening Rate

[0074] 3. Number of days to expose vulnerabilities -

[0075] 4. Number of days in a year - n

[0076] The model uses a set of intermediate calculations as described below. It starts with the probability of a vulnerability being exposed each day.

[0077]

[0078] in e It is the probability of vulnerability opening occurring within a given year. o It refers to the asset vulnerability exposure rate within that year, and n This refers to the number of days in a given year. The year is defined as a unit of time, and the number of days as a subunit of time; this formula aims for modularity. Based on this, it can be said that the likelihood of any particular subunit of time being vulnerable is calculated based on the probability that a vulnerability window will remain open for a number of subunits within that window.

[0079]

[0080] in It is about Binary Vulnerability Analysis (BVA) function for vulnerabilities. e It is the probability of vulnerability opening occurring in each time subunit, and d This represents the number of time sub-units in which vulnerabilities are exposed. Then, the probability of a threat actor scanning the asset at any given time sub-unit is calculated.

[0081]

[0082] in It is the BVA function of the contact frequency. k It is the contact frequency within a given unit of time, and n This refers to the number of sub-units within a given time unit. Now, we calculate the probability that an asset is vulnerable to attack (resulting in a loss event) while a threat actor is scanning the asset.

[0083]

[0084] in It represents the probability or likelihood that a threat actor will scan assets within a given sub-unit of time. It's a BVA function related to vulnerability, and This is a BVA function related to the contact frequency. This can be converted to a parent time frame via the following:

[0085]

[0086] in This represents the annual frequency of loss events. After several algebraic transformations, the complete equation is:

[0087]

[0088] The model's output and an example calculation of the output are described below.

[0089] 1. Frequency of loss events -

[0090] One example uses the current frequency of loss events. The frequency of loss events in the next time period is calculated using the estimated value ƒ' of the frequency change. .

[0091]

[0092] in This is an estimated frequency change. If it is a range, only the average value within that range is taken.

[0093]

[0094] When estimated in the next time period When there is no change, Remain unchanged. In the event of changes, the estimated changes Can be multiplied by the current If it does not exist in the current time period. At that time, it is possible to estimate the next time period. .

[0095] Although the present technology has been described in detail for the purpose of illustration based on embodiments currently considered to be the most practical and preferred, it will be understood that such detail is for the purposes described only, and the present technology is not limited to the disclosed embodiments. Rather, the present technology is intended to cover modifications and equivalent arrangements within the spirit and scope of the technical solutions according to the present invention. For example, it will be understood that, to the extent possible, the present technology contemplates that one or more features of any embodiment may be combined with one or more features of any other embodiment.

Claims

1. A system configured to determine the frequency of network risk losses within one or more computing systems comprising computing elements, the system comprising: One or more hardware processors, the one or more hardware processors being configured by machine-readable instructions to: Vulnerability is assessed by determining the exposure window of the computing element, wherein determining the exposure window includes determining the number of discrete moments within a given time frame when the computing element is in a vulnerable state, wherein determining the number of discrete moments includes determining between an exploitable vulnerable state and an unexploitable vulnerable state, and wherein the exposure window represents a time window that is exploited by a threat actor. Determine the frequency of contact between the computing element and the threatening actor; The exposure window is normalized by setting each discrete time as a first time interval and setting the given time frame as a second time interval that is longer than the first time interval; The contact frequency is normalized by determining the average contact interval time, wherein the average contact interval time is represented by the number of first time periods occurring within the second time period. The frequency of loss events is calculated by dividing the normalized exposure window by the normalized contact frequency; as well as Repeat the above steps for multiple computing elements.

2. The system of claim 1, wherein the normalization of the exposure window is performed as part of assessing the vulnerability, and the normalization of the contact frequency is performed as part of determining the frequency.

3. The system of claim 1, wherein the first time period is one day and the second time period is one year.

4. The system of claim 1, wherein the exposure window, the contact frequency, and the loss event frequency are expressed as ranges, and calculating the loss event frequency includes applying a stochastic process.

5. The system of claim 1, wherein assessing the vulnerability includes configuring the one or more hardware processors with machine-readable instructions to determine the number of discrete times using only exploitable vulnerable states.

6. The system of claim 1, wherein, in order to determine the frequency, the one or more hardware processors are configured by machine-readable instructions to determine, including determining the location of the computing element within the threat environment, and wherein data indicating the contact frequency is determined based on the location.

7. The system of claim 1, wherein, in order to assess the vulnerability, the one or more hardware processors are configured by machine-readable instructions to determine the exposure window using zero-day exploitation information.

8. The system of claim 1, wherein the one or more hardware processors are further configured by the machine-readable instructions to take network risk prevention activities based on the priority of the computing elements.

9. The system of claim 1, wherein the one or more hardware processors are further configured by the machine-readable instructions to combine the determined loss event frequency with loss magnitude data and to prioritize the computing elements based on loss exposure.

10. A method for prioritizing network risks within one or more computing systems comprised of computing elements, the method comprising: Vulnerability is assessed by determining the exposure window of the computing element, wherein determining the exposure window includes determining the number of discrete moments within a given time frame when the computing element is in a vulnerable state, wherein determining the number of discrete moments includes determining between an exploitable vulnerable state and an unexploitable vulnerable state, and wherein the exposure window represents a time window that is exploited by a threat actor. Determine the frequency of contact between the computing element and the threatening actor; The exposure window is normalized by setting each discrete time as a first time interval and setting the given time frame as a second time interval that is longer than the first time interval; The contact frequency is normalized by determining the average contact interval time, wherein the average contact interval time is represented by the number of first time periods occurring within the second time period. as well as The frequency of loss events is calculated by dividing the normalized exposure window by the normalized contact frequency; as well as Repeat the above steps for multiple computing elements.

11. The method of claim 10, wherein the normalization of the exposure window is performed as part of assessing the vulnerability, and the normalization of the contact frequency is performed as part of determining the frequency.

12. The method of claim 10, wherein the first time period is one day and the second time period is one year.

13. The method of claim 10, wherein the exposure window, the contact frequency, and the loss event frequency are expressed as ranges, and calculating the loss event frequency includes applying a stochastic process.

14. The method of claim 10, wherein assessing the vulnerability includes determining the number of discrete times using only the exploitable vulnerable states.

15. The method of claim 10, wherein determining the frequency includes determining the location of the computing element within the threat environment, and wherein data indicating the contact frequency is determined based on the location.

16. The method of claim 10, wherein assessing the vulnerability includes using zero-day exploitation information to determine the exposure window.

17. The method of claim 10, further comprising performing network risk prevention activities based on the priority of the computing elements.

18. The method of claim 10, further comprising combining the determined loss event frequency with loss magnitude data, and prioritizing the computing elements based on loss exposure.

19. A non-transitory computer-readable storage medium, wherein instructions are included on the non-transitory computer-readable storage medium, the instructions being executable by one or more processors to perform a method for prioritizing network risks within one or more computing systems comprising computing elements, the method comprising: Vulnerability is assessed by determining the exposure window of the computing element, wherein determining the exposure window includes determining the number of discrete moments within a given time frame when the computing element is in a vulnerable state, wherein determining the number of discrete moments includes determining between an exploitable vulnerable state and an unexploitable vulnerable state, and wherein the exposure window represents a time window that is exploited by a threat actor. Determine the frequency of contact between the computing element and the threatening actor; The exposure window is normalized by setting each discrete time as a first time interval and setting the given time frame as a second time interval that is longer than the first time interval; The contact frequency is normalized by determining the average contact interval time, wherein the average contact interval time is represented by the number of first time periods occurring within the second time period. as well as The frequency of loss events is calculated by dividing the normalized exposure window by the normalized contact frequency. as well as Repeat the above steps for multiple computing elements.

20. The computer-readable storage medium of claim 19, wherein the normalization of the exposure window is performed as part of assessing the vulnerability, and the normalization of the contact frequency is performed as part of determining the frequency.

21. The computer-readable storage medium of claim 20, wherein the first time period is one day and the second time period is one year.

22. The computer-readable storage medium of claim 19, wherein the exposure window, the contact frequency, and the loss event frequency are expressed as ranges, and calculating the loss event frequency includes applying a stochastic process.

23. The computer-readable storage medium of claim 19, wherein assessing the vulnerability includes determining the number of discrete times using only the exploitable vulnerable states.

24. The computer-readable storage medium of claim 19, wherein determining the frequency includes determining the location of the computing element within a threat environment, and wherein data indicating the contact frequency is determined based on the location.

25. The computer-readable storage medium of claim 19, wherein assessing the vulnerability includes using zero-day exploitation information to determine the exposure window.

26. The computer-readable storage medium of claim 19, wherein the method further comprises performing network risk prevention activities based on the prioritization of the computing elements.

27. The computer-readable storage medium of claim 19, wherein the method further comprises combining the loss event frequency with loss magnitude data and prioritizing the computing elements based on loss exposure.

Images