Odkazy na iné časti výskumu
- (Ste tu)
Tento článok uzatvára cyklus publikácií venovaných zabezpečeniu informačnej bezpečnosti bankových bezhotovostných platieb. Tu sa pozrieme na typické modely hrozieb, na ktoré sme odkazovali v :
- .
- .
- .
- .
HABRO-WARNING !!! Vážení užívatelia Habra, toto nie je zábavný príspevok.
Skryté pod článkom 40+ strán materiálov sú určené na pomoc pri práci alebo štúdiu ľuďom, ktorí sa špecializujú na bankovníctvo alebo zabezpečenie informačnej bezpečnosti. Tieto materiály sú konečným produktom výskumu a sú napísané v suchom oficiálnom tóne. V podstate ide o predpripravené dokumenty pre interné materiály o IB.A tradične — „použitie informácií z článku na nelegálne účely sa sledovať podľa zákona“. Produktívne čítanie!
Informácie pre čitateľov, ktorí sa oboznamujú s výskumom, počínajúc touto publikáciou.
O čom je výskum
Čítate sprievodcu pre odborníka zodpovedného za zabezpečenie informačnej bezpečnosti platieb v banke.
Logika zloženia
Na začiatku v a je uvedený popis objektu ochrany. Potom v hovorí sa o tom, ako vytvoriť systém ochrany a o potrebe vytvorenia modelu hrozieb. V hovorí sa o tom, aké modely hrozieb existujú a ako ich definujú. V a sa uvádza analýza skutočných útokov. a obsahujú popis modelu hrozieb zostaveného na základe informácií zo všetkých predchádzajúcich častí.
TYPOVÝ MODEL HROZIEB. SIEŤOVÉ SPOJENIE
Objekt ochrany, pre ktorý sa uplatňuje model hrozieb (scope)
Objektom ochrany sú údaje prenášané cez sieťové spojenie, ktoré funguje v sieťach prenosu dát postavených na základe TCP/IP.
Architektúra
Popis prvkov architektúry:
- «Konečné uzly» — uzly vymieňajúce chránené informácie.
- «Medziuzlové uzly» — prvky siete prenosu dát: smerovače, prepínače, prístupové servery, proxy servery a iné zariadenia, cez ktoré sa prenáša prevádzka sieťového spojenia. Vo všeobecnosti môže sieťové spojenie fungovať aj bez medziuzlov (priamo medzi konečnými uzlami).
Hrozby bezpečnosti najvyššej úrovne
Dekonštrukcia
H1. Neautorizovaný prístup k prenášaným údajom.
H2. Neautorizovaná modifikácia prenášaných údajov.
H3. Porušenie autorských práv prenášaných údajov.
H1. Neautorizovaný prístup k prenášaným údajom
Dekonštrukcia
H1.1. <…>, vykonávané na konečných alebo medziuzlových uzloch:
H1.1.1. <…> čítaním údajov počas ich prítomnosti v pamäti uzla:
H1.1.1.1. <…> v operačnej pamäti.
Vysvetlenia k H1.1.1.1.
Napríklad, počas spracovania údajov sieťovým zásobníkom uzla.
H1.1.1.2. <…> v pamäti s trvalým úložiskom.
Vysvetlenia k H1.1.1.2.
Napríklad, pri uchovávaní prenášaných údajov v cache, dočasných súboroch alebo súboroch stránkovania.
H1.2. <…>, vykonávané na cudzích uzloch siete prenosu dát:
H1.2.1. <…> metódou zachytenia všetkých paketov, ktoré prechádzajú sieťovým rozhraním uzla:
Vysvetlenia k H1.2.1.
Zachytenie všetkých paketov sa uskutočňuje prepnutím sieťovej karty do štandardného režimu (promiscuous režim pre káblové adaptéry alebo monitorovací režim pre wi-fi adaptéry).
H1.2.2. <…> vykonaním útokov typu „človek v strede (MiTM)“, avšak bez modifikácie prenášaných údajov (s výnimkou smerových údajov sieťových protokolov).
H1.2.2.1. Odkaz: .
U1.3. , realizované prostredníctvom úniku informácií technickými kanálmi (TKUI) z fyzických uzlov alebo komunikačných liniek.
U1.4. , realizované inštaláciou na koncových alebo medzistaniciach špeciálnych technických prostriedkov (STC), určených na tajné zberanie informácií.
U2. Neoprávnená modifikácia prenášaných údajov
Dekonštrukcia
U2.1. , realizovaná na koncových alebo medzistaniciach:
U2.1.1. čítaním a vykonávaním zmien v údajoch počas ich pobytu v pamäťových médiách uzlov:
U2.1.1.1. v operačnej pamäti:
U2.1.1.2. v nevolatilnej pamäti:
U2.2. , realizovaná na externých uzloch siete prenosu údajov:
U2.2.1. prostredníctvom vykonávania útokov typu „človek uprostred (MiTM)“ a presmerovania prevádzky na uzol útočníkov:
U2.2.1.1. Fyzické pripojenie zariadení útočníkov do prerušenia sieťového pripojenia.
U2.2.1.2. Vykonávanie útokov na sieťové protokoly:
U2.2.1.2.1. spravovania virtuálnych lokálnych sietí (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Neoprávnená modifikácia nastavení VLAN na prepínačoch alebo smerovačoch.
U2.2.1.2.2. smerovania prevádzky:
U2.2.1.2.2.1. Neoprávnená modifikácia tabuliek statického smerovania smerovačov.
U2.2.1.2.2.2. Anonkovanie útočníkmi falošných trás cez protokoly dynamického smerovania.
U2.2.1.2.3. automatizovaného konfigurácie:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. adresovania a rozpoznávania mien:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Vykonávanie neoprávnených zmien v lokálnych súboroch mien uzlov (hosts, lmhosts a pod.)
U3. Porušenie autorstva prenášaných údajov
Dekonštrukcia
U3.1. Neutralizácia mechanizmov určenia autorstva informácií prostredníctvom uvedenia falošných údajov o autorovi alebo zdroji údajov:
U3.1.1. Zmena údajov o autorovi obsiahnutých v prenášanej informácii.
U3.1.1.1. Neutralizácia kryptografickej ochrany integrity a autorstva prenášaných údajov:
U3.1.1.1.1. Odkaz: .
U3.1.1.2. Neutralizácia ochrany autorských práv prenosu údajov realizovanej pomocou jednorazových potvrdení:
U3.1.1.2.1. .
U3.1.2. Zmena údajov o zdroji prenášanej informácie:
U3.1.2.1. .
U3.1.2.2. .
TYPICKÝ MODEL HROZBY. INFORMATÍVNY SYSÉM POSTAVENÝ NA ZÁKLADNE ARCHITEKTÚRY KLIENT-SERVER
Objekt ochrany, pre ktorý sa uplatňuje model hrozieb (scope)
Objektom ochrany je informačný systém, postavený na základe architektúry klient-server.
Architektúra
Popis prvkov architektúry:
- „Klient“ – zariadenie, na ktorom funguje klientská časť informačného systému.
- „Server“ – zariadenie, na ktorom funguje serverová časť informačného systému.
- „Úložisko údajov“ — časť serverovej infraštruktúry informačného systému určená na uloženie údajov spracovávaných informačným systémom.
- „Sieťové spojenie“ — kanál výmeny informácií medzi Klientom a Serverom, prechádzajúci cez sieť prenosu údajov. Podrobnejší popis modelu prvku je uvedený v .
Obmedzenia
Pri modelovaní objektu sú stanovené nasledujúce obmedzenia:
- Používateľ interaguje s informačným systémom v rámci konečných časových intervalov, nazývaných relácie práce.
- Na začiatku každej relácie práce prebieha identifikácia, autentizácia a autorizácia používateľa.
- Všetky chránené informácie sú uložené na serverovej časti informačného systému.
Hrozby bezpečnosti najvyššej úrovne
Dekonštrukcia
U1. Vykonávanie neautorizovaných činov kybernetickými zločincami v mene legitímneho používateľa.
U2. Neautorizovaná modifikácia chránených informácií počas ich spracovania serverovou časťou informačného systému.
U1. Vykonávanie neautorizovaných činov kybernetickými zločincami v mene legitímneho používateľa
Vysvetlenia
Vo všeobecnosti sa v informačných systémoch súvisiace činy s vykonávateľom pripisujú pomocou:
- záznamov činnosti systému (logs).
- špeciálnych atribútov objektov údajov, ktoré obsahujú informácie o používateľovi, ktorý ich vytvoril alebo zmenil.
V súvislosti s reláciou práce môže byť táto hrozba dekomponovaná na:
- vykonané v rámci relácie práce používateľa.
- vykonané mimo relácie práce používateľa.
Relácie práce používateľa môžu byť iniciované:
- Samotným používateľom.
- Kybernetickými zločincami.
V tejto fáze bude medzičná dekompozícia tejto hrozby vyzerať nasledovne:
U1.1. Neoprávnené činnosti vykonané v rámci pracovnej relácie používateľa:
U1.1.1. , nainštalované napadnutým používateľom.
U1.1.2. , nainštalované útočníkmi.
U1.2. Neoprávnené činnosti vykonané mimo pracovnej relácie používateľa.
Z pohľadu objektov informačnej infraštruktúry, na ktoré môžu útočníci vplývať, bude dekompozícia medzičnej hrozby vyzerať nasledovne:
Prvky
Dekompozícia hrozieb
U1.1.1.
U1.1.2.
U1.2.
Klienta
U1.1.1.1.
U1.1.2.1.
Sieťové pripojenie
U1.1.1.2.
Server
U1.2.1.
Dekonštrukcia
U1.1. Neoprávnené činnosti vykonané v rámci pracovnej relácie používateľa:
U1.1.1. , nainštalované napadnutým používateľom:
U1.1.1.1. Útočníci konali priamo ako Klient:
U1.1.1.1.1 Útočníci použili štandardné prostriedky prístupu informačného systému:
U1.1.1.1.1.1. Útočníci využili fyzické vstupno-výstupné prostriedky Klienta (klávesnica, myš, monitor alebo dotyková obrazovka mobilného zariadenia):
U1.1.1.1.1.1.1. Útočníci konali v časoch, keď bola relácia aktívna, vstupno-výstupné prostriedky dostupné a používateľ nebol prítomný.
U1.1.1.1.1.2. Útočníci použili prostriedky vzdialeného spravovania (štandardné alebo poskytované škodlivým kódom) na riadenie Klienta:
U1.1.1.1.1.2.1. Útočníci konali v časoch, keď bola relácia aktívna, vstupno-výstupné prostriedky dostupné a používateľ nebol prítomný.
U1.1.1.1.1.2.2. Útočníci použili prostriedky vzdialeného spravovania, ktorých činnosť bola pre napadnutého používateľa neviditeľná.
U1.1.1.2. Útočníci podvádzali údaje v sieťovom pripojení medzi Klientom a Serverom tak, aby boli vnímané ako činnosti legitímneho používateľa:
U1.1.1.2.1. Odkaz: .
U1.1.1.3. Útočníci prinútili používateľa vykonať určité činnosti pomocou metód sociálneho inžinierstva.
U1.1.2 nainštalované útočníkmi:
U1.1.2.1. Útočníci konali ako Klient (A):
U1.1.2.1.1. Útočníci neutralizovali systém obmedzovania prístupu informačného systému:
U1.1.2.1.1.1. Odkaz: .
U1.1.2.1.2. Útočníci využili bežné prostriedky prístupu informačného systému
U1.1.2.2. Útočníci konali z iných uzlov siete na prenos dát, z ktorých je možné nadviazať sieťové pripojenie so Serverom (A):
U1.1.2.2.1. Útočníci neutralizovali systém obmedzovania prístupu informačného systému:
U1.1.2.2.1.1. Odkaz: .
U1.1.2.2.2. Útočníci použili neštandardné prostriedky prístupu informačnej sústavy.
Vysvetlenia U1.1.2.2.2.
Útočníci mohli nainštalovať štandardného klienta informačného systému na cudzí uzol alebo mohli použiť neštandardný softvér, ktorý realizuje štandardné protokoly výmeny medzi Klientom a Serverom.
U1.2 Neautorizované akcie boli vykonané mimo relácie prístupu používateľa.
U1.2.1 Útočníci vykonali neautorizované akcie a následne vykonali neautorizované zmeny v záznamoch prác informačného systému alebo špeciálnych atribútoch dátových objektov, uvádzajúc, že vykonané akcie boli realizované legitímnym používateľom.
U2. Neautorizovaná modifikácia chránených informácií počas ich spracovania serverovou časťou informačného systému
Dekonštrukcia
U2.1. Útočníci modifikujú chránené informácie pomocou štandardných prostriedkov informačného systému a robia to v mene legitímneho používateľa.
U2.1.1. Odkaz: .
U2.2. Útočníci modifikujú chránené informácie použitím mechanizmov prístupu k dátam, ktoré nie sú predpokladané bežným režimom fungovania informačného systému.
U2.2.1. Útočníci modifikujú súbory obsahujúce chránené informácie:
U2.2.1.1. , využívajúc mechanizmy práce so súbormi, ktoré poskytuje operačný systém.
U2.2.1.2. provokovaním obnovenia súborov z neautorizovane modifikovanej zálohy.
U2.2.2. Útočníci modifikujú chránené informácie, ktoré sú uložené v databáze (A):
U2.2.2.1. Útočníci neutralizujú systém prístupových práv DBMS:
U2.2.2.1.1. Odkaz: .
U2.2.2.2. Útočníci modifikujú informácie pomocou štandardných rozhraní DBMS na prístup k dátam.
U2.3. Útočníci modifikujú chránené informácie neoprávnenou modifikáciou algoritmov fungovania spracovateľského softvéru.
U2.3.1. Modifikáciám podlieha zdrojový kód softvéru.
U2.3.1. Modifikáciám podlieha strojový kód softvéru.
U2.4. Útočníci modifikujú chránené informácie zneužitím zraniteľností v softvéri informačného systému.
U2.5. Útočníci modifikujú chránené informácie pri ich prenose medzi komponentmi serverovej časti informačného systému (napríklad medzi serverom databáz a serverom aplikácií):
U2.5.1. Odkaz: .
TYPOVÝ MODEL HROZBY. SYSTÉM ROZDEĽOVANIA PRÍSTUPU
Objekt ochrany, pre ktorý sa uplatňuje model hrozieb (scope)
Objekt ochrany, pre ktorý sa uplatňuje tento model hrozieb, zodpovedá objektu ochrany modelu hrozieb: „Typový model hrozieb. Informačný systém postavený na architektúre klient-server“.
Pod systémom rozdeľovania prístupu používateľov v tomto modeli hrozieb sa rozumie komponent informačného systému, ktorý vykonáva funkcie:
- Identifikácie používateľov.
- Autentifikácie používateľov.
- Autorizácie používateľov.
- Protokolovania činnosti používateľov.
Hrozby bezpečnosti najvyššej úrovne
Dekonštrukcia
U1. Neoprávnené nadviazanie pracovnej relácie v mene legitímneho používateľa.
U2. Neoprávnené zvýšenie oprávnení používateľa v informačnom systéme.
U1. Neoprávnené nadviazanie pracovnej relácie v mene legitímneho používateľa
Vysvetlenia
Dezkompozícia tejto hrozby v generálnom prípade bude závisieť od typu systémov identifikácie a autentifikácie používateľov.
V tomto modeli bude prejednávaný iba systém identifikácie a autentifikácie používateľov, ktorý používa textové prihlasovacie meno a heslo. Pritom budeme predpokladať, že prihlasovacie meno používateľa je verejne dostupná informácia, známa útočníkom.
Dekonštrukcia
U1.1. na základe kompromitácie prihlasovacích údajov:
U1.1.1. Útočníci skompromitovali prihlasovacie údaje používateľa počas ich uchovávania.
Vysvetlenia U1.1.1.
Napríklad, prihlasovacie údaje mohli byť napísané na nálepke prilepenej na monitore.
U1.1.2. Používateľ náhodne alebo so zlým úmyslom odovzdal prístupové údaje útočníkom.
U1.1.2.1. Používateľ nahlas hovoril o svojich prihlasovacích údajoch počas ich zadávania.
U1.1.2.2. Používateľ úmyselne odovzdal svoje prihlasovacie údaje:
U1.1.2.2.1. kolegom v práci.
Objasnenia U1.1.2.2.1.
Napríklad, aby ich mohli nahradiť počas choroby.
U1.1.2.2.2. obchodným partnerom zamestnávateľa, ktorí vykonávajú práce na objektoch informačnej infraštruktúry.
U1.1.2.2.3. tretím osobám.
Objasnenia U1.1.2.2.3.
Jedným, ale nie jediným variantom realizácie tejto hrozby je použitie metód sociálneho inžinierstva útočníkmi.
U1.1.3. Útočníci uhádli prihlasovacie údaje metódou pokusu a omylu:
U1.1.3.1. využitím štandardných prístupových mechanizmov.
U1.1.3.2. prostredníctvom predtým zachytených kódov (napríklad, hashov hesiel) uchovávania prihlasovacích údajov.
U1.1.4. Útočníci použili škodlivý kód na zachytenie prihlasovacích údajov používateľa.
U1.1.5. Útočníci extrahovali prihlasovacie údaje z sieťového spojenia medzi Klientom a Serverom:
U1.1.5.1. Odkaz: .
U1.1.6. Útočníci extrahovali prihlasovacie údaje z záznamov systémov monitorovania práce:
U1.1.6.1. systéme sledovania videa (v prípade, že sa počas práce zaznamenávali stlačenia klávesov na klávesnici).
U1.1.6.2. systémoch kontroly činností zamestnancov na počítači.
Objasnenia U1.1.6.2.
Príkladom podobného systému je .
U1.1.7. Útočníci skompromitovali prihlasovacie údaje používateľa v dôsledku nedostatkov v procese ich prenosu.
Objasnenia U1.1.7.
Napríklad, odovzdanie hesiel v nezakryptovanej podobe prostredníctvom e-mailu.
U1.1.8. Útočníci získali prihlasovacie údaje pozorovaním užívateľskej relácie používateľa pomocou systémov vzdialeného spravovania.
U1.1.9. Útočníci extrahovali prihlasovacie údaje v dôsledku ich úniku cez technické kanály (TKU):
U1.1.9.1. Útočníci videli, ako používateľ zadáva prihlasovacie údaje z klávesnice:
U1.1.9.1.1 Útočníci sa nachádzali v tesnej blízkosti používateľa a videli, ako zadáva prihlasovacie údaje vlastnými očami.
Objasnenia U1.1.9.1.1
K podobným prípadom patrí konanie kolegov v práci alebo situácia, keď je klávesnica používateľa viditeľná návštevníkom organizácie.
U1.1.9.1.2 Útočníci použili dodatočné technické prostriedky, ako sú ďalekohľad alebo bezpilotný lietajúci aparát, a videli zadávanie prihlasovacích údajov cez okno.
U1.1.9.2. Útočníci získali prihlasovacie údaje z záznamov rádiovej komunikácie medzi klávesnicou a systémovou jednotkou počítača, ak boli pripojené prostredníctvom rádiového rozhrania (napríklad Bluetooth).
U1.1.9.3. Útočníci zachytili prihlasovacie údaje vďaka ich úniku cez kanál bočných elektromagnetických žiarení a indukcií (PEMI).
Vysvetlenia U1.1.9.3.
Príklady útokov a .
U1.1.9.4. Útočník zachytil zadávanie prihlasovacích údajov z klávesnice pomocou špeciálnych technických prostriedkov (ŠTP), určených na tajné získavanie informácií.
Vysvetlenia U1.1.9.4.
Príklady .
U1.1.9.5. Útočníci zachytili zadávanie prihlasovacích údajov z klávesnice prostredníctvom
analýzy Wi-Fi signálu modulovaného procesom stláčania klávesov používateľom.
Vysvetlenia U1.1.9.5.
Príklad .
U1.1.9.6. Útočníci zachytili zadávanie prihlasovacích údajov z klávesnice prostredníctvom analýzy zvukov stláčania klávesov.
Vysvetlenia U1.1.9.6.
Príklad .
U1.1.9.7. Útočníci zachytili zadávanie prihlasovacích údajov z klávesnice mobilného zariadenia analýzou údajov z akcelerometra.
Vysvetlenia U1.1.9.7.
Príklad .
U1.1.10. , predtým uložené na Klientovi.
Vysvetlenia U1.1.10.
Napríklad, používateľ mohol uložiť v prehliadači prihlasovacie meno a heslo pre prístup na konkrétnu stránku.
U1.1.11. Útočníci skompromitovali prihlasovacie údaje z dôvodu nedostatkov v procese odvolávania prístupov používateľov.
Vysvetlenia U1.1.11.
Napríklad, po odchode používateľa z pracoviska jeho používateľské účty zostali nezablokované.
U1.2. vďaka využívaniu zraniteľností v systéme obmedzenia prístupu.
U2. Neoprávnené zvýšenie privilégií používateľa v informačnom systéme
Dekonštrukcia
U2.1 prostredníctvom neoprávnených zmien v údajoch, ktoré obsahujú informácie o privilégiách používateľa.
U2.2 vďaka využívaniu zraniteľností v systéme obmedzenia prístupu.
U2.3. z dôvodu nedostatkov v procese správy prístupov používateľov.
Vysvetlenia U2.3.
Príklad 1. Používateľovi bol poskytnutý prístup väčší, než potreboval pre pracovné potreby.
Príklad 2. Po presune používateľa na inú pozíciu neboli predchádzajúce prístupové práva zrušené.
TYPICKÝ MODELOVÝ HROZBA. MODUL INTEGRÁCIE
Objekt ochrany, pre ktorý sa uplatňuje model hrozieb (scope)
Modul integrácie je súbor objektov informačnej infraštruktúry určený na organizáciu výmeny informácií medzi informačnými systémami.
Zohľadňujúc fakt, že v korporátnych sieťach nie je vždy možné jednoznačne oddeliť jeden informačný systém od druhého, modul integrácie možno považovať aj za spojenie medzi komponentmi v rámci jedného informačného systému.
Architektúra
Zovšeobecnená schéma modulu integrácie vyzerá nasledovne:
Popis prvkov architektúry:
- „Server výmeny (SV)“ – uzol / služba / komponent informačného systému, ktorý vykonáva funkciu výmeny údajov s iným informačným systémom.
- „Prostredník“ – uzol / služba určená na organizáciu interakcie medzi informačnými systémami, ale nie je súčasťou ich štruktúry.
Príklad „Prostredníkov“ môžu byť služby elektronickej pošty, podnikové služobné zbernice (enterprise service bus / SoA-architektúra), externé súborové servery atď. V obvyklých prípadoch modul integrácie nemusí obsahovať „Prostredníkov“. - „SW na spracovanie údajov“ – súbor programov, ktoré implementujú protokoly výmeny údajov a transformáciu formátov.
Napríklad, transformácia údajov z formátu UFEBS do formátu ABS, zmena stavov správ počas prenosu atď. - „Sieťové spojenie“ zodpovedá objektu opísanému v typovom modeli hrozieb „Sieťové pripojenie“. Niektoré sieťové pripojenia z tých, ktoré sú zobrazené na schéme vyššie, nemusia existovať.
Príklady modulov integrácie
Schéma 1. Integrácia ABS a ARM KBR cez externý súborový server
Na vykonanie platieb poverený zamestnanec banky vyexportuje z ABS elektronické platobné dokumenty a uloží ich do súboru (vlastného formátu, napríklad SQL-dump) na sieťovej zdieľanej zložke (…SHARE) súborového servera. Potom sa tento súbor pomocou skriptu na konverziu pretransformuje na súbor formátu UFEBS, ktorý potom číta ARM KBR.
Po prijatí zamestnanec s oprávneniami — používateľ AРM КБР — zašifruje a podpíše prijatý súbor a pošle ho do platobného systému Banky Ruska.
Pri prijímaní platieb z Banky Ruska AРM КБР vykonáva ich dešifrovanie a overovanie elektronického podpisu, následne ich zapisuje vo forme súborového súboru vo formáte УФЭБС na súborový server. Pred importom platobných dokumentov do АБС sa tieto konvertujú pomocou skriptu-konvertora z formátu УФЭБС do formátu АБС.
Predpokladajme, že v tejto schéme АБС funguje na jednom fyzickom serveri, AРM КБР funguje na vyhradenom počítači a skript-konvertor pracuje na súborovom serveri.
Zhodnosť objektov vyskytujúcich sa v schéme s prvkami modelu integračného modulu:
„Servery výmeny zo strany АБС“ – server АБС.
„Servery výmeny zo strany AРM КБР“ – počítač AРM КБР.
„Prostredník“ – externý súborový server.
„SW na spracovanie údajov“ – skript-konvertor.
Schéma 2. Integrácia АБС a AРM КБР pri umiestnení spoločnej sieťovej zložky s platbami na AРM КБР
Všetko podobne ako v Schéme 1, ale samostatný súborový server nie je používaný, namiesto toho sa sieťová zložka (…SHARE) s elektronickými platobnými dokumentmi umiestňuje na počítači s AРM КБР. Skript-konvertor tiež pracuje na AРM КБР.
Zhodnosť objektov vyskytujúcich sa v schéme s prvkami modelu integračného modulu:
Podobne ako v Schéme 1, ale „Prostredník“ nie je používaný.
Schéma 3. Integrácia АБС a AРM КБР-Н cez IBM WebSphere MQ a vykonanie podpisu elektronických dokumentov „na strane АБС“
АБС funguje na platforme, ktorá nie je podporovaná SКЗИ СКАД Сигнатура. Podpis odchádzajúcich elektronických dokumentov sa vykonáva na špeciálnom servery elektronického podpisu (Server ЭП). Tento server tiež overuje elektronický podpis prijatých dokumentov z Banky Ruska.
АБС exportuje na Server ЭП súbor s platobnými dokumentmi vo vlastnom formáte.
Server ЭП pomocou skriptu-konvertora konvertuje súbor na elektronické správy formátu УФЭБС, po čom sú elektronické správy podpísané a odoslané na IBM WebSphere MQ.
AРM КБР-Н sa obráti na IBM WebSphere MQ a získa odtiaľ podpísané platobné správy, po čom zamestnanec s oprávneniami — používateľ AРM КБР — zašifruje a odošle ich do platobného systému Banky Ruska.
Pri prijímaní platieb z Banku Ruska ARK KBR-N ich dešifruje a kontroluje elektronický podpis. Úspešne spracované platby vo forme dešifrovaných a podpísaných elektronických správ formátu UFEBS sa odosielajú do IBM WebSphere MQ, odkiaľ ich prijíma Server EP.
Server EP overuje elektronický podpis prijatých platieb a uklada ich do súboru formátu ABS. Potom oprávnený pracovník — používateľ ABS — načíta získaný súbor do ABS podľa stanoveného postupu.
Zhodnosť objektov vyskytujúcich sa v schéme s prvkami modelu integračného modulu:
„Server výmeny zo strany ABS“ – server АБС.
„Server výmeny zo strany ARK KBR“ — počítač ARK KBR.
„Prostredník“ – Server EP a IBM WebSphere MQ.
„SW na spracovanie údajov“ – skript-prevodník, SKZI SKAD Podpis na Serveri EP.
Schéma 4. Integrácia Servera DBO a ABS cez API, poskytovaného vyhradeným serverom výmeny
Považujme, že v banke sa používa niekoľko systémov dištančného bankovníctva (DBO):
- „Internet Klient-Bank“ pre fyzické osoby (IKB FZ);
- „Internet Klient-Bank“ pre právnické osoby (IKB PO).
S cieľom zabezpečiť informačnú bezpečnosť sa všetka interakcia ABS so systémami DBO uskutočňuje cez vyhradený server výmeny, ktorý funguje v rámci informačného systému „ABS“.
Ďalej si pozrieme proces interakcie systému DBO IKB PO s ABS.
Server DBO, ktorý od klienta dostal riadne overené platobné príkazy, musí na ich základe vytvoriť príslušný dokument v ABS. Na tento účel prostredníctvom API odovzdáva informácie na server výmeny, ktorý následne vkladá údaje do ABS.
Pri zmene zostatkov na účte klienta ABS generuje elektronické upozornenia, ktoré sa prostredníctvom servera výmeny odosielajú na server DBO.
Zhodnosť objektov vyskytujúcich sa v schéme s prvkami modelu integračného modulu:
„Server výmeny zo strany DBO“ – server DBO IKB PO.
„Server výmeny zo strany ABS“ – server výmeny.
„Prostredník“ – chýba.
„SW na spracovanie údajov“ – komponenty Servera DBO, zodpovedné za používanie API servera výmeny, komponenty servera výmeny, zodpovedné za používanie API ABS.
Hrozby bezpečnosti najvyššej úrovne
Dekonštrukcia
U1. Vniknutie útočníkov s falošnými informáciami prostredníctvom integračného modulu.
U1. Vniknutie útočníkov s falošnými informáciami prostredníctvom integračného modulu
Dekonštrukcia
U1.1. Neoprávnená modifikácia legitímnych údajov pri ich prenose cez sieťové spojenia:
U1.1.1 Odkaz: .
U1.2. Prenos falošných údajov po komunikačných kanáloch menom legitímneho účastníka výmeny:
U1.1.2 Odkaz: .
U1.3. Neoprávnená modifikácia legitímnych údajov pri ich spracovaní na serveroch výmeny alebo prostriedkoch:
U1.3.1. Odkaz: .
U1.4. Vytvorenie falošných údajov na serveroch výmeny alebo prostriedkoch v mene legitímneho účastníka výmeny:
U1.4.1. Odkaz:
U1.5. Neoprávnená modifikácia údajov pri ich spracovaní pomocou softvéru na spracovanie údajov:
U1.5.1. prostredníctvom neoprávnených zmien útočníkov v nastaveniach (konfigurácii) softvéru na spracovanie údajov.
U1.5.2. prostredníctvom neoprávnených zmien útočníkov vo vykonávaných súboroch softvéru na spracovanie údajov.
U1.5.3. prostredníctvom interaktívneho riadenia správania softvéru na spracovanie údajov útočníkmi.
TYPOLÓGIA HROZIEB. SYSTÉM KRYPTOGRAFICKÉHO OCHRANY INFORMÁCIÍ
Objekt ochrany, pre ktorý sa uplatňuje model hrozieb (scope)
Chráneným objektom je systém kryptografickej ochrany informácií, ktorý sa používa na zabezpečenie informačného systému.
Architektúra
Základom každého informačného systému je aplikačný softvér, ktorý realizuje jeho cieľový funkčný výkon.
Kryptografická ochrana sa obvykle realizuje pomocou volania kryptografických primitívov z obchodnej logiky aplikačného softvéru, ktoré sú umiestnené v špecializovaných knižniciach – kryptojadroch.
K kryptografickým primitívom patrí nízkoúrovňové kryptografické funkcie, ako sú:
- zašifrovať / dešifrovať blok údajov;
- vytvoriť / overiť elektronický podpis bloku údajov;
- vypočítať hash-funkciu bloku údajov;
- vytvoriť / načítať / vyexportovať kľúčové údaje;
- a pod.
Obchodná logika aplikačného softvéru implementuje pomocou kryptografických primitívov vyšší funkčný výkon:
- zašifrovať súbor na kľúčoch vybraných príjemcov;
- nastaviť zabezpečené sieťové pripojenie;
- informovať o výsledkoch overenia elektronického podpisu;
- a podobne.
Interakcia biznis logiky a kryptotela môže prebiehať:
- priamo, prostredníctvom volania biznis logikou kryptografických primitívov z dynamických knižníc kryptotela (.DLL – pre Windows, .SO – pre Linux);
- nepriamo, cez kryptografické rozhrania – obálky (wrappers), napríklad MS Crypto API, Java Cryptography Architecture, PKCS#11 a ďalšie. V tomto prípade biznis logika oslovuje kryptointerface, ktorý prekladá volanie na príslušné kryptotelo, ktoré sa v tomto prípade nazýva kryptoprovider. Používanie kryptografických rozhraní umožňuje aplikačnému softvéru abstrahovať od konkrétnych kryptografických algoritmov a byť flexibilnejšie.
Možno rozlíšiť dve typické schémy organizácie kryptotela:
Schéma 1 – Monolitické kryptotelo
Schéma 2 – Rozdelené kryptotelo
Prvky na uvedených schémach môžu byť ako samostatnými modulmi softvéru, ktoré fungujú na jednom počítači, tak aj sieťovými službami, ktoré interagujú v rámci výpočtovej siete.
Pri použití systémov postavených na schéme 1 aplikačný softvér a kryptotelo fungujú v rámci jedinej prevádzkové prostredia kryptosystému (FKC), napríklad na rovnakom počítači, pod riadením rovnakého operačného systému. Používateľ systému zvyčajne môže spúšťať v rámci tohto prostredia aj ďalšie programy, vrátane tých, ktoré obsahujú škodlivý kód. V takýchto podmienkach existuje vážne riziko úniku uzavretých kryptografických kľúčov.
Na minimalizáciu rizika sa používa schéma 2, pri ktorej sa kryptotelo delí na dve časti:
- Prvá časť spolu s aplikačným softvérom funguje v nedôveryhodnom prostredí, kde existuje riziko nákazy škodlivým kódom. Túto časť budeme nazývať – „softvérová časť“.
- Druhá časť funguje v dôveryhodnom prostredí na vyhradenom zariadení, ktoré obsahuje vo svojej zostave úložisko uzavretých kľúčov. Ďalej budeme túto časť nazývať – „hardvérová časť“.
Rozdelenie kryptojadra na softvérové a hardvérové časti je veľmi podmienené. Na trhu existujú systémy postavené na schéme s rozdeleným kryptojadrom, ale "hardvérová" časť z nich je prezentovaná vo forme obrazu virtuálneho stroja — virtual HSM ().
Interakcia oboch častí kryptojadra prebieha takým spôsobom, že súkromné kryptografické kľúče sa nikdy neprenášajú do softvérovej časti a teda nemôžu byť ukradnuté pomocou škodlivého kódu.
Rozhranie interakcie (API) a súbor kryptografických primitívov poskytovaných aplikačným softvérom kryptojadrom sú v oboch prípadoch rovnaké. Rozdiel spočíva v spôsobe ich implementácie.
Tak pri použití schémy s rozdeleným kryptojadrom prebieha interakcia softvérovej a hardvérovej časti podľa nasledujúceho princípu:
- Kryptografické primitívy, ktoré nevyžadujú použitie súkromného kľúča (napríklad výpočet hash-funkcie, overovanie elektronického podpisu a pod.), sú vykonávané softvérovou časťou.
- Kryptografické primitívy, používajúce súkromný kľúč (vytváranie elektronického podpisu, dešifrovanie údajov a pod.), sú vykonávané hardvérovou časťou.
Ilustrujme prácu rozdeleného kryptojadra na príklade vytvárania elektronického podpisu:
- Softvérová časť vypočíta hash-funkciu podpisovaných údajov a prostredníctvom výmenného kanála medzi kryptojadrami tento údaj prenáša do hardvérovej časti.
- Hardvérová časť, využívajúc súkromný kľúč a hash, vytvorí hodnotu elektronického podpisu a prostredníctvom výmenného kanála ju prenáša do softvérovej časti.
- Softvérová časť vráti získanú hodnotu aplikačnému softvéru.
Osobitosti overovania správnosti elektronického podpisu
Keď prijímajúca strana dostane údaje podpísané elektronickým podpisom, musí prejsť niekoľkými etapami overenia. Kladný výsledok overenia elektronického podpisu sa dosiahne iba pri úspešnom prechode všetkými etapami overenia.
Etapa 1. Kontrola integrity údajov a autorstva údajov.
Obsah etapy. Prebieha kontrola elektronického podpisu údajov podľa zodpovedajúceho kryptografického algoritmu. Úspešné dokončenie tejto fázy znamená, že údaje neboli modifikované od momentu ich podpísania a že podpis bol vytvorený súkromným kľúčom, ktorý zodpovedá verejnému kľúču pre kontrolu elektronického podpisu.
Miesto vykonania fázy: krypto jadro.
Fáza 2. Kontrola dôvery k verejnému kľúču podpisujúceho a kontrola platnosti súkromného kľúča elektronického podpisu.
Obsah etapy. Fáza sa skladá z dvoch medzi-fáz. Na prvej sa stanovuje, či bol verejný kľúč pre kontrolu elektronického podpisu dôveryhodný v momente podpisovania údajov. Na druhej sa zisťuje, či súkromný kľúč elektronického podpisu bol platný v momente podpisovania údajov. V obvyklých prípadoch môžu byť lehoty platnosti týchto kľúčov nesúrodé (napríklad pre kvalifikované certifikáty kľúčov pre kontrolu elektronického podpisu). Spôsob, ako určiť dôveru k verejnému kľúču podpisujúceho, je daný pravidlami elektronického dokumentového obchodu, ktoré boli prijaté zúčastnenými stranami.
Miesto vykonania fázy: aplik softvér / krypto jadro.
Fáza 3. Kontrola oprávnení podpisujúceho.
Obsah etapy. V súlade s ustanovenými pravidlami elektronického dokumentového obchodu sa kontroluje, či mal podpisujúci právo overiť chránené údaje. Pre ilustráciu uvádzame situáciu porušenia oprávnení. Predpokladajme, že existuje organizácia, kde všetci zamestnanci majú elektronický podpis. Do vnútornej sústavy elektronického dokumentového obchodu prichádza príkaz vedúceho, ale podpísaný elektronickým podpisom vedúceho skladu. Preto takýto dokument nemôže byť považovaný za legitímny.
Miesto vykonania fázy: aplik softvér.
Predpoklady prijaté pri opise objektu ochrany
- Kanály prenosu informácií, okrem kanálov na zmenu kľúčov, vrátane prechádzajú cez aplik softvér, API a krypto jadro.
- Informácie o dôvere k verejným kľúčom a/alebo certifikátom, ako aj informácie o oprávneniach vlastníkov verejných kľúčov, sa umiestňujú do úložiska verejných kľúčov.
- Aplik softvér pracuje s úložiskom verejných kľúčov cez krypto jadro.
Príklad informačného systému chráneného pomocou SKZI
Na ilustráciu predtým predložených schém zvážime hypotetický informačný systém a vyzdvihneme na ňom všetky štrukturálne prvky.
Popis informačného systému
Dve organizácie sa rozhodli zaviesť medzi sebou právne platný elektronický obeh dokumentov (EOD). Na tento účel uzavreli dohodu, v ktorej stanovili, že dokumenty budú zasielané e-mailom a musia byť pritom šifrované a podpisované kvalifikovaným elektronickým podpisom. Ako prostriedky na vytváranie a spracovávanie dokumentov budú používané kancelárske programy z balíka Microsoft Office 2016, a ako prostriedky na kryptografickú ochranu – SKZI KryptoPRO a softvér šifrovania KryptoARM.
Popis infraštruktúry organizácie 1
Organizácia 1 sa rozhodla, že nainštaluje SKZI KryptoPRO a softvér KryptoARM na AÚP používateľa – fyzický počítač. Kľúče na šifrovanie a elektronický podpis budú uložené na kľúčovom nosiči ruToken, fungujúcom v režime vyberateľného kľúča. Používateľ bude pripravovať elektronické dokumenty lokálne na svojom počítači, po čom ich zašifruje, podpíše a pošle pomocou lokálne nainštalovaného e-mailového klienta.
Popis infraštruktúry organizácie 2
Organizácia 2 sa rozhodla presunúť funkcie šifrovania a elektronického podpisu na vyhradenú virtuálnu mašinu. Všetky kryptografické operácie budú vykonávané automaticky.
Na tejto vyhradenej virtuálnej mašine sú zriadené dve sieťové priečinky: „...In“, „...Out“. Do sieťového priečinka „...In“ budú automaticky umiestňované prijaté od obchodného partnera súbory v otvorenom formáte. Tieto súbory budú dešifrované a na nich bude overený elektronický podpis.
Do priečinka „...Out“ bude používateľ umiestňovať súbory, ktoré je potrebné zašifrovať, podpísať a poslať obchodnému partnerovi. Samotné súbory bude používateľ pripravovať na svojom AÚPe.
Na vykonávanie funkcií šifrovania a elektronického podpisu je na virtuálnu mašinu nainštalovaná SKZI KryptoPRO, softvér KryptoARM a e-mailový klient. Automatická správa všetkých prvkov virtuálnej mašiny bude realizovaná pomocou skriptov vyvinutých systémovými administrátormi. Práca skriptov je protokolovaná do súborov záznamov (logs).
Криптографические ключи электронной подписи будут размещаться на токене с неизвлекаемым ключом JaCarta ГОСТ, который пользователь будет подключать к своему локальному компьютеру.
Токен будет пробрасываться на виртуальную машину с помощью специализированных программных средств USB-over-IP, установленных на АРМе пользователя и на виртуальной машине.
Системные часы на АРМе пользователя в организации 1 будут корректироваться в ручном режиме. Системные часы специализированной виртуальной машины в организации 2 будут синхронизироваться с системными часами гипервизора, а те, в свою очередь, будут синхронизироваться через Интернет с публичными серверами времени.
Выделение структурных элементов СКЗИ
На основании вышеприведенного описания IT-инфраструктуры выделим структурные элементы СКЗИ и запишем их в таблицу.
Таблица — Соответствие элементов модели СКЗИ элементам информационных систем
Наименование элемента
Организация 1
Организация 2
Прикладное ПО
ПО КриптоАРМ
ПО КриптоАРМ
Программная часть криптоядра
СКЗИ КриптоПРО CSP
СКЗИ КриптоПРО CSP
Аппаратная часть криптоядра
neexistuje
JaCarta ГОСТ
API
MS CryptoAPI
MS CryptoAPI
Хранилище открытых ключей
АРМ пользователя:
— жесткий диск;
— стандартное хранилище сертификатов Windows.
Гипервизор:
— жесткий диск.
Виртуальная машина:
— жесткий диск;
— стандартное хранилище сертификатов Windows.
Хранилище закрытых ключей
Ключевой носитель ruToken, работающий в режиме извлекаемого ключа
Ключевой носитель JaCarta ГОСТ, работающий в режиме неизвлекаемого ключа
Канал обмена открытыми ключами
АРМ пользователя:
— оперативная память.
Гипервизор:
— оперативная память.
Виртуальная машина:
— оперативная память.
Канал обмена закрытыми ключами
АРМ пользователя:
— USB шина;
— оперативная память.
neexistuje
Канал обмена между криптоядрами
отсутствует (нет аппаратной части криптоядра)
АРМ пользователя:
— USB шина;
— оперативная память;
— программный модуль USB-over-IP;
— сетевой интерфейс.
Корпоративная сеть организации 2.
Гипервизор:
— оперативная память;
— сетевой интерфейс.
Виртуальная машина:
— сетевой интерфейс;
— оперативная память;
— программный модуль USB-over-IP.
Канал обмена открытыми данными
АРМ пользователя:
— средства ввода-вывода;
— оперативная память;
— жесткий диск.
АРМ пользователя:
— средства ввода-вывода;
— оперативная память;
— жесткий диск;
— сетевой интерфейс.
Корпоративная сеть организации 2.
Гипервизор:
— сетевой интерфейс;
— оперативная память;
— жесткий диск.
Виртуальная машина:
— сетевой интерфейс;
— оперативная память;
— жесткий диск.
Канал обмена защищенными данными
Интернет.
Корпоративная сеть организации 1.
АРМ пользователя:
— жесткий диск;
— оперативная память;
— сетевой интерфейс.
Интернет.
Корпоративная сеть организации 2.
Гипервизор:
— сетевой интерфейс;
— оперативная память;
— жесткий диск.
Виртуальная машина:
— сетевой интерфейс;
— оперативная память;
— жесткий диск.
Канал передачи времени
АРМ пользователя:
— средства ввода-вывода;
— оперативная память;
— системный таймер.
Интернет.
Корпоративная сеть организации 2,
Гипервизор:
— сетевой интерфейс;
— оперативная память;
— системный таймер.
Виртуальная машина:
— оперативная память;
— системный таймер.
Канал передачи управляющих команд
АРМ пользователя:
— средства ввода-вывода;
— оперативная память.
(Графический пользовательский интерфейс ПО КриптоАРМ)
Виртуальная машина:
— оперативная память;
— жесткий диск.
(Скрипты автоматизации)
Канал приема результатов работы
АРМ пользователя:
— средства ввода-вывода;
— оперативная память.
(Графический пользовательский интерфейс ПО КриптоАРМ)
Виртуальная машина:
— оперативная память;
— жесткий диск.
(Файлы журналов работы скриптов автоматизации)
Hrozby bezpečnosti najvyššej úrovne
Vysvetlenia
Допущения, принятые при декомпозиции угроз:
- Používajú sa odolné kryptografické algoritmy.
- Kryptografické algoritmy sa používajú bezpečným spôsobom v správnych prevádzkových režimoch (napríklad, nepoužíva sa na šifrovanie veľkých objemov dát, pričom sa berie do úvahy prípustná záťaž kľúča atď.).
- Útočníkom sú známe všetky používané algoritmy, protokoly a verejné kľúče.
- Útočníkom sú prístupné na čítanie všetky zašifrované dáta.
- Útočníci sú schopní reprodukovať akékoľvek softvérové elementy v systéme.
Dekonštrukcia
U1. Kompromitácia súkromných kryptografických kľúčov.
U2. Šifrovanie falošných dát v mene legitímneho odosielateľa.
U3. Dešifrovanie zašifrovaných dát osobami, ktoré nie sú legitímnymi príjemcami dát (útočníkmi).
U4. Vytvorenie elektronického podpisu legitímneho podpisujúceho na falošných dátach.
U5. Získanie pozitívneho výsledku kontroly elektronického podpisu falošných dát.
U6. Chybné prijatie elektronických dokumentov na vykonanie v dôsledku problémov v organizácii elektronického dokumentového toku.
U7. Neoprávnené oboznámenie sa s chránenými dátami počas ich spracovania SKZI.
U1. Kompromitácia súkromných kryptografických kľúčov
U1.1. Získanie súkromného kľúča z úložiska súkromných kľúčov.
U1.2. Získanie súkromného kľúča z objektov prostredia funkcie kryptomedzi, v ktorých môže dočasne existovať.
Vysvetlenia U1.2.
Medzi objekty, v ktorých môže dočasne existovať súkromný kľúč, sa budú rátať:
- operačná pamäť,
- dočasné súbory,
- swap súbory,
- hibernačné súbory,
- súbory snímok „horúceho“ stavu virtuálnych strojov, vrátane súborov obsahu operačnej pamäte virtuálnych strojov, ktoré sú pozastavené.
U1.2.1. Extrahovanie súkromných kľúčov z pracujúcej operačnej pamäte prostredníctvom zmrazenia modulov RAM, ich extrakcie a následného čítania dát (freeze attack).
Vysvetlenia U1.2.1.
Príklad .
U1.3. Získanie súkromného kľúča z kanála výmeny súkromných kľúčov.
Vysvetlenia U1.3.
Príklad implementácie tejto hrozby bude uvedený .
U1.4. Neoprávnená modifikácia kryptomotora, v dôsledku ktorej sa súkromné kľúče dostanú do rúk útočníkom.
U1.5. Kompromitácia uzavretého kľúča v dôsledku používania technických kanálov úniku informácií (TKUI).
Vysvetlenia U1.5.
Príklad .
U1.6. Kompromitácia uzavretého kľúča v dôsledku používania špecializovaných technických prostriedkov (STS), určených na nelegálny zber informácií ("červíky").
U1.7. Kompromitácia uzavretých kľúčov počas ich uchovávania mimo SKZI.
Vysvetlenia U1.7.
Napríklad, používateľ uchováva svoje kľúčové médiá v zásuvke pracovného stola, odkiaľ ich môžu ľahko vybrať útočníci.
U2. Šifrovanie falošných údajov v mene legitímneho odosielateľa.
Vysvetlenia
Toto ohrozenie sa zvažuje iba pre schémy šifrovania údajov s autentizáciou odosielateľa. Príklady takýchto schém sú uvedené v odporúčaniach na standardizáciu. . Pre ostatné kryptografické schémy toto ohrozenie neexistuje, pretože šifrovanie prebieha na verejných kľúčoch príjemcu, ktoré sú vo všeobecnosti známe útočníkom.
Dekonštrukcia
U2.1. Kompromitácia uzavretého kľúča odosielateľa:
U2.1.1. Odkaz: .
U2.2. Nahradenie vstupných údajov v kanáli výmeny verejných údajov.
Poznámky U2.2.
Príklady realizácie tohto ohrozenia sú uvedené nižšie. a .
U3. Dešifrovanie zašifrovaných údajov osobami, ktoré nie sú legitímnymi príjemcami údajov (útočníkmi).
Dekonštrukcia
U3.1. Kompromitácia uzavretých kľúčov príjemcu zašifrovaných údajov.
U3.1.1 Odkaz: .
U3.2. Nahradenie zašifrovaných údajov v kanáli výmeny chránených údajov.
U4. Vytvorenie elektronického podpisu legitímneho podpisovateľa pod falošnými údajmi.
Dekonštrukcia
U4.1. Kompromitácia uzavretých kľúčov elektronického podpisu legitímneho podpisovateľa.
U4.1.1 Odkaz: .
U4.2. Nahradenie podpisovaných údajov v kanáli výmeny verejných údajov.
Poznámka U4.2.
Príklady realizácie tohto ohrozenia sú uvedené nižšie. a .
U5. Získanie kladného výsledku kontroly elektronického podpisu falošných údajov.
Dekonštrukcia
U5.1. Útočníci zachytávajú v kanále prenosu výsledkov práce správu o negatívnom výsledku kontroly elektronického podpisu a nahrádzajú ju správou s pozitívnym výsledkom.
U5.2. Útočníci realizujú útok na dôveru k certifikátom podpisu (SCENÁR — všetky prvky sú povinné):
U5.2.1. Útočníci generujú verejný a súkromný kľúč elektronického podpisu. Ak sa v systéme používajú certifikáty kľúčov elektronického podpisu, generujú certifikát elektronického podpisu maximálne podobný certifikátu predpokladaného odosielateľa údajov, ktorého správu sa snažia falšovať.
U5.2.2. Útočníci vykonávajú neoprávnené zmeny v úložisku verejných kľúčov, pričom generovaný verejný kľúč obdarujú potrebnou úrovňou dôvery a právomocami.
U5.2.3. Útočníci podpisujú falošné údaje predtým vytvoreným kľúčom elektronického podpisu a zavádzajú ich do kanála výmeny chránených údajov.
U5.3. Útočníci realizujú útok pomocou uplynulých kľúčov elektronického podpisu legitímneho podpisovateľa (SCENÁR — všetky prvky sú povinné):
U5.3.1. Útočníci kompromitujú uplynulé (v súčasnosti neplatné) súkromné kľúče elektronického podpisu legitímneho odosielateľa.
U5.3.2. Útočníci nahrádzajú čas v kanále prenosu času časom, keď ich kompromitované kľúče ešte platili.
U5.3.3. Útočníci podpisujú falošné údaje predtým kompromitovaným kľúčom elektronického podpisu a zavádzajú ich do kanála výmeny chránených údajov.
U5.4. Útočníci realizujú útok pomocou skompromitovaných kľúčov elektronického podpisu legitímneho podpisovateľa (SCENÁR — všetky prvky sú povinné):
U5.4.1. Útočníci vytvárajú kópiu úložiska verejných kľúčov.
U5.4.2. Útočníci kompromitujú súkromné kľúče jedného z legálnych odosielateľov. Ten si všimne kompromitáciu, odvolá kľúče, informácie o odvolaní kľúča sú umiestnené v úložisku verejných kľúčov.
U5.4.3. Útočníci nahrádzajú úložisko verejných kľúčov predtým skopírovaným.
U5.4.4. Útočníci podpisujú falošné údaje predtým skompromitovaným kľúčom elektronického podpisu a zavádzajú ich do kanála výmeny chránených údajov.
U5.5. v dôsledku chýb pri realizácii 2. a 3. fázy overovania elektronického podpisu:
Vysvetlenia U5.5.
Príklad realizácie tejto hrozby je uvedený .
U5.5.1. Overenie dôvery k certifikátu kľúča elektronického podpisu len na základe existencie dôvery k certifikátu, ktorým bol podpísaný, bez overovania CRL alebo OCSP.
Vysvetlenia U5.5.1.
Príklad realizácie .
U5.5.2. Pri vytváraní reťazca dôvery k certifikátu sa neanalyzujú oprávnenia vydávajúcich certifikátov
Vysvetlenia U5.5.2.
Príklad útoku na SSL/TLS certifikáty.
Útočníci zakúpili legitímny certifikát pre svoju e-mailovú adresu. Potom vytvorili podvodný certifikát webovej stránky a podpísali ho svojim certifikátom. Ak sa overenie oprávnení nebude vykonávať, reťazec dôvery sa ukáže ako správny a podvodný certifikát taktiež bude považovaný za správny.
U5.5.3. Pri vytváraní reťazca dôvery k certifikátu sa neoverujú medzičlánkové certifikáty na zrušenie.
U5.5.4. Aktualizácia CRL prebieha menej často, ako ich vydáva certifikačná autorita.
U5.5.5. Rozhodnutie o dôvere k elektronickému podpisu sa prijíma skôr, než sa získa OCSP-odpoveď o stave certifikátu zaslané na žiadosť podanú po čase vytvorenia podpisu alebo skôr, než sa získa ďalšie CRL po vytvorení podpisu.
Vysvetlenia U5.5.5.
V reguláciách väčšiny CA je časom zrušenia certifikátu považovaný čas vydania najbližšieho CRL obsahujúceho informácie o zrušení certifikátu.
U5.5.6. Pri prijímaní podpísaných údajov sa neoveruje príslušnosť certifikátu odosielateľovi.
Vysvetlenia U5.5.6.
Príklad útoku. Pokiaľ ide o SSL certifikáty: nemusí sa overovať zhodnosť adresy volaného servera s hodnotou poľa CN v certifikáte.
Príklad útoku. Útočníci kompromitovali kľúče elektronického podpisu jedného z účastníkov platobného systému. Potom hackli sieť iného účastníka a jeho menom odoslali na vyúčtovací server platobného systému platobné dokumenty podpísané kompromitovanými kľúčmi. Ak server analyzuje len dôveru a neoveruje zhodnosť, podvodné dokumenty budú považované za legitímne.
U6. Chybné prijatie elektronických dokumentov na vykonanie v dôsledku problémov v organizácii elektronického dokumentového toku.
Dekonštrukcia
U6.1. Prijímajúca strana nezistí duplicitu prijímaných dokumentov.
Vysvetlenia U6.1.
Príklad útoku. Útočníci môžu zachytiť dokument, ktorý je zasielaný príjemcovi, aj keď je kryptograficky chránený, a následne ho mnohokrát poslať cez kanál prenosu chránených údajov. Ak príjemca nezistil duplicity, všetky prijaté dokumenty budú považované a spracované ako rôzne dokumenty.
U7. Neoprávnené oboznámenie sa s chránenými údajmi počas ich spracovania SKZI
Dekonštrukcia
U7.1. v dôsledku úniku informácií prostredníctvom bočných kanálov (side channel attack).
Vysvetlenie U7.1.
Príklad .
U7.2. v dôsledku neutralizácie ochrany proti neoprávnenému prístupu k informáciám spracovávaným na SKZI:
U7.2.1. Vykonávanie SKZI v rozpore s požiadavkami uvedenými v dokumentácii na SKZI.
U7.2.2. , vykonanej v dôsledku existencie zraniteľností v:
U7.2.2.1. prostriedkoch ochrany proti neoprávnenému prístupu.
U7.2.2.2. samotnej SKZI.
U7.2.2.3. prostredí fungovania kryptografického prostriedku.
Príklady útokov
Nižšie uvedené scenáre zámerne obsahujú chyby v organizácii informačnej bezpečnosti a slúžia len na ilustráciu možných útokov.
Scenár 1. Príklad realizácie hrozieb U2.2 a U4.2.
Popis objektu
PO ARM KBR a SKZI SKAD Sygantúra sú nainštalované na fyzickom počítači, ktorý nie je pripojený k výpočtovej sieti. Ako kľúčové nosiče sa používa FKN vdToken v režime práce s nevyťažiteľným kľúčom.
Reglement pre vykonanie výpočtov predpokladá, že špecialista na výpočty si z počítača stiahne elektronické správy v otvorenej forme (schéma starého ARM KBR) z osobitného chráneného súborového servera, potom ich zapíše na odnímateľné zariadenie USB a prenesie na ARM KBR, kde ich šifruje a podpisuje. Potom špecialista prenáša na odnímateľné zariadenie chránené elektronické správy a následne ich cez svoj pracovný počítač zapisuje na súborový server, odkiaľ sa dostávajú na UTA a ďalej do platobného systému Banky Ruska.
V tomto prípade kanály výmeny otvorených a chránených údajov budú obsahovať: súborový server, pracovný počítač špecialistu a odnímateľné úložisko.
Útok
Útočníci neautorizovane inštalujú na pracovný počítač odborníka systém vzdialeného riadenia a v momente zapisovania na odovzdávané nosiče platobných príkazov (elektronických správ) v otvorenom formáte zamieňajú obsah jedného z nich. Odborník prenáša platobné príkazy na APM KBR, podpisuje a šifruje ich, aniž by si všimol zámenu (napríklad kvôli veľkému počtu platobných príkazov v behu, únave a pod.). Potom sa falošný platobný príkaz, prechádzajúc technologickým reťazcom, dostáva do platobného systému Banky Ruska.
Scenár 2. Príklad realizácie hrozieb U2.2 a U4.2.
Popis objektu
Počítač s nainštalovanými APM KBR, SKAD Signature a pripojeným kľúčovým nosičom FKN vdToken funguje v vyhradenom priestore bez prístupu personálu.
Odborník na výpočty sa pripojuje k APM KBR v režime vzdialeného prístupu prostredníctvom protokolu RDP.
Útok
Útočníci zachytávajú údaje, pomocou ktorých odborník na výpočty realizuje pripojenie a prácu s APM KBR (napríklad prostredníctvom škodlivého kódu na jeho počítači). Potom sa pripoja jeho menom a zašlú do platobného systému Banky Ruska falošný platobný príkaz.
Scenár 3. Príklad realizácie hrozby U1.3.
Popis objektu
Zvážime jeden z hypotetických variantov realizácie integračných modulov "ABS-KBR" pre novú schému (APM KBR-N), pri ktorej sa elektronický podpis odchádzajúcich dokumentov uskutočňuje na strane ABS. Predpokladajme, že ABS funguje na báze operačného systému, ktorý nie je podporovaný SKZI SKAD Signature, a preto bol kryptografický funkčný systém presunutý na samostatnú virtuálnu stroj – integračný modul "ABS-KBR."
Ako kľúčový nosič sa používa bežný USB token, ktorý funguje v režime vyberateľného kľúča. Pri pripojení kľúčového nosiča k hypervízoru sa ukázalo, že v systéme nie sú voľné USB porty, preto sa rozhodlo pripojiť USB token cez sieťový USB hub a na virtuálnu stroj nainštalovať klienta USB-over-IP, ktorý bude realizovať spojenie s hubom.
Útok
Útočníci získali súkromný kľúč elektronického podpisu z komunikačného kanála medzi USB rozbočovačom a hypervízorom (údaje boli prenášané v otvorenej forme). So súkromným kľúčom útočníci vytvorili falošný platobný príkaz, podpísali ho elektronickým podpisom a poslali ho na vykonanie do AРM KБР-Н.
Scenár 4. Príklad realizácie hrozieb U5.5.
Popis objektu
Pozrime sa na tú istú schému ako v predchádzajúcom scenári. Predpokladajme, že elektronické správy prichádzajúce z AРM KБР-Н sa dostanú do priečinka …SHAREIn, a tie, ktoré sú odoslané do AРM KБР-Н a ďalej do platobného systému Banky Ruska, sa dostanú do …SHAREout.
Tiež predpokladajme, že pri realizácii integračného modulu sa zoznamy odobratých certifikátov aktualizujú iba pri opätovnom vydaní kryptografických kľúčov, a že elektronické správy, ktoré sa dostanú do priečinka …SHAREIn, sa kontrolujú len z hľadiska integrity a dôveryhodnosti otvoreného kľúča elektronického podpisu.
Útok
Útočníci, využívajúc ukradnuté kľúče z predchádzajúceho scenára, podpísali falošný platobný príkaz, ktorý obsahoval informácie o prijatí peňazí na účet podvodníka, a vložili ho do kanála výmeny chránených údajov. Keďže sa nekontroluje, či bol platobný príkaz podpísaný skutočne Bankou Ruska, prijíma sa na vykonanie.
Zdroj: habr.com
