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

What research



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 payments for cryptographic confirmation of 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:
   
   
   
   At <Threat Code>
   
   
   
   where “U” 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 implementation of a threat, an 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

In the area of ​​the model includes the following information infrastructure:







Here:



“The site of the payment system of the Bank of Russia (PS BR)” is a part of the information infrastructure that is subject to the requirements of the Bank of Russia Regulation No. 552-P dated August 24, 2016. The criterion for assigning the information infrastructure to the BR substation area is the processing of electronic messages in the UFBS format at the information infrastructure objects .



The “e-mail transmission channel” includes the bank’s communication channel with the Central Bank of the Russian Federation, built through a specialized telecommunications operator or modem connection, as well as an e-mail exchange mechanism that functions through a courier and alienated 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.



Model limitations

This threat model applies only to the payment infrastructure organization option with the CBD AWS , which combines encryption and electronic signature functions, and does not consider the use of the AWS KBR-N , where the electronic signature is carried out "on the ABS side".

Top level security threats

Decomposition



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:

• Catalog of threats BSI Threat catalog .
• Recommendations in the field of standardization of the Bank of Russia RS BR IB IBBS-2.2-2009. Ensuring information security organizations of the banking system of the Russian Federation .
• GOST R 51275-2006 Information Security. The object of informatization. Factors affecting information. General provisions .

Decomposition



V1.1. Problems with equipment or data carriers used in the implementation of translation:

D1.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 ):

D1.4.1. <...> via 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 courier on alienable machine-readable media (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:

D1.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. The emergence in the premises of the conditions under which the normal functioning of technical equipment, communication channels and personnel involved in the translations:

D1.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 where the information infrastructure used for making payments is located:

D1.9.1. Blocking access by authorities:

D.9.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:

D.9.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

Explanations



Theft of funds in the process of functioning of the cashless 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



B2.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 for which the bank can execute a fake payment order is its introduction by hackers into the business process of payment processing.



Decomposition



B2.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.

Items	Threat decomposition “2.1.1. Intrusion of a fake outgoing payment order into the business process of payment processing
Bank operator	U2.1.1.1.
Rbo server	U2.1.1.2.
DBO-ABS integration module	W2.1.1.3.
ABS	W2.1.1.4.
ABS-CBD integration module	W2.1.1.5.
ARM CBD	W2.1.1.6.
CBD-UTA Integration Module	W2.1.1.7.
UTA	U2.1.1.8.
Email channel	W2.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



When accepting a paper payment order from a client, the operator 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



W2.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



W2.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:

W2.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



From the point of view of information security, the main function of the AWS of the CBD is the cryptographic protection of electronic messages exchanged with the Bank of Russia payment system. 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 CBD - 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.

Items	Threat decomposition «2.2.1. Intrusion of a fake incoming payment order into the business process of payment processing by attackers.
ABS	U2.2.1.1.
ABS-CBD integration module	U2.2.1.2.
ARM CBD	U2.2.1.3.
CBD-UTA Integration Module	U2.2.1.4.
UTA	U2.2.1.5.
Email channel	U2.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

Explanations



When processing incoming payment documents, the AWS of the CBD is the last line of defense, whose task is to decrypt 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 on to the Bank of Russia payment system, attackers lose the possibility of unauthorized exposure of the cryptographic information protection system (CIPI), therefore, all data falling from the Integration Module into the AWS of the CBD should 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:

• information system based on client-server architecture
• network connection
• access control systems
• integration module
• cryptographic information protection systems .