**4.4 Step 4: Determining threat**

In this phase, information on potential threats to the organizational assets and information is gathered that may have a direct or an indirect impact on the business process. This includes collecting details of the threats on each IT entities from inside and outside users or attackers. This ultimately guides the risk assessment process for the necessary remediation plan and action to protect the organizational resources.

### **4.5 Step 5: Risk assessment**

This phase focuses on determining the probability and impact of the vulnerabilities in the entities of IT systems. As all threats do not have the likelihood of equal occurrence and impact on the organizations' infrastructure, so it is crucial to correctly identify different levels of risk. Hence, each level of risk is determined by mapping individual threats, exposure, and vulnerabilities of an entity based on their probability and impact to critical resources of the organization. This, in turn, helps in decision making on the implementation of appropriate remediation acts.

### **4.6 Step 6: Risk mitigation**

Once the risk assessment is performed, the final step for IT managers is to plan and act according to take preventive measures for potential threats to the organizations. It may consist of different measures such as identifying different threats before their occurrence, minimizing or eliminating the consequences of security breaches, recovering to a safe state to resume normal business process, etc.

Generally, the V3 standard is an improvement over the V2 standard as V3 considers the context of attacker's access rights to read/write/execute to exploit the vulnerability and physical manipulation of the affected components. Hence, the risk assessment module uses the V3 version of CVE as its CVS value for necessary risk assessment for secure business processes and information flow. However, for some older vulnerabilities there exist only V2 values in NVD. In such a case, the CVS value for a vulnerability is calculated in two steps from the available V2 metrics in

*Parsing CVE values from NVD and storing as CVS values in local vulnerability database for risk assessment.*

To compute the overall vulnerability value, CVSS considers certain metrics that define the hardware, software and network-level vulnerabilities in the IT systems. The V2 version differs from the V3 version in terms of the metrics and their values considered for overall vulnerability score computation. However, for some older vulnerabilities, V3 value is not available in the NVD. In this scenario, the CVS value for a vulnerability in our solution is estimated from the V2 metrics available in the XML file by appropriately transforming the metrics and their values as shown in **Table 1**. The transformation is performed as per the CVSS V2 and V3 standards

These metrics after the transformation process are then used for the necessary CVS computation in the proposed mechanism. The estimation of CVS value for a

The CVS value for a vulnerability is determined from the desired metrics obtained in the previous step, using the standard equations for the overall V3 version of CVSS computation [24] with optimization to minimize the overhead of the CVS computation process. The procedure of the overall CVS value calculation is

The entities of the IT infrastructure might be the potential sources of vulnerabilities in the organization. Hence, the vulnerability of each entity is determined by

vulnerability is performed as explained below in the subsequent step.

NVD as discussed below.

*Risk Assessment in IT Infrastructure*

*DOI: http://dx.doi.org/10.5772/intechopen.90907*

[23, 24].

**99**

**Figure 2.**

*5.1.1 Step 1: Transformation of V2 metrics*

*5.1.2 Step 2: Calculation of CVS values*

illustrated in **Figure 3**.

## **5. IT risk assessment framework**

In this chapter, an effective IT assessment framework is presented to ensure a strong security perimeter over the vulnerable IT environment of the organizations.

### **5.1 Vulnerability analysis**

The Common Vulnerability Scoring System (CVSS) [2] plays an important role in the risk assessment of the entities in the IT infrastructure to ensure secure business information flow across the IT systems. The risk assessment module uses a data structure called vulnerability database for this purpose. The vulnerability database is a local repository (offline) stored in the controller. It is periodically updated with the recent Common Vulnerability Score (CVS) values of the applications or protocols or services running in different hardware and software components or entities of IT infrastructure. The CVS values are computed by extracting necessary metrics from the online National Vulnerability Database (NVD) [22] using a script.

The recent vulnerability values available in NVD are in XML format which contains two standard scores: V2 and V3 in the form of Common Vulnerability and Exposure (CVE) measures. The detailed process of parsing CVE values from NVD and storing in the local vulnerability database as CVS values is explained in **Figure 2**. It is to be noted that in the vulnerability database, there exists exactly one entry of CVS value for an application with its version and the Operating System platform as it is the updated CVSS value of the application parsed from NVD's recent XML file using the script. The structure of an entry in the vulnerability database is < *Application=service=protocol*, *Version*, *Operating system*, *CVS value*>.

*Risk Assessment in IT Infrastructure DOI: http://dx.doi.org/10.5772/intechopen.90907*

### **Figure 2.**

**4.4 Step 4: Determining threat**

**4.5 Step 5: Risk assessment**

**4.6 Step 6: Risk mitigation**

**5. IT risk assessment framework**

**5.1 Vulnerability analysis**

using a script.

**98**

In this phase, information on potential threats to the organizational assets and information is gathered that may have a direct or an indirect impact on the business process. This includes collecting details of the threats on each IT entities from inside and outside users or attackers. This ultimately guides the risk assessment process for the necessary remediation plan and action to protect the organizational resources.

*Security and Privacy From a Legal, Ethical, and Technical Perspective*

This phase focuses on determining the probability and impact of the vulnerabilities in the entities of IT systems. As all threats do not have the likelihood of equal occurrence and impact on the organizations' infrastructure, so it is crucial to correctly identify different levels of risk. Hence, each level of risk is determined by mapping individual threats, exposure, and vulnerabilities of an entity based on their probability and impact to critical resources of the organization. This, in turn, helps

Once the risk assessment is performed, the final step for IT managers is to plan and act according to take preventive measures for potential threats to the organizations. It may consist of different measures such as identifying different threats before their occurrence, minimizing or eliminating the consequences of security breaches, recovering to a safe state to resume normal business process, etc.

In this chapter, an effective IT assessment framework is presented to ensure a strong security perimeter over the vulnerable IT environment of the organizations.

The Common Vulnerability Scoring System (CVSS) [2] plays an important role

in the risk assessment of the entities in the IT infrastructure to ensure secure business information flow across the IT systems. The risk assessment module uses a data structure called vulnerability database for this purpose. The vulnerability database is a local repository (offline) stored in the controller. It is periodically updated with the recent Common Vulnerability Score (CVS) values of the applications or protocols or services running in different hardware and software components or entities of IT infrastructure. The CVS values are computed by extracting necessary metrics from the online National Vulnerability Database (NVD) [22]

The recent vulnerability values available in NVD are in XML format which contains two standard scores: V2 and V3 in the form of Common Vulnerability and Exposure (CVE) measures. The detailed process of parsing CVE values from NVD and storing in the local vulnerability database as CVS values is explained in

**Figure 2**. It is to be noted that in the vulnerability database, there exists exactly one entry of CVS value for an application with its version and the Operating System platform as it is the updated CVSS value of the application parsed from NVD's recent XML file using the script. The structure of an entry in the vulnerability database is < *Application=service=protocol*, *Version*, *Operating system*, *CVS value*>.

in decision making on the implementation of appropriate remediation acts.

*Parsing CVE values from NVD and storing as CVS values in local vulnerability database for risk assessment.*

Generally, the V3 standard is an improvement over the V2 standard as V3 considers the context of attacker's access rights to read/write/execute to exploit the vulnerability and physical manipulation of the affected components. Hence, the risk assessment module uses the V3 version of CVE as its CVS value for necessary risk assessment for secure business processes and information flow. However, for some older vulnerabilities there exist only V2 values in NVD. In such a case, the CVS value for a vulnerability is calculated in two steps from the available V2 metrics in NVD as discussed below.

### *5.1.1 Step 1: Transformation of V2 metrics*

To compute the overall vulnerability value, CVSS considers certain metrics that define the hardware, software and network-level vulnerabilities in the IT systems. The V2 version differs from the V3 version in terms of the metrics and their values considered for overall vulnerability score computation. However, for some older vulnerabilities, V3 value is not available in the NVD. In this scenario, the CVS value for a vulnerability in our solution is estimated from the V2 metrics available in the XML file by appropriately transforming the metrics and their values as shown in **Table 1**. The transformation is performed as per the CVSS V2 and V3 standards [23, 24].

These metrics after the transformation process are then used for the necessary CVS computation in the proposed mechanism. The estimation of CVS value for a vulnerability is performed as explained below in the subsequent step.

### *5.1.2 Step 2: Calculation of CVS values*

The CVS value for a vulnerability is determined from the desired metrics obtained in the previous step, using the standard equations for the overall V3 version of CVSS computation [24] with optimization to minimize the overhead of the CVS computation process. The procedure of the overall CVS value calculation is illustrated in **Figure 3**.

The entities of the IT infrastructure might be the potential sources of vulnerabilities in the organization. Hence, the vulnerability of each entity is determined by


the above-mentioned steps. Then, the threat for different entities is determined using the threat model using vulnerability and exposure analysis of those entities. Then, the overall risk of the IT systems is determined as cumulative threat values of

In this phase, the threat associated with different IT entities is modeled using the

Several vulnerable applications, services or protocols such as FTP, RSH, Nmap, etc. may be running in an IT entity for the functioning of business processes. The vulnerability *Ve* of an entity *e* is calculated as the average of the Common Vulnerability Scores (CVS) of all the applications running on the entity extracted from the

> P*<sup>k</sup> <sup>i</sup>*¼<sup>1</sup>*CVSi*

where *CVSi* is the Common Vulnerability Score of the *i*th application or protocol or service running in the entity *e*, and *k* is the number of applications, protocols, and/or services running in the entity. The average value of the CVS of all applications, protocols and/or services is divided by 10 to normalize the value of *Ve* to 1 as

The exposure *Ee* of an entity *e* is determined considering the number of entities that may be affected because of the vulnerability in the target entity. Hence, it is

*Ee* <sup>¼</sup> *<sup>n</sup>*

where *n* is the number of entities communicating with the target entity and *N* is

The vulnerability values and threat models guide the risk assessment process for

*<sup>k</sup>* (1)

*<sup>N</sup>* (2)

the entities and criticality of the business process and information flow.

**V2 metric Value Transformed metric Value**

Low: 0.5 Confidentiality,

integrity, and availability requirements

Medium: 1.0 Medium: 1.0 High: 1.51 High: 1.5

Low: 0.5

*Ve* <sup>¼</sup> <sup>1</sup> <sup>10</sup> <sup>∗</sup>

vulnerability and exposure of the entities as follows.

*Transformation of V2 metrics and their values for CVS computation.*

**5.2 Threat model**

Impact subscore modifier

**Table 1.**

Confidentiality, integrity, and availability requirements

*DOI: http://dx.doi.org/10.5772/intechopen.90907*

*Risk Assessment in IT Infrastructure*

*5.2.1 Vulnerability of an entity*

vulnerability database, that is,

the CVS lies between 0 and 10.

the total number of entities in the IT systems.

estimating risk levels of the entities in the IT infrastructure.

*5.2.2 Exposure of an entity*

computed as,

**101**


### **Table 1.**

**V2 metric Value Transformed metric Value**

Adjacent network:

0.646

*Security and Privacy From a Legal, Ethical, and Technical Perspective*

Access vector Local: 0.395 Attack vector Local: 0.55

Access complexity High: 0.35 Attack complexity High: 0.44

Authentication Multiple: 0.45 Privileges required High: 0.27

None: 0.0 Confidentiality,

Exploitability Unproven: 0.85 Exploitability Unproven: 0.91

Remediation level Official fix: 0.87 Remediation level Official fix: 0.95

Report confidence Unconfirmed: 0.90 Report confidence Unknown: 0.92

Proof-of-concept:

Uncorroborated:

High (catastrophic loss): 0.5

0.95

0.9

Network: 1.0 Network: 0.85

Medium: 0.61 Medium: 0.62 Low: 0.71 Low: 0.77

Single: 0.56 Low: 0.62 None: 0.704 None: 0.85

> integrity, and availability

Partial: 0.275 Low: 0.22 Complete: 0.66 High: 0.56

Functional: 0.95 Functional: 0.97 High: 1.0 High: 1.0

Temporary fix: 0.90 Temporary fix: 0.96 Workaround: 0.95 Workaround: 0.97 Unavailable: 1.0 Unavailable: 1.0

Confirmed: 1.0 Confirmed: 1.0

None: 0 Attack vector None: 0 Low (light loss): 0.1 Physical: 0.2 Low-medium: 0.3 Local: 0.55 Medium-high: 0.4 Adjacent network:

None: 0 Attack complexity None: 0

Low: 0.25 Low: 0.77 Medium: 0.75 Medium: 0.62 High: 1.0 High: 0.44

Adjacent: 0.62

None: 0.0

Proof-of-concept:

Reasonable: 0.96

0.62

Network: 0.85

0.94

Base metrics Exploitability group

Impact group Confidentiality,

Temporal metrics

Environmental metrics

Collateral damage potential

Target distribution

General modifiers

**100**

integrity, and availability

*Transformation of V2 metrics and their values for CVS computation.*

the above-mentioned steps. Then, the threat for different entities is determined using the threat model using vulnerability and exposure analysis of those entities. Then, the overall risk of the IT systems is determined as cumulative threat values of the entities and criticality of the business process and information flow.
