Linkuri către alte părți ale cercetării
- (Ești aici)
Acest articol finalizează seria de publicații dedicate asigurării securității informaționale pentru plățile bancare fără numerar. Aici vom analiza modelele standard de amenințări, la care s-a făcut referire în :
- .
- .
- .
- .
HABRO-WARNING !!! Dragi utilizatori Habra, acesta nu este un post de divertisment.
Materialele ascunse sub tag sunt menite să ajute în muncă sau studiu persoanelor specializate în domeniul bancar sau în asigurarea securității informaționale. Aceste materiale sunt produsul final al cercetării și sunt redactate într-un ton oficial și rece. Practic, acestea constituie schițe pentru documentele interne privind securitatea informațională.Și tradiționalul — „utilizarea informațiilor din articol în scopuri ilegale se pedepsește conform legii”. Lectură productivă!
Informații pentru cititorii care încep să se familiarizeze cu cercetarea din această publicație.
Despre ce este cercetarea
Citești un ghid pentru specialistul responsabil de asigurarea securității informaționale pentru plățile din bancă.
Logica expunerii
La început în și se oferă descrierea obiectului protecției. Apoi, în se vorbește despre cum să construiești un sistem de protecție și se discută despre necesitatea formării unui model de amenințare. În se discută despre ce modele de amenințare există și cum sunt formate acestea. În și se face o analiză a atacurilor reale. și conțin descrierea unui model de amenințare, construit ținând cont de informațiile din toate părțile anterioare.
MODEL TIPA DE AMENINȚARE. CONEXIUNE DE REȚEA
Obiectul de protecție pentru care se aplică modelul de amenințare (scope)
Obiectul de protecție sunt datele transmise printr-o conexiune de rețea, care funcționează în rețele de transmisie a datelor, construite pe baza stivei TCP/IP.
Arhitectură
Descrierea elementelor arhitecturii:
- „Noduri finale” — noduri care schimbă informații protejate.
- „Noduri intermediare” — elemente ale rețelei de transmisie a datelor: routere, comutatoare, servere de acces, servere proxy și alte echipamente, — prin care trece traficul conexiunii de rețea. În general, o conexiune de rețea poate funcționa fără noduri intermediare (direct între nodurile finale).
Amenințări de securitate de nivel înalt
Dezintegrare
U1. Acces neautorizat la datele transmise.
U2. Modificarea neautorizată a datelor transmise.
U3. Încălcarea dreptului de autor asupra datelor transmise.
U1. Acces neautorizat la datele transmise
Dezintegrare
U1.1. , efectuat la noduri finale sau intermediare:
U1.1.1. prin citirea datelor în timp ce se află în dispozitivele de memorie ale nodului:
U1.1.1.1. în memoria operațională.
Explicații pentru U1.1.1.1.
De exemplu, în timpul procesării datelor de către stiva de rețea a nodului.
U1.1.1.2. în memoria non-volatilă.
Explicații pentru U1.1.1.2.
De exemplu, atunci când datele transmise sunt stocate în cache, fișiere temporare sau fișiere de swap.
U1.2. , efectuat pe noduri externe ale rețelei de transmisie a datelor:
U1.2.1. prin capturarea tuturor pachetelor care ajung la interfața de rețea a nodului:
Explicații pentru U1.2.1.
Capturarea tuturor pachetelor se efectuează prin schimbarea modului plăcii de rețea în modul promiscu (modul promiscu pentru adaptoare cu fir sau în modul monitor pentru adaptoare Wi-Fi).
U1.2.2. prin efectuarea de atacuri de tip „omul din mijloc (MiTM)”, dar fără modificarea datelor transmise (cu excepția datelor de serviciu ale protocoalelor de rețea).
U1.2.2.1. Referință: .
U1.3. , realizat prin scurgerea de informații prin canalele tehnice (TKUI) de la noduri fizice sau linii de comunicare.
U1.4. , realizat prin instalarea pe noduri finale sau intermediare a unor echipamente tehnice speciale (ETS) pentru extragerea neoficială a informațiilor.
U2. Modificarea neautorizată a datelor transmise
Dezintegrare
U2.1. , realizată la noduri finale sau intermediare:
U2.1.1. prin citirea și modificarea datelor în timpul stocării lor în memoriile nodurilor:
U2.1.1.1. în memoria RAM:
U2.1.1.2. în memoria non-volatilă:
U2.2. , realizată la noduri externe ale rețelei de date:
U2.2.1. prin atacuri de tip „omul din mijloc (MiTM)” și redirecționarea traficului către nodul atacatorilor:
U2.2.1.1. Conectarea fizică a echipamentului atacatorilor în întreruperea conexiunii de rețea.
U2.2.1.2. Efectuarea de atacuri asupra protocoalelor de rețea:
U2.2.1.2.1. gestionarea 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 de rutare statică ale routerelor.
U2.2.1.2.2.2. Anunțarea de către atacatori a rutelor false prin protocoale de rutare dinamică.
U2.2.1.2.3. configurarea automată:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. adresarea și rezolvarea numelui:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Efectuarea de modificări neautorizate în fișierele locale de nume de gazde (hosts, lmhosts etc.)
U3. Încălcarea paternității datelor transmise
Dezintegrare
U3.1. Neutralizarea mecanismelor de identificare a paternității informației prin introducerea de date false despre autor sau sursa de informații:
U3.1.1. Modificarea informațiilor despre autor conținute în datele transmise.
U3.1.1.1. Neutralizarea protecției criptografice a integrității și paternității datelor transmise:
U3.1.1.1.1. Referință: .
U3.1.1.2. Neutralizarea protecției drepturilor de autor pentru datele transmise, realizată prin coduri de confirmare temporare:
U3.1.1.2.1. .
U3.1.2. Modificarea informațiilor despre sursa datelor transmise:
U3.1.2.1. .
U3.1.2.2. .
MODEL TIPIC DE AMENINȚARE. SISTEM INFORMATIV CONSTRUIT PE O ARHITECTURĂ CLIENT-SERVER
Obiectul de protecție pentru care se aplică modelul de amenințare (scope)
Obiectul protecției este un sistem informațional construit pe baza arhitecturii client-server.
Arhitectură
Descrierea elementelor arhitecturii:
- „Client” – dispozitivul pe care funcționează partea client a sistemului informațional.
- „Server” – dispozitivul pe care funcționează partea server a sistemului informațional.
- „Depozit de date” — parte a infrastructurii serverului sistemului informațional, destinată stocării datelor procesate de sistemul informațional.
- „Conexiune de rețea” — canalul de schimb de informații între Client și Server, care trece prin rețeaua de transmisie de date. O descriere mai detaliată a modelului elementului este prezentată în .
Limitări
În modelarea obiectului au fost stabilite următoarele restricții:
- Utilizatorul interacționează cu sistemul informațional în cadrul intervalelor de timp definitive, denumite sesiuni de lucru.
- La începutul fiecărei sesiuni de lucru se efectuează identificarea, autentificarea și autorizarea utilizatorului.
- Toate informațiile protejate sunt stocate pe partea server a sistemului informațional.
Amenințări de securitate de nivel înalt
Dezintegrare
U1. Comportamentul neautorizat al infractorilor în numele unui utilizator legitim.
U2. Modificarea neautorizată a informațiilor protejate în timpul procesării de către partea server a sistemului informațional.
U1. Comportamentul neautorizat al infractorilor în numele unui utilizator legitim
Explicații
De obicei, în sistemele informaționale, corelarea acțiunilor cu utilizatorul care le-a efectuat se face prin:
- jurnalele de activitate ale sistemului (logs).
- atribute speciale ale obiectelor de date, care conțin informații despre utilizatorul care le-a creat sau modificat.
În raport cu sesiunea de lucru, această amenințare poate fi descompusă în:
- efectuate în cadrul sesiunii de lucru a utilizatorului.
- efectuate în afara sesiunii de lucru a utilizatorului.
Sesiunea de lucru a utilizatorului poate fi inițiată:
- De către utilizatorul în sine.
- Atacatorilor.
În această etapă, descompunerea intermediară a acestei amenințări va arăta astfel:
U1.1. Acțiuni neautorizate desfășurate în sesiunea de lucru a utilizatorului:
U1.1.1. <…>, instalat de utilizatorul atacat.
U1.1.2. <…>, instalat de atacatori.
U1.2. Acțiuni neautorizate desfășurate în afara sesiunii de lucru a utilizatorului.
Din punct de vedere al obiectelor infrastructurii informaționale asupra cărora atacatorii pot exercita influență, descompunerea amenințărilor intermediare va arăta astfel:
Elementele
Descompunerea amenințărilor
U1.1.1.
U1.1.2.
U1.2.
Clientului
U1.1.1.1.
U1.1.2.1.
Conexiune de rețea
U1.1.1.2.
Server
U1.2.1.
Dezintegrare
U1.1. Acțiuni neautorizate desfășurate în sesiunea de lucru a utilizatorului:
U1.1.1. <…>, instalat de utilizatorul atacat:
U1.1.1.1. Atacatorii au acționat singuri din partea Clientului:
U1.1.1.1.1 Atacatorii au folosit instrumentele standard de acces la sistemul informațional:
U1.1.1.1.1.1. Atacatorii au folosit dispozitivele fizice de input-output ale Clientului (tastatură, mouse, monitor sau ecran tactil al dispozitivului mobil):
U1.1.1.1.1.1.1. Atacatorii au acționat în perioadele în care sesiunea era activă, dispozitivele de input-output erau disponibile și utilizatorul nu era prezent.
U1.1.1.1.1.2. Atacatorii au folosit instrumente de administrare la distanță (standard sau furnizate de codul malițios) pentru a controla Clientul:
U1.1.1.1.1.2.1. Atacatorii au acționat în perioadele în care sesiunea era activă, dispozitivele de input-output erau disponibile și utilizatorul nu era prezent.
U1.1.1.1.1.2.2. Atacatorii au folosit instrumente de administrare la distanță, a căror funcționare nu era perceptibilă pentru utilizatorul atacat.
U1.1.1.2. Atacatorii au înlocuit datele în conexiunea de rețea între Client și Server, modificându-le astfel încât să fie percepute ca fiind acțiuni ale unui utilizator legitim:
U1.1.1.2.1. Link: .
U1.1.1.3. Atacatorii au forțat utilizatorul să execute acțiunile indicate de ei, folosind metode de inginerie socială.
U1.1.2 <…> instalat de atacatori:
U1.1.2.1. Atacatorii au acționat din partea Clientului (Și):
U1.1.2.1.1. Atacatorii au neutralizat sistemul de delimitare a accesului la sistemul informațional:
U1.1.2.1.1.1. Link: .
U1.1.2.1.2. Atacatorii au folosit mijloace standard de acces la sistemul informațional
U1.1.2.2. Atacatorii au acționat de pe alte noduri ale rețelei de comunicații, de unde se poate stabili o conexiune de rețea cu Serverul (Și):
U1.1.2.2.1. Atacatorii au neutralizat sistemul de delimitare a accesului la sistemul informațional:
U1.1.2.2.1.1. Legătură: .
U1.1.2.2.2. Atacatorii au folosit mijloace neomologate de acces la sistemul informațional.
Explicații U1.1.2.2.2.
Atacatorii ar fi putut instala clientul standard al sistemului informațional pe un nod extern sau ar fi putut utiliza software neomologat care implementează protocoale standard de schimb între Client și Server.
U1.2 Acțiunile neautorizate au fost efectuate în afara sesiunii de lucru a utilizatorului.
U1.2.1 Atacatorii au efectuat acțiuni neautorizate și apoi au făcut modificări neautorizate în jurnalele activității sistemului informațional sau în atributele speciale ale obiectelor de date, indicând că acțiunile efectuate de ei au fost realizate de un utilizator legitim.
U2. Modificarea neautorizată a informațiilor protejate în timpul procesării de către partea server a sistemului informațional
Dezintegrare
U2.1. Atacatorii modifică informațiile protejate folosind mijloace standard ale sistemului informațional și efectuează această modificare în numele unui utilizator legitim.
U2.1.1. Legătură: .
U2.2. Atacatorii modifică informațiile protejate utilizând mecanismele de acces la date care nu sunt prevăzute de modul de funcționare standard al sistemului informațional.
U2.2.1. Atacatorii modifică fișierele care conțin informații protejate:
U2.2.1.1. , folosind mecanismele de lucru cu fișierele oferite de sistemul de operare.
U2.2.1.2. prin provocarea recuperării fișierelor dintr-o copie de rezervă modificată neautorizat.
U2.2.2. Atacatorii modifică informațiile protejate stocate în baza de date (Și):
U2.2.2.1. Atacatorii neutralizează sistemul de delimitare a accesului SGBD:
U2.2.2.1.1. Link: .
U2.2.2.2. Atacatorii modifică informațiile, folosind interfețele standard SGBD pentru accesarea datelor.
U2.3. Atacatorii modifică informațiile protejate prin modificări neautorizate ale algoritmilor software-ului care le procesează.
U2.3.1. Codul sursă al software-ului este subiectul modificărilor.
U2.3.1. Codul mașină al software-ului este subiectul modificărilor.
U2.4. Atacatorii modifică informațiile protejate prin exploatarea vulnerabilităților din software-ul sistemului informațional.
U2.5. Atacatorii modifică informațiile protejate în timpul transmiterii acestora între componentele părții server a sistemului informațional (de exemplu, între serverul de baze de date și serverul de aplicații):
U2.5.1. Link: .
MODEL TIPIC DE AMENINȚARE. SISTEM DE DELIMITARE A ACCESULUI
Obiectul de protecție pentru care se aplică modelul de amenințare (scope)
Obiectul de protecție pentru care se aplică acest model de amenințare corespunde obiectului de protecție al modelului de amenințare: „Model tipic de amenințare. Sistem informațional bazat pe arhitectură client-server”.
Prin sistemul de delimitare a accesului utilizatorilor în acest model de amenințare se înțelege componenta sistemului informațional care realizează funcțiile:
- Identificarea utilizatorilor.
- Autentificarea utilizatorilor.
- Autorizarea utilizatorilor.
- Înregistrarea acțiunilor utilizatorilor.
Amenințări de securitate de nivel înalt
Dezintegrare
U1. Stabilirea neautorizată a unei sesiuni de lucru în numele unui utilizator autorizat.
U2. Creșterea neautorizată a privilegiilor utilizatorului în sistemul informațional.
U1. Stabilirea neautorizată a unei sesiuni de lucru în numele unui utilizator autorizat
Explicații
Dezintegrarea acestei amenințări, în general, va depinde de tipul de sisteme folosite pentru identificarea și autentificarea utilizatorilor.
În acest model va fi examinată doar sistemul de identificare și autentificare a utilizatorilor care folosește un login și o parolă text. Vom considera că login-ul utilizatorului este o informație publică, cunoscută atacatorilor.
Dezintegrare
U1.1. prin compromiterea datelor de acces:
U1.1.1. Atacatorii au compromis datele de acces al utilizatorului în timpul stocării acestora.
Explicații U1.1.1.
De exemplu, datele de acces ar fi putut fi notate pe un post-it lipit de monitor.
U1.1.2. Utilizatorul a transmis accidental sau cu intenție malefică detalii de acces infractorilor.
U1.1.2.1. Utilizatorul a rostit datele de autentificare cu voce tare în timpul introducerii.
U1.1.2.2. Utilizatorul a transmis intenționat datele sale de autentificare:
U1.1.2.2.1. colegilor de muncă.
Explicații U1.1.2.2.1.
De exemplu, pentru ca aceștia să poată să le înlocuiască pe o perioadă de boală.
U1.1.2.2.2. contraentităților angajatorului, care îndeplinesc sarcini legate de infrastructura informațională.
U1.1.2.2.3. terților.
Explicații U1.1.2.2.3.
Una dintre variantele de realizare a acestei amenințări este utilizarea de către infractori a metodelor de inginerie socială.
U1.1.3. Infractorii au obținut datele de autentificare prin metoda de forțare:
U1.1.3.1. utilizând mecanismele standard de acces.
U1.1.3.2. folosind coduri interceptate anterior (de exemplu, hash-uri pentru parole) pentru stocarea datelor de autentificare.
U1.1.4. Infractorii au utilizat cod malițios pentru a intercepta datele de autentificare ale utilizatorului.
U1.1.5. Infractorii au extras datele de autentificare din conexiunea de rețea între Client și Server:
U1.1.5.1. Link: .
U1.1.6. Infractorii au extras datele de autentificare din înregistrările sistemelor de monitorizare a activității:
U1.1.6.1. sistemelor de videoconferință (în cazul în care, în timpul funcționării, s-au înregistrat apăsările de taste de pe tastatură).
U1.1.6.2. sistemelor de control al acțiunilor angajaților de la calculator
Explicații U1.1.6.2.
Un exemplu al unui astfel de sistem este— .
U1.1.7. Infractorii au compromis datele de autentificare ale utilizatorului din cauza defectelor în procesul de transmitere.
Explicații U1.1.7.
De exemplu, transmiterea parolelor în mod deschis prin e-mail.
U1.1.8. Infractorii au aflat datele de autentificare observând sesiunea de lucru a utilizatorului prin intermediul sistemelor de administrare la distanță.
U1.1.9. Infractorii au extras datele de autentificare ca urmare a scurgerilor prin canale tehnice (CTUI):
U1.1.9.1. Infractorii au observat cum utilizatorul introduce datele de autentificare de pe tastatură:
U1.1.9.1.1 Infractorii se aflau în imediata apropiere a utilizatorului și au văzut inserțiile de date de autentificare cu ochii lor.
Explicații U1.1.9.1.1
Cazuri de acest tip includ acțiunile colegilor de muncă sau situația în care tastatura utilizatorului este vizibilă pentru vizitatorii organizației.
U1.1.9.1.2 Infractorii au folosit echipamente tehnice suplimentare, precum un binocular sau un vehicul aerian fără pilot, și au observat introducerea datelor de autentificare prin fereastră.
U1.1.9.2. Infractorii au extras datele de autentificare din comunicațiile radio între tastatură și unitatea de sistem a computerului în cazul în care erau conectate printr-o interfață radio (de exemplu, Bluetooth).
U1.1.9.3. Infractorii au interceptat datele de autentificare prin scurgerea acestora prin canale de radiații electromagnetice secundare și induceri (PEMIN).
Explicații U1.1.9.3.
Exemple de atac și .
U1.1.9.4. Infractorul a interceptat introducerea datelor de autentificare de la tastatură folosind echipamente tehnice speciale (ETS) destinate captării necontrolate a informațiilor.
Explicații U1.1.9.4.
Exemple .
U1.1.9.5. Infractorii au interceptat introducerea datelor de autentificare de la tastatură prin
analiza semnalului Wi-Fi, modulată de procesul de apăsare a tastelor de către utilizator.
Explicații U1.1.9.5.
Exemplu .
U1.1.9.6. Infractorii au interceptat introducerea datelor de autentificare de la tastatură prin analiza sunetelor apăsării tastelor.
Explicații U1.1.9.6.
Exemplu .
U1.1.9.7. Infractorii au interceptat introducerea datelor de autentificare de la tastatura unui dispozitiv mobil prin analiza datelor accelerometrului.
Explicații U1.1.9.7.
Exemplu .
U1.1.10. , preîntâmpinat la Client.
Explicații U1.1.10.
De exemplu, utilizatorul ar fi putut salva în browser numele de utilizator și parola pentru accesul la un anumit site.
U1.1.11. Infractorii au compromis datele de autentificare din cauza deficiențelor procesului de revocare a accesului utilizatorilor.
Explicații U1.1.11.
De exemplu, după ce un utilizator a fost concediat, conturile sale au rămas neblocate.
U1.2. prin utilizarea vulnerabilităților din sistemul de control al accesului.
U2. Creșterea neautorizată a privilegiilor utilizatorului în sistemul informațional
Dezintegrare
U2.1 prin efectuarea de modificări neautorizate în datele care conțin informații despre privilegiile utilizatorului.
U2.2 prin utilizarea vulnerabilităților din sistemul de control al accesului.
U2.3. din cauza deficiențelor procesului de gestionare a accesului utilizatorilor.
Explicații U2.3.
Exemplul 1. Utilizatorului i s-a oferit un acces mai mare decât necesarul său pentru sarcina de serviciu.
Exemplul 2. După transferarea utilizatorului pe o altă funcție, drepturile de acces acordate anterior nu au fost revocate.
MODELUL TIPOLOGIC AL AMENINȚĂRILOR. MODUL DE INTEGRARE
Obiectul de protecție pentru care se aplică modelul de amenințare (scope)
Modul de integrare – un set de obiecte ale infrastructurii informaționale, destinat organizării schimbului de informații între sistemele informaționale.
Având în vedere că în rețelele corporative nu este întotdeauna posibil să se separe clar un sistem informațional de altul, modul de integrare poate fi văzut și ca un element de legătură între componentele din cadrul unui singur sistem informațional.
Arhitectură
Schema generalizată a modulului de integrare arată în felul următor:
Descrierea elementelor arhitecturii:
- „Serverul de schimb (SE)" – nod / serviciu / componentă a sistemului informațional, care îndeplinește funcția de schimb de date cu alt sistem informațional.
- „Mediator” – nod / serviciu, destinat organizării interacțiunii între sistemele informaționale, dar care nu face parte din acestea.
Exemple de „Mediatori” pot fi serviciile de email, bus-urile de servicii ale întreprinderii (enterprise service bus / arhitectura SoA), servere de fișiere externe etc. În general, modul de integrare poate să nu conțină „Mediatori”. - „SO de procesare a datelor” – un ansamblu de programe care implementează protocoale de schimb de date și conversia formatelor.
De exemplu, conversia datelor din formatul UFEBS în formatul ABS, schimbarea statutelor mesajelor în procesul de transmitere etc. - „Conexiune de rețea” corespunde obiectului descris în modelul tipologic al amenințărilor „Conexiune de rețea”. Unele conexiuni de rețea din cele prezentate în schema de mai sus pot să nu existe.
Exemple de module de integrare
Schema 1. Integrarea ABS și ARM KBR prin intermediul unui server de fișiere extern
Pentru executarea plăților, un angajat autorizat al băncii descarcă din ABS documentele electronice de plată și le salvează într-un fișier (într-un format propriu, de exemplu, un dump SQL) pe un folder de rețea (…SHARE) al serverului de fișiere. Apoi, acest fișier este convertit cu ajutorul unui script de conversie într-un set de fișiere în format UFEBS, care sunt apoi citite de ARM KBR.
După aceasta, lucrătorul autorizat — utilizatorul ARM KBR — criptează și semnează fișierul primit și îl trimite în sistemul de plăți al Băncii Rusiei.
La primirea plăților din partea Băncii Rusiei, ARM KBR efectuează decriptarea acestora și verificarea semnăturii electronice, după care le înregistrează sub formă de set de fișiere în format UFEBS pe serverul de fișiere. Înainte de importul documentelor de plată în ABS, acestea sunt convertite cu ajutorul unui script-convertor din formatul UFEBS în formatul ABS.
Să considerăm că în acest sistem ABS funcționează pe un singur server fizic, ARM KBR funcționează pe un computer dedicat, iar scriptul-convertor rulează pe serverul de fișiere.
Correspondența obiectelor din schema analizată cu elementele modelului modulului de integrare:
«Serverele de schimb de la ABS» – serverul ABS.
«Serverele de schimb de la ARM KBR» – computerul ARM KBR.
„Mediator” – serverul de fișiere extern.
„SO de procesare a datelor” – scriptul-convertor.
Schema 2. Integrarea ABS și ARM KBR prin plasarea unei foldere rețea comune cu plățile pe ARM KBR
Toate sunt similare cu Schema 1, dar nu se utilizează un server de fișiere separat, în schimb, o folder rețea (…SHARE) cu documentele de plată electronice este plăsuită pe computerul cu ARM KBR. Scriptul-convertor funcționează de asemenea pe ARM KBR.
Correspondența obiectelor din schema analizată cu elementele modelului modulului de integrare:
Similar cu Schema 1, dar „Mediator” nu se utilizează.
Schema 3. Integrarea ABS și ARM KBR-N prin IBM WebSphere MQ și realizarea semnăturii documentelor electronice „pe partea ABS”
ABS funcționează pe o platformă care nu este suportată de SKZI SKAD Semnătură. Semnătura documentelor electronice ieșite se face pe un server special de semnătură electronică (Server EP). Acest server verifică de asemenea semnătura electronică a documentelor primite de la Banca Rusiei.
ABS descarcă pe Server EP un fișier cu documentele de plată în propriul său format.
Serverul EP, cu ajutorul scriptului-convertor, convertește fișierul în mesaje electronice în format UFEBS, după care aceste mesaje electronice sunt semnate și transmise pe IBM WebSphere MQ.
ARM KBR-N se conectează la IBM WebSphere MQ și primește mesajele de plată semnate, după care lucrătorul autorizat — utilizatorul ARM KBR — le criptează și le trimite în sistemul de plăți al Băncii Rusiei.
La primirea plăților din partea Băncii Rusiei, ARM KBR decodează și verifică semnătura electronică. Plățile procesate cu succes, sub formă de mesaje electronice decode și semnate în format UFEBS, sunt transmise în IBM WebSphere MQ, de unde sunt primite de Serverul EP.
Serverul EP verifică semnătura electronică a plăților primite și le salvează într-un fișier în format ABS. Apoi, un angajat autorizat — utilizator al ABS — încarcă fișierul rezultat în ABS conform procedurii stabilite.
Correspondența obiectelor din schema analizată cu elementele modelului modulului de integrare:
„Serverul de schimb de date din partea ABS” – serverul ABS.
„Serverul de schimb de date din partea ARM KBR” — computer ARM KBR.
„Mediator” – Server EP și IBM WebSphere MQ.
„SO de procesare a datelor” – script de conversie, SKZI SKAD Semnătura pe Serverul EP.
Schema 4. Integrarea Serverului DBO și ABS prin API-ul furnizat de serverul dedicat de schimb de date
Să presupunem că în bancă sunt utilizate mai multe sisteme de servicii bancare la distanță (DBO):
- „Internet Client-Bank” pentru persoane fizice (IKB FL);
- „Internet Client-Bank” pentru persoane juridice (IKB JL).
În scopul asigurării securității informațiilor, toată comunicarea ABS cu sistemele DBO se realizează prin intermediul unui server dedicat de schimb de date, care funcționează în cadrul sistemului de informații „ABS”.
În continuare, vom examina procesul de interacțiune între sistemul DBO IKB JL și ABS.
Serverul DBO, primind de la client un ordin de plată corespunzător, trebuie să creeze pe baza acestuia documentul corespunzător în ABS. Pentru aceasta, el transmite informația la serverul de schimb de date folosind API, iar acesta, la rândul său, introduce datele în ABS.
Atunci când soldurile contului clientului se modifică, ABS generează notificări electronice, care sunt transmise pe serverul DBO prin intermediul serverului de schimb de date.
Correspondența obiectelor din schema analizată cu elementele modelului modulului de integrare:
„Serverul de schimb de date din partea DBO” – serverul DBO IKB JL.
„Serverul de schimb de date din partea ABS” – serverul de schimb de date.
„Mediator” – absența.
„SO de procesare a datelor” – componentele Serverului DBO, responsabile pentru utilizarea API-ului serverului de schimb de date, componentele serverului de schimb de date, responsabile pentru utilizarea API-ului ABS.
Amenințări de securitate de nivel înalt
Dezintegrare
U1. Introducerea de informații false de către atacatori prin intermediul modulului de integrare.
U1. Introducerea de informații false de către atacatori prin intermediul modulului de integrare
Dezintegrare
U1.1. Modificarea neautorizată a datelor legitime în timpul transmiterii acestora prin conexiuni de rețea:
U1.1.1 Link: .
U1.2. Transmiterea de date false în numele unui participant legitim la schimb:
U1.1.2 Link: .
U1.3. Modificarea neautorizată a datelor legitime în timpul procesării acestora pe Serverele de schimb sau Intermediar:
U1.3.1. Link: .
U1.4. Crearea de date false pe Serverele de schimb sau Intermediar în numele unui participant legitim la schimb:
U1.4.1. Link:
U1.5. Modificarea neautorizată a datelor în timpul procesării acestora cu ajutorul software-ului de procesare a datelor:
U1.5.1. prin efectuarea de către atacatori a modificărilor neautorizate în setările (configurația) software-ului de procesare a datelor.
U1.5.2. prin efectuarea de către atacatori a modificărilor neautorizate în fișierele executabile ale software-ului de procesare a datelor.
U1.5.3. prin controlul interactiv de către atacatori al activității software-ului de procesare a datelor.
MODELUL TIPIC DE AMENINȚE. SISTEMUL DE PROTECȚIE CRIPTOGRAFICĂ A INFORMAȚIEI
Obiectul de protecție pentru care se aplică modelul de amenințare (scope)
Obiectul protecției este sistemul de protecție criptografică a informației, utilizat pentru a asigura securitatea sistemului informațional.
Arhitectură
Baza oricărui sistem informațional este software-ul aplicațiilor (SO), care realizează funcționalitatea sa țintă.
Protecția criptografică este de obicei realizată prin apelarea din logica de afaceri a software-ului aplicațiilor a primitivelor criptografice, care sunt plasate în biblioteci specializate - nuclee criptografice.
Primitivelor criptografice includ funcții criptografice de nivel inferior, cum ar fi:
- criptarea / decriptarea unui bloc de date;
- crearea / verificarea unei semnături electronice a unui bloc de date;
- calcularea funcției hash a unui bloc de date;
- formarea / încărcarea / descărcarea informațiilor cheie;
- etc.
Logica de afaceri a software-ului aplicațiilor realizează cu ajutorul primitivelor criptografice funcționalități de nivel superior:
- criptarea unui fișier cu cheile destinatariilor aleși;
- stabilirea unei conexiuni de rețea securizate;
- informarea cu privire la rezultatele verificării semnăturii electronice;
- etc.
Interacțiunea dintre logica de afaceri și nucleul criptografic poate fi realizată:
- direct, prin apelarea de către logica de afaceri a primitivelor criptografice din bibliotecile dinamice ale nucleului criptografic (.DLL – pentru Windows, .SO – pentru Linux);
- indirect, prin intermediul interfețelor criptografice – wrapperi, cum ar fi MS Crypto API, Java Cryptography Architecture, PKCS#11 etc. În acest caz, logica de afaceri se adresează interfeței criptografice, care apoi transpune apelul la nucleul criptografic corespunzător, care în acest caz se numește furnizor de criptografie. Utilizarea interfețelor criptografice permite aplicațiilor să se abstreze de algoritmii criptografici specifici și să fie mai flexibile.
Se pot distinge două scheme tipice de organizare a nucleului criptografic:
Schema 1 – Nucleu criptografic monolitic
Schema 2 – Nucleu criptografic împărțit
Elementele din schemele prezentate pot fi module software separate, funcționând pe un singur computer, sau servicii de rețea care interacționează în cadrul unei rețele de calcul.
În utilizarea sistemelor construite conform schemei 1, aplicațiile software și nucleul criptografic funcționează în cadrul unui mediu comun de funcționare a instrumentului criptografic (SFC), de exemplu, pe același computer, sub gestionarea aceluiași sistem de operare. Utilizatorul sistemului poate, în general, să ruleze în cadrul acestui mediu comun și alte programe, inclusiv cele care conțin cod malițios. În astfel de condiții, există un risc semnificativ de scurgere a cheilor criptografice secrete.
Pentru a minimiza riscul, se utilizează schema 2, în cadrul căreia nucleul criptografic este împărțit în două părți:
- Prima parte funcționează împreună cu aplicația software într-un mediu de neîncredere, unde există riscul de infectare cu cod malițios. Vom numi această parte – „partea software”.
- A doua parte funcționează într-un mediu de încredere pe un dispozitiv dedicat, care conține un stocare a cheilor secrete. Vom numi această parte – „partea hardware”.
Divizarea nucleului cryptografic în părți software și hardware este destul de relativă. Pe piață există sisteme construite pe o schemă cu nucleu cryptografic divizat, dar partea „hardware” este reprezentată sub formă de imagine a unei mașini virtuale — virtual HSM ().
Interacțiunea dintre cele două părți ale nucleului cryptografic se realizează în așa fel încât cheile criptografice private nu sunt niciodată transferate în partea software și, prin urmare, nu pot fi furate prin cod malițios.
Interfața de interacțiune (API) și setul de primitive criptografice furnizate aplicațiilor software de nucleul cryptografic sunt identice în ambele cazuri. Diferența constă în modul în care sunt implementate.
Astfel, atunci când se utilizează schema cu nucleu cryptografic divizat, interacțiunea dintre partea software și partea hardware se realizează după următorul principiu:
- Primitivele criptografice care nu necesită utilizarea cheii private (de exemplu, calcularea funcției hash, verificarea semnăturii electronice etc.) sunt executate de partea software.
- Primitivele criptografice care utilizează cheia privată (crearea semnăturii electronice, decriptarea datelor etc.) sunt executate de partea hardware.
Să ilustreze funcționarea nucleului cryptografic divizat prin exemplul creării unei semnături electronice:
- Partea software calculează funcția hash a datelor ce trebuie semnate și transmite această valoare părții hardware prin intermediul canalului de schimb între nucleele cryptografice.
- Partea hardware, folosind cheia privată și hash-ul, generează valoarea semnăturii electronice și o transmite înapoi părții software prin canalul de schimb.
- Partea software returnează valoarea obținută aplicației software.
Particularitățile verificării corectitudinii semnăturii electronice
Când partea primitoare primește date semnate cu semnătura electronică, aceasta trebuie să efectueze mai multe etape de verificare. Un rezultat pozitiv al verificării semnăturii electronice este obținut numai după ce toate etapele de verificare sunt completate cu succes.
Etapa 1. Controlul integrității datelor și al autorității datelor.
Conținutul etapei. Se efectuează verificarea semnăturii electronice a datelor conform algoritmului criptografic corespunzător. Trecerea cu succes a acestei etape indică faptul că datele nu au fost modificate de la momentul semnării, precum și că semnătura a fost realizată cu cheia privată corespunzătoare cheii publice de verificare a semnăturii electronice.
Locul realizării etapei: nucleul criptografic.
Etapa 2. Controlul încrederii în cheia publică a semnatarului și controlul valabilității cheii private a semnăturii electronice.
Conținutul etapei. Etapa constă în două subetape intermediare. În prima se stabilește dacă cheia publică de verificare a semnăturii electronice a fost de încredere la momentul semnării datelor. În a doua se verifică dacă cheia privată a semnăturii electronice a fost valabilă la momentul semnării datelor. În general, termenul de valabilitate al acestor chei poate să nu coincidă (de exemplu, pentru certificatele calificate ale cheilor de verificare a semnăturilor electronice). Modalitățile de stabilire a încrederii în cheia publică a semnatarului sunt reglementate de regulile de schimb electronic de documente adoptate de părțile implicate.
Locul realizării etapei: software aplicativ / nucleu criptografic.
Etapa 3. Controlul atribuțiilor semnatarului.
Conținutul etapei. Conform regulilor stabilite pentru schimbul electronic de documente, se verifică dacă semnatarul avea dreptul de a certifica datele protejate. De exemplu, să presupunem o situație de încălcare a atribuțiilor. Există o organizație unde toți angajații au semnături electronice. În sistemul intern de schimb electronic de documente, ajunge o dispoziție a conducerii, dar semnată cu semnătura electronică a responsabilului de depozit. Prin urmare, un astfel de document nu poate fi considerat legitim.
Locul realizării etapei: software aplicativ.
Presupozițiile adoptate la descrierea obiectului de protecție
- Canalele de transmitere a informațiilor, cu excepția canalelor de schimb de chei, trec, de asemenea, prin software aplicativ, API și nucleul criptografic.
- Informațiile despre încrederea în cheile publice și (sau) certificate, precum și informațiile despre atribuțiile posesorilor cheilor publice, sunt stocate în depozitul cheilor publice.
- Software-ul aplicativ lucrează cu depozitul cheilor publice prin nucleul criptografic.
Exemplu de sistem informațional protejat prin SKeyZ
Pentru a ilustra schemele prezentate anterior, să luăm în considerare un sistem informațional ipotetic și să evidențiem toate elementele structurale ale acestuia.
Descrierea sistemului informațional
Două organizații au decis să implementeze un flux electronic de documente (FED) juridic între ele. În acest scop, au încheiat un acord prin care au stipulat că documentele vor fi transmise prin e-mail, și că acestea trebuie să fie criptate și semnate cu o semnătură electronică calificată. Ca mijloace de creare și procesare a documentelor, trebuie să se utilizeze programele de birou din pachetul Microsoft Office 2016, iar ca mijloace de protecție criptografică — SKZI KriptoPRO și software-ul de criptare KriptoARM.
Descrierea infrastructurii organizației 1
Organizația 1 a decis că va instala SKZI KriptoPRO și software-ul KriptoARM pe stația de lucru a utilizatorului — un computer fizic. Cheile de criptare și semnăturile electronice vor fi stocate pe un suport de cheie ruToken, care funcționează în modul de cheie removabilă. Utilizatorul va pregăti documentele electronice local pe computerul său, după care le va cripta, semna și trimite prin intermediul clientului de e-mail instalat local.
Descrierea infrastructurii organizației 2
Organizația 2 a decis să exteriorizeze funcțiile de criptare și semnare electronică pe o mașină virtuală dedicată. Toate operațiile criptografice vor fi efectuate în mod automat.
Pentru aceasta, pe mașina virtuală dedicată au fost organizate două foldere de rețea: „…In”, „…Out”. În folderul de rețea „…In” vor fi plasate automat fișierele primite de la partener în formă deschisă. Aceste fișiere vor fi decriptate și va fi verificată semnătura electronică.
În folderul „…Out” utilizatorul va plasa fișierele care trebuie criptate, semnate și trimise partenerului. Fișierele în sine vor fi pregătite de utilizator pe stația sa de lucru.
Pentru a îndeplini funcțiile de criptare și semnare electronică, pe mașina virtuală sunt instalate SKZI KriptoPRO, software-ul KriptoARM și clientul de e-mail. Controlul automat al tuturor elementelor mașinii virtuale va fi efectuat prin intermediul scripturilor dezvoltate de administratorii de sistem. Funcționarea scripturilor este înregistrată în fișierele jurnal (logs).
Cheile criptografice ale semnăturii electronice vor fi stocate pe un token cu cheie neextrabilă JaCarta GOST, care va fi conectat la calculatorul local al utilizatorului.
Tokenul va fi redirecționat către mașina virtuală prin intermediul unor instrumente software specializate USB-over-IP, instalate atât pe statia de lucru a utilizatorului, cât și pe mașina virtuală.
Ceasurile de sistem de pe statia de lucru a utilizatorului din organizația 1 vor fi corectate manual. Ceasurile de sistem ale mașinii virtuale din organizația 2 vor fi sincronizate cu ceasurile de sistem ale hypervisor-ului, care, la rândul lor, vor fi sincronizate prin Internet cu servere publice de timp.
Identificarea elementelor structurale ale Securității Informației Criptografice (SKZI)
Pe baza descrierii anterioare a infrastructurii IT, vom identifica elementele structurale ale SKZI și le vom înregistra într-un tabel.
Tabel - Corelarea elementelor modelului SKZI cu elementele sistemelor informaționale
Denumirea elementului
Organizația 1
Organizația 2
Software aplicativ
Software CryptoARM
Software CryptoARM
Partea software a nucleului criptografic
SKZI CryptoPRO CSP
SKZI CryptoPRO CSP
Partea hardware a nucleului criptografic
). În SUSE/openSUSE, vulnerabilitatea nu se manifestă din cauza utilizării ramurii Exim 4.88.
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Depozitul de chei publice
Statia de lucru a utilizatorului:
— hard disk;
— depozit standard de certificate Windows.
Hypervisor:
— hard disk.
Mașina virtuală:
— hard disk;
— depozit standard de certificate Windows.
Depozitul de chei private
Dispozitivul de stocare ruToken, funcționând în modul de extragere a cheii
Dispozitivul de stocare JaCarta GOST, funcționând în modul de cheie neextrabilă
Canalul de schimb al cheilor publice
Statia de lucru a utilizatorului:
— memorie RAM.
Hypervisor:
— memorie RAM.
Mașina virtuală:
— memorie RAM.
Canalul de schimb al cheilor private
Statia de lucru a utilizatorului:
— magistrala USB;
— memorie RAM.
). În SUSE/openSUSE, vulnerabilitatea nu se manifestă din cauza utilizării ramurii Exim 4.88.
Canalul de schimb între nucleele criptografice
lipsă (fără parte hardware a nucleului criptografic)
Statia de lucru a utilizatorului:
— magistrala USB;
— memorie RAM;
— modul software USB-over-IP;
— interfață de rețea.
Rețeaua corporativă a organizației 2.
Hypervisor:
— memorie RAM;
— interfață de rețea.
Mașina virtuală:
— interfață de rețea;
— memorie RAM;
— modul software USB-over-IP.
Canalul de schimb al datelor publice
Statia de lucru a utilizatorului:
— dispozitive de intrare-ieșire;
— memorie RAM;
— hard disk.
Statia de lucru a utilizatorului:
— dispozitive de intrare-ieșire;
— memorie RAM;
— hard disk;
— interfață de rețea.
Rețeaua corporativă a organizației 2.
Hypervisor:
— interfață de rețea;
— memorie RAM;
— hard disk.
Mașina virtuală:
— interfață de rețea;
— memorie RAM;
— hard disk.
Canalul de schimb al datelor protejate
Internet.
Rețeaua corporativă a organizației 1.
Statia de lucru a utilizatorului:
— hard disk;
— memorie RAM;
— interfață de rețea.
Internet.
Rețeaua corporativă a organizației 2.
Hypervisor:
— interfață de rețea;
— memorie RAM;
— hard disk.
Mașina virtuală:
— interfață de rețea;
— memorie RAM;
— hard disk.
Canalul de transmisie a timpului
Statia de lucru a utilizatorului:
— dispozitive de intrare-ieșire;
— memorie RAM;
— timer de sistem.
Internet.
Rețeaua corporativă a organizației 2,
Hypervisor:
— interfață de rețea;
— memorie RAM;
— timer de sistem.
Mașina virtuală:
— memorie RAM;
— timer de sistem.
Canalul de transmisie a comenzilor de control
Statia de lucru a utilizatorului:
— dispozitive de intrare-ieșire;
— memorie RAM.
(Interfața grafică a software-ului CryptoARM)
Mașina virtuală:
— memorie RAM;
— hard disk.
(Scripte de automatizare)
Canalul de primire a rezultatelor execuției
Statia de lucru a utilizatorului:
— dispozitive de intrare-ieșire;
— memorie RAM.
(Interfața grafică a software-ului CryptoARM)
Mașina virtuală:
— memorie RAM;
— hard disk.
(Fișiere de jurnal pentru execuția scriptelor de automatizare)
Amenințări de securitate de nivel înalt
Explicații
Presupozițiile acceptate la decompunerea amenințărilor:
- Se utilizează algoritmi criptografici rezistenți.
- Algoritmii criptografici sunt utilizați în mod sigur în modurile corecte de funcționare (de exemplu, nu se aplică pentru criptarea unor volume mari de date, se ia în considerare sarcina permisibilă pe cheie etc.).
- Atacatorii cunosc toți algoritmii, protocoalele și cheile publice utilizate.
- Toate datele criptate sunt accesibile atacatorilor pentru citire.
- Atacatorii pot reproduce orice elemente software în sistem.
Dezintegrare
U1. Compromiterea cheilor criptografice private.
U2. Criptarea datelor falsificate în numele unui expeditor legitim.
U3. Decriptarea datelor criptate de către persoane care nu sunt destinatari legitimi (atacatori).
U4. Crearea unei semnături electronice a semnatarului legitim pentru date falsificate.
U5. Obținerea unui rezultat pozitiv în verificarea semnăturii electronice pentru date falsificate.
U6. Acceptarea eronată a documentelor electronice pentru execuție din cauza problemelor din organizarea circulației documentelor electronice.
U7. Acces neautorizat la datele protejate în timpul procesării acestora de către SKZI.
U1. Compromiterea cheilor criptografice private
U1.1. Obținerea cheii private din depozitul cheilor private.
U1.2. Obținerea cheii private din obiectele mediului de funcționare a criptosistemului, în care aceasta poate fi temporar.
Explicații U1.2.
Obiectele în care cheia privată poate fi stocată temporar includ:
- memoria RAM,
- fișiere temporare,
- fișiere de swap,
- fișiere de hibernare,
- fișierele instantaneelor stării „caldă” a mașinilor virtuale, inclusiv fișierele conținutului memoriei RAM a mașinilor virtuale suspendate.
U1.2.1. Extracția cheilor private din memoria RAM activă prin înghețarea modulelor RAM, extragerea acestora și citirea ulterioară a datelor (atac prin înghețare).
Explicații U1.2.1.
Exemplu .
U1.3. Obținerea cheii private din canalul de schimb al cheilor private.
Explicații U1.3.
Un exemplu de implementare a acestei amenințări va fi oferit .
U1.4. Modificarea neautorizată a nucleului criptografic, prin care cheile private devin cunoscute atacatorilor.
U1.5. Compromiterea cheii private ca urmare a utilizării canalelor tehnice de scurgere a informațiilor (CTSI).
Explicații U1.5.
Exemplu .
U1.6. Compromiterea cheii private ca urmare a utilizării unor echipamente tehnice speciale (ETS) destinate pentru obținerea clandestină a informațiilor («buguri»).
U1.7. Compromiterea cheilor private în timpul stocării acestora în afara SKZI.
Explicații U1.7.
De exemplu, utilizatorul își păstrează suporturile cheie într-un sertar de birou, din care pot fi ușor extrase de către infractori.
U2. Criptarea datelor false în numele unui expeditor legitim.
Explicații
Această amenințare este luată în considerare doar pentru schemele de criptare a datelor cu autentificarea expeditorului. Exemple de astfel de scheme sunt menționate în recomandările de standardizare. . Pentru restul schemelor criptografice, această amenințare nu există, deoarece criptarea se efectuează pe baza cheilor publice ale destinatarului, care, în general, sunt cunoscute de infractori.
Dezintegrare
U2.1. Compromiterea cheii private a expeditorului:
U2.1.1. Legătură: .
U2.2. Înlocuirea datelor de intrare în canalul de schimb de date publice.
Note U2.2.
Exemple de implementare a acestei amenințări sunt prezentate mai jos. și .
U3. Descrifrare a datelor criptate de către persoane care nu sunt destinatari legitimi ai datelor (infractori).
Dezintegrare
U3.1. Compromiterea cheilor private ale destinatarului datelor criptate.
U3.1.1 Referință: .
U3.2. Înlocuirea datelor criptate în canalul de schimb al datelor protejate.
U4. Crearea unei semnături electronice de către un semnatar legitim pentru date false.
Dezintegrare
U4.1. Compromiterea cheilor private ale semnatarului electronic legitim.
U4.1.1 Referință: .
U4.2. Înlocuirea datelor semnate în canalul de schimb de date publice.
Notă U4.2.
Exemple de implementare a acestei amenințări sunt prezentate mai jos. și .
U5. Obținerea unui rezultat pozitiv al verificării semnăturii electronice pentru date false.
Dezintegrare
U5.1. Atacatorii interceptă în canalul de transmitere a rezultatelor un mesaj despre un rezultat negativ al verificării semnăturii electronice și îl substituie cu un mesaj cu un rezultat pozitiv.
U5.2. Atacatorii efectuează un atac asupra încrederii în certificatele de semnătură (SCENARIU — toate elementele sunt obligatorii):
U5.2.1. Atacatorii generează o cheie publică și una privată pentru semnătura electronică. Dacă în sistem sunt utilizate certificate de chei de semnătură electronică, ei generează un certificat de semnătură electronică cât mai asemănător posibil cu certificatul presupusului expeditor de date, al cărui mesaj doresc să-l falsifice.
U5.2.2. Atacatorii introduc modificări neautorizate în depozitul de chei publice, conferindu-le cheii publice generate de ei un nivel necesar de încredere și autoritate.
U5.2.3. Atacatorii semnează datele false cu cheia de semnătură electronică generată anterior și le integrează în canalul de schimb de date protejate.
U5.3. Atacatorii efectuează un atac folosind chei de semnătură electronică expirate ale unui semnatar legal (SCENARIU — toate elementele sunt obligatorii):
U5.3.1. Atacatorii compromit cheile private expirate (care nu sunt active în prezent) ale expeditorului legitim.
U5.3.2. Atacatorii substituie timpul în canalul de transmitere a timpului cu un moment în care cheile compromise erau încă active.
U5.3.3. Atacatorii semnează datele false cu cheia de semnătură electronică compromisă anterior și le integrează în canalul de schimb de date protejate.
U5.4. Atacatorii efectuează un atac folosind chei de semnătură electronică compromise ale unui semnatar legal (SCENARIU — toate elementele sunt obligatorii):
U5.4.1. Atacatorii fac o copie a depozitului de chei publice.
U5.4.2. Atacatorii compromit cheile private ale unuia dintre expeditorii legali. Acesta observă compromiterea, revocând cheile, iar informațiile despre revocarea cheii sunt plasate în depozitul de chei publice.
U5.4.3. Atacatorii înlocuiesc depozitul de chei publice cu cel anterior copiat.
U5.4.4. Atacatorii semnează datele false cu cheia de semnătură electronică compromisă anterior și le integrează în canalul de schimb de date protejate.
U5.5. din cauza erorilor în implementarea etapei 2 și 3 a verificării semnăturii electronice:
Explicații U5.5.
Un exemplu de implementare a acestei amenințări este prezentat .
U5.5.1. Verificarea încrederii în certificatul cheii de semnătură electronică doar pe baza încrederii în certificatul cu care a fost semnat, fără verificări CRL sau OCSP.
Explicații U5.5.1.
Exemplu de implementare .
U5.5.2. Atunci când se construiește lanțul de încredere pentru certificat, nu se analizează autoritatea certificatelor emise
Explicații U5.5.2.
Exemplu de atac în legătură cu certificatul SSL/TLS.
Atacatorii au cumpărat un certificat legitim pentru e-mailul lor. Apoi, au creat un certificat fraudulos pentru un site și l-au semnat cu certificatul lor. Dacă nu se va efectua verificarea autorității, atunci verificarea lanțului de încredere va fi corectă, iar, prin urmare, certificatul fraudulos va fi de asemenea corect.
U5.5.3. Atunci când se construiește lanțul de încredere pentru certificat, nu se verifică certificatele intermediare pentru revocare.
U5.5.4. Actualizarea CRL se realizează mai rar decât emiterea lor de către centrul de acreditare.
U5.5.5. Decizia de încredere în semnătura electronică este luată înainte de a primi răspunsul OCSP referitor la statutul certificatului, trimis în urma unei cereri făcute după momentul generării semnăturii sau înainte de a primi 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 aproape CRL, care conține informații despre revocarea certificatului.
U5.5.6. La primirea datelor semnate, nu se verifică apartenența certificatului la expeditor.
Explicații U5.5.6.
Exemplu de atac. În cazul certificatelor SSL: se poate să nu fie verificată conformitatea adresei serverului apelat cu valoarea câmpului CN din certificat.
Exemplu de atac. Atacatorii au compromis cheile semnăturii electronice ale unui participant din sistemul de plată. Apoi au spart rețeaua unui alt participant și, în numele acestuia, au trimis la serverul de calcul al sistemului de plată documente de plată semnate cu cheile compromise. Dacă serverul analizează doar încrederea și nu verifică conformitatea, documentele frauduloase vor fi considerate legitime.
U6. Acceptarea eronată a documentelor electronice pentru execuție din cauza problemelor din organizarea circulației documentelor electronice.
Dezintegrare
U6.1. Partea primitoare nu detectează duplicarea documentelor primite.
Explicații U6.1.
Exemplu de atac. Atacatorii pot intercepta documentul trimis destinatarului, chiar și cel criptografic protejat, și apoi să-l trimită de mai multe ori în canalul de transmitere a datelor protejate. Dacă destinatarul nu identifică duplicatele, toate documentele primite vor fi tratate și procesate ca fiind documente diferite.
U7. Acces neautorizat la datele protejate în timpul procesării SКZI
Dezintegrare
U7.1. ca urmare a scurgerii de informații prin canale externe (atac prin canal secundar).
Explicații U7.1.
Exemplu .
U7.2. din cauza neutralizării protecției împotriva accesului neautorizat la informațiile procesate pe SКZI:
U7.2.1. Utilizarea SКZI cu încălcarea cerințelor descrise în documentația SКZI.
U7.2.2. , realizată datorită existenței vulnerabilităților în:
U7.2.2.1. mijloacele de protecție împotriva accesului neautorizat.
U7.2.2.2. SКZI însăși.
U7.2.2.3. mediu de funcționare a instrumentului criptografic.
Exemple de atacuri
Scenariile discutate mai jos conțin în mod intenționat erori de organizare a securității informației și servesc doar ca ilustrație a posibilelor atacuri.
Scenariul 1. Exemplu de implementare a amenințărilor U2.2 și U4.2.
Descrierea obiectului
SOFTWARE AРМ KBR și SКZI SKAD Semnătura este instalată pe un computer fizic, neconectat la rețeaua de calculatoare. Ca suport cheie este utilizat FKN vdToken în modul de operare cu cheie neretractabilă.
Reguli referitoare la efectuarea calculului presupun că specialistul de calcul descărcă mesaje electronice în format deschis (schema vechiului AРМ KBR) de pe un server de fișiere protejat special, apoi le scrie pe un mediu de stocare transferabil USB flash și le transferă pe AРМ KBR, unde acestea sunt criptate și semnate. După aceasta, specialistul transferă pe un mediu de stocare transferabil mesajele electronice protejate, iar apoi prin intermediul computerului său de lucru le încarcă pe serverul de fișiere, de unde ajung la UTA și mai departe în sistemul de plăți al Băncii Rusiei.
În acest caz, canalele de schimb de date deschise și protejate vor include: server de fișiere, computerul de lucru al specialistului și mediu de stocare transferabil.
Atac
Infractorii instalează neautorizat un sistem de control la distanță pe computerul de lucru al specialistului și, în momentul înregistrării pe suportul de stocare al ordinelor de plată (mesaje electronice), înlocuiesc conținutul unuia dintre ele într-o formă deschisă. Specialistul transferă ordinele de plată pe ARM KBR, le semnează și le criptează fără a observa înlocuirea (de exemplu, din cauza numărului mare de ordine de plată în curs de procesare, oboselii etc.). Ulterior, ordinul de plată falsificat, trecând prin lanțul tehnologic, ajunge în sistemul de plăți al Băncii Rusiei.
Scenariul 2. Exemplu de implementare a amenințărilor U2.2 și U4.2.
Descrierea obiectului
Computerul cu ARM KBR, SCAD Semnătură și un suport de cheie FKN vdToken conectat funcționează într-o cameră dedicată, fără acces din partea personalului.
Specialistul în plăți se conectează la ARM KBR în modul de acces la distanță prin protocolul RDP.
Atac
Infractorii interceptă datele necesare, utilizându-le pentru ca specialistul în plăți să se conecteze și să lucreze cu ARM KBR (de exemplu, printr-un cod malițios pe computerul său). Apoi, ei se conectează în numele lui și trimit un ordin de plată falsificat în sistemul de plăți al Băncii Rusiei.
Scenariul 3. Exemplu de implementare a amenințării U1.3.
Descrierea obiectului
Să luăm în considerare una dintre variantele ipotetice de implementare a modulelor de integrare „ABS-KBR” pentru noul sistem (ARM KBR-N), în care semnătura electronică a documentelor de ieșire se realizează pe partea ABS. În acest sens, vom considera că ABS funcționează pe o platformă de operare care nu este compatibilă cu SKEI SCAD Semnătură, și, în consecință, funcționalitatea criptografică este transferată pe o mașină virtuală separată — modulul de integrare „ABS-KBR”.
Ca suport de cheie este utilizat un token USB obișnuit, care funcționează în modul de cheie detașabil. La conectarea suportului de cheie la hipervizor, s-a constatat că în sistem nu sunt porturi USB disponibile, astfel că s-a decis conectarea tokenului USB printr-un hub USB de rețea, iar pe mașina virtuală a fost instalat clientul USB-over-IP, care va realiza conexiunea cu hub-ul.
Atac
Infractorii au interceptat cheia privată a semnăturii electronice din canalul de comunicație între hub-ul USB și hypervizor (datele erau transmise în formă deschisă). Având cheia privată, infractorii au generat un ordin de plată fals, l-au semnat cu semnătura electronică și l-au trimis spre executare în AРM KБP-Н.
Scenariul 4. Exemplu de implementare a amenințărilor U5.5.
Descrierea obiectului
Să analizăm aceeași schemă ca în scenariul anterior. Vom considera că mesajele electronice provenite din AРM KБP-Н ajung în folderul …SHAREIn, iar cele care sunt trimise în AРM KБP-Н și mai departe în sistemul de plată al Băncii Rusiei ajung în …SHAREout.
De asemenea, vom considera că, în implementarea modulului de integrare, listele de certificate retrase sunt actualizate doar în momentul reemisiei cheilor criptografice, precum și faptul că mesajele electronice care ajung în folderul …SHAREIn sunt verificate doar pentru controlul integrității și pentru controlul încrederii în cheia publică a semnăturii electronice.
Atac
Infractorii, profitând de cheile furate în scenariul anterior, au semnat un ordin de plată fals care conținea informații despre intrarea banilor în contul clientului-fraudator și l-au injectat în canalul de schimb de date protejate. Deoarece nu se efectuează verificări pentru a confirma că ordinul de plată este semnat de Banca Rusiei, acesta este acceptat pentru executare.
Sursa: habr.com
