Patent Description:
Businesses and organizations rely more and more on networked computer systems for information and services. The computer systems can include computing devices such as computers and smartphones, databases or data stores, as well as computer networks such as private and public networks (including the Internet). In computer networking, a network service ("Information Technology" (IT) service) is an application running at the network application layer (and above) that provides data storage, manipulation, presentation, communication or other capability. An IT service may be implemented using a multi-tier architecture such as, for example, a web-tier, an application tier, and a database tier, with each tier providing compute and/or storage services. Each IT service is usually provided by a server component running on one or more computers (often a dedicated server computer offering multiple services) and accessed via a communication network by client components running on network endpoint devices, such as desktop or laptop computers, or portable devices like tablets and smart phones.

IT services that are commonly provided on computer networks include, for example, directory services, e-mail services, file sharing, instant messaging services, online gaming services, printing, file server services, voice over Internet Protocol (VoIP) services, video on demand, video telephony, World Wide Web access, simple network management protocol (SNMP), time services, wireless sensor network services, business applications, etc..

A computer security "vulnerability" may be a weakness, exposure, or gap in a computer system that can be exploited by threats by an unauthorized third party to gain unauthorized access to the computer network or to the network assets. Computer security can also be considered as information security. Establishing good computer security (which may include processes and mechanisms by which equipment, information, and services are protected from unauthorized access, changes, or destruction) is essential for secure operation of a computer network. Software, hardware, and firmware vulnerabilities pose a critical risk to any organization operating a computer network, and can be difficult to categorize and mitigate.

In traditional threat and vulnerability management (TVM), security alerts reporting vulnerabilities (identified, for example, by a vulnerability name or nomenclature matching application) may be sent to various stakeholders (e.g., application owner/users, security teams, system administrators, agents, etc.) who may be affected by, or can act on, the reported vulnerabilities. The stakeholders may be, for example, organizational entities (e.g., IT administrators) or machine entities (e.g., other computing devices, services, or software modules), which have been granted privileges to access parts of the computer network to correct or mitigate the reported vulnerabilities. Correction or mitigation of vulnerability may include, for example, blocking access to, blocking operation of, patching, replacing, or removing the vulnerable service component. Correction or mitigation of the vulnerability may also include scanning the computer system for viruses or other malware that may have been introduced, and removing the viruses or other malware.

Consideration is being given to systems and methods for mitigating security risks for IT services implemented on a computer network.

<CIT> describes an approach to identify vulnerabilities for individual assets in a computer system with assets. The approach comprises the identification of threats that use the vulnerabilities and of countermeasures.

A computer network implements a secure IT service.

In a general aspect, the computer network includes network assets including computing devices each having at least one processor and at least one memory.

A computing device hosts a security risk solution application that includes a service model module and a security tools data module. The service model module identifies network assets in the computer network used by the service. The service model module also identifies dependencies of the network assets in the computer network. The security tools data module receives data identifying vulnerabilities in one or more of the network assets. Each vulnerability may have one or more vulnerability risk dimensions. Identifying vulnerabilities in one or more of the network assets includes determining a risk value for each vulnerability risk dimension. Determining a risk value for each vulnerability risk dimension includes using information obtained from one or more network security tools coupled to the computer network.

In other words, each network asset is potentially exposed to a risk, related to a technical configuration of the network asset. As used herein, the risks are differentiated into dimensions, and the dimensions are labelled ". In that sense, the risks are multi-dimensional risks.

In a first dimension, the network asset faces a so-called "public facing" risk because the network asset is connected to a communication network that allows data communication without restrictions. An example is the internet. A network asset belonging to a firewall-protected intranet would not face a risk in that dimension.

In a second dimension, the network asset faces a so-called "live threat" risk: While in operation, the network asset can be attacked at the same time that means in real-time. For example, an attacker computer can connect to a particular computer in the network (being the asset for example), and can cause the particular computer to perform actions under control of the attacker (such as distributing messages with malware, deleting data etc.). In other words, there is a concrete and immediate risk that the network asset is being "hijacked".

In a third dimension, the network asset faces a so-called "patch vulnerability" risk because, a particular software patch has been identified but not yet deployed or installed to the network asset. In other words, there is a patch pending risk.

In a fourth dimension, the network asset faces a so-called "policy non-compliance" risk because a policy defines a particular rule that is not implemented by the network asset. For example, a policy may require the network assets to communicate with each other via communication channels that use encryption, but the particular network asset may not support encryption.

It is noted that each particular network asset may face the risks in the dimensions differently. The network asset might face risk in none, in one or more dimension.

The dimensions can be defined otherwise, for example in terms of confidentiality, integrity, availability, non-repudiation, access control (or other aspects of information security).

The mentioned example dimensions fit into such a classification as well. A risk in the dimension "public facing" is applicable, for example to the confidentiality and access control aspects (intruders could use the internet to gain access to data), the dimension "policy non-compliance risk" is applicable, for example because the policies may be been established to implement technical measures to provide confidentiality, integrity, availability, non-repudiation, access control and so on.

The computing device also includes a risk score calculator and a prioritization simulator. The risk score calculator determines an asset risk score for each of the network assets used by the IT service based on the risk values of the vulnerability risk dimensions of the vulnerabilities of the network asset. The risk score calculator further determines a service risk score for the IT service based on the determined asset risk scores of the network assets, for example, by aggregating the asset risk scores of the individual network assets used by the IT service.

The prioritization simulator prioritizes and implements one or more vulnerability remediation actions on the computer network to secure the service. For this purpose, the prioritization simulator simulates effects of different vulnerability remediation actions on the service risk score, and prioritizes implementation of a vulnerability remediation action that has a larger simulated reduction in the service risk score over implementation of other vulnerability remediation actions that have smaller simulated reductions in the service risk score.

In other words, there is (first) the calculation of a current risk (in terms of scores) and (second), the simulation of the IT service performance with modified settings, and (second) the calculation of a potential risk with modified settings. Reducing the risk is the goal.

A computer network (e.g., a public cloud, a private cloud, or an on-premise system) can host one or more services ("IT services"). The computer network may encompass or include a variety of hardware, software and firmware components ("assets") used to implement an IT service. The network assets used to implement the IT service may include, for example, one or more servers (e.g., web servers, application servers, etc.), databases, software code, network components, applications, and other services. In other words, the network assets are portions of the computer network, wherein the network could be portioned into hardware portions (i.e., the servers), software portions (i.e., the software code), modules in hardware/software combination (i.e., computing devices, computers with databases, network components etc.).

A computer security "vulnerability" (or information security weakness) is a weakness, exposure, or gap in a computer network or computing device that can be exploited by threats (e.g., an unauthorized third party) to gain unauthorized access to a network asset in the computer network or computing device. In other words, the computer security "vulnerability" is different term for a situation in that a network asset faces a risk.

For example, a network asset can have a weakness in being protected against unauthorized access, because for example an access control measure (at the network asset) may not be implemented (cf. the above-mentioned dimension of the patch vulnerability), a measure demanded by a policy (cf. the non-compliance) may not be available or for other reasons.

An information security vulnerability can be defined as a security flaw or weakness in a computer network's or computing device's design, implementation, or operation and management. The security flaw or weakness may be exploited to violate the computer network's or computing device's security policy and compromise security for the computer network or computing device. A vulnerability can create a possible path or means by which a malicious actor can gain unauthorized access to a computer network or computing device. The vulnerability may be a state in a computer network or computing device (or set of networks or devices) that, for example, either allows an attacker to execute commands posing as another user, allows the attacker to access data that is contrary to the specified access restrictions for that data, allows the attacker to pose as another entity, or allows the attacker to conduct a denial of service attack, etc. Common vulnerabilities include, for example, operating system (O/S) flaws (e.g., default permits), infected Internet sites (e.g., web sites containing malicious spyware/adware which could infect computers and collect personal information. etc.), flaws in software code (e.g., unchecked user inputs that may result in buffer overflows or SQL injection), password management flaws (e.g., acceptance of weak passwords that can be discovered by brute force attacks), and software bugs (e.g., computer viruses that allow the attacker to misuse the infected computer).

Most businesses or organizations recognize a need for continually monitoring their computer networks and computing devices to identify assets at risk not only from known vulnerabilities but also from newly reported vulnerabilities (e.g., due to new computer viruses or malicious programs). Identification of vulnerable software allows prophylactic actions to be taken, for example, to secure the vulnerable software and prevent breaches of computer security. The prophylactic action may include inserting changes in the code of software programs running on the computer networks or computing devices (e.g., patches or bug fixes) that are designed to update, fix, or improve the vulnerable software programs. Other prophylactic actions may include, for example, deploying specific anti-virus software and/or restricting operation of the vulnerable software to limit damage. The prophylactic actions may also involve hardening of systems by, for example, using best security practices for configuring the systems for their intended use (e.g., enabling services).

Under the Common Vulnerabilities and Exposure (CVE) initiative and other such industry initiatives, an information security "vulnerability" is defined as a flaw in software code or configuration that can be directly used by an attacker to gain access to a system or network. Further, under the CVE and other such initiatives, an information security "exposure" is defined as a system configuration issue or a flaw in software that allows access to information or capabilities that can be used by an attacker or hacker as a stepping-stone into a system or network. A system configuration issue or a flaw may be a security exposure if it does not directly allow compromise, and is a violation of a reasonable security policy. An information security "exposure" describes a state in a computer network or computing devices (or set of networks or devices) that is not a vulnerability, but (a) allows an attacker to conduct information-gathering activities, (b) allows an attacker to hide activities, (c) allows the computer network or computing device to behave as expected, but is compromising such network or device, (d) is a primary point of entry that an attacker may attempt to use to gain access to the system or data, or (e) is considered a problem according to some reasonable security policy.

Vulnerability scanning tools (e.g., tools that are commercially available in the TVM space) may be used to identify vulnerabilities in computer systems that can be exploited by malicious actors. These vulnerability scanning tools can scan and report on information security vulnerabilities of different types (e.g., computer networks' or computing devices' O/S, applications, software code, and policy violations vulnerabilities). Some of the commercially available vulnerability scanning tools (e.g., Qualys, Nessus, Rapid7, etc.) focus on reporting about vulnerabilities on computer network's or computing devices' O/S, core software, and application vulnerabilities. Other tools (e.g., Whitehat, Sonatype, CheckMark, etc.) focus on reporting about software code vulnerabilities. Yet other tools (e.g., SecOps Policy, etc.) focus on reporting computer or software misconfigurations that are against company or regulatory policies. These vulnerability scanning tools may be used to identify vulnerabilities relating to mis-configured assets or flawed software that resides on a computer network's asset, such as a firewall, router, web server, application server, etc..

The computer systems of an organization may have thousands of vulnerabilities (and even millions of vulnerabilities in large environments) at any given time. Not all vulnerabilities are, or can be, remedied immediately in a running computer system without prior testing in a development or quality assurance environment. Vulnerability remediation may involve shutting down or interrupting the computer network's or computing device's operation. Traditional techniques for TVM may involve installing patches in the computer networks and computing devices on a periodic maintenance schedule (e.g., a monthly or quarterly patching schedule) for the computer system. The traditional TVM may involve using numerical Common Vulnerability Scoring System (CVSS) scores to assess the severities of the identified vulnerabilities, and prioritizing remediation (i.e., installing patches) of a few of the vulnerabilities according to their CVSS scores.

While a CVSS score can capture the principal (technical) characteristics of a vulnerability in an asset and produce a numerical score reflecting its severity, the CVSS score does not account for the importance or relevance of the particular vulnerable asset in the context of the IT service, and does not account for the importance or relevance of the IT service to the business goals, business processes, business applications, etc. of the IT service provider. Further while the CVSS score can provide a one-dimensional view (i.e., the technical characteristics) of the vulnerability of an asset, the CVSS score does not consider the impact of other aspects or dimensions such as policy violation, indicators of compromise (IOC), applications' vulnerabilities, and other threats associated with assets that pose a security risk to the IT service.

Each IT service may have its own importance in the IT service provider's business. Breach or unavailability of any particular IT service amongst several IT services may result in different degrees of business risk for the IT service provider. Prioritizing remediation of a few of the vulnerabilities according to their CVSS scores does not consider the impact on the business risks of the IT service provider of low-scoring vulnerabilities, which may not be remediated in a timely manner because of the low CVSS scores. Further, each IT service involves multiple network assets, such as web servers, application servers, database servers, and network devices, etc. Prioritizing remediation of a few of the vulnerabilities based on merely the one-dimensional CVSS scores ignores the impact of asset vulnerabilities on the non-technical aspects of providing the IT service. For example, in an IT service such as an on-line credit card payment service, an application server may be responsible for credit card processing, and a database (DB) server may hold personally identifiable information (PII) or medical records. Both these servers may have vulnerabilities with "medium" CVSS scores, and may have policy violations of mandatory Payment Card Industry (PCI) standards or mandatory Health Insurance Portability and Accountability Act (HIPPA) regulations. Under a typical CVSS score-based prioritization approach to remediation, the two servers having only medium CVSS score vulnerabilities may not be timely remedied, and thus the IT service may remain active even with critical policy or regulatory violations on the two servers.

Such a situation (i.e., rendering an active IT service with unacceptable threat exposure caused by critical policy or regulatory violations) may be avoided by considering overall service security risk as a criterion for prioritizing vulnerability remediation. Considering the IT service's security risk may allow tagging the two servers as having high-service-risk vulnerabilities (i.e. policy or regulatory violations) for immediate or priority remediation to provide a compliant on-line credit card payment service on the application or DB servers.

Systems and methods (collectively "service security risk solutions") for assessing and prioritizing mitigation of security risks of an IT service are disclosed herein. The disclosed solutions take a multi-dimensional view of vulnerabilities of the assets used by the IT service. The IT service may combine processes and functions of software, hardware, and networks. The IT service may be implemented over a computer network involving a variety of assets including, for example, servers, databases, software applications, and network components. The security risk of the IT service can be a function of vulnerabilities of the individual network assets, and the threats that can exploit the vulnerabilities of such assets.

In example implementations, a service security risk solution may generate a security risk score ("asset risk score") for a network asset as a function of the threat vulnerabilities associated with the network asset, the threat agents involved, and the impact of a successful malicious exploit of a vulnerability by an attacker on the IT service goals of the service provider. For purposes of generating asset risk scores, the service security risk solution may consider the network asset's vulnerabilities to include software vulnerabilities (i.e., vulnerabilities that can be remedied by code patches or fixes), system configuration vulnerabilities (i.e., vulnerabilities that can be remedied by system reconfigurations, such as server hardening, closing or opening ports, etc.), and security policy violation vulnerabilities (i.e., vulnerabilities that can be remedied by applying policy controls, etc.).

Further, the service security risk solution may generate a service risk score that is a normalized aggregate of the risk scores of the individual network assets used by, or associated with, the IT service.

In example implementations, the service security risk solution may receive or prepare a service model (e.g., service model <NUM>, <FIG> and <FIG>) identifying and describing the network assets used by the IT service. The service model may identify the particular assets (e.g., servers, databases, and software applications) utilized or accessed by the IT service and also include or describe the logical dependencies between the particular assets (e.g., servers, databases, and software applications) utilized or accessed by the IT service.

The service security risk solution may generate the service risk score for the IT service based on consideration of different aspects or dimensions of the IT service including, for example, the importance of an individual vulnerable network asset within the IT service model from a business perspective, the importance of the IT service to which the vulnerable network asset belongs, current security controls for the IT service as a whole (such as having an Intrusion Prevention System and/or Web Access Firewall in front of the IT service as a whole, and not merely security controls for individual network assets), and consideration of aspects, such as application security (appsec) vulnerabilities, indicators of compromise (IOCs), malware, policy violations, and configuration weakness.

The service security risk solutions described herein can make the service model underlying the service risk score visible to IT administrators (who may be responsible for vulnerability remediation), for example, on a computing device's display. The IT administrators can utilize the service security risk score (and the individual network assets' risk scores) in conjunction with the service model for risk prioritization, remediation of the vulnerabilities, and post- remediation testing of the IT service.

<FIG> is a block diagram of an example system <NUM> for implementing an example service security risk solution for assessing, and prioritizing mitigation of security risks of an IT service (e.g., IT service <NUM>), in accordance with the principles of the present disclosure.

IT service <NUM> may be hosted on a computer network <NUM>, which includes one or more network assets (e.g., network asset <NUM>-<NUM>, network asset <NUM>-<NUM>, network asset <NUM>-<NUM>, network asset <NUM>-<NUM>,. network asset <NUM>-n, etc.). In other words, there is a set of network assets. IT service <NUM> may use or require only a subset of the one or more network assets of computer network <NUM> for service operation (i.e. a subset of the set). While one IT service <NUM> is shown in <FIG>, other IT services (not shown) using one or more of the same assets as IT service <NUM> may be concurrently implemented on computer network <NUM>.

Computer network <NUM> may be coupled to one or more vulnerability and threat detection tools (e.g., vulnerability scanner <NUM>, anti-virus (AV) tool <NUM>, policy compliance tool <NUM>, live threat feeds <NUM>, etc.), and to asset discovery tools and asset identification resources (e.g., asset discovery tool <NUM>, configuration management database (CMDB) <NUM>, etc.).

In system <NUM>, the service security risk solution for assessing and prioritizing of security risks of IT service <NUM> may be implemented via application <NUM>. Application <NUM> may, for example, be hosted on one or more physical or virtual computers (e.g., a computing device <NUM> that, for example, includes a processor <NUM>, a memory <NUM>, an O/S <NUM>, an input/output port (I/O) <NUM> and a display <NUM>) coupled to computer network <NUM>.

In example implementations, application <NUM> may be configured to assess service security risks based on a multi-dimensional view of vulnerabilities in the network assets used by IT service <NUM>. One or more of the vulnerability and threat detection tools (e.g., vulnerability scanner <NUM>, anti-virus (AV) tool <NUM>, policy compliance tool <NUM>, live threat feeds <NUM>, etc.) coupled to computer network <NUM> may correspond to a respective dimensional view of vulnerabilities in the network assets, and provide to application <NUM> vulnerability information about the multi-dimensional view of vulnerabilities in computer network <NUM>.

Application <NUM> (e.g., hosted on computing device <NUM>) may include one or more modules (e.g., service model module <NUM>, service criticality module <NUM>, risk dimension weights module <NUM>, security tools data module <NUM>, risk score calculator <NUM>, security controls factor module <NUM>, modified risk score calculator <NUM>, and prioritization simulator <NUM>, etc.) for processing the received vulnerability information and generating prioritization schedules for remediation of the vulnerabilities in the network assets used by IT service <NUM>.

The functions and operations of the one or more modules <NUM>-<NUM> may be configured to implement the steps (e.g., steps <NUM>- <NUM>) of a method (e.g. method <NUM>, <FIG>) for prioritizing remediation of the vulnerabilities in the network assets used by IT service <NUM>.

Application <NUM> may generate a security risk score of a network asset ("asset risk score") as a function of the threat vulnerabilities associated with the network asset, the threat agents involved, and the impact of a malicious exploit of the vulnerability by an attacker on the IT service's goals of the service provider. For purposes of generating asset risk scores, application <NUM> may consider "vulnerabilities" to include software vulnerabilities (i.e., vulnerabilities that can be remedied by code patches), system configuration vulnerabilities (i.e., vulnerabilities that can be remedied by system reconfigurations, such as server hardening, closing of network ports, etc.), and security policy violation vulnerabilities (i.e., vulnerabilities that can be remedied by policy remediation).

Further, application <NUM> may generate a service risk score of IT service <NUM> that is a normalized aggregate of the asset risk scores of the assets in computer network <NUM> associated with IT service <NUM>.

In example implementations, service model module <NUM> in application <NUM> may receive, or prepare, a service model (e.g., service model <NUM>, <FIG> and <FIG>) of the network assets used for IT service <NUM>. The service model may include the logical dependencies between the network assets (e.g., servers, databases and software applications) utilized or accessed by IT service <NUM>.

In example implementations, module <NUM> may use a network asset discovery tool to scan computer network <NUM> and obtain information on, and dependencies of, the particular network assets (e.g., software, hardware, network, storage, and services) used by IT service <NUM>. The network asset discovery tool may, for example, be a cloud discovery tool, such as BMC Discovery (which pings IP addresses of assets in the network for automated asset discovery and application dependency mapping).

Service model module <NUM> may, for example, further use an asset identification resource (e.g., a configuration management database (CMDB)) to identify the assets in computer network <NUM> and create a service model (e.g., model <NUM>) by tagging the identified assets in computer network <NUM> that belong to, or are used for, IT service <NUM>.

<FIG> and <FIG> shows an example service model <NUM> of the particular network assets used by IT service <NUM>, in accordance with the principles of the present disclosure. <FIG> shows model <NUM> with symbols, and <FIG> is a legend that explains the symbols. For the example shown in <FIG>, IT service <NUM> may be, for example, an education portal service implemented on network <NUM>. Further, the particular network assets used by IT service <NUM> may be a subset of the network assets (network asset <NUM>-<NUM>,. network asset <NUM>-n) of computer network <NUM>. The particular network assets used by IT service <NUM> and their dependencies may be depicted in service model <NUM> as a sub network (e.g., network <NUM>) of computer network <NUM>. Each of the particular network assets that is used (or can be used) by IT service <NUM> may be represented by a node (e.g., nodes 200a-200r) in network <NUM> (as shown in <FIG> and <FIG>). Each connecting edge between any two nodes in network <NUM> may represent a dependency of the respective assets that are tagged at the two nodes. For purposes of illustration, these connecting edges are shown in <FIG> by bold, dashed or dotted lines.

Application <NUM> may generate the service risk score for IT service <NUM> based on consideration of different dimensions of the service including, for example, the importance, from a business perspective, of an individual network asset within the service model (e.g., service model <NUM>), the importance of the service which uses the network assets, current security controls for the service as a whole (and not merely security controls for individual network assets), and consideration of aspects such as application security (appsec) vulnerabilities, indicators of compromise (IOCs), malware, policy violations, and configuration weakness.

Application <NUM> may process the logical dependencies between the network assets shown in the service model (e.g., service model <NUM>) to generate the service risk score based on consideration of the different dimensions of the IT service <NUM>. The security risk solutions described herein can make the service model (e.g., service model <NUM>) underlying the service risk score visible to IT administrators (who may be responsible for vulnerability remediation), for example, on display <NUM>. The IT administrators can utilize the service risk score (and the individual network assets' risk scores) in conjunction with the service model for risk prioritization and remediation of the vulnerabilities.

With renewed reference to <FIG>, service criticality module <NUM> in application <NUM> may include, or have access to, service criticality values that may be assigned by a service provider to different services (e.g., an enterprise resource planning (ERP) service, a vacation portal service, a GitLab service, an SAP DB service, etc.) implemented on network <NUM>. The service criticality value (e.g., between a low <NUM> and a high <NUM>) assigned to a service by the service provider may, for example, be based on consideration of the relative business importance of the service. For example, the ERP service may be assigned a criticality value of <NUM> as being of high business importance, and the vacation portal service may be assigned a criticality value of <NUM> as being of a lower business importance to the service provider.

For determining the asset and service risk scores for a service (e.g., IT service <NUM>), in example implementations, the service criticality module <NUM> may assign the criticality value assigned to the service by the service provider to each network asset tagged in service model <NUM> (e.g., network assets at nodes 200a- 200r in network <NUM>) as part of the IT service <NUM>. In other words, all network assets of the service inherit the assigned criticality value of the IT service <NUM>. In some implementations, other criticality value propagation rules for the network assets of an IT service can be used. These other criticality value propagation rules (which may be based on network asset type) may, for example, assign a default criticality value of <NUM> to an SAP DB asset, and a default criticality value of <NUM> to webserver assets (instead of the assigned criticality value of the IT service). This variation in the assigned criticality value for network assets of an IT service may be defined through a set of criticality value propagation rules applied by the service criticality module <NUM>.

Each risk dimension for each type of network asset may correspond to a security exposure or vulnerability type detected by the vulnerability and threat detection tools (e.g., vulnerability scanner <NUM>, anti-virus (AV) tool <NUM>, policy compliance tool <NUM>, live threat feeds <NUM>, etc.) that scan computer network <NUM> to provide vulnerability and security exposure information to application <NUM>. Thus, in the example shown in <FIG>, where there may be four types of security exposures detected by the deployed vulnerability and threat detection tools, there are four corresponding risk dimensions. The four corresponding risk dimensions may, for example, be labelled Patch Vulnerability, Malware, Policy Non-Compliance, and Public Facing (e.g., Internet Facing), respectively (see e.g., TABLE A below).

For each network asset in network <NUM> used by the service, relative risk dimension weights may be assigned (e.g., by IT administrators) to the various risk dimensions. The relative risk dimension weights may indicate a relative importance of the contribution of each dimension to a network asset's risk. Table A below shows an example of relative risk dimension weights that may assigned to various network assets (e.g., Computer1, Computer <NUM>, Network, and Firewall) used by IT service <NUM> for the four risk dimensions - Patch Vulnerability, Malware, Policy Non-Compliance, and Public Facing (e.g., Internet Facing).

In application <NUM>, module risk dimension weights <NUM> may include, or have access to, the foregoing relative risk dimension importance weights assigned to the various risk dimensions for determining the network asset risk scores.

Further, the security tools data module <NUM> in application <NUM> may include, or have access to, vulnerability information associated with the network assets used by IT service <NUM>. The vulnerability information may be obtained by the various vulnerability and threat detection tools coupled to computer network <NUM>. The vulnerability information associated with the network assets may, for example, include data related to patching vulnerabilities, policy violations, application security, malware, and asset location (e.g., whether a network asset is public facing or not), etc..

Module security tools data <NUM> may be configured to process the vulnerability information obtained by the various vulnerability and threat detection tools for each network asset to compute a numerical dimension risk value for each risk dimension of the network asset. A dimension risk value may be a function that aggregates the overall vulnerability values reported by the security tools, such as CVSS scores, policy violation scores, etc..

The risk score calculator module <NUM> in application <NUM> may include algorithms to calculate, for each network asset used by IT service <NUM>, a weighted sum of the numerical dimension risk values over all the risk dimensions of the individual network asset. Further, each network asset may be assigned an asset importance or criticality value (e.g., the assigned criticality value for assets of a service) indicating an importance of the particular network asset relative to other network assets. The network asset criticality value maybe used to scale the weighted sum of the numerical dimension risk values to obtain an asset risk score for the network asset.

In example implementations, risk score calculator module <NUM> may calculate an asset risk score for a network asset using equation <NUM>: <MAT>.

In application <NUM>, risk score calculator module <NUM> may be further configured to calculate a service risk score for IT service <NUM>. Risk score calculator module <NUM> may calculate the service risk score, for example, by aggregating the asset risk scores of all the network assets (e.g., at nodes 200a- 200r, model <NUM>) used by IT service <NUM> in network <NUM>. In example implementations, the service risk score for IT service <NUM> may be normalized, for example, by dividing the aggregated asset risk scores by the number of assets with positive (i.e., non-zero) asset risk scores.

In a numerical example of the determination of risk scores by module risk score calculator <NUM>, a network asset in network <NUM> used by IT service <NUM> may be the web server at node 200q (tagged as "Collection_IIS Webserver <NUM>" in <FIG> and referred to as Webserver (200q) in this numerical example). Webserver (200q) may have four risk dimensions:.

The four risk dimensions may have risk dimension importance weights of <NUM>, <NUM>, <NUM> and <NUM>, respectively, assigned to them (and recorded, for example, at the risk dimension weights module <NUM>). Further, the four risk dimensions - (i) public facing, (ii) malware, (iii) patch vulnerability and (iv) policy non-compliance, of Webserver (200q) may, for example, have numerical dimension risk values of <NUM>, <NUM>, <NUM> and <NUM>, respectively, (as calculated or obtained, for example, by security tools data <NUM>).

Webserver (200q) may have an assigned asset criticality value of <NUM> (indicating a high importance of Webserver (200q) relative to other network assets). Using equation <NUM> and the foregoing example risk dimension weights and dimension risk values, risk score calculator module <NUM> can calculate the asset risk score for Webserver (200q) to be: <MAT>.

Further, in the numerical example, another network asset used by IT service <NUM> may be the Web Application Firewall (or "WAF" in short) present at node <NUM> in network <NUM> (which is tagged as "F5 BIG-IP on lb-prod-mcr-<NUM>. com" at node <NUM> in <FIG> and referred to as WAF (<NUM>) in this example). WAF (<NUM>) like Webserver (200q) may have an assigned criticality value of <NUM> (indicating a high importance of WAF (<NUM>) relative to other network assets). WAF (<NUM>) may have only a single risk dimension corresponding, for example, to a named patch vulnerability "Vuln-wf1". The vulnerability Vuln-wf1 may have a dimension risk value of <NUM> (and a default dimension weight =<NUM>).

Using equation (<NUM>) and risk dimension weights and dimension risk values of WAF (<NUM>), risk score calculator module <NUM> may calculate the asset risk score for WAF (<NUM>), for example, to be: <MAT>.

For purposes of illustration, consider further a simple example in which network assets other than Webserver (200q) and WAF (<NUM>) in network <NUM> have no asset risks (i.e. asset risks = zero). In this simple example, Webserver (200q) and WAF (<NUM>) both have risk dimensions weights = <NUM>, and the service risk score for IT service <NUM> may be obtained by aggregating the asset risk scores, for example, as: <MAT>.

In examples where network assets other than Webserver (200q) and WAF (<NUM>) have non-zero asset risks, the service risk score may be computed using equation <NUM> to include the weighted contribution of the non-zero asset risks summed over all network assets.

Further, a normalized service risk score for IT service <NUM> with the two vulnerable assets - Webserver (200q) and WAF (<NUM>), may be calculated to be:
= <NUM> /<NUM> = <NUM>.

An attack surface of service is, for example, the sum of the different points in the network where an unauthorized user can try to enter data to or extract data from the service. The service risk score for IT service <NUM> calculated by risk score calculator module <NUM> may represent an attack surface of IT service <NUM>.

With renewed reference to <FIG>, computer systems (e.g., computer network <NUM>) may have built-in (or pre-existing) security or mitigation controls (e.g., features to close or block network ports, policy controls, etc.) that can be activated while network assets are running without requiring shut down or interruption of the network assets. Activating or implementing one or more of these preexisting security or mitigation controls may secure one or more of the asset vulnerabilities and can reduce the service risk score of IT service <NUM> and its attack surface.

Security control factors applicator module <NUM> in application <NUM> may include or have access to mitigation factors that can be applied to the normalized risk score to account for available preexisting security and mitigation controls in computer network <NUM>. Applying or activating the pre-existing security and mitigation controls in computer network <NUM> may eliminate or reduce the risk to IT service <NUM> from some vulnerabilities. For example, IT service <NUM> may have a high service risk score (calculated by risk score calculator module <NUM>) because it processes credit card transactions. However, IT service <NUM> may be well protected by applying an existing security control (e.g., Payment Card Industry Data Security Standard (PCI DSS)). Accordingly, modified risk score calculator module <NUM> may re-compute the normalized service risk score after applying the security control. The recomputed normalized service risk score may be referred to as the modified service risk score for the IT service <NUM>.

Prioritization simulator module <NUM> in application <NUM> may be configured to recommend prioritization schedules for remediation of network asset vulnerabilities in computer network <NUM> to secure IT service <NUM>. In example implementations, module prioritization simulator <NUM> may be configured to simulate the effect of different remediation schedules on the service risk score (normalized or modified service risk scores) of IT service <NUM>. The simulations may take into account vulnerability interdependencies by considering the effects of each remediation action on multiple network asset vulnerabilities. Prioritization simulator module <NUM> may prioritize and recommend a schedule of remediation actions according to the simulated effect of the remediation actions on lowering the service risk score. The effect of known remediation actions may be considered on a per network asset basis. In the simulations, the service risk score may be computed for each remediation action and the one that results in the largest reduction in service risk may be recommended as the first remediation action to be implemented.

As an illustrative example of the effect of a remediation action on multiple network asset vulnerabilities, consider a simulation scenario in which two assets (e.g., the web server (IIS Webserver) at node 200j, and the WAF (F5 BIG-IP on lb-prod-mcr-<NUM>. com) at node <NUM> are network assets at risk in network <NUM>. The two assets (referred to as Webserver (200j) and WAF (<NUM>) in this example) may both have criticality values equal to <NUM> indicating high importance.

Further, Webserver (200j) may, for example, have five risks:.

Further, WAF (<NUM>) may, for example, have one risk:
Patch vulnerability: Vuln-wf1.

Some of the risks listed above may be interrelated. For example, WannaCry malware tries to spread by infecting hosts that have port <NUM> (a traditional Microsoft networking port) open to the Internet with a version of Server Message Block (SMB) and running an unpatched version of Windows on the hosts.

Webserver (200j) may, for example, have an asset risk score of <NUM> and WAF(<NUM>) may, for example, have an asset risk score of <NUM> as determined by risk score calculator module <NUM>. The service risk score for IT service <NUM> may be obtained by aggregating the asset risk scores, for example, as: <MAT>.

Further, an initial normalized service risk score for IT service <NUM> with the two vulnerable assets - Webserver (200j) and WAF (<NUM>), may be calculated to be: = <NUM>/<NUM> = <NUM>.

Activating a remediation action for the asset Webserver (200j) (i.e., a policy control of blocking open port <NUM>) may not only remedy a first vulnerability (i.e., Port <NUM> open), but may also remedy a second vulnerability (i.e., CVE-WannaCry) by blocking WannaCry malware's attack path to Webserver (200j) via open port <NUM>.

After the remedy of blocking open port <NUM> is applied in the simulation, Webserver (200j) may, for example, have an asset risk score of <NUM> as determined by risk score calculator module <NUM> leading to a determination that IT service <NUM> now has a <MAT>.

Prioritization simulator module <NUM> in application <NUM> may be configured to perform "what-if" simulations of known remediation actions on a per network asset basis, such as described in the foregoing simulation scenario. The service risk score may be recomputed after applying each available remediation action in the simulation. A remediation action that results in a large reduction in the service risk score may be recommended for securing a service (e.g., IT service <NUM>) with a higher priority than other remediation actions that result in smaller reductions in the service risk score. A sequence of recommended remediation actions may be optimized to obtain the lowest service risk score for securing a service (e.g., IT service <NUM>).

Table B shows an example sequence of three prioritized remediation actions (e.g., Modify Policy control to block port <NUM>, Patch CVE-<NUM>-<NUM>, and Patch Vuln-wf1) that may be recommended by prioritization simulator module <NUM> in the above-discussed simulation scenario involving the two network assets- Webserver (200j) and WAF (<NUM>). The three remediation actions are individually listed in Table B as priority <NUM>, priority <NUM>, and priority <NUM> according to the expected reductions in the service risk score on applying the individual remediation action.

<FIG> shows an example method <NUM> for identifying security risks of an IT service (e.g., IT service <NUM>) arising from vulnerabilities and recommending a schedule for remediation of the vulnerabilities.

Method <NUM> includes establishing a service model identifying the network assets used by the IT service implemented on a computer network, and describing dependencies of the network assets in the computer network (<NUM>), assigning a service criticality value of the IT service to the network assets used by the service (<NUM>), assigning a relative risk dimension weight to each vulnerability risk dimension associated with a network asset used by the IT service (<NUM>), and identifying one or more vulnerabilities in each of the network assets (using , e.g., network security scanning tools) (<NUM>). Identifying the vulnerabilities may include determining risk values for each of the risk dimensions associated with the network asset using information gathered by the network security scanning tools (e.g., Qualys, Nessus, or Rapid7, BMC's SecOPS Policy service, live threat feeds, etc.).

Method <NUM> further includes determining an asset risk score for each of the network assets (<NUM>), determining a service risk score (<NUM>), and modifying the service risk score after applying one or more pre-existing mitigation or security controls (<NUM>).

Method <NUM> may further include recommending a vulnerability remediation schedule based on simulated reductions in the service risk score on applying vulnerability remediation actions (<NUM>).

Method <NUM> may involve what-if simulations of the effect of a set of remediation actions (on a per asset basis) on the service risk score. A set of remediation actions may be recommended for implementation to secure the service. A remediation action which results in a larger reduction in the service risk score may be prioritized over other remediation actions that result in smaller reductions in the service score.

Method <NUM> may include securing the IT service by implementing the recommended remediation actions (<NUM>).

Implementations of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Implementations may be implemented as a computer program product, i.e., a computer program tangibly embodied in a non-transitory information carrier, e.g., in a machine-readable storage device (computer-readable medium) for processing by, or to control the operation of, data processing apparatuses, e.g., programmable processors or multiple computers. A computer program, such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be processed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communications network.

Method steps may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method steps also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

Processors suitable for the processing of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory or both. Generally, a computer also may include, or be operatively coupled to receive data from or transfer data to, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of nonvolatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CDROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in special purpose logic circuitry.

To provide for interaction with a user, implementations may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.

Implementations may be implemented in a computer network that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communications network. Examples of communications networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.

Claim 1:
A computer-implemented method for securing a service implemented on a computer network (<NUM>), wherein the service involves multiple network assets, the method comprising:
identifying network assets (<NUM>-n) in the computer network (<NUM>) used by the service, with describing logical dependencies of the network assets (<NUM>-n) in the computer network (<NUM>) by a service model;
identifying computer security vulnerabilities in one or more of the network assets (<NUM>-n), each computer security vulnerability having one or more vulnerability risk dimensions, wherein the computer security vulnerabilities are identified with determining a risk value for each vulnerability risk dimension, by using information obtained from one or more network security tools;
based on the identified computer security vulnerabilities, determining an asset risk score for each of the network assets (<NUM>-n), based on the risk values of the vulnerability risk dimensions of the vulnerabilities in each of the network assets, by using an asset criticality value as a multiplier, wherein the asset criticality value indicates an importance of each network asset relative to other network assets, and by applying the criticality value to a sum of the one or more vulnerability risk dimensions as weighted by the risk value for each of the vulnerability risk dimensions;
based on the determined asset risk scores of the network assets (<NUM>-n), determining a service risk score for the service, by processing the logical dependencies between the network assets in the service model and by aggregating the asset risk scores of the network assets (<NUM>-n) used by the service; and
prioritizing implementation of one or more vulnerability remediation actions on the computer network (<NUM>) to best reduce the service risk score and secure the service.