Linkovi na druge dijelove studije
- (Jesi li tu)
Ovaj članak upotpunjuje seriju publikacija posvećenih osiguravanju informacijske sigurnosti bankovnog bezgotovinskog plaćanja. Ovdje ćemo pogledati tipične modele prijetnji o kojima se govori u :
- .
- .
- .
- .
HABRO-UPOZORENJE!!! Dragi Khabrovci, ovo nije zabavan post.
Namijenjeno je 40+ stranica materijala skrivenih ispod reza pomoć u radu ili učenju ljudi specijalizirani za bankarstvo ili sigurnost informacija. Ovi materijali su konačni proizvod istraživanja i napisani su suhim, formalnim tonom. U suštini, ovo su praznine za interne dokumente o sigurnosti informacija.Pa tradicionalno - “korištenje informacija iz članka u nezakonite svrhe je kažnjivo po zakonu”. Produktivno čitanje!
Informacije za čitaoce koji se upoznaju sa studijom počevši od ove publikacije.
O čemu je studija
Čitate vodič za stručnjaka odgovornog za osiguranje informacione sigurnosti plaćanja u banci.
Logika prezentacije
Na početku u и dat je opis zaštićenog objekta. Onda unutra opisuje kako izgraditi sigurnosni sistem i govori o potrebi kreiranja modela prijetnje. IN govori o tome koji modeli prijetnji postoje i kako se formiraju. IN и Pruža se analiza stvarnih napada. и sadrže opis modela prijetnje, izgrađen uzimajući u obzir informacije iz svih prethodnih dijelova.
TIPIČNI MODEL PRIJETNJE. MREŽNA VEZA
Objekt zaštite za koji se primjenjuje model prijetnje (opseg).
Predmet zaštite su podaci koji se prenose putem mrežne veze koja radi u mrežama za prenos podataka izgrađenim na bazi steka. TCP/IP.
arhitektura
Opis arhitektonskih elemenata:
- "Krajnji čvorovi" — čvorovi koji razmjenjuju zaštićene informacije.
- "Međučvorovi" — elementi mreže za prenos podataka: ruteri, svičevi, pristupni serveri, proxy serveri i druga oprema — preko koje se prenosi saobraćaj mrežne veze. Općenito, mrežna veza može funkcionirati bez međučvorova (direktno između krajnjih čvorova).
Sigurnosne prijetnje najvišeg nivoa
Raspadanje
U1. Neovlašteni pristup prenesenim podacima.
U2. Neovlaštena izmjena prenesenih podataka.
U3. Povreda autorstva prenesenih podataka.
U1. Neovlašteni pristup prenesenim podacima
Raspadanje
U1.1. <…>, izvedeno na krajnjim ili srednjim čvorovima:
U1.1.1. <…> čitanjem podataka dok su u host uređajima za pohranu:
U1.1.1.1. <…> u RAM-u.
Objašnjenja za U1.1.1.1.
Na primjer, tokom obrade podataka od strane mrežnog stoga domaćina.
U1.1.1.2. <…> u nepromjenjivoj memoriji.
Objašnjenja za U1.1.1.2.
Na primjer, kada pohranjujete prenesene podatke u keš memoriju, privremene datoteke ili swap datoteke.
U1.2. <…>, izvršeno na čvorovima treće strane mreže podataka:
U1.2.1. <…> metodom hvatanja svih paketa koji stignu na mrežni interfejs hosta:
Objašnjenja za U1.2.1.
Hvatanje svih paketa se vrši prebacivanjem mrežne kartice u promiskuitetni režim (promiskuitetni režim za žičane adaptere ili režim monitora za wi-fi adaptere).
U1.2.2. <…> izvođenjem napada čovjeka u sredini (MiTM), ali bez modifikacije prenesenih podataka (ne računajući podatke usluge mrežnog protokola).
U1.2.2.1. Veza: .
U1.3. <…>, izvršeno zbog curenja informacija kroz tehničke kanale (TKUI) iz fizičkih čvorova ili komunikacijskih linija.
U1.4. <…>, koja se izvodi ugradnjom posebnih tehničkih sredstava (STS) na krajnje ili međučvorove, namijenjena tajnom prikupljanju informacija.
U2. Neovlaštena izmjena prenesenih podataka
Raspadanje
U2.1. <…>, izvedeno na krajnjim ili srednjim čvorovima:
U2.1.1. <…> čitanjem i izmjenama podataka dok su u uređajima za pohranu čvorova:
U2.1.1.1. <…> u RAM-u:
U2.1.1.2. <…> u nepromenljivoj memoriji:
U2.2. <…>, izvršeno na čvorovima treće strane mreže za prijenos podataka:
U2.2.1. <…> provođenjem napada čovjeka u sredini (MiTM) i preusmjeravanjem prometa na čvor napadača:
U2.2.1.1. Fizička povezanost opreme napadača uzrokuje prekid mrežne veze.
U2.2.1.2. Izvođenje napada na mrežne protokole:
U2.2.1.2.1. <…> upravljanje virtuelnim lokalnim mrežama (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Neovlaštena izmjena VLAN postavki na prekidačima ili ruterima.
U2.2.1.2.2. <…> ruta saobraćaja:
U2.2.1.2.2.1. Neovlaštena modifikacija statičkih tabela rutera rutera.
U2.2.1.2.2.2. Najava lažnih ruta od strane napadača kroz dinamičke protokole rutiranja.
U2.2.1.2.3. <…> automatska konfiguracija:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. <…> adresiranje i razlučivanje imena:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Pravljenje neovlaštenih promjena u lokalnim datotekama imena hosta (hostovi, lmhostovi, itd.)
U3. Povreda autorskih prava prenesenih podataka
Raspadanje
U3.1. Neutralizacija mehanizama za utvrđivanje autorstva informacije navođenjem lažnih podataka o autoru ili izvoru podataka:
U3.1.1. Promjena informacija o autoru sadržanih u prenesenim informacijama.
U3.1.1.1. Neutralizacija kriptografske zaštite integriteta i autorstva prenesenih podataka:
U3.1.1.1.1. Veza: .
U3.1.1.2. Neutralizacija autorske zaštite prenesenih podataka, implementirana korištenjem jednokratnih potvrdnih kodova:
U3.1.1.2.1. .
U3.1.2. Promjena informacija o izvoru prenesenih informacija:
U3.1.2.1. .
U3.1.2.2. .
TIPIČNI MODEL PRIJETNJE. INFORMACIONI SISTEM IZGRAĐEN NA BAZI KLIJENT-SERVER ARHITEKTURE
Objekt zaštite za koji se primjenjuje model prijetnje (opseg).
Predmet zaštite je informacioni sistem izgrađen na bazi klijent-server arhitekture.
arhitektura
Opis arhitektonskih elemenata:
- "klijent" – uređaj na kojem radi klijentski dio informacionog sistema.
- "Server" – uređaj na kojem radi serverski dio informacionog sistema.
- "Skladište podataka" — dio serverske infrastrukture informacionog sistema, dizajniran za skladištenje podataka koje obrađuje informacioni sistem.
- "mrežna veza" — kanal za razmjenu informacija između Klijenta i Servera koji prolazi kroz mrežu podataka. Detaljniji opis modela elemenata dat je u .
Ograničenja
Prilikom modeliranja objekta postavljaju se sljedeća ograničenja:
- Korisnik komunicira sa informacionim sistemom u ograničenim vremenskim periodima, koji se nazivaju radne sesije.
- Na početku svake radne sesije korisnik se identifikuje, autentifikuje i autorizuje.
- Sve zaštićene informacije pohranjuju se na serverskom dijelu informacionog sistema.
Sigurnosne prijetnje najvišeg nivoa
Raspadanje
U1. Izvođenje neovlaštenih radnji od strane napadača u ime legitimnog korisnika.
U2. Neovlašćena izmjena zaštićenih informacija tokom njihove obrade od strane serverskog dijela informacionog sistema.
U1. Izvođenje neovlaštenih radnji od strane napadača u ime legitimnog korisnika
Objašnjenja
Obično u informacionim sistemima radnje su povezane sa korisnikom koji ih je izvršio koristeći:
- evidencije rada sistema (logove).
- posebne atribute objekata podataka koji sadrže informacije o korisniku koji ih je kreirao ili modificirao.
U odnosu na radnu sesiju, ova prijetnja se može dekomponovati na:
- <…> izvedeno unutar korisničke sesije.
- <…> se izvršava izvan korisničke sesije.
Korisnička sesija se može pokrenuti:
- Od samog korisnika.
- Malefactors.
U ovoj fazi, srednja dekompozicija ove prijetnje će izgledati ovako:
U1.1. Neovlaštene radnje izvršene su u okviru korisničke sesije:
U1.1.1. <…> instalirao napadnuti korisnik.
U1.1.2. <…> instalirali su napadači.
U1.2. Izvršene su neovlaštene radnje izvan korisničke sesije.
Sa stanovišta objekata informacione infrastrukture na koje napadači mogu uticati, dekompozicija međupretnji će izgledati ovako:
Elementi
Razgradnja prijetnje
U1.1.1.
U1.1.2.
U1.2.
Kupac
U1.1.1.1.
U1.1.2.1.
Mrežna veza
U1.1.1.2.
Server
U1.2.1.
Raspadanje
U1.1. Neovlaštene radnje izvršene su u okviru korisničke sesije:
U1.1.1. <…> instaliran od strane napadnutog korisnika:
U1.1.1.1. Napadači su djelovali nezavisno od Klijenta:
U1.1.1.1.1 Napadači su koristili standardne alate za pristup informacionom sistemu:
U1.1.1.1.1.1. Napadači su koristili fizičke ulazno/izlazne uređaje Klijenta (tastaturu, miš, monitor ili ekran osjetljiv na dodir mobilnog uređaja):
U1.1.1.1.1.1.1. Napadači su djelovali tokom perioda kada je sesija bila aktivna, I/O objekti su bili dostupni, a korisnik nije bio prisutan.
U1.1.1.1.1.2. Napadači su koristili alate za daljinsku administraciju (standardne ili obezbeđene zlonamernim kodom) da kontrolišu klijenta:
U1.1.1.1.1.2.1. Napadači su djelovali tokom perioda kada je sesija bila aktivna, I/O objekti su bili dostupni, a korisnik nije bio prisutan.
U1.1.1.1.1.2.2. Napadači su koristili alate za udaljenu administraciju, čiji je rad nevidljiv napadnutim korisnikom.
U1.1.1.2. Napadači su zamenili podatke u mrežnoj vezi između Klijenta i Servera, modifikujući ih na način da se percipiraju kao radnje legitimnog korisnika:
U1.1.1.2.1. Veza: .
U1.1.1.3. Napadači su prisilili korisnika da izvrši radnje koje su odredili koristeći metode društvenog inženjeringa.
U1.1.2 <…> instaliran od strane napadača:
U1.1.2.1. Napadači su djelovali od strane Klijenta (И):
U1.1.2.1.1. Napadači su neutralisali sistem kontrole pristupa informacionom sistemu:
U1.1.2.1.1.1. Veza: .
U1.1.2.1.2. Napadači su koristili standardne alate za pristup informacionom sistemu
U1.1.2.2. Napadači su djelovali sa drugih čvorova podatkovne mreže, iz kojih se mogla uspostaviti mrežna veza sa Serverom (И):
U1.1.2.2.1. Napadači su neutralisali sistem kontrole pristupa informacionom sistemu:
U1.1.2.2.1.1. Veza: .
U1.1.2.2.2. Napadači su koristili nestandardna sredstva za pristup informacionom sistemu.
Objašnjenja U1.1.2.2.2.
Napadači bi mogli da instaliraju standardnog klijenta informacionog sistema na čvoru treće strane ili da koriste nestandardni softver koji implementira standardne protokole razmene između Klijenta i Servera.
U1.2 Neovlaštene radnje su izvedene izvan korisničke sesije.
U1.2.1 Napadači su izvršili neovlaštene radnje, a zatim izvršili neovlaštene promjene u evidenciji rada informacionog sistema ili posebnim atributima objekata podataka, što ukazuje da je radnje koje su izvršili izvršio legitimni korisnik.
U2. Neovlašćena izmjena zaštićenih informacija tokom njihove obrade od strane serverskog dijela informacionog sistema
Raspadanje
U2.1. Napadači modificiraju zaštićene informacije koristeći standardne alate informacionog sistema i to rade u ime legitimnog korisnika.
U2.1.1. Veza: .
U2.2. Napadači modificiraju zaštićene informacije koristeći mehanizme pristupa podacima koji nisu predviđeni normalnim radom informacionog sistema.
U2.2.1. Napadači modificiraju datoteke koje sadrže zaštićene informacije:
U2.2.1.1. <…>, koristeći mehanizme za rukovanje datotekama koje obezbeđuje operativni sistem.
U2.2.1.2. <…> izazivanjem obnavljanja datoteka iz neovlaštene modificirane sigurnosne kopije.
U2.2.2. Napadači modificiraju zaštićene informacije pohranjene u bazi podataka (И):
U2.2.2.1. Napadači neutraliziraju DBMS sistem kontrole pristupa:
U2.2.2.1.1. Veza: .
U2.2.2.2. Napadači modificiraju informacije koristeći standardna DBMS sučelja za pristup podacima.
U2.3. Napadači modificiraju zaštićene informacije neovlaštenom modifikacijom algoritama rada softvera koji ih obrađuje.
U2.3.1. Izvorni kod softvera je podložan izmjenama.
U2.3.1. Mašinski kod softvera je podložan izmjenama.
U2.4. Napadači modificiraju zaštićene informacije iskorištavanjem ranjivosti u softveru informacionog sistema.
U2.5. Napadači modificiraju zaštićene informacije kada se prenose između komponenti serverskog dijela informacionog sistema (na primjer, server baze podataka i server aplikacija):
U2.5.1. Veza: .
TIPIČNI MODEL PRIJETNJE. SISTEM KONTROLE PRISTUPA
Objekt zaštite za koji se primjenjuje model prijetnje (opseg).
Objekt zaštite za koji se primjenjuje ovaj model prijetnje odgovara objektu zaštite modela prijetnje: „Tipični model prijetnje. Informacioni sistem izgrađen na arhitekturi klijent-server.”
U ovom modelu prijetnji, sistem kontrole pristupa korisnika označava komponentu informacionog sistema koja implementira sljedeće funkcije:
- Identifikacija korisnika.
- Autentifikacija korisnika.
- Autorizacije korisnika.
- Evidentiranje radnji korisnika.
Sigurnosne prijetnje najvišeg nivoa
Raspadanje
U1. Neovlašteno uspostavljanje sesije u ime legitimnog korisnika.
U2. Neovlašteno povećanje privilegija korisnika u informacionom sistemu.
U1. Neovlašteno uspostavljanje sesije u ime legitimnog korisnika
Objašnjenja
Dekompozicija ove prijetnje općenito će ovisiti o vrsti sistema identifikacije korisnika i autentifikacije koji se koristi.
U ovom modelu će se uzeti u obzir samo sistem identifikacije i autentifikacije korisnika koji koristi tekstualnu prijavu i lozinku. U ovom slučaju, pretpostavit ćemo da je prijava korisnika javno dostupna informacija poznata napadačima.
Raspadanje
U1.1. <…> zbog kompromitacije akreditiva:
U1.1.1. Napadači su kompromitovali korisničke akreditive dok su ih pohranjivali.
Objašnjenja U1.1.1.
Na primjer, vjerodajnice mogu biti napisane na ljepljivoj noti zalijepljenoj za monitor.
U1.1.2. Korisnik je slučajno ili zlonamjerno proslijedio podatke o pristupu napadačima.
U1.1.2.1. Korisnik je izgovorio akreditive naglas dok je ulazio.
U1.1.2.2. Korisnik je namjerno podijelio svoje akreditive:
U1.1.2.2.1. <…> kolegama s posla.
Objašnjenja U1.1.2.2.1.
Na primjer, kako bi ga mogli zamijeniti tokom bolesti.
U1.1.2.2.2. <…> izvođačima radova poslodavca koji izvode radove na objektima informacione infrastrukture.
U1.1.2.2.3. <…> trećim licima.
Objašnjenja U1.1.2.2.3.
Jedna, ali ne i jedina opcija za implementaciju ove prijetnje je korištenje metoda društvenog inženjeringa od strane napadača.
U1.1.3. Napadači su odabrali akreditive koristeći metode brutalne sile:
U1.1.3.1. <…> koristeći standardne mehanizme pristupa.
U1.1.3.2. <…> korištenjem prethodno presretnutih kodova (na primjer, heševa lozinki) za pohranjivanje vjerodajnica.
U1.1.4. Napadači su koristili zlonamjerni kod da presretnu korisničke vjerodajnice.
U1.1.5. Napadači su izvukli vjerodajnice iz mrežne veze između klijenta i servera:
U1.1.5.1. Veza: .
U1.1.6. Napadači su izvukli akreditive iz evidencije sistema za praćenje rada:
U1.1.6.1. <…> sistemi video nadzora (ako su u toku rada snimljeni udarci tastera na tastaturi).
U1.1.6.2. <…> sistemi za praćenje radnji zaposlenih na računaru
Objašnjenja U1.1.6.2.
Primjer takvog sistema je .
U1.1.7. Napadači su ugrozili korisničke vjerodajnice zbog nedostataka u procesu prijenosa.
Objašnjenja U1.1.7.
Na primjer, slanje lozinki u čistom tekstu putem e-pošte.
U1.1.8. Napadači su dobili vjerodajnice praćenjem sesije korisnika koristeći sisteme udaljene administracije.
U1.1.9. Napadači su dobili akreditive kao rezultat njihovog curenja putem tehničkih kanala (TCUI):
U1.1.9.1. Napadači su posmatrali kako korisnik unosi akreditive sa tastature:
U1.1.9.1.1 Napadači su bili locirani u neposrednoj blizini korisnika i vidjeli su unošenje akreditiva vlastitim očima.
Objašnjenja U1.1.9.1.1
Takvi slučajevi uključuju radnje kolega na poslu ili slučaj kada je tastatura korisnika vidljiva posjetiocima organizacije.
U1.1.9.1.2 Napadači su koristili dodatna tehnička sredstva, kao što su dvogled ili bespilotna letjelica, te su vidjeli unos akreditiva kroz prozor.
U1.1.9.2. Napadači su izvukli akreditive iz radio komunikacije između tastature i sistemske jedinice računara kada su bili povezani preko radio interfejsa (na primer, Bluetooth).
U1.1.9.3. Napadači su presreli akreditive propuštajući ih kroz kanal lažnog elektromagnetnog zračenja i smetnji (PEMIN).
Objašnjenja U1.1.9.3.
Primjeri napada и .
U1.1.9.4. Napadač je presreo unos akreditiva sa tastature upotrebom specijalnih tehničkih sredstava (STS) dizajniranih za tajno dobijanje informacija.
Objašnjenja U1.1.9.4.
primjeri .
U1.1.9.5. Napadači su presreli unos akreditiva sa tastature koristeći
analiza Wi-Fi signala moduliranog procesom pritiskanja tipke korisnika.
Objašnjenja U1.1.9.5.
Primjer: .
U1.1.9.6. Napadači su presreli unos akreditiva sa tastature analizirajući zvukove pritisaka na tastere.
Objašnjenja U1.1.9.6.
Primjer: .
U1.1.9.7. Napadači su presreli unos akreditiva sa tastature mobilnog uređaja analizirajući očitanja akcelerometra.
Objašnjenja U1.1.9.7.
Primjer: .
U1.1.10. <…>, prethodno sačuvana na Klijentu.
Objašnjenja U1.1.10.
Na primjer, korisnik može sačuvati login i lozinku u pretraživaču kako bi pristupio određenoj stranici.
U1.1.11. Napadači su ugrozili vjerodajnice zbog nedostataka u procesu opoziva pristupa korisnicima.
Objašnjenja U1.1.11.
Na primjer, nakon što je korisnik otpušten, njegovi nalozi su ostali deblokirani.
U1.2. <…> iskorištavanjem ranjivosti u sistemu kontrole pristupa.
U2. Neovlašteno podizanje privilegija korisnika u informacionom sistemu
Raspadanje
U2.1 <…> neovlaštenim izmjenama podataka koji sadrže informacije o privilegijama korisnika.
U2.2 <…> kroz korištenje ranjivosti u sistemu kontrole pristupa.
U2.3. <…> zbog nedostataka u procesu upravljanja pristupom korisnika.
Objašnjenja U2.3.
Primjer 1. Korisniku je dat veći pristup za rad nego što mu je potrebno iz poslovnih razloga.
Primjer 2: Nakon što je korisnik premješten na drugu poziciju, prethodno odobrena prava pristupa nisu opozvana.
TIPIČNI MODEL PRIJETNJE. INTEGRACIJSKI MODUL
Objekt zaštite za koji se primjenjuje model prijetnje (opseg).
Integracioni modul je skup objekata informacione infrastrukture dizajniranih da organizuju razmenu informacija između informacionih sistema.
S obzirom na to da u korporativnim mrežama nije uvijek moguće jednoznačno odvojiti jedan informacioni sistem od drugog, integracioni modul se može smatrati i veznom karikom između komponenti unutar jednog informacionog sistema.
arhitektura
Generalizirani dijagram integracijskog modula izgleda ovako:
Opis arhitektonskih elemenata:
- "Exchange Server (SO)" – čvor/usluga/komponenta informacionog sistema koji obavlja funkciju razmjene podataka sa drugim informacionim sistemom.
- "posrednik" – čvor/usluga dizajniran da organizuje interakciju između informacionih sistema, ali nije deo njih.
Primerami "posrednici" mogu postojati usluge e-pošte, uslužne sabirnice preduzeća (uslužna magistrala preduzeća / SoA arhitektura), serveri datoteka trećih strana, itd. Općenito, integracijski modul ne smije sadržavati „Posrednike“. - "Softver za obradu podataka" – skup programa koji implementiraju protokole za razmjenu podataka i konverziju formata.
Na primjer, pretvaranje podataka iz UFEBS formata u ABS format, promjena statusa poruka tokom prijenosa itd. - "mrežna veza" odgovara objektu opisanom u standardnom modelu prijetnje “mrežna veza”. Neke od mrežnih veza prikazanih na dijagramu iznad možda ne postoje.
Primjeri integracijskih modula
Šema 1. Integracija ABS i AWS KBR preko servera datoteka treće strane
Za izvršenje plaćanja, ovlašteni službenik banke preuzima dokumente elektronskog plaćanja iz osnovnog bankarskog sistema i pohranjuje ih u datoteku (u vlastitom formatu, na primjer SQL dump) u mrežnom folderu (...SHARE) na serveru datoteka. Zatim se ova datoteka konvertuje pomoću skripte za pretvaranje u skup datoteka u UFEBS formatu, koje zatim čita CBD radna stanica.
Nakon toga, ovlašćeni radnik - korisnik automatizovanog radnog mesta KBR - šifruje i potpisuje primljene datoteke i šalje ih u platni sistem Banke Rusije.
Kada uplate budu primljene od Banke Rusije, automatizovano radno mesto KBR-a ih dešifruje i proverava elektronski potpis, nakon čega ih beleži u obliku skupa datoteka u UFEBS formatu na serveru datoteka. Prije uvoza platnih dokumenata u ABS, oni se konvertuju pomoću skripte pretvarača iz UFEBS formata u ABS format.
Pretpostavićemo da u ovoj šemi ABS radi na jednom fizičkom serveru, KBR radna stanica radi na namenskom računaru, a skripta pretvarača radi na serveru datoteka.
Korespondencija objekata razmatranog dijagrama sa elementima modela integracionog modula:
“Zamjena servera sa ABS strane” – ABS server.
“Server za razmjenu sa strane AWS KBR” – računarska radna stanica KBR.
"posrednik" – server datoteka treće strane.
"Softver za obradu podataka" – skripta za pretvaranje.
Šema 2. Integracija ABS i AWS KBR pri postavljanju dijeljene mrežne mape sa uplatama na AWS KBR
Sve je slično shemi 1, ali se umjesto toga ne koristi poseban fajl server, već se na računar sa radnom stanicom CBD-a postavlja mrežni folder (...SHARE) sa dokumentima za elektronsko plaćanje. Skripta pretvarača također radi na CBD radnoj stanici.
Korespondencija objekata razmatranog dijagrama sa elementima modela integracionog modula:
Slično šemi 1, ali "posrednik" nije korišteno.
Šema 3. Integracija ABS-a i automatiziranog radnog mjesta KBR-N preko IBM WebSphera MQ i potpisivanje elektronskih dokumenata “na ABS strani”
ABS radi na platformi koju CIPF SCAD Signature ne podržava. Potpisivanje odlaznih elektronskih dokumenata vrši se na posebnom serveru za elektronski potpis (ES Server). Isti server provjerava elektronski potpis na dokumentima koji pristižu iz Banke Rusije.
ABS učitava datoteku sa platnim dokumentima u svom formatu na ES server.
ES server, koristeći skriptu za pretvaranje, pretvara datoteku u elektronske poruke u UFEBS formatu, nakon čega se elektronske poruke potpisuju i prenose u IBM WebSphere MQ.
KBR-N radna stanica pristupa IBM WebSphere MQ i odatle prima potpisane platne poruke, nakon čega ih ovlašteni zaposlenik - korisnik KBR radne stanice - šifrira i šalje u platni sistem Banke Rusije.
Kada se uplate primaju od Banke Rusije, automatizovano radno mesto KBR-N ih dešifruje i verifikuje elektronski potpis. Uspješno obrađene uplate u obliku dešifriranih i potpisanih elektroničkih poruka u UFEBS formatu prenose se u IBM WebSphere MQ, odakle ih prima poslužitelj elektroničkog potpisa.
Server za elektronski potpis provjerava elektronski potpis primljenih uplata i pohranjuje ih u datoteku u ABS formatu. Nakon toga, ovlašteni zaposlenik - korisnik ABS-a - učitava rezultirajući fajl u ABS na propisan način.
Korespondencija objekata razmatranog dijagrama sa elementima modela integracionog modula:
“Zamjena servera sa ABS strane” – ABS server.
“Server za razmjenu sa strane AWS KBR” — računarska radna stanica KBR.
"posrednik" – ES poslužitelj i IBM WebSphere MQ.
"Softver za obradu podataka" – skript konvertor, CIPF SCAD potpis na ES serveru.
Šema 4. Integracija RBS servera i osnovnog bankarskog sistema preko API-ja obezbeđenog od namenskog servera za razmenu
Pretpostavićemo da banka koristi nekoliko sistema daljinskog bankarstva (RBS):
- "Internet klijent-banka" za fizička lica (IKB FL);
- "Internet klijent-banka" za pravna lica (IKB LE).
Kako bi se osigurala sigurnost informacija, sva interakcija između ABS-a i sistema daljinskog bankarstva odvija se preko namjenskog servera za razmjenu podataka koji radi u okviru ABS informacionog sistema.
Zatim ćemo razmotriti proces interakcije između RBS sistema IKB LE i ABS-a.
RBS server, nakon što je od klijenta primio uredno ovjereni nalog za plaćanje, mora na osnovu njega kreirati odgovarajući dokument u ABS-u. Da bi to učinio, koristeći API, prenosi informacije na server za razmjenu, koji zauzvrat unosi podatke u ABS.
Kada se stanje na računu klijenta promijeni, ABS generira elektronska obavještenja, koja se putem servera za razmjenu prenose na udaljeni bankarski server.
Korespondencija objekata razmatranog dijagrama sa elementima modela integracionog modula:
“Exchange server sa RBS strane” – RBS server IKB YUL.
“Zamjena servera sa ABS strane” – server za razmjenu.
"posrednik" - odsutan.
"Softver za obradu podataka" – Komponente RBS servera odgovorne za korištenje API servera za razmjenu, komponente servera za razmjenu odgovorne za korištenje osnovnog bankarskog API-ja.
Sigurnosne prijetnje najvišeg nivoa
Raspadanje
U1. Ubacivanje lažnih informacija od strane napadača kroz integracijski modul.
U1. Ubacivanje lažnih informacija od strane napadača kroz integracijski modul
Raspadanje
U1.1. Neovlaštena modifikacija legitimnih podataka kada se prenose preko mrežnih veza:
U1.1.1 Link: .
U1.2. Prijenos lažnih podataka putem komunikacijskih kanala u ime legitimnog učesnika u razmjeni:
U1.1.2 Link: .
U1.3. Neovlaštena modifikacija legitimnih podataka tokom njihove obrade na Exchange serverima ili posredniku:
U1.3.1. Veza: .
U1.4. Kreiranje lažnih podataka na Exchange serverima ili posredniku u ime legitimnog učesnika u razmjeni:
U1.4.1. Veza:
U1.5. Neovlaštena modifikacija podataka prilikom obrade pomoću softvera za obradu podataka:
U1.5.1. <…> zbog napadača koji neovlašteno mijenjaju postavke (konfiguracije) softvera za obradu podataka.
U1.5.2. <…> zbog napadača koji neovlašteno mijenjaju izvršne datoteke softvera za obradu podataka.
U1.5.3. <…> zbog interaktivne kontrole softvera za obradu podataka od strane napadača.
TIPIČNI MODEL PRIJETNJE. SISTEM ZAŠTITE KRIPTOGRAFSKIH INFORMACIJA
Objekt zaštite za koji se primjenjuje model prijetnje (opseg).
Predmet zaštite je kriptografski sistem zaštite informacija koji se koristi za osiguranje sigurnosti informacionog sistema.
arhitektura
Osnova svakog informacionog sistema je aplikativni softver koji implementira njegovu ciljnu funkcionalnost.
Kriptografska zaštita se obično implementira pozivanjem kriptografskih primitiva iz poslovne logike aplikativnog softvera, koji se nalaze u specijalizovanim bibliotekama - kripto jezgrama.
Kriptografski primitivi uključuju kriptografske funkcije niskog nivoa kao što su:
- šifriranje/dešifriranje bloka podataka;
- kreirati/verifikovati elektronski potpis bloka podataka;
- izračunati hash funkciju bloka podataka;
- generirati/učitati/učitati ključne informacije;
- i tako dalje.
Poslovna logika aplikacijskog softvera implementira funkcionalnost višeg nivoa koristeći kriptografske primitive:
- šifrirajte datoteku pomoću ključeva odabranih primatelja;
- uspostaviti sigurnu mrežnu vezu;
- obavještava o rezultatima provjere elektronskog potpisa;
- i tako dalje.
Interakcija poslovne logike i kripto jezgra može se izvesti:
- direktno, pozivanjem kriptografskih primitiva iz dinamičkih biblioteka kripto jezgra (.DLL) od strane poslovne logike Windows, .TAKO – za Linux);
- direktno, preko kriptografskih interfejsa - omotača, na primer, MS Crypto API, Java Cryptography Architecture, PKCS#11, itd. U ovom slučaju poslovna logika pristupa kripto interfejsu, a ono prevodi poziv u odgovarajuće kripto jezgro, koje u ovaj slučaj se zove kripto provajder. Upotreba kriptografskih sučelja omogućava aplikacijskom softveru da se apstrahuje od specifičnih kriptografskih algoritama i bude fleksibilniji.
Postoje dvije tipične sheme za organiziranje kripto jezgre:
Šema 1 – Monolitno kripto jezgro
Shema 2 – Podijeljena kripto jezgra
Elementi u gornjim dijagramima mogu biti ili pojedinačni softverski moduli koji rade na jednom računaru ili mrežni servisi koji komuniciraju unutar računarske mreže.
Kada se koriste sistemi izgrađeni prema Šemi 1, aplikativni softver i kripto jezgro rade unutar jednog operativnog okruženja za kripto alat (SFC), na primjer, na istom računaru, pod istim operativnim sistemom. Korisnik sistema, po pravilu, može da pokreće druge programe, uključujući i one koji sadrže zlonamerni kod, u okviru istog operativnog okruženja. U takvim uslovima postoji ozbiljan rizik od curenja privatnih kriptografskih ključeva.
Da bi se rizik sveo na minimum, koristi se šema 2, u kojoj je kripto jezgro podijeljeno na dva dijela:
- Prvi dio, zajedno sa aplikativnim softverom, radi u nepouzdanom okruženju gdje postoji rizik od zaraze zlonamjernim kodom. Ovaj dio ćemo nazvati “softverskim dijelom”.
- Drugi dio radi u pouzdanom okruženju na namjenskom uređaju, koji sadrži pohranu privatnog ključa. Od sada ćemo ovaj dio zvati “hardver”.
Podjela kripto jezgra na softverske i hardverske dijelove je vrlo proizvoljna. Na tržištu postoje sistemi izgrađeni prema šemi sa podijeljenim kripto jezgrom, ali "hardverski" dio je predstavljen u obliku slike virtuelne mašine - virtuelni HSM ().
Interakcija oba dijela kripto jezgre se događa na način da se privatni kriptografski ključevi nikada ne prenose u softverski dio i, shodno tome, ne mogu biti ukradeni korištenjem zlonamjernog koda.
Interakcioni interfejs (API) i skup kriptografskih primitiva koje kripto jezgro daje aplikacijskom softveru isti su u oba slučaja. Razlika je u načinu na koji se implementiraju.
Dakle, kada se koristi shema s podijeljenim kripto jezgrom, interakcija softvera i hardvera se provodi prema sljedećem principu:
- Softver izvodi kriptografske primitive koji ne zahtijevaju korištenje privatnog ključa (na primjer, izračunavanje hash funkcije, provjera elektronskog potpisa itd.).
- Kriptografski primitivi koji koriste privatni ključ (kreiranje elektronskog potpisa, dešifrovanje podataka, itd.) se izvode hardverskim putem.
Ilustrirajmo rad podijeljene kripto jezgre na primjeru kreiranja elektronskog potpisa:
- Softverski dio izračunava hash funkciju potpisanih podataka i prenosi ovu vrijednost na hardver preko kanala razmjene između kripto jezgri.
- Hardverski dio, koristeći privatni ključ i hash, generiše vrijednost elektronskog potpisa i prenosi je softverskom dijelu putem kanala za razmjenu.
- Softverski dio vraća primljenu vrijednost aplikativnom softveru.
Značajke provjere ispravnosti elektronskog potpisa
Kada primalac primi elektronski potpisane podatke, mora izvršiti nekoliko koraka verifikacije. Pozitivan rezultat provjere elektronskog potpisa postiže se samo ako su sve faze provjere uspješno završene.
Faza 1. Kontrola integriteta podataka i autorstva podataka.
Sadržaj bine. Elektronski potpis podataka provjerava se odgovarajućim kriptografskim algoritmom. Uspješno završena ova faza ukazuje da podaci nisu mijenjani od trenutka kada su potpisani, kao i da je potpis napravljen privatnim ključem koji odgovara javnom ključu za verifikaciju elektronskog potpisa.
Lokacija bine: kripto jezgro.
Faza 2. Kontrola povjerenja u javni ključ potpisnika i kontrola roka važenja privatnog ključa elektronskog potpisa.
Sadržaj bine. Faza se sastoji od dvije međufaze. Prvi je da se utvrdi da li je javni ključ za provjeru elektronskog potpisa bio pouzdan u trenutku potpisivanja podataka. Drugi određuje da li je privatni ključ elektronskog potpisa bio važeći u trenutku potpisivanja podataka. Općenito, periodi važenja ovih ključeva se možda ne podudaraju (na primjer, za kvalifikovane certifikate ključeva za verifikaciju elektronskog potpisa). Metode za uspostavljanje poverenja u javni ključ potpisnika određuju se pravilima elektronskog upravljanja dokumentima koje su usvojile strane u interakciji.
Lokacija bine: aplikativni softver / kripto jezgro.
Faza 3. Kontrola ovlaštenja potpisnika.
Sadržaj bine. U skladu sa utvrđenim pravilima elektronskog upravljanja dokumentima, provjerava se da li je potpisnik imao pravo ovjeriti zaštićene podatke. Kao primjer navedimo situaciju kršenja ovlaštenja. Pretpostavimo da postoji organizacija u kojoj svi zaposleni imaju elektronski potpis. Interni sistem elektronskog upravljanja dokumentima prima nalog od upravnika, ali potpisan elektronskim potpisom upravnika skladišta. Shodno tome, takav dokument se ne može smatrati legitimnim.
Lokacija bine: aplikativni softver.
Pretpostavke pri opisivanju objekta zaštite
- Kanali za prijenos informacija, sa izuzetkom kanala za razmjenu ključeva, također prolaze kroz aplikativni softver, API i kripto jezgro.
- Informacije o povjerenju u javne ključeve i (ili) certifikate, kao i informacije o ovlastima vlasnika javnih ključeva, nalaze se u spremištu javnih ključeva.
- Aplikacijski softver radi sa pohranjivanjem javnih ključeva preko kripto kernela.
Primjer informacionog sistema zaštićenog CIPF-om
Da bismo ilustrirali prethodno prikazane dijagrame, razmotrimo hipotetički informacioni sistem i istaknemo sve strukturne elemente na njemu.
Opis informacionog sistema
Dvije organizacije odlučile su da uvedu pravno značajno elektronsko upravljanje dokumentima (EDF) između sebe. Da bi to učinili, sklopili su ugovor u kojem su predvidjeli da će se dokumenti slati e-poštom, a da pritom moraju biti šifrirani i potpisani kvalifikovanim elektronskim potpisom. Office programe iz paketa Microsoft Office 2016 treba koristiti kao alate za kreiranje i obradu dokumenata, a CIPF CryptoPRO i softver za šifrovanje CryptoARM kao sredstva kriptografske zaštite.
Opis infrastrukture organizacije 1
Organizacija 1 odlučila je da instalira CIPF CryptoPRO i CryptoARM softver na radnu stanicu korisnika – fizički računar. Ključevi šifriranja i elektronskog potpisa bit će pohranjeni na mediju ključeva ruToken, koji će raditi u načinu preuzimanja ključa. Korisnik će pripremiti elektronske dokumente lokalno na svom računaru, zatim ih šifrirati, potpisati i poslati pomoću lokalno instaliranog email klijenta.
Opis infrastrukture organizacije 2
Organizacija 2 odlučila je da prebaci funkcije šifriranja i elektronskog potpisa na namjensku virtuelnu mašinu. U tom slučaju, sve kriptografske operacije će se izvršiti automatski.
Da bi se to postiglo, na namenskoj virtuelnoj mašini su organizovane dve mrežne fascikle: “...In”, “...Out”. Datoteke primljene od druge ugovorne strane u otvorenom obliku će automatski biti smještene u mrežnu mapu “…In”. Ovi fajlovi će biti dešifrovani i elektronski potpis će biti verifikovan.
Korisnik će u folder “...Out” smjestiti datoteke koje treba šifrirati, potpisati i poslati drugoj strani. Korisnik će sam pripremiti fajlove na svojoj radnoj stanici.
Za obavljanje funkcija šifriranja i elektronskog potpisa, na virtuelnoj mašini su instalirani CIPF CryptoPRO, CryptoARM softver i email klijent. Automatsko upravljanje svim elementima virtuelne mašine će se vršiti pomoću skripti koje su razvili administratori sistema. Rad skripti se prijavljuje u log fajlovima.
Kriptografski ključevi za elektronski potpis biće postavljeni na token sa nepovratnim JaCarta GOST ključem, koji će korisnik povezati sa svojim lokalnim računarom.
Token će biti proslijeđen na virtuelnu mašinu pomoću specijalizovanog USB-over-IP softvera instaliranog na radnoj stanici korisnika i na virtuelnoj mašini.
Sistemski sat na radnoj stanici korisnika u organizaciji 1 biće podešen ručno. Sistemski sat namenske virtuelne mašine u Organizaciji 2 biće sinhronizovan sa satom sistema hipervizora, koji će zauzvrat biti sinhronizovan preko Interneta sa serverima javnog vremena.
Identifikacija strukturnih elemenata CIPF-a
Na osnovu gornjeg opisa IT infrastrukture izdvojićemo strukturne elemente CIPF-a i zapisati ih u tabelu.
Tabela - Korespondencija elemenata CIPF modela sa elementima informacionog sistema
Naziv artikla
Organizacija 1
Organizacija 2
Aplikacioni softver
CryptoARM softver
CryptoARM softver
Softverski dio kripto jezgre
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Hardver za kripto jezgro
ne
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Prodavnica javnih ključeva
Korisnička radna stanica:
- HDD;
— standardno skladištenje certifikata Windows.
hipervizor:
- HDD.
Virtuelna mašina:
- HDD;
— standardno skladištenje certifikata Windows.
Skladištenje privatnog ključa
Nosilac ključa ruToken koji radi u načinu preuzimanja ključa
JaCarta GOST nosač ključa koji radi u načinu rada koji se ne može ukloniti
Kanal za razmjenu javnih ključeva
Korisnička radna stanica:
- RAM.
hipervizor:
- RAM.
Virtuelna mašina:
- RAM.
Kanal za razmjenu privatnih ključeva
Korisnička radna stanica:
— USB magistrala;
- RAM.
ne
Kanal za razmjenu između kripto jezgri
nedostaje (bez hardvera kripto jezgre)
Korisnička radna stanica:
— USB magistrala;
- RAM;
— USB-over-IP softverski modul;
- mrežni interfejs.
Korporativna mreža organizacije 2.
hipervizor:
- RAM;
- mrežni interfejs.
Virtuelna mašina:
— mrežni interfejs;
- RAM;
— USB-over-IP softverski modul.
Otvorite Data Channel
Korisnička radna stanica:
— ulazno-izlazna sredstva;
- RAM;
- HDD.
Korisnička radna stanica:
— ulazno-izlazna sredstva;
- RAM;
- HDD;
- mrežni interfejs.
Korporativna mreža organizacije 2.
hipervizor:
— mrežni interfejs;
- RAM;
- HDD.
Virtuelna mašina:
— mrežni interfejs;
- RAM;
- HDD.
Siguran kanal za razmjenu podataka
Internet.
Korporativna mreža organizacije 1.
Korisnička radna stanica:
- HDD;
- RAM;
- mrežni interfejs.
Internet.
Korporativna mreža organizacije 2.
hipervizor:
— mrežni interfejs;
- RAM;
- HDD.
Virtuelna mašina:
— mrežni interfejs;
- RAM;
- HDD.
Vremenski kanal
Korisnička radna stanica:
— ulazno-izlazna sredstva;
- RAM;
- sistemski tajmer.
Internet.
Korporativna mreža organizacija 2,
hipervizor:
— mrežni interfejs;
- RAM;
- sistemski tajmer.
Virtuelna mašina:
- RAM;
- sistemski tajmer.
Kanal za prijenos upravljačkih komandi
Korisnička radna stanica:
— ulazno-izlazna sredstva;
- RAM.
(Grafičko korisničko sučelje CryptoARM softvera)
Virtuelna mašina:
- RAM;
- HDD.
(Skripte za automatizaciju)
Kanal za prijem rezultata rada
Korisnička radna stanica:
— ulazno-izlazna sredstva;
- RAM.
(Grafičko korisničko sučelje CryptoARM softvera)
Virtuelna mašina:
- RAM;
- HDD.
(Datoteke evidencije skripti za automatizaciju)
Sigurnosne prijetnje najvišeg nivoa
Objašnjenja
Pretpostavke napravljene prilikom dekompozicije prijetnji:
- Koriste se jaki kriptografski algoritmi.
- Kriptografski algoritmi se bezbedno koriste u ispravnim režimima rada (npr. ne koristi se za šifriranje velikih količina podataka, uzima se u obzir dozvoljeno opterećenje ključa itd.).
- Napadači znaju sve algoritme, protokole i javne ključeve koji se koriste.
- Napadači mogu pročitati sve šifrirane podatke.
- Napadači su u mogućnosti da reprodukuju bilo koji softverski element u sistemu.
Raspadanje
U1. Kompromitacija privatnih kriptografskih ključeva.
U2. Šifriranje lažnih podataka u ime legitimnog pošiljaoca.
U3. Dešifriranje šifriranih podataka od strane osoba koje nisu legitimni primaoci podataka (napadači).
U4. Izrada elektronskog potpisa legitimnog potpisnika pod lažnim podacima.
U5. Dobivanje pozitivnog rezultata provjerom elektronskog potpisa krivotvorenih podataka.
U6. Pogrešan prijem elektronskih dokumenata na izvršenje zbog problema u organizovanju elektronskog toka dokumenata.
U7. Neovlašteni pristup zaštićenim podacima tokom njihove obrade od strane CIPF-a.
U1. Kompromitacija privatnih kriptografskih ključeva
U1.1. Preuzimanje privatnog ključa iz skladišta privatnih ključeva.
U1.2. Dobijanje privatnog ključa od objekata u operativnom okruženju kripto-alata, u kojem se može privremeno nalaziti.
Objašnjenja U1.2.
Objekti koji mogu privremeno pohraniti privatni ključ bi uključivali:
- RAM,
- privremeni fajlovi,
- zamijeniti fajlove,
- hibernacijski fajlovi,
- datoteke snimaka „vrućeg“ stanja virtuelnih mašina, uključujući datoteke sadržaja RAM memorije pauziranih virtuelnih mašina.
U1.2.1. Ekstrakcija privatnih ključeva iz radne RAM-a zamrzavanjem RAM modula, njihovim uklanjanjem i zatim čitanjem podataka (napad zamrzavanja).
Objašnjenja U1.2.1.
Primjer: .
U1.3. Dobijanje privatnog ključa iz kanala za razmjenu privatnih ključeva.
Objašnjenja U1.3.
Dat će se primjer implementacije ove prijetnje .
U1.4. Neovlaštena modifikacija kripto jezgre, zbog čega privatni ključevi postaju poznati napadačima.
U1.5. Kompromitacija privatnog ključa kao rezultat korištenja tehničkih kanala curenja informacija (TCIL).
Objašnjenja U1.5.
Primjer: .
U1.6. Kompromitacija privatnog ključa kao rezultat upotrebe posebnih tehničkih sredstava (STS) dizajniranih za tajno preuzimanje informacija („bugovi“).
U1.7. Kompromitacija privatnih ključeva tokom njihovog skladištenja izvan CIPF-a.
Objašnjenja U1.7.
Na primjer, korisnik pohranjuje svoje ključne medije u ladicu na radnoj površini, iz koje ih napadači lako mogu preuzeti.
U2. Šifriranje lažnih podataka u ime legitimnog pošiljaoca
Objašnjenja
Ova prijetnja se razmatra samo za šeme šifriranja podataka s autentifikacijom pošiljatelja. Primjeri takvih šema navedeni su u preporukama za standardizaciju . Za druge kriptografske šeme ova prijetnja ne postoji, jer se šifriranje vrši na javnim ključevima primatelja, a oni su općenito poznati napadačima.
Raspadanje
U2.1. Kompromitacija privatnog ključa pošiljaoca:
U2.1.1. Veza: .
U2.2. Zamjena ulaznih podataka u otvorenom kanalu razmjene podataka.
Napomene U2.2.
Primjeri implementacije ove prijetnje dati su u nastavku. и .
U3. Dešifriranje šifriranih podataka od strane osoba koje nisu legitimni primaoci podataka (napadači)
Raspadanje
U3.1. Kompromitacija privatnih ključeva primatelja šifriranih podataka.
U3.1.1 Link: .
U3.2. Zamjena šifriranih podataka u sigurnom kanalu za razmjenu podataka.
U4. Kreiranje elektronskog potpisa legitimnog potpisnika pod lažnim podacima
Raspadanje
U4.1. Kompromitacija privatnih ključeva elektronskog potpisa legitimnog potpisnika.
U4.1.1 Link: .
U4.2. Zamjena potpisanih podataka u otvorenom kanalu razmjene podataka.
Napomena U4.2.
Primjeri implementacije ove prijetnje dati su u nastavku. и .
U5. Dobivanje pozitivnog rezultata provjerom elektronskog potpisa krivotvorenih podataka
Raspadanje
U5.1. Napadači presreću poruku u kanalu za prenos rezultata rada o negativnom rezultatu provjere elektronskog potpisa i zamjenjuju je porukom s pozitivnim rezultatom.
U5.2. Napadači napadaju povjerenje u potpisivanje certifikata (SCRIPT - svi elementi su obavezni):
U5.2.1. Napadači generišu javni i privatni ključ za elektronski potpis. Ako sistem koristi sertifikate ključeva elektronskog potpisa, onda generišu sertifikat elektronskog potpisa koji je što sličniji sertifikatu nameravanog pošiljaoca podataka čiju poruku žele da krivotvore.
U5.2.2. Napadači vrše neovlašćene promjene u spremištu javnih ključeva, dajući javnom ključu generišu neophodan nivo povjerenja i ovlaštenja.
U5.2.3. Napadači potpisuju lažne podatke prethodno generiranim ključem za elektronski potpis i ubacuju ih u siguran kanal za razmjenu podataka.
U5.3. Napadači izvode napad koristeći istekle ključeve elektronskog potpisa zakonskog potpisnika (SCRIPT - svi elementi su obavezni):
U5.3.1. Napadači kompromituju istekle (trenutno nevažeće) privatne ključeve elektronskog potpisa legitimnog pošiljaoca.
U5.3.2. Napadači zamjenjuju vrijeme u kanalu za prenos vremena vremenom u kojem su kompromitovani ključevi još uvijek bili važeći.
U5.3.3. Napadači potpisuju lažne podatke prethodno kompromitovanim ključem za elektronski potpis i ubacuju ih u siguran kanal za razmjenu podataka.
U5.4. Napadači izvode napad koristeći kompromitovane ključeve elektronskog potpisa zakonskog potpisnika (SCRIPT - svi elementi su obavezni):
U5.4.1. Napadač pravi kopiju skladišta javnog ključa.
U5.4.2. Napadači kompromituju privatne ključeve jednog od legitimnih pošiljalaca. On uočava kompromis, opoziva ključeve, a informacija o opozivu ključa se stavlja u skladište javnih ključeva.
U5.4.3. Napadači zamjenjuju skladište javnog ključa prethodno kopiranim.
U5.4.4. Napadači potpisuju lažne podatke prethodno kompromitovanim ključem za elektronski potpis i ubacuju ih u siguran kanal za razmjenu podataka.
U5.5. <…> zbog prisustva grešaka u implementaciji 2. i 3. faze provjere elektronskog potpisa:
Objašnjenja U5.5.
Naveden je primjer implementacije ove prijetnje .
U5.5.1. Provjera povjerenja u certifikat ključa elektronskog potpisa samo prisustvom povjerenja u certifikat kojim je potpisan, bez CRL ili OCSP provjera.
Objašnjenja U5.5.1.
Primjer implementacije .
U5.5.2. Prilikom izgradnje lanca povjerenja za certifikat, ovlaštenja izdavanja certifikata se ne analiziraju
Objašnjenja U5.5.2.
Primjer napada na SSL/TLS certifikate.
Napadači su kupili legitimni sertifikat za svoju e-poštu. Zatim su napravili lažni certifikat lokacije i potpisali ga svojim certifikatom. Ako se vjerodajnice ne provjere, tada će se prilikom provjere lanca povjerenja ispostaviti da su ispravne, a prema tome, lažni certifikat će također biti ispravan.
U5.5.3. Prilikom izgradnje lanca povjerenja certifikata, srednji certifikati se ne provjeravaju za opoziv.
U5.5.4. CRL-ovi se ažuriraju rjeđe nego što ih izdaje certifikacijsko tijelo.
U5.5.5. Odluka o povjerenju elektronskom potpisu se donosi prije nego što se primi OCSP odgovor o statusu certifikata, poslan na zahtjev koji je učinjen kasnije od vremena kada je potpis generiran ili prije sljedećeg CRL-a nakon generiranja potpisa.
Objašnjenja U5.5.5.
U propisima većine CA, vrijeme opoziva certifikata se smatra vremenom izdavanja najbližeg CRL-a koji sadrži informacije o opozivu certifikata.
U5.5.6. Prilikom prijema potpisanih podataka ne provjerava se certifikat koji pripada pošiljaocu.
Objašnjenja U5.5.6.
Primjer napada. U odnosu na SSL certifikate: ne može se provjeriti korespondencija adrese pozvanog servera sa vrijednošću CN polja u certifikatu.
Primjer napada. Napadači su kompromitovali ključeve elektronskog potpisa jednog od učesnika platnog sistema. Nakon toga su hakovali mrežu drugog učesnika i u njegovo ime poslali platne dokumente potpisane kompromitovanim ključevima na server za poravnanje platnog sistema. Ako server samo analizira povjerenje i ne provjerava usklađenost, tada će se lažni dokumenti smatrati legitimnim.
U6. Pogrešan prijem elektronskih dokumenata na izvršenje zbog problema u organizovanju elektronskog toka dokumenata.
Raspadanje
U6.1. Primalac ne otkriva dupliranje primljenih dokumenata.
Objašnjenja U6.1.
Primjer napada. Napadači mogu presresti dokument koji se prenosi primaocu, čak i ako je kriptografski zaštićen, a zatim ga više puta poslati preko sigurnog kanala za prijenos podataka. Ako primalac ne identifikuje duplikate, onda će svi primljeni dokumenti biti percipirani i obrađeni kao različiti dokumenti.
U7. Neovlašteni pristup zaštićenim podacima tokom njihove obrade od strane CIPF-a
Raspadanje
U7.1. <…> zbog curenja informacija preko bočnih kanala (napad sa strane kanala).
Objašnjenja U7.1.
Primjer: .
U7.2. <…> zbog neutralizacije zaštite od neovlaštenog pristupa informacijama koje se obrađuju na CIPF-u:
U7.2.1. Rad CIPF-a u suprotnosti sa zahtjevima opisanim u dokumentaciji za CIPF.
U7.2.2. <…>, sprovedeno zbog prisustva ranjivosti u:
U7.2.2.1. <…> sredstva zaštite od neovlaštenog pristupa.
U7.2.2.2. <…> sam CIPF.
U7.2.2.3. <…> operativno okruženje kripto-alata.
Primjeri napada
Scenariji o kojima se govori u nastavku očigledno sadrže greške u informacijskoj sigurnosti i služe samo za ilustraciju mogućih napada.
Scenarij 1. Primjer implementacije prijetnji U2.2 i U4.2.
Opis objekta
AWS KBR softver i CIPF SCAD Signature su instalirani na fizičkom računaru koji nije povezan na računarsku mrežu. FKN vdToken se koristi kao nosač ključa u načinu rada sa neizmjenjivim ključem.
Propisi o poravnanju pretpostavljaju da stručnjak za obračun sa svog radnog računara preuzima elektronske poruke u čistom tekstu (šema stare KBR radne stanice) sa posebnog sigurnog servera datoteka, zatim ih upisuje na prenosivi USB fleš disk i prenosi na KBR radnu stanicu, gdje su šifrirani i znakovi. Nakon toga, specijalista prenosi sigurne elektronske poruke na otuđeni medij, a zatim ih preko svog radnog računara upisuje na fajl server, odakle idu u UTA, a zatim u platni sistem Banke Rusije.
U ovom slučaju, kanali za razmjenu otvorenih i zaštićenih podataka će uključivati: server datoteka, radni računar specijaliste i otuđene medije.
Napad
Neovlašćeni napadači instaliraju sistem daljinskog upravljanja na radni računar specijaliste i u trenutku pisanja naloga za plaćanje (elektronske poruke) na prenosivi medij, sadržaj jednog od njih zamjenjuju čistim tekstom. Specijalista prenosi naloge za plaćanje na automatizovano radno mesto KBR-a, potpisuje ih i šifruje ne primećujući zamenu (na primer, zbog velikog broja naloga za plaćanje na letu, umora, itd.). Nakon toga, lažni nalog za plaćanje, prošavši kroz tehnološki lanac, ulazi u platni sistem Banke Rusije.
Scenarij 2. Primjer implementacije prijetnji U2.2 i U4.2.
Opis objekta
Računar sa instaliranom radnom stanicom KBR, SCAD Signature i povezanim nosačem ključeva FKN vdToken radi u posebnoj prostoriji bez pristupa osoblja.
Stručnjak za proračun se povezuje na CBD radnu stanicu u režimu udaljenog pristupa preko RDP protokola.
Napad
Napadači presreću detalje pomoću kojih se stručnjak za proračun povezuje i radi sa CBD radnom stanicom (na primjer, putem zlonamjernog koda na svom računalu). Zatim se povezuju u njegovo ime i šalju lažni nalog za plaćanje u platni sistem Banke Rusije.
Scenarij 3. Primjer implementacije prijetnje U1.3.
Opis objekta
Razmotrimo jednu od hipotetičkih opcija za implementaciju ABS-KBR integracijskih modula za novu šemu (AWS KBR-N), u kojoj se elektronski potpis odlaznih dokumenata javlja na strani ABS-a. U ovom slučaju, pretpostavit ćemo da ABS radi na bazi operativnog sistema koji nije podržan od strane CIPF SKAD Signature, te se, shodno tome, kriptografska funkcionalnost prenosi na zasebnu virtuelnu mašinu - integraciju „ABS-KBR“ modul.
Kao nosilac ključa koristi se običan USB token koji radi u načinu preuzimanja ključa. Prilikom povezivanja ključnog medija na hipervizor, ispostavilo se da u sistemu nema slobodnih USB portova, pa je odlučeno da se USB token poveže preko mrežnog USB huba, a na virtuelni se instalira USB-over-IP klijent. mašina, koja bi komunicirala sa čvorištem.
Napad
Napadači su presreli privatni ključ elektronskog potpisa iz komunikacijskog kanala između USB čvorišta i hipervizora (podaci su prenošeni u čistom tekstu). Posjedujući privatni ključ, napadači su generirali lažni nalog za plaćanje, potpisali ga elektronskim potpisom i poslali na izvršenje na automatizirano radno mjesto KBR-N.
Scenario 4. Primjer implementacije prijetnji U5.5.
Opis objekta
Razmotrimo isti krug kao u prethodnom scenariju. Pretpostavićemo da elektronske poruke koje dolaze sa KBR-N radne stanice završavaju u fascikli …SHAREIn, a one koje se šalju na KBR-N radnu stanicu i dalje u platni sistem Banke Rusije idu u …SHAREout.
Također ćemo pretpostaviti da se prilikom implementacije integracijskog modula liste opozvanih certifikata ažuriraju samo pri ponovnom izdavanju kriptografskih ključeva, kao i da se elektronske poruke primljene u folderu …SHAREIn provjeravaju samo za kontrolu integriteta i kontrolu povjerenja u javnom ključu elektronski potpis.
Napad
Napadači su, koristeći ključeve ukradene u prethodnom scenariju, potpisali lažni platni nalog koji je sadržavao informaciju o prijemu novca na račun prevarantskog klijenta i uveo ga u siguran kanal za razmjenu podataka. Pošto ne postoji provera da je nalog za plaćanje potpisala Banka Rusije, on je prihvaćen za izvršenje.
izvor: www.habr.com
