🤟🏻 ♠️ 👎 Analysis of international documents on information security risk management. Part 1 🈺 🍡 🚴🏾

Friends, in a previous postWe reviewed regulatory documents on information protection in the Russian credit and financial sector, some of which refer to information security risk assessment and management methodologies. Generally speaking, from a business perspective, information security management is a subsidiary process of a wider risk management process: if a company, after analyzing and evaluating all its business risks, concludes that the risks of information security are relevant, then information protection itself comes into play as a way to minimize some risks. Risk management allows you to efficiently and rationally build IS processes and allocate resources to protect company assets, and risk assessment allows you to apply appropriate measures to minimize them: to protect against significant and relevant threats, it will be logical to use more expensive solutions,than to counter insignificant or difficult to implement threats.

In addition, the built-in IS risk management process will allow developing and, if necessary, applying clear plans for ensuring business continuity and disaster recovery (Business Continuity & Disaster Recovery): a deep study of various risks will help to take into account, for example, a sudden need for remote access for a large number of employees, as this may happen in the event of an epidemic or collapse of the transport system. So, in this publication - an analysis of international documents on information security risk management. Enjoy reading!

The general concept of IS risk management

Information security risk, or cyber risk, is understood to mean the potential possibility of exploiting asset vulnerabilities as a specific threat to harm the organization. The value of risk conditionally means the product of the probability of a negative event and the amount of damage. In turn, the probability of an event is understood as the product of the probability of a threat and the danger of vulnerability, expressed in qualitative or quantitative form. Conventionally, we can express this with the logical formula:
ValueRisk = Probability of an Event * Size of Damage , where the Probability of an Event = Probability of Threats * Value of Vulnerability

There are also conditional risk classifications: by source of risk (for example, attacks by hackers or insiders, financial errors, the impact of government regulators, legal claims by contractors, negative informational impact of competitors); by purpose (information assets, physical assets, reputation, business processes); by the duration of influence (operational, tactical, strategic).

The goals of IS risk analysis are as follows:

Identify assets and evaluate their value.
Identify threats to assets and security vulnerabilities.
Calculate the likelihood of threats and their impact on the business.
Maintain a balance between the cost of possible negative consequences and the cost of protective measures, give recommendations to the management of the company on the processing of identified risks.

Steps 1 through 3 are a risk assessment and are a collection of available information. Stage 4 is already a direct risk analysis (English risk analysis), i.e. study of the data collected and the issuance of results / directions for further action. It is important to understand your own level of confidence in the correctness of the assessment. Stage 4 also offers processing methods for each of the relevant risks: transfer (for example, through insurance), avoidance (for example, refusal to introduce a particular technology or service), acceptance (conscious willingness to suffer damage in case of risk), minimization ( application of measures to reduce the likelihood of a negative event leading to the realization of the risk).After completing all stages of the risk analysis, you should select an acceptable risk level for the company, establish the minimum possible level of safety (English baselines of performance), then implement countermeasures and further evaluate them in terms of the attainability of the established minimum possible level security.

Damage from the implementation of an attack can be direct or indirect .

Direct damage is the immediate obvious and easily predicted loss of the company, such as loss of intellectual property rights, disclosure of production secrets, reduction of the value of assets or their partial or complete destruction, legal costs and payment of fines and compensations, etc.

Indirect damage can result in quality or indirect loss.
Qualitative losses can be a suspension or decrease in the efficiency of a company, loss of customers, decrease in the quality of manufactured goods or rendered services. IndirectLosses are, for example, lost profits, loss of goodwill, and additional expenses incurred. In addition, in the foreign literature there are also such concepts as total risk (Eng. Total risk), which is present, if no protective measures are implemented at all, as well as residual risk (Eng. Residual risk), which is present if the threats are realized, despite the implemented protection measures.

Risk analysis can be both quantitative and qualitative .

Consider one of the methods of quantitative risk analysis. The main indicators are the following values:

ALE - annual loss expectancy; “Cost” of all incidents per year.
SLE - single loss expectancy, expected one-time losses, i.e. "Cost" of one incident.
EF - exposure factor, factor of openness to the threat, i.e. what percentage of the asset the threat will destroy if it is successfully implemented.
ARO - annualized rate of occurrence, the average number of incidents per year according to statistics.

The SLE value is calculated as the product of the estimated asset value and the EF value, i.e. SLE = AssetValue * EF . At the same time, the cost of the asset should include penalties for its insufficient protection.

The value of ALE is calculated as the product of SLE and ARO, i.e. ALE = SLE * ARO. ALE value will help to rank the risks - the risk with high ALE will be the most critical. Further, the calculated ALE value can be used to determine the maximum cost of the implemented protective measures, since, according to the generally accepted approach, the cost of protective measures should not exceed the value of the asset or the amount of the predicted damage, and the estimated reasonable cost of the attack for the attacker should be less than the expected profit from the implementation of this attack. The value of protective measures can also be determined by subtracting from the calculated ALE value before the implementation of protective measures the value of the calculated ALE value after the implementation of protective measures, as well as by subtracting the annual costs of implementing these measures. Conditionally write this expression as follows:

(The value of protective measures for the company) = (ALE before the implementation of protective measures) - (ALE after the implementation of protective measures) - (Annual costs of implementing protective measures)

Examples of qualitative risk analysis can be, for example, the Delphi method, in which an anonymous survey of experts is conducted in several iterations until consensus is reached, as well as brainstorming and other examples of so-called assessment "Expert method."

Next, we give a brief and non-exhaustive list of various risk management methodologies , and the most popular of them we will consider in more detail below.

1. The NIST Risk Management Framework based on US government documents NIST (National Institute of Standards and Technology, National Institute of Standards and Technology USA) includes a set of interconnected so-called "Special publications" (Eng. Special Publication (SP), we will call them standards for ease of perception):

1.1. The NIST SP 800-39 standard “Managing Information Security Risk” offers a three-level approach to risk management: organization, business processes, information systems. This standard describes the methodology of the risk management process: identification, assessment, response and monitoring of risks.
1.2. NIST SP 800-37, the Risk Management Framework for Information Systems and Organizations, proposes a system lifecycle management approach for security and privacy.
1.3. The NIST SP 800-30 Standard, Guide for Conducting Risk Assessments, focuses on IT, IS, and operational risks. It describes an approach to the processes of preparing and conducting a risk assessment, communicating the results of an assessment, and further supporting the assessment process.
1.4. The NIST SP 800-137 standard “Information Security Continuous Monitoring” describes an approach to the monitoring process of information systems and IT environments in order to control the measures taken to handle IS risks and the need to review them.

2. The standards of the International Organization for Standardization ISO (International Organization for Standardization):

2.1. Standard ISO / IEC 27005: 2018 "Information technology - Security techniques - Information security risk management" ("Information technology. Methods and security tools. Information security risk management") is part of a series of ISO 27000 standards and is logically interconnected with other standards for IB from this series. This standard has a focus on information security when considering risk management processes.
2.2. The ISO / IEC 27102: 2019 standard “Information security management - Guidelines for cyber-insurance” offers approaches to assessing the need to acquire cyber insurance as a risk treatment measure, as well as to assessing and interacting with the insurer.
2.3. The ISO / IEC 31000: 2018 series of standards describes an approach to risk management without being tied to IT / IS. In this series, it is worth noting the ISO / IEC 31010: 2019 standard “Risk management - Risk assessment techniques” - for this standard in its domestic version GOST R ISO / IEC 31010-2011 “Risk management. Methods of risk assessment ”refers 607-P of the Central Bank of the Russian Federation“ On requirements for the procedure for ensuring uninterrupted operation of the payment system, indicators of uninterrupted operation of the payment system and methods of risk analysis in the payment system, including risk profiles ”.

3. The FRAP (Facilitated Risk Analysis Process) methodology is a relatively simplified risk assessment method, with a focus on only the most critical assets. Qualitative analysis is carried out using expert judgment.

4. The OCTAVE methodology (Operationally Critical Threat, Asset, and Vulnerability Evaluation) is focused on the independent work of members of business units. It is used for large-scale assessment of all information systems and business processes of a company.

5. AS / NZS 4360 is an Australian and New Zealand standard with a focus not only on IT systems, but also on the company's business health, i.e. offers a more global approach to risk management. Note that this standard is currently replaced by AS / NZS ISO 31000-2009.

6. The FMEA (Failure Modes and Effect Analysis) methodology offers an assessment of the system in terms of its weak points for finding unreliable elements.

7. The CRAMM (Central Computing and Telecommunications Agency Risk Analysis and Management Method) methodology proposes the use of automated risk management tools.

8. The FAIR methodology (Factor Analysis of Information Risk) is a proprietary framework for conducting quantitative risk analysis, which offers a model for building a risk management system based on a cost-effective approach, informed decision making, comparison of risk management measures, financial indicators and accurate risk models.

9. The concept of COSO ERM (Enterprise Risk Management) describes ways to integrate risk management with the strategy and financial performance of the company and focuses on the importance of their relationship. The document describes such risk management components as strategy and goal setting, economic efficiency of the company, risk analysis and review, corporate governance and culture, as well as information, communication and reporting.

NIST Risk Management Framework

The first set of documents will be the Risk Management Framework of the American National Institute of Standards and Technology (NIST). This institute issues information security documents as part of a series of FIPS (Federal Information Processing Standards) and SP (Special Publications, 800 Series) recommendations. This series of publications is characterized by logical interconnectedness, detail, a single terminological base. Among the documents related to information security risk management, NIST SP 800-39, 800-37, 800-30, 800-137 and 800-53 / 53a should be noted.

The creation of this set of documents was a consequence of the adoption of the US Federal Information Security Management Act (FISMA, 2002) and the US Federal Information Security Modernization Act (FISMA, 2014). Despite the declared “binding” of NIST standards and publications to US law and the mandatory implementation of them for US government agencies, these documents can be considered as suitable for any company seeking to improve IS management, regardless of jurisdiction and form of ownership.

NIST SP 800-39

So, NIST SP 800-39 “Managing Information Security Risk: Organization, Mission, and Information System View” offers a vendor-independent, structured, but flexible approach to IS risk management in the context of the operations of a company, assets, individuals and counterparties. At the same time, risk management should be a holistic process that affects the entire organization in which risk-based decision-making is practiced at all levels. Risk management is defined in this document as a comprehensive process, which includes the steps of identifying (frame), assessing (assess), processing (respond) and monitoring (monitor) risks. Consider these steps in more detail.

1. At the stage of determining the risks of the organization should identify:

risk assumptions, i.e. identify current threats, vulnerabilities, consequences, the likelihood of risks;
risk limits, i.e. assessment, response, and monitoring capabilities;
risk tolerance, i.e. risk tolerance - acceptable types and levels of risks, as well as an acceptable level of uncertainty in risk management issues;
priorities and possible compromises, i.e. it is necessary to prioritize business processes, to study the trade-offs that an organization can make when processing risks, as well as the time constraints and uncertainties that accompany this process.

2. At the stage of risk assessment, the organization should identify:

IS threats, i.e. specific actions, persons or entities that may constitute threats to the organization itself or may be directed to other organizations;
internal and external vulnerabilities, including organizational vulnerabilities in company management business processes, IT systems architecture, etc .;
damage to the organization, taking into account the possibilities of exploiting vulnerabilities by threats;
the likelihood of damage.

As a result, the organization receives the determinants of risk, i.e. damage level and probability of occurrence of damage for each risk.

To ensure the risk assessment process, the organization pre-determines:

tools, techniques and methodologies used for risk assessment;
assumptions regarding risk assessment;
restrictions that may affect risk assessments;
roles and responsibilities;
ways to collect, process and transmit risk assessment information within the organization;
ways to conduct a risk assessment in the organization;
frequency of risk assessment;
ways to obtain information about threats (sources and methods).

3. At the risk response stage, the organization performs the following activities:

developing possible risk response plans;
assessment of possible risk response plans;
determination of risk response plans acceptable from the point of view of the organization's risk tolerance;
implementation of accepted risk response plans.

In order to be able to respond to risks, the organization determines the types of possible risk treatment (accepting, avoiding, minimizing, sharing or transferring risk), as well as tools, technologies and methodologies for developing response plans, methods for evaluating response plans and notification methods of response measures taken within organizations and / or external counterparties.

4. At the stage of risk monitoring, the following tasks are solved:

verification of the implementation of adopted risk response plans and compliance with IS requirements;
determining the current effectiveness of risk response measures;
- - , , , - , -, , - ..

Organizations describe methods for assessing regulatory compliance and the effectiveness of risk responses, as well as how changes are controlled that can affect the effectiveness of risk responses.

Risk management is carried out at the levels of the organization, business processes and information systems, while interconnection and exchange of information between these levels should be ensured in order to continuously improve the effectiveness of the actions taken and the communication of risks to all stakeholders. At the upper level (organization level), decisions are made to identify risks, which directly affects the processes conducted at the lower levels (business processes and information systems), as well as the financing of these processes.

Organization leveldevelopment and implementation of management functions that are consistent with the organization’s business goals and regulatory requirements are carried out: the creation of a risk management function, the appointment of those responsible, the implementation of a risk management strategy and the determination of risk tolerance, the development and implementation of investment strategies in IT and information security.

At the level of business processes , the definition and creation of risk-oriented business processes and organizational architecture are carried out, which should be based on segmentation, resource reservation and the absence of single points of failure. In addition, at this level, the development of information security architecture is being carried out, which will ensure the effective implementation of information security requirements and the implementation of all necessary measures and means of protection.

At the level of information systemsit is necessary to ensure the implementation of decisions taken at higher levels, namely, to ensure IS risk management at all stages of the systems life cycle: initialization, development or acquisition, implementation, use and decommissioning. The document emphasizes the importance of resilience of IT systems, which is an indicator of the viability of a company's business functions.

Note that in Appendix “H” to the document considered in this document, each of the risk treatment methods listed in the risk response stage is described. So, it is indicated that the organization should have both a general strategy for choosing a specific risk treatment method in a given situation, and separate strategies for each of the risk treatment methods. The basic principles of choosing one or another approach to risk management are indicated:

(acceptance) - ;
(avoidance) , - , -;
(share) (transfer) — , — - ;
( ) (mitigation) . - , , , , , .

The document also pays great attention to organizational culture and trust in suppliers / contractors as factors for successful risk management. In particular, it is said that the organizational culture and top managers of the company directly affect the decisions chosen for risk management, therefore, the overall risk management strategy should take into account the risk appetite of the company and reflect the actual methods of risk management. Models for building trust with counterparties and suppliers are described in Appendix “G”: models based on checks of contractors (for example, through audits), historical trust (when the counterparty made no violations during the long-term history of relations), trust to a third party ( which conducts an independent evaluation of counterparties), on a credential trust (in the casewhen regulatory requirements establish trust requirements for such a supplier), as well as a hybrid model.

NIST SP 800-37

Now let's move on to NIST SP 800-37 “Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy” (“Risk management framework for information systems and organizations: the life cycle of systems for security and privacy”) .

Current document has revision №2 and was updated in December 2018 in order to take into account the modern landscape of threats and to emphasize the importance of risk management at the level of heads of the companies, to emphasize the link between risk management framework (Risk Management Framework, RMF) and cyber-security framework ( Cybersecurity Framework, CSF), point out the importance of integrating privacy management processes and supply chain risk management (SCRM), and also logically link the list of proposed security measures (controls) to the NIST document SP 800-53. In addition, the implementation of the provisions of NIST SP 800-37 can be used if necessary to conduct a mutual assessment of the risk management procedures of companies in cases where these companies need to exchange data or resources. By analogy with NIST SP 800-39, risk management is considered at the levels of organization, mission, information systems.

NIST SP 800-37 states that the Risk Management Framework as a whole indicates the importance of developing and implementing security and confidentiality capabilities in IT systems throughout the entire life cycle (system development life cycle, SDLC), continuous support of situational awareness on the state of protection of IT systems using continuous monitoring (CM) processes and providing information to management for making informed risk-based decisions. The following types of risks are identified in RMF: program risk, non-compliance risk, financial risk, legal risk, business risk, political risk, security and confidentiality risk (including supply chain risk), project risk, reputational risk, life safety risk, strategic risk planning.

In addition, the Risk Management Framework:

provides a repeatable process for risk-based protection of information and information systems;
Emphasizes the importance of preparatory activities for managing security and privacy;
provides categorization of information and information systems, as well as the selection, implementation, evaluation and monitoring of protective equipment;
suggests using automation tools to manage risks and protective measures in near real-time mode, as well as relevant time metrics to provide information to management for decision-making;
connects risk management processes at various levels and indicates the importance of choosing those responsible for taking protective measures.

The document contains 7 steps for applying RMF:

, .. -;
( , NIST SP 800-30 3 , : , , );
() ;
, ;
, , ;
;
, , , .

Further, the NIST SP 800-37 publication lists the tasks that should be performed at each stage of the application of RMF. For each task, the name of the task (control) is indicated, the input and output (resulting) data of the process are listed with reference to the categories of the corresponding CSF controls, a list of responsible and auxiliary roles, an additional description of the task, and, if necessary, links to related NIST documents are given.

We list below the tasks for each of the stages of applying RMF.

The objectives of the “ Preparation ” phase at the organization level include:

definition of roles for risk management;
creation of a risk management strategy, taking into account the risk tolerance of the organization;
risk assessment;
selection of target values of protection measures and / or profiles from the Cybersecurity Framework document;
Definition for IT systems of general protection measures that can be inherited from higher levels (for example, from the level of organization or business processes)
prioritization of IT systems;
development and implementation of a strategy for continuous monitoring of the effectiveness of protective measures.

The tasks of the “ Preparation ” stage at the level of IT systems include:

Defining the business functions and processes that each IT system supports
identification of persons (stakeholders) interested in the creation, implementation, evaluation, functioning, support, decommissioning of systems;
identification of assets requiring protection;
determination of the authorization boundary for the system;
identification of types of information processed / transmitted / stored in the system;
identification and analysis of the life cycle of all types of information processed / transmitted / stored in the system;
conducting risk assessments at the level of IT systems and updating the list of assessment results;
Defining security and confidentiality requirements for systems and operational environments
location of systems in the overall architecture of the company;
distribution of points of application of security and confidentiality requirements for systems and operational environments;
formal registration of IT systems in relevant departments and documents.

The tasks of the “ Categorization ” phase include:

documentation of system characteristics;
system categorization and documentation of categorization results according to safety requirements;
review and approval of results and decisions on categorization according to safety requirements.

The tasks of the stage “ Selection of a set of protective measures ” include:

selection of protection measures for the system and its functioning environment;
clarification (adaptation) of selected protection measures for the system and its functioning environment;
distribution of points of application of security and confidentiality measures to the system and its functioning environment;
documentation of the planned measures to ensure the security and confidentiality of the system and its environment in the relevant plans;
creation and implementation of a strategy for monitoring the effectiveness of the applied protective measures, which is logically connected with and complements the overall organizational monitoring strategy;
review and approval of plans to ensure the security and confidentiality of the system and its operating environment.

The tasks of the “ Implementation of protective measures ” phase include:

implementing security measures in accordance with security and confidentiality plans;
documenting changes to planned safeguards after the fact, based on the actual implementation result.

The tasks of the stage “ Assessment of implemented security measures ” include:

selection of an appraiser or assessment team appropriate to the type of assessment being carried out;
development, review and approval of plans for the assessment of implemented protective measures;
Assessment of protective measures in accordance with the assessment procedures described in the assessment plans;
preparation of assessment reports containing the defects found and recommendations for their elimination;
taking corrective actions with protective measures and reassessing the corrected measures;
preparation of an action plan based on shortcomings found and recommendations from assessment reports.

The tasks of the “ Authorization ” phase include:

collecting an authorization package of documents and sending it to the person in charge for authorization;
analysis and determination of the risk of using the system or applying protective measures;
determination and implementation of a preferred action plan in response to the identified risk;
determination of the acceptability of the risk of using the system or applying protective measures;
reporting authorization results and any lack of security measures that pose a significant risk to security or privacy.

The tasks of the “ Continuous Monitoring ” phase include:

, ;
;
, , ;
, , ;
;
;
.

NIST SP 800-30

The NIST SP 800-30 Special Guide for Conducting Risk Assessments focuses on the risk assessment process, which is a fundamental component of the organization’s risk management process in accordance with NIST SP 800-39, along with the definition of processing and monitoring risks. Risk assessment procedures are used to identify, assess and prioritize risks arising from the use of information systems for the operating activities of an organization, its assets and employees. The objectives of risk assessment are to inform decision-makers and support the risk response process by identifying:

actual threats both to the organization itself and indirectly to other organizations;
internal and external vulnerabilities;
potential damage to the organization, taking into account the possibilities of exploiting vulnerabilities by threats;
the likelihood of this damage.

The end result is the calculation of the determinant (value) of risk, i.e. functions of the amount of damage and the likelihood of damage. Risk assessment can be carried out at all three levels of risk management (levels of organization, mission, information systems), by analogy with the approach used in NIST SP 800-39 and NIST SP 800-37. It is emphasized that risk assessment is an ongoing process that affects all levels of risk management in the organization, and also requires inclusion in the system development life cycle (SDLC) and carried out with a frequency adequate to the objectives and scope of the assessment.

The risk assessment process includes:

preparation for risk assessment;
risk assessment;
communicating assessment results and transferring information within the organization;
maintaining achieved results.

The document says about the importance of compiling a risk assessment methodology, which is developed by the organization at the stage of identifying risks. It is indicated that the organization can choose one or several risk assessment methodologies, depending on available resources, SDLC phase, complexity and maturity of business processes, criticality / importance of the information processed. At the same time, by creating the correct methodology, the organization improves the quality and reproducibility of the realized risk assessments. A risk assessment methodology usually includes:

description of the risk assessment process;
a risk model that describes the risk factors being evaluated and the relationships between them;
a risk assessment method (for example, qualitative or quantitative) that describes the values that risk factors can take and how combinations of these factors can be processed;
a method of analysis (for example, threat centric, focused on assets or vulnerabilities) that describes how combinations of risk factors are identified and analyzed.

The risk model describes the estimated risk factors and the relationships between them. Risk factors are characteristics used in risk models as input to determine risk levels when conducting a risk assessment. In addition, risk factors are used in communicating risks to highlight those factors that significantly affect risk levels in certain situations and contexts. Typical risk factors include:

threats;
vulnerabilities;
Negative influence;
probability;
preconditions.

However, some risk factors can be decomposed to more detailed characteristics, for example, threats can be decomposed into threat sources and threat events.

A threat is any circumstance or event that has the potential to negatively affect business processes or assets, employees, other organizations through unauthorized access, destruction, disclosure or modification of information and / or denial of service. Threat events are generated by threat sources. The source of threats may be a deliberate action aimed at exploiting the vulnerability, or an unintentional action, as a result of which the vulnerability was exploited accidentally. In general, types of threat sources include:

;
;
, ;
.

The details of determining threat events depend on the depth of building a risk model. In the case of a detailed consideration of the risk model, it is possible to build threat scenarios, which are a set of several threat events that lead to negative effects attributed to a specific source of threats (or several sources) and ordered by time; in this case, the potential probability of the sequential exploitation of several vulnerabilities leading to the successful implementation of the attack is considered. Events threats in cyber or physical attacks are characterized by a set of tactics, techniques and procedures (Eng. Tactics, techniques, and procedures, TTPs), about which we have said previously .

The document under consideration also speaks of such a concept as “ threat bias"(Eng. Threat shifting), which is understood as the attackers changing their TTPs depending on the protection measures taken by the company and identified by the attackers. Threat shifting can be carried out in a temporary domain (for example, attempts to attack at another time or extend the attack in time), in a target domain (for example, choosing a less secure target), a resource domain (for example, using attackers additional resources to break into a target), a domain planning or attack method (for example, using other hacker tools or trying to attack using other methods). In addition, it is emphasized that attackers often prefer the path of least resistance to achieve their goals, i.e. choose the weakest link in the protection chain.

Vulnerability- this is a weakness in the information system, security procedures, internal methods of protection, or in the features of a particular implementation / implementation of a particular technology or system. Vulnerability is characterized by its danger in the context of the calculated importance of fixing it; however, the danger can be determined depending on the expected negative effect from the exploitation of this vulnerability. Most of the vulnerabilities in the organization’s information systems arise either due to IS measures that have not been applied (either accidentally or deliberately), or are applied incorrectly. It is also important to remember the evolution of threats and the protected systems themselves - both changes occur over time, which should be taken into account when reassessing risks. In addition to technical vulnerabilities in IT systems,errors in organization management and system architecture should also be considered.

A predisposing condition in the context of risk assessment is a condition that exists in a business process, architecture, or IT system that affects (decreases or increases) the likelihood of damage being threatened. The logical synonyms are the terms “susceptibility” (English susceptibility) or “openness” (English exposure) to risk, meaning that the vulnerability can be exploited by a threat to harm. For example, a SQL server is potentially vulnerable to SQL injection vulnerability. In addition to technical preconditions, organizational ones should be taken into account: for example, the location of an office in a lowland increases the risk of flooding, and the lack of communication between employees when developing an IT system increases the risk of breaking it in the future.

Probability of occurrence(English likelihood of occurrence) threats - a risk factor calculated on the basis of the analysis of the probability that a certain vulnerability (or group of vulnerabilities) can be exploited by a certain threat, taking into account the probability that the threat will ultimately cause real damage. For intentional threats, an assessment of the likelihood of occurrence is usually evaluated based on the intentions, capabilities, and goals of the attacker. For unintentional threats, the assessment of the likelihood of occurrence usually depends on empirical and historical data. Moreover, the probability of occurrence is estimated for a certain time perspective - for example, for the next year or for the reporting period. If the threat is almost wholly 100% initiated or implemented within a certain time period,when assessing risks, the expected frequency of its implementation should be taken into account. When assessing the likelihood of a threat, the state of the organization’s management and business processes, preconditions, the presence and effectiveness of existing protection measures should be considered. The likelihood of negative impact means the possibility that any damage will be caused during the implementation of the threat, regardless of its magnitude. The following three steps can be used to determine the overall probability of occurrence of threat events:The following three steps can be used to determine the overall probability of occurrence of threat events:The following three steps can be used to determine the overall probability of occurrence of threat events:

, - ( ) ( ).
, , , .
.

In addition to this approach, the document recommends not looking for absolutely all related threats and vulnerabilities, but concentrating on those that can really be used in attacks, as well as on business processes and functions with insufficient protection measures.

The level of negative impact (eng. Impact) of a threat event is the amount of damage that is expected from unauthorized disclosure, access, alteration, loss of information or inaccessibility of information systems. Organizations explicitly define:

The process used to determine the negative impact.
Assumptions used to determine adverse effects.
Sources and methods of obtaining information on the negative impact.
The rationale used to determine the negative impact.

In addition, when calculating the negative impact, organizations should take into account the value of assets and information: you can use the company’s accepted system for categorizing information by significance level or the results of evaluations of the negative impact on confidentiality.

When assessing risks, an important factor is the degree of inaccuracy (English uncertainty) that arises due to the following, in general, natural limitations, such as the inability to accurately predict future events; insufficient available information about the threats; unknown vulnerabilities; unrecognized interdependencies.

Based on the foregoing, the risk model can be described as the following logical structure:

source of threat(with certain characteristics) with a certain degree of probability initiates a threat event that exploits the vulnerability (having a certain degree of danger, taking into account the preconditions and successful circumvention of protective measures), as a result of which a negative effect is created (with a certain amount of risk as a function of the amount of damage and probability damage) that gives rise to risk .

The document also gives recommendations on the use of the risk aggregation process.(English risk aggregation) in order to combine several fragmented or low-level risks into one more general: for example, the risks of individual IT systems can be aggregated into a common risk for the entire business system they support. With such a combination, it should be borne in mind that some risks may occur simultaneously or more often than predicted. It is also necessary to take into account the relationship between disparate risks and either combine them, or, conversely, disconnect them.

NIST SP 800-30 also describes the main methods of risk assessment : quantitative (English quantitative), qualitative (English qualitative) and semi-quantitative (English semi-quantitative).

Quantitativethe analysis operates with specific numbers (cost, downtime, costs, etc.) and is best suited for cost-benefit analysis, however it is quite resource-intensive.

Qualitative analysis uses descriptive characteristics (for example, high, medium, low), which can lead to incorrect conclusions due to the small number of possible estimates and the subjectivity of their presentation.

Semi-quantitativethe method is an intermediate option, offering to use a larger range of possible ratings (for example, on a scale of 1 to 10) for a more accurate assessment and analysis of the comparison results. The application of a specific risk assessment method depends both on the organization's field of activity (for example, a more rigorous quantitative analysis can be applied in the banking sector) and on the system life cycle stage (for example, only a qualitative risk assessment can be carried out at the initial stages of the cycle, but at more mature ones) - already quantitative).

Finally, the document also describes three main ways of analyzing risk factors: threat-centric (eng. Threat-oriented), asset-oriented (eng. Asset / impact-oriented) or vulnerabilities (eng. Vulnerability-oriented).

Threat-centeredthe method focuses on creating threat scenarios and begins with determining the sources of threats and threat events; further, vulnerabilities are identified in the context of threats, and the negative impact is associated with the intentions of the attacker. Asset-oriented

method involves identifying threat events and sources of threats that can have a negative impact on assets; potential damage to assets is at the forefront. Applying a Vulnerability-Based Method

begins with an analysis of a set of preconditions and weaknesses / weaknesses that can be exploited; Further, possible events of threats and the consequences of exploiting their vulnerabilities are determined. The document contains recommendations for combining the described analysis methods to obtain a more objective picture of threats in assessing risks.

So, as we have already indicated above, according to NIST SP 800-30, the risk assessment process is divided into 4 steps:

preparation for risk assessment;
risk assessment;
communicating assessment results and transferring information within the organization;
maintaining achieved results.

Let us consider in more detail the tasks performed at each stage.

1. Preparation for risk assessment.

In preparation for the risk assessment, the following tasks are performed:

1.1. Identification of the purpose of the risk assessment: what information is expected as a result of the assessment, what decisions will be dictated by the result of the assessment.
1.2. Identification of the scope of risk assessment in the context of applicability to a particular organization, time frame, information about the architecture and technologies used
1.3. Identification of specific assumptions and limitations, taking into account which risk assessment is carried out. As part of this task, assumptions and limitations are defined in such elements as sources of threats, threat events, vulnerabilities, preconditions, probability of occurrence, negative impact, risk tolerance and level of inaccuracy, as well as the chosen method of analysis.
1.4. Identification of sources of preliminary information, sources of threats and vulnerabilities, as well as information on negative impact that will be used in risk assessment. In this process, sources of information can be both internal (such as incident and audit reports, security logs and monitoring results), and external (for example, CERT reports, research results, and other relevant publicly available information).
1.5. Identification of the risk model, risk assessment method and analysis approach to be used in risk assessment.

2. Conducting a risk assessment.

As part of the risk assessment, the following tasks are performed:

2.1. Identification and characterization of current sources of threats, including the capabilities, intentions and goals of intentional threats, as well as the possible effects of unintentional threats.
2.2. Identification of potential threat events, the relevance of these events, as well as the sources of threats that can trigger threat events.
2.3. Identification of vulnerabilities and preconditions that affect the likelihood that current threat events will lead to a negative impact. Its purpose is to determine how vulnerable the business processes and information systems are to the previously identified sources of threats and how identified threats can actually be triggered by these sources of threats.
2.4. Determining the likelihood that current threat events will lead to a negative impact, taking into account the characteristics of the sources of threats, vulnerabilities and preconditions, as well as the organization's exposure to these threats, taking into account the implemented protective measures.
2.5. Determination of the negative impact generated by the sources of threats, taking into account the characteristics of the sources of threats, vulnerabilities and preconditions, as well as the organization's exposure to these threats, taking into account the implemented protective measures.
2.6. Determining the risk from the implementation of current threat events, taking into account the level of negative impact from these events and the likelihood of these events occurring. Appendix “I” to this standard contains Table I-2 for calculating the level of risk depending on the levels of probability and negative impact.

3. Communicating risk assessment results and transmitting information.

In the framework of communicating the results of risk assessment and information transfer, the following tasks are performed:

3.1. Communicating risk assessment results to decision makers to respond to risks.
3.2. Transmission to interested parties of information regarding risks identified as a result of the assessment.

4. Maintenance of the achieved results.

In the framework of maintaining the achieved results, the following tasks are performed:

4.1. Conducting continuous monitoring of risk factors that affect risks in the operating activities of the organization, its assets, employees, and other organizations. This task is devoted to the standard NIST SP 800-137, which we will consider further.
4.2. Updating risk assessment using the results of the process of continuous monitoring of risk factors.

As you can see, the NIST SP 800-30 document offers a fairly detailed approach to threat modeling and risk calculation. The appendices to this standard, containing examples of calculations for each of the sub-tasks of risk assessment, as well as lists of possible sources of threats, threat events, vulnerabilities and preconditions, are also valuable.

NIST SP 800-137

We now turn to the review of the document NIST SP 800-137 "Information Security Continuous Monitoring for Federal information Systems and Organizations" ("Continuous Monitoring of Information Security for Federal Information Systems and Organizations").

The task of building a strategy for continuous monitoring of information security is to assess the effectiveness of security measures and the security status of systems in order to respond to constantly changing challenges and tasks in the field of information security. The information security continuous monitoring system helps to provide situational awareness of the security status of the company's information systems based on information collected from various resources (such as assets, processes, technologies, employees), as well as the available capabilities for responding to changes in the situation. This system is one of the tactics in the overall risk management strategy.

Like other documents of the SP series, this publication provides the recommended process approach to building an information security monitoring system, consisting of:

( , - ; ; );
( ; ; );
;
( ; ; );
;
.

The document also provides the following recommendations for choosing tools for ensuring continuous monitoring of information security:

their support for a large number of data sources;
the use of open and public specifications (for example, SCAP - Security Content Automation Protocol);
integration with other software, such as Help Desk systems, inventory and configuration management systems, incident response systems;
supporting the compliance analysis process with applicable laws;
flexible reporting process, the ability to “fail” (English drill-down) in the depth of the data under consideration;
Support for Security Information and Event Management (SIEM) systems and data visualization systems.

UPD: The continuation of this article is here .