Seguridad de la información de los pagos bancarios sin efectivo. Parte 7 - Modelo básico de amenazas

¿De qué trata el estudio?

Este artículo presenta un modelo básico de amenazas de seguridad de la información a las transferencias bancarias realizadas a través del sistema de pago del Banco de Rusia.

Las amenazas presentadas aquí son ciertas para casi cualquier banco en la Federación Rusa, así como para cualquier otra organización que use clientes de gran volumen para realizar pagos con confirmación criptográfica de pagos.

Este modelo de amenaza tiene por objeto garantizar la seguridad práctica y la formación de documentación interna de los bancos de conformidad con los requisitos del Reglamento del Banco de Rusia No. 552-P del 24 de agosto de 2016 y el No. 382-P del 9 de junio de 2012.

El uso de la información de un artículo para fines ilegales es punible por ley .

Técnica de modelado

Estructura del modelo de amenaza

Uno de los métodos más exitosos para modelar ataques informáticos en la actualidad es la cadena Kill . Este método representa un ataque informático como una secuencia de pasos realizados por los atacantes para lograr sus objetivos.

La mayoría de las etapas se describen en MITER ATT & CK Matrix , pero no hay una decodificación de las acciones finales: "Acciones" (la última etapa de la cadena Kill), para las cuales los atacantes llevaron a cabo el ataque y que, en esencia, son robos de dinero del banco. Otro problema con el uso de la clásica cadena Kill para el modelado de amenazas es la falta de una descripción de las amenazas asociadas con la accesibilidad.

Este modelo de amenaza está diseñado para compensar estas deficiencias. Para ello, constará formalmente de dos partes:

• El primero describirá los problemas de accesibilidad.
• El segundo, que es una clásica cadena de asesinatos con el último paso descifrado, describirá el robo de dinero "por computadora" del banco.

Metodología para crear un modelo de amenaza

Los requisitos principales para el modelo de amenaza creado fueron:

• manteniendo la compacidad y minimizando la duplicación,
• integridad de la identificación de amenazas y facilidad de refinamiento del modelo,
• brindando la oportunidad de trabajar con el modelo tanto para profesionales de negocios como para trabajadores técnicos.

Para implementar el conjunto de tareas, el modelo se construyó sobre la base de la metodología del "árbol de amenazas" , en la que se realizaron mejoras menores:

1. Se describieron las amenazas, comenzando desde el nivel comercial, y se descompusieron gradualmente en componentes técnicos.
2. Las amenazas inherentes a elementos típicos de la infraestructura de información (por ejemplo, conexiones de red, sistemas de protección de información criptográfica, ...) se agruparon en modelos estándar de amenazas.
3. Además, al modelar las amenazas inherentes a los elementos típicos de la infraestructura de información, en lugar de duplicar la descripción de las amenazas, se hizo referencia al modelo estándar correspondiente.

El procedimiento para aplicar este modelo de amenaza a objetos reales.

La aplicación de este modelo de amenaza a objetos reales debe comenzar aclarando la descripción de la infraestructura de información y luego, si es necesario, llevar a cabo una descomposición más detallada de las amenazas.

El procedimiento para actualizar las amenazas descritas en el modelo debe llevarse a cabo de acuerdo con los documentos internos de la organización. En ausencia de tales documentos, se pueden desarrollar en base a las técnicas discutidas en el artículo de investigación anterior .

Características de diseño del modelo de amenaza

En este modelo de amenaza, se adoptan las siguientes reglas de autorización:

1. El modelo de amenaza es un árbol de amenazas. El árbol de amenazas se escribe en forma de una lista jerárquica, donde cada elemento de la lista corresponde a un nodo del árbol y, en consecuencia, una amenaza específica.
2. El nombre de la amenaza comienza con el identificador de la amenaza, que tiene la forma:
   
   U <Código de amenaza>
   
   donde "Y" es la abreviatura de la amenaza, "Código de amenaza" es el número de amenaza en la lista jerárquica (árbol de amenazas).
3. La descripción de la amenaza puede contener dos bloques:
   • Las explicaciones proporcionan explicaciones para la amenaza descrita. Aquí se pueden dar ejemplos de realización de amenazas, explicación de decisiones tomadas durante la descomposición, restricciones de modelado y otra información.
   • La descomposición contiene una lista jerárquica de amenazas infantiles.
   
   
4. Al descomponer las amenazas, por defecto se considera que la implementación de al menos una amenaza secundaria conduce a la implementación de la amenaza principal. Si la implementación de la amenaza principal depende de la implementación de las amenazas secundarias de otra manera, cuando se descompone al final de la línea que describe el elemento primario, se indica el tipo de dependencia:
   
   
   • ( I ) - la implementación de la amenaza parental ocurre solo con la implementación de todas las amenazas infantiles.
   • ( Escenario ): la implementación de la amenaza parental ocurre con algún escenario o algoritmo específico para la implementación de amenazas infantiles.
   
   
5. Los enlaces a las amenazas descritas en el mismo u otros modelos de amenazas se realizan de acuerdo con la plantilla: Enlace: "<Nombre del modelo de amenaza>. <Nombre de la amenaza> ".
6. Si el nombre de la amenaza infantil comienza con <...>, esto significa que al leer, en lugar de <...>, debe insertar completamente el nombre de la amenaza principal.

El modelo básico de amenazas a la seguridad de la información de los pagos bancarios sin efectivo

El objeto de protección para el cual se aplica el modelo de amenaza (alcance)

El alcance de este modelo de amenaza se extiende al proceso de transferencias de fondos sin efectivo a través del sistema de pago del Banco de Rusia.

Arquitectura
El rango del modelo incluye la siguiente infraestructura de información:



Aquí:

"Sección del sistema de pago del Banco de Rusia (PS BR)" : una sección de la infraestructura de información que está sujeta a los requisitos del Reglamento del Banco de Rusia del 24 de agosto de 2016 No. 552-P. El criterio para clasificar la infraestructura de información como parte de la subestación BR es el procesamiento de mensajes electrónicos en formato UFEBS en las instalaciones de infraestructura de información.

Un "canal de transferencia de mensajes electrónicos" incluye un canal de comunicación del banco con el Banco Central de la Federación de Rusia, creado a través de un operador de telecomunicaciones especializado o una conexión de módem, así como un mecanismo de mensajería electrónica que funciona utilizando un servicio de mensajería y medio de almacenamiento de computadora desechable (OMNI).

La lista de locales incluidos en el área de cobertura del modelo de amenaza está determinada por el criterio para la presencia de instalaciones de infraestructura de información involucradas en la transferencia de fondos.

Limitaciones del modelo
Este modelo de amenaza se extiende solo a la opción de organizar una infraestructura de pago con KBR AWP , combinando funciones de cifrado y firma electrónica, y no considera el uso de KBR-N AWP , donde la firma electrónica se lleva a cabo "en el lado del ABS".

Amenazas de seguridad de nivel superior

Descomposición

U1. Terminación del sistema de transferencias sin efectivo.
U2 Robo de fondos durante el funcionamiento del sistema de transferencias sin efectivo.

U1. Terminación del sistema de transferencia sin efectivo

Explicaciones

El daño potencial de la implementación de esta amenaza se puede evaluar sobre la base de los siguientes supuestos:

• En los acuerdos de servicio de cuentas bancarias celebrados entre clientes y el banco, por regla general, hay una marca sobre cuánto tiempo se requiere que el banco realice el pago. La violación de los términos especificados en el contrato dará lugar a la responsabilidad del banco ante el cliente.
• Si el banco deja de hacer pagos de repente, esto generará dudas sobre su estabilidad financiera y, como resultado, puede provocar una salida masiva de depósitos.
• La continuidad de los pagos es una de las condiciones para mantener una licencia bancaria. Las fallas sistemáticas y el mal funcionamiento pueden generar serias preguntas para el banco del Banco Central de la Federación de Rusia y llevar a la revocación de la licencia.

En el caso general, el retraso máximo permitido en la ejecución del pago puede considerarse un vuelo por día operativo. Un aumento adicional en el retraso conducirá a más y más daños al banco.

Al descomponer esta amenaza, se tuvieron en cuenta los siguientes documentos:

• Catálogo de amenazas BSI .
• Recomendaciones en el campo de la estandarización del Banco de Rusia RS BR IBBS-2.2-2009. Garantizar la seguridad de la información de las organizaciones del sistema bancario de la Federación de Rusia .
• GOST R 51275-2006 Seguridad de la información. El objeto de la informatización. Factores que afectan la información. Disposiciones generales

Descomposición

U1.1. Problemas con el equipo o los medios de almacenamiento utilizados en la traducción:
U1.1.1. Fracasos y fracasos.
U1.1.2. Robo
U1.1.3. Pérdida
U1.2. Destrucción de programas o datos necesarios para realizar transferencias.
U1.3. Ataques de denegación de servicio (DoS, DDoS) por medios técnicos y canales de comunicación utilizados para realizar transferencias por parte de ciberdelincuentes.
U1.4. Incapacidad para intercambiar mensajes electrónicos con el sistema de pago del Banco Central de la Federación de Rusia ( I ):
U1.4.1. <...> a través de conexiones de red:
U1.4.1.1. Inoperabilidad de los canales de comunicación con el Banco Central de la Federación de Rusia ( I ):
U1.4.1.1.1. <...> proporcionado por un operador de telecomunicaciones especializado.
U1.4.1.1.2. <...> organizado como una conexión de módem.
U1.4.1.2. Terminación de la información utilizada para autenticar una conexión de red con el Banco Central de la Federación de Rusia.
U1.4.2. <...>, realizado con la ayuda de un servicio de mensajería sobre soportes de datos de máquinas enajenadas (OMNI):
U1.4.2.1. Falta de documentos debidamente ejecutados:
U1.4.2.1.1 <...>, confirmando la autoridad del servicio de mensajería.
U1.4.2.1.2 <...> pagos adjuntos a OMNI.
U1.5. Terminación de claves criptográficas utilizadas para proteger mensajes electrónicos:
U1.5.1. Caducidad de claves criptográficas.
U1.5.2. Compromiso de claves criptográficas.
U1.5.3. La provocación por parte de los atacantes del centro de certificación del Banco Central de la Federación de Rusia para bloquear la acción de las claves criptográficas del banco.
U1.6. Falta de personas involucradas en la implementación de pagos sin efectivo en el lugar de trabajo.
U1.7. Usar versiones desactualizadas del software utilizado para realizar transferencias bancarias.
U1.8. La ocurrencia en las instalaciones de condiciones bajo las cuales el funcionamiento normal del equipo técnico, los canales de comunicación y el personal involucrado en las transferencias es imposible:
U1.8.1. La falta de poder.
U1.8.2. Violaciones significativas del régimen de temperatura (sobrecalentamiento, hipotermia).
U1.8.3. El fuego
U1.8.4. Inundaciones de la sala.
U1.8.5. Colapso o amenaza de colapso de las instalaciones.
U1.8.6. Ataque armado
U1.8.7. Contaminación radiactiva o química.
U1.8.8. Fuerte interferencia electromagnética.
U1.8.9. Epidemias
U1.9. Terminación administrativa del acceso a edificios o locales en los que se encuentra la infraestructura de información utilizada para realizar pagos:
U1.9.1. Bloqueo de acceso por parte de las autoridades:
U1.9.1.1. Realizar búsquedas u otras medidas de investigación operativas.
U1.9.1.2. Realización de eventos culturales, fiestas religiosas, etc.
U1.9.2. Bloqueo de acceso del propietario:
U1.9.2.1. Conflicto de entidades comerciales.
U1.10. Circunstancias de fuerza mayor (desastres naturales, catástrofes, disturbios, ataques terroristas, operaciones militares, apocalipsis zombie, ...).

U2 Robo de fondos durante la operación del sistema de transferencia sin efectivo

Explicaciones

El robo de fondos durante el funcionamiento del sistema de transferencia sin efectivo es el robo de fondos no monetarios con su retiro posterior o simultáneo del banco víctima.

El robo de fondos no monetarios es un cambio no autorizado en el saldo del cliente o cuenta bancaria. Estos cambios pueden ocurrir como resultado de:

• cambios de contingencia en el saldo de la cuenta;
• Transferencia de dinero intrabancaria o interbancaria no autorizada.

Un cambio anormal en el saldo de la cuenta se denominará acciones no reguladas por la documentación interna del banco, como resultado de lo cual se produjo una disminución o aumento no autorizado del saldo de la cuenta bancaria. Ejemplos de tales acciones pueden ser: realizar una transacción bancaria ficticia, cambiar directamente el saldo en el lugar de almacenamiento (por ejemplo, en la base de datos) y otras acciones.

Un cambio anormal en el saldo de la cuenta generalmente se acompaña de operaciones regulares sobre el gasto de fondos robados. Dichas operaciones incluyen:

• retiro de efectivo en cajeros automáticos del banco víctima,
• transferencias de dinero a cuentas abiertas con otros bancos,
• compras en línea
• etc.

Una transferencia de fondos no autorizada es una transferencia realizada sin el consentimiento de personas autorizadas para disponer de los fondos y, como regla, cometida por el banco al ejecutar una orden de transferencia falsa.

Las órdenes de transferencia de dinero falsas pueden generarse tanto por culpa de los clientes como por culpa del banco. En este modelo de amenaza, solo se considerarán las amenazas en la zona de responsabilidad del banco. En este modelo, solo las órdenes de pago se considerarán como órdenes de transferencias de dinero .

En el caso general, se puede considerar que el procesamiento de transferencias intrabancarias por parte de un banco es un caso especial del procesamiento de transferencias interbancarias, por lo tanto, para preservar la compacidad del modelo, solo se considerarán las transferencias interbancarias a continuación.

El robo de fondos sin efectivo se puede realizar tanto al ejecutar órdenes de pago salientes como al ejecutar órdenes de pago entrantes. En este caso, la orden de pago saliente se llamará la orden de pago enviada por el banco al sistema de pago del Banco de Rusia, y la orden de pago recibida se llamará la orden de pago recibida por el banco del sistema de pago del Banco de Rusia.

Descomposición

U2.1. Ejecución bancaria de falsas órdenes de pago salientes.
U2.2. Ejecución bancaria de falsas órdenes de pago entrantes.
U2.3. Cambio anormal en saldos de cuenta.

U2.1. Ejecución bancaria de órdenes de pago salientes falsas

Explicaciones

La razón principal por la que un banco puede ejecutar una orden de pago falsa es su introducción por parte de delincuentes en el proceso comercial de procesamiento de pagos.

Descomposición

U2.1.1. Intrusos que inyectan una orden de pago saliente falsa en el proceso comercial de procesamiento de pagos.

U2.1.1. Intrusos que introducen una orden de pago saliente falsa en el proceso comercial de procesamiento de pagos

Explicaciones

Esta amenaza se descompondrá de acuerdo con los elementos de la infraestructura de información en la que puede ocurrir la introducción de una orden de pago falsa.

Artículos	Descomposición de la amenaza "2.1.1. Intrusos que introducen una orden de pago saliente falsa en el proceso comercial de procesamiento de pagos "
Operador del banco	U2.1.1.1.
Servidor RBS	U2.1.1.2.
Módulo de integración DBO-ABS	U2.1.1.3.
ABS	U2.1.1.4.
Módulo de integración ABS-CBD	U2.1.1.5.
AWP CBD	U2.1.1.6.
Módulo de integración CBD-UTA	U2.1.1.7.
UTA	U2.1.1.8.
Canal de correo electrónico	U2.1.1.9.

Descomposición

U2.1.1.1. <...> en el elemento "Operador de banco".
U2.1.1.2. <...> en el elemento "Servidor RBS".
U2.1.1.3. <...> en el elemento "Módulo de integración DBO-ABS".
U2.1.1.4. <...> en el elemento ABS.
U2.1.1.5. <...> en el elemento "Módulo de integración ABS-CBD".
Y2.1.1.6. <...> en el elemento "AWP KBR".
U2.1.1.7. <...> en el elemento "Módulo de integración CBD-UTA".
U2.1.1.8. <...> en el elemento UTA.
U2.1.1.9. <...> en el elemento "Canal de mensajes electrónicos".

U2.1.1.1. <...> en el elemento "Operador del banco"

Explicaciones

Al aceptar una orden de pago en papel del cliente, el operador ingresa sobre su base un documento electrónico en el ABS. La gran mayoría de los ABS modernos se basan en una arquitectura cliente-servidor, que permite el análisis de esta amenaza en función de un modelo de amenaza típico de los sistemas de información cliente-servidor.

Descomposición

U2.1.1.1.1. El operador del banco aceptó del atacante, quien se presentó como cliente del banco, una orden de pago falsa en papel.
U2.1.1.1.2. En nombre del operador del banco, se envió una orden de pago electrónica falsa al ABS.
U2.1.1.1.2.1. El empleado actuó maliciosamente o cometió un error involuntario.
U2.1.1.1.2.2. En nombre del operador, los atacantes actuaron:
U2.1.1.1.2.2.1. Enlace: “Un modelo de amenaza típico. Un sistema de información construido sobre la base de la arquitectura cliente-servidor. U1. La perpetración de acciones no autorizadas por delincuentes en nombre de un usuario legítimo " .

Nota Los modelos de amenaza típicos se analizarán en los siguientes artículos.

U2.1.1.2. <...> en el elemento "Servidor RBS"

Descomposición

U2.1.1.2.1. El servidor RBS aceptó en nombre del cliente una orden de pago debidamente certificada, pero redactada por atacantes sin el consentimiento del cliente:
U2.1.1.2.1.1. Enlace: “Un modelo de amenaza típico. Un sistema de información construido sobre la base de la arquitectura cliente-servidor. U1. La perpetración de acciones no autorizadas por delincuentes en nombre de un usuario legítimo " .
U2.1.1.2.2. :
2.1.1.2.2.1. : « . , -. 2. » .

2.1.1.3. <...> « -»

2.1.1.3.1. : « . . 1. » .

2.1.1.4. <...> «»

2.1.1.4.1. : « . , -. 2. » .

2.1.1.5. <...> « -»

2.1.1.5.1. : « . . 1. » .

2.1.1.6. <...> « »

, . .

():

2.1.1.6.1. :
2.1.1.6.1.1. : « . . 2. » .
2.1.1.6.2. :
2.1.1.6.2.1. : « . . 4. » .

2.1.1.7. <...> « -»

— . , .

():

2.1.1.7.1. : « . 2.1.1.6. <...> « » .
2.1.1.7.2. : « . . 1. » .

2.1.1.8. <...> «»

— , , , . .

():

2.1.1.8.1. : « . 2.1.1.6. <...> « » .
2.1.1.8.2. : « . . 1. » .

2.1.1.9. <...> « »

():

2.1.1.9.1. : « . 2.1.1.6. <...> « » .
2.1.1.9.2. :
2.1.1.9.2.1. <...> , .
2.1.1.9.2.2. <...> .

2.2.

2.2.1. - .

2.2.1. -

— . — .

. (private PKI), : — . , .

, - , -.

,

	«2.2.1. - »
	2.2.1.1.
-	2.2.1.2.
	2.2.1.3.
-	2.2.1.4.
	2.2.1.5.
	2.2.1.6.

2.2.1.1. <...> «».
2.2.1.2. <...> « -».
2.2.1.3 .<...> « ».
2.2.1.4 .<...> « -».
2.2.1.5. <...> «».
2.2.1.6. <...> « ».

2.2.1.1. <...> «»

2.2.1.1.1. : « . , -. 2. » .

2.2.1.2. <...> « -»

2.2.1.2.1. : « . . 1. » .

2.2.1.3. <...> « »

, . , , , , .



2.2.1.3.1. :
2.2.1.3.1.1 : « . . 5. » .

2.2.1.4. <...> « -»

, , (), , , . , , .

():

2.2.1.4.1. ( ):
2.2.1.4.1.1. :
2.2.1.4.1.1.1. : « . . 2. » .
2.2.1.4.1.2. , :
2.2.1.4.1.2.1. : « . . 4. » .
2.2.1.4.2. : « . . 1. » .

2.2.1.5. <...> «»

:

2.2.1.5.1. : « . 2.2.1.4. <...> « -» .

2.2.1.6. <...> « »

():

2.2.1.6.1. : « .2.2.1.4.1. » .
2.2.1.6.2. :
2.2.1.6.2.1. <...> , .
2.2.1.6.2.2. <...> .

Conclusión

:

• , -
• .