Odkazy na další části výzkumu
- (Jste zde)
Tento článek uzavírá cyklus publikací věnovaných zajištění informační bezpečnosti bankovních bezhotovostních plateb. Zde se zaměříme na typické modely hrozeb, na které se odkazovalo v :
- .
- .
- .
- .
HABRO-WARNING !!! Vážení čtenáři, toto není zábavný příspěvek.
Skryté pod katem více než 40 stran materiálů mají za cíl pomoci při práci nebo studiu lidí specializujících se na bankovnictví nebo zabezpečení informační bezpečnosti. Tyto materiály jsou konečným produktem výzkumu a jsou napsány suchým oficiálním stylem. V podstatě se jedná o šablony pro interní dokumenty v oblasti IB.A tradičně – „použití informací z článku k nelegálním účelům je trestné podle zákona“. Produktivní čtení!
Informace pro čtenáře, kteří se s výzkumem seznamují počínaje touto publikací.
O čem je výzkum
Čtete průvodce pro specialistu odpovědného za zajištění informační bezpečnosti plateb v bance.
Logika výkladu
Na začátku se a představuje objekt ochrany. Poté v popisuje, jak vybudovat systém ochrany, a hovoří o potřebě vytváření modelu hrozeb. V se pojednává o tom, jaké modely hrozeb existují a jak se vytvářejí. V a je uvedena analýza skutečných útoků. a obsahují popis modelu hrozeb, který byl vybudován s ohledem na informace ze všech předchozích částí.
TYPICKÝ MODEL HROZEB. Síťové připojení
Objekt ochrany, pro který se používá model hrozeb (scope)
Objektem ochrany jsou data, která jsou přenášena prostřednictvím síťového připojení, fungujícího v datových sítích postavených na základě protokolu TCP/IP.
Architektura
Popis prvků architektury:
- "Koncové uzly" — uzly, které si vyměňují chráněné informace.
- "Mezilehlé uzly" — prvky datové sítě: směrovače, přepínače, servery přístupu, proxy servery a další zařízení, skrze které se přenáší provoz síťového připojení. Obecně může síťové připojení fungovat bez mezilehlých uzlů (přímo mezi koncovými uzly).
Hrozby bezpečnosti na vyšší úrovni
Dekonstrukce
H1. Neoprávněný přístup k přenášeným datům.
H2. Neoprávněná modifikace přenášených dat.
H3. Porušení autorského práva přenášených dat.
H1. Neoprávněný přístup k přenášeným datům
Dekonstrukce
H1.1. , prováděné na koncových nebo mezilehlých uzlech:
H1.1.1. čtením dat během jejich přítomnosti ve vzdělávacích zařízeních uzlu:
H1.1.1.1. v operační paměti.
Vysvětlivky k H1.1.1.1.
Například během zpracování dat síťovým zásobníkem uzlu.
H1.1.1.2. ve flash paměti.
Vysvětlivky k H1.1.1.2.
Například při ukládání přenášených dat do cache, do dočasných souborů nebo swapových souborů.
H1.2. , prováděné na cizích uzlech datové sítě:
H1.2.1. metodou zachycení všech paketů, které přicházejí na síťové rozhraní uzlu:
Vysvětlivky k H1.2.1.
Zachycení všech paketů se provádí přepnutím síťové karty do promiscuous režimu (promiscuous mode pro drátové adaptéry nebo do monitorovacího režimu pro Wi-Fi adaptéry).
H1.2.2. prováděním útoků typu "člověk uprostřed (MiTM)", ale bez modifikace přenášených dat (s výjimkou provozních dat síťových protokolů).
H1.2.2.1. Odkaz: .
U1.3. , prováděné prostřednictvím úniku informací technickými kanály (TKU) z fyzických uzlů nebo spojových linií.
U1.4. , prováděné instalací speciálních technických prostředků (STP) na koncové nebo meziuzlové uzly, určených k tajnému zachycování informací.
U2. Neautorizovaná modifikace přenášených dat
Dekonstrukce
U2.1. , prováděná na koncových nebo meziuzlových uzlech:
U2.1.1. čtením a prováděním změn v datech během jejich přítomnosti v paměťových zařízeních uzlů:
U2.1.1.1. v operační paměti:
U2.1.1.2. v nevolatile paměti:
U2.2. , prováděná na cizích uzlech datových přenosů:
U2.2.1. prováděním útoků typu „člověk uprostřed (MiTM)“ a přesměrováním provozu na uzel útočníka:
U2.2.1.1. Fyzické připojení zařízení útočníků do přerušení síťového spojení.
U2.2.1.2. Provádění útoků na síťové protokoly:
U2.2.1.2.1. správa virtuálních lokálních sítí (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Neautorizovaná modifikace nastavení VLAN na přepínačích nebo směrovačích.
U2.2.1.2.2. směrování provozu:
U2.2.1.2.2.1. Neautorizovaná modifikace tabulek statického směrování směrovačů.
U2.2.1.2.2.2. Annoncování falšovaných tras útočníky prostřednictvím protokolů dynamického směrování.
U2.2.1.2.3. automatické konfigurace:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. adresace a resoluce jmen:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Provádění neautorizovaných změn v místních souborech jmen uzlů (hosts, lmhosts atd.)
U3. Porušení autorství přenášených dat
Dekonstrukce
U3.1. Neutralizace mechanismů určení autorství informací prostřednictvím uvedení falšovaných údajů o autorovi nebo zdroji dat:
U3.1.1. Změna údajů o autorovi obsažených v přenášených informacích.
U3.1.1.1. Neutralizace kryptografické ochrany integrity a autorství přenášených dat:
U3.1.1.1.1. Odkaz: .
U3.1.1.2. Neutralizace ochrany autorských práv přenášených dat, realizované pomocí jednorázových kódů potvrzení:
U3.1.1.2.1. .
U3.1.2. Změna údajů o zdroji přenášených informací:
U3.1.2.1. .
U3.1.2.2. .
TYPOVÝ MODEL HROZEB. INFORMAČNÍ SYSTÉM, POSTAVENÝ NA ZÁKLADĚ ARCHITEKTURY KLIENT-SERVER
Objekt ochrany, pro který se používá model hrozeb (scope)
Ochranným objektem je informační systém, který je postaven na základě architektury klient-server.
Architektura
Popis prvků architektury:
- „Klient“ – zařízení, na kterém funguje klientská část informačního systému.
- „Server“ – zařízení, na kterém funguje serverová část informačního systému.
- „Úložiště dat“ – část serverové infrastruktury informačního systému určená k ukládání dat zpracovávaných informačním systémem.
- „Síťové spojení“ – kanál výměny informací mezi Klientem a Serverem, procházející sítí přenosu dat. Podrobnější popis modelu prvku je uveden v .
Omezení
Při modelování objektu byla stanovena následující omezení:
- Uživatel interaguje s informačním systémem v rámci konečných časových intervalů nazývaných sezení.
- Na začátku každého sezení probíhá identifikace, autentizace a autorizace uživatele.
- Všechny chráněné informace jsou uloženy na serverové části informačního systému.
Hrozby bezpečnosti na vyšší úrovni
Dekonstrukce
U1. Provádění nezákonných akcí útočníky na jméno legitimního uživatele.
U2. Neautorizovaná modifikace chráněných informací během jejich zpracování serverovou částí informačního systému.
U1. Provádění nezákonných akcí útočníky na jméno legitimního uživatele
Vysvětlení
Obvykle se ve informačních systémech vztahují akce k provádějícímu uživateli pomocí:
- protokolů práce systému (logs).
- speciálních atributů objektů dat, které obsahují informace o uživateli, který je vytvořil nebo změnil.
Ve vztahu k sezení může být tato hrozba dekomponována na:
- provedené v rámci sezení uživatele.
- provedené mimo sezení uživatele.
Sezení uživatele může být zahájeno:
- Samotným uživatelem.
- Útočníky.
V této fázi bude mezilaterální dekompozice této hrozby vypadat následovně:
U1.1. Neoprávněné akce byly provedeny v rámci relace uživatele:
U1.1.1. , nainstalované napadeným uživatelem.
U1.1.2. , nainstalované útočníky.
U1.2. Neoprávněné akce byly provedeny mimo relaci uživatele.
Z pohledu objektů informační infrastruktury, na které mohou útočníci cílit, bude dekompozice mezilaterálních hrozeb vypadat následovně:
Prvky
Dekompozice hrozeb
U1.1.1.
U1.1.2.
U1.2.
Zákazník
U1.1.1.1.
U1.1.2.1.
Síťové spojení
U1.1.1.2.
Server
U1.2.1.
Dekonstrukce
U1.1. Neoprávněné akce byly provedeny v rámci relace uživatele:
U1.1.1. , nainstalované napadeným uživatelem:
U1.1.1.1. Útočníci jednali samostatně z Klienta:
U1.1.1.1.1 Útočníci využili standardní prostředky pro přístup k informačnímu systému:
U1.1.1.1.1.1. Útočníci použili fyzická vstupní a výstupní zařízení Klienta (klávesnice, myš, monitor nebo dotyková obrazovka mobilního zařízení):
U1.1.1.1.1.1.1. Útočníci jednali v časových obdobích, kdy byla relace aktivní, vstupní a výstupní prostředky byly k dispozici a uživatel nebyl přítomen.
U1.1.1.1.1.2. Útočníci použili prostředky pro vzdálenou správu (standardní nebo poskytnuté škodlivým kódem) k ovládnutí Klienta:
U1.1.1.1.1.2.1. Útočníci jednali v časových obdobích, kdy byla relace aktivní, vstupní a výstupní prostředky byly k dispozici a uživatel nebyl přítomen.
U1.1.1.1.1.2.2. Útočníci použili prostředky pro vzdálenou správu, jejichž činnost byla pro napadeného uživatele nepozorovatelná.
U1.1.1.2. Útočníci podvrhli data v síťovém spojení mezi Klientem a Serverem, modifikujíc je tak, aby byla vnímána jako akce legitimního uživatele:
U1.1.1.2.1. Odkaz: .
U1.1.1.3. Útočníci donutili uživatele k provedení požadovaných akcí pomocí metod sociálního inženýrství.
U1.1.2 nainstalované útočníky:
U1.1.2.1. Útočníci jednáni z Klienta (A):
U1.1.2.1.1. Útočníci neutralizovali systém přístupu k informačnímu systému:
U1.1.2.1.1.1. Odkaz: .
U1.1.2.1.2. Útočníci použili standardní nástroje pro přístup k informačnímu systému
U1.1.2.2. Útočníci jednali z jiných uzlů datové sítě, ze kterých je možné navázat síťové spojení se serverem (A):
U1.1.2.2.1. Útočníci neutralizovali systém řízení přístupu informačního systému:
U1.1.2.2.1.1. Odkaz: .
U1.1.2.2.2. Útočníci použili nestandardní prostředky pro přístup k informačnímu systému.
Vysvětlení U1.1.2.2.2.
Útočníci mohli nainstalovat standardního klienta informačního systému na externí uzel nebo použít nestandardní software, který realizuje standardní protokoly výměny mezi klientem a serverem.
U1.2 Neautorizované akce provedeny mimo relaci uživatele.
U1.2.1 Útočníci provedli neautorizované akce a poté učinili neautorizované změny v protokolech činnosti informačního systému nebo ve speciálních atributů datových objektů, označující, že vykonané akce provedl oprávněný uživatel.
U2. Neautorizovaná modifikace chráněných informací během zpracování jejich serverovou částí informačního systému
Dekonstrukce
U2.1. Útočníci modifikují chráněné informace pomocí standardních prostředků informačního systému a dělají to jménem oprávněného uživatele.
U2.1.1. Odkaz: .
U2.2. Útočníci modifikují chráněné informace pomocí mechanismů přístupu k datům, které nejsou standardně zahrnuty v režimu fungování informačního systému.
U2.2.1. Útočníci modifikují soubory obsahující chráněné informace:
U2.2.1.1. , použitím mechanismů práce se soubory poskytovaných operačním systémem.
U2.2.1.2. provokací obnovení souborů z neoprávněně modifikované záložní kopie.
U2.2.2. Útočníci modifikují chráněné informace uložené v databázi (A):
U2.2.2.1. Útočníci neutralizují přístupový kontrolní systém databázového serveru:
U2.2.2.1.1. Odkaz: .
U2.2.2.2. Útočníci modifikují informace pomocí standardních rozhraní databázového serveru pro přístup k datům.
U2.3. Útočníci modifikují chráněné informace prostřednictvím neoprávněné změny algoritmů fungování zpracovávajícího softwaru.
U2.3.1. Změnám podléhá zdrojový kód softwaru.
U2.3.1. Změnám podléhá strojový kód softwaru.
U2.4. Útočníci modifikují chráněné informace pomocí zranitelností v software informačního systému.
U2.5. Útočníci modifikují chráněné informace během jejího přenosu mezi komponenty serverové části informačního systému (například mezi serverem databází a aplikačním serverem):
U2.5.1. Odkaz: .
TYPOVÝ MODEL HROZEB. SYSTÉM ROZLIŠOVÁNÍ PŘÍSTUPU
Objekt ochrany, pro který se používá model hrozeb (scope)
Objekt ochrany, pro který je tento model hrozeb aplikován, odpovídá objektu ochrany v modelu hrozeb: „Typový model hrozeb. Informační systém postavený na architektuře klient-server“.
Pod systémem rozlišování přístupu uživatelů v tomto modelu hrozeb se rozumí komponent informačního systému, který realizuje funkce:
- Identifikace uživatelů.
- Autentizace uživatelů.
- Autorizace uživatelů.
- Protokolování akcí uživatelů.
Hrozby bezpečnosti na vyšší úrovni
Dekonstrukce
U1. Neoprávněné ustanovení relace na jméno legálního uživatele.
U2. Neoprávněné zvýšení privilegií uživatele v informačním systému.
U1. Neoprávněné ustanovení relace na jméno legálního uživatele
Vysvětlení
Dekompozice této hrozby bude obecně záviset na použitém typu systémů identifikace a autentizace uživatelů.
V tomto modelu bude zvažován pouze systém identifikace a autentizace uživatelů, který používá textový login a heslo. Předpokládáme, že login uživatele je veřejně přístupná informace, známá útočníkům.
Dekonstrukce
U1.1. díky kompromisi přihlašovacích údajů:
U1.1.1. Útočníci kompromitovali přihlašovací údaje uživatele během jejich ukládání.
Vysvětlení U1.1.1.
Například přihlašovací údaje mohly být napsány na nálepce, přilepené k monitoru.
U1.1.2. Uživatel náhodou nebo úmyslně předal přihlašovací údaje útočníkům.
U1.1.2.1. Uživatel nahlas vyřkl své přihlašovací údaje při zadávání.
U1.1.2.2. Uživatel úmyslně předal své přihlašovací údaje:
U1.1.2.2.1. kolegům v práci.
Objasnění U1.1.2.2.1.
Například, aby je mohli použít k zajištění náhrady v době nemoci.
U1.1.2.2.2. kontraktorům zaměstnavatele, kteří provádějí práce na objektech informační infrastruktury.
U1.1.2.2.3. třetím stranám.
Objasnění U1.1.2.2.3.
Jednou, ale ne jedinou variantou tohoto ohrožení je použití metod sociálního inženýrství ze strany útočníků.
U1.1.3. Útočníci uhádli přihlašovací údaje metodou brute-force:
U1.1.3.1. pomocí standardních přístupových mechanismů.
U1.1.3.2. na základě dříve zachycených kódů (například hashů hesel) pro uchovávání přihlašovacích údajů.
U1.1.4. Útočníci použili škodlivý kód k zachycení přihlašovacích údajů uživatele.
U1.1.5. Útočníci extrahovali přihlašovací údaje z síťového spojení mezi Klientem a Serverem:
U1.1.5.1. Odkaz: .
U1.1.6. Útočníci extrahovali přihlašovací údaje z záznamů monitorovacích systémů:
U1.1.6.1. systémů videonadzoru (pokud byla v průběhu práce zaznamenávána stisknutí kláves na klávesnici).
U1.1.6.2. systémů monitorování činnosti zaměstnanců na počítači.
Objasnění U1.1.6.2.
Příkladem takového systému je — .
U1.1.7. Útočníci kompromitovali přihlašovací údaje uživatele kvůli nedostatkům v procesu jejich přenosu.
Objasnění U1.1.7.
Například, přenos hesel v otevřeném formátu e-mailem.
U1.1.8. Útočníci se dozvěděli přihlašovací údaje sledováním pracovního sezení uživatele pomocí systémů vzdálené správy.
U1.1.9. Útočníci získali přihlašovací údaje v důsledku jejich úniku technickými kanály (TKUI):
U1.1.9.1. Útočníci pozorovali, jak uživatel zadává přihlašovací údaje na klávesnici:
U1.1.9.1.1 Útočníci byli v bezprostřední blízkosti uživatele a viděli, jak se přihlašovací údaje zadávají.
Objasnění U1.1.9.1.1.
Mezi takové případy patří jednání kolegů v práci nebo situace, kdy je klávesnice uživatele viditelná návštěvníkům organizace.
Ú1.1.9.1.2 Útočníci použili další technické prostředky, jako je dalekohled nebo bezpilotní létající aparát, a viděli zadávání přihlašovacích údajů skrz okno.
Ú1.1.9.2. Útočníci získali přihlašovací údaje z nahrávek rádiového spojení mezi klávesnicí a systémovou jednotkou počítače v případě, že byly připojeny přes rádiové rozhraní (např. Bluetooth).
Ú1.1.9.3. Útočníci provedli odposlech přihlašovacích údajů díky jejich úniku skrze kanál vedlejších elektromagnetických emisí a indukcí (PÉM).
Vysvětlení Ú1.1.9.3.
Příklady útoku a .
Ú1.1.9.4. Útočník provedl odposlech zadávání přihlašovacích údajů z klávesnice pomocí speciálních technických prostředků (STP), určených pro tajné snímání informací.
Vysvětlení Ú1.1.9.4.
Příklady .
Ú1.1.9.5. Útočníci provedli odposlech zadávání přihlašovacích údajů z klávesnice díky
analýze Wi-Fi signálu, modifikovaného procesem stisknutí kláves uživateli.
Vysvětlení Ú1.1.9.5.
Příklad .
Ú1.1.9.6. Útočníci provedli odposlech zadávání přihlašovacích údajů z klávesnice díky analýze zvuků stisknutí kláves.
Vysvětlení Ú1.1.9.6.
Příklad .
Ú1.1.9.7. Útočníci provedli odposlech zadávání přihlašovacích údajů z klávesnice mobilního zařízení díky analýze údajů z akcelerometru.
Vysvětlení Ú1.1.9.7.
Příklad .
Ú1.1.10. , dříve uložených na Klientovi.
Vysvětlení Ú1.1.10.
Například uživatel mohl v prohlížeči uložit přihlašovací jméno a heslo pro přístup na určitou webovou stránku.
Ú1.1.11. Útočníci zkompromitovali přihlašovací údaje kvůli nedostatkům v procesu odnětí přístupů uživatelů.
Vysvětlení Ú1.1.11.
Například po odchodu uživatele z práce jeho účty zůstaly nezablokované.
Ú1.2. díky využití zranitelností v systému přístupového řízení.
Ú2. Neoprávněné zvýšení oprávnění uživatele v informačním systému.
Dekonstrukce
Ú2.1 provedením neoprávněných změn v údajích, které obsahují informace o oprávněních uživatele.
Ú2.2 díky využití zranitelností v systému přístupového řízení.
Ú2.3. kvůli nedostatkům procesu správy přístupu uživatelů.
Vysvětlení U2.3.
Příklad 1. Uživatel měl přístup, který byl větší, než jaký potřeboval pro své pracovní povinnosti.
Příklad 2. Po převedení uživatele na jinou pozici nebyla dříve poskytnutá práva přístupu odvolána.
TYPOVÝ MODEL HROZEB. INTEGRAČNÍ MODUL
Objekt ochrany, pro který se používá model hrozeb (scope)
Integrační modul je soubor objektů informační infrastruktury určený k uspořádání výměny informací mezi informačními systémy.
Vzhledem k tomu, že v korporátních sítích není vždy možné jednoznačně oddělit jeden informační systém od druhého, integrační modul lze chápat také jako spojovací článek mezi komponenty uvnitř jednoho informačního systému.
Architektura
Zjednodušený diagram integračního modulu vypadá takto:
Popis prvků architektury:
- «Server výměny (СО)» – uzel / služba / komponenta informačního systému, která vykonává funkci výměny dat s jiným informačním systémem.
- «Zprostředkovatel» – uzel / služba, určená k organizaci interakce mezi informačními systémy, ale nepatřící do jejich struktury.
Příklady «Zprostředkovatelů» mohou být služby elektronické pošty, podnikové servisní sběrnice (enterprise service bus / architektura SoA), externí souborové servery atd. V obecném případě integrační modul nemusí obsahovat «Zprostředkovatele». - «SW pro zpracování dat» – soubor programů, které realizují protokoly pro výměnu dat a transformaci formátů.
Například převod dat z formátu UFEBS do formátu ABS, změna stavů zpráv během přenosu atd. - „Síťové spojení“ odpovídá objektu popsanému v typovém modelu hrozeb «Síťové spojení». Některá síťová spojení z těch, které jsou uvedeny na výše uvedeném diagramu, nemusí existovat.
Příklady integračních modulů
Diagram 1. Integrace ABS a ARM KBR prostřednictvím externího souborového serveru
Pro provedení plateb určený pracovník banky exportuje z ABS elektronické platební dokumenty a ukládá je do souboru (vlastního formátu, například SQL-dump) ve sdílené složce (…SHARE) souborového serveru. Následně je tento soubor pomocí konverzního skriptu převeden do souborů formátu UFEBS, které následně načítá ARM KBR.
Poté oprávněný pracovník — uživatel ARM KBR — zašifruje a podepíše obdržený soubor a odešle jej do platebního systému Centrální banky Ruska.
Při příjmu plateb od Centrální banky Ruska ARM KBR provede jejich dešifrování a kontrolu elektronického podpisu, poté je uloží jako sadu souborů ve formátu UFBSC na souborový server. Před importem platebních dokumentů do ABS jsou převedeny pomocí konverzního skriptu z formátu UFBSC do formátu ABS.
Předpokládejme, že v této schématu funguje ABS na jednom fyzickém serveru, ARM KBR běží na vyhrazeném počítači a konverzní skript pracuje na souborovém serveru.
Soulad objektů uvedené schématu s prvky modelu integračního modulu:
„Servery výměny ze strany ABS“ – server ABS.
„Servery výměny ze strany ARM KBR“ – počítač ARM KBR.
«Zprostředkovatel» – externí souborový server.
«SW pro zpracování dat» – konverzní skript.
Schéma 2. Integrace ABS a ARM KBR při umístění sdílené síťové složky s platbami na ARM KBR
Vše podobně jako ve Schématu 1, ale není použit samostatný souborový server, místo toho je síťová složka (…SHARE) s elektronickými platebními dokumenty umístěna na počítači s ARM KBR. Konverzní skript také pracuje na ARM KBR.
Soulad objektů uvedené schématu s prvky modelu integračního modulu:
Stejně jako ve Schématu 1, ale «Zprostředkovatel» není používán.
Schéma 3. Integrace ABS a ARM KBR-N přes IBM WebSphere MQ a provedení podpisu elektronických dokumentů „na straně ABS“
ABS běží na platformě, která není podporována SKZI SKAD Signatura. Podpis odchozích elektronických dokumentů se provádí na speciálním serveru elektronického podpisu (Server EP). Tento samý server kontroluje elektronický podpis u příchozích dokumentů od Centrální banky Ruska.
ABS nahrává na Server EP soubor s platebními dokumenty ve vlastním formátu.
Server EP pomocí konverzního skriptu převádí soubor na elektronické zprávy ve formátu UFBSC, poté jsou elektronické zprávy podepsány a odeslány na IBM WebSphere MQ.
ARM KBR-N se obrací na IBM WebSphere MQ a získává odtud podepsané platební zprávy, poté oprávněný pracovník — uživatel ARM KBR — je zašifruje a odešle do platebního systému Centrální banky Ruska.
Při přijímání plateb od Banky Ruska ARМ KBR-N je dekóduje a kontroluje elektronický podpis. Úspěšně zpracované platby ve formě dešifrovaných a podepsaných elektronických zpráv formátu UFEB budou předány do IBM WebSphere MQ, odkud je obdrží Server EP.
Server EP kontroluje elektronický podpis přijatých plateb a ukládá je do souboru formátu ABS. Poté oprávněný pracovník — uživatel ABS — nahraje získaný soubor do ABS v předepsaném pořadí.
Soulad objektů uvedené schématu s prvky modelu integračního modulu:
„Server výměny ze strany ABS“ – server ABS.
„Server výměny ze strany ARМ KBR“ — počítač ARМ KBR.
«Zprostředkovatel» – Server EP a IBM WebSphere MQ.
«SW pro zpracování dat» – skript-konvertor, SKZI SKAD Podpis na Serveru EP.
Schéma 4. Integrace Serveru DBO a ABS přes API poskytované vyhrazeným serverem výměny
Budeme předpokládat, že v bance je používáno několik systémů vzdáleného bankovnictví (DBO):
- „Internet Klient-Bank“ pro fyzické osoby (IKB FL);
- „Internet Klient-Bank“ pro právnické osoby (IKB JЛ).
Za účelem zajištění informační bezpečnosti je veškerá interakce ABS se systémy DBO realizována prostřednictvím vyhrazeného serveru výměny, který pracuje v rámci informačního systému „ABS“.
Nyní se podíváme na proces interakce systému DBO IKB JЛ s ABS.
Server DBO, který od klienta obdržel řádně ověřený platební příkaz, musí na jeho základě vytvořit odpovídající dokument v ABS. K tomu pomocí API předává informace na server výměny, který poté vkládá data do ABS.
Při změně zůstatků na účtu klienta ABS vytváří elektronická oznámení, která pomocí serveru výměny předává na server DBO.
Soulad objektů uvedené schématu s prvky modelu integračního modulu:
„Server výměny ze strany DBO“ – server DBO IKB JЛ.
„Server výměny ze strany ABS“ – server výměny.
«Zprostředkovatel» – není přítomno.
«SW pro zpracování dat» – komponenty Serveru DBO odpovědné za využívání API serveru výměny, komponenty serveru výměny odpovědné za využívání API ABS.
Hrozby bezpečnosti na vyšší úrovni
Dekonstrukce
U1. Vniknutí útočníky falešných informací prostřednictvím integračního modulu.
U1. Vniknutí útočníky falešných informací prostřednictvím integračního modulu
Dekonstrukce
U1.1. Neautorizovaná modifikace legitimních dat během jejich přenosu skrze síťová spojení:
U1.1.1 Odkaz: .
U1.2. Přenos falešných dat po komunikačních kanálech jménem legitimního účastníka výměny:
U1.1.2 Odkaz: .
U1.3. Neoprávněná modifikace legitimních dat při jejich zpracování na serverech výměny nebo zprostředkovatelích:
U1.3.1. Odkaz: .
U1.4. Vytvoření na serverech výměny nebo zprostředkovatelích podvodných dat jménem legitimního účastníka výměny:
U1.4.1. Odkaz:
U1.5. Neoprávněná modifikace dat při jejich zpracování pomocí softwaru pro zpracování dat:
U1.5.1. v důsledku neoprávněných změn provedených útočníky v nastaveních (konfiguraci) softwaru pro zpracování dat.
U1.5.2. v důsledku neoprávněných změn provedených útočníky v vykonatelných souborech softwaru pro zpracování dat.
U1.5.3. v důsledku interaktivního řízení útočníky nad činností softwaru pro zpracování dat.
TYPOVÝ MODEL HROZEB. SYSTÉM KRYPTOGRAFICKÉ OCHRANY INFORMACÍ
Objekt ochrany, pro který se používá model hrozeb (scope)
Objektem ochrany je systém kryptografické ochrany informací, který se používá k zajištění bezpečnosti informačního systému.
Architektura
Základem jakéhokoli informačního systému je aplikační software (SW), který realizuje jeho cílovou funkcionalitu.
Kryptografická ochrana se obvykle realizuje voláním kryptografických primitiv z obchodní logiky aplikačního SW, které jsou umístěny ve specializovaných knihovnách – kryptojádrech.
Kryptografická primitiva zahrnují nízkoúrovňové kryptografické funkce, jako například:
- šifrovat / dešifrovat blok dat;
- vytvořit / ověřit elektronický podpis bloku dat;
- vypočítat hash funkci bloku dat;
- vytvořit / nahrát / exportovat klíčové informace;
- atd.
Obchodní logika aplikačního SW s pomocí kryptografických primitiv realizuje vyšší úrovňovou funkcionalitu:
- šifrovat soubor na základě klíčů vybraných příjemců;
- nastavit zabezpečené síťové připojení;
- informovat o výsledcích kontroly elektronického podpisu;
- atd.
Interakce obchodní logiky a kryptojádra může probíhat:
- přímo, prostřednictvím vyvolání kryptografických primitiv obchodní logikou z dynamických knihoven kryptojádra (.DLL – pro Windows, .SO – pro Linux);
- nepřímo, prostřednictvím kryptografických rozhraní – wrapperů, například MS Crypto API, Java Cryptography Architecture, PKCS#11 atd. V tomto případě obchodní logika volá kryptointerface, které pak přeloží volání na příslušné kryptojádro, které se v takovém případě nazývá kryptopro poskytovatelem. Použití kryptografických rozhraní umožňuje aplikačnímu softwaru abstrahovat se od konkrétních kryptografických algoritmů a být flexibilnější.
Lze vyčlenit dvě typové schémata organizace kryptojádra:
Schéma 1 – Monolitické kryptojádro
Schéma 2 – Rozdělené kryptojádro
Elementy v uvedených schématech mohou být jak jednotlivými moduly softwaru, které pracují na jednom počítači, tak síťovými službami, které interagují v rámci výpočetní sítě.
Při použití systémů založených na schématu 1 pracují aplikační software a kryptojádro v rámci jedné provozní prostředí kryptografického prostředku (SFK), například na stejném počítači, pod řízením stejného operačního systému. Uživatel systému má obvykle možnost spouštět v rámci této provozní prostředí i další programy, včetně takových, které obsahují škodlivý kód. V takových podmínkách existuje vážné riziko úniku uzavřených kryptografických klíčů.
Pro minimalizaci rizika se používá schéma 2, při kterém se kryptojádro dělí na dvě části:
- První část spolu s aplikačním softwarem pracuje v nedůvěryhodném prostředí, kde existuje riziko nakažení škodlivým kódem. Budeme tuto část nazývat – „programovou částí“.
- Druhá část pracuje v důvěryhodném prostředí na dedikovaném zařízení, které obsahuje úložiště uzavřených klíčů. Dále budeme tuto část nazývat – „hardwarovou částí“.
Rozdělení kryptojádra na softwarovou a hardwarovou část je velmi relativní. Na trhu existují systémy, které jsou postaveny na principu se separovaným kryptojádrem, ale "hardwarová" část je prezentována ve formě obrazu virtuální stroje — virtual HSM ().
Interakce obou částí kryptojádra probíhá tak, že uzavřené kryptografické klíče nikdy nejsou předávány do softwarové části a tím pádem nemohou být ukradeny pomocí malwaru.
Rozhraní pro interakci (API) a sada kryptografických primitiv, které kryptojádro poskytuje aplikačnímu softwaru, jsou v obou případech shodné. Rozdíl spočívá v způsobu jejich implementace.
Při použití schématu se separovaným kryptojádrem je interakce softwarové a hardwarové části prováděna podle následujícího principu:
- Kryptografické primitivy, které nevyžadují použití uzavřeného klíče (například výpočet hashové funkce, ověření elektronického podpisu atd.), jsou vykonávány softwarovou částí.
- Kryptografické primitivy, které používají uzavřený klíč (vytváření elektronického podpisu, dešifrování dat atd.), jsou vykonávány hardwarovou částí.
Pro ilustrování práce separovaného kryptojádra použijeme příklad vytváření elektronického podpisu:
- Softwarová část vypočítá hashovou funkci podepisovaných dat a přes výměnný kanál mezi kryptojádry předá tuto hodnotu hardwarové části.
- Hardwarová část, využívající uzavřený klíč a hash, vytvoří hodnotu elektronického podpisu a přes výměnný kanál ji předá do softwarové části.
- Softwarová část vrátí obdrženou hodnotu do aplikačního softwaru.
Specifika ověřování správnosti elektronického podpisu
Když přijímající strana obdrží data podepsaná elektronickým podpisem, musí provést několik fází ověření. Kladný výsledek ověření elektronického podpisu je dosažen pouze při úspěšném splnění všech fází ověření.
Fáze 1. Kontrola integrity dat a autorství dat.
Obsah fáze. Kontrola elektronického podpisu dat se provádí podle příslušného kryptografického algoritmu. Úspěšné dokončení této fáze ukazuje, že data nebyla změněna od doby jejich podepsání a že podpis byl vytvořen soukromým klíčem odpovídajícím veřejnému klíči pro kontrolu elektronického podpisu.
Místo provádění fáze: krypto jádro.
Fáze 2. Kontrola důvěry k veřejnému klíči signatáře a kontrola platnosti soukromého klíče elektronického podpisu.
Obsah fáze. Fáze se skládá ze dvou podfází. V první se určuje, zda byl veřejný klíč pro kontrolu elektronického podpisu důvěryhodný v okamžiku podepsání dat. Ve druhé se určuje, zda byl soukromý klíč elektronického podpisu platný v době podepsání dat. Obecně mohou mít platnosti těchto klíčů různou dobu (například pro kvalifikované certifikáty klíčů pro kontrolu elektronického podpisu). Způsoby určení důvěry k veřejnému klíči signatáře se stanovují pravidly elektronického dokumentového oběhu přijatými zainteresovanými stranami.
Místo provádění fáze: aplikovaná SW / krypto jádro.
Fáze 3. Kontrola oprávnění signatáře.
Obsah fáze. V souladu se stanovenými pravidly elektronického dokumentového oběhu se kontroluje, zda měl signatář právo ověřit chráněná data. Například si vezměme situaci porušení oprávnění. Představme si organizaci, kde mají všichni zaměstnanci elektronický podpis. Do interního systému elektronického dokumentového oběhu přijde příkaz vedoucího, ale je podepsán elektronickým podpisem skladového mistra. Takový dokument tedy nemůže být považován za legitimní.
Místo provádění fáze: aplikovaná SW.
Předpoklady přijaté při popisu objektu ochrany.
- Kanály přenosu informací, s výjimkou kanálů pro výměnu klíčů, procházejí aplikovaným SW, API a krypto jádrem.
- Informace o důvěře k veřejným klíčům a/nebo certifikátům, stejně jako informace o oprávněních vlastníků veřejných klíčů, se ukládají do úložiště veřejných klíčů.
- Aplikovaný SW pracuje s úložištěm veřejných klíčů přes krypto jádro.
Příklad informačního systému chráněného pomocí SKZI.
Pro ilustraci dříve uvedených schémat uvažujme hypotetický informační systém a vyzdvihneme v něm všechny strukturované prvky.
Popis informačního systému
Dvě organizace se rozhodly zavést mezi sebou právně závazný elektronický oběh dokumentů (EBD). K tomu uzavřely dohodu, v níž bylo uvedeno, že dokumenty budou předávány prostřednictvím e-mailu a musí být zašifrovány a podepsány kvalifikovaným elektronickým podpisem. Jako prostředky pro vytváření a zpracování dokumentů mají být použity kancelářské programy z balíku Microsoft Office 2016, a jako prostředky kryptografické ochrany — SZT KryptoPRO a SW šifrování KryptoARM.
Popis infrastruktury organizace 1
Organizace 1 se rozhodla nainstalovat SZT KryptoPRO a SW KryptoARM na uživatelské pracoviště — fyzický počítač. Klíče pro šifrování a elektronický podpis budou uloženy na klíčovém nosiči ruToken, fungujícím v režimu vyjímatelného klíče. Uživatel bude lokalizovaně připravovat elektronické dokumenty na svém počítači, poté je zašifruje, podepíše a odešle pomocí lokálně nainstalovaného poštovního klienta.
Popis infrastruktury organizace 2
Organizace 2 se rozhodla přesunout funkce šifrování a elektronického podpisu na vyhrazenou virtuální stroj. Všechny kryptografické operace budou prováděny automaticky.
K tomu byly na vyhrazené virtuální mašině vytvořeny dvě síťové složky: „…In“, „…Out“. Do síťové složky „…In“ budou automaticky umisťovány soubory přijaté od protistrany v otevřeném formátu. Tyto soubory budou dešifrovány a bude ověřen jejich elektronický podpis.
Do složky „…Out“ bude uživatel umisťovat soubory, které je třeba zašifrovat, podepsat a odeslat protistraně. Uživatel bude tyto soubory připravovat na svém uživatelském pracovním místě.
Pro provádění funkcí šifrování a elektronického podpisu je na virtuální stroj nainstalován SZT KryptoPRO, SW KryptoARM a poštovní klient. Automatizované řízení všech prvků virtuálního stroje bude zajištěno pomocí skriptů vyvinutých systémovými administrátory. Práce skriptů je protokolována do souborů protokolů (logs).
Kryptografické klíče elektronického podpisu budou umístěny na tokenu s nevyjímatelným klíčem JaCarta ГОСТ, který uživatel připojí k vlastnímu počítači.
Token bude přenesen na virtuální stroj pomocí specializovaných softwarových prostředků USB-over-IP nainstalovaných na uživatelském pracovním místě a na virtuálním stroji.
Systémové hodiny na uživatelském pracovním místě v organizaci 1 budou nastavovány ručně. Systémové hodiny specializovaného virtuálního stroje v organizaci 2 budou synchronizovány se systémovými hodinami hypervizoru, které budou také synchronizovány přes Internet s veřejnými časovými servery.
Identifikace strukturálních prvků SKZИ
Na základě výše uvedeného popisu IT infrastruktury identifikujeme struktury SKZИ a zapíšeme je do tabulky.
Tabulka — Shoda prvků modelu SKZИ s prvky informačních systémů
Název prvku
Organizace 1
Organizace 2
Aplikační software
Software CryptoARM
Software CryptoARM
Programová část kryptoprocesoru
SKZИ CryptoPRO CSP
SKZИ CryptoPRO CSP
Hardwarová část kryptoprocesoru
chybí
JaCarta ГОСТ
API
MS CryptoAPI
MS CryptoAPI
Úložiště veřejných klíčů
Uživatelské pracovní místo:
— pevný disk;
— standardní úložiště certifikátů Windows.
Hypervizor:
— pevný disk.
Virtuální stroj:
— pevný disk;
— standardní úložiště certifikátů Windows.
Úložiště soukromých klíčů
Klíčový nosič ruToken pracující v režimu vyjímatelného klíče
Klíčový nosič JaCarta ГОСТ pracující v režimu nevyjímatelného klíče
Kanál pro výměnu veřejných klíčů
Uživatelské pracovní místo:
— operační paměť.
Hypervizor:
— operační paměť.
Virtuální stroj:
— operační paměť.
Kanál pro výměnu soukromých klíčů
Uživatelské pracovní místo:
— USB sběrnice;
— operační paměť.
chybí
Kanál mezi kryptoprocesory
neexistuje (není hardwarová část kryptoprocesoru)
Uživatelské pracovní místo:
— USB sběrnice;
— operační paměť;
— softwarový modul USB-over-IP;
— síťové rozhraní.
Korporátní síť organizace 2.
Hypervizor:
— operační paměť;
— síťové rozhraní.
Virtuální stroj:
— síťové rozhraní;
— operační paměť;
— softwarový modul USB-over-IP.
Kanál pro výměnu veřejných dat
Uživatelské pracovní místo:
— vstupně-výstupní prostředky;
— operační paměť;
— pevný disk.
Uživatelské pracovní místo:
— vstupně-výstupní prostředky;
— operační paměť;
— pevný disk;
— síťové rozhraní.
Korporátní síť organizace 2.
Hypervizor:
— síťové rozhraní;
— operační paměť;
— pevný disk.
Virtuální stroj:
— síťové rozhraní;
— operační paměť;
— pevný disk.
Kanál pro výměnu chráněných dat
Internet.
Korporátní síť organizace 1.
Uživatelské pracovní místo:
— pevný disk;
— operační paměť;
— síťové rozhraní.
Internet.
Korporátní síť organizace 2.
Hypervizor:
— síťové rozhraní;
— operační paměť;
— pevný disk.
Virtuální stroj:
— síťové rozhraní;
— operační paměť;
— pevný disk.
Kanál pro přenos času
Uživatelské pracovní místo:
— vstupně-výstupní prostředky;
— operační paměť;
— systémový časovač.
Internet.
Korporátní síť organizace 2,
Hypervizor:
— síťové rozhraní;
— operační paměť;
— systémový časovač.
Virtuální stroj:
— operační paměť;
— systémový časovač.
Kanál pro přenos řídicích příkazů
Uživatelské pracovní místo:
— vstupně-výstupní prostředky;
— operační paměť.
(Grafické uživatelské rozhraní softwaru CryptoARM)
Virtuální stroj:
— operační paměť;
— pevný disk.
(Automatizační skripty)
Kanál pro příjem výsledků práce
Uživatelské pracovní místo:
— vstupně-výstupní prostředky;
— operační paměť.
(Grafické uživatelské rozhraní softwaru CryptoARM)
Virtuální stroj:
— operační paměť;
— pevný disk.
(Soubory protokolů práce automatizačních skriptů)
Hrozby bezpečnosti na vyšší úrovni
Vysvětlení
Předpoklady přijaté při dekompozici hrozeb:
- Používají se odolné kryptografické algoritmy.
- Kryptografické algoritmy se používají bezpečným způsobem ve správných provozních režimech (například, není použita pro šifrování velkého objemu dat, zohledňuje se přijatelná zátěž na klíč atd.).
- Útočníkům jsou známy všechny používané algoritmy, protokoly a veřejné klíče.
- Útočníkům jsou dostupná k přečtení všechna zašifrovaná data.
- Útočníci jsou schopni reprodukovat jakékoli softwarové prvky v systému.
Dekonstrukce
U1. Kompromitace uzavřených kryptografických klíčů.
U2. Šifrování podvržených dat jménem legitimního odesílatele.
U3. Dešifrování zašifrovaných dat osobami, které nejsou legitimními příjemci dat (útočníky).
U4. Vytvoření elektronického podpisu legitimního podpisového zástupce pod podvrženými daty.
U5. Získání pozitivního výsledku kontroly elektronického podpisu podvržených dat.
U6. Chybné přijetí elektronických dokumentů k realizaci v důsledku problémů v organizaci elektronického oběhu dokumentů.
U7. Neautorizovaný přístup k chráněným datům během jejich zpracování SKZI.
U1. Kompromitace uzavřených kryptografických klíčů
U1.1. Získání uzavřeného klíče ze skladu uzavřených klíčů.
U1.2. Získání uzavřeného klíče z objektů prostředí fungování kryptografického prostředku, ve kterých může dočasně být.
Vysvětlení U1.2.
Mezi objekty, ve kterých může dočasně být uzavřený klíč, budou patřit:
- operativní paměť,
- dočasné soubory,
- swapovací soubory,
- hibernační soubory,
- soubory snapshotů „horkého“ stavu virtuálních strojů, včetně souborů obsahu operativní paměti virtuálních strojů, které byly pozastaveny.
U1.2.1. Extrakce uzavřených klíčů z běžící operativní paměti pomocí zmrazení modulů RAM, jejich extrakce a následné čtení dat (freeze attack).
Vysvětlení U1.2.1.
Příklad .
U1.3. Získání uzavřeného klíče z kanálu výměny uzavřených klíčů.
Vysvětlení U1.3.
Příklad realizace této hrozby bude uveden .
U1.4. Neautorizovaná modifikace kryptojádra, v důsledku které se uzavřené klíče stanou známými útočníkům.
U1.5. Kompromitace soukromého klíče v důsledku použití technických kanálů úniku informací (TKUI).
Vysvětlení U1.5.
Příklad .
U1.6. Kompromitace soukromého klíče v důsledku použití speciálních technických prostředků (STS), určených pro tajné snímání informací ("hmyz").
U1.7. Kompromitace soukromých klíčů během jejich uchovávání mimo SKZI.
Vysvětlení U1.7.
Například uživatel uchovává své klíčové nosiče v zásuvce pracovního stolu, odkud mohou být snadno vytaženy útočníky.
U2. Šifrování falešných dat jménem legitimního odesílatele
Vysvětlení
Toto nebezpečí je zvažováno pouze pro schémata šifrování dat s autentizací odesílatele. Příklady takových schémat jsou uvedeny v doporučeních pro standardizaci. . Pro ostatní kryptografické schémata toto nebezpečí neexistuje, protože šifrování probíhá na veřejných klíčích příjemce, které jsou obecně známé útočníkům.
Dekonstrukce
U2.1. Kompromitace soukromého klíče odesílatele:
U2.1.1. Odkaz: .
U2.2. Záměna vstupních dat v kanálu výměny veřejných dat.
Poznámky U2.2.
Příklady realizace tohoto nebezpečí jsou uvedeny níže. a .
U3. Dešifrování zašifrovaných dat osobami, které nejsou legitimními příjemci dat (útočníky).
Dekonstrukce
U3.1. Kompromitace soukromých klíčů příjemce zašifrovaných dat.
U3.1.1 Odkaz: .
U3.2. Záměna zašifrovaných dat v kanálu výměny chráněných dat.
U4. Vytváření elektronického podpisu legitimního signatáře na falešných datech.
Dekonstrukce
U4.1. Kompromitace soukromých klíčů elektronického podpisu legitimního signatáře.
U4.1.1 Odkaz: .
U4.2. Záměna podepisovaných dat v kanálu výměny veřejných dat.
Poznámka U4.2.
Příklady realizace tohoto nebezpečí jsou uvedeny níže. a .
U5. Získání pozitivního výsledku kontroly elektronického podpisu falešných dat.
Dekonstrukce
U5.1. Útočníci zachytávají v kanálu přenosu výsledků zprávu o negativním výsledku ověření elektronického podpisu a nahrazují ji zprávou s pozitivním výsledkem.
U5.2. Útočníci provádějí útok na důvěru v certifikáty podpisu (SCENÁŘ — všechny prvky jsou povinné):
U5.2.1. Útočníci generují veřejný a soukromý klíč elektronického podpisu. Pokud jsou v systému použity certifikáty klíčů elektronického podpisu, generují certifikát elektronického podpisu co nejvíce podobný certifikátu předpokládaného odesílatele dat, jehož zprávu chtějí falšovat.
U5.2.2. Útočníci provádějí neoprávněné změny v úložišti veřejných klíčů, přičemž generovanému veřejnému klíči přiřazují požadovanou úroveň důvěry a oprávnění.
U5.2.3. Útočníci podepisují falešná data dříve vytvořeným klíčem elektronického podpisu a vkládají je do kanálu výměny zabezpečených dat.
U5.3. Útočníci provádějí útok pomocí expired elektronických podpisů legálního podepisovatele (SCENÁŘ — všechny prvky jsou povinné):
U5.3.1. Útočníci kompromitují vypršené (v tuto chvíli neplatné) soukromé klíče elektronického podpisu legitimního odesílatele.
U5.3.2. Útočníci nahrazují čas v kanálu přenosu času na čas, kdy byly kompromitované klíče ještě platné.
U5.3.3. Útočníci podepisují falešná data dříve kompromitovaným klíčem elektronického podpisu a vkládají je do kanálu výměny zabezpečených dat.
U5.4. Útočníci provádějí útok pomocí kompromitovaných klíčů elektronického podpisu legálního podepisovatele (SCENÁŘ — všechny prvky jsou povinné):
U5.4.1. Útočníci vytvářejí kopii úložiště veřejných klíčů.
U5.4.2. Útočníci kompromitují soukromé klíče jednoho z legálních odesílatelů. Ten si všimne kompromitace, odvolá klíče, informace o odvolání klíče jsou umístěny v úložišti veřejných klíčů.
U5.4.3. Útočníci nahrazují úložiště veřejných klíčů dříve zkopírovaným.
U5.4.4. Útočníci podepisují falešná data dříve kompromitovaným klíčem elektronického podpisu a vkládají je do kanálu výměny zabezpečených dat.
U5.5. <…> z důvodu chyb v realizaci 2. a 3. fáze ověřování elektronického podpisu:
Vysvětlení U5.5.
Příklad realizace této hrozby je uveden .
U5.5.1. Ověření důvěryhodnosti certifikátu klíče elektronického podpisu pouze na základě důvěry k certifikátu, kterým byl podepsán, bez kontrol CRL nebo OCSP.
Vysvětlení U5.5.1.
Příklad implementace .
U5.5.2. Při vytváření řetězce důvěry k certifikátu nejsou analyzovány pravomoci vydávajících certifikátů
Vysvětlení U5.5.2.
Příklad útoku na certifikáty SSL/TLS.
Útočníci zakoupili legitimní certifikát pro svůj e-mail. Poté vytvořili podvodný certifikát webu a podepsali ho svým certifikátem. Pokud nebude provedena kontrola pravomocí, pak při kontrole řetězce důvěry bude považován za správný a podle toho bude také podvodný certifikát v pořádku.
U5.5.3. Při vytváření řetězce důvěry k certifikátu se neověřují mezilehlé certifikáty na odvolání.
U5.5.4. Aktualizace CRL probíhá méně často, než je je vydává certifikační autorita.
U5.5.5. Rozhodnutí o důvěře k elektronickému podpisu je přijato dříve, než je obdržena odpověď OCSP o stavu certifikátu, zaslaná na žádost podanou po čase vytvoření podpisu nebo dříve, než je obdržena následující CRL po vytvoření podpisu.
Vysvětlení U5.5.5.
V předpisech většiny CA je čas odvolání certifikátu považován za čas vydání nejbližší CRL, která obsahuje informace o odvolání certifikátu.
U5.5.6. Při příjmu podepsaných dat se neověřuje příslušnost certifikátu odesílateli.
Vysvětlení U5.5.6.
Příklad útoku. Ve vztahu k SSL certifikátům: nemůže být kontrolována shoda adresy volaného serveru s hodnotou pole CN v certifikátu.
Příklad útoku. Útočníci kompromitovali klíče elektronického podpisu jednoho z účastníků platebního systému. Poté hackli síť jiného účastníka a jeho jménem zaslali na vyúčtovací server platebního systému platební dokumenty podepsané kompromitovanými klíči. Pokud server analyzuje pouze důvěru a neověřuje shodu, pak budou podvodné dokumenty považovány za legitimní.
U6. Chybné přijetí elektronických dokumentů k realizaci v důsledku problémů v organizaci elektronického oběhu dokumentů.
Dekonstrukce
U6.1. Přijímající strana neodhaluje duplicity obdržených dokumentů.
Vysvětlení U6.1.
Příklad útoku. Útočníci mohou zachytit dokument, který je zasílán příjemci, i když je kryptograficky chráněn, a poté ho opakovaně poslat do kanálu pro přenos chráněných dat. Pokud příjemce nezjistí duplicity, budou všechny obdržené dokumenty považovány a zpracovávány jako různé dokumenty.
U7. Nepovoleno seznámení s chráněnými daty během jejich zpracování CKZ
Dekonstrukce
U7.1. v důsledku úniku informací přes boční kanály (side channel attack).
Vysvětlení U7.1.
Příklad .
U7.2. v důsledku neutralizace ochrany proti neoprávněnému přístupu k informacím zpracovávaným na CKZ:
U7.2.1. Využívání CKZ s porušením požadavků uvedených v dokumentaci k CKZ.
U7.2.2. , uskutečněné díky přítomnosti zranitelností v:
U7.2.2.1. prostředcích ochrany proti neoprávněnému přístupu.
U7.2.2.2. samotném CKZ.
U7.2.2.3. prostředí fungování kryptografických prostředků.
Příklady útoků
Níže uvedené scénáře nutně obsahují chyby v organizaci informační bezpečnosti a slouží pouze k ilustraci možných útoků.
Scénář 1. Příklad realizace hrozeb U2.2 a U4.2.
Popis objektu
SW APM KBR a CKZ SKAD Signatura je nainstalována na fyzickém počítači, který není připojen k výpočetní síti. Jako klíčový nosič se používá FKN vdToken v režimu práce s nevyjímatelným klíčem.
Regulace provádění výpočtů předpokládá, že specialisté na výpočty stahují elektronické zprávy v otevřené podobě (schéma starého APM KBR) z speciálního chráněného souborového serveru na svém pracovním počítači, poté je zaznamenávají na přenosném USB flash disku a přenášejí na APM KBR, kde je šifrují a podepisují. Poté odborník přenáší na přenosný nosič chráněné elektronické zprávy a poté je přes svůj pracovní počítač zapisuje na souborový server, odkud se dostávají na UTA a dále do platebního systému Banky Ruska.
V tomto případě budou kanály pro výměnu otevřených a chráněných dat zahrnovat: souborový server, pracovní počítač specialisty a přenosný nosič.
Útok
Útočníci nainstalují na pracovní počítač specialisty systém vzdáleného ovládání a v momentě, kdy se zapisují na přenositelný médium platební příkazy (elektronické zprávy), v otevřeném formátu zamění obsah jednoho z nich. Specialista přesune platební příkazy na AРМ КБР, podepíše je a zašifruje, aniž by si všiml této výměny (například kvůli velkému počtu platebních příkazů v dávce, únavě atd.). Poté fiktivní platební příkaz, procházející technologickým řetězcem, skončí v platebním systému Banky Ruska.
Scénář 2. Příklad realizace hrozeb U2.2 a U4.2.
Popis objektu
Počítač s nainstalovanými AРМ КБР, SKAD Signatura a připojeným klíčovým médiem FKN vdToken funguje v vymezeném prostoru bez přístupu ze strany personálu.
Specialista na platby se připojuje k AРМ КБР v režimu vzdáleného přístupu pomocí protokolu RDP.
Útok
Útočníci zachycují přihlašovací údaje, pomocí kterých se specialisté na platby připojují a pracují s AРМ КБР (například pomocí škodlivého kódu na jeho počítači). Poté se připojí jeho jménem a odešlou do platebního systému Banky Ruska falešný platební příkaz.
Scénář 3. Příklad realizace hrozby U1.3.
Popis objektu
Zvažme jednu z hypotetických variant realizace integračních modulů "ABS-КБР" pro novou schéma (АРМ КБР-Н), při které se elektronický podpis odchozích dokumentů provádí na straně ABS. Předpokládáme, že ABS funguje na bázi operačního systému, který není podporován SKZI SKAD Signatura, a proto byl kryptografický funkční aspekt přenesen na samostatnou virtuální stroj — integrační modul "ABS-КБР".
Jako klíčové médium se používá běžný USB-token, který funguje v režimu odnímatelného klíče. Při připojení klíčového média k hypervizoru se ukázalo, že v systému nejsou volné USB porty, a proto bylo rozhodnuto připojit USB-token prostřednictvím síťového USB hubu a na virtuální stroj nainstalovat klienta USB-over-IP, který bude realizovat spojení s hubem.
Útok
Útočníci zachytili soukromý klíč elektronického podpisu z komunikačního kanálu mezi USB hubem a hypervizorem (data byla předávána v nešifrované podobě). S tímto soukromým klíčem vytvořili útočníci falešný platební příkaz, podepsali ho elektronickým podpisem a poslali k realizaci do APM KBR-N.
Scénář 4. Příklad realizace hrozeb U5.5.
Popis objektu
Zvažme stejnou schématu jako v předchozím scénáři. Předpokládejme, že elektronické zprávy přicházející z APM KBR-N se dostávají do složky …SHAREIn, a ty, které jsou odesílány do APM KBR-N a dále do platebního systému Banky Ruska, se dostávají do …SHAREout.
Také předpokládejme, že při realizaci integračního modulu se seznamy odvolaných certifikátů aktualizují pouze při opětovném vydání kryptografických klíčů, a také to, že elektronické zprávy, které přišly do složky …SHAREIn, jsou kontrolovány pouze na základě ochrany integrity a důvěry k veřejnému klíči elektronického podpisu.
Útok
Útočníci, kteří využili ukradené klíče z předchozího scénáře, podepsali falešný platební příkaz obsahující údaje o převodu peněz na účet klienta-podvodníka a vložili jej do kanálu pro výměnu chráněných dat. Jelikož není prováděna kontrola, že platební příkaz byl podepsán skutečně Bankou Ruska, je akceptován k realizaci.
Zdroj: habr.com
