Odkazy na ďalšie časti štúdie
- (Ste tu)
Tento článok dopĺňa sériu publikácií venovaných zaisteniu informačnej bezpečnosti bankových bezhotovostných platieb. Tu sa pozrieme na typické modely hrozieb uvedené v :
- .
- .
- .
- .
HABRO-VAROVANIE!!! Vážení Chabrovici, toto nie je zábavný príspevok.
Viac ako 40 strán materiálov skrytých pod strihom je určených na pomoc pri práci alebo štúdiu ľudí špecializujúcich sa na bankovníctvo alebo informačnú bezpečnosť. Tieto materiály sú konečným produktom výskumu a sú napísané suchým, formálnym tónom. V podstate ide o polotovary pre interné dokumenty informačnej bezpečnosti.No, tradičné - „použitie informácií z článku na nezákonné účely je trestné podľa zákona“. Produktívne čítanie!
Informácie pre čitateľov, ktorí sa zoznámia so štúdiou počnúc touto publikáciou.
O čom je štúdium?
Čítate príručku pre špecialistu zodpovedného za zabezpečenie informačnej bezpečnosti platieb v banke.
Logika prezentácie
Na začiatku v и je uvedený popis chráneného objektu. Potom v popisuje ako vybudovať bezpečnostný systém a hovorí o potrebe vytvorenia modelu hrozby. IN hovorí o tom, aké modely hrozieb existujú a ako sa vytvárajú. IN и Poskytuje sa analýza skutočných útokov. и obsahujú popis modelu hrozby zostaveného s prihliadnutím na informácie zo všetkých predchádzajúcich častí.
TYPICKÝ MODEL HROZBY. SIEŤOVÉ PRIPOJENIE
Objekt ochrany, pre ktorý sa aplikuje model hrozby (rozsah).
Predmetom ochrany sú dáta prenášané cez sieťové pripojenie fungujúce v dátových sieťach vybudovaných na báze TCP/IP stacku.
architektúra
Popis architektonických prvkov:
- "Koncové uzly" — uzly, ktoré si vymieňajú chránené informácie.
- "Medziľahlé uzly" — prvky siete na prenos údajov: smerovače, prepínače, prístupové servery, proxy servery a iné zariadenia, prostredníctvom ktorých sa prenáša prevádzka sieťového pripojenia. Vo všeobecnosti môže sieťové pripojenie fungovať bez medziľahlých uzlov (priamo medzi koncovými uzlami).
Bezpečnostné hrozby najvyššej úrovne
Rozklad
U1. Neoprávnený prístup k prenášaným údajom.
U2. Neoprávnená úprava prenášaných údajov.
U3. Porušenie autorstva prenášaných údajov.
U1. Neoprávnený prístup k prenášaným údajom
Rozklad
U1.1. <…>, ktoré sa vykonávajú v konečných alebo medziľahlých uzloch:
U1.1.1. <…> čítaním údajov, keď sú v hostiteľských úložných zariadeniach:
U1.1.1.1. <…> v pamäti RAM.
Vysvetlivky k U1.1.1.1.
Napríklad počas spracovania údajov sieťovým zásobníkom hostiteľa.
U1.1.1.2. <…> v energeticky nezávislej pamäti.
Vysvetlivky k U1.1.1.2.
Napríklad pri ukladaní prenášaných dát do vyrovnávacej pamäte, dočasných súborov alebo odkladacích súborov.
U1.2. <…>, vykonávané na uzloch dátovej siete tretích strán:
U1.2.1. <…> metódou zachytávania všetkých paketov prichádzajúcich na sieťové rozhranie hostiteľa:
Vysvetlivky k U1.2.1.
Zachytávanie všetkých paketov sa vykonáva prepnutím sieťovej karty do promiskuitného režimu (promiskuitný režim pre káblové adaptéry alebo režim monitora pre wi-fi adaptéry).
U1.2.2. <…> vykonaním útokov typu man-in-the-middle (MiTM), ale bez úpravy prenášaných dát (nepočítajúc dáta služby sieťového protokolu).
U1.2.2.1. odkaz: .
U1.3. <…>, vykonávané z dôvodu úniku informácií cez technické kanály (TKUI) z fyzických uzlov alebo komunikačných liniek.
U1.4. <…>, vykonávané inštaláciou špeciálnych technických prostriedkov (STS) na koncové alebo medziľahlé uzly, určené na tajný zber informácií.
U2. Neoprávnená úprava prenášaných údajov
Rozklad
U2.1. <…>, ktoré sa vykonávajú v konečných alebo medziľahlých uzloch:
U2.1.1. <…> čítaním a vykonávaním zmien údajov, kým sú v úložných zariadeniach uzlov:
U2.1.1.1. <…> v RAM:
U2.1.1.2. <…> v energeticky nezávislej pamäti:
U2.2. <…>, vykonávané na uzloch siete na prenos údajov tretích strán:
U2.2.1. <…> vykonávaním útokov typu man-in-the-middle (MiTM) a presmerovaním prevádzky do uzla útočníkov:
U2.2.1.1. Fyzické pripojenie zariadení útočníkov spôsobuje prerušenie sieťového pripojenia.
U2.2.1.2. Vykonávanie útokov na sieťové protokoly:
U2.2.1.2.1. <…> správa virtuálnych lokálnych sietí (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Neoprávnená úprava nastavení VLAN na prepínačoch alebo smerovačoch.
U2.2.1.2.2. <…> smerovanie premávky:
U2.2.1.2.2.1. Neoprávnená úprava statických smerovacích tabuliek smerovačov.
U2.2.1.2.2.2. Oznamovanie falošných trás útočníkmi prostredníctvom dynamických smerovacích protokolov.
U2.2.1.2.3. <…> automatická konfigurácia:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. <…> adresovanie a rozlíšenie názvu:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Neoprávnené zmeny v lokálnych súboroch názvov hostiteľov (hosts, lmhosts atď.)
U3. Porušenie autorských práv prenášaných údajov
Rozklad
U3.1. Neutralizácia mechanizmov na určenie autorstva informácií uvedením nepravdivých informácií o autorovi alebo zdroji údajov:
U3.1.1. Zmena informácií o autorovi obsiahnutých v prenášaných informáciách.
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 prenášaných údajov, realizovaná pomocou jednorazových potvrdzovacích kódov:
U3.1.1.2.1. .
U3.1.2. Zmena informácií o zdroji prenášaných informácií:
U3.1.2.1. .
U3.1.2.2. .
TYPICKÝ MODEL HROZBY. INFORMAČNÝ SYSTÉM POSTAVENÝ NA ZÁKLADE ARCHITEKTÚRY KLIENT-SERVER
Objekt ochrany, pre ktorý sa aplikuje model hrozby (rozsah).
Predmetom ochrany je informačný systém vybudovaný na báze architektúry klient-server.
architektúra
Popis architektonických prvkov:
- "Zákazník" – zariadenie, na ktorom funguje klientska časť informačného systému.
- "server" – zariadenie, na ktorom funguje serverová časť informačného systému.
- "Uloženie údajov" — časť serverovej infraštruktúry informačného systému určená na uchovávanie údajov spracovávaných informačným systémom.
- "Sieťové pripojenie" — kanál na výmenu informácií medzi Klientom a Serverom prechádzajúci dátovou sieťou. Podrobnejší popis modelu prvkov je uvedený v .
Obmedzenie
Pri modelovaní objektu sú nastavené nasledujúce obmedzenia:
- Používateľ interaguje s informačným systémom v rámci konečných časových úsekov, ktoré sa nazývajú pracovné relácie.
- Na začiatku každej pracovnej relácie je používateľ identifikovaný, overený a autorizovaný.
- Všetky chránené informácie sú uložené na serverovej časti informačného systému.
Bezpečnostné hrozby najvyššej úrovne
Rozklad
U1. Vykonávanie neoprávnených akcií útočníkmi v mene legitímneho používateľa.
U2. Neoprávnená zmena chránených informácií počas ich spracovania serverovou časťou informačného systému.
U1. Vykonávanie neoprávnených akcií útočníkmi v mene legitímneho používateľa
Vysvetlenie
Typicky v informačných systémoch akcie korelujú s používateľom, ktorý ich vykonal pomocou:
- denníky prevádzky systému (logy).
- špeciálne atribúty dátových objektov obsahujúce informácie o užívateľovi, ktorý ich vytvoril alebo upravil.
V súvislosti s pracovným stretnutím možno túto hrozbu rozložiť na:
- <…> vykonaná v rámci relácie používateľa.
- <…> vykonaný mimo relácie používateľa.
Reláciu používateľa možno spustiť:
- Samotným používateľom.
- Škodcovia.
V tomto štádiu bude prechodný rozklad tejto hrozby vyzerať takto:
U1.1. V rámci relácie používateľa boli vykonané neautorizované akcie:
U1.1.1. <…> nainštalovaný napadnutým používateľom.
U1.1.2. <…> nainštalovaný útočníkmi.
U1.2. Mimo relácie používateľa boli vykonané neoprávnené akcie.
Z pohľadu objektov informačnej infraštruktúry, ktoré môžu byť napadnuté útočníkmi, bude dekompozícia medziľahlých hrozieb vyzerať takto:
prvky
Rozklad hrozby
U1.1.1.
U1.1.2.
U1.2.
zákazník
U1.1.1.1.
U1.1.2.1.
Sieťové pripojenie
U1.1.1.2.
Server
U1.2.1.
Rozklad
U1.1. V rámci relácie používateľa boli vykonané neautorizované akcie:
U1.1.1. <…> nainštalovaný napadnutým používateľom:
U1.1.1.1. Útočníci konali nezávisle od klienta:
U1.1.1.1.1 Útočníci použili štandardné nástroje prístupu do informačného systému:
У1.1.1.1.1.1. Útočníci použili fyzické vstupné/výstupné prostriedky klienta (klávesnica, myš, monitor alebo dotyková obrazovka mobilného zariadenia):
U1.1.1.1.1.1.1. Útočníci operovali počas časových období, keď bola relácia aktívna, boli k dispozícii I/O zariadenia a používateľ nebol prítomný.
У1.1.1.1.1.2. Útočníci použili na kontrolu Klienta nástroje vzdialenej správy (štandardné alebo poskytované škodlivým kódom):
U1.1.1.1.1.2.1. Útočníci operovali počas časových období, keď bola relácia aktívna, boli k dispozícii I/O zariadenia a používateľ nebol prítomný.
У1.1.1.1.1.2.2. Útočníci použili nástroje vzdialenej správy, ktorých činnosť je pre napadnutého používateľa neviditeľná.
U1.1.1.2. Útočníci nahradili údaje v sieťovom spojení medzi Klientom a Serverom a upravili ich tak, aby to bolo vnímané ako konanie legitímneho používateľa:
U1.1.1.2.1. odkaz: .
U1.1.1.3. Útočníci prinútili používateľa vykonať akcie, ktoré určili pomocou metód sociálneho inžinierstva.
У1.1.2 <…> nainštalovaný útočníkmi:
U1.1.2.1. Útočníci konali od klienta (И):
U1.1.2.1.1. Útočníci zneškodnili prístupový systém informačného systému:
U1.1.2.1.1.1. odkaz: .
У1.1.2.1.2. Útočníci použili štandardné nástroje na prístup k informačnému systému
U1.1.2.2. Útočníci operovali z iných uzlov dátovej siete, z ktorých bolo možné nadviazať sieťové spojenie so Serverom (И):
U1.1.2.2.1. Útočníci zneškodnili prístupový systém 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 na prístup do informačného systému.
Vysvetlivky U1.1.2.2.2.
Útočníci by mohli nainštalovať štandardného klienta informačného systému na uzol tretej strany alebo mohli použiť neštandardný softvér, ktorý implementuje štandardné výmenné protokoly medzi Klientom a Serverom.
U1.2 Mimo relácie používateľa boli vykonané neoprávnené akcie.
U1.2.1 Útočníci vykonali neoprávnené akcie a následne vykonali neoprávnené zmeny v prevádzkových protokoloch informačného systému alebo špeciálnych atribútoch dátových objektov, čo naznačuje, že akcie, ktoré vykonali, vykonal legitímny používateľ.
U2. Neoprávnená zmena chránených informácií počas ich spracovania serverovou časťou informačného systému
Rozklad
U2.1. Útočníci upravujú chránené informácie pomocou štandardných nástrojov informačného systému a robia to v mene legitímneho používateľa.
U2.1.1. odkaz: .
U2.2. Útočníci upravujú chránené informácie pomocou mechanizmov prístupu k údajom, ktoré nie sú zabezpečené bežnou prevádzkou informačného systému.
U2.2.1. Útočníci upravujú súbory obsahujúce chránené informácie:
U2.2.1.1. <…> pomocou mechanizmov spracovania súborov poskytovaných operačným systémom.
U2.2.1.2. <…> vyvolaním obnovy súborov z neautorizovanej upravenej záložnej kópie.
U2.2.2. Útočníci upravujú chránené informácie uložené v databáze (И):
U2.2.2.1. Útočníci neutralizujú systém kontroly prístupu DBMS:
U2.2.2.1.1. odkaz: .
U2.2.2.2. Útočníci upravujú informácie pomocou štandardných rozhraní DBMS na prístup k údajom.
U2.3. Útočníci upravujú chránené informácie neoprávnenou úpravou operačných algoritmov softvéru, ktorý ich spracováva.
U2.3.1. Zdrojový kód softvéru podlieha zmenám.
U2.3.1. Strojový kód softvéru podlieha zmenám.
U2.4. Útočníci upravujú chránené informácie využívaním zraniteľností v softvéri informačného systému.
U2.5. Útočníci upravujú chránené informácie pri ich prenose medzi komponentmi serverovej časti informačného systému (napríklad databázový server a aplikačný server):
U2.5.1. odkaz: .
TYPICKÝ MODEL HROZBY. SYSTÉM KONTROLY PRÍSTUPU
Objekt ochrany, pre ktorý sa aplikuje model hrozby (rozsah).
Objekt ochrany, pre ktorý sa tento model hrozby aplikuje, zodpovedá objektu ochrany modelu hrozby: „Typický model hrozby. Informačný systém postavený na architektúre klient-server.“
V tomto modeli hrozby systém riadenia prístupu používateľov znamená komponent informačného systému, ktorý implementuje nasledujúce funkcie:
- Identifikácia užívateľa.
- Overenie používateľa.
- Používateľské oprávnenia.
- Zaznamenávanie akcií používateľa.
Bezpečnostné hrozby najvyššej úrovne
Rozklad
U1. Neoprávnené vytvorenie relácie v mene legitímneho používateľa.
U2. Neoprávnené zvýšenie užívateľských práv v informačnom systéme.
U1. Neoprávnené vytvorenie relácie v mene legitímneho používateľa
Vysvetlenie
Rozklad tejto hrozby bude vo všeobecnosti závisieť od typu použitých systémov identifikácie a autentifikácie používateľov.
V tomto modeli sa bude brať do úvahy iba systém identifikácie a autentifikácie používateľa pomocou textového prihlasovacieho mena a hesla. V tomto prípade budeme predpokladať, že prihlásenie používateľa je verejne dostupná informácia, ktorú útočníci poznajú.
Rozklad
U1.1. <…> z dôvodu ohrozenia poverení:
U1.1.1. Útočníci kompromitovali prihlasovacie údaje používateľa pri ich ukladaní.
Vysvetlivky U1.1.1.
Poverenia môžu byť napríklad napísané na lepiacu poznámku prilepenú k monitoru.
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ľ pri vstupe vyslovil prihlasovacie údaje nahlas.
U1.1.2.2. Používateľ úmyselne zdieľal svoje poverenia:
U1.1.2.2.1. <…> kolegom z práce.
Vysvetlivky U1.1.2.2.1.
Napríklad, aby si ho mohli nahradiť počas choroby.
U1.1.2.2.2. <…> dodávateľom zamestnávateľa vykonávajúcim práce na objektoch informačnej infraštruktúry.
U1.1.2.2.3. <…> tretím stranám.
Vysvetlivky U1.1.2.2.3.
Jednou, no nie jedinou možnosťou implementácie tejto hrozby je využitie metód sociálneho inžinierstva útočníkmi.
U1.1.3. Útočníci vybrali poverenia pomocou metód hrubej sily:
U1.1.3.1. <…> pomocou štandardných prístupových mechanizmov.
U1.1.3.2. <…> pomocou predtým zachytených kódov (napríklad hash hesiel) na ukladanie poverení.
U1.1.4. Útočníci použili škodlivý kód na zachytenie prihlasovacích údajov používateľov.
U1.1.5. Útočníci extrahovali poverenia zo sieťového pripojenia medzi klientom a serverom:
U1.1.5.1. odkaz: .
U1.1.6. Útočníci získali poverenia zo záznamov systémov monitorovania práce:
U1.1.6.1. <…> video monitorovacie systémy (ak boli počas prevádzky zaznamenané stlačenia klávesov na klávesnici).
U1.1.6.2. <…> systémy na monitorovanie akcií zamestnancov na počítači
Vysvetlivky U1.1.6.2.
Príkladom takéhoto systému je .
U1.1.7. Útočníci kompromitovali prihlasovacie údaje používateľa kvôli chybám v procese prenosu.
Vysvetlivky U1.1.7.
Napríklad posielanie hesiel vo forme čistého textu prostredníctvom e-mailu.
U1.1.8. Útočníci získali poverenia monitorovaním relácie používateľa pomocou systémov vzdialenej správy.
U1.1.9. Útočníci získali poverenia v dôsledku úniku cez technické kanály (TCUI):
U1.1.9.1. Útočníci pozorovali, ako používateľ zadával poverenia z klávesnice:
U1.1.9.1.1 Útočníci sa nachádzali v tesnej blízkosti používateľa a na vlastné oči videli zadávanie prihlasovacích údajov.
Vysvetlivky U1.1.9.1.1
Takéto prípady zahŕňajú akcie kolegov v práci alebo prípad, keď je klávesnica používateľa viditeľná pre návštevníkov organizácie.
U1.1.9.1.2 Útočníci použili dodatočné technické prostriedky, ako napríklad ďalekohľad alebo bezpilotné lietadlo, a cez okno videli vstup poverení.
U1.1.9.2. Útočníci získali poverenia z rádiovej komunikácie medzi klávesnicou a počítačovou systémovou jednotkou, keď boli pripojení cez rádiové rozhranie (napríklad Bluetooth).
U1.1.9.3. Útočníci zachytili poverenia ich únikom cez kanál falošného elektromagnetického žiarenia a rušenia (PEMIN).
Vysvetlivky U1.1.9.3.
Príklady útokov и .
U1.1.9.4. Útočník zachytil zadávanie prihlasovacích údajov z klávesnice pomocou špeciálnych technických prostriedkov (STS) určených na tajné získavanie informácií.
Vysvetlivky U1.1.9.4.
príklady .
U1.1.9.5. Útočníci zachytili zadávanie poverení z klávesnice pomocou
analýza signálu Wi-Fi modulovaného procesom stlačenia klávesu používateľom.
Vysvetlivky U1.1.9.5.
Príklad .
U1.1.9.6. Útočníci zachytili zadávanie prihlasovacích údajov z klávesnice analyzovaním zvukov stlačenia klávesov.
Vysvetlivky 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 hodnôt akcelerometra.
Vysvetlivky U1.1.9.7.
Príklad .
U1.1.10. <…>, ktoré boli predtým uložené v Klientovi.
Vysvetlivky U1.1.10.
Používateľ si môže napríklad uložiť prihlasovacie meno a heslo do prehliadača na prístup na konkrétnu stránku.
U1.1.11. Útočníci kompromitovali prihlasovacie údaje kvôli chybám v procese odvolania prístupu používateľov.
Vysvetlivky U1.1.11.
Napríklad po prepustení používateľa zostali jeho účty odblokované.
U1.2. <…> využívaním zraniteľností v systéme kontroly prístupu.
U2. Neoprávnené zvýšenie užívateľských práv v informačnom systéme
Rozklad
U2.1 <…> vykonaním neoprávnených zmien údajov obsahujúcich informácie o používateľských právach.
U2.2 <…> prostredníctvom používania zraniteľností v systéme kontroly prístupu.
U2.3. <…> z dôvodu nedostatkov v procese riadenia prístupu používateľov.
Vysvetlivky U2.3.
Príklad 1. Používateľovi bol poskytnutý väčší prístup k práci, ako potreboval z obchodných dôvodov.
Príklad 2: Po presunutí používateľa na inú pozíciu neboli predtým udelené prístupové práva odvolané.
TYPICKÝ MODEL HROZBY. INTEGRAČNÝ MODUL
Objekt ochrany, pre ktorý sa aplikuje model hrozby (rozsah).
Integračný modul je súbor objektov informačnej infraštruktúry určených na organizovanie výmeny informácií medzi informačnými systémami.
Vzhľadom na to, že v podnikových sieťach nie je vždy možné jednoznačne oddeliť jeden informačný systém od druhého, možno integračný modul považovať aj za spojovací článok medzi komponentmi v rámci jedného informačného systému.
architektúra
Zovšeobecnený diagram integračného modulu vyzerá takto:
Popis architektonických prvkov:
- "Exchange Server (SO)" – uzol / služba / komponent informačného systému, ktorý plní funkciu výmeny údajov s iným informačným systémom.
- "mediátor" – uzol/služba určená na organizovanie interakcie medzi informačnými systémami, ale nie ich súčasťou.
Podľa príkladov "sprostredkovatelia" môžu existovať e-mailové služby, podnikové servisné zbernice (podniková servisná zbernica / architektúra SoA), súborové servery tretích strán atď. Integračný modul vo všeobecnosti nemusí obsahovať „Sprostredkovatelia“. - "Softvér na spracovanie údajov" – súbor programov, ktoré implementujú protokoly výmeny údajov a konverziu formátu.
Napríklad prevod dát z formátu UFEBS do formátu ABS, zmena stavov správ počas prenosu atď. - "Sieťové pripojenie" zodpovedá objektu opísanému v štandardnom modeli hrozby „Sieťové pripojenie“. Niektoré sieťové pripojenia zobrazené na obrázku vyššie nemusia existovať.
Príklady integračných modulov
Schéma 1. Integrácia ABS a AWS KBR cez súborový server tretej strany
Na realizáciu platieb si poverený pracovník banky stiahne elektronické platobné doklady z hlavného bankového systému a uloží ich do súboru (vo vlastnom formáte, napr. SQL dump) v sieťovom priečinku (...SHARE) na súborovom serveri. Potom sa tento súbor skonvertuje pomocou skriptu prevodníka na súbor súborov vo formáte UFEBS, ktoré potom načíta pracovná stanica CBD.
Potom poverený zamestnanec - používateľ automatizovaného pracoviska KBR - zašifruje a podpíše prijaté súbory a odošle ich do platobného systému Bank of Russia.
Keď sú platby prijaté z Bank of Russia, automatizované pracovisko KBR ich dešifruje a skontroluje elektronický podpis, potom ich zaznamená vo forme súboru súborov vo formáte UFEBS na súborový server. Pred importovaním platobných dokladov do ABS sú tieto konvertované pomocou konvertorového skriptu z formátu UFEBS do formátu ABS.
Budeme predpokladať, že v tejto schéme ABS pracuje na jednom fyzickom serveri, pracovná stanica KBR pracuje na vyhradenom počítači a skript prevodníka beží na súborovom serveri.
Zhoda objektov uvažovaného diagramu s prvkami modelu integračného modulu:
“Výmenný server zo strany ABS” - ABS server.
„Výmenný server zo strany AWS KBR“ – počítačová pracovná stanica KBR.
"mediátor" – súborový server tretej strany.
"Softvér na spracovanie údajov" – skript prevodníka.
Schéma 2. Integrácia ABS a AWS KBR pri umiestnení zdieľaného sieťového priečinka s platbami na AWS KBR
Všetko je podobné ako v schéme 1, ale nepoužíva sa samostatný súborový server, namiesto toho je na počítači s pracovnou stanicou CBD umiestnený sieťový priečinok (...SHARE) s elektronickými platobnými dokladmi. Skript prevodníka funguje aj na pracovnej stanici CBD.
Zhoda objektov uvažovaného diagramu s prvkami modelu integračného modulu:
Podobne ako v schéme 1, ale "mediátor" nepoužité.
Schéma 3. Integrácia ABS a automatizovaného pracoviska KBR-N cez IBM WebSphera MQ a podpisovanie elektronických dokumentov „na strane ABS“
ABS funguje na platforme, ktorá nie je podporovaná CIPF SCAD Signature. Podpisovanie odchádzajúcich elektronických dokumentov sa vykonáva na špeciálnom serveri pre elektronický podpis (ES Server). Ten istý server kontroluje elektronický podpis na dokumentoch prichádzajúcich z Bank of Russia.
ABS nahrá súbor s platobnými dokladmi vo vlastnom formáte na ES Server.
Server ES pomocou skriptu prevodníka skonvertuje súbor na elektronické správy vo formáte UFEBS, potom sa elektronické správy podpíšu a prenesú do IBM WebSphere MQ.
Pracovná stanica KBR-N pristupuje k IBM WebSphere MQ a prijíma odtiaľ podpísané platobné správy, po ktorých ich oprávnený zamestnanec – používateľ pracovnej stanice KBR – zašifruje a odošle do platobného systému Ruskej banky.
Keď sú platby prijaté z Bank of Russia, automatizované pracovisko KBR-N ich dešifruje a overí elektronický podpis. Úspešne spracované platby vo forme dešifrovaných a podpísaných elektronických správ vo formáte UFEBS sa prenášajú do IBM WebSphere MQ, odkiaľ ich prijíma server elektronického podpisu.
Server elektronického podpisu overí elektronický podpis prijatých platieb a uloží ich do súboru vo formáte ABS. Po tomto poverený zamestnanec - užívateľ ABS - nahrá výsledný súbor predpísaným spôsobom do ABS.
Zhoda objektov uvažovaného diagramu s prvkami modelu integračného modulu:
“Výmenný server zo strany ABS” - ABS server.
„Výmenný server zo strany AWS KBR“ — počítačová pracovná stanica KBR.
"mediátor" – ES server a IBM WebSphere MQ.
"Softvér na spracovanie údajov" – konvertor skriptov, podpis CIPF SCAD na ES Serveri.
Schéma 4. Integrácia servera RBS a základného bankového systému prostredníctvom API, ktoré poskytuje dedikovaný výmenný server
Budeme predpokladať, že banka používa niekoľko vzdialených bankových systémov (RBS):
- "Internetový klient-Banka" pre fyzické osoby (IKB FL);
- „Internetový klient-Banka“ pre právnické osoby (IKB LE).
V záujme zabezpečenia informačnej bezpečnosti sa všetka interakcia medzi ABS a vzdialenými bankovými systémami uskutočňuje prostredníctvom dedikovaného výmenného servera fungujúceho v rámci informačného systému ABS.
Ďalej zvážime proces interakcie medzi systémom RBS IKB LE a ABS.
Server RBS po prijatí riadne overeného platobného príkazu od klienta musí na jeho základe vytvoriť zodpovedajúci dokument v ABS. Na tento účel pomocou rozhrania API prenáša informácie na server výmeny, ktorý zase vkladá údaje do ABS.
Pri zmene zostatkov na účte klienta ABS generuje elektronické notifikácie, ktoré sa prenášajú na vzdialený bankový server pomocou výmenného servera.
Zhoda objektov uvažovaného diagramu s prvkami modelu integračného modulu:
„Výmenný server zo strany RBS“ – server RBS IKB YUL.
“Výmenný server zo strany ABS” - výmenný server.
"mediátor" - neprítomný.
"Softvér na spracovanie údajov" – Komponenty servera RBS zodpovedné za používanie rozhrania API servera Exchange, komponenty servera Exchange zodpovedné za používanie rozhrania API základného bankovníctva.
Bezpečnostné hrozby najvyššej úrovne
Rozklad
U1. Vloženie nepravdivých informácií útočníkmi prostredníctvom integračného modulu.
U1. Vloženie nepravdivých informácií útočníkmi prostredníctvom integračného modulu
Rozklad
U1.1. Neoprávnená úprava legitímnych údajov pri prenose cez sieťové pripojenia:
Odkaz na U1.1.1: .
U1.2. Prenos nepravdivých údajov prostredníctvom komunikačných kanálov v mene legitímneho účastníka výmeny:
Odkaz na U1.1.2: .
U1.3. Neoprávnená úprava legitímnych údajov počas ich spracovania na Exchange serveroch alebo Sprostredkovateľovi:
U1.3.1. odkaz: .
U1.4. Vytváranie nepravdivých údajov na Exchange serveroch alebo Sprostredkovateľovi v mene legitímneho účastníka burzy:
U1.4.1. odkaz:
U1.5. Neoprávnená úprava údajov pri spracovaní pomocou softvéru na spracovanie údajov:
U1.5.1. <…> v dôsledku neoprávnených zmien nastavení (konfigurácie) softvéru na spracovanie údajov zo strany útočníkov.
U1.5.2. <…> kvôli útočníkom, ktorí neoprávnene upravujú spustiteľné súbory softvéru na spracovanie údajov.
U1.5.3. <…> vďaka interaktívnemu ovládaniu softvéru na spracovanie údajov útočníkmi.
TYPICKÝ MODEL HROZBY. SYSTÉM OCHRANY KRYPTOGRAFICKÝCH INFORMÁCIÍ
Objekt ochrany, pre ktorý sa aplikuje model hrozby (rozsah).
Predmetom ochrany je kryptografický systém ochrany informácií slúžiaci na zabezpečenie bezpečnosti informačného systému.
architektúra
Základom každého informačného systému je aplikačný softvér, ktorý implementuje jeho cieľovú funkcionalitu.
Kryptografická ochrana sa zvyčajne realizuje volaním kryptografických primitív z obchodnej logiky aplikačného softvéru, ktoré sa nachádzajú v špecializovaných knižniciach – kryptojadrách.
Kryptografické primitíva zahŕňajú nízkoúrovňové kryptografické funkcie, ako napríklad:
- šifrovať/dešifrovať blok údajov;
- vytvoriť/overiť elektronický podpis bloku údajov;
- vypočítať hašovaciu funkciu dátového bloku;
- generovať / načítať / odovzdať kľúčové informácie;
- atď
Obchodná logika aplikačného softvéru implementuje funkčnosť vyššej úrovne pomocou kryptografických primitív:
- zašifrovať súbor pomocou kľúčov vybraných príjemcov;
- vytvoriť bezpečné sieťové pripojenie;
- informovať o výsledkoch kontroly elektronického podpisu;
- a tak ďalej.
Interakciu obchodnej logiky a kryptojadra je možné uskutočniť:
- priamo, pomocou obchodnej logiky volaním kryptografických primitív z dynamických knižníc kryptojadra (.DLL pre Windows, .SO pre Linux);
- priamo, prostredníctvom kryptografických rozhraní - wrapperov, napr. tento prípad sa nazýva poskytovateľ kryptomien. Použitie kryptografických rozhraní umožňuje aplikačnému softvéru abstrahovať od špecifických kryptografických algoritmov a byť flexibilnejší.
Existujú dve typické schémy organizácie kryptojadra:
Schéma 1 – Monolitické krypto jadro
Schéma 2 – Rozdelené krypto jadro
Prvky vo vyššie uvedených diagramoch môžu byť buď jednotlivé softvérové moduly bežiace na jednom počítači alebo sieťové služby interagujúce v rámci počítačovej siete.
Pri použití systémov vytvorených podľa schémy 1 aplikačný softvér a kryptografické jadro fungujú v rámci jedného operačného prostredia pre kryptografický nástroj (SFC), napríklad na rovnakom počítači s rovnakým operačným systémom. Používateľ systému môže spravidla v tom istom operačnom prostredí spúšťať iné programy, vrátane tých, ktoré obsahujú škodlivý kód. Za takýchto podmienok existuje vážne riziko úniku súkromných kryptografických kľúčov.
Na minimalizáciu rizika sa používa schéma 2, v ktorej je krypto jadro rozdelené na dve časti:
- Prvá časť spolu s aplikačným softvérom funguje v nedôveryhodnom prostredí, kde hrozí infikovanie š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 úložisko súkromných kľúčov. Odteraz budeme túto časť nazývať „hardvér“.
Rozdelenie kryptojadra na softvérovú a hardvérovú časť je veľmi ľubovoľné. Na trhu sú systémy postavené podľa schémy s rozdeleným kryptografickým jadrom, ktorých „hardvérová“ časť je však prezentovaná vo forme obrazu virtuálneho stroja – virtuálneho HSM ().
Interakcia oboch častí kryptojadra prebieha tak, že súkromné kryptografické kľúče sa nikdy neprenesú do softvérovej časti, a teda nemôžu byť odcudzené pomocou škodlivého kódu.
Interakčné rozhranie (API) a súbor kryptografických primitív poskytovaných aplikačnému softvéru kryptografickým jadrom sú v oboch prípadoch rovnaké. Rozdiel spočíva v spôsobe ich implementácie.
Pri použití schémy s rozdeleným kryptografickým jadrom sa teda interakcia softvéru a hardvéru uskutočňuje podľa nasledujúceho princípu:
- Kryptografické primitívy, ktoré nevyžadujú použitie súkromného kľúča (napríklad výpočet hašovacej funkcie, overenie elektronického podpisu atď.), vykonáva softvér.
- Kryptografické primitívy, ktoré využívajú súkromný kľúč (vytváranie elektronického podpisu, dešifrovanie dát a pod.), sú vykonávané hardvérom.
Ukážme si fungovanie rozdeleného kryptojadra na príklade vytvorenia elektronického podpisu:
- Softvérová časť vypočítava hašovaciu funkciu podpísaných dát a prenáša túto hodnotu do hardvéru cez výmenný kanál medzi kryptojadrami.
- Hardvérová časť pomocou súkromného kľúča a hashu generuje hodnotu elektronického podpisu a prenáša ju do softvérovej časti výmenným kanálom.
- Softvérová časť vráti prijatú hodnotu do aplikačného softvéru.
Funkcie kontroly správnosti elektronického podpisu
Keď prijímajúca strana dostane elektronicky podpísané údaje, musí vykonať niekoľko overovacích krokov. Pozitívny výsledok kontroly elektronického podpisu sa dosiahne iba vtedy, ak sú úspešne ukončené všetky fázy overovania.
Fáza 1. Kontrola integrity údajov a autorstvo údajov.
Obsah javiska. Elektronický podpis údajov je overený pomocou príslušného kryptografického algoritmu. Úspešné ukončenie tejto etapy znamená, že údaje neboli zmenené od momentu ich podpisu a tiež, že podpis bol vykonaný súkromným kľúčom zodpovedajúcim verejnému kľúču na overenie elektronického podpisu.
Umiestnenie javiska: krypto jadro.
Fáza 2. Kontrola dôvery vo verejný kľúč podpisovateľa a kontrola doby platnosti súkromného kľúča elektronického podpisu.
Obsah javiska. Etapa pozostáva z dvoch medzistupňov. Prvým je zistenie, či bol verejný kľúč na overenie elektronického podpisu v čase podpisovania údajov dôveryhodný. Druhý určuje, či bol súkromný kľúč elektronického podpisu platný v čase podpisu údajov. Vo všeobecnosti sa doby platnosti týchto kľúčov nemusia zhodovať (napríklad pri kvalifikovaných certifikátoch kľúčov na overovanie elektronického podpisu). Metódy na vytvorenie dôvery vo verejný kľúč signatára sú určené pravidlami správy elektronických dokumentov, ktoré prijali zúčastnené strany.
Umiestnenie javiska: aplikačný softvér / kryptografické jadro.
Fáza 3. Kontrola autority signatára.
Obsah javiska. V súlade so stanovenými pravidlami správy elektronických dokumentov sa kontroluje, či signatár mal právo na certifikáciu chránených údajov. Ako príklad uveďme situáciu porušenia autority. Predpokladajme, že existuje organizácia, kde majú všetci zamestnanci elektronický podpis. Interný elektronický systém správy dokumentov dostane objednávku od vedúceho, avšak podpísanú elektronickým podpisom vedúceho skladu. Preto takýto dokument nemožno považovať za legitímny.
Umiestnenie javiska: aplikačný softvér.
Predpoklady urobené pri popise predmetu ochrany
- Kanály prenosu informácií, s výnimkou kanálov na výmenu kľúčov, prechádzajú aj cez aplikačný softvér, API a kryptografické jadro.
- Informácie o dôvere vo verejné kľúče a (alebo) certifikáty, ako aj informácie o právomociach vlastníkov verejných kľúčov, sú umiestnené v úložisku verejných kľúčov.
- Aplikačný softvér spolupracuje s úložiskom verejných kľúčov prostredníctvom kryptojadra.
Príklad informačného systému chráneného pomocou CIPF
Na ilustráciu vyššie uvedených diagramov uvažujme hypotetický informačný systém a zvýraznite na ňom všetky štrukturálne prvky.
Popis informačného systému
Obe organizácie sa rozhodli zaviesť medzi sebou právne významnú správu elektronických dokumentov (EDF). Za týmto účelom uzavreli zmluvu, v ktorej si stanovili, že dokumenty sa budú posielať emailom a zároveň musia byť zašifrované a podpísané kvalifikovaným elektronickým podpisom. Ako nástroje na vytváranie a spracovanie dokumentov by mali slúžiť kancelárske programy z balíka Microsoft Office 2016 a ako prostriedky kryptografickej ochrany CIPF CryptoPRO a šifrovací softvér CryptoARM.
Popis infraštruktúry organizácie 1
Organizácia 1 sa rozhodla, že nainštaluje softvér CIPF CryptoPRO a CryptoARM na pracovnú stanicu používateľa – fyzický počítač. Šifrovacie kľúče a kľúče elektronického podpisu budú uložené na kľúčovom médiu ruToken, ktoré bude fungovať v režime obnovenia kľúča. Používateľ si pripraví elektronické dokumenty lokálne na svojom počítači, následne ich zašifruje, podpíše a odoš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álny stroj. V tomto prípade sa všetky kryptografické operácie vykonajú automaticky.
Na tento účel sú na vyhradenom virtuálnom stroji usporiadané dva sieťové priečinky: „...In“, „...Out“. Súbory prijaté od protistrany v otvorenej forme budú automaticky umiestnené do sieťového priečinka „…In“. Tieto súbory budú dešifrované a elektronický podpis bude overený.
Používateľ umiestni do priečinka „...Out“ súbory, ktoré je potrebné zašifrovať, podpísať a odoslať protistrane. Súbory si užívateľ pripraví sám na svojej pracovnej stanici.
Na vykonávanie funkcií šifrovania a elektronického podpisu sú na virtuálnom počítači nainštalované CIPF CryptoPRO, softvér CryptoARM a e-mailový klient. Automatická správa všetkých prvkov virtuálneho stroja sa bude vykonávať pomocou skriptov vyvinutých správcami systému. Práca skriptov sa zaznamenáva do log súborov.
Kryptografické kľúče pre elektronický podpis budú umiestnené na tokene s nestiahnuteľným kľúčom JaCarta GOST, ktorý si používateľ pripojí k svojmu lokálnemu počítaču.
Token bude odovzdaný virtuálnemu stroju pomocou špecializovaného softvéru USB-over-IP nainštalovaného na pracovnej stanici používateľa a na virtuálnom stroji.
Systémové hodiny na pracovnej stanici používateľa v organizácii 1 sa nastavia manuálne. Systémové hodiny vyhradeného virtuálneho stroja v organizácii 2 budú synchronizované so systémovými hodinami hypervízora, ktoré budú zase synchronizované cez internet s verejnými časovými servermi.
Identifikácia konštrukčných prvkov CIPF
Na základe uvedeného popisu IT infraštruktúry zvýrazníme štrukturálne prvky CIPF a zapíšeme ich do tabuľky.
Tabuľka - Korešpondencia prvkov modelu CIPF s prvkami informačného systému
Názov položky
Organizácia 1
Organizácia 2
Aplikačný softvér
Softvér CryptoARM
Softvér CryptoARM
Softvérová časť jadra kryptomien
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Hardvér kryptojadra
nie
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Úložisko verejného kľúča
Pracovná stanica používateľa:
- HDD;
- štandardné úložisko certifikátov Windows.
Hypervízor:
- HDD.
Virtuálny prístroj:
- HDD;
- štandardné úložisko certifikátov Windows.
Úložisko súkromných kľúčov
Nosič kľúčov ruToken pracujúci v režime s možnosťou získania kľúča
Nosič kľúčov JaCarta GOST pracujúci v režime nevyberateľného kľúča
Kanál na výmenu verejných kľúčov
Pracovná stanica používateľa:
- RAM.
Hypervízor:
- RAM.
Virtuálny prístroj:
- RAM.
Kanál výmeny súkromných kľúčov
Pracovná stanica používateľa:
— USB zbernica;
- RAM.
nie
Výmenný kanál medzi kryptojadrami
chýba (žiadny kryptografický hardvér)
Pracovná stanica používateľa:
— USB zbernica;
- RAM;
— USB-over-IP softvérový modul;
- sieťové rozhranie.
Firemná sieť organizácie 2.
Hypervízor:
- RAM;
- sieťové rozhranie.
Virtuálny prístroj:
— sieťové rozhranie;
- RAM;
— USB-over-IP softvérový modul.
Otvorte dátový kanál
Pracovná stanica používateľa:
— vstupno-výstupné prostriedky;
- RAM;
- HDD.
Pracovná stanica používateľa:
— vstupno-výstupné prostriedky;
- RAM;
- HDD;
- sieťové rozhranie.
Firemná sieť organizácie 2.
Hypervízor:
— sieťové rozhranie;
- RAM;
- HDD.
Virtuálny prístroj:
— sieťové rozhranie;
- RAM;
- HDD.
Bezpečný kanál na výmenu údajov
Internet.
Firemná sieť organizácie 1.
Pracovná stanica používateľa:
- HDD;
- RAM;
- sieťové rozhranie.
Internet.
Firemná sieť organizácie 2.
Hypervízor:
— sieťové rozhranie;
- RAM;
- HDD.
Virtuálny prístroj:
— sieťové rozhranie;
- RAM;
- HDD.
Časový kanál
Pracovná stanica používateľa:
— vstupno-výstupné prostriedky;
- RAM;
- systémový časovač.
Internet.
Firemná sieť organizácie 2,
Hypervízor:
— sieťové rozhranie;
- RAM;
- systémový časovač.
Virtuálny prístroj:
- RAM;
- systémový časovač.
Prenosový kanál riadiaceho príkazu
Pracovná stanica používateľa:
— vstupno-výstupné prostriedky;
- RAM.
(Grafické používateľské rozhranie softvéru CryptoARM)
Virtuálny prístroj:
- RAM;
- HDD.
(automatizačné skripty)
Kanál na prijímanie pracovných výsledkov
Pracovná stanica používateľa:
— vstupno-výstupné prostriedky;
- RAM.
(Grafické používateľské rozhranie softvéru CryptoARM)
Virtuálny prístroj:
- RAM;
- HDD.
(Súbory denníka automatizačných skriptov)
Bezpečnostné hrozby najvyššej úrovne
Vysvetlenie
Predpoklady prijaté pri rozklade hrozieb:
- Používajú sa silné kryptografické algoritmy.
- Kryptografické algoritmy sa používajú bezpečne v správnych prevádzkových režimoch (napr. sa nepoužíva na šifrovanie veľkých objemov dát, berie sa do úvahy prípustné zaťaženie kľúča a pod.).
- Útočníci poznajú všetky použité algoritmy, protokoly a verejné kľúče.
- Útočníci môžu čítať všetky zašifrované údaje.
- Útočníci sú schopní reprodukovať akékoľvek softvérové prvky v systéme.
Rozklad
U1. Kompromis súkromných kryptografických kľúčov.
U2. Šifrovanie falošných údajov v mene legitímneho odosielateľa.
U3. Dešifrovanie zašifrovaných údajov osobami, ktoré nie sú legitímnymi príjemcami údajov (útočníci).
U 4. Vytvorenie elektronického podpisu oprávnenej osoby pod falošnými údajmi.
U5. Získanie pozitívneho výsledku z kontroly elektronického podpisu sfalšovaných údajov.
TY 6. Chybné prijatie elektronických dokumentov na vykonanie v dôsledku problémov s organizáciou toku elektronických dokumentov.
U7. Neoprávnený prístup k chráneným údajom počas ich spracovania CIPF.
U1. Kompromis 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 v operačnom prostredí kryptonástroja, v ktorom sa môže dočasne nachádzať.
Vysvetlivky U1.2.
Medzi objekty, ktoré môžu dočasne uložiť súkromný kľúč, patria:
- RAM,
- dočasné súbory,
- výmena súborov,
- hibernačné súbory,
- súbory snímok „horúceho“ stavu virtuálnych strojov vrátane súborov obsahu pamäte RAM pozastavených virtuálnych strojov.
U1.2.1. Extrahovanie súkromných kľúčov z pracovnej pamäte RAM zmrazením modulov RAM, ich odstránením a následným prečítaním údajov (útok zmrazením).
Vysvetlivky U1.2.1.
Príklad .
U1.3. Získanie súkromného kľúča z kanála na výmenu súkromných kľúčov.
Vysvetlivky U1.3.
Uvedie sa príklad implementácie tejto hrozby .
U1.4. Neoprávnená úprava kryptojadra, v dôsledku ktorej sa súkromné kľúče stanú známymi útočníkom.
U1.5. Kompromitácia súkromného kľúča v dôsledku použitia kanálov úniku technických informácií (TCIL).
Vysvetlivky U1.5.
Príklad .
U1.6. Kompromitácia súkromného kľúča v dôsledku použitia špeciálnych technických prostriedkov (STS) určených na tajné získavanie informácií („chyby“).
U1.7. Kompromitácia súkromných kľúčov počas ich uchovávania mimo CIPF.
Vysvetlivky U1.7.
Používateľ napríklad ukladá svoje kľúčové médiá do zásuvky na pracovnej ploche, z ktorej ich útočníci môžu ľahko získať.
U2. Šifrovanie falošných údajov v mene legitímneho odosielateľa
Vysvetlenie
Táto hrozba sa berie do úvahy iba pri schémach šifrovania údajov s overením odosielateľa. Príklady takýchto schém sú uvedené v štandardizačných odporúčaniach . V prípade iných kryptografických schém táto hrozba neexistuje, pretože šifrovanie sa vykonáva na verejných kľúčoch príjemcu a útočníkom sú všeobecne známe.
Rozklad
U2.1. Ohrozenie súkromného kľúča odosielateľa:
U2.1.1. odkaz: .
U2.2. Náhrada vstupných údajov v otvorenom kanáli výmeny údajov.
Poznámky U2.2.
Príklady implementácie tejto hrozby sú uvedené nižšie. и .
U3. Dešifrovanie zašifrovaných údajov osobami, ktoré nie sú legitímnymi príjemcami údajov (útočníci)
Rozklad
U3.1. Kompromitácia súkromných kľúčov príjemcu zašifrovaných údajov.
Odkaz na U3.1.1: .
U3.2. Nahradenie zašifrovaných údajov v zabezpečenom kanáli výmeny údajov.
U 4. Vytvorenie elektronického podpisu oprávneného podpisovateľa pod falošnými údajmi
Rozklad
U4.1. Kompromitácia súkromných kľúčov elektronického podpisu legitímneho podpisovateľa.
Odkaz na U4.1.1: .
U4.2. Nahradenie podpísaných údajov v otvorenom kanáli výmeny údajov.
Poznámka U4.2.
Príklady implementácie tejto hrozby sú uvedené nižšie. и .
U5. Získanie pozitívneho výsledku z kontroly elektronického podpisu sfalšovaných údajov
Rozklad
U5.1. Útočníci zachytia správu v kanáli na prenos výsledkov práce o negatívnom výsledku kontroly elektronického podpisu a nahradia ju správou s pozitívnym výsledkom.
U5.2. Útočníci útočia na dôveru v podpisovanie certifikátov (SCRIPT - všetky prvky sú povinné):
U5.2.1. Útočníci generujú verejný a súkromný kľúč pre elektronický podpis. Ak systém používa certifikáty kľúčov pre elektronický podpis, potom vygenerujú certifikát elektronického podpisu, ktorý je čo najviac podobný certifikátu zamýšľaného odosielateľa údajov, ktorých správu chcú sfalšovať.
U5.2.2. Útočníci robia neautorizované zmeny v úložisku verejných kľúčov, čím dávajú verejnému kľúču, ktorý generujú potrebnú úroveň dôvery a autority.
U5.2.3. Útočníci podpíšu falošné údaje predtým vygenerovaným kľúčom elektronického podpisu a vložia ho do zabezpečeného kanála výmeny údajov.
U5.3. Útočníci uskutočnia útok s použitím kľúčov elektronického podpisu, ktorých platnosť vypršala.SCRIPT - všetky prvky sú povinné):
U5.3.1. Útočníci kompromitovali expirované (aktuálne neplatné) súkromné kľúče elektronického podpisu legitímneho odosielateľa.
U5.3.2. Útočníci nahradia čas v časovom prenosovom kanáli časom, v ktorom boli napadnuté kľúče stále platné.
U5.3.3. Útočníci podpisujú nepravdivé údaje predtým napadnutým kľúčom elektronického podpisu a vložia ich do zabezpečeného kanála na výmenu údajov.
U5.4. Útočníci uskutočnia útok pomocou kompromitovaných kľúčov elektronického podpisu zákonného signatára (SCRIPT - všetky prvky sú povinné):
U5.4.1. Útočník vytvorí kópiu úložiska verejných kľúčov.
U5.4.2. Útočníci kompromitujú súkromné kľúče jedného z legitímnych odosielateľov. Všimne si kompromis, odvolá kľúče a informácia o odvolaní kľúča sa umiestni do úložiska verejných kľúčov.
U5.4.3. Útočníci nahradia úložisko verejných kľúčov predtým skopírovaným.
U5.4.4. Útočníci podpisujú nepravdivé údaje predtým napadnutým kľúčom elektronického podpisu a vložia ich do zabezpečeného kanála na výmenu údajov.
U5.5. <…> z dôvodu výskytu chýb pri implementácii 2. a 3. etapy overovania elektronického podpisu:
Vysvetlivky U5.5.
Uvádza sa príklad implementácie tejto hrozby .
U5.5.1. Kontrola dôvery v certifikát kľúča elektronického podpisu len prítomnosťou dôvery v certifikát, ktorým je podpísaný, bez kontroly CRL alebo OCSP.
Vysvetlivky U5.5.1.
Príklad implementácie .
U5.5.2. Pri vytváraní dôveryhodného reťazca pre certifikát sa neanalyzujú autority vydávajúcich certifikáty
Vysvetlivky U5.5.2.
Príklad útoku proti SSL/TLS certifikátom.
Útočníci si na svoj e-mail kúpili legitímny certifikát. Potom vytvorili podvodný certifikát stránky a podpísali ho svojim certifikátom. Ak sa poverenia nekontrolujú, pri kontrole reťazca dôvery sa ukáže, že je správny, a preto bude správny aj podvodný certifikát.
U5.5.3. Pri vytváraní reťazca dôveryhodnosti certifikátov sa nekontroluje zrušenie prechodných certifikátov.
U5.5.4. CRL sa aktualizujú menej často, ako ich vydáva certifikačná autorita.
U5.5.5. Rozhodnutie dôverovať elektronickému podpisu sa robí pred prijatím odpovede OCSP o stave certifikátu, odoslanej na žiadosť zadanú neskôr ako v čase vygenerovania podpisu alebo skôr ako v nasledujúcom CRL po vygenerovaní podpisu.
Vysvetlivky U5.5.5.
V predpisoch väčšiny CA sa za čas zrušenia certifikátu považuje čas vydania najbližšieho CRL obsahujúceho informáciu o zrušení certifikátu.
U5.5.6. Pri prijímaní podpísaných údajov sa nekontroluje, či certifikát patrí odosielateľovi.
Vysvetlivky U5.5.6.
Príklad útoku. Vo vzťahu k SSL certifikátom: zhoda adresy volaného servera s hodnotou poľa CN v certifikáte nemusí byť kontrolovaná.
Príklad útoku. Útočníci kompromitovali kľúče elektronického podpisu jedného z účastníkov platobného systému. Potom sa nabúrali do siete iného účastníka a v jeho mene poslali platobné dokumenty podpísané kompromitovanými kľúčmi na zúčtovací server platobného systému. Ak server iba analyzuje dôveru a nekontroluje súlad, podvodné dokumenty budú považované za legitímne.
TY 6. Chybné prijatie elektronických dokumentov na vykonanie v dôsledku problémov s organizáciou toku elektronických dokumentov.
Rozklad
U6.1. Prijímajúca strana nezistila duplikáciu prijatých dokumentov.
Vysvetlivky U6.1.
Príklad útoku. Útočníci môžu zachytiť dokument odosielaný príjemcovi, aj keď je kryptograficky chránený, a potom ho opakovane odoslať cez bezpečný kanál na prenos údajov. Ak príjemca neidentifikuje duplikáty, všetky prijaté dokumenty budú vnímané a spracované ako odlišné dokumenty.
U7. Neoprávnený prístup k chráneným údajom počas ich spracovania CIPF
Rozklad
U7.1. <…> v dôsledku úniku informácií bočnými kanálmi (útok na bočný kanál).
Vysvetlivky U7.1.
Príklad .
U7.2. <…> z dôvodu neutralizácie ochrany pred neoprávneným prístupom k informáciám spracúvaným na CIPF:
U7.2.1. Prevádzka CIPF v rozpore s požiadavkami popísanými v dokumentácii pre CIPF.
U7.2.2. <…>, vykonávané z dôvodu prítomnosti zraniteľností v:
U7.2.2.1. <…> prostriedky ochrany pred neoprávneným prístupom.
U7.2.2.2. <…> CIPF samotný.
U7.2.2.3. <…> operačné prostredie kryptonástroja.
Príklady útokov
Nižšie uvedené scenáre zjavne obsahujú chyby informačnej bezpečnosti a slúžia len na ilustráciu možných útokov.
Scenár 1. Príklad implementácie hrozieb U2.2 a U4.2.
Popis objektu
Softvér AWS KBR a CIPF SCAD Signature sú nainštalované na fyzickom počítači, ktorý nie je pripojený k počítačovej sieti. FKN vdToken sa používa ako kľúčový nosič v režime práce s nevyberateľným kľúčom.
Pravidlá zúčtovania predpokladajú, že špecialista na zúčtovanie zo svojho pracovného počítača stiahne elektronické správy vo forme čistého textu (schéma starej pracovnej stanice KBR) zo špeciálneho zabezpečeného súborového servera, potom ich zapíše na prenosný USB flash disk a prenesie na pracovnú stanicu KBR, kde sú zašifrované a podpísané. Potom špecialista prenesie zabezpečené elektronické správy na odcudzené médium a potom ich prostredníctvom svojho pracovného počítača zapíše na súborový server, odkiaľ idú do UTA a potom do platobného systému Ruskej banky.
V tomto prípade kanály na výmenu otvorených a chránených údajov budú zahŕňať: súborový server, pracovný počítač špecialistu a odcudzené médiá.
útok
Neoprávnení útočníci si nainštalujú na pracovný počítač špecialistu systém diaľkového ovládania a v čase zapisovania platobných príkazov (elektronických správ) na prenosné médium nahradia obsah jedného z nich čistým textom. Špecialista prenesie platobné príkazy na automatizované pracovisko KBR, podpíše a zašifruje ich bez toho, aby si ich zámenu všimol (napríklad z dôvodu veľkého počtu platobných príkazov počas letu, únavy a pod.). Potom falošný platobný príkaz, ktorý prešiel technologickým reťazcom, vstupuje do platobného systému Ruskej banky.
Scenár 2. Príklad implementácie hrozieb U2.2 a U4.2.
Popis objektu
Počítač s nainštalovanou pracovnou stanicou KBR, SCAD Signature a pripojeným kľúčovým nosičom FKN vdToken funguje vo vyhradenej miestnosti bez prístupu personálu.
Výpočtový špecialista sa pripojí k pracovnej stanici CBD v režime vzdialeného prístupu cez protokol RDP.
útok
Útočníci zachytia detaily, pomocou ktorých sa výpočtový špecialista spojí a spolupracuje s pracovnou stanicou CBD (napríklad prostredníctvom škodlivého kódu na svojom počítači). Potom sa v jeho mene spoja a pošlú falošný platobný príkaz do platobného systému Bank of Russia.
Scenár 3. Príklad implementácie hrozby U1.3.
Popis objektu
Uvažujme jednu z hypotetických možností implementácie integračných modulov ABS-KBR pre novú schému (AWS KBR-N), v ktorej sa elektronický podpis odchádzajúcich dokumentov vyskytuje na strane ABS. V tomto prípade budeme predpokladať, že ABS funguje na základe operačného systému, ktorý nie je podporovaný podpisom CIPF SKAD, a preto je kryptografická funkčnosť prenesená na samostatný virtuálny stroj – integrácia „ABS-KBR“. modul.
Ako nosič kľúčov sa používa bežný USB token pracujúci v režime s možnosťou obnovenia kľúča. Pri pripájaní kľúčového média k hypervízoru sa ukázalo, že v systéme nie sú voľné USB porty, preto bolo rozhodnuté pripojiť USB token cez sieťový USB rozbočovač a nainštalovať USB-over-IP klienta na virtuálny stroj, ktorý by komunikoval s rozbočovačom.
útok
Útočníci zachytili súkromný kľúč elektronického podpisu z komunikačného kanála medzi USB hubom a hypervízorom (údaje boli prenášané ako čistý text). Útočníci so súkromným kľúčom vygenerovali falošný platobný príkaz, podpísali ho elektronickým podpisom a odoslali na vykonanie na automatizované pracovisko KBR-N.
Scenár 4. Príklad implementácie hrozieb U5.5.
Popis objektu
Uvažujme rovnaký obvod ako v predchádzajúcom scenári. Budeme predpokladať, že elektronické správy prichádzajúce z pracovnej stanice KBR-N skončia v priečinku ...SHAREIn a správy odoslané na pracovnú stanicu KBR-N a ďalej do platobného systému Bank of Russia smerujú do ...SHAREout.
Budeme tiež predpokladať, že pri implementácii integračného modulu sa zoznamy zrušených certifikátov aktualizujú až pri opätovnom vydaní kryptografických kľúčov a tiež, že elektronické správy prijaté v priečinku …SHAREIn sú kontrolované len z hľadiska kontroly integrity a kontroly dôveryhodnosti verejného kľúča elektronický podpis.
útok
Útočníci pomocou kľúčov ukradnutých v predchádzajúcom scenári podpísali falošný platobný príkaz s informáciou o prijatí peňazí na účet podvodného klienta a zaviedli ho do zabezpečeného kanála výmeny dát. Keďže neexistuje overenie, že platobný príkaz podpísala Banka Ruska, je akceptovaný na vykonanie.
Zdroj: hab.com