Odkazy na další části studie
- (Jste tady)
Tento článek završuje cyklus publikací věnovaných zajištění informační bezpečnosti bankovních bezhotovostních plateb. Zde se podíváme na obecné modely hrozeb, na které se odkazuje :
- .
- .
- .
- .
HABR-VAROVÁNÍ!!! Vážení Khabrovite, toto není zábavný příspěvek.
Je požadováno více než 40 stran materiálů skrytých pod řezem pomoci s prací nebo studiem lidé, kteří se specializují na bankovnictví nebo informační bezpečnost. Tyto materiály jsou konečným produktem studie a jsou psány suchým formálním tónem. Ve skutečnosti se jedná o polotovary pro interní dokumenty o bezpečnosti informací.No, tradiční „Použití informací z článku k nezákonným účelům je trestné podle zákona“. Produktivní čtení!
Informace pro čtenáře, kteří čtou studii počínaje touto publikací.
O čem studie je
Čtete příručku pro specialistu odpovědného za zajištění informační bezpečnosti plateb v bance.
Prezentační logika
Na začátku v и je uveden popis předmětu ochrany. Pak dovnitř říká, jak vytvořit systém ochrany, a hovoří o nutnosti vytvořit model hrozeb. V Vypráví o tom, co jsou modely hrozeb a jak se tvoří. V и je uvedena analýza skutečných útoků. и obsahovat popis modelu hrozby sestaveného s ohledem na informace ze všech předchozích dílů.
TYPICKÝ MODEL HROZEB. INTERNETOVÉ PŘIPOJENÍ
Objekt ochrany, pro který je použit model hrozby (rozsah)
Předmětem ochrany jsou data přenášená prostřednictvím síťového připojení fungujícího v datových sítích vybudovaných na bázi TCP/IP stacku.
architektura
Popis prvků architektury:
- "koncové uzly" — uzly, které si vyměňují chráněné informace.
- "Mezilehlé uzly" - prvky sítě pro přenos dat: směrovače, přepínače, přístupové servery, proxy servery a další zařízení - přes které je přenášen provoz síťového připojení. Obecně platí, že síťové připojení může fungovat bez mezilehlých uzlů (přímo mezi koncovými uzly).
Bezpečnostní hrozby nejvyšší úrovně
Rozklad
U1. Neoprávněný přístup k přenášeným datům.
U2. Neoprávněná úprava přenášených dat.
U3. Porušení autorství přenášených dat.
U1. Neoprávněný přístup k přenášeným datům
Rozklad
U1.1. <...>, prováděné na konečných nebo mezilehlých uzlech:
U1.1.1. <…> čtením dat, když jsou v úložných zařízeních uzlu:
U1.1.1.1. <…> v paměti RAM.
Vysvětlivky k V1.1.1.1.
Například při zpracování dat síťovým zásobníkem uzlu.
U1.1.1.2. <…> v energeticky nezávislé paměti.
Vysvětlivky k V1.1.1.2.
Například při ukládání přenášených dat do mezipaměti, dočasných souborů nebo stránkovacích souborů.
Y1.2. <…> prováděné na uzlech datové sítě třetích stran:
U1.2.1. <...> zachycením všech paketů, které spadají do síťového rozhraní uzlu:
Vysvětlivky k V1.2.1.
Všechny pakety jsou zachyceny přepnutím síťové karty do promiskuitního režimu (promiskuitní režim pro kabelové adaptéry nebo režim monitoru pro wi-fi adaptéry).
U1.2.2. <…> prováděním útoků typu man-in-the-middle (MiTM), ale bez úpravy přenášených dat (nepočítaje servisní data síťových protokolů).
Y1.2.2.1. Odkaz: .
Y1.3. <...>, prováděné z důvodu úniku informací technickými kanály (TCUI) z fyzických uzlů nebo komunikačních linek.
U1.4. <...>, prováděné pro instalaci speciálních technických prostředků (STS) na koncových nebo mezilehlých uzlech, určených pro skryté odstraňování informací.
U2. Neoprávněná úprava přenášených dat
Rozklad
U2.1. <...>, prováděné na konečných nebo mezilehlých uzlech:
Y2.1.1. <...> čtením a úpravou dat, když jsou v úložných zařízeních uzlů:
Y2.1.1.1. <...> v paměti RAM:
Y2.1.1.2. <…> v energeticky nezávislé paměti:
Y2.2. <...> prováděné na uzlech datové sítě třetích stran:
U2.2.1. <…> prováděním útoků Man-in-the-Middle (MiTM) a přesměrováním provozu na škodlivého hostitele:
Y2.2.1.1. Fyzické připojení zařízení útočníků k přerušení síťového připojení.
Y2.2.1.2. Implementace útoků na síťové protokoly:
Y2.2.1.2.1. <…> správa virtuální místní sítě (VLAN):
Y2.2.1.2.1.1. .
Y2.2.1.2.1.2. Neoprávněná úprava nastavení VLAN na přepínačích nebo směrovačích.
Y2.2.1.2.2. <…> směrování provozu:
Y2.2.1.2.2.1. Neoprávněná úprava statických směrovacích tabulek směrovačů.
Y2.2.1.2.2.2. Oznamování falešných cest útočníky prostřednictvím dynamických směrovacích protokolů.
Y2.2.1.2.3. <…> automatická konfigurace:
Y2.2.1.2.3.1. .
Y2.2.1.2.3.2. .
Y2.2.1.2.4. <…> adresování a rozlišení jmen:
Y2.2.1.2.4.1. .
Y2.2.1.2.4.2. .
Y2.2.1.2.4.3. Provádění neoprávněných změn v místních souborech názvů hostitelů (hosts, lmhosts atd.)
U3. Porušení autorství přenášených dat
Rozklad
Y3.1. Neutralizace mechanismů pro určování autorství informací uvedením nepravdivých informací o autorovi nebo zdroji dat:
Y3.1.1. Změna informací o autorovi obsažených v přenášených informacích.
Y3.1.1.1. Neutralizace kryptografické ochrany integrity a autorství přenášených dat:
Y3.1.1.1.1. Odkaz: .
Y3.1.1.2. Neutralizace ochrany autorství přenášených dat realizovaná pomocí jednorázových potvrzovacích kódů:
Y3.1.1.2.1. .
Y3.1.2. Změna informací o zdroji přenášených informací:
Y3.1.2.1. .
Y3.1.2.2. .
TYPICKÝ MODEL HROZEB. INFORMAČNÍ SYSTÉM VYBUDOVANÝ NA ZÁKLADĚ ARCHITEKTURY KLIENT-SERVER
Objekt ochrany, pro který je použit model hrozby (rozsah)
Předmětem ochrany je informační systém vybudovaný na bázi 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.
- "Internetové připojení" — kanál pro výměnu informací mezi Klientem a Serverem procházející sítí pro přenos dat. Podrobnější popis modelu prvku viz .
Omezení
Při modelování objektu jsou nastavena následující omezení:
- Uživatel interaguje s informačním systémem v rámci omezených časových úseků, nazývaných pracovní sezení.
- Na začátku každé relace je uživatel identifikován, ověřen a autorizován.
- Veškeré chráněné informace jsou uloženy na serverové části informačního systému.
Bezpečnostní hrozby nejvyšší úrovně
Rozklad
U1. Útočníci provádějící neoprávněné akce jménem legitimního uživatele.
U2. Neoprávněná úprava chráněných informací při jejich zpracování serverovou částí informačního systému.
U1. Útočníci provádějící neoprávněné akce jménem legitimního uživatele
Vysvětlení
V informačních systémech se korelace akcí s uživatelem, který je provedl, obvykle provádí pomocí:
- systémové protokoly (logy).
- speciální atributy datových objektů obsahující informace o uživateli, který je vytvořil nebo upravil.
Ve vztahu k pracovnímu jednání lze tuto hrozbu rozložit na:
- <…> provedené v rámci uživatelské relace.
- <…> provedené mimo relaci uživatele.
Uživatelskou relaci lze zahájit:
- Od samotného uživatele.
- Vetřelci.
V této fázi bude přechodný rozklad této hrozby vypadat takto:
U1.1. Neoprávněné akce provedené v rámci uživatelské relace:
U1.1.1. <…> nastavená napadeným uživatelem.
U1.1.2. <…> nainstalované útočníky.
Y1.2. Mimo relaci uživatele byly provedeny neoprávněné akce.
Z pohledu objektů informační infrastruktury, které mohou být napadeny vetřelci, bude rozklad středních hrozeb vypadat takto:
prvky
Dekompozice hrozeb
Y1.1.1.
Y1.1.2.
Y1.2.
Zákazník
Y1.1.1.1.
Y1.1.2.1.
internetové připojení
Y1.1.1.2.
Server
Y1.2.1.
Rozklad
U1.1. Neoprávněné akce provedené v rámci uživatelské relace:
U1.1.1. <…> nastavené napadeným uživatelem:
U1.1.1.1. Útočníci jednali nezávisle na klientovi:
У1.1.1.1.1 Útočníci použili standardní nástroje pro přístup k informačnímu systému:
Y1.1.1.1.1.1. Útočníci použili fyzické vstupně/výstupní prostředky Klienta (klávesnice, myš, monitor nebo dotyková obrazovka mobilního zařízení):
Y1.1.1.1.1.1.1. Útočníci jednali během časových úseků, kdy je relace aktivní, jsou k dispozici I/O zařízení a uživatel je pryč.
Y1.1.1.1.1.2. Ke správě Klienta útočníci použili nástroje pro vzdálenou správu (standardní nebo poskytované škodlivým kódem):
Y1.1.1.1.1.2.1. Útočníci jednali během časových úseků, kdy je relace aktivní, jsou k dispozici I/O zařízení a uživatel je pryč.
Y1.1.1.1.1.2.2. Útočníci použili nástroje vzdálené správy, jejichž činnost je pro napadeného uživatele neviditelná.
U1.1.1.2. Útočníci podvrhli data v síťovém spojení mezi Klientem a Serverem a upravili je tak, aby byla vnímána jako akce legitimního uživatele:
Y1.1.1.2.1. Odkaz: .
Y1.1.1.3. Útočníci donutili uživatele provést akce, které určili pomocí metod sociálního inženýrství.
U1.1.2 <…> nastavené útočníky:
Y1.1.2.1. Útočníci jednali z klienta (И):
Y1.1.2.1.1. Útočníci zneškodnili přístupový systém informačního systému:
Y1.1.2.1.1.1. Odkaz: .
Y1.1.2.1.2. Zločinci používali běžné prostředky přístupu k informačnímu systému
U1.1.2.2. Útočníci jednali z jiných uzlů sítě pro přenos dat, ze kterých je možné navázat síťové spojení se Serverem (И):
Y1.1.2.2.1. Útočníci zneškodnili přístupový systém informačního systému:
Y1.1.2.2.1.1. Odkaz: .
Y1.1.2.2.2. Útočníci použili nestandardní prostředky přístupu k informačnímu systému.
Vysvětlivky Y1.1.2.2.2.
Útočníci by mohli nainstalovat běžného klienta informačního systému na uzel třetí strany nebo mohli použít nestandardní software, který implementuje standardní výměnné protokoly mezi klientem a serverem.
P1.2 Neoprávněné akce provedené mimo relaci uživatele.
S1.2.1 Útočníci provedli neoprávněné akce a následně provedli neoprávněné změny v protokolech informačního systému nebo speciálních atributech datových objektů, což naznačuje, že akce, kterých se dopustili, byly provedeny legitimním uživatelem.
U2. Neoprávněná úprava chráněných informací při jejich zpracování serverovou částí informačního systému
Rozklad
Y2.1. Útočníci upravují chráněné informace pomocí standardních nástrojů informačního systému a dělají to jménem legitimního uživatele.
Y2.1.1. Odkaz: .
Y2.2. Útočníci modifikují chráněné informace pomocí mechanismů přístupu k datům, které nejsou zajištěny běžným provozem informačního systému.
U2.2.1. Útočníci upravují soubory obsahující chráněné informace:
Y2.2.1.1. <…> pomocí mechanismů pro manipulaci se soubory poskytovaných operačním systémem.
Y2.2.1.2. <...> provokací k obnovení souborů z neoprávněně upravené zálohy.
U2.2.2. Škodlivci upravují chráněné informace uložené v databázi (И):
Y2.2.2.1. Útočníci neutralizují systém řízení přístupu DBMS:
Y2.2.2.1.1. Odkaz: .
Y2.2.2.2. Útočníci upravují informace pomocí standardních rozhraní DBMS pro přístup k datům.
Y2.3. Škodlivci upravují chráněné informace neoprávněnou úpravou pracovních algoritmů softwaru, který je zpracovává.
Y2.3.1. Jsou provedeny úpravy ve zdrojovém kódu softwaru.
Y2.3.1. Změny se provádějí ve strojovém kódu softwaru.
Y2.4. Útočníci upravují chráněné informace využíváním zranitelností v softwaru informačního systému.
Y2.5. Útočníci upravují chráněné informace při jejich přenosu mezi komponenty serverové části informačního systému (například databázový server a aplikační server):
Y2.5.1. Odkaz: .
TYPICKÝ MODEL HROZEB. SYSTÉM ŘÍZENÍ PŘÍSTUPU
Objekt ochrany, pro který je použit model hrozby (rozsah)
Objekt ochrany, pro který je tento model hrozby aplikován, odpovídá objektu ochrany modelu hrozby: „Typický model hrozby. Informační systém vybudovaný na bázi architektury klient-server.
Systém řízení přístupu uživatelů v tomto modelu hrozeb je chápán jako komponenta informačního systému, která implementuje následující funkce:
- Identifikace uživatele.
- Ověření uživatele.
- Uživatelská oprávnění.
- Protokolování uživatelských akcí.
Bezpečnostní hrozby nejvyšší úrovně
Rozklad
U1. Neoprávněné vytvoření relace jménem legitimního uživatele.
U2. Neoprávněné zvýšení uživatelských oprávnění v informačním systému.
U1. Neoprávněné vytvoření relace jménem legitimního uživatele
Vysvětlení
Rozklad této hrozby v obecném případě bude záviset na typu použitých systémů identifikace a autentizace uživatele.
V tomto modelu bude uvažován pouze systém identifikace a autentizace uživatele pomocí textového přihlašovacího jména a hesla. V tomto případě budeme předpokládat, že přihlašovací údaje uživatele jsou veřejnými informacemi známými útočníkům.
Rozklad
U1.1. <…> kompromitováním 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ětlivky Y1.1.1.
Pověřovací údaje lze například zapsat na lepicí papír nalepený na monitoru.
U1.1.2. Uživatel omylem nebo úmyslně předal přístupové údaje útočníkům.
Y1.1.2.1. Uživatel při vstupu vyslovil přihlašovací údaje nahlas.
U1.1.2.2. Uživatel úmyslně předal své přihlašovací údaje:
Y1.1.2.2.1. <…> kolegové v práci.
Vysvětlivky Y1.1.2.2.1.
Třeba proto, aby to mohli nahradit obdobím nemoci.
Y1.1.2.2.2. <…> protistranám zaměstnavatele provádějícího práce na objektech informační infrastruktury.
Y1.1.2.2.3. <…> třetím stranám.
Vysvětlivky Y1.1.2.2.3.
Jedním, ale ne jediným způsobem, jak tuto hrozbu implementovat, je použití metod sociálního inženýrství útočníků.
U1.1.3. Útočníci si brutálně vynutili pověření:
Y1.1.3.1. <…> pomocí běžných přístupových mechanismů.
U1.1.3.2. <...> dříve zachycenými kódy (například hash hesel) pro ukládá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 ze síťového připojení mezi klientem a serverem:
Y1.1.5.1. Odkaz: .
U1.1.6. Útočníci vytáhli přihlašovací údaje ze záznamů systémů sledování práce:
U1.1.6.1. <…> video monitorovací systémy (v případě, že byly během provozu zaznamenány stisky kláves na klávesnici).
U1.1.6.2. <…> systémy pro sledování akcí zaměstnanců u počítače
Vysvětlivky Y1.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 chybám v procesu přenosu.
Vysvětlivky Y1.1.7.
Například předávání hesel v čistém textu e-mailem.
U1.1.8. Útočníci se přihlašovací údaje dozvěděli monitorováním relace uživatele pomocí systémů vzdálené správy.
U1.1.9. Útočníci získali pověření v důsledku jejich úniku přes technické kanály (TCUE):
U1.1.9.1. Útočníci špehovali, jak uživatel zadává přihlašovací údaje z klávesnice:
E1.1.9.1.1 Útočníci se nacházeli v těsné blízkosti uživatele a na vlastní oči viděli zadání přihlašovacích údajů.
C1.1.9.1.1 Vysvětlivky
Mezi takové případy patří akce kolegů v práci nebo případ, kdy je uživatelská klávesnice viditelná pro návštěvníky organizace.
E1.1.9.1.2 Útočníci použili další technické prostředky, jako je dalekohled nebo bezpilotní letoun, a zahlédli vstup pověřovacích údajů oknem.
U1.1.9.2. Útočníci vytáhli přihlašovací údaje ze záznamů rádiové výměny mezi klávesnicí a systémovou jednotkou počítače, pokud byli připojeni přes rádiové rozhraní (například Bluetooth).
U1.1.9.3. Útočníci zachytili přihlašovací údaje tak, že je propustili kanálem falešného elektromagnetického záření a snímačů (PEMIN).
Vysvětlivky Y1.1.9.3.
Příklady útoků и .
U1.1.9.4. Útočník zachytil zadání přihlašovacích údajů z klávesnice pomocí speciálních technických prostředků (STS) určených ke skrytému odstranění informací.
Vysvětlivky Y1.1.9.4.
Příklady .
U1.1.9.5. Útočníci zachytili zadávání přihlašovacích údajů z klávesnice pomocí
analýza signálu Wi-Fi modulovaného procesem stisknutí kláves uživatelem.
Vysvětlivky Y1.1.9.5.
příklad .
U1.1.9.6. Útočníci zachytili zadání přihlašovacích údajů z klávesnice analýzou zvuků stisku kláves.
Vysvětlivky Y1.1.9.6.
příklad .
U1.1.9.7. Útočníci zachytili zadání přihlašovacích údajů z klávesnice mobilního zařízení analýzou údajů z akcelerometru.
Vysvětlivky Y1.1.9.7.
příklad .
U1.1.10. <...> dříve uložený v Klientovi.
Vysvětlivky Y1.1.10.
Uživatel by si například mohl uložit uživatelské jméno a heslo do prohlížeče pro přístup na konkrétní stránku.
U1.1.11. Útočníci kompromitovali přihlašovací údaje kvůli chybám v procesu zrušení přístupu uživatele.
Vysvětlivky Y1.1.11.
Například po propuštění uživatele zůstaly jeho účty nezablokovány.
Y1.2. <…> využíváním zranitelností v systému řízení přístupu.
U2. Neoprávněné zvýšení uživatelských oprávnění v informačním systému
Rozklad
P2.1 <...> provedením neoprávněných změn údajů obsahujících informace o oprávněních uživatele.
U2.2 <…> využíváním zranitelností v systému řízení přístupu.
Y2.3. <…> kvůli chybám v procesu řízení přístupu uživatelů.
Vysvětlivky Y2.3.
Příklad 1. Uživateli byl poskytnut větší přístup k práci, než potřeboval kvůli oficiálním potřebám.
Příklad 2: Po převedení uživatele na jinou pozici nebyla zrušena dříve udělená přístupová práva.
TYPICKÝ MODEL HROZEB. INTEGRAČNÍ MODUL
Objekt ochrany, pro který je použit model hrozby (rozsah)
Integrační modul - sada objektů informační infrastruktury určená k organizaci výměny informací mezi informačními systémy.
Vzhledem k tomu, že v podnikových sítích není vždy možné jednoznačně oddělit jeden informační systém od druhého, lze integrační modul považovat i za propojení komponent v rámci jednoho informačního systému.
architektura
Zobecněné schéma integračního modulu vypadá takto:
Popis prvků architektury:
- "Exchange Server (CO)" – uzel / služba / komponenta informačního systému, která plní 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 není jejich součástí.
Příklady "zprostředkovatelé" mohou to být e-mailové služby, podniková servisní sběrnice / architektura SoA, souborové servery třetích stran atd. V obecném případě nemusí integrační modul obsahovat „Zprostředkovatele“. - "Software pro zpracování dat" - sada programů, které implementují protokoly výměny dat a konverzi formátu.
Například převod dat z formátu UFEBS do formátu ABS, změna stavů zpráv při přenosu atp. - "Internetové připojení" odpovídá objektu popsanému v typickém modelu hrozby "Síťové připojení". Některá síťová připojení z těch uvedených na obrázku výše nemusí být.
Příklady integračních modulů
Schéma 1. Integrace ABS a AWP KBR prostřednictvím souborového serveru třetí strany
Pro realizaci plateb nahraje pověřený pracovník banky elektronické platební doklady z ABS a uloží je do souboru (vlastního formátu, např. SQL dump) v síťové složce (…SHARE) souborového serveru. Poté je tento soubor převeden na sadu souborů ve formátu UFEBS pomocí skriptu převodníku, které jsou následně čteny CBD AWP.
Poté pověřený zaměstnanec - uživatel AWS CBD - zašifruje a podepíše přijatý soubor a odešle je do platebního systému Bank of Russia.
Po přijetí plateb od Bank of Russia je AWP CBR dešifruje a zkontroluje elektronický podpis, poté je zapíše jako sadu souborů ve formátu UFEBS na souborový server. Před importem platebních dokladů do ABS jsou převedeny pomocí script-konvertoru z formátu UFEBS do formátu ABS.
Budeme předpokládat, že v tomto schématu ABS pracuje na jednom fyzickém serveru, CBD pracovní stanice pracuje na vyhrazeném počítači a konvertor skriptů pracuje na souborovém serveru.
Korespondence objektů uvažovaného schématu s prvky modelu integračního modulu:
"Výměnné servery ze strany ABS" - ABS server.
"Výměnné servery ze strany AWP KBR" - počítačová pracovní stanice KBR.
"Zprostředkovatel" - souborový server třetí strany.
"Software pro zpracování dat" - převodník skriptů.
Schéma 2. Integrace ABS a AWS KBR při umístění sdílené síťové složky s platbami na AWS KBR
Vše je podobné schématu 1, ale není použit samostatný souborový server, místo toho je na počítači s AWS CBD umístěna síťová složka (…SHARE) s elektronickými platebními doklady. Převodník skriptů také funguje na AWP CBD.
Korespondence objektů uvažovaného schématu s prvky modelu integračního modulu:
Podobné jako schéma 1, ale "Zprostředkovatel" nepoužívá.
Schéma 3. Integrace ABS a AWS KBR-N prostřednictvím IBM WebSphera MQ a podepisování elektronických dokumentů "na straně ABS"
ABS funguje na platformě, kterou nepodporuje CIPF SKAD Signature. Odchozí elektronické dokumenty jsou podepisovány na speciálním serveru pro elektronický podpis (ES Server). Stejný server ověřuje elektronický podpis pod dokumenty přicházejícími z Bank of Russia.
ABS nahraje na ES Server soubor s platebními dokumenty ve vlastním formátu.
Server ES pomocí skriptu převodníku převede soubor na elektronické zprávy ve formátu UFEBS, načež jsou elektronické zprávy podepsány a přeneseny do IBM WebSphere MQ.
AWS KBR-N přistupuje k IBM WebSphere MQ a přijímá odtud podepsané platební zprávy, načež je pověřený zaměstnanec - uživatel AWS KBR - zašifruje a odešle do platebního systému Bank of Russia.
Po přijetí plateb od Ruské banky je AWP KBR-N dešifruje a ověří elektronický podpis. Úspěšně zpracované platby ve formě dešifrovaných a podepsaných elektronických zpráv ve formátu UFEBS jsou přenášeny do IBM WebSphere MQ, odkud jsou přijímány ES Serverem.
ES server ověří elektronický podpis přijatých plateb a uloží je do souboru ve formátu ABS. Poté pověřený pracovník – uživatel ABS – nahraje předepsaným způsobem výsledný soubor do ABS.
Korespondence objektů uvažovaného schématu s prvky modelu integračního modulu:
"Výměnný server ze strany ABS" - ABS server.
"Výměnný server ze strany AWP KBR" - počítačová pracovní stanice KBR.
"Zprostředkovatel" – ES server a IBM WebSphere MQ.
"Software pro zpracování dat" – konvertor skriptů, podpis CIPF SCAD na ES Serveru.
Schéma 4. Integrace serveru RBS a ABS prostřednictvím rozhraní API poskytovaného vyhrazeným serverem pro výměnu informací
Předpokládáme, že banka používá několik vzdálených bankovních systémů (RBS):
- "Internet Client-Bank" pro fyzické osoby (ICB FL);
- "Internetový klient-Banka" pro právnické osoby (ICB LE).
Pro zajištění bezpečnosti informací probíhá veškerá interakce ABS se systémy RB prostřednictvím vyhrazeného výměnného serveru fungujícího v rámci informačního systému ABS.
Dále se budeme zabývat procesem interakce systému RBS ICB LE s ABS.
Server RBS po obdržení řádně ověřeného platebního příkazu od klienta musí na jeho základě vytvořit příslušný dokument v ABS. K tomu pomocí API přenáší informace na burzovní server, který zase zadává data do ABS.
Při změně zůstatků na účtu klienta ABS generuje elektronická upozornění, která jsou pomocí burzovního serveru přenášena na server RBS.
Korespondence objektů uvažovaného schématu s prvky modelu integračního modulu:
"Výměnný server od RBS" – server RBS IKB YUL.
"Výměnný server ze strany ABS" - výměnný server.
"Zprostředkovatel" - chybí.
"Software pro zpracování dat" – Komponenty RB Server odpovědné za používání rozhraní API Exchange Server, komponenty Exchange Server zodpovědné za používání ABS API.
Bezpečnostní hrozby nejvyšší úrovně
Rozklad
U1. Zavedení nepravdivých informací pachateli prostřednictvím integračního modulu.
U1. Zavedení nepravdivých informací útočníky prostřednictvím integračního modulu
Rozklad
U1.1. Neoprávněná úprava legitimních dat při jejich přenosu přes síťová připojení:
Odkaz U1.1.1: .
Y1.2. Předávání nepravdivých údajů prostřednictvím komunikačních kanálů jménem legitimního účastníka burzy:
Odkaz U1.1.2: .
Y1.3. Neoprávněná úprava legitimních údajů při jejich zpracování na Exchange Serverech nebo Zprostředkovateli:
Y1.3.1. Odkaz: .
U1.4. Vytváření falešných dat na Exchange Serverech nebo Zprostředkovateli jménem legitimního účastníka burzy:
Y1.4.1. Odkaz:
Y1.5. Neoprávněná úprava údajů při jejich zpracování pomocí softwaru pro zpracování údajů:
U1.5.1. <…> z důvodu zavedení neoprávněných změn narušitelů do nastavení (konfigurace) softwaru pro zpracování dat.
U1.5.2. <…> kvůli neoprávněným změnám ve spustitelných souborech softwaru pro zpracování dat ze strany narušitelů.
U1.5.3. <...> kvůli interaktivnímu ovládání softwaru pro zpracování dat útočníky.
TYPICKÝ MODEL HROZEB. SYSTÉM OCHRANY KRYPTOGRAFICKÝCH INFORMACÍ
Objekt ochrany, pro který je použit model hrozby (rozsah)
Předmětem ochrany je kryptografický systém ochrany informací sloužící k zajištění bezpečnosti informačního systému.
architektura
Základem každého informačního systému je aplikační software (software), který implementuje jeho cílovou funkcionalitu.
Kryptografická ochrana je v tomto případě obvykle realizována voláním kryptografických primitiv z obchodní logiky aplikačního softwaru, která jsou umístěna ve specializovaných knihovnách – krypto-kernelech.
Kryptografická primitiva zahrnují nízkoúrovňové kryptografické funkce, jako jsou:
- šifrovat/dešifrovat blok dat;
- vytvořit / ověřit elektronický podpis bloku dat;
- vypočítat hashovací funkci datového bloku;
- vygenerovat / nahrát / nahrát klíčové informace;
- atd.
Obchodní logika aplikačního softwaru, využívající kryptografická primitiva, implementuje funkcionalitu vyšší úrovně:
- zašifrovat soubor klíči vybraných příjemců;
- vytvořit zabezpečené síťové připojení;
- informovat o výsledcích ověření elektronického podpisu;
- a tak dále.
Interakce obchodní logiky a kryptojádra může být provedena:
- přímo, voláním kryptografických primitiv z dynamických knihoven kryptokernelu (.DLL - pro Windows, .SO - pro Linux) obchodní logikou;
- přímo, prostřednictvím kryptografických rozhraní - wrapperů, například MS Crypto API, Java Cryptography Architecture, PKCS # 11 atd. V tomto případě se obchodní logika odkazuje na kryptografické rozhraní a to překládá volání na odpovídající kryptografické jádro, které v tomto případě se nazývá poskytovatel kryptoměn. Použití kryptografických rozhraní umožňuje aplikačnímu softwaru abstrahovat od konkrétních kryptografických algoritmů a být flexibilnější.
Existují dvě typická schémata pro organizaci kryptojádra:
Schéma 1 - Monolitické krypto-jádro
Schéma 2 - Split Crypto Core
Prvky ve výše uvedených diagramech mohou být buď samostatné softwarové moduly běžící na stejném počítači, nebo síťové služby interagující v rámci počítačové sítě.
Při použití systémů sestavených podle schématu 1 aplikační software a krypto-jádro pracují v rámci jednoho prostředí pro provoz krypto-prostředku (CFC), například na stejném počítači se stejným operačním systémem. Uživatel systému může zpravidla ve stejném operačním prostředí spouštět další programy, včetně těch, které obsahují škodlivý kód. Za takových podmínek existuje vážné riziko úniku soukromých kryptografických klíčů.
Pro minimalizaci rizika se používá schéma 2, ve kterém je kryptojádro rozděleno na dvě části:
- První část spolu s aplikačním softwarem pracuje v nedůvěryhodném prostředí, kde hrozí napadení škodlivým kódem. Tuto část budeme nazývat „softwarová část“.
- Druhá část funguje v důvěryhodném prostředí na vyhrazeném zařízení, které obsahuje úložiště soukromých klíčů. Od této chvíle budeme na tuto část odkazovat jako na „hardwarovou část“.
Rozdělení krypto-kernelu na softwarovou a hardwarovou část je velmi podmíněné. Na trhu existují systémy postavené podle schématu s rozděleným kryptografickým jádrem, ale jejich „hardwarová“ část je prezentována ve formě obrazu virtuálního stroje – virtuálního HSM ().
Interakce obou částí kryptojádra probíhá tak, že soukromé kryptografické klíče nejsou nikdy přeneseny do softwarové části, a tudíž nemohou být odcizeny pomocí škodlivého kódu.
Interakční rozhraní (API) a sada kryptografických primitiv poskytovaných aplikačnímu softwaru kryptojádrem jsou v obou případech stejné. Rozdíl spočívá ve způsobu jejich implementace.
Takže při použití schématu s rozděleným kryptojádrem se interakce mezi softwarem a hardwarem provádí podle následujícího principu:
- Kryptografická primitiva, která nevyžadují použití soukromého klíče (například výpočet hashovací funkce, ověření elektronického podpisu atd.), provádí software.
- Kryptografická primitiva využívající soukromý klíč (vytvoření elektronického podpisu, dešifrování dat atd.) provádí hardware.
Ukažme si fungování rozděleného kryptojádra na příkladu vytvoření elektronického podpisu:
- Softwarová část vypočítá hašovací funkci podepsaných dat a předá tuto hodnotu hardwaru prostřednictvím výměnného kanálu mezi kryptojádry.
- Hardwarová část pomocí soukromého klíče a hashe vygeneruje hodnotu elektronického podpisu a přenese ji do softwarové části výměnným kanálem.
- Softwarová část vrátí přijatou hodnotu do aplikačního softwaru.
Funkce kontroly 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ého výsledku ověření elektronického podpisu je dosaženo pouze tehdy, jsou-li úspěšně dokončeny všechny fáze ověření.
Fáze 1. Kontrola integrity dat a autorství dat.
Obsah jeviště. Elektronický podpis dat je ověřen podle odpovídajícího kryptografického algoritmu. Úspěšné dokončení této fáze znamená, že data nebyla od jejich podpisu změněna a že podpis byl proveden soukromým klíčem odpovídajícím veřejnému klíči pro ověření elektronického podpisu.
Umístění jeviště: kryptokernel.
Fáze 2. Kontrola důvěry ve veřejný klíč podepisujícího a kontrola doby platnosti soukromého klíče elektronického podpisu.
Obsah jeviště. Etapa se skládá ze dvou mezistupňů. První z nich zjišťuje, zda byl veřejný klíč pro ověření elektronického podpisu důvěryhodný v době podepisování dat. Druhý zjišťuje, zda byl soukromý klíč elektronického podpisu platný v době podpisu dat. V obecném případě se doby platnosti těchto klíčů nemusí shodovat (například u kvalifikovaných certifikátů klíčů pro ověřování elektronického podpisu). Metody pro vytvoření důvěry ve veřejný klíč podepisujícího jsou určeny pravidly správy elektronických dokumentů přijatými interagujícími stranami.
Umístění jeviště: aplikační software / krypto-kernel.
Fáze 3. Kontrola autority signatáře.
Obsah jeviště. V souladu se stanovenými pravidly správy elektronických dokumentů se kontroluje, zda podepisující osoba měla právo chráněné údaje certifikovat. Zvažte například situaci porušení autority. Předpokládejme, že existuje organizace, kde mají všichni zaměstnanci elektronický podpis. Interní elektronický systém správy dokumentů obdrží objednávku od vedoucího, ale podepsanou elektronickým podpisem vedoucího skladu. Takový dokument tedy nelze považovat za legitimní.
Umístění jeviště: aplikační software.
Předpoklady učiněné při popisu předmětu ochrany
- Kanály přenosu informací, s výjimkou kanálů pro výměnu klíčů, také procházejí aplikačním softwarem, API a kryptojádrem.
- Informace o důvěře ve veřejné klíče a (nebo) certifikáty, stejně jako informace o autoritě vlastníků veřejných klíčů, jsou umístěny v úložišti veřejných klíčů.
- Aplikační software pracuje s úložištěm veřejného klíče prostřednictvím krypto-kernelu.
Příklad informačního systému chráněného CIPF
Pro ilustraci výše uvedených schémat zvažte hypotetický informační systém a vyberte na něm všechny konstrukční prvky.
Popis informačního systému
Obě organizace se rozhodly zavést mezi sebou právně závaznou správu elektronických dokumentů (EDF). K tomu uzavřeli smlouvu, ve které uvedli, že dokumenty budou předávány e-mailem a zároveň musí být zašifrovány a podepsány kvalifikovaným elektronickým podpisem. Jako prostředek pro tvorbu a zpracování dokumentů by měly být použity kancelářské programy z balíku Microsoft Office 2016 a jako prostředek kryptografické ochrany - CIPF CryptoPRO a šifrovací software CryptoARM.
Popis infrastruktury organizace 1
Organizace 1 se rozhodla, že nainstaluje software CryptoPRO CIPF a CryptoARM na pracovní stanici uživatele – fyzický počítač. Šifrovací klíče a klíče pro elektronický podpis budou uloženy na nosiči klíčů ruToken pracujícím v režimu zpětného klíče. Uživatel si připraví elektronické dokumenty lokálně 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 vyhrazený virtuální stroj. V tomto případě budou všechny kryptografické operace provedeny automaticky.
Za tímto účelem jsou na vyhrazeném virtuálním počítači uspořádány dvě síťové složky: „…In“, „…Out“. Soubory přijaté od protistrany v otevřené podobě budou automaticky umístěny do síťové složky „…In“. Tyto soubory budou dešifrovány a bude na nich ověřen elektronický podpis.
Do složky „…Out“ uživatel umístí soubory, které je třeba zašifrovat, podepsat a odeslat protistraně. Soubory si uživatel připraví sám na své pracovní stanici.
Pro provádění funkcí šifrování a elektronického podpisu je na virtuálním počítači nainstalován CryptoPRO CIPF, software CryptoARM a poštovní klient. Automatická správa všech prvků virtuálního stroje bude prováděna pomocí skriptů vyvinutých správci systému. Práce skriptů se zaznamenává do log souborů (logů).
Kryptografické klíče elektronického podpisu budou umístěny na tokenu s nezjistitelným klíčem JaCarta GOST, který si uživatel připojí ke svému lokálnímu počítači.
Token bude předán virtuálnímu počítači pomocí specializovaného softwaru USB-over-IP nainstalovaného na pracovní stanici uživatele a na virtuálním počítači.
Systémové hodiny na pracovní stanici uživatele v organizaci 1 budou upraveny ručně. Systémové hodiny vyhrazeného virtuálního stroje v organizaci 2 budou synchronizovány se systémovými hodinami hypervizoru, který bude zase synchronizován přes internet s veřejnými časovými servery.
Alokace konstrukčních prvků CIPF
Na základě výše uvedeného popisu IT infrastruktury vyčleníme konstrukční prvky CIPF a zapíšeme je do tabulky.
Tabulka - Korespondence prvků modelu CIPF s prvky informačních systémů
Název položky
Organizace 1
Organizace 2
Aplikační software
CryptoARM software
CryptoARM software
Softwarová část kryptokernelu
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Hardwarová část kryptokernelu
Ne
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Úložiště veřejného klíče
Uživatelská pracovní stanice:
- HDD;
- standardní úložiště certifikátů Windows.
Hypervizor:
- HDD.
Virtuální stroj:
- HDD;
- standardní úložiště certifikátů Windows.
Úložiště soukromých klíčů
Nosič klíče ruToken pracující v režimu vyjímatelného klíče
Nosič klíčů JaCarta GOST fungující v režimu bez zpětného klíče
Kanál výměny veřejného klíče
Uživatelská pracovní stanice:
- RAM.
Hypervizor:
- RAM.
Virtuální stroj:
- RAM.
Kanál výměny soukromých klíčů
Uživatelská pracovní stanice:
- USB sběrnice;
- RAM.
Ne
Výměnný kanál mezi kryptojádry
chybí (žádný kryptojádrový hardware)
Uživatelská pracovní stanice:
- USB sběrnice;
- RAM;
- USB-over-IP softwarový modul;
- síťové rozhraní.
Firemní síť organizace 2.
Hypervizor:
- RAM;
- síťové rozhraní.
Virtuální stroj:
- síťové rozhraní;
- RAM;
- USB-over-IP softwarový modul.
Otevřený kanál pro výměnu dat
Uživatelská pracovní stanice:
- prostředky vstup-výstup;
- RAM;
- HDD.
Uživatelská pracovní stanice:
- prostředky vstup-výstup;
- RAM;
- HDD;
- síťové rozhraní.
Firemní síť organizace 2.
Hypervizor:
- síťové rozhraní;
- RAM;
- HDD.
Virtuální stroj:
- síťové rozhraní;
- RAM;
- HDD.
Zabezpečený kanál pro výměnu dat
Internet.
Firemní síť organizace 1.
Uživatelská pracovní stanice:
- HDD;
- RAM;
- síťové rozhraní.
Internet.
Firemní síť organizace 2.
Hypervizor:
- síťové rozhraní;
- RAM;
- HDD.
Virtuální stroj:
- síťové rozhraní;
- RAM;
- HDD.
Časový kanál
Uživatelská pracovní stanice:
- prostředky vstup-výstup;
- RAM;
- systémový časovač.
Internet.
Firemní síť organizace 2,
Hypervizor:
- síťové rozhraní;
- RAM;
- systémový časovač.
Virtuální stroj:
- RAM;
- systémový časovač.
Přenosový kanál řídicího příkazu
Uživatelská pracovní stanice:
- prostředky vstup-výstup;
- RAM.
(GUI softwaru CryptoARM)
Virtuální stroj:
- RAM;
- HDD.
(Automatizační skripty)
Kanál pro příjem pracovních výsledků
Uživatelská pracovní stanice:
- prostředky vstup-výstup;
- RAM.
(GUI softwaru CryptoARM)
Virtuální stroj:
- RAM;
- HDD.
(Soubory protokolu pro automatizační skripty)
Bezpečnostní hrozby nejvyšší úrovně
Vysvětlení
Předpoklady učiněné při rozkladu hrozeb:
- Používají se silné kryptografické algoritmy.
- Kryptografické algoritmy se používají bezpečně ve správných provozních režimech (např. se nevztahuje na šifrování velkého množství dat, zohledňuje se povolené zatížení klíče apod.).
- Zločinci znají všechny používané algoritmy, protokoly a veřejné klíče.
- Útočníci mají přístup ke všem zašifrovaným datům.
- Útočníci jsou schopni reprodukovat jakékoli programové prvky v systému.
Rozklad
U1. Kompromit soukromých kryptografických klíčů.
U2. Šifrování falešných dat jménem legitimního odesílatele.
U3. Dešifrování zašifrovaných dat osobami, které nejsou legitimními příjemci dat (vetřelci).
U4. Vytvoření elektronického podpisu oprávněného podepisujícího pod nepravdivými údaji.
U5. Získání pozitivního výsledku kontroly elektronického podpisu nepravdivých údajů.
U6. Chybné přijímání elektronických dokumentů k provedení kvůli problémům v organizaci správy elektronických dokumentů.
U7. Neoprávněný přístup k chráněným údajům při jejich zpracování CIPF.
U1. Kompromit soukromých kryptografických klíčů
U1.1. Získejte soukromý klíč z úložiště soukromých klíčů.
Y1.2. Získání soukromého klíče z objektů prostředí fungování kryptografického nástroje, ve kterém se může dočasně nacházet.
Vysvětlivky Y1.2.
Mezi objekty, které mohou dočasně uložit soukromý klíč, patří:
- RAM,
- dočasné soubory,
- stránkovací soubory,
- soubory hibernace,
- soubory snímků „horkého“ stavu virtuálních strojů, včetně souborů obsahu paměti RAM virtuálních strojů, které byly pozastaveny.
U1.2.1. Získání soukromých klíčů z pracovní paměti RAM zmrazením modulů RAM, jejich extrakcí a následným přečtením dat (útok zmrazením).
Vysvětlivky Y1.2.1.
příklad .
Y1.3. Získání soukromého klíče z kanálu pro výměnu soukromých klíčů.
Vysvětlivky Y1.3.
Bude uveden příklad implementace této hrozby .
U1.4. Neoprávněná úprava kryptojádra, v důsledku čehož se soukromé klíče dostanou do povědomí útočníků.
Y1.5. Narušení soukromého klíče v důsledku použití technických kanálů úniku informací (TCLE).
Vysvětlivky Y1.5.
příklad .
U1.6. Prolomení soukromého klíče v důsledku použití speciálních technických prostředků (STS) určených k tajnému získávání informací ("chyby").
Y1.7. Kompromitace soukromých klíčů během jejich uložení mimo CIPF.
Vysvětlivky Y1.7.
Uživatel například uchovává svá klíčová média v zásuvce stolního počítače, odkud je mohou vetřelci snadno získat.
U2. Šifrování falešných dat jménem legitimního odesílatele
Vysvětlení
Tato hrozba je zvažována pouze pro schémata šifrování dat s ověřením odesílatele. Příklady takových schémat jsou uvedeny v doporučeních pro standardizaci. . U jiných kryptografických schémat tato hrozba neexistuje, protože šifrování se provádí na veřejných klíčích příjemce, které jsou útočníkům obecně známé.
Rozklad
Y2.1. Prolomení soukromého klíče odesílatele:
Y2.1.1. Odkaz: .
Y2.2. Náhrada vstupních dat v otevřeném kanálu výměny dat.
Poznámky U2.2.
Příklady implementace této hrozby jsou uvedeny níže. и .
U3. Dešifrování zašifrovaných dat osobami, které nejsou legitimními příjemci dat (vetřelci)
Rozklad
Y3.1. Kompromitace soukromých klíčů příjemce šifrovaných dat.
Odkaz U3.1.1: .
Y3.2. Náhrada zašifrovaných dat v zabezpečeném kanálu pro výměnu dat.
U4. Vytvoření elektronického podpisu oprávněného podepisujícího pod nepravdivými údaji
Rozklad
Y4.1. Kompromitace soukromých klíčů elektronického podpisu legitimního podepisujícího.
Odkaz U4.1.1: .
Y4.2. Náhrada podepsaných dat v otevřeném kanálu výměny dat.
Poznámka U4.2.
Příklady implementace této hrozby jsou uvedeny níže. и .
U5. Získání pozitivního výsledku kontroly elektronického podpisu nepravdivých údajů
Rozklad
Y5.1. Škodlivé osoby zachytí v kanálu přenosu výsledků práce zprávu o negativním výsledku kontroly elektronického podpisu a nahradí ji zprávou s pozitivním výsledkem.
Y5.2. Útočníci provádějí útok na důvěru v podepisování certifikátů (SCÉNÁŘ – všechny prvky jsou povinné):
U5.2.1. Útočníci generují veřejný a soukromý klíč pro elektronický podpis. Pokud systém používá certifikáty klíče pro elektronický podpis, vygenerují certifikát elektronického podpisu, který je co nejpodobnější certifikátu údajného odesílatele dat, jehož zprávu chtějí zfalšovat.
Y5.2.2. Útočníci provádějí neoprávněné změny v úložišti veřejných klíčů a dávají jimi vygenerovanému veřejnému klíči nezbytnou úroveň důvěry a autority.
Y5.2.3. Útočníci podepisují falešná data pomocí dříve vygenerovaného klíče elektronického podpisu a vkládají je do zabezpečeného kanálu pro výměnu dat.
Y5.3. Útočníci provádějí útok pomocí prošlých klíčů elektronického podpisu oprávněného podepisujícího (SCÉNÁŘ – všechny prvky jsou povinné):
Y5.3.1. Útočníci kompromitují prošlé (aktuálně neplatné) soukromé klíče elektronického podpisu legitimního odesílatele.
Y5.3.2. Útočníci nahrazují čas v časovém přenosovém kanálu časem, kdy byly kompromitované klíče stále platné.
Y5.3.3. Útočníci podepisují falešná data pomocí dříve kompromitovaného klíče elektronického podpisu a vkládají je do zabezpečeného kanálu pro výměnu dat.
Y5.4. Útočníci provádějí útok pomocí kompromitovaných klíčů elektronického podpisu zákonného podepisujícího (SCÉNÁŘ – všechny prvky jsou povinné):
Y5.4.1. Útočníci si vytvoří kopii úložiště veřejných klíčů.
Y5.4.2. Útočníci kompromitují soukromé klíče jednoho z legitimních odesílatelů. Ten si všimne kompromisu, zneplatní klíče, informace o revokaci klíče se umístí do úložiště veřejných klíčů.
Y5.4.3. Útočníci nahradí úložiště veřejných klíčů dříve zkopírovaným.
Y5.4.4. Útočníci podepisují falešná data pomocí dříve kompromitovaného klíče elektronického podpisu a vkládají je do zabezpečeného kanálu pro výměnu dat.
U5.5. <...> z důvodu výskytu chyb při provádění 2. a 3. etapy ověřování elektronického podpisu:
Vysvětlivky Y5.5.
Je uveden příklad implementace této hrozby .
U5.5.1. Ověření důvěry v certifikát klíče elektronického podpisu pouze přítomností důvěry v certifikát, kterým je podepsán, bez kontrol CRL nebo OCSP.
Vysvětlivky Y5.5.1.
Příklad implementace .
Y5.5.2. Při budování řetězce důvěry pro certifikát není analyzována autorita vydávající certifikáty
Vysvětlivky Y5.5.2.
Příklad útoku proti SSL/TLS certifikátům.
Útočníci si pro svůj e-mail koupili legitimní certifikát. Poté vytvořili podvodný webový certifikát a podepsali jej vlastním certifikátem. Pokud se kontrola pověření neprovede, při kontrole řetězce důvěry se ukáže, že je správná, a proto bude správný i podvodný certifikát.
Y5.5.3. Při vytváření řetězu důvěryhodnosti certifikátů nejsou zprostředkující certifikáty kontrolovány na odvolání.
Y5.5.4. Seznamy CRL jsou aktualizovány méně často, než je vydává certifikační autorita.
Y5.5.5. Rozhodnutí důvěřovat elektronickému podpisu je učiněno před přijetím odpovědi OCSP o stavu certifikátu, zaslané na žádost podanou později, než je čas generování podpisu nebo dříve než následující po obdržení podpisu CRL.
Vysvětlivky Y5.5.5.
V předpisech většiny CA se za dobu zneplatnění certifikátu považuje čas vydání nejbližšího CRL obsahujícího informaci o zneplatnění certifikátu.
Y5.5.6. Při příjmu podepsaných dat nekontroluje, zda certifikát patří odesílateli.
Vysvětlivky Y5.5.6.
Příklad útoku. U SSL certifikátů nemusí kontrolovat, zda adresa volaného serveru odpovídá hodnotě pole CN v certifikátu.
Příklad útoku. Útočníci kompromitovali klíče elektronického podpisu jednoho z účastníků platebního styku. Poté hackli síť dalšího účastníka a jeho jménem odeslali platební dokumenty podepsané kompromitovanými klíči na zúčtovací server platebního systému. Pokud server analyzuje pouze důvěryhodnost a nekontroluje shodu, budou podvodné dokumenty považovány za legitimní.
U6. Chybné přijímání elektronických dokumentů k provedení kvůli problémům v organizaci správy elektronických dokumentů.
Rozklad
U6.1. Přijímající strana nezjistí duplikaci přijatých dokumentů.
Vysvětlivky Y6.1.
Příklad útoku. Zločinci mohou zachytit dokument předaný příjemci, i když je kryptograficky chráněn, a poté jej opakovaně odeslat na zabezpečený kanál pro přenos dat. Pokud příjemce nezjistí duplikáty, budou všechny přijaté dokumenty vnímány a zpracovány jako různé dokumenty.
U7. Neoprávněný přístup k chráněným údajům při jejich zpracování CIPF
Rozklad
U7.1. <…> kvůli úniku informací prostřednictvím kanálů třetích stran (útok na boční kanál).
Vysvětlivky Y7.1.
příklad .
U7.2. <...> z důvodu neutralizace ochrany před neoprávněným přístupem k informacím zpracovávaným na CIPF:
Y7.2.1. Provoz CIPF s porušením požadavků popsaných v dokumentaci k CIPF.
Y7.2.2. <…> implementováno kvůli přítomnosti zranitelností v:
Y7.2.2.1. <…> prostředky ochrany proti neoprávněnému přístupu.
Y7.2.2.2. <…> samotný CIPF.
Y7.2.2.3. <...> prostředí pro fungování kryptografického nástroje.
Příklady útoků
Níže popsané scénáře zjevně obsahují chyby v organizaci informační bezpečnosti a slouží pouze pro ilustraci možných útoků.
Scénář 1. Příklad implementace hrozeb U2.2 a U4.2.
Popis objektu
Software ARM KBR a CIPF SCAD Signature jsou nainstalovány na fyzickém počítači, který není připojen k počítačové síti. FKN vdToken se používá jako nosič klíče v provozním režimu s nevyměnitelným klíčem.
Nařízení o vypořádání předpokládá, že specialista na vypořádání ze svého pracovního počítače stáhne elektronické zprávy ve formátu prostého textu (schéma starého KBR AWS) ze speciálního zabezpečeného souborového serveru, poté je zapíše na vyměnitelný USB flash disk a přenese je do KBR AWP. , kde jsou zašifrovány a podepsány. Poté specialista převede zabezpečené elektronické zprávy na přenosné médium a poté je prostřednictvím svého pracovního počítače zapíše na souborový server, odkud se dostanou do UTA a poté do platebního systému Ruské banky.
V tomto případě budou kanály pro výměnu otevřených a zabezpečených dat zahrnovat: souborový server, pracovní počítač specialisty a přenosná média.
Útok
Neoprávnění útočníci nainstalují na pracovní počítač specialisty systém dálkového ovládání a v době záznamu platebních příkazů (elektronických zpráv) na přenosné médium otevřeně nahrazují obsah jednoho z nich. Specialista převede platební příkazy do AWS KBR, podepíše je a zašifruje, aniž by zaznamenal záměnu (např. z důvodu velkého počtu platebních příkazů za letu, únavy atd.). Poté falešný platební příkaz, který prošel technologickým řetězcem, vstupuje do platebního systému Ruské banky.
Scénář 2. Příklad implementace hrozeb U2.2 a U4.2.
Popis objektu
Počítač s nainstalovaným AWS KBR, SKAD Signature a připojeným nosičem klíčů FKN vdToken funguje ve vyhrazené místnosti bez přístupu personálu.
Vypořádací specialista se připojuje k AWS KBR v režimu vzdáleného přístupu přes protokol RDP.
Útok
Útočníci zachycují detaily, pomocí kterých se vypořádací specialista spojuje a spolupracuje s automatizovaným pracovištěm KBR (například kvůli škodlivému kódu na svém počítači). Poté se jeho jménem spojí a pošlou falešný platební příkaz do platebního systému Ruské banky.
Scénář 3. Příklad implementace hrozby U1.3.
Popis objektu
Uvažujme jednu z hypotetických možností implementace integračních modulů ABS-KBR pro nové schéma (ARM KBR-N), ve kterém se elektronický podpis odchozích dokumentů vyskytuje na straně ABS. Zároveň budeme předpokládat, že ABS funguje na základě operačního systému, který není podporován CIPF SKAD Signature, a proto je kryptografická funkčnost umístěna na samostatném virtuálním stroji - integračním modulu ABS-CBR .
Jako nosič klíčů se používá běžný USB token pracující v režimu výměnného klíče. Když byl nosič klíčů připojen k hypervizoru, ukázalo se, že v systému nejsou žádné volné USB porty, takže bylo rozhodnuto připojit USB token přes síťový USB hub a nainstalovat klienta USB-over-IP na virtuální stroj, který bude komunikovat s hubem.
Útok
Útočníci zachytili privátní klíč elektronického podpisu z komunikačního kanálu mezi USB hubem a hypervizorem (data byla přenášena v čistém textu). Útočníci s privátním klíčem vygenerovali falešný platební příkaz, podepsali jej elektronickým podpisem a odeslali k provedení na automatizované pracoviště KBR-N.
Scénář 4. Příklad implementace hrozeb U5.5.
Popis objektu
Zvažte stejný obvod jako v předchozím scénáři. Budeme předpokládat, že e-maily přicházející z pracovní stanice KBR-N končí ve složce …SHAREIn a ty, které jsou odeslány na pracovní stanici KBR-N a dále do platebního systému Bank of Russia, jdou do …SHAREout.
Budeme také předpokládat, že při implementaci integračního modulu jsou seznamy zneplatněných certifikátů aktualizovány pouze při opětovném vydání kryptografických klíčů a také, že elektronické zprávy přijaté ve složce …SHAREIn jsou kontrolovány pouze z hlediska kontroly integrity a kontroly důvěry k veřejnému klíči elektronického podpisu.
Útok
Útočníci pomocí klíčů odcizených v předchozím scénáři podepsali falešný platební příkaz obsahující informaci o přijetí peněz na účet podvodného klienta a uvedli jej do zabezpečeného kanálu výměny dat. Protože neexistuje žádné ověření, že platební příkaz je podepsán Bankou Ruska, je přijat k provedení.
Zdroj: www.habr.com