Information security of bank non-cash payments. Part 7 - Basic Threat Model

  • Tutorial


What research
Links to other parts of the study


This article presents a basic model of threats to the information security of bank non-cash transfers made through the Bank of Russia payment system.

The threats presented here are valid for almost any bank in the Russian Federation, as well as for any other organizations that use fat clients with cryptographic payment confirmation to make payments.

This threat model is designed to ensure practical security and the formation of banks' internal documentation in accordance with the requirements of Bank of Russia Regulations No. 552-P dated August 24, 2016 and No. 382-P dated June 9, 2012.
The use of information from the article for illegal purposes is punishable by law .



Simulation technique


Threat Model Structure


One of the most successful to date methods of modeling computer attacks is the Kill chain . This method represents a computer attack as a sequence of steps performed by hackers to achieve their goals.

Most stages are described in MITRE ATT & CK Matrix , but there is no decryption of the final actions - “Actions” (the last stage of the Kill chain), for which the attackers carried out the attack and which, in essence, are theft of money from the bank. Another problem with using the classic Kill chain to model threats is the lack of a description of the threats associated with accessibility.

This threat model is designed to compensate for these shortcomings. For this, it will formally consist of two parts:

  • The first will describe the problems associated with accessibility.
  • The second one, which is a classic Kill chain with the deciphered last stage, will describe the “computer” theft of money from the bank.



Methods of forming a threat model


The main requirements for the created threat model were:

  • maintaining compactness and minimizing duplication,
  • complete identification of threats and ease of model refinement,
  • providing the opportunity to work with the model for both business professionals and technical workers.

To implement the tasks, the model was built on the basis of the “threat tree” methodology , in which small improvements were made:

  1. Threats were described, starting from the business level, and gradually decomposed into technical components.
  2. The threats inherent in typical elements of the information infrastructure (for example, network connections, cryptographic information protection systems, ...) were grouped into typical threat models.
  3. Further, when modeling threats typical of typical elements of the information infrastructure, instead of duplicating the description of threats, reference was made to the corresponding typical model.

The order of application of this threat model to real objects


The application of this threat model to real objects should begin with clarifying the description of the information infrastructure, and then, if necessary, carry out a more detailed decomposition of threats.

The procedure for updating the threats described in the model should be carried out in accordance with the internal documents of the organization. In the absence of such documents, they can be developed on the basis of the methods discussed in the previous research article .

Features of the threat model design


In this threat model, the following design rules are adopted:

  1. The threat model is a threat tree. The threat tree is recorded in the form of a hierarchical list, where each element of the list corresponds to a tree node and, accordingly, a specific threat.
  2. The name of the threat begins with a threat identifier, which has the form:

    Y <Threat Code>

    where "Y" is short for threat, "Threat Code" is the threat number in the hierarchical list (threat tree).
  3. The threat description may contain two blocks:
    • Explanations contain explanations to the described threat. Examples of the threat implementation, explanation of decisions made during the decomposition, restrictions on modeling, and other information can be given here.
    • Decomposition contains a hierarchical list of child threats.

  4. When decomposing threats by default, it is considered that the implementation of at least one child threat leads to the realization of the parent threat. If the implementation of the parent threat depends on the implementation of the child threats in a different way, then the decomposition at the end of the line describing the parent element indicates the type of dependency:

    • ( I ) - the implementation of the parental threat occurs only with the implementation of all child threats.
    • ( Scenario ) - the implementation of the parental threat occurs under a certain scenario or algorithm for the implementation of child threats.

  5. Links to threats described in the same or other threat models are formatted as follows: Link: "<Threat Model Name>. <Threat Name> ".
  6. If the name of a child threat begins with <...>, then this means that when reading instead of <...>, you must fully insert the name of the parent threat.

Basic threat model for information security of bank cashless payments


Protection object for which the threat model is applied (scope)


The scope of this threat model covers the process of cashless transfers of funds through the payment system of the Bank of Russia.

Architecture
The model includes the following information infrastructure:



Here:

“Bank of Russia Payment System Section (PS BR)” is a section of information infrastructure subject to the requirements of Bank of Russia Regulation No. 552-P of August 24, 2016. The criterion for assigning the information infrastructure to the PS BR site is the processing of electronic messages in the UFBS format at the information infrastructure objects .

"The channel of transmission of electronic messages"It includes a communication channel of the bank with the Central Bank of the Russian Federation, built through a specialized telecommunications operator or modem connection, as well as an electronic messaging mechanism that operates with the help of a courier and alienable computer storage media (OMNI).

The list of premises within the zone of the threat model is determined by the criterion of the presence of information infrastructure facilities involved in the transfer of funds.

Limitations of the model
This threat model applies only to the option of organizing a payment infrastructure with the CBD AWS , which combines encryption and electronic signature functions, and does not consider the use of the AWS CBD-N , where the electronic signature is “on the ABS side”.

Top level security threats


Decomposition of

U1. Termination of the functioning of the cashless transfer system.
Y2. Theft of funds in the process of functioning of the cashless transfer system.

U1. Termination of the non-cash transfer system


Explanations

The potential damage from the realization of this threat can be estimated based on the following assumptions:

  • In bank account service agreements concluded between customers and the bank, as a rule, there is a mark on how long the bank is obliged to make the payment. Violation of the terms specified in the contract entails the responsibility of the bank to the client.
  • If the bank unexpectedly stops making payments, it will raise questions about its financial stability, and, as a result, could provoke a massive outflow of deposits.
  • The continuity of payments is one of the conditions for maintaining a banking license. Systematic refusals and failures can cause serious questions to the bank from the CBR and lead to the revocation of the license.

In general, the maximum allowable delay in the execution of a payment can be considered one flight per operational day. A further increase in delay will lead to more and more damage for the bank.

When decomposing this threat, the following documents were taken into account:


Decomposition at

1.1. Problems with equipment or data carriers used in the implementation of transfers:
1.1.1. Failures and failures.
D1.1.2. Theft.
D1.1.3. Loss.
D1.2. Destruction of programs or data required for translation.
V1.3. Perpetrators of denial-of-service (DoS, DDoS) attacks on technical means and channels of communication used to effect transfers.
D1.4. The impossibility of exchanging electronic messages with the payment system of the Central Bank of the Russian Federation ( I ):
U1.4.1. <...> carried out through network connections:
D1.4.1.1. The inoperability of communication channels with the Central Bank of the Russian Federation ( I ):
1.1.4.1.1.1. <...> provided by a specialized telecom operator.
U1.4.1.1.2. <...> organized as a dial-up connection.
D1.4.1.2. Termination of information used to authenticate a network connection with the CBR.
D1.4.2. <...>, carried out with the help of a courier on alienable machine-made information carriers (OMNI):
D1.4.2.1. Lack of duly executed documents:
D1.4.2.1.1 <...> confirming the courier’s authority.
D1.4.2.1.2 <...>, accompanying payments to OMNI.
U1.5. Termination of cryptographic keys used to protect electronic messages:
У1.5.1. End of validity of cryptographic keys.
D1.5.2. Compromising cryptographic keys.
D1.5.3. Provocation by the cybercriminals of the certifying center of the Central Bank of the Russian Federation to block the operation of the bank's cryptographic keys.
H1.6. Absence in the workplace of persons involved in the implementation of non-cash payments.
U1.7. Use of outdated versions of software used for cashless transfers.
D1.8. Occurrence in the premises of conditions under which the normal functioning of technical equipment, communication channels and personnel involved in the translations is
impossible : У1.8.1. Lack of power.
D1.8.2. Significant violations of the temperature regime (overheating, overcooling).
D1.8.3. Fire.
D1.8.4. Flooding of the room.
D1.8.5. Collapse or threat of room collapse.
D1.8.6. Armed attack.
D1.8.7. Radioactive or chemical contamination.
D.8.8. Strong electromagnetic interference.
W1.8.9. Epidemics.
D1.9. Administrative termination of access to the buildings or premises in which the information infrastructure used to make payments is located:
D1.9.1. Blocking access by authorities:
D1.9.1.1. Conducting searches or other operational investigations.
D.9.9.1.2. Cultural events, religious holidays, etc.
D1.9.2. Blocking access by the owner:
D1.9.2.1. Conflict of economic entities.
U1.10. The action of force majeure (natural disasters, catastrophes, riots, terrorist attacks, military actions, zombie apocalypse, ...).

Y2. Theft of cash in the process of functioning of the system of cashless transfers


Explanation The

theft of funds in the process of the non-cash transfer system is the theft of non-cash funds with their subsequent or simultaneous withdrawal from the victim bank.

Theft of non-cash funds is an unauthorized change in the balance of a customer or bank account. These changes may occur as a result of:

  • abnormal changes in the account balance;
  • unauthorized intrabank or interbank money transfer.

We will call the actions that are not regulated by the internal documentation of the bank, as a result of which an unauthorized decrease or increase in the bank account balance occurred, will be called an abnormal change in the account balance. Examples of such actions can be: conducting fictitious bank transactions, directly changing the balance at the place of storage (for example, in a database) and other actions.

An abnormal change in the account balance, as a rule, is accompanied by regular operations to spend stolen funds. Such operations include:

  • cash withdrawal at ATMs of the victim bank,
  • transferring funds to accounts opened with other banks,
  • making online purchases,
  • etc.

Unauthorized transfer of funds is a transfer made without the consent of the persons legally managing the funds and, as a rule, made by the bank executing a fake money transfer order.

The formation of fake money transfer orders can be made either through the fault of customers or due to the fault of the bank. In this threat model, only threats that are within the responsibility of the bank will be considered. As orders for the transfer of funds in this model, only payment orders will be considered.

In the general case, it can be considered that the processing by a bank of intrabank transfers is a special case of processing interbank transfers, therefore, to preserve the compactness of the model, only interbank transfers will be further considered.

Theft of non-cash funds can be carried out both when executing outgoing payment orders and when executing incoming payment orders. In this case, the outgoing payment order will be the payment order sent by the bank to the payment system of the Bank of Russia, and the incoming payment call will be the payment order received by the bank from the payment system of the Bank of Russia.

Decomposition

U2.1. Execution by the bank of fake outgoing payment orders.
Y2.2. Execution by the bank of fake incoming payment orders.
Y2.3. An abnormal change in account balances.

B2.1. Execution by the bank of fake outgoing payment orders


Explanations

The main reason why a bank can execute a counterfeit payment order is its introduction by hackers into the business process of payment processing.

Decomposition

U2.1.1. The intruders introduce a fake outgoing payment order into the business process of payment processing.

B2.1.1. Intrusion of a fake outgoing payment order by attackers into the payment processing business process


Explanations

This threat will be decomposed into elements of the information infrastructure in which a fake payment order may be introduced.
ItemsThreat decomposition “У2.1.1. Intrusion of a fake outgoing payment order into the business process of payment processing
Bank operatorU2.1.1.1.
Rbo serverU2.1.1.2.
DBO-ABS integration moduleW2.1.1.3.
ABSW2.1.1.4.
ABS-CBD integration moduleW2.1.1.5.
ARM CBDW2.1.1.6.
CBD-UTA Integration ModuleW2.1.1.7.
UTAU2.1.1.8.
Email channelW2.1.1.9.

Decomposition

U2.1.1.1. <...> in the “Bank Operator” element.
U2.1.1.2. <...> in the “DBO Server” element.
W2.1.1.3. <...> in the element "Module of the RBS-ABS".
W2.1.1.4. <...> in the ABS element.
W2.1.1.5. <...> in the “ABS-CBD Integration Module” element.
U2.1.1.6. <...> in the “AWP of the CBD” element.
U2.1.1.7. <...> in the “CBD-UTA Integration Module” element.
U2.1.1.8. <...> in the element "UTA".
W2.1.1.9. <...> in the "E-mail transmission channel" element.

U2.1.1.1. <...> in the “Bank Operator” element


Explanations The

operator, when accepting a paper payment order from a client, enters an electronic document in the ABS on its basis. The vast majority of modern automated banking systems are based on the client-server architecture, which makes it possible to analyze this threat based on a typical threat model of client-server information systems.

Decomposition of

U2.1.1.1.1. A bank operator received a fake payment order on paper from an intruder who introduced himself as a bank customer.
W2.1.1.1.2. A fake electronic payment order was made on behalf of a bank operator.
W2.1.1.1.2.1. The operator acted on malicious intent or made an unintentional mistake.
U2.1.1.1.2.2. The attackers acted on behalf of the teller:
U2.1.1.1.2.2.1. Reference: "Typical Threat Model." Information system built on the basis of client-server architecture. U1. Perpetrators of unauthorized actions on behalf of a legitimate user . ”

Note. Typical threat models will be discussed in the following articles.

U2.1.1.2. <...> in the “DBO Server” element


Decomposition of

U2.1.1.2.1. The RBS server accepted, on behalf of the client, a duly certified payment order, but compiled by hackers without the client's consent:
У2.1.1.2.1.1. Reference: "Typical Threat Model." Information system built on the basis of client-server architecture. U1. Perpetrators of unauthorized actions on behalf of a legitimate user . ”
W2.1.1.2.2. The attackers have introduced a fake payment order into the RBS server:
У2.1.1.2.2.1. Reference: "Typical Threat Model." Information system built on the basis of client-server architecture. Y2. Unauthorized modification of the protected information during its processing by the server part of the information system " .

W2.1.1.3. <...> in the element of the DBO-ABS integration module


Decomposition of

U2.1.1.3.1. Reference: "Typical Threat Model." Integration module. U1. The introduction of false information by the intruders through the integration module ” .

W2.1.1.4. <...> in the ABS element


Decomposition of

U2.1.1.4.1. Reference: "Typical Threat Model." Information system built on the basis of client-server architecture. Y2. Unauthorized modification of the protected information during its processing by the server part of the information system " .

W2.1.1.5. <...> in the “ABS-CBD Integration Module” element


Decomposition of

U2.1.1.5.1. Reference: "Typical Threat Model." Integration module. U1. The introduction of false information by the intruders through the integration module ” .

W2.1.1.6. <...> in the “ARM CBD” element


Explanations

The main function of the ARM CBD in terms of information security is the cryptographic protection of electronic messages exchanged by the bank with the payment system of the Bank of Russia. All outgoing payment documents are encrypted in the public keys of the Bank of Russia and the private keys of the bank’s electronic signature.

Decomposition (s):

D2.1.1.6.1. Encryption of a fake payment order on the public keys of the Bank of Russia:
У2.1.1.6.1.1. Reference: "Typical Threat Model." The system of cryptographic protection of information. Y2. Encryption of fake data on behalf of a legitimate sender . "
W2.1.1.6.2. Electronic signature of a fake payment order on the bank's private keys:
У2.1.1.6.2.1. Link:“Typical threat model. The system of cryptographic protection of information. E4 Creation of an electronic signature of a legitimate signatory under false data . ”

W2.1.1.7. <...> in the “CBD-UTA Integration Module” element


Explanations

In accordance with the technological process of payment processing, electronic messages on the ARM KBR - Central Bank of the Russian Federation section were signed with an electronic signature and encrypted. Accordingly, the introduction of a fake payment order at this stage is possible only if the attackers managed to bypass the standard cryptographic protection procedure bypassing and signing the fake payment order.

Decomposition (s):

D2.1.1.7.1. Reference: "The current threat model. W2.1.1.6. <...> in the “ARM CBD” element .
W2.1.1.7.2. Reference: "Typical Threat Model." Integration module. U1. The introduction of false information by the intruders through the integration module ” .

U2.1.1.8. <...> in the element "UTA"


Explanations

UTA is essentially an information robot that exchanges cryptographically protected electronic messages with the Central Bank of the Russian Federation. Information security threats of this element correspond with threats of integration modules.

Decomposition (s):

D2.1.1.8.1. Reference: "The current threat model. W2.1.1.6. <...> in the “ARM CBD” element .
W2.1.1.8.2. Reference: "Typical Threat Model." Integration module. U1. The introduction of false information by the intruders through the integration module ” .

W2.1.1.9. <...> in the “E-mail channel” element


Decomposition (s):

D2.1.1.9.1. Reference: "The current threat model. W2.1.1.6. <...> in the “ARM CBD” element .
W2.1.1.9.2. The transfer of a fake payment order by cybercriminals to the Bank of Russia:
У2.1.1.9.2.1. <...> during a communication session with the Bank of Russia, established on behalf of the bank.
W2.1.1.9.2.2. <...> using a courier for OMNI.

Y2.2. Execution by the bank of a fake incoming payment order


Decomposition

U2.2.1. The intruders introduce a fake incoming payment order into the business process of payment processing.

U2.2.1. Intrusion of a fake incoming payment order into the business process of payment processing


Explanations

On the ARM CBD site - the payment system of the Bank of Russia, payment orders are encrypted and signed with an electronic signature. In the area of ​​the AWS of the CBD - ABS, payment orders are generally not cryptographically protected.

Payment orders received by the bank are encrypted with the bank’s public keys and signed with Bank of Russia private keys. The key system of cryptographic protection is based on a private PKI (private PKI) implemented on the basis of SKDI SCAD Signature and includes: the certifying center of the Bank of Russia and users - credit organizations. All members of the public key infrastructure trust certificates issued by the certification center of the Central Bank of the Russian Federation.

Thus, to introduce a fake incoming payment order, attackers need to compromise the public encryption keys of the receiving bank and electronic signature keys whose certificates are trusted by the receiving bank.

This threat will be decomposed on the basis of infrastructure elements in which the introduction of fake incoming payment orders may occur.
ItemsThreat decomposition «У2.2.1. Intrusion of a fake incoming payment order into the business process of payment processing by attackers.
ABSU2.2.1.1.
ABS-CBD integration moduleU2.2.1.2.
ARM CBDU2.2.1.3.
CBD-UTA Integration ModuleU2.2.1.4.
UTAU2.2.1.5.
Email channelU2.2.1.6.

Decomposition

U2.2.1.1. <...> in the ABS element.
U2.2.1.2. <...> in the “ABS-CBD Integration Module” element.
U2.2.1.3. <...> in the “AWP of the CBD” element.
U2.2.1.4. <...> in the “CBD-UTA Integration Module” element.
U2.2.1.5. <...> in the element "UTA".
U2.2.1.6. <...> in the "E-mail transmission channel" element.

U2.2.1.1. <...> in the ABS element


Decomposition

U2.2.1.1.1. Reference: "Typical Threat Model." Information system built on the basis of client-server architecture. Y2. Unauthorized modification of the protected information during its processing by the server part of the information system " .

U2.2.1.2. <...> in the “ABS-CBD Integration Module” element


Decomposition

U2.2.1.2.1. Reference: "Typical Threat Model." Integration module. U1. The introduction of false information by the intruders through the integration module ” .

U2.2.1.3. <...> in the “ARM CBD” element


Explanatory notes

When processing incoming payment documents, the AWS of the CBD is the last line of defense whose task is to decipher and verify the integrity of incoming cryptographically protected electronic messages. Protection of this stage will be neutralized if the AWS of the CBD, having received a fake payment order at the entrance, will report that the electronic signature under it is correct.

Decomposition

U2.2.1.3.1. Successful verification of the electronic signature of a fake incoming payment order:
D2.2.1.3.1.1. Reference: “Typical threat model. The system of cryptographic protection of information. V5 Obtaining a positive result of the verification of the electronic signature of false data " .

U2.2.1.4. <...> in the “CBD-UTA Integration Module” element


Explanations

Starting from this element and further, to the payment system of the Bank of Russia, attackers lose the possibility of unauthorized impact on the cryptographic information protection system (ICTD), therefore all data falling from the Integration Module into the AWS of the CBD must be correctly encrypted and signed. Malicious users should use the public keys of the bank for encryption, and private keys for the electronic signature, the certificates of which are trusted by the bank.

Decomposition (I):

U2.2.1.4.1. Neutralization of cryptographic protection of incoming electronic messages ( I ):
У2.2.1.4.1.1. Encryption of a fake payment order on the bank's public keys:
У2.2.1.4.1.1.1. Reference: "Typical Threat Model." The system of cryptographic protection of information. Y2. Encryption of fake data on behalf of a legitimate sender . "
U2.2.1.4.1.2. Electronic signature of a fake payment order on private keys whose certificates are trusted by the bank:
У2.2.1.4.1.2.1. Reference: "Typical Threat Model." The system of cryptographic protection of information. E4 Creation of an electronic signature of a legitimate signatory under false data . ”
U2.2.1.4.2. Link:“Typical threat model. Integration module. U1. The introduction of false information by the intruders through the integration module ” .

U2.2.1.5. <...> in the element "UTA"


Decomposition:

U2.2.1.5.1. Reference: "The current threat model. U2.2.1.4. <...> in the “CBD-UTA Integration Module” element .

U2.2.1.6. <...> in the “E-mail channel” element


Decomposition (s):

D2.2.1.6.1. Reference: "The current threat model. U2.2.1.4.1. Neutralization of cryptographic protection of incoming electronic messages .
U2.2.1.6.2. Receiving a fake payment order from the Central Bank of the Russian Federation:
У2.2.1.6.2.1. <...> during a communication session with the Bank of Russia, established on behalf of the bank.
U2.2.1.6.2.2. <...> using a courier for OMNI.

Conclusion


The next article in the cycle will look at typical threat models:

Tags:

Also popular now: