Link-uri către alte părți ale studiului
- (Esti aici)
Acest articol completează seria de publicații dedicate asigurării securității informaționale a plăților bancare fără numerar. Aici ne vom uita la modelele tipice de amenințare la care se face referire în :
- .
- .
- .
- .
HABRO-AVERTISMENT!!! Dragi Khabroviți, aceasta nu este o postare distractivă.
Cele peste 40 de pagini de materiale ascunse sub tăietură sunt destinate ajutor la muncă sau la studiu persoane specializate în domeniul bancar sau în securitatea informațiilor. Aceste materiale sunt produsul final al cercetării și sunt scrise pe un ton sec, formal. În esență, acestea sunt spații libere pentru documentele interne de securitate a informațiilor.Ei bine, tradițional - „folosirea informațiilor din articol în scopuri ilegale este pedepsită de lege”. Lectură productivă!
Informații pentru cititorii care se familiarizează cu studiul începând cu această publicație.
Despre ce este studiul?
Citiți un ghid pentru un specialist responsabil cu asigurarea securității informațiilor plăților într-o bancă.
Logica prezentării
La început în и se oferă o descriere a obiectului protejat. Apoi în descrie cum se construiește un sistem de securitate și vorbește despre necesitatea creării unui model de amenințare. ÎN vorbește despre ce modele de amenințare există și cum sunt ele formate. ÎN и Este oferită o analiză a atacurilor reale. и conțin o descriere a modelului de amenințare, construită luând în considerare informațiile din toate părțile anterioare.
MODEL TIPIC DE AMENINȚARE. CONEXIUNE RETEA
Obiect de protecție pentru care se aplică modelul de amenințare (sfera).
Obiectul protecției îl reprezintă datele transmise printr-o conexiune de rețea care funcționează în rețele de date construite pe baza stivei TCP/IP.
Arhitectură
Descrierea elementelor arhitecturale:
- „Nodurile de sfârșit” — noduri care fac schimb de informații protejate.
- "Noduri intermediare" — elemente ale unei rețele de transmisie a datelor: routere, comutatoare, servere de acces, servere proxy și alte echipamente — prin care se transmite traficul de conexiune la rețea. În general, o conexiune la rețea poate funcționa fără noduri intermediare (direct între nodurile finale).
Amenințări de securitate de nivel superior
Descompunere
U1. Acces neautorizat la datele transmise.
U2. Modificarea neautorizată a datelor transmise.
U3. Încălcarea dreptului de autor a datelor transmise.
U1. Acces neautorizat la datele transmise
Descompunere
U1.1. , efectuat la nodurile finale sau intermediare:
U1.1.1. citind datele în timp ce acestea se află în dispozitivele de stocare gazdă:
U1.1.1.1. în RAM.
Explicații pentru U1.1.1.1.
De exemplu, în timpul procesării datelor de către stiva de rețea a gazdei.
U1.1.1.2. în memoria nevolatilă.
Explicații pentru U1.1.1.2.
De exemplu, atunci când stocați datele transmise într-un cache, fișiere temporare sau fișiere de schimb.
U1.2. , efectuat pe noduri terțe ale rețelei de date:
U1.2.1. prin metoda de captare a tuturor pachetelor care ajung la interfața de rețea a gazdei:
Explicații pentru U1.2.1.
Capturarea tuturor pachetelor se realizează prin comutarea plăcii de rețea în modul promiscuu (mod promiscuu pentru adaptoarele cu fir sau modul monitor pentru adaptoarele wi-fi).
U1.2.2. prin efectuarea de atacuri „man-in-the-middle” (MiTM), dar fără modificarea datelor transmise (fără a lua în calcul datele serviciului protocolului de rețea).
U1.2.2.1. Legătură: .
U1.3. , realizată din cauza scurgerii de informații prin canale tehnice (TKUI) din nodurile fizice sau liniile de comunicație.
U1.4. , realizat prin instalarea de mijloace tehnice speciale (STS) pe nodurile terminale sau intermediare, destinate colectarii secrete de informatii.
U2. Modificarea neautorizată a datelor transmise
Descompunere
U2.1. , efectuat la nodurile finale sau intermediare:
U2.1.1. prin citirea și modificarea datelor în timp ce acestea se află în dispozitivele de stocare ale nodurilor:
U2.1.1.1. în RAM:
U2.1.1.2. în memoria nevolatilă:
U2.2. , efectuate pe noduri terțe ale rețelei de transmisie a datelor:
U2.2.1. prin efectuarea de atacuri „man-in-the-middle” (MiTM) și redirecționarea traficului către nodul atacatorilor:
U2.2.1.1. Conexiunea fizică a echipamentului atacatorilor face ca o conexiune la rețea să fie întreruptă.
U2.2.1.2. Efectuarea de atacuri asupra protocoalelor de rețea:
U2.2.1.2.1. managementul rețelelor locale virtuale (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Modificarea neautorizată a setărilor VLAN pe comutatoare sau routere.
U2.2.1.2.2. rutarea traficului:
U2.2.1.2.2.1. Modificarea neautorizată a tabelelor statice de rutare ale routerelor.
U2.2.1.2.2.2. Anunțarea rutelor false de către atacatori prin protocoale de rutare dinamică.
U2.2.1.2.3. configurare automată:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. adresare și rezoluție nume:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Efectuarea de modificări neautorizate la fișierele locale de nume de gazdă (gazde, lmhosts etc.)
U3. Încălcarea drepturilor de autor asupra datelor transmise
Descompunere
U3.1. Neutralizarea mecanismelor de determinare a dreptului de autor al informațiilor prin indicarea informațiilor false despre autor sau sursa datelor:
U3.1.1. Modificarea informațiilor despre autor conținute în informațiile transmise.
U3.1.1.1. Neutralizarea protecției criptografice a integrității și a autorului datelor transmise:
U3.1.1.1.1. Legătură: .
U3.1.1.2. Neutralizarea protecției drepturilor de autor a datelor transmise, implementată folosind coduri de confirmare unice:
U3.1.1.2.1. .
U3.1.2. Modificarea informațiilor despre sursa informațiilor transmise:
U3.1.2.1. .
U3.1.2.2. .
MODEL TIPIC DE AMENINȚARE. SISTEM INFORMATIC CONSTRUIT PE BAZĂ A ARHITECTURII CLIENT-SERVER
Obiect de protecție pentru care se aplică modelul de amenințare (sfera).
Obiectul protecției este un sistem informațional construit pe baza unei arhitecturi client-server.
Arhitectură
Descrierea elementelor arhitecturale:
- "Client" – un dispozitiv pe care operează partea client a sistemului informatic.
- "Server" – un dispozitiv pe care funcționează partea server a sistemului informatic.
- „Magazin de date” — parte a infrastructurii de server a unui sistem informatic, concepută pentru a stoca datele prelucrate de sistemul informatic.
- "Conexiune retea" — un canal de schimb de informații între Client și Server care trece prin rețeaua de date. O descriere mai detaliată a modelului elementului este dată în .
Restricții
La modelarea unui obiect, sunt stabilite următoarele restricții:
- Utilizatorul interacționează cu sistemul informațional în perioade finite de timp, numite sesiuni de lucru.
- La începutul fiecărei sesiuni de lucru, utilizatorul este identificat, autentificat și autorizat.
- Toate informațiile protejate sunt stocate pe partea de server a sistemului informatic.
Amenințări de securitate de nivel superior
Descompunere
U1. Efectuarea de acțiuni neautorizate de către atacatori în numele unui utilizator legitim.
U2. Modificarea neautorizată a informațiilor protejate în timpul procesării acestora de către partea de server a sistemului informatic.
U1. Efectuarea de acțiuni neautorizate de către atacatori în numele unui utilizator legitim
explicații
De obicei, în sistemele informaționale, acțiunile sunt corelate cu utilizatorul care le-a efectuat folosind:
- jurnalele de operare a sistemului (jurnalele).
- atribute speciale ale obiectelor de date care conțin informații despre utilizatorul care le-a creat sau modificat.
În legătură cu o sesiune de lucru, această amenințare poate fi descompusă în:
- efectuat în cadrul sesiunii utilizator.
- executat în afara sesiunii utilizator.
O sesiune utilizator poate fi inițiată:
- De către utilizatorul însuși.
- Malefactori.
În această etapă, descompunerea intermediară a acestei amenințări va arăta astfel:
U1.1. Au fost efectuate acțiuni neautorizate în cadrul unei sesiuni de utilizator:
U1.1.1. instalat de utilizatorul atacat.
U1.1.2. instalat de atacatori.
U1.2. Au fost efectuate acțiuni neautorizate în afara sesiunii utilizator.
Din punctul de vedere al obiectelor de infrastructură informațională care pot fi afectate de atacatori, descompunerea amenințărilor intermediare va arăta astfel:
element
Descompunerea amenințării
U1.1.1.
U1.1.2.
U1.2.
client
U1.1.1.1.
U1.1.2.1.
Conexiune retea
U1.1.1.2.
Server
U1.2.1.
Descompunere
U1.1. Au fost efectuate acțiuni neautorizate în cadrul unei sesiuni de utilizator:
U1.1.1. instalat de utilizatorul atacat:
U1.1.1.1. Atacatorii au acționat independent de Client:
U1.1.1.1.1 Atacatorii au folosit instrumente standard de acces la sistemul informatic:
У1.1.1.1.1.1. Atacatorii au folosit mijloacele fizice de intrare/ieșire ale Clientului (tastatură, mouse, monitor sau ecran tactil al unui dispozitiv mobil):
U1.1.1.1.1.1.1. Atacatorii au operat în perioadele de timp în care sesiunea era activă, facilitățile I/O erau disponibile și utilizatorul nu era prezent.
У1.1.1.1.1.2. Atacatorii au folosit instrumente de administrare la distanță (standard sau furnizate de cod rău intenționat) pentru a gestiona Clientul:
U1.1.1.1.1.2.1. Atacatorii au operat în perioadele de timp în care sesiunea era activă, facilitățile I/O erau disponibile și utilizatorul nu era prezent.
У1.1.1.1.1.2.2. Atacatorii au folosit instrumente de administrare la distanță, a căror funcționare este invizibilă pentru utilizatorul atacat.
U1.1.1.2. Atacatorii au înlocuit datele din conexiunea de rețea dintre Client și Server, modificându-le în așa fel încât să fie percepute ca acțiuni ale unui utilizator legitim:
U1.1.1.2.1. Legătură: .
U1.1.1.3. Atacatorii l-au forțat pe utilizator să efectueze acțiunile pe care le-au specificat folosind metode de inginerie socială.
У1.1.2 instalat de atacatori:
U1.1.2.1. Atacatorii au acționat din partea Clientului (И):
U1.1.2.1.1. Atacatorii au neutralizat sistemul de control al accesului la sistemul informatic:
U1.1.2.1.1.1. Legătură: .
У1.1.2.1.2. Atacatorii au folosit instrumente standard de acces la sistemul informatic
U1.1.2.2. Atacatorii au operat de pe alte noduri ale rețelei de date, din care se putea stabili o conexiune de rețea la Server (И):
U1.1.2.2.1. Atacatorii au neutralizat sistemul de control al accesului la sistemul informatic:
U1.1.2.2.1.1. Legătură: .
U1.1.2.2.2. Atacatorii au folosit mijloace non-standard de acces la sistemul informatic.
Explicații U1.1.2.2.2.
Atacatorii ar putea instala un client standard al sistemului informatic pe un nod terță parte sau ar putea folosi software non-standard care implementează protocoale standard de schimb între Client și Server.
U1.2 Au fost efectuate acțiuni neautorizate în afara sesiunii utilizator.
U1.2.1 Atacatorii au efectuat acțiuni neautorizate și apoi au făcut modificări neautorizate în jurnalele de operare a sistemului informațional sau în atributele speciale ale obiectelor de date, indicând că acțiunile pe care le-au efectuat au fost efectuate de un utilizator legitim.
U2. Modificarea neautorizată a informațiilor protejate în timpul procesării acestora de către partea de server a sistemului informatic
Descompunere
U2.1. Atacatorii modifică informațiile protejate folosind instrumente standard ale sistemului de informații și fac acest lucru în numele unui utilizator legitim.
U2.1.1. Legătură: .
U2.2. Atacatorii modifică informațiile protejate utilizând mecanisme de acces la date neprevăzute de funcționarea normală a sistemului informațional.
U2.2.1. Atacatorii modifică fișierele care conțin informații protejate:
U2.2.1.1. , folosind mecanismele de gestionare a fișierelor furnizate de sistemul de operare.
U2.2.1.2. provocând restaurarea fișierelor dintr-o copie de rezervă modificată neautorizat.
U2.2.2. Atacatorii modifică informațiile protejate stocate în baza de date (И):
U2.2.2.1. Atacatorii neutralizează sistemul de control al accesului DBMS:
U2.2.2.1.1. Legătură: .
U2.2.2.2. Atacatorii modifică informațiile folosind interfețele standard DBMS pentru a accesa date.
U2.3. Atacatorii modifică informațiile protejate prin modificarea neautorizată a algoritmilor de operare ai software-ului care le prelucrează.
U2.3.1. Codul sursă al software-ului este supus modificării.
U2.3.1. Codul mașină al software-ului este supus modificării.
U2.4. Atacatorii modifică informațiile protejate prin exploatarea vulnerabilităților din software-ul sistemului informatic.
U2.5. Atacatorii modifică informațiile protejate atunci când acestea sunt transferate între componente ale părții server a sistemului informațional (de exemplu, un server de baze de date și un server de aplicații):
U2.5.1. Legătură: .
MODEL TIPIC DE AMENINȚARE. SISTEM DE CONTROL ACCES
Obiect de protecție pentru care se aplică modelul de amenințare (sfera).
Obiectul de protecție pentru care se aplică acest model de amenințare corespunde obiectului de protecție al modelului de amenințare: „Model de amenințare tipic. Un sistem informatic construit pe o arhitectură client-server.”
În acest model de amenințare, un sistem de control al accesului utilizatorului înseamnă o componentă a unui sistem informatic care implementează următoarele funcții:
- Identificarea utilizatorului.
- Autentificarea utilizatorului.
- Autorizări de utilizator.
- Înregistrarea acțiunilor utilizatorului.
Amenințări de securitate de nivel superior
Descompunere
U1. Stabilirea neautorizată a unei sesiuni în numele unui utilizator legitim.
U2. Creșterea neautorizată a privilegiilor utilizatorului într-un sistem informatic.
U1. Stabilirea neautorizată a unei sesiuni în numele unui utilizator legitim
explicații
Descompunerea acestei amenințări va depinde în general de tipul de sisteme de identificare și autentificare a utilizatorilor utilizate.
În acest model, va fi luat în considerare doar un sistem de identificare și autentificare a utilizatorului folosind autentificare text și parolă. În acest caz, vom presupune că datele de conectare ale utilizatorului sunt informații disponibile public cunoscute de atacatori.
Descompunere
U1.1. din cauza compromiterii acreditărilor:
U1.1.1. Atacatorii au compromis acreditările utilizatorului în timp ce le-au stocat.
Explicații U1.1.1.
De exemplu, acreditările ar putea fi scrise pe un bilețel lipit de monitor.
U1.1.2. Utilizatorul a transmis accidental sau rău intenționat detaliile de acces atacatorilor.
U1.1.2.1. Utilizatorul a rostit acreditările cu voce tare când a intrat.
U1.1.2.2. Utilizatorul și-a partajat în mod intenționat acreditările:
U1.1.2.2.1. la colegii de muncă.
Explicații U1.1.2.2.1.
De exemplu, pentru a-l putea înlocui în timpul bolii.
U1.1.2.2.2. contractanților angajatorului care efectuează lucrări la obiecte de infrastructură informațională.
U1.1.2.2.3. către terți.
Explicații U1.1.2.2.3.
Una, dar nu singura opțiune pentru implementarea acestei amenințări, este utilizarea metodelor de inginerie socială de către atacatori.
U1.1.3. Atacatorii au selectat acreditările folosind metode de forță brută:
U1.1.3.1. folosind mecanisme de acces standard.
U1.1.3.2. folosind coduri interceptate anterior (de exemplu, hash-uri de parole) pentru stocarea acreditărilor.
U1.1.4. Atacatorii au folosit cod rău intenționat pentru a intercepta acreditările utilizatorilor.
U1.1.5. Atacatorii au extras acreditările din conexiunea de rețea dintre Client și Server:
U1.1.5.1. Legătură: .
U1.1.6. Atacatorii au extras acreditările din înregistrările sistemelor de monitorizare a muncii:
U1.1.6.1. sisteme de supraveghere video (dacă apăsările de pe tastatură au fost înregistrate în timpul funcționării).
U1.1.6.2. sisteme de monitorizare a acțiunilor angajaților la computer
Explicații U1.1.6.2.
Un exemplu de astfel de sistem este .
U1.1.7. Atacatorii au compromis acreditările utilizatorului din cauza unor defecte în procesul de transmitere.
Explicații U1.1.7.
De exemplu, trimiterea parolelor în text clar prin e-mail.
U1.1.8. Atacatorii au obținut acreditări prin monitorizarea sesiunii unui utilizator folosind sisteme de administrare la distanță.
U1.1.9. Atacatorii au obținut acreditări ca urmare a scurgerii lor prin canale tehnice (TCUI):
U1.1.9.1. Atacatorii au observat cum utilizatorul a introdus acreditările de la tastatură:
U1.1.9.1.1 Atacatorii au fost localizați în imediata apropiere a utilizatorului și au văzut intrarea acreditărilor cu proprii lor ochi.
Explicații U1.1.9.1.1
Astfel de cazuri includ acțiunile colegilor de muncă sau cazul în care tastatura utilizatorului este vizibilă pentru vizitatorii organizației.
U1.1.9.1.2 Atacatorii au folosit mijloace tehnice suplimentare, cum ar fi un binoclu sau un vehicul aerian fără pilot, și au văzut intrarea acreditărilor printr-o fereastră.
U1.1.9.2. Atacatorii au extras acreditările din comunicațiile radio dintre tastatură și unitatea de sistem a computerului atunci când erau conectați printr-o interfață radio (de exemplu, Bluetooth).
U1.1.9.3. Atacatorii au interceptat acreditările prin scurgerea lor prin canalul de radiații și interferențe electromagnetice false (PEMIN).
Explicații U1.1.9.3.
Exemple de atacuri и .
U1.1.9.4. Atacatorul a interceptat introducerea acreditărilor de la tastatură prin utilizarea unor mijloace tehnice speciale (STS) menite să obțină informații în secret.
Explicații U1.1.9.4.
exemple .
U1.1.9.5. Atacatorii au interceptat introducerea acreditărilor de la tastatură folosind
analiza semnalului Wi-Fi modulat de procesul de apăsare a tastei utilizatorului.
Explicații U1.1.9.5.
Exemplu .
U1.1.9.6. Atacatorii au interceptat introducerea acreditărilor de la tastatură analizând sunetele apăsărilor de taste.
Explicații U1.1.9.6.
Exemplu .
U1.1.9.7. Atacatorii au interceptat introducerea acreditărilor de la tastatura unui dispozitiv mobil analizând citirile accelerometrului.
Explicații U1.1.9.7.
Exemplu .
U1.1.10. , salvat anterior pe Client.
Explicații U1.1.10.
De exemplu, un utilizator ar putea salva o autentificare și o parolă în browser pentru a accesa un anumit site.
U1.1.11. Atacatorii au compromis acreditările din cauza unor defecte în procesul de revocare a accesului utilizatorilor.
Explicații U1.1.11.
De exemplu, după ce un utilizator a fost concediat, conturile lui au rămas deblocate.
U1.2. prin exploatarea vulnerabilităților din sistemul de control al accesului.
U2. Creșterea neautorizată a privilegiilor utilizatorului într-un sistem informatic
Descompunere
U2.1 prin efectuarea de modificări neautorizate la datele care conțin informații despre privilegiile utilizatorului.
U2.2 prin utilizarea vulnerabilităților în sistemul de control al accesului.
U2.3. din cauza deficiențelor în procesul de gestionare a accesului utilizatorilor.
Explicații U2.3.
Exemplul 1. Un utilizator i s-a oferit mai mult acces pentru muncă decât avea nevoie din motive de afaceri.
Exemplul 2: După ce un utilizator a fost transferat pe o altă poziție, drepturile de acces acordate anterior nu au fost revocate.
MODEL TIPIC DE AMENINȚARE. MODUL DE INTEGRARE
Obiect de protecție pentru care se aplică modelul de amenințare (sfera).
Un modul de integrare este un set de obiecte de infrastructură informațională concepute pentru a organiza schimbul de informații între sistemele informaționale.
Având în vedere faptul că în rețelele corporative nu este întotdeauna posibilă separarea fără ambiguitate a unui sistem informațional de altul, modulul de integrare poate fi considerat și ca o legătură de legătură între componentele dintr-un sistem informațional.
Arhitectură
Diagrama generalizată a modulului de integrare arată astfel:
Descrierea elementelor arhitecturale:
- „Server de schimb (SO)” – un nod/serviciu/componentă a unui sistem informațional care îndeplinește funcția de schimb de date cu un alt sistem informațional.
- "Mediator" – un nod/serviciu conceput pentru a organiza interacțiunea dintre sistemele informaționale, dar nu o parte a acestora.
exemple „Intermediari” pot exista servicii de e-mail, autobuze de servicii pentru întreprinderi (magistrală de servicii de întreprindere/arhitectură SoA), servere de fișiere terțe etc. În general, modulul de integrare nu poate conține „Intermediari”. - „Software de prelucrare a datelor” – un set de programe care implementează protocoale de schimb de date și conversie de format.
De exemplu, conversia datelor din formatul UFEBS în formatul ABS, schimbarea stărilor mesajelor în timpul transmisiei etc. - "Conexiune retea" corespunde obiectului descris în modelul standard de amenințare „Conexiune la rețea”. Este posibil ca unele dintre conexiunile de rețea prezentate în diagrama de mai sus să nu existe.
Exemple de module de integrare
Schema 1. Integrarea ABS și AWS KBR printr-un server de fișiere terță parte
Pentru a executa plăți, un angajat autorizat al băncii descarcă documente de plată electronice din sistemul bancar de bază și le salvează într-un fișier (în format propriu, de exemplu un dump SQL) într-un folder de rețea (...SHARE) pe un server de fișiere. Apoi, acest fișier este convertit folosind un script convertor într-un set de fișiere în format UFEBS, care sunt apoi citite de stația de lucru CBD.
După aceasta, angajatul autorizat - utilizatorul locului de muncă automatizat KBR - criptează și semnează fișierele primite și le trimite către sistemul de plată al Băncii Rusiei.
Când se primesc plăți de la Banca Rusiei, locul de muncă automatizat al KBR le decriptează și verifică semnătura electronică, după care le înregistrează sub forma unui set de fișiere în format UFEBS pe un server de fișiere. Înainte de a importa documente de plată în ABS, acestea sunt convertite folosind un script de conversie din formatul UFEBS în formatul ABS.
Vom presupune că, în această schemă, ABS-ul funcționează pe un server fizic, stația de lucru KBR funcționează pe un computer dedicat, iar script-ul convertor rulează pe un server de fișiere.
Corespondența obiectelor diagramei luate în considerare cu elementele modelului modulului de integrare:
„Server de schimb din partea ABS” – server ABS.
„Server de schimb din partea AWS KBR” – statie de lucru computer KBR.
"Mediator" – server de fișiere terță parte.
„Software de prelucrare a datelor” – script convertizor.
Schema 2. Integrarea ABS și AWS KBR atunci când plasați un folder de rețea partajat cu plăți pe AWS KBR
Totul este similar cu Schema 1, dar nu se folosește un server de fișiere separat; în schimb, un folder de rețea (...SHARE) cu documente de plată electronică este plasat pe un computer cu o stație de lucru CBD. Scriptul convertor funcționează și pe stația de lucru CBD.
Corespondența obiectelor diagramei luate în considerare cu elementele modelului modulului de integrare:
Similar cu Schema 1, dar "Mediator" nefolosit.
Schema 3. Integrarea ABS și la locul de muncă automatizat KBR-N prin IBM WebSphera MQ și semnarea documentelor electronice „pe partea ABS”
ABS operează pe o platformă care nu este acceptată de Semnătura CIPF SCAD. Semnarea documentelor electronice trimise se realizează pe un server special de semnătură electronică (ES Server). Același server verifică semnătura electronică pe documentele primite de la Banca Rusiei.
ABS încarcă un fișier cu documente de plată în format propriu pe serverul ES.
Serverul ES, folosind un script convertor, convertește fișierul în mesaje electronice în format UFEBS, după care mesajele electronice sunt semnate și transmise către IBM WebSphere MQ.
Stația de lucru KBR-N accesează IBM WebSphere MQ și primește de acolo mesaje de plată semnate, după care un angajat autorizat - un utilizator al stației de lucru KBR - le criptează și le trimite către sistemul de plată al Băncii Rusiei.
Când plățile sunt primite de la Banca Rusiei, locul de muncă automatizat KBR-N le decriptează și verifică semnătura electronică. Plățile procesate cu succes sub formă de mesaje electronice decriptate și semnate în format UFEBS sunt transferate către IBM WebSphere MQ, de unde sunt primite de către Serverul de semnătură electronică.
Serverul de semnătură electronică verifică semnătura electronică a plăților primite și le salvează într-un fișier în format ABS. După aceasta, angajatul autorizat - utilizatorul ABS - încarcă fișierul rezultat în ABS în modul prescris.
Corespondența obiectelor diagramei luate în considerare cu elementele modelului modulului de integrare:
„Server de schimb din partea ABS” – server ABS.
„Server de schimb din partea AWS KBR” — stație de lucru KBR.
"Mediator" – Server ES și IBM WebSphere MQ.
„Software de prelucrare a datelor” – convertor de scripturi, semnătură CIPF SCAD pe serverul ES.
Schema 4. Integrarea serverului RBS și a sistemului bancar de bază prin intermediul API-ului furnizat de un server de schimb dedicat
Vom presupune că banca utilizează mai multe sisteme bancare la distanță (RBS):
- „Internet Client-Bank” pentru persoane fizice (IKB FL);
- „Internet Client-Bank” pentru persoane juridice (IKB LE).
Pentru a asigura securitatea informațiilor, toată interacțiunea dintre ABS și sistemele bancare la distanță se realizează printr-un server de schimb dedicat care funcționează în cadrul sistemului de informații ABS.
În continuare, vom lua în considerare procesul de interacțiune dintre sistemul RBS al IKB LE și ABS.
Serverul RBS, după ce a primit un ordin de plată certificat corespunzător de la client, trebuie să creeze un document corespunzător în ABS pe baza acestuia. Pentru a face acest lucru, folosind API-ul, transmite informații către serverul de schimb, care, la rândul său, introduce datele în ABS.
Când soldurile contului clientului se modifică, ABS generează notificări electronice, care sunt transmise serverului bancar la distanță folosind serverul de schimb.
Corespondența obiectelor diagramei luate în considerare cu elementele modelului modulului de integrare:
„Server de schimb din partea RBS” – Serverul RBS al IKB YUL.
„Server de schimb din partea ABS” – server de schimb.
"Mediator" - dispărut.
„Software de prelucrare a datelor” – Componentele serverului RBS responsabile cu utilizarea API-ului serverului de schimb, componente ale serverului Exchange responsabile cu utilizarea API-ului de bază bancar.
Amenințări de securitate de nivel superior
Descompunere
U1. Injectarea de informații false de către atacatori prin modulul de integrare.
U1. Injectarea de informații false de către atacatori prin modulul de integrare
Descompunere
U1.1. Modificarea neautorizată a datelor legitime atunci când sunt transmise prin conexiuni de rețea:
Legătura U1.1.1: .
U1.2. Transmiterea de date false prin canale de comunicare în numele unui participant legitim la schimb:
Legătura U1.1.2: .
U1.3. Modificarea neautorizată a datelor legitime în timpul prelucrării acestora pe serverele Exchange sau pe intermediar:
U1.3.1. Legătură: .
U1.4. Crearea de date false pe serverele sau intermediarul Exchange în numele unui participant legitim la schimb:
U1.4.1. Legătură:
U1.5. Modificarea neautorizată a datelor atunci când sunt prelucrate folosind software-ul de prelucrare a datelor:
U1.5.1. din cauza atacatorilor care efectuează modificări neautorizate în setările (configurarea) software-ului de procesare a datelor.
U1.5.2. din cauza atacatorilor care efectuează modificări neautorizate în fișierele executabile ale software-ului de procesare a datelor.
U1.5.3. datorită controlului interactiv al software-ului de procesare a datelor de către atacatori.
MODEL TIPIC DE AMENINȚARE. SISTEM DE PROTECȚIE A INFORMAȚIILOR CRIPTOGRAFICE
Obiect de protecție pentru care se aplică modelul de amenințare (sfera).
Obiectul protecției este un sistem de protecție a informațiilor criptografice utilizat pentru a asigura securitatea sistemului informațional.
Arhitectură
Baza oricărui sistem informatic este aplicația software care implementează funcționalitatea țintă.
Protecția criptografică este de obicei implementată prin apelarea primitivelor criptografice din logica de afaceri a software-ului aplicației, care se află în biblioteci specializate - nuclee criptografice.
Primitivele criptografice includ funcții criptografice de nivel scăzut, cum ar fi:
- criptează/decriptează un bloc de date;
- crearea/verificarea unei semnături electronice a unui bloc de date;
- calculați funcția hash a blocului de date;
- generare / încărcare / încărcare informații cheie;
- etc
Logica de afaceri a aplicației software implementează funcționalități de nivel superior folosind primitive criptografice:
- criptați fișierul folosind cheile destinatarilor selectați;
- stabiliți o conexiune la rețea sigură;
- informează despre rezultatele verificării semnăturii electronice;
- și așa mai departe.
Interacțiunea dintre logica de afaceri și nucleul cripto poate fi realizată:
- direct, prin logica de afaceri apelând primitive criptografice din bibliotecile dinamice ale nucleului cripto (.DLL pentru Windows, .SO pentru Linux);
- direct, prin interfețe criptografice - wrapper-uri, de exemplu, MS Crypto API, Java Cryptography Architecture, PKCS#11, etc. În acest caz, logica de afaceri accesează interfața cripto, și traduce apelul în nucleul cripto corespunzător, care în acest caz se numește furnizor de cripto. Utilizarea interfețelor criptografice permite software-ului aplicației să facă abstracție de la algoritmi criptografici specifici și să fie mai flexibil.
Există două scheme tipice pentru organizarea nucleului cripto:
Schema 1 – Miez criptomonolitic
Schema 2 – Divizarea miezului criptografic
Elementele din diagramele de mai sus pot fi fie module software individuale care rulează pe un computer, fie servicii de rețea care interacționează într-o rețea de calculatoare.
Când se utilizează sisteme construite conform Schemei 1, software-ul aplicației și nucleul cripto operează într-un singur mediu de operare pentru instrumentul cripto (SFC), de exemplu, pe același computer, care rulează același sistem de operare. Utilizatorul sistemului, de regulă, poate rula alte programe, inclusiv cele care conțin cod rău intenționat, în același mediu de operare. În astfel de condiții, există un risc serios de scurgere a cheilor criptografice private.
Pentru a minimiza riscul, se utilizează schema 2, în care miezul cripto este împărțit în două părți:
- Prima parte, împreună cu aplicația software, funcționează într-un mediu neîncrezat, unde există riscul de infectare cu cod rău intenționat. Vom numi această parte „partea software”.
- A doua parte funcționează într-un mediu de încredere pe un dispozitiv dedicat, care conține o cheie privată de stocare. De acum înainte vom numi această parte „hardware”.
Împărțirea nucleului cripto în părți software și hardware este foarte arbitrară. Există pe piață sisteme construite conform unei scheme cu un nucleu cripto divizat, dar a cărui parte „hardware” este prezentată sub forma unei imagini de mașină virtuală - HSM virtual ().
Interacțiunea ambelor părți ale nucleului cripto are loc în așa fel încât cheile criptografice private nu sunt niciodată transferate către partea software și, în consecință, nu pot fi furate folosind cod rău intenționat.
Interfața de interacțiune (API) și setul de primitive criptografice furnizate software-ului aplicației de către miezul cripto sunt aceleași în ambele cazuri. Diferența constă în modul în care sunt implementate.
Astfel, atunci când se utilizează o schemă cu un nucleu cripto divizat, interacțiunea dintre software și hardware se realizează conform următorului principiu:
- Primitivele criptografice care nu necesită utilizarea unei chei private (de exemplu, calcularea unei funcții hash, verificarea unei semnături electronice etc.) sunt efectuate de software.
- Primitivele criptografice care folosesc o cheie privată (crearea unei semnături electronice, decriptarea datelor etc.) sunt realizate de hardware.
Să ilustrăm activitatea nucleului cripto divizat folosind exemplul creării unei semnături electronice:
- Partea software calculează funcția hash a datelor semnate și transmite această valoare către hardware prin intermediul canalului de schimb între nucleele cripto.
- Partea hardware, folosind cheia privată și hash, generează valoarea semnăturii electronice și o transmite părții software printr-un canal de schimb.
- Partea software returnează valoarea primită software-ului aplicației.
Caracteristici de verificare a corectitudinii unei semnături electronice
Atunci când partea care primește datele semnate electronic, aceasta trebuie să efectueze mai mulți pași de verificare. Un rezultat pozitiv al verificării unei semnături electronice este obținut numai dacă toate etapele verificării sunt finalizate cu succes.
Etapa 1. Controlul integrității datelor și al autorului datelor.
Conținutul scenei. Semnătura electronică a datelor este verificată folosind algoritmul criptografic corespunzător. Parcurgerea cu succes a acestei etape indică faptul că datele nu au fost modificate din momentul semnării, precum și că semnătura a fost realizată cu o cheie privată corespunzătoare cheii publice de verificare a semnăturii electronice.
Locația scenei: miez criptografic.
Etapa 2. Controlul încrederii în cheia publică a semnatarului și controlul perioadei de valabilitate a cheii private a semnăturii electronice.
Conținutul scenei. Etapa constă din două subetape intermediare. Primul este de a determina dacă cheia publică pentru verificarea semnăturii electronice era de încredere la momentul semnării datelor. Al doilea determină dacă cheia privată a semnăturii electronice era valabilă la momentul semnării datelor. În general, perioadele de valabilitate ale acestor chei pot să nu coincidă (de exemplu, pentru certificatele calificate ale cheilor de verificare a semnăturii electronice). Modalitățile de stabilire a încrederii în cheia publică a semnatarului sunt determinate de regulile de gestionare a documentelor electronice adoptate de părțile care interacționează.
Locația scenei: software de aplicație / nucleu cripto.
Etapa 3. Controlul autorității semnatarului.
Conținutul scenei. În conformitate cu regulile de gestionare electronică a documentelor stabilite, se verifică dacă semnatarul avea dreptul de a certifica datele protejate. Ca exemplu, să dăm o situație de încălcare a autorității. Să presupunem că există o organizație în care toți angajații au o semnătură electronică. Sistemul electronic intern de management al documentelor primește o comandă de la manager, dar semnată cu semnătura electronică a managerului depozitului. Prin urmare, un astfel de document nu poate fi considerat legitim.
Locația scenei: software de aplicație.
Ipoteze făcute la descrierea obiectului de protecție
- Canalele de transmitere a informațiilor, cu excepția canalelor de schimb de chei, trec și prin software-ul de aplicație, API și nucleul cripto.
- Informațiile despre încrederea în cheile publice și (sau) certificate, precum și informații despre puterile proprietarilor de chei publice, sunt plasate în depozitul de chei publice.
- Aplicația software funcționează cu magazinul de chei publice prin intermediul nucleului cripto.
Un exemplu de sistem informatic protejat folosind CIPF
Pentru a ilustra diagramele prezentate anterior, să luăm în considerare un sistem informațional ipotetic și să evidențiem toate elementele structurale de pe acesta.
Descrierea sistemului informatic
Cele două organizații au decis să introducă între ele un management electronic al documentelor (EDF) semnificativ din punct de vedere juridic. Pentru a face acest lucru, aceștia au încheiat un acord în care stipulau că documentele vor fi transmise prin e-mail, iar în același timp trebuie să fie criptate și semnate cu o semnătură electronică calificată. Programele Office din pachetul Microsoft Office 2016 ar trebui folosite ca instrumente pentru crearea și procesarea documentelor, iar CIPF CryptoPRO și software-ul de criptare CryptoARM ar trebui folosite ca mijloace de protecție criptografică.
Descrierea infrastructurii organizației 1
Organizația 1 a decis că va instala software-ul CIPF CryptoPRO și CryptoARM pe stația de lucru a utilizatorului - un computer fizic. Cheile de criptare și semnătură electronică vor fi stocate pe suportul de chei ruToken, funcționând în modul cheie recuperabilă. Utilizatorul va pregăti documentele electronice local pe computerul său, apoi le va cripta, semna și trimite folosind un client de e-mail instalat local.
Descrierea infrastructurii organizației 2
Organizația 2 a decis să mute funcțiile de criptare și semnătură electronică pe o mașină virtuală dedicată. În acest caz, toate operațiunile criptografice vor fi efectuate automat.
Pentru a face acest lucru, pe mașina virtuală dedicată sunt organizate două foldere de rețea: „...In”, „...Out”. Fișierele primite de la contraparte în formă deschisă vor fi plasate automat în folderul de rețea „…În”. Aceste fișiere vor fi decriptate și semnătura electronică va fi verificată.
Utilizatorul va plasa fișiere în folderul „…Out” care trebuie să fie criptate, semnate și trimise către contrapartidă. Utilizatorul va pregăti singur fișierele pe stația sa de lucru.
Pentru a efectua funcții de criptare și semnătură electronică, pe mașina virtuală sunt instalate CIPF CryptoPRO, software-ul CryptoARM și un client de e-mail. Gestionarea automată a tuturor elementelor mașinii virtuale va fi efectuată folosind scripturi dezvoltate de administratorii de sistem. Lucrarea scripturilor este înregistrată în fișierele jurnal.
Cheile criptografice pentru semnătura electronică vor fi plasate pe un token cu o cheie JaCarta GOST nerecuperabilă, pe care utilizatorul o va conecta la computerul său local.
Tokenul va fi redirecționat către mașina virtuală folosind un software specializat USB-over-IP instalat pe stația de lucru a utilizatorului și pe mașina virtuală.
Ceasul de sistem de pe stația de lucru a utilizatorului din organizația 1 va fi reglat manual. Ceasul de sistem al mașinii virtuale dedicate din Organizația 2 va fi sincronizat cu ceasul sistemului hypervisor, care, la rândul său, va fi sincronizat prin Internet cu serverele de timp publice.
Identificarea elementelor structurale ale CIPF
Pe baza descrierii de mai sus a infrastructurii IT, vom evidenția elementele structurale ale CIPF și le vom scrie într-un tabel.
Tabel - Corespondența elementelor modelului CIPF cu elementele sistemului informațional
Numele articolului
Organizarea 1
Organizarea 2
Software de aplicație
Software CryptoARM
Software CryptoARM
Parte software a nucleului cripto
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Hardware de bază cripto
nu
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Magazin de chei publice
Stația de lucru a utilizatorului:
- HDD;
- depozit de certificate standard Windows.
Hypervisor:
- HDD.
Mașină virtuală:
- HDD;
- depozit de certificate standard Windows.
Stocare chei private
Purtatorul de chei ruToken care funcționează în modul cheie recuperabilă
Suportul de chei JaCarta GOST care funcționează în modul cheie nedetașabilă
Canal de schimb de chei publice
Stația de lucru a utilizatorului:
- RAM.
Hypervisor:
- RAM.
Mașină virtuală:
- RAM.
Canal de schimb de chei private
Stația de lucru a utilizatorului:
— magistrală USB;
- RAM.
nu
Canal de schimb între nuclee cripto
lipsă (fără hardware de bază cripto)
Stația de lucru a utilizatorului:
— magistrală USB;
- RAM;
— modul software USB-over-IP;
- interfata retea.
Rețeaua corporativă a organizației 2.
Hypervisor:
- RAM;
- interfata retea.
Mașină virtuală:
- interfata retea;
- RAM;
— Modul software USB-over-IP.
Canal de date deschise
Stația de lucru a utilizatorului:
— mijloace de intrare-ieșire;
- RAM;
- HDD.
Stația de lucru a utilizatorului:
— mijloace de intrare-ieșire;
- RAM;
- HDD;
- interfata retea.
Rețeaua corporativă a organizației 2.
Hypervisor:
- interfata retea;
- RAM;
- HDD.
Mașină virtuală:
- interfata retea;
- RAM;
- HDD.
Canal securizat de schimb de date
Internet.
Rețeaua corporativă a organizației 1.
Stația de lucru a utilizatorului:
- HDD;
- RAM;
- interfata retea.
Internet.
Rețeaua corporativă a organizației 2.
Hypervisor:
- interfata retea;
- RAM;
- HDD.
Mașină virtuală:
- interfata retea;
- RAM;
- HDD.
Canalul de timp
Stația de lucru a utilizatorului:
— mijloace de intrare-ieșire;
- RAM;
- temporizator de sistem.
Internet.
Rețeaua corporativă a organizației 2,
Hypervisor:
- interfata retea;
- RAM;
- temporizator de sistem.
Mașină virtuală:
- RAM;
- temporizator de sistem.
Canalul de transmitere a comenzii de control
Stația de lucru a utilizatorului:
— mijloace de intrare-ieșire;
- RAM.
(Interfața grafică de utilizator a software-ului CryptoARM)
Mașină virtuală:
- RAM;
- HDD.
(Scripturi de automatizare)
Canal pentru primirea rezultatelor muncii
Stația de lucru a utilizatorului:
— mijloace de intrare-ieșire;
- RAM.
(Interfața grafică de utilizator a software-ului CryptoARM)
Mașină virtuală:
- RAM;
- HDD.
(Fișiere jurnal ale scripturilor de automatizare)
Amenințări de securitate de nivel superior
explicații
Ipoteze făcute la descompunerea amenințărilor:
- Se folosesc algoritmi criptografici puternici.
- Algoritmii criptografici sunt utilizați în siguranță în modurile corecte de operare (de ex. nu este utilizat pentru criptarea unor volume mari de date, se ia în considerare încărcarea permisă a cheii etc.).
- Atacatorii cunosc toți algoritmii, protocoalele și cheile publice folosite.
- Atacatorii pot citi toate datele criptate.
- Atacatorii sunt capabili să reproducă orice elemente software din sistem.
Descompunere
U1. Compromisul cheilor criptografice private.
U2. Criptarea datelor false în numele expeditorului legitim.
U3. Decriptarea datelor criptate de către persoane care nu sunt destinatari legitimi ai datelor (atacatori).
U4. Crearea unei semnături electronice a unui semnatar legitim sub date false.
U5. Obținerea unui rezultat pozitiv din verificarea semnăturii electronice a datelor falsificate.
U6. Acceptarea eronată a documentelor electronice spre executare din cauza problemelor de organizare a gestiunii documentelor electronice.
U7. Acces neautorizat la datele protejate în timpul prelucrării acestora de către CIPF.
U1. Compromisul cheilor criptografice private
U1.1. Preluarea cheii private din magazinul de chei private.
U1.2. Obținerea unei chei private de la obiecte din mediul de operare al instrumentului cripto, în care poate locui temporar.
Explicații U1.2.
Obiectele care pot stoca temporar o cheie privată ar include:
- RAM,
- fișiere temporare,
- schimba fișiere,
- fișiere de hibernare,
- fișiere instantanee ale stării „fierbinte” a mașinilor virtuale, inclusiv fișiere ale conținutului RAM al mașinilor virtuale întrerupte.
U1.2.1. Extragerea cheilor private din RAM funcțională prin înghețarea modulelor RAM, eliminarea acestora și apoi citirea datelor (atac înghețat).
Explicații U1.2.1.
Exemplu .
U1.3. Obținerea unei chei private de la un canal de schimb de chei private.
Explicații U1.3.
Va fi dat un exemplu de implementare a acestei amenințări .
U1.4. Modificarea neautorizată a nucleului cripto, în urma căreia cheile private devin cunoscute atacatorilor.
U1.5. Compromisul unei chei private ca urmare a utilizării canalelor de scurgere a informațiilor tehnice (TCIL).
Explicații U1.5.
Exemplu .
U1.6. Compromisul unei chei private ca urmare a utilizării unor mijloace tehnice speciale (STS) concepute pentru preluarea în secret a informațiilor („bug-uri”).
U1.7. Compromisul cheilor private în timpul stocării lor în afara CIPF.
Explicații U1.7.
De exemplu, un utilizator își stochează media cheie într-un sertar de pe desktop, din care pot fi preluate cu ușurință de atacatori.
U2. Criptarea datelor false în numele unui expeditor legitim
explicații
Această amenințare este luată în considerare numai pentru schemele de criptare a datelor cu autentificare a expeditorului. Exemple de astfel de scheme sunt indicate în recomandările de standardizare . Pentru alte scheme criptografice, această amenințare nu există, deoarece criptarea este efectuată pe cheile publice ale destinatarului și sunt în general cunoscute atacatorilor.
Descompunere
U2.1. Se compromite cheia privată a expeditorului:
U2.1.1. Legătură: .
U2.2. Înlocuirea datelor de intrare într-un canal deschis de schimb de date.
Note U2.2.
Mai jos sunt prezentate exemple de implementare a acestei amenințări. и .
U3. Decriptarea datelor criptate de către persoane care nu sunt destinatari legitimi ai datelor (atacatori)
Descompunere
U3.1. Compromisul cheilor private ale destinatarului datelor criptate.
Legătura U3.1.1: .
U3.2. Înlocuirea datelor criptate într-un canal de schimb de date securizat.
U4. Crearea unei semnături electronice a unui semnatar legitim sub date false
Descompunere
U4.1. Compromisul cheilor private ale semnăturii electronice a unui semnatar legitim.
Legătura U4.1.1: .
U4.2. Înlocuirea datelor semnate într-un canal deschis de schimb de date.
Nota U4.2.
Mai jos sunt prezentate exemple de implementare a acestei amenințări. и .
U5. Obținerea unui rezultat pozitiv din verificarea semnăturii electronice a datelor falsificate
Descompunere
U5.1. Atacatorii interceptează un mesaj pe canalul de transmitere a rezultatelor muncii despre un rezultat negativ al verificării unei semnături electronice și îl înlocuiesc cu un mesaj cu un rezultat pozitiv.
U5.2. Atacatorii atacă încrederea în semnarea certificatelor (SCRIPT - toate elementele sunt necesare):
U5.2.1. Atacatorii generează o cheie publică și privată pentru o semnătură electronică. Dacă sistemul utilizează certificate de cheie de semnătură electronică, atunci acestea generează un certificat de semnătură electronică care este cât mai asemănător cu certificatul expeditorului vizat al datelor al cărui mesaj doresc să-l falsifice.
U5.2.2. Atacatorii fac modificări neautorizate în depozitul de chei publice, oferind cheii publice pe care o generează nivelul necesar de încredere și autoritate.
U5.2.3. Atacatorii semnează date false cu o cheie de semnătură electronică generată anterior și o introduc în canalul securizat de schimb de date.
U5.3. Atacatorii efectuează un atac folosind cheile de semnătură electronică expirate ale unui semnatar legal (SCRIPT - toate elementele sunt necesare):
U5.3.1. Atacatorii compromit cheile private expirate (nu sunt valabile în prezent) ale semnăturii electronice ale unui expeditor legitim.
U5.3.2. Atacatorii înlocuiesc ora din canalul de transmisie a timpului cu ora la care cheile compromise erau încă valabile.
U5.3.3. Atacatorii semnează date false cu o cheie de semnătură electronică compromisă anterior și le injectează în canalul securizat de schimb de date.
U5.4. Atacatorii efectuează un atac folosind cheile de semnătură electronică compromise ale unui semnatar legal (SCRIPT - toate elementele sunt necesare):
U5.4.1. Atacatorul face o copie a depozitului de chei publice.
U5.4.2. Atacatorii compromit cheile private ale unuia dintre expeditorii legitimi. El observă compromisul, revocă cheile, iar informațiile despre revocarea cheilor sunt plasate în magazinul de chei publice.
U5.4.3. Atacatorii înlocuiesc depozitul de chei publice cu unul copiat anterior.
U5.4.4. Atacatorii semnează date false cu o cheie de semnătură electronică compromisă anterior și le injectează în canalul securizat de schimb de date.
U5.5. din cauza prezenței erorilor în implementarea etapelor a 2-a și a 3-a de verificare a semnăturii electronice:
Explicații U5.5.
Este dat un exemplu de implementare a acestei amenințări .
U5.5.1. Verificarea încrederii într-un certificat de cheie de semnătură electronică numai prin prezența încrederii în certificatul cu care este semnat, fără verificări CRL sau OCSP.
Explicații U5.5.1.
Exemplu de implementare .
U5.5.2. La construirea unui lanț de încredere pentru un certificat, autoritățile care emit certificate nu sunt analizate
Explicații U5.5.2.
Un exemplu de atac împotriva certificatelor SSL/TLS.
Atacatorii au cumpărat un certificat legitim pentru e-mailul lor. Apoi au făcut un certificat de site fraudulos și l-au semnat cu certificatul lor. Dacă acreditările nu sunt verificate, atunci când se verifică lanțul de încredere, acesta se va dovedi a fi corect și, în consecință, certificatul fraudulos va fi, de asemenea, corect.
U5.5.3. La construirea unui lanț de încredere de certificate, certificatele intermediare nu sunt verificate pentru revocare.
U5.5.4. CRL-urile sunt actualizate mai rar decât sunt emise de autoritatea de certificare.
U5.5.5. Decizia de a avea încredere într-o semnătură electronică se ia înainte de primirea unui răspuns OCSP cu privire la starea certificatului, trimis la o solicitare făcută mai târziu de momentul generării semnăturii sau mai devreme de următorul CRL după generarea semnăturii.
Explicații U5.5.5.
În reglementările majorității CA, momentul revocării certificatului este considerat a fi momentul emiterii celui mai apropiat CRL care conține informații despre revocarea certificatului.
U5.5.6. La primirea datelor semnate, certificatul aparține expeditorului nu este verificat.
Explicații U5.5.6.
Exemplu de atac. În legătură cu certificatele SSL: este posibil să nu fie verificată corespondența adresei serverului apelat cu valoarea câmpului CN din certificat.
Exemplu de atac. Atacatorii au compromis cheile de semnătură electronică ale unuia dintre participanții la sistemul de plată. După aceea, au spart în rețeaua altui participant și, în numele acestuia, au trimis documente de plată semnate cu chei compromise către serverul de decontare al sistemului de plăți. Dacă serverul analizează doar încrederea și nu verifică conformitatea, atunci documentele frauduloase vor fi considerate legitime.
U6. Acceptarea eronată a documentelor electronice spre executare din cauza problemelor de organizare a gestiunii documentelor electronice.
Descompunere
U6.1. Partea care primește nu detectează duplicarea documentelor primite.
Explicații U6.1.
Exemplu de atac. Atacatorii pot intercepta un document care este transmis unui destinatar, chiar dacă este protejat criptografic, apoi îl pot trimite în mod repetat printr-un canal de transmisie de date securizat. Dacă destinatarul nu identifică duplicatele, atunci toate documentele primite vor fi percepute și procesate ca documente diferite.
U7. Acces neautorizat la datele protejate în timpul prelucrării acestora de către CIPF
Descompunere
U7.1. din cauza scurgerii de informații prin canale laterale (atac pe canalul lateral).
Explicații U7.1.
Exemplu .
U7.2. datorită neutralizării protecției împotriva accesului neautorizat la informațiile prelucrate pe CIPF:
U7.2.1. Funcționarea CIPF cu încălcarea cerințelor descrise în documentația pentru CIPF.
U7.2.2. , realizată din cauza prezenței unor vulnerabilități în:
U7.2.2.1. mijloace de protecție împotriva accesului neautorizat.
U7.2.2.2. CIPF însuși.
U7.2.2.3. mediul de operare al instrumentului cripto.
Exemple de atacuri
Scenariile discutate mai jos conțin în mod evident erori de securitate a informațiilor și servesc doar la ilustrarea posibilelor atacuri.
Scenariul 1. Un exemplu de implementare a amenințărilor U2.2 și U4.2.
Descrierea obiectului
Software-ul AWS KBR și CIPF SCAD Signature sunt instalate pe un computer fizic care nu este conectat la rețeaua de calculatoare. FKN vdToken este folosit ca purtător de chei în modul de lucru cu o cheie care nu poate fi amovibilă.
Reglementările de decontare presupun că specialistul în decontare de pe computerul său de lucru descarcă mesaje electronice în text clar (schema vechii stații de lucru KBR) de pe un server de fișiere securizat special, apoi le scrie pe o unitate flash USB transferabilă și le transferă pe stația de lucru KBR, unde sunt criptate și semnate. După aceasta, specialistul transferă mesaje electronice securizate către mediul înstrăinat, iar apoi, prin computerul său de lucru, le scrie pe un server de fișiere, de unde merg la UTA și apoi la sistemul de plăți al Băncii Rusiei.
În acest caz, canalele de schimb de date deschise și protejate vor include: un server de fișiere, computerul de lucru al unui specialist și medii înstrăinate.
Atac
Atacatorii neautorizați instalează un sistem de control de la distanță pe computerul de lucru al unui specialist și, în momentul scrierii ordinelor de plată (mesaje electronice) pe un mediu transferabil, înlocuiesc conținutul unuia dintre ele în text clar. Specialistul transferă ordinele de plată la locul de muncă automatizat KBR, le semnează și le criptează fără a observa înlocuirea (de exemplu, din cauza unui număr mare de ordine de plată pe zbor, oboseală etc.). După aceasta, ordinul de plată fals, după ce a trecut prin lanțul tehnologic, intră în sistemul de plată al Băncii Rusiei.
Scenariul 2. Un exemplu de implementare a amenințărilor U2.2 și U4.2.
Descrierea obiectului
Un computer cu o stație de lucru instalată KBR, SCAD Signature și un purtător de chei conectat FKN vdToken funcționează într-o cameră dedicată fără acces de la personal.
Specialistul în calcul se conectează la stația de lucru CBD în modul de acces la distanță prin protocolul RDP.
Atac
Atacatorii interceptează detaliile, cu ajutorul cărora specialistul în calcul se conectează și lucrează cu stația de lucru CBD (de exemplu, prin intermediul unui cod rău intenționat de pe computerul său). Apoi se conectează în numele lui și trimit un ordin de plată fals către sistemul de plată al Băncii Rusiei.
Scenariul 3. Exemplu de implementare a amenințărilor U1.3.
Descrierea obiectului
Să luăm în considerare una dintre opțiunile ipotetice de implementare a modulelor de integrare ABS-KBR pentru o nouă schemă (AWS KBR-N), în care semnătura electronică a documentelor de ieșire are loc pe partea ABS. În acest caz, vom presupune că ABS funcționează pe baza unui sistem de operare care nu este acceptat de semnătura CIPF SKAD și, în consecință, funcționalitatea criptografică este transferată pe o mașină virtuală separată - integrarea „ABS-KBR”. modul.
Un token USB obișnuit care funcționează în modul cheie recuperabilă este utilizat ca purtător de chei. La conectarea cheii media la hypervisor, sa dovedit că nu existau porturi USB libere în sistem, așa că s-a decis să se conecteze token-ul USB printr-un hub USB de rețea și să se instaleze un client USB-over-IP pe virtualul mașină, care ar comunica cu hub-ul.
Atac
Atacatorii au interceptat cheia privată a semnăturii electronice de pe canalul de comunicare dintre hub-ul USB și hypervisor (datele au fost transmise în text clar). Având cheia privată, atacatorii au generat un ordin de plată fals, l-au semnat cu semnătură electronică și l-au trimis la locul de muncă automatizat KBR-N pentru execuție.
Scenariul 4. Un exemplu de implementare a amenințărilor U5.5.
Descrierea obiectului
Să luăm în considerare același circuit ca în scenariul anterior. Vom presupune că mesajele electronice care vin de la stația de lucru KBR-N ajung în folderul …SHAREIn, iar cele trimise către stația de lucru KBR-N și mai departe către sistemul de plată al Băncii Rusiei merg la …SHAREout.
De asemenea, vom presupune că la implementarea modulului de integrare, listele de certificate revocate sunt actualizate numai atunci când cheile criptografice sunt reemise și, de asemenea, că mesajele electronice primite în folderul …SHAREIn sunt verificate doar pentru controlul integrității și controlul încrederii în cheia publică a fișierului. semnatura electronica.
Atac
Atacatorii, folosind cheile furate în scenariul anterior, au semnat un ordin de plată fals care conținea informații despre primirea de bani în contul clientului fraudulos și l-au introdus în canalul securizat de schimb de date. Deoarece nu există nicio verificare că ordinul de plată a fost semnat de Banca Rusiei, acesta este acceptat pentru executare.
Sursa: www.habr.com