Enllaços a altres parts de l'estudi
- (Estàs aquí)
Aquest article completa el cicle de publicacions dedicades a garantir la seguretat de la informació dels pagaments bancaris sense efectiu. Aquí mirem els models d'amenaça genèrics als quals es fa referència :
- .
- .
- .
- .
HABR-ADVERTIMENT!!! Benvolguts Khabrovites, aquesta no és una publicació entretinguda.
Es demanen més de 40 pàgines de materials ocults sota el tall ajuda amb el treball o l'estudi persones especialitzades en banca o seguretat de la informació. Aquests materials són el producte final de l'estudi i estan escrits en un to formal sec. De fet, són espais en blanc per a documents interns sobre seguretat de la informació.Bé, el tradicional "L'ús de la informació de l'article amb finalitats il·legals està sancionat per llei". Lectura productiva!
Informació per als lectors que llegeixen l'estudi a partir d'aquesta publicació.
De què tracta l'estudi
Esteu llegint una guia per a un especialista encarregat de garantir la seguretat de la informació dels pagaments en un banc.
Lògica de presentació
Al principi en и es fa la descripció de l'objecte de protecció. Llavors a explica com construir un sistema de protecció i parla de la necessitat de crear un model d'amenaça. EN Explica què són els models d'amenaça i com es formen. EN и es fa anàlisi d'atacs reals. и conté una descripció del model d'amenaça construït tenint en compte la informació de totes les parts anteriors.
MODEL TÍPIC D'AMENACES. CONNEXIÓ DE XARXA
L'objecte de protecció al qual s'aplica el model d'amenaça (abast)
L'objecte de protecció són les dades transmeses a través d'una connexió de xarxa que funciona en xarxes de dades construïdes sobre la base de la pila TCP/IP.
arquitectura
Descripció dels elements arquitectònics:
- "nodes finals" — nodes que intercanvien informació protegida.
- "Nodes intermedis" - elements de la xarxa de transmissió de dades: encaminadors, commutadors, servidors d'accés, servidors proxy i altres equips, a través dels quals es transmet el trànsit de connexió de xarxa. En general, una connexió de xarxa pot funcionar sense nodes intermedis (directament entre nodes finals).
Amenaces de seguretat de primer nivell
Descomposició
U1. Accés no autoritzat a les dades transmeses.
U2. Modificació no autoritzada de les dades transmeses.
U3. Violació de l'autoria de les dades transmeses.
U1. Accés no autoritzat a les dades transmeses
Descomposició
U1.1. <...>, realitzat en nodes finals o intermedis:
U1.1.1. <…> llegint les dades mentre es troben als dispositius d'emmagatzematge del node:
U1.1.1.1. <…> a la memòria RAM.
Explicacions a V1.1.1.1.
Per exemple, durant el processament de dades per part de la pila de xarxa del node.
U1.1.1.2. <…> en memòria no volàtil.
Explicacions a V1.1.1.2.
Per exemple, quan s'emmagatzemen dades transmeses a la memòria cau, fitxers temporals o fitxers de paginació.
Y1.2. <…> realitzat en nodes de xarxa de dades de tercers:
U1.2.1. <...> capturant tots els paquets que cauen a la interfície de xarxa del node:
Explicacions a V1.2.1.
Tots els paquets es capturen canviant la targeta de xarxa al mode promiscu (mode promiscu per als adaptadors amb cable o mode monitor per als adaptadors wi-fi).
U1.2.2. <…> realitzant atacs man-in-the-middle (MiTM), però sense modificar les dades transmeses (sense comptar les dades de servei dels protocols de xarxa).
Y1.2.2.1. Enllaç: .
Y1.3. <...>, realitzada per filtració d'informació per canals tècnics (TCUI) des de nodes físics o línies de comunicació.
U1.4. <...>, realitzada per a la instal·lació de mitjans tècnics especials (STS) als nodes finals o intermedis, destinats a l'eliminació encoberta d'informació.
U2. Modificació no autoritzada de les dades transmeses
Descomposició
U2.1. <...>, realitzat en nodes finals o intermedis:
Y2.1.1. <...> llegint i modificant les dades mentre es troben als dispositius d'emmagatzematge dels nodes:
Y2.1.1.1. <...> a la memòria RAM:
Y2.1.1.2. <…> en memòria no volàtil:
Y2.2. <...> realitzat en nodes de xarxa de dades de tercers:
U2.2.1. <...> realitzant atacs Man-in-the-Middle (MiTM) i redirigint el trànsit a l'amfitrió maliciós:
Y2.2.1.1. La connexió física dels equips dels atacants per trencar la connexió de xarxa.
Y2.2.1.2. Implementació d'atacs a protocols de xarxa:
Y2.2.1.2.1. <…> gestió de la xarxa d'àrea local virtual (VLAN):
Y2.2.1.2.1.1. .
Y2.2.1.2.1.2. Modificació no autoritzada de la configuració de VLAN en commutadors o encaminadors.
Y2.2.1.2.2. <…> encaminament del trànsit:
Y2.2.1.2.2.1. Modificació no autoritzada de les taules d'encaminament estàtiques dels encaminadors.
Y2.2.1.2.2.2. Anunci de rutes falses per part dels atacants mitjançant protocols d'encaminament dinàmic.
Y2.2.1.2.3. <…> configuració automàtica:
Y2.2.1.2.3.1. .
Y2.2.1.2.3.2. .
Y2.2.1.2.4. <…> adreça i resolució de noms:
Y2.2.1.2.4.1. .
Y2.2.1.2.4.2. .
Y2.2.1.2.4.3. Fer canvis no autoritzats als fitxers de noms d'amfitrió locals (amfitrions, lmhosts, etc.)
U3. Violació de l'autoria de les dades transmeses
Descomposició
Y3.1. Neutralització dels mecanismes per determinar l'autoria de la informació mitjançant la indicació d'informació falsa sobre l'autor o la font de dades:
Y3.1.1. Modificació de la informació sobre l'autor continguda a la informació transmesa.
Y3.1.1.1. Neutralització de la protecció criptogràfica de la integritat i l'autoria de les dades transmeses:
Y3.1.1.1.1. Enllaç: .
Y3.1.1.2. Neutralització de la protecció de l'autoria de les dades transmeses, implementada mitjançant codis de confirmació d'un sol ús:
Y3.1.1.2.1. .
Y3.1.2. Canvi de la informació sobre la font de la informació transmesa:
Y3.1.2.1. .
Y3.1.2.2. .
MODEL TÍPIC D'AMENACES. SISTEMA D'INFORMACIÓ CONSTRUIT A BASE DE L'ARQUITECTURA CLIENT-SERVIDOR
L'objecte de protecció al qual s'aplica el model d'amenaça (abast)
L'objecte de protecció és un sistema d'informació construït sobre la base de l'arquitectura client-servidor.
arquitectura
Descripció dels elements arquitectònics:
- "Client" - un dispositiu en el qual opera la part client del sistema d'informació.
- "Servidor" - un dispositiu en el qual opera la part servidor del sistema d'informació.
- "Magatzem de dades" - part de la infraestructura de servidors del sistema d'informació, dissenyada per emmagatzemar dades processades pel sistema d'informació.
- "Connexió de xarxa" — un canal d'intercanvi d'informació entre el client i el servidor que passa per la xarxa de transmissió de dades. Per obtenir una descripció més detallada del model d'elements, vegeu .
Restriccions
Quan es modela un objecte, s'estableixen les restriccions següents:
- L'usuari interactua amb el sistema d'informació en períodes de temps finits, anomenats sessions de treball.
- A l'inici de cada sessió, l'usuari és identificat, autenticat i autoritzat.
- Tota la informació protegida s'emmagatzema a la part del servidor del sistema d'informació.
Amenaces de seguretat de primer nivell
Descomposició
U1. Atacants que cometen accions no autoritzades en nom d'un usuari legítim.
U2. Modificació no autoritzada de la informació protegida durant el seu tractament per part del servidor del sistema d'informació.
U1. Atacants que cometen accions no autoritzades en nom d'un usuari legítim
Explicacions
Normalment en els sistemes d'informació, la correlació d'accions amb l'usuari que les ha realitzat es realitza mitjançant:
- registres del sistema (registres).
- atributs especials dels objectes de dades que contenen informació sobre l'usuari que els ha creat o modificat.
En relació a una sessió de treball, aquesta amenaça es pot descompondre en:
- <…> realitzat dins de la sessió d'usuari.
- <…> realitzat fora de la sessió d'usuari.
Es pot iniciar una sessió d'usuari:
- Pel propi usuari.
- Intrusos.
En aquesta etapa, la descomposició intermèdia d'aquesta amenaça es veurà així:
U1.1. Accions no autoritzades realitzades dins de la sessió d'usuari:
U1.1.1. <…> establert per l'usuari atacat.
U1.1.2. <…> instal·lat per atacants.
Y1.2. S'han realitzat accions no autoritzades fora de la sessió de l'usuari.
Des del punt de vista dels objectes d'infraestructura de la informació que poden ser afectats per intrusos, la descomposició de les amenaces intermèdies es veurà així:
Ítems
Descomposició de l'amenaça
Y1.1.1.
Y1.1.2.
Y1.2.
Client
Y1.1.1.1.
Y1.1.2.1.
connexió de xarxa
Y1.1.1.2.
Servidor
Y1.2.1.
Descomposició
U1.1. Accions no autoritzades realitzades dins de la sessió d'usuari:
U1.1.1. <…> establert per l'usuari atacat:
U1.1.1.1. Els atacants van actuar de manera independent respecte al client:
У1.1.1.1.1 Els atacants van utilitzar eines estàndard d'accés al sistema d'informació:
Y1.1.1.1.1.1. Els atacants van utilitzar els mitjans físics d'entrada/sortida del client (teclat, ratolí, monitor o pantalla tàctil d'un dispositiu mòbil):
Y1.1.1.1.1.1.1. Els atacants van actuar durant períodes de temps en què la sessió està activa, les instal·lacions d'E/S estan disponibles i l'usuari està fora.
Y1.1.1.1.1.2. Els atacants van utilitzar eines d'administració remota (estàndard o proporcionades per codi maliciós) per gestionar el client:
Y1.1.1.1.1.2.1. Els atacants van actuar durant períodes de temps en què la sessió està activa, les instal·lacions d'E/S estan disponibles i l'usuari està fora.
Y1.1.1.1.1.2.2. Els atacants van utilitzar eines d'administració remota, el funcionament de les quals és invisible per a l'usuari atacat.
U1.1.1.2. Els atacants van falsificar les dades de la connexió de xarxa entre el client i el servidor, modificant-les de manera que es perceben com accions d'un usuari legítim:
Y1.1.1.2.1. Enllaç: .
Y1.1.1.3. Els atacants van obligar l'usuari a realitzar les accions que especificava mitjançant mètodes d'enginyeria social.
U1.1.2 <...> establert pels atacants:
Y1.1.2.1. Els atacants van actuar des del Client (И):
Y1.1.2.1.1. Els atacants van neutralitzar el sistema de control d'accés del sistema d'informació:
Y1.1.2.1.1.1. Enllaç: .
Y1.1.2.1.2. Els malfactors utilitzaven mitjans habituals d'accés al sistema d'informació
U1.1.2.2. Els atacants van actuar des d'altres nodes de la xarxa de transmissió de dades, des dels quals és possible establir una connexió de xarxa amb el servidor (И):
Y1.1.2.2.1. Els atacants van neutralitzar el sistema de control d'accés del sistema d'informació:
Y1.1.2.2.1.1. Enllaç: .
Y1.1.2.2.2. Els atacants van utilitzar mitjans no estàndards per accedir al sistema d'informació.
Explicacions Y1.1.2.2.2.
Els atacants podrien instal·lar un client de sistema d'informació normal en un node de tercers o podrien utilitzar programari no estàndard que implementa protocols d'intercanvi estàndard entre el client i el servidor.
P1.2 Accions no autoritzades realitzades fora de la sessió de l'usuari.
S1.2.1 Els atacants van realitzar accions no autoritzades i després van fer canvis no autoritzats als registres del sistema d'informació o als atributs especials dels objectes de dades, indicant que les accions que van cometre van ser realitzades per un usuari legítim.
U2. Modificació no autoritzada de la informació protegida durant el seu tractament per part del servidor del sistema d'informació
Descomposició
Y2.1. Els atacants modifiquen la informació protegida mitjançant eines estàndard del sistema d'informació i ho fan en nom d'un usuari legítim.
Y2.1.1. Enllaç: .
Y2.2. Els atacants modifiquen la informació protegida utilitzant mecanismes d'accés a les dades que no estan previstos pel funcionament habitual del sistema d'informació.
U2.2.1. Els atacants modifiquen fitxers que contenen informació protegida:
Y2.2.1.1. <…> utilitzant els mecanismes de gestió de fitxers proporcionats pel sistema operatiu.
Y2.2.1.2. <...> provocant la restauració de fitxers a partir d'una còpia de seguretat modificada no autoritzada.
U2.2.2. Els malfactors modifiquen la informació protegida emmagatzemada a la base de dades (И):
Y2.2.2.1. Els atacants neutralitzen el sistema de control d'accés al SGBD:
Y2.2.2.1.1. Enllaç: .
Y2.2.2.2. Els atacants modifiquen la informació mitjançant interfícies estàndard de DBMS per accedir a les dades.
Y2.3. Els malfactors modifiquen la informació protegida mitjançant la modificació no autoritzada dels algorismes de treball del programari que la processa.
Y2.3.1. Es fan modificacions al codi font del programari.
Y2.3.1. Es fan modificacions al codi màquina del programari.
Y2.4. Els atacants modifiquen la informació protegida aprofitant les vulnerabilitats del programari del sistema d'informació.
Y2.5. Els atacants modifiquen la informació protegida quan es transfereix entre els components de la part del servidor del sistema d'informació (per exemple, el servidor de bases de dades i el servidor d'aplicacions):
Y2.5.1. Enllaç: .
MODEL TÍPIC D'AMENACES. SISTEMA DE CONTROL D'ACCÉS
L'objecte de protecció al qual s'aplica el model d'amenaça (abast)
L'objecte de protecció al qual s'aplica aquest model d'amenaça correspon a l'objecte de protecció del model d'amenaça: “Model d'amenaça típic. Un sistema d'informació construït sobre la base d'una arquitectura client-servidor.
El sistema de control d'accés dels usuaris en aquest model d'amenaça s'entén com un component del sistema d'informació que implementa les funcions següents:
- Identificació de l'usuari.
- Autenticació d'usuari.
- Autoritzacions d'usuari.
- Registre d'accions de l'usuari.
Amenaces de seguretat de primer nivell
Descomposició
U1. Establiment no autoritzat d'una sessió en nom d'un usuari legítim.
U2. Elevació no autoritzada dels privilegis d'usuari al sistema d'informació.
U1. Establiment de sessió no autoritzat en nom d'un usuari legítim
Explicacions
La descomposició d'aquesta amenaça en el cas general dependrà del tipus de sistemes d'identificació i autenticació dels usuaris utilitzats.
En aquest model, només es tindrà en compte el sistema d'identificació i autenticació de l'usuari mitjançant l'inici de sessió de text i la contrasenya. En aquest cas, assumirem que l'inici de sessió de l'usuari és informació pública coneguda pels atacants.
Descomposició
U1.1. <…> comprometent les credencials:
U1.1.1. Els atacants van comprometre les credencials de l'usuari mentre s'emmagatzemaven.
Explicacions Y1.1.1.
Per exemple, les credencials es podrien escriure en una nota adhesiva gravada al monitor.
U1.1.2. L'usuari ha passat de manera accidental o maliciosa els detalls d'accés als atacants.
Y1.1.2.1. L'usuari va pronunciar les credencials en veu alta mentre entrava.
U1.1.2.2. L'usuari ha passat intencionadament les seves credencials:
Y1.1.2.2.1. <…> companys de feina.
Explicacions Y1.1.2.2.1.
Per exemple, perquè puguin substituir-lo per un període de malaltia.
Y1.1.2.2.2. <…> a les contraparts de l'empresari que realitzen treballs sobre els objectes de la infraestructura de la informació.
Y1.1.2.2.3. <…> a tercers.
Explicacions Y1.1.2.2.3.
Una, però no l'única manera d'implementar aquesta amenaça, és utilitzar mètodes d'enginyeria social per part dels atacants.
U1.1.3. Els atacants van forçar les credencials:
Y1.1.3.1. <…> utilitzant mecanismes d'accés habituals.
U1.1.3.2. <...> mitjançant codis interceptats prèviament (per exemple, hash de contrasenya) per emmagatzemar credencials.
U1.1.4. Els atacants van utilitzar codi maliciós per interceptar les credencials de l'usuari.
U1.1.5. Els atacants van extreure credencials d'una connexió de xarxa entre el client i el servidor:
Y1.1.5.1. Enllaç: .
U1.1.6. Els atacants van extreure credencials dels registres dels sistemes de control del treball:
U1.1.6.1. <…> sistemes de videovigilància (en cas que les pulsacions del teclat s'enregistrin durant el funcionament).
U1.1.6.2. <…> sistemes de seguiment de l'actuació dels empleats a l'ordinador
Explicacions Y1.1.6.2.
Un exemple d'aquest sistema és .
U1.1.7. Els atacants van comprometre les credencials de l'usuari a causa de defectes en el procés de transmissió.
Explicacions Y1.1.7.
Per exemple, la transmissió de contrasenyes en text clar per correu electrònic.
U1.1.8. Els atacants van aprendre les credencials supervisant la sessió de l'usuari mitjançant sistemes d'administració remota.
U1.1.9. Els atacants van extreure les credencials com a resultat de la seva filtració a través de canals tècnics (TCUE):
U1.1.9.1. Els atacants van espiar com l'usuari introduïa les credencials des del teclat:
E1.1.9.1.1 Els atacants estaven situats molt a prop de l'usuari i van veure l'entrada de credencials amb els seus propis ulls.
C1.1.9.1.1 Explicacions
Aquests casos inclouen les accions dels companys a la feina o el cas en què el teclat de l'usuari és visible per als visitants de l'organització.
E1.1.9.1.2 Els atacants van utilitzar mitjans tècnics addicionals, com ara prismàtics o un vehicle aeri no tripulat, i van veure l'entrada de credencials per una finestra.
U1.1.9.2. Els atacants van extreure credencials dels registres de l'intercanvi de ràdio entre el teclat i la unitat del sistema de l'ordinador si estaven connectats mitjançant la interfície de ràdio (per exemple, Bluetooth).
U1.1.9.3. Els atacants van interceptar les credencials filtrant-les pel canal de radiació electromagnètica espúria i captadores (PEMIN).
Explicacions Y1.1.9.3.
Exemples d'atac и .
U1.1.9.4. L'atacant va interceptar l'entrada de credencials des del teclat mitjançant l'ús de mitjans tècnics especials (STS) dissenyats per eliminar informació encoberta.
Explicacions Y1.1.9.4.
Примеры .
U1.1.9.5. Els atacants van interceptar l'entrada de credencials des del teclat
anàlisi del senyal Wi-Fi modulat pel procés de prémer les tecles per part de l'usuari.
Explicacions Y1.1.9.5.
Exemple .
U1.1.9.6. Els atacants van interceptar l'entrada de credencials des del teclat mitjançant l'anàlisi dels sons de les pulsacions de tecles.
Explicacions Y1.1.9.6.
Exemple .
U1.1.9.7. Els atacants van interceptar l'entrada de credencials des del teclat d'un dispositiu mòbil mitjançant l'anàlisi de les lectures de l'acceleròmetre.
Explicacions Y1.1.9.7.
Exemple .
U1.1.10. <...> desat prèviament al Client.
Explicacions Y1.1.10.
Per exemple, un usuari podria desar un nom d'usuari i una contrasenya al navegador per accedir a un lloc concret.
U1.1.11. Els atacants van comprometre les credencials a causa de defectes en el procés de revocació de l'accés dels usuaris.
Explicacions Y1.1.11.
Per exemple, després de l'acomiadament d'un usuari, els seus comptes romanien sense bloquejar.
Y1.2. <…> aprofitant les vulnerabilitats del sistema de control d'accés.
U2. Elevació no autoritzada dels privilegis d'usuari al sistema d'informació
Descomposició
P2.1 <...> fent canvis no autoritzats a les dades que contenen informació sobre els privilegis de l'usuari.
U2.2 <…> mitjançant l'explotació de vulnerabilitats en el sistema de control d'accés.
Y2.3. <…> a causa de defectes en el procés de control d'accés dels usuaris.
Explicacions Y2.3.
Exemple 1. A un usuari se li va donar més accés a la feina del que necessitava per necessitats oficials.
Exemple 2: després de transferir un usuari a una altra posició, no es van revocar els drets d'accés concedits anteriorment.
MODEL TÍPIC D'AMENACES. MÒDUL D'INTEGRACIÓ
L'objecte de protecció al qual s'aplica el model d'amenaça (abast)
Mòdul d'integració: un conjunt d'objectes d'infraestructura d'informació dissenyats per organitzar l'intercanvi d'informació entre sistemes d'informació.
Atès que a les xarxes corporatives no sempre és possible separar inequívocament un sistema d'informació d'un altre, el mòdul d'integració també es pot considerar com un enllaç entre components d'un sistema d'informació.
arquitectura
L'esquema generalitzat del mòdul d'integració és el següent:
Descripció dels elements arquitectònics:
- "Servidor d'intercanvi (CO)" – un node / servei / component d'un sistema d'informació que realitza la funció d'intercanviar dades amb un altre sistema d'informació.
- "intermediari" - un node/servei dissenyat per organitzar la interacció entre sistemes d'informació, però no part d'ells.
Exemples "Intermediaris" poden ser serveis de correu electrònic, bus de servei empresarial / arquitectura SoA, servidors de fitxers de tercers, etc. En el cas general, el mòdul d'integració no pot contenir "Intermediaris". - "Programari de tractament de dades" - un conjunt de programes que implementen protocols d'intercanvi de dades i conversió de formats.
Per exemple, convertir dades del format UFEBS al format ABS, canviar l'estat dels missatges durant la transmissió, etc. - "Connexió de xarxa" correspon a l'objecte descrit al model d'amenaça típic de "Connexió a la xarxa". Algunes connexions de xarxa de les que es presenten al diagrama anterior poden no ser-ho.
Exemples de mòduls d'integració
Esquema 1. Integració d'ABS i AWP KBR mitjançant un servidor de fitxers de tercers
Per executar els pagaments, un empleat autoritzat del banc carrega documents de pagament electrònic des de l'ABS i els desa en un fitxer (de format propi, per exemple, bolcat SQL) a la carpeta de xarxa (…SHARE) del servidor de fitxers. A continuació, aquest fitxer es converteix en un conjunt de fitxers en format UFEBS mitjançant un script convertidor, que després llegeix el CBD AWP.
Després d'això, un empleat autoritzat, un usuari de l'AWS CBD, xifra i signa el fitxer rebut i l'envia al sistema de pagament del Banc de Rússia.
Un cop rebuts els pagaments del Banc de Rússia, l'AWP del CBR els desxifra i comprova la signatura electrònica, després d'això els escriu com un conjunt de fitxers en format UFEBS al servidor de fitxers. Abans d'importar documents de pagament a l'ABS, es converteixen mitjançant un convertidor d'scripts del format UFEBS al format ABS.
Suposarem que en aquest esquema, l'ABS funciona en un servidor físic, l'estació de treball CBD funciona en un ordinador dedicat i el convertidor d'scripts funciona en un servidor de fitxers.
Correspondència dels objectes de l'esquema considerat amb els elements del model del mòdul d'integració:
"Servidors d'intercanvi des del costat ABS" - Servidor ABS.
"Servidors d'intercanvi des del costat de l'AWP KBR" - Estació de treball informàtica KBR.
"intermediari" - Servidor de fitxers de tercers.
"Programari de tractament de dades" - Convertidor d'scripts.
Esquema 2. Integració d'ABS i AWS KBR en col·locar una carpeta de xarxa compartida amb pagaments a AWS KBR
Tot és semblant a l'Esquema 1, però no s'utilitza un servidor de fitxers independent; en canvi, una carpeta de xarxa (...SHARE) amb documents de pagament electrònic es troba en un ordinador amb AWS CBD. El convertidor de scripts també funciona amb AWP CBD.
Correspondència dels objectes de l'esquema considerat amb els elements del model del mòdul d'integració:
Similar a l'esquema 1, però "intermediari" no utilitzat.
Esquema 3. Integració d'ABS i AWS KBR-N mitjançant IBM WebSphera MQ i signatura de documents electrònics "al costat ABS"
L'ABS funciona en una plataforma no compatible amb CIPF SKAD Signature. Els documents electrònics de sortida es signen en un servidor especial de signatura electrònica (ES Server). El mateix servidor verifica la signatura electrònica sota els documents que arriben del Banc de Rússia.
L'ABS carrega al Servidor ES un fitxer amb els documents de pagament en el seu propi format.
El servidor ES, mitjançant un script convertidor, converteix el fitxer en missatges electrònics en el format UFEBS, després del qual els missatges electrònics es signen i es transmeten a IBM WebSphere MQ.
AWS KBR-N accedeix a IBM WebSphere MQ i rep missatges de pagament signats des d'allà, després dels quals un empleat autoritzat, un usuari d'AWS KBR, els xifra i els envia al sistema de pagament del Banc de Rússia.
Un cop rebuts els pagaments del Banc de Rússia, AWP KBR-N els desxifra i verifica la signatura electrònica. Els pagaments processats correctament en forma de missatges electrònics desxifrats i signats en el format UFEBS es transfereixen a IBM WebSphere MQ, des d'on els rep l'ES Server.
El servidor ES verifica la signatura electrònica dels pagaments rebuts i els guarda en un fitxer en format ABS. Després d'això, un empleat autoritzat, l'usuari de l'ABS, carrega el fitxer resultant a l'ABS de la manera prescrita.
Correspondència dels objectes de l'esquema considerat amb els elements del model del mòdul d'integració:
"Servidor d'intercanvi des del costat ABS" - Servidor ABS.
"Servidor d'intercanvi des del costat de l'AWP KBR" - Estació de treball informàtica KBR.
"intermediari" – Servidor ES i IBM WebSphere MQ.
"Programari de tractament de dades" – script-converter, CIPF SCAD Signature al servidor ES.
Esquema 4. Integració del Servidor RBS i ABS mitjançant l'API proporcionada per un servidor d'intercanvi dedicat
Suposem que el banc utilitza diversos sistemes de banca remota (RBS):
- "Internet Client-Bank" per a particulars (ICB FL);
- "Internet Client-Bank" per a persones jurídiques (ICB LE).
Per tal de garantir la seguretat de la informació, tota la interacció de l'ABS amb els sistemes RB es realitza mitjançant un servidor d'intercanvi dedicat que funciona en el marc del sistema d'informació ABS.
A continuació, considerarem el procés d'interacció del sistema RBS de l'ICB LE amb l'ABS.
El servidor RBS, havent rebut una ordre de pagament degudament certificada del client, ha de crear un document adequat a l'ABS a partir d'ella. Per fer-ho, mitjançant l'API, transfereix informació al servidor d'intercanvi, que, al seu torn, introdueix dades a l'ABS.
Quan els saldos del compte del client canvien, l'ABS genera notificacions electròniques, que es transmeten al servidor RBS mitjançant el servidor d'intercanvi.
Correspondència dels objectes de l'esquema considerat amb els elements del model del mòdul d'integració:
"Servidor d'intercanvi de RBS" – Servidor RBS IKB YUL.
"Servidor d'intercanvi des del costat ABS" - Servidor d'intercanvi.
"intermediari" - absent.
"Programari de tractament de dades" – Components del servidor RB responsables d'utilitzar l'API del servidor d'intercanvi, components del servidor d'intercanvi responsables de l'ús de l'API ABS.
Amenaces de seguretat de primer nivell
Descomposició
U1. La introducció d'informació falsa per part dels malfactors mitjançant el mòdul d'integració.
U1. La introducció d'informació falsa per part dels atacants mitjançant el mòdul d'integració
Descomposició
U1.1. Modificació no autoritzada de dades legítimes durant la seva transmissió a través de connexions de xarxa:
Enllaç U1.1.1: .
Y1.2. Transferència de dades falses a través de canals de comunicació en nom d'un participant legítim de l'intercanvi:
Enllaç U1.1.2: .
Y1.3. Modificació no autoritzada de dades legítimes durant el seu tractament als Servidors d'Exchange o a l'Intermediari:
Y1.3.1. Enllaç: .
U1.4. Creació als servidors d'intercanvi o a l'intermediari de dades falses en nom d'un participant legítim de l'intercanvi:
Y1.4.1. Enllaç:
Y1.5. Modificació no autoritzada de dades durant el seu tractament mitjançant programari de tractament de dades:
U1.5.1. <…> a causa de la introducció de canvis no autoritzats per part dels intrusos a la configuració (configuració) del programari de tractament de dades.
U1.5.2. <…> a causa dels intrusos que fan canvis no autoritzats als fitxers executables del programari de tractament de dades.
U1.5.3. <...> a causa del control interactiu del programari de processament de dades per part dels atacants.
MODEL TÍPIC D'AMENACES. SISTEMA DE PROTECCIÓ DE LA INFORMACIÓ CRIPTOGRÀFICA
L'objecte de protecció al qual s'aplica el model d'amenaça (abast)
L'objecte de protecció és el sistema de protecció de la informació criptogràfica utilitzat per garantir la seguretat del sistema d'informació.
arquitectura
La base de qualsevol sistema d'informació és el programari d'aplicació (programari) que implementa la seva funcionalitat objectiu.
En aquest cas, la protecció criptogràfica sol implementar-se cridant primitives criptogràfiques des de la lògica empresarial del programari d'aplicació, que es troben en biblioteques especialitzades: nuclis criptogràfics.
Les primitives criptogràfiques inclouen funcions criptogràfiques de baix nivell com ara:
- xifrar/desxifrar el bloc de dades;
- crear/verificar la signatura electrònica del bloc de dades;
- calcular la funció hash del bloc de dades;
- generar / carregar / carregar informació clau;
- etcètera
La lògica de negoci del programari d'aplicació, utilitzant primitives criptogràfiques, implementa una funcionalitat de nivell superior:
- xifrar el fitxer amb les claus dels destinataris seleccionats;
- establir una connexió de xarxa segura;
- informar sobre els resultats de la verificació de la signatura electrònica;
- i així successivament.
La interacció de la lògica de negoci i el nucli criptogràfic es pot realitzar:
- directament, cridant primitives criptogràfiques des de les biblioteques dinàmiques del cryptokernel (.DLL - per a Windows, .SO - per a Linux) per la lògica empresarial;
- directament, mitjançant interfícies criptogràfiques: embolcalls, per exemple, MS Crypto API, Java Cryptography Architecture, PKCS # 11, etc. En aquest cas, la lògica empresarial es refereix a la interfície criptogràfica i tradueix la trucada al nucli criptogràfic corresponent, que en aquest cas s'anomena proveïdor de cripto. L'ús d'interfícies criptogràfiques permet al programari d'aplicacions abstraure's d'algorismes criptogràfics específics i ser més flexible.
Hi ha dos esquemes típics per organitzar un nucli criptogràfic:
Esquema 1: cripto-nucli monolític
Esquema 2 - Split Crypto Core
Els elements dels diagrames anteriors poden ser mòduls de programari separats que s'executen al mateix ordinador o serveis de xarxa que interactuen dins d'una xarxa d'ordinadors.
Quan s'utilitzen sistemes construïts segons l'esquema 1, el programari d'aplicació i el nucli criptogràfic funcionen dins d'un únic entorn per al funcionament d'un mitjà criptogràfic (CFC), per exemple, en el mateix ordinador amb el mateix sistema operatiu. L'usuari del sistema, per regla general, pot executar altres programes dins del mateix entorn operatiu, inclosos els que contenen codi maliciós. En aquestes condicions, hi ha un greu risc de fuga de claus criptogràfiques privades.
Per minimitzar el risc, s'utilitza l'esquema 2, en el qual el nucli criptogràfic es divideix en dues parts:
- La primera part, juntament amb el programari d'aplicació, funciona en un entorn no fiable on hi ha risc d'infecció amb codi maliciós. A aquesta part l'anomenarem "part de programari".
- La segona part funciona en un entorn de confiança en un dispositiu dedicat que conté un magatzem de claus privades. A partir d'ara ens referirem a aquesta part com a "part de maquinari".
La divisió del nucli criptogràfic en parts de programari i maquinari és molt condicional. Hi ha sistemes al mercat construïts segons l'esquema amb un nucli criptogràfic dividit, però la part "maquinari" dels quals es presenta en forma d'imatge de màquina virtual: HSM virtual ().
La interacció d'ambdues parts del cryptocore es produeix de manera que les claus criptogràfiques privades mai es transfereixen a la part del programari i, per tant, no es poden robar mitjançant codi maliciós.
La interfície d'interacció (API) i el conjunt de primitives criptogràfiques proporcionades al programari d'aplicació pel cryptocore són els mateixos en ambdós casos. La diferència rau en la manera com s'executen.
Per tant, quan s'utilitza un esquema amb un nucli criptogràfic dividit, la interacció entre programari i maquinari es realitza d'acord amb el principi següent:
- Les primitives criptogràfiques que no requereixen l'ús d'una clau privada (per exemple, el càlcul d'una funció hash, la verificació d'una signatura electrònica, etc.) són realitzades pel programari.
- Les primitives criptogràfiques que utilitzen una clau privada (crear una signatura electrònica, desxifrar dades, etc.) són realitzades pel maquinari.
Il·lustrem el funcionament d'un nucli criptogràfic dividit utilitzant l'exemple de creació d'una signatura electrònica:
- La part del programari calcula la funció hash de les dades signades i transmet aquest valor al maquinari mitjançant el canal d'intercanvi entre els nuclis criptogràfics.
- La part de maquinari, utilitzant la clau privada i el hash, genera el valor de la signatura electrònica i el transfereix a la part de programari a través del canal d'intercanvi.
- La part del programari retorna el valor rebut al programari d'aplicació.
Característiques de la comprovació de la correcció d'una signatura electrònica
Quan la part receptora rep dades signades amb signatura electrònica, ha de realitzar diverses fases de verificació. Un resultat positiu de la verificació d'una signatura electrònica només s'aconsegueix si totes les etapes de la verificació es completen amb èxit.
Etapa 1. Control de la integritat i l'autoria de les dades.
Contingut escènic. La signatura electrònica de les dades es verifica segons l'algorisme criptogràfic corresponent. La superació d'aquesta fase indica que les dades no s'han modificat des de la seva signatura, i que la signatura s'ha fet amb una clau privada corresponent a la clau pública per a la verificació de la signatura electrònica.
Ubicació de l'escenari: criptonucli.
Fase 2. Control de la confiança en la clau pública del signant i control del període de vigència de la clau privada de la signatura electrònica.
Contingut escènic. L'etapa consta de dues subetapes intermèdies. El primer estableix si la clau pública per verificar la signatura electrònica era de confiança en el moment de signar les dades. El segon estableix si la clau privada de la signatura electrònica era vàlida en el moment de signar les dades. En el cas general, els períodes de validesa d'aquestes claus poden no coincidir (per exemple, per a certificats qualificats de claus de verificació de signatura electrònica). Els mètodes per establir la confiança en la clau pública del signant estan determinats per les normes de gestió documental electrònica adoptades per les parts que interactuen.
Ubicació de l'escenari: programari d'aplicació / cripto-nucli.
Fase 3. Control de l'autoritat del signant.
Contingut escènic. D'acord amb les normes establertes de gestió documental electrònica, es comprova si el signant tenia dret a certificar les dades protegides. Per exemple, considereu la situació de violació de l'autoritat. Suposem que hi ha una organització on tots els empleats tenen una signatura electrònica. El sistema de gestió electrònica interna de documents rep una comanda del responsable, però signada per la signatura electrònica del responsable del magatzem. En conseqüència, aquest document no es pot considerar legítim.
Ubicació de l'escenari: programari d'aplicació.
Hipòtesis que es fan a l'hora de descriure l'objecte de protecció
- Els canals de transferència d'informació, a excepció dels canals d'intercanvi de claus, també passen per programari d'aplicació, API i cripto-core.
- La informació sobre la confiança en les claus públiques i (o) els certificats, així com la informació sobre l'autoritat dels propietaris de claus públiques, es col·loca al magatzem de claus públiques.
- El programari d'aplicació funciona amb l'emmagatzematge de claus públiques mitjançant el nucli criptogràfic.
Un exemple de sistema d'informació protegit amb CIPF
Per il·lustrar els esquemes presentats anteriorment, considereu un sistema d'informació hipotètic i seleccioneu-hi tots els elements estructurals.
Descripció del sistema d'informació
Les dues organitzacions van decidir introduir la gestió de documents electrònics (EDF) legalment vinculant entre elles. Per fer-ho, van signar un acord en el qual asseguraven que els documents es transmetrien per correu electrònic, i al mateix temps s'han d'encriptar i signar amb una signatura electrònica qualificada. Com a mitjà per crear i processar documents, s'han d'utilitzar programes d'oficina del paquet Microsoft Office 2016 i com a mitjà de protecció criptogràfica: CIPF CryptoPRO i programari de xifratge CryptoARM.
Descripció de la infraestructura de l'organització 1
L'organització 1 va decidir que instal·laria el programari CryptoPRO CIPF i CryptoARM a l'estació de treball de l'usuari: un ordinador físic. Les claus d'encriptació i signatura electrònica s'emmagatzemaran al portador de claus ruToken que funciona en el mode de clau recuperable. L'usuari prepararà localment els documents electrònics al seu ordinador, després dels quals seran xifrats, signats i enviats mitjançant un client de correu instal·lat localment.
Descripció de la infraestructura de l'organització 2
L'organització 2 va decidir traslladar les funcions de xifratge i signatura electrònica a una màquina virtual dedicada. En aquest cas, totes les operacions criptogràfiques es realitzaran automàticament.
Per fer-ho, s'organitzen dues carpetes de xarxa en una màquina virtual dedicada: “…In”, “…Out”. Els fitxers rebuts de la contrapart en forma oberta es col·locaran automàticament a la carpeta de xarxa "...A". Aquests fitxers seran desxifrats i es verificarà la signatura electrònica en ells.
A la carpeta “…Fora”, l'usuari col·locarà els fitxers que s'han de xifrar, signar i enviar a la contrapart. L'usuari prepararà els fitxers ell mateix a la seva estació de treball.
Per realitzar funcions de xifratge i signatura electrònica, s'instal·len a la màquina virtual CryptoPRO CIPF, el programari CryptoARM i un client de correu. La gestió automàtica de tots els elements de la màquina virtual es durà a terme mitjançant scripts desenvolupats pels administradors del sistema. El treball dels scripts es registra als fitxers de registre (logs).
Les claus criptogràfiques de la signatura electrònica es col·locaran en un testimoni amb una clau no recuperable de JaCarta GOST, que l'usuari connectarà al seu ordinador local.
El testimoni s'enviarà a la màquina virtual mitjançant un programari especialitzat d'USB sobre IP instal·lat a l'estació de treball de l'usuari i a la màquina virtual.
El rellotge del sistema a l'estació de treball de l'usuari a l'organització 1 s'ajustarà manualment. El rellotge del sistema de la màquina virtual dedicada a l'organització 2 es sincronitzarà amb el rellotge del sistema de l'hipervisor, que al seu torn es sincronitzarà a través d'Internet amb servidors de temps públics.
Assignació d'elements estructurals del CIPF
A partir de la descripció anterior de la infraestructura informàtica, destaquem els elements estructurals del CIPF i els anotem en una taula.
Taula - Correspondència dels elements del model CIPF amb els elements dels sistemes d'informació
Nom de l'element
Organització 1
Organització 2
Programari d'aplicació
Programari CryptoARM
Programari CryptoARM
La part del programari del criptokernel
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
La part de maquinari del cryptokernel
no
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Emmagatzematge de claus públiques
Estació de treball d'usuari:
- disc dur;
- magatzem de certificats estàndard de Windows.
Hipervisor:
- HDD.
Màquina virtual:
- disc dur;
- magatzem de certificats estàndard de Windows.
Emmagatzematge de clau privada
Portador de claus ruToken que funciona en el mode de clau extraïble
El portador de claus JaCarta GOST funciona en mode de clau no recuperable
Canal d'intercanvi de claus públiques
Estació de treball d'usuari:
- RAM.
Hipervisor:
- RAM.
Màquina virtual:
- RAM.
Canal d'intercanvi de claus privades
Estació de treball d'usuari:
- Bus USB;
- RAM.
no
Canal d'intercanvi entre cripto-nuclis
absent (no hi ha maquinari criptogràfic)
Estació de treball d'usuari:
- Bus USB;
- RAM;
- Mòdul de programari USB sobre IP;
- interfície de xarxa.
Xarxa corporativa de l'organització 2.
Hipervisor:
- RAM;
- interfície de xarxa.
Màquina virtual:
- interfície de xarxa;
- RAM;
- Mòdul de programari USB sobre IP.
Canal obert d'intercanvi de dades
Estació de treball d'usuari:
- mitjans d'entrada-sortida;
- RAM;
- HDD.
Estació de treball d'usuari:
- mitjans d'entrada-sortida;
- RAM;
- disc dur;
- interfície de xarxa.
Xarxa corporativa de l'organització 2.
Hipervisor:
- interfície de xarxa;
- RAM;
- HDD.
Màquina virtual:
- interfície de xarxa;
- RAM;
- HDD.
Canal d'intercanvi de dades segur
Internet.
Xarxa corporativa de l'organització 1.
Estació de treball d'usuari:
- disc dur;
- RAM;
- interfície de xarxa.
Internet.
Xarxa corporativa de l'organització 2.
Hipervisor:
- interfície de xarxa;
- RAM;
- HDD.
Màquina virtual:
- interfície de xarxa;
- RAM;
- HDD.
Canal del temps
Estació de treball d'usuari:
- mitjans d'entrada-sortida;
- RAM;
- Temporitzador del sistema.
Internet.
Xarxa corporativa de l'organització 2,
Hipervisor:
- interfície de xarxa;
- RAM;
- Temporitzador del sistema.
Màquina virtual:
- RAM;
- Temporitzador del sistema.
Canal de transmissió de comandaments de control
Estació de treball d'usuari:
- mitjans d'entrada-sortida;
- RAM.
(GUI del programari CryptoARM)
Màquina virtual:
- RAM;
- HDD.
(Guions d'automatització)
Canal per rebre resultats del treball
Estació de treball d'usuari:
- mitjans d'entrada-sortida;
- RAM.
(GUI del programari CryptoARM)
Màquina virtual:
- RAM;
- HDD.
(Fitxers de registre per a scripts d'automatització)
Amenaces de seguretat de primer nivell
Explicacions
Hipòtesis fetes en la descomposició de les amenaces:
- S'utilitzen algorismes criptogràfics forts.
- Els algorismes criptogràfics s'utilitzen de forma segura en els modes de funcionament correctes (per exemple, no s'aplica al xifrat de grans quantitats de dades, es té en compte la càrrega admissible de la clau, etc.).
- Els malfactors coneixen tots els algorismes, protocols i claus públiques utilitzats.
- Els atacants tenen accés a totes les dades xifrades.
- Els atacants poden reproduir qualsevol element del programa del sistema.
Descomposició
U1. Compromís de claus criptogràfiques privades.
U2. Xifratge de dades falses en nom d'un remitent legítim.
U3. Desxifrat de dades xifrades per persones que no són destinataris legítims de dades (intrusos).
U4. Creació d'una signatura electrònica d'un signant legítim sota dades falses.
U5. Obtenció d'un resultat positiu de la comprovació de la signatura electrònica de dades falses.
U6. Acceptació errònia de documents electrònics per a la seva execució per problemes en l'organització de la gestió documental electrònica.
U7. Accés no autoritzat a dades protegides durant el seu tractament pel CIPF.
U1. Compromís de claus criptogràfiques privades
U1.1. Obteniu la clau privada de la botiga de claus privades.
Y1.2. Obtenció d'una clau privada dels objectes de l'entorn de funcionament de l'eina criptogràfica, en la qual es pot localitzar temporalment.
Explicacions Y1.2.
Els objectes que poden emmagatzemar temporalment una clau privada inclouen:
- RAM,
- fitxers temporals,
- fitxers de paginació,
- fitxers d'hibernació,
- fitxers d'instantània de l'estat "calent" de les màquines virtuals, inclosos els fitxers del contingut de la memòria RAM de les màquines virtuals que s'han posat en pausa.
U1.2.1. Recuperació de claus privades de la memòria RAM en funcionament congelant els mòduls de la memòria RAM, extraient-los i després llegint les dades (atac de congelació).
Explicacions Y1.2.1.
Exemple .
Y1.3. Obtenció d'una clau privada d'un canal d'intercanvi de clau privada.
Explicacions Y1.3.
Es donarà un exemple de la implementació d'aquesta amenaça .
U1.4. Modificació no autoritzada del nucli criptogràfic, com a resultat de la qual les claus privades són conegudes pels atacants.
Y1.5. Compromís de la clau privada com a conseqüència de l'ús de canals tècnics de fuga d'informació (TCLE).
Explicacions Y1.5.
Exemple .
U1.6. Compromís de la clau privada com a resultat de l'ús de mitjans tècnics especials (STS) dissenyats per a la recuperació secreta d'informació ("errors").
Y1.7. Compromís de les claus privades durant el seu emmagatzematge fora del CIPF.
Explicacions Y1.7.
Per exemple, un usuari guarda els seus mitjans clau en un calaix de l'escriptori, des del qual els intrusos els poden recuperar fàcilment.
U2. Xifratge de dades falses en nom d'un remitent legítim
Explicacions
Aquesta amenaça només es considera per als esquemes de xifratge de dades amb autenticació del remitent. A les recomanacions d'estandardització s'indiquen exemples d'aquests esquemes. . Per a altres esquemes criptogràfics, aquesta amenaça no existeix, ja que el xifratge es realitza a les claus públiques del destinatari, i generalment són conegudes pels atacants.
Descomposició
Y2.1. Compromís de la clau privada del remitent:
Y2.1.1. Enllaç: .
Y2.2. Substitució de dades d'entrada en el canal d'intercanvi de dades obert.
Notes U2.2.
A continuació es donen exemples de la implementació d'aquesta amenaça. и .
U3. Desxifrat de dades xifrades per persones que no són destinataris legítims de dades (intrusos)
Descomposició
Y3.1. Compromís de les claus privades del destinatari de les dades xifrades.
Enllaç U3.1.1: .
Y3.2. Substitució de dades xifrades en un canal d'intercanvi de dades segur.
U4. Creació d'una signatura electrònica d'un signant legítim sota dades falses
Descomposició
Y4.1. Compromís de claus privades de la signatura electrònica d'un signant legítim.
Enllaç U4.1.1: .
Y4.2. Substitució de dades signades en el canal d'intercanvi de dades obertes.
Nota U4.2.
A continuació es donen exemples de la implementació d'aquesta amenaça. и .
U5. Obtenció d'un resultat positiu de la comprovació de la signatura electrònica de dades falses
Descomposició
Y5.1. Els malfactors intercepten en el canal de transmissió de resultats del treball el missatge de resultat negatiu de la comprovació de la signatura electrònica i el substitueixen pel missatge amb resultat positiu.
Y5.2. Els atacants fan un atac a la confiança en la signatura de certificats (ESCENARI: tots els elements són necessaris):
U5.2.1. Els atacants generen una clau pública i privada per a una signatura electrònica. Si el sistema utilitza certificats de clau de signatura electrònica, generen un certificat de signatura electrònica el més semblant possible al certificat del presumpte remitent de les dades el missatge del qual volen falsificar.
U5.2.2. Els atacants fan canvis no autoritzats al magatzem de claus públiques, dotant la clau pública generada per ells amb el nivell de confiança i autoritat necessaris.
Y5.2.3. Els atacants signen dades falses amb una clau de signatura electrònica generada prèviament i les incrusten en un canal d'intercanvi de dades segur.
Y5.3. Els atacants duen a terme un atac utilitzant claus de signatura electrònica caducades d'un signant legal (ESCENARI: tots els elements són necessaris):
Y5.3.1. Els atacants comprometen les claus privades caducades (actualment no vàlides) de la signatura electrònica del remitent legítim.
Y5.3.2. Els atacants substitueixen l'hora del canal de transmissió de temps per l'hora en què les claus compromeses encara eren vàlides.
Y5.3.3. Els atacants signen dades falses amb una clau de signatura electrònica prèviament compromesa i les incrusten en un canal d'intercanvi de dades segur.
Y5.4. Els atacants duen a terme un atac utilitzant claus de signatura electrònica compromesa d'un signant legal (ESCENARI: tots els elements són necessaris):
Y5.4.1. Els atacants fan una còpia del magatzem de claus públiques.
Y5.4.2. Els atacants comprometen les claus privades d'un dels remitents legítims. S'adona del compromís, revoca les claus, la informació sobre la revocació de la clau es col·loca al magatzem de claus públiques.
Y5.4.3. Els atacants substitueixen el magatzem de claus públiques per un de copiat anteriorment.
Y5.4.4. Els atacants signen dades falses amb una clau de signatura electrònica prèviament compromesa i les incrusten en un canal d'intercanvi de dades segur.
Y5.5. <...> a causa de la presència d'errors en la implementació de la 2a i 3a fase de verificació de la signatura electrònica:
Explicacions Y5.5.
Es dóna un exemple de la implementació d'aquesta amenaça .
U5.5.1. Verificació de la confiança en el certificat de la clau de signatura electrònica només per la presència de confiança en el certificat amb el qual està signat, sense comprovacions CRL o OCSP.
Explicacions Y5.5.1.
Exemple d'implementació .
U5.5.2. Quan es construeix una cadena de confiança per a un certificat, no s'analitza l'autoritat d'emissió de certificats
Explicacions Y5.5.2.
Un exemple d'atac contra certificats SSL/TLS.
Els atacants van comprar un certificat legítim per al seu correu electrònic. Després van fer un certificat de lloc web fraudulent i el van signar amb el seu propi certificat. Si la comprovació de credencials no es realitza, en comprovar la cadena de confiança, resultarà correcta i, en conseqüència, el certificat fraudulent també ho serà.
Y5.5.3. Quan es construeix una cadena de confiança de certificats, no es comprova la revocació dels certificats intermedis.
Y5.5.4. Els CRL s'actualitzen amb menys freqüència de la que l'autoritat de certificació els emet.
Y5.5.5. La decisió de confiar en la signatura electrònica es pren abans de rebre la resposta de l'OCSP sobre l'estat del certificat, enviada a una sol·licitud feta posteriorment a l'hora de generació de la signatura o abans de la següent després de rebre la signatura de CRL.
Explicacions Y5.5.5.
A la normativa de la majoria de les CA, el temps de revocació del certificat es considera el moment d'emissió del CRL més proper que conté informació sobre la revocació del certificat.
U5.5.6. En rebre les dades signades, no es verifica la titularitat del certificat per part del remitent.
Explicacions Y5.5.6.
Exemple d'atac. Per als certificats SSL, és possible que no comproveu si l'adreça del servidor cridat coincideix amb el valor del camp CN del certificat.
Exemple d'atac. Els atacants van comprometre les claus de signatura electrònica d'un dels participants en el sistema de pagament. Després d'això, van piratejar la xarxa d'un altre participant i, en nom seu, van enviar documents de pagament signats amb claus compromeses al servidor de liquidació del sistema de pagament. Si el servidor només analitza la confiança i no verifica el seu compliment, els documents fraudulents es consideraran legítims.
U6. Acceptació errònia de documents electrònics per a la seva execució per problemes en l'organització de la gestió documental electrònica.
Descomposició
U6.1. La part receptora no detecta la duplicació dels documents rebuts.
Explicacions Y6.1.
Exemple d'atac. Els malfactors poden interceptar el document transferit al destinatari, encara que estigui protegit criptogràficament, i després enviar-lo repetidament al canal de transmissió de dades segur. Si el destinatari no detecta duplicats, tots els documents rebuts es percebran i es processaran com a documents diferents.
U7. Accés no autoritzat a dades protegides durant el seu tractament pel CIPF
Descomposició
U7.1. <…> a causa de la filtració d'informació a través de canals de tercers (atac de canal lateral).
Explicacions Y7.1.
Exemple .
U7.2. <...> a causa de la neutralització de la protecció contra l'accés no autoritzat a la informació tractada al CIPF:
Y7.2.1. Funcionament del CIPF amb infraccions dels requisits descrits a la documentació del CIPF.
Y7.2.2. <…> implementat a causa de la presència de vulnerabilitats a:
Y7.2.2.1. <…> mitjans de protecció contra l'accés no autoritzat.
Y7.2.2.2. <…> el propi CIPF.
Y7.2.2.3. <...> l'entorn per al funcionament de l'eina criptogràfica.
Exemples d'atac
Els escenaris comentats a continuació contenen, òbviament, errors en l'organització de la seguretat de la informació i només serveixen per il·lustrar possibles atacs.
Escenari 1. Un exemple de la implementació de les amenaces U2.2 i U4.2.
Descripció de l'objecte
El programari ARM KBR i CIPF SCAD Signature s'instal·len en un ordinador físic que no està connectat a una xarxa informàtica. El vdToken FKN s'utilitza com a portador de claus en el mode d'operació amb una clau no recuperable.
El reglament de liquidació suposa que l'especialista en liquidació des del seu ordinador de treball descarrega missatges electrònics en text clar (l'esquema de l'antic KBR AWS) des d'un servidor de fitxers segur especial, després els escriu a una unitat flash USB extraïble i els transfereix al KBR AWP. , on estan xifrats i signes. Després d'això, l'especialista transfereix missatges electrònics segurs a un mitjà transferible i després, a través del seu ordinador de treball, els escriu a un servidor de fitxers, des d'on arriben a UTA i després al sistema de pagament del Banc de Rússia.
En aquest cas, els canals d'intercanvi de dades obertes i segures inclouran: un servidor de fitxers, un ordinador de treball d'un especialista i un suport transferible.
Atac
Els atacants no autoritzats instal·len un sistema de control remot a l'ordinador de treball de l'especialista i, en el moment d'enregistrar les ordres de pagament (missatges electrònics) en el suport transferible, substitueixen obertament el contingut d'un d'ells. L'especialista transfereix les ordres de pagament a l'AWS del KBR, les signa i les xifra sense adonar-se de la substitució (per exemple, a causa del gran nombre d'ordres de pagament al vol, fatiga, etc.). Després d'això, l'ordre de pagament falsa, després d'haver passat per la cadena tecnològica, entra al sistema de pagament del Banc de Rússia.
Escenari 2. Un exemple de la implementació de les amenaces U2.2 i U4.2.
Descripció de l'objecte
L'ordinador amb l'AWS KBR, SKAD Signature instal·lat i el portador de claus connectat del FKN vdToken funciona en una sala dedicada sense accés del personal.
L'especialista en liquidació es connecta a l'AWS del KBR en mode d'accés remot mitjançant el protocol RDP.
Atac
Els atacants intercepten els detalls, mitjançant els quals l'especialista en assentaments es connecta i treballa amb el lloc de treball automatitzat KBR (per exemple, a causa del codi maliciós al seu ordinador). A continuació, es connecten en nom seu i envien una ordre de pagament falsa al sistema de pagament del Banc de Rússia.
Escenari 3. Un exemple d'implementació de l'amenaça U1.3.
Descripció de l'objecte
Considerem una de les opcions hipotètiques per a la implementació de mòduls d'integració ABS-KBR per al nou esquema (ARM KBR-N), en què la signatura electrònica dels documents de sortida es produeix al costat de l'ABS. Al mateix temps, assumirem que l'ABS funciona sobre la base d'un sistema operatiu que no és compatible amb la signatura CIPF SKAD i, en conseqüència, la funcionalitat criptogràfica es col·loca en una màquina virtual separada: el mòdul d'integració ABS-CBR. .
Un testimoni USB normal que funciona en el mode de clau extraïble s'utilitza com a portador de claus. Quan el portador de claus es va connectar a l'hipervisor, va resultar que no hi havia ports USB lliures al sistema, de manera que es va decidir connectar el testimoni USB a través d'un concentrador USB de xarxa i instal·lar un client USB sobre IP al màquina virtual que es comunicarà amb el concentrador.
Atac
Els atacants van interceptar la clau privada de la signatura electrònica des del canal de comunicació entre el concentrador USB i l'hipervisor (les dades es van transmetre en text clar). Tenint una clau privada, els atacants van generar una ordre de pagament falsa, la van signar amb una signatura electrònica i la van enviar al lloc de treball automatitzat KBR-N per a la seva execució.
Escenari 4. Un exemple d'implementació d'amenaces U5.5.
Descripció de l'objecte
Considereu el mateix circuit que en l'escenari anterior. Assumirem que els correus electrònics procedents de l'estació de treball KBR-N acaben a la carpeta …SHAREIn, i els que s'envien a l'estació de treball KBR-N i, més endavant, al sistema de pagament del Banc de Rússia van a …SHAREout.
També assumirem que en implementar el mòdul d'integració, les llistes de certificats revocats s'actualitzen només quan es tornen a emetre les claus criptogràfiques, i també que els missatges electrònics rebuts a la carpeta …SHAREIn només es comproven per al control d'integritat i el control de confiança a la clau pública de la signatura electrònica.
Atac
Els atacants, utilitzant les claus robades en l'escenari anterior, van signar una ordre de pagament falsa que contenia informació sobre la recepció de diners a compte d'un client fraudulent i la van introduir en un canal d'intercanvi de dades segur. Com que no hi ha cap verificació que l'ordre de pagament estigui signada pel Banc de Rússia, s'accepta per a l'execució.
Font: www.habr.com