102 within, or across, networks (e.g., networks 104, 130), or observational data pertaining to how often that device 102 is accessed, or the types of access made to that device as determined from observed operational characteristics (e.g., dynamic device data determined by risk assessment system 110 from within the network 104 itself). As another example, network device data for device 102 may also include data pertaining to the reachability of the network device 102. Risk assessment system 110 may thus use network device data to determine a reachability factor that accounts for whether a network device 102 is accessible over the Internet or generally outside network 104, or how accessible the device is (e.g., the number or types of ports or connections the device has open, etc.).

Accordingly, to generate a risk score for device 102, the risk assessment system 110 may first generate an initial risk score for network device 102. Such an initial risk score may then be adjusted by various other factors determined based on network device data associated with the device 102 (e.g., as determined from network device data from external data sources 120 or observed dynamic network device data determined by the risk assessment system 110) including, for example, a popularity factor determined for that network device 102 or a reachability factor determined for that network device 102. By using such factors, embodiments of the risk assessment system 110 may generate a risk score for network device 102 that (at least partially) reflects the risk of the device 102, and in some cases may be based on observed dynamic operation of that network device 102 in the network 104.

Moving to FIG. 2 an architecture for one embodiment of a risk assessment system is depicted. Here, risk assessment system 210 may be a computing device which includes processing circuitry 206 and storage (i.e., memory) 208. Control circuitry 204 may send and receive commands, requests, and other suitable data using an I/O path. Control circuitry 204 includes processing circuitry 206 and storage 208. As referred to herein, processing circuitry should be understood to mean circuitry based on one or more microprocessors, microcontrollers, digital signal processors, programmable logic devices, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc., and may include a multi-core processor (e.g., dual-core, quad-core, hexa-core, octa-core, or any suitable number of cores). In some embodiments, processing circuitry 206 is distributed across multiple separate processors or processing units, for example, multiple of the same type of processing units or multiple different processors. The circuitry described herein may execute instructions included in software running on one or more general purpose or specialized processors.

Storage 208 may be an electronic storage device that includes volatile random-access memory (RAM) which does not retain its contents when power is turned off, and non-volatile RAM, which does retain its contents when power is turned off. As referred to herein, the phrase “storage”, “electronic storage device” or “storage device” should be understood to mean any device for storing electronic data, computer software, instructions, or firmware, such as RAM, content-addressable memory (CAM) (including a TCAM), hard drives, optical drives, solid state devices, quantum storage devices, or any other suitable fixed or removable storage devices, or any combination of the same.

Risk assessment system 210 may store identifiers or other representations 202 (e.g., objects) of devices in a network that includes risk assessment system 210, and associate network device data 240 with these representations 202 of network device 202 (for ease of description herein, representations 202 of network devices will be referred to also just as “network devices”). This network device data 240 may include device type data 254 indicating the hardware (e.g., manufacturer or model designation of the hardware of device) or the software of the device. In some cases, the network device data 240 may also include software version data 252 indicating, for example, a name or version of an operating system or other applications on network device 202.

As discussed, in some cases, risk assessment system 210 may be implemented with, or be included in, an NDR system or another type of network security system. Thus, network device data 240 associated with network device 202 may include dynamic data 262 on the operation of the network including risk assessment system 210 and network devices 202 determined at the packet (e.g., via packet inspection), network, device, workload, application, or user level, such as dynamic device characteristics visible from observation of network or device 202 (or data communicated to, or originating from network device 202) such as frequency or types of access, reachability or accessibility of device, open ports on the device or other observed data pertaining to the network device 202.

Risk assessment system 210 also includes risk scoring engine 270 (e.g., a set of instructions that may be executed on processing circuitry 206) adapted for generating risk scores (e.g., any indicator of risk which) for network devices (e.g., represented network devices 202) based on network device data 240 associated with the device. Risk scoring engine 270 includes data gathering module 274 for obtaining network device data 240 from external data sources (i.e., sources of data external to risk assessment system 210) and scoring module 272 for generating the risk scores 296 which may be stored in storage 208. It will be noted that both data gathering module 274 and scoring module 272 may operate in a synchronous or asynchronous manner to one another, where each may operate at certain time intervals (e.g., data gathering or risk scoring may occur at certain time intervals) or on demand when requested (e.g., by a user, another application or module, through web services request, etc.). In this manner, risk scores for device 202 may not be static and may be continuously updated (e.g., as new vulnerabilities are discovered or as the software versions on device 202 change).

In certain embodiments, data gathering module 274 may obtain CVE data 250 on each of a set of CVEs associated with network device 202 from data sources based on device type 254 of the network device 202. Thus, these data sources may be searched or otherwise queried (e.g., by device type 254) for CVEs pertaining to the device 202 (e.g., the device type 254 of the device 202). This querying may include obtaining data on CVEs for the device using an Application Programming Interface (API) provided by a data source. For example, the Shodan Exploit API may be queried by device type 254 to obtain resulting identifiers for CVEs associated with that device type 254. Additionally, using an Internet search engine (e.g., Bing, Google, etc.) data gathering module 274 may perform an Internet search of certain sites on the Internet (e.g., nvd.nist.com), for CVEs pertaining to the device type 254. The returned search results may be processed to determine identifiers of one or more CVEs pertaining to device 202. This processing may include performing NLP or other types of analysis of the search results (e.g., the titles of the pages returned in the search results).

CVE data 250 on each of the determined CVEs may then be obtained from a data source (e.g., based on identifiers of those CVEs) and stored in network device data 240. This obtained CVE data may include data regarding a description of the CVE, a published date of the CVE, a CVSS score for the CVE, a CVSS version, a CVSS risk, CPEs (e.g., list), a Version end or Version start indicating a software version (or range) impacted by the CVE, or CWEs (e.g., list). Thus, CVE data 250 for each of a set of CVEs associated with each device 202 may be stored in network device data 240 for device 202.

Data gathering module 274 may also determine device popularity data 280 and reachability data 282 and store the device popularity data 280 and reachability data 282 as network device data 240 for device 202. For example, device popularity data 280 for a device may be fetched from Fing (https://dev.embedtech.lansweeper.com/) and may be a score from 0-100, while reachability data 282 may be data pertaining to whether device 202 is reachable from the Internet that may be obtained from Shodan or a similar service.

Scoring module 272 utilizes network device data 240 for network device 202 in determining a risk score for that network device 202. To determine a risk score for network device 202, scoring module 272 may first determine an initial risk score. To determine the initial risk score, the scoring module 272 may identify a set of CVEs associated with the network device 202 to utilize for generating a risk score from CVE data 250 of network device data 240 associated with network device 202. If software version 252 is included in network device data 240 associated with network device 202 (e.g., an operating system version or the like), the CVEs for the network device may be filtered to exclude CVEs that do not apply to software version 252 (e.g., software version 252 is compared to the Version end or Version start for a CVE in CVE data 250 and the CVE is excluded (if the software version 252 does not match the Version end or Version start in CVE data 250). If no software version 252 is included in network device data 240 all CVEs in network device data 240 may be utilized in generating an initial risk score.

Scoring module 272 can then use the CVSS score in CVE data 250 for each of the determined set of CVEs to determine the initial risk score (e.g., by summing the CVSS scores). In some embodiments, scoring module 272 may determine one or more factors for applying to the CVSS score for a CVE to adjust the CVSS score for that CVE before it is summed.

For example, scoring module 272 can determine a time based weighting factor 256 for each of the determined set of CVEs associated with device 202, Such a time based weighting factor 256 for a CVE may be determined by determining the age of the CVE (e.g., the time elapsed since the CVE publication date) included in the CVE data for that CVE. The scoring module 272 can then define a decay function that assigns less weight to older CVEs (e.g., exponential decay, linear decay, etc.) and applying the decay function to the age of that CVE to obtain the time based weighting factor 256 for that CVE. In one embodiment, for example, an exponential decay function with a half-life of one year (365 days) may be used as the decay function. This function would give a weighting factor of 0.5 for a vulnerability that is one year old, 0.25 for a vulnerability that is two years old, and so on. This time based weighting factor 256 can be applied to the CVSS score for that CVE before it is summed to generate an initial risk score.

For each of the set of CVEs being used to determine an initial risk score, scoring module 272 may also determine if a brute force attack is associated with that CVE. For example, to determine if a brute force attack is associated with a CVE, the CVE description in CVE data 250 for that CVE may be processed to determine the presence of brute force attacks. In one embodiment, scoring module 272 may check for the presence of brute force attack-related keywords in the CVE description of the CVE data 250 for that CVE (e.g., keywords that indicate brute force attacks, such as “RDP”, “Telnet”, “FTP”, “SSH”, “HTTP”, etc.) by searching the CVE description of the CVE data 250 for the presence of any of these keywords. If a keyword is found, scoring module 272 may determine brute force weighting factor 258 (e.g., 1.2) for that CVE. Brute force weighting factor 258 may be applied to a CVSS score of a CVE before it is summed to generate an initial risk score to, for example, increase the CVSS score of the affected CVE by a specified percentage (e.g., when a brute force keyword is detected).

As another example, scoring module 272 may attempt to determine exploit weighting factor 260 for each CVE when determining an initial risk score for a device. Such an exploit weighting factor for a CVE may be determined by searching for exploit data on the CVE (e.g., searching the National Vulnerability Database (NVD) for exploit information; searching GitHub for repositories that contain exploit code for the CVE; searching other reliable vulnerability and exploit databases, such as the Exploit Database or Known Exploited Vulnerabilities (KEV) Database etc.). For example, the GitHub searchsploit library can be used to probe the exploit database of GitHub. Additionally, these GitHub APIs may be utilized to examine repositories for exploit code or proof of concept related to the CVE. All CVEs in the KEV database (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) are compiled, and the database may be utilized to determine whether a CVE has been exploited. If such exploit data is found, exploit weighting factor 260 (e.g., 1.3) for that CVE. Exploit weighting factor 260 may be applied to a CVSS score of a CVE before it is summed to generate an initial risk score to, for example, increase the CVSS score of the affected CVE by a specified percentage (e.g., when an exploit data associated with that CVE is detected).

Scoring module 272 can thus determine an initial risk score for device 202 by summing the CVSS score for each CVE determined for that network device 202 (e.g., all of the CVEs associated with the device 202 or the filtered set of CVEs associated with the software version 252 of network device 202). Before the CVSS score for a CVE is summed, the CVSS score for that CVE may be adjusted by any additional weighting factors determined for that CVE (e.g., time based weighting factor 256, brute force weighting factor 258 or exploit weighting factor 260 determined for that CVE). Such an adjustment may include multiplying the CVSS score (or a previously adjusted CVSS score) for that CVE by the weighting factor.

Accordingly, in one embodiment, the formula for determining an initial risk score may thus be initial risk score=> (CVSS [i]*W [i]*BF [i]*EF [i]) where CVSS [i] is the CVSS score of the i-th filtered CVE, W [i] is the time-based weighting factor for the i-th filtered CVE, calculated using: W [i]=exp (−age_in_days [i]/365), BF [i] is the brute force weighting factor for the i-th filtered CVE, which is equal to the defined brute force weighting factor (e.g., 1.2) if a brute force keyword is found in the i-th filtered CVE's description, and 1 otherwise and EF [i] is the exploit weighting factor for the i-th filtered CVE, which is equal to the defined exploit factor (e.g., 1.3) if an exploit is available for the i-th filtered CVE, and 1 otherwise.