Poveznice na druge dijelove studije
- (Ovdje si)
Ovaj članak dovršava seriju publikacija posvećenih osiguravanju informacijske sigurnosti bankovnih bezgotovinskih plaćanja. Ovdje ćemo pogledati tipične modele prijetnji koji se spominju u :
- .
- .
- .
- .
HABRO-UPOZORENJE!!! Dragi Khabrovci, ovo nije zabavan post.
40+ stranica materijala skrivenih ispod rezanja namijenjeno je pomoć u radu ili učenju ljudi specijalizirani za bankarstvo ili informacijsku sigurnost. Ovi materijali konačni su proizvod istraživanja i napisani su suhoparnim, formalnim tonom. U biti, to su praznine za dokumente interne informacijske sigurnosti.Pa, tradicionalno - “korištenje informacija iz članka u nezakonite svrhe kažnjivo je zakonom”. Produktivno čitanje!
Informacije za čitatelje koji se upoznaju sa studijom počevši od ove publikacije.
O čemu se radi u studiji?
Čitate vodič za stručnjaka zaduženog za osiguravanje informacijske sigurnosti plaćanja u banci.
Logika izlaganja
Na početku u и daje se opis zaštićenog objekta. Zatim unutra opisuje kako izgraditi sigurnosni sustav i govori o potrebi stvaranja modela prijetnji. U govori o tome koji modeli prijetnji postoje i kako nastaju. U и Prikazana je analiza stvarnih napada. и sadrže opis modela prijetnje, izgrađenog 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 mrežnom vezom koja funkcionira u podatkovnim mrežama izgrađenim na temelju TCP/IP steka.
arhitektura
Opis arhitektonskih elemenata:
- "Krajnji čvorovi" — čvorovi koji razmjenjuju zaštićene informacije.
- "Međučvorovi" — elementi mreže za prijenos podataka: usmjerivači, preklopnici, pristupni poslužitelji, proxy poslužitelji i druga oprema — preko koje se prenosi promet mrežne veze. Općenito, mrežna veza može funkcionirati bez međučvorova (izravno između krajnjih čvorova).
Sigurnosne prijetnje najviše razine
Raspad
U1. Neovlašteni pristup prenesenim podacima.
U2. Neovlaštena izmjena prenesenih podataka.
U 3. Povreda autorstva prenesenih podataka.
U1. Neovlašteni pristup prenesenim podacima
Raspad
U1.1. <…>, koje se izvode na završnim ili srednjim čvorovima:
U1.1.1. <…> čitanjem podataka dok su u uređajima za pohranu glavnog računala:
U1.1.1.1. <…> u RAM-u.
Objašnjenja za U1.1.1.1.
Na primjer, tijekom obrade podataka mrežnim stogom glavnog računala.
U1.1.1.2. <…> u trajnoj memoriji.
Objašnjenja za U1.1.1.2.
Na primjer, kod pohranjivanja prenesenih podataka u predmemoriju, privremene datoteke ili datoteke za razmjenu.
U1.2. <…>, koja se provodi na čvorovima podatkovne mreže treće strane:
U1.2.1. <…> metodom hvatanja svih paketa koji stižu na mrežno sučelje hosta:
Objašnjenja za U1.2.1.
Hvatanje svih paketa provodi se prebacivanjem mrežne kartice u promiskuitetni način rada (promiskuitetni način rada za žične adaptere ili način rada monitora za wi-fi adaptere).
U1.2.2. <…> izvođenjem napada čovjeka u sredini (MiTM), ali bez izmjene 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. <…>, provodi se ugradnjom posebnih tehničkih sredstava (STS) na krajnje ili srednje čvorove, namijenjenih tajnom prikupljanju podataka.
U2. Neovlaštena izmjena prenesenih podataka
Raspad
U2.1. <…>, koje se izvode na završnim 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 trajnoj memoriji:
U2.2. <…>, koje se provode na čvorovima trećih strana mreže za prijenos podataka:
U2.2.1. <…> izvođenjem napada čovjeka u sredini (MiTM) i preusmjeravanjem prometa na čvor napadača:
U2.2.1.1. Fizičko povezivanje 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 virtualnim lokalnim mrežama (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Neovlaštena izmjena VLAN postavki na preklopnicima ili usmjerivačima.
U2.2.1.2.2. <…> usmjeravanje prometa:
U2.2.1.2.2.1. Neovlaštena izmjena statičkih tablica usmjeravanja usmjerivača.
U2.2.1.2.2.2. Najava lažnih ruta od strane napadača putem protokola dinamičkog usmjeravanja.
U2.2.1.2.3. <…> automatska konfiguracija:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. <…> rješavanje adresa i naziva:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Neovlašteno mijenjanje datoteka naziva lokalnog računala (hosts, lmhosts, itd.)
U 3. Povreda autorskih prava prenesenih podataka
Raspad
U3.1. Neutralizacija mehanizama za utvrđivanje autorstva informacija navođenjem lažnih podataka o autoru ili izvoru podataka:
U3.1.1. Promjena podataka o autoru sadržanih u prenesenim informacijama.
U3.1.1.1. Neutralizacija kriptografske zaštite cjelovitosti i autorstva prenesenih podataka:
U3.1.1.1.1. Veza: .
U3.1.1.2. Neutralizacija zaštite autorskih prava prenesenih podataka, implementirana pomoću jednokratnih kodova za potvrdu:
U3.1.1.2.1. .
U3.1.2. Promjena podataka o izvoru prenesenih informacija:
U3.1.2.1. .
U3.1.2.2. .
TIPIČNI MODEL PRIJETNJE. INFORMACIJSKI SUSTAV IZGRAĐEN NA BAZI ARHITEKTURE KLIJENT-poslužitelj
Objekt zaštite za koji se primjenjuje model prijetnje (opseg).
Predmet zaštite je informacijski sustav izgrađen na bazi klijent-poslužitelj arhitekture.
arhitektura
Opis arhitektonskih elemenata:
- "Klijent" – uređaj na kojem radi klijentski dio informacijskog sustava.
- "poslužitelj" – uređaj na kojem radi serverski dio informacijskog sustava.
- "Skladište podataka" — dio poslužiteljske infrastrukture informacijskog sustava, dizajniran za pohranu podataka koje obrađuje informacijski sustav.
- "Mrežna veza" — kanal za razmjenu informacija između klijenta i poslužitelja koji prolazi kroz podatkovnu mrežu. Detaljniji opis modela elemenata dat je u .
Ograničenja
Prilikom modeliranja objekta postavljaju se sljedeća ograničenja:
- Korisnik komunicira s informacijskim sustavom unutar ograničenih vremenskih razdoblja, koja se nazivaju radnim sesijama.
- Na početku svake radne sesije korisnik se identificira, autentificira i autorizira.
- Sve zaštićene informacije pohranjuju se na serverskom dijelu informacijskog sustava.
Sigurnosne prijetnje najviše razine
Raspad
U1. Izvođenje neovlaštenih radnji od strane napadača u ime legitimnog korisnika.
U2. Neovlaštena izmjena zaštićenih informacija tijekom njihove obrade od strane serverskog dijela informacijskog sustava.
U1. Izvođenje neovlaštenih radnji od strane napadača u ime legitimnog korisnika
objašnjenja
Tipično u informacijskim sustavima radnje su u korelaciji s korisnikom koji ih je izvršio koristeći:
- dnevnici rada sustava (dnevnici).
- posebni atributi podatkovnih objekata koji sadrže podatke o korisniku koji ih je stvorio ili izmijenio.
U odnosu na radnu sesiju, ova se prijetnja može rastaviti na:
- <…> izvedeno unutar korisničke sesije.
- <…> izvršeno izvan korisničke sesije.
Korisnička sesija može se pokrenuti:
- Od strane samog korisnika.
- Zlonamjernici.
U ovoj fazi, srednja dekompozicija ove prijetnje izgledat će ovako:
U1.1. Unutar korisničke sesije izvršene su neovlaštene radnje:
U1.1.1. <…> instalirao napadnuti korisnik.
U1.1.2. <…> instalirali napadači.
U1.2. Neovlaštene radnje izvršene su izvan korisničke sesije.
Sa stajališta objekata informacijske infrastrukture na koje mogu utjecati napadači, dekompozicija međuprijetnji izgledat će 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.
Raspad
U1.1. Unutar korisničke sesije izvršene su neovlaštene radnje:
U1.1.1. <…> instalirao napadnuti korisnik:
U1.1.1.1. Napadači su djelovali neovisno o Naručitelju:
U1.1.1.1.1 Napadači su koristili standardne alate za pristup informacijskom sustavu:
U1.1.1.1.1.1. Napadači su koristili Klijentova fizička ulazno/izlazna sredstva (tipkovnica, miš, monitor ili dodirni zaslon mobilnog uređaja):
U1.1.1.1.1.1.1. Napadači su djelovali u vremenskim razdobljima kada je sesija bila aktivna, I/O sadržaji bili dostupni, a korisnik nije bio prisutan.
U1.1.1.1.1.2. Napadači su koristili alate za daljinsku administraciju (standardne ili osigurane zlonamjernim kodom) za kontrolu Klijenta:
U1.1.1.1.1.2.1. Napadači su djelovali u vremenskim razdobljima kada je sesija bila aktivna, I/O sadržaji 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 napadnutom korisniku.
U1.1.1.2. Napadači su zamijenili podatke u mrežnoj vezi između klijenta i poslužitelja, modificirajuć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 <…> instalirali napadači:
U1.1.2.1. Napadači su djelovali iz Naručitelja (И):
U1.1.2.1.1. Napadači su neutralizirali sustav kontrole pristupa informacijskom sustavu:
U1.1.2.1.1.1. Veza: .
U1.1.2.1.2. Napadači su koristili standardne alate za pristup informacijskom sustavu
U1.1.2.2. Napadači su djelovali iz drugih čvorova podatkovne mreže, s kojih se mogla uspostaviti mrežna veza s poslužiteljem (И):
U1.1.2.2.1. Napadači su neutralizirali sustav kontrole pristupa informacijskom sustavu:
U1.1.2.2.1.1. Veza: .
U1.1.2.2.2. Napadači su koristili nestandardne načine pristupa informacijskom sustavu.
Objašnjenja U1.1.2.2.2.
Napadači mogu instalirati standardni klijent informacijskog sustava na čvor treće strane ili mogu koristiti nestandardni softver koji implementira standardne protokole razmjene između klijenta i poslužitelja.
U1.2 Neovlaštene radnje izvedene su izvan korisničke sesije.
U1.2.1 Napadači su izveli neovlaštene radnje, a zatim izvršili neovlaštene promjene u zapisima rada informacijskog sustava ili posebnim atributima podatkovnih objekata, što ukazuje da je radnje koje su izvršili izvršio legitimni korisnik.
U2. Neovlaštena izmjena zaštićenih informacija tijekom njihove obrade od strane serverskog dijela informacijskog sustava
Raspad
U2.1. Napadači modificiraju zaštićene podatke koristeći standardne alate informacijskog sustava i to rade u ime legitimnog korisnika.
U2.1.1. Veza: .
U2.2. Napadači mijenjaju zaštićene informacije koristeći mehanizme pristupa podacima koji nisu predviđeni normalnim radom informacijskog sustava.
U2.2.1. Napadači mijenjaju datoteke koje sadrže zaštićene informacije:
U2.2.1.1. <…>, koristeći mehanizme za rukovanje datotekama koje pruža operativni sustav.
U2.2.1.2. <…> provocirajući vraćanje datoteka iz neovlašteno modificirane sigurnosne kopije.
U2.2.2. Napadači mijenjaju zaštićene informacije pohranjene u bazi podataka (И):
U2.2.2.1. Napadači neutraliziraju DBMS sustav kontrole pristupa:
U2.2.2.1.1. Veza: .
U2.2.2.2. Napadači mijenjaju informacije koristeći standardna DBMS sučelja za pristup podacima.
U2.3. Napadači mijenjaju zaštićene informacije neovlaštenom modifikacijom algoritama rada softvera koji ih obrađuje.
U2.3.1. Izvorni kod softvera podložan je izmjenama.
U2.3.1. Strojni kod softvera podložan je izmjenama.
U2.4. Napadači modificiraju zaštićene informacije iskorištavanjem ranjivosti softvera informacijskog sustava.
U2.5. Napadači mijenjaju zaštićene informacije kada se one prenose između komponenti poslužiteljskog dijela informacijskog sustava (na primjer, poslužitelj baze podataka i aplikacijski poslužitelj):
U2.5.1. Veza: .
TIPIČNI MODEL PRIJETNJE. SUSTAV 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. Informacijski sustav izgrađen na arhitekturi klijent-poslužitelj.”
U ovom modelu prijetnji, sustav kontrole korisničkog pristupa znači komponentu informacijskog sustava koja implementira sljedeće funkcije:
- Identifikacija korisnika.
- Autentifikacija korisnika.
- Ovlaštenja korisnika.
- Bilježenje radnji korisnika.
Sigurnosne prijetnje najviše razine
Raspad
U1. Neovlašteno uspostavljanje sesije u ime legitimnog korisnika.
U2. Neovlašteno povećanje korisničkih privilegija u informacijskom sustavu.
U1. Neovlašteno uspostavljanje sesije u ime legitimnog korisnika
objašnjenja
Razgradnja ove prijetnje općenito će ovisiti o vrsti sustava identifikacije korisnika i autentifikacije koji se koriste.
U ovom modelu razmatrat će se samo sustav 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.
Raspad
U1.1. <…> zbog ugrožavanja vjerodajnica:
U1.1.1. Napadači su kompromitirali vjerodajnice korisnika dok su ih pohranjivali.
Objašnjenja U1.1.1.
Na primjer, vjerodajnice mogu biti napisane na samoljepljivoj ceduljici zalijepljenoj na monitor.
U1.1.2. Korisnik je slučajno ili zlonamjerno proslijedio podatke o pristupu napadačima.
U1.1.2.1. Korisnik je naglas izgovorio vjerodajnice dok je ulazio.
U1.1.2.2. Korisnik je namjerno podijelio svoje vjerodajnice:
U1.1.2.2.1. <…> kolegama s posla.
Objašnjenja U1.1.2.2.1.
Na primjer, kako bi ga mogli zamijeniti tijekom bolesti.
U1.1.2.2.2. <…> izvođačima radova koji izvode radove na objektima informacijske infrastrukture.
U1.1.2.2.3. <…> trećim stranama.
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 vjerodajnice koristeći brute force metode:
U1.1.3.1. <…> korištenjem standardnih mehanizama pristupa.
U1.1.3.2. <…> koristeći prethodno presretnute kodove (na primjer, hashove zaporke) za pohranjivanje vjerodajnica.
U1.1.4. Napadači su koristili zlonamjerni kod za presretanje korisničkih vjerodajnica.
U1.1.5. Napadači su izvukli vjerodajnice iz mrežne veze između klijenta i poslužitelja:
U1.1.5.1. Veza: .
U1.1.6. Napadači su izvukli vjerodajnice iz zapisa sustava za praćenje rada:
U1.1.6.1. <…> sustavi videonadzora (ako su tijekom rada snimljeni pritisci tipki na tipkovnici).
U1.1.6.2. <…> sustavi za praćenje radnji zaposlenika za računalom
Objašnjenja U1.1.6.2.
Primjer takvog sustava 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 jasnom tekstu putem e-pošte.
U1.1.8. Napadači su dobili vjerodajnice nadgledanjem korisničke sesije pomoću sustava za udaljenu administraciju.
U1.1.9. Napadači su dobili vjerodajnice kao rezultat njihovog curenja kroz tehničke kanale (TCUI):
U1.1.9.1. Napadači su promatrali kako korisnik unosi vjerodajnice s tipkovnice:
U1.1.9.1.1 Napadači su se nalazili u neposrednoj blizini korisnika i vlastitim su očima vidjeli unos vjerodajnica.
Objašnjenja U1.1.9.1.1
Takvi slučajevi uključuju radnje kolega s posla ili slučaj kada je korisnikova tipkovnica vidljiva posjetiteljima organizacije.
U1.1.9.1.2 Napadači su koristili dodatna tehnička sredstva, poput dalekozora ili bespilotne letjelice, te su kroz prozor vidjeli unos vjerodajnica.
U1.1.9.2. Napadači su izvukli vjerodajnice iz radijske komunikacije između tipkovnice i jedinice računalnog sustava kada su bili povezani putem radijskog sučelja (na primjer, Bluetooth).
U1.1.9.3. Napadači su presreli vjerodajnice propuštajući ih kroz kanal lažnog elektromagnetskog zračenja i smetnji (PEMIN).
Objašnjenja U1.1.9.3.
Primjeri napada и .
U1.1.9.4. Napadač je presreo unos vjerodajnica s tipkovnice korištenjem posebnih tehničkih sredstava (STS) namijenjenih tajnom dobivanju informacija.
Objašnjenja U1.1.9.4.
Primjeri .
U1.1.9.5. Napadači su presreli unos vjerodajnica s tipkovnice pomoću
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 vjerodajnica s tipkovnice analizirajući zvukove pritiska na tipke.
Objašnjenja U1.1.9.6.
Primjer .
U1.1.9.7. Napadači su presreli unos vjerodajnica s tipkovnice mobilnog uređaja analizirajući očitanja akcelerometra.
Objašnjenja U1.1.9.7.
Primjer .
U1.1.10. <…>, prethodno spremljen na Klijentu.
Objašnjenja U1.1.10.
Na primjer, korisnik može spremiti prijavu i lozinku u preglednik za pristup određenom mjestu.
U1.1.11. Napadači su ugrozili vjerodajnice zbog nedostataka u procesu opoziva korisničkog pristupa.
Objašnjenja U1.1.11.
Na primjer, nakon što je korisnik dobio otkaz, njegovi računi su ostali deblokirani.
U1.2. <…> iskorištavanjem ranjivosti u sustavu kontrole pristupa.
U2. Neovlašteno podizanje korisničkih privilegija u informacijskom sustavu
Raspad
U2.1 <…> neovlaštenim mijenjanjem podataka koji sadrže informacije o korisničkim privilegijama.
U2.2 <…> korištenjem ranjivosti u sustavu kontrole pristupa.
U2.3. <…> zbog nedostataka u procesu upravljanja korisničkim pristupom.
Objašnjenja U2.3.
Primjer 1. Korisnik je dobio više pristupa za posao nego što mu je bilo potrebno iz poslovnih razloga.
Primjer 2: Nakon što je korisnik prebačen na drugo radno mjesto, prethodno dodijeljena prava pristupa nisu opozvana.
TIPIČNI MODEL PRIJETNJE. INTEGRACIJSKI MODUL
Objekt zaštite za koji se primjenjuje model prijetnje (opseg).
Integracijski modul je skup objekata informacijske infrastrukture dizajniran za organiziranje razmjene informacija između informacijskih sustava.
S obzirom na to da u korporativnim mrežama nije uvijek moguće jednoznačno odvojiti jedan informacijski sustav od drugoga, integracijski modul se može smatrati i poveznicom između komponenti unutar jednog informacijskog sustava.
arhitektura
Generalizirani dijagram integracijskog modula izgleda ovako:
Opis arhitektonskih elemenata:
- "Exchange Server (SO)" – čvor / usluga / komponenta informacijskog sustava koja obavlja funkciju razmjene podataka s drugim informacijskim sustavom.
- "Posrednik" – čvor/usluga namijenjena organiziranju interakcije između informacijskih sustava, ali ne i njihov dio.
Primjeri "Posrednici" mogu postojati usluge e-pošte, sabirnice poslovnih usluga (sabirnica poslovnih usluga / SoA arhitektura), poslužitelji 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 pretvorbu formata.
Na primjer, pretvaranje podataka iz UFEBS formata u ABS format, mijenjanje statusa poruka tijekom prijenosa itd. - "Mrežna veza" odgovara objektu opisanom u standardnom modelu prijetnji “Mrežna veza”. Neke od mrežnih veza prikazanih na gornjem dijagramu možda ne postoje.
Primjeri integracijskih modula
Shema 1. Integracija ABS-a i AWS KBR-a putem poslužitelja datoteka treće strane
Za izvršenje plaćanja ovlašteni djelatnik banke preuzima elektroničke platne dokumente iz središnjeg bankovnog sustava i sprema ih u datoteku (u vlastitom formatu, npr. SQL dump) u mrežnu mapu (...SHARE) na datotečnom poslužitelju. Zatim se ova datoteka pretvara pomoću skripte pretvarača u skup datoteka u UFEBS formatu, koje zatim čita CBD radna stanica.
Nakon toga, ovlašteni zaposlenik - korisnik automatiziranog radnog mjesta KBR - šifrira i potpisuje primljene datoteke i šalje ih u sustav plaćanja Banke Rusije.
Kada primi uplate od Banke Rusije, automatizirano radno mjesto KBR-a ih dešifrira i provjerava elektronički potpis, nakon čega ih bilježi u obliku skupa datoteka u formatu UFEBS na poslužitelju datoteka. Prije uvoza platnih dokumenata u ABS, oni se pretvaraju konverterskom skriptom iz UFEBS formata u ABS format.
Pretpostavit ćemo da u ovoj shemi ABS radi na jednom fizičkom poslužitelju, KBR radna stanica radi na namjenskom računalu, a skripta pretvarača radi na datotečnom poslužitelju.
Podudarnost objekata razmatranog dijagrama s elementima modela integracijskog modula:
“Exchange server sa ABS strane” – ABS poslužitelj.
“Exchange poslužitelj sa strane AWS KBR” – računalna radna stanica KBR.
"Posrednik" – poslužitelj datoteka treće strane.
"Softver za obradu podataka" – pretvarač skripti.
Shema 2. Integracija ABS-a i AWS KBR-a prilikom postavljanja zajedničke mrežne mape s plaćanjima na AWS KBR
Sve je slično shemi 1, ali se ne koristi zasebni datotečni poslužitelj, već se mrežna mapa (...SHARE) s elektroničkim platnim dokumentima postavlja na računalo s radnom stanicom CBD-a. Skripta pretvarača također radi na CBD radnoj stanici.
Podudarnost objekata razmatranog dijagrama s elementima modela integracijskog modula:
Slično shemi 1, ali "Posrednik" nije korišteno.
Shema 3. Integracija ABS-a i automatiziranog radnog mjesta KBR-N preko IBM WebSphera MQ i potpisivanje elektroničkih dokumenata “na ABS strani”
ABS radi na platformi koju ne podržava CIPF SCAD potpis. Potpisivanje odlaznih elektroničkih dokumenata provodi se na posebnom poslužitelju za elektronički potpis (ES Server). Isti poslužitelj provjerava elektronički potpis na dokumentima koji dolaze iz Banke Rusije.
ABS učitava datoteku s dokumentima plaćanja u vlastitom formatu na ES Server.
ES poslužitelj pomoću skripte pretvarača pretvara datoteku u elektroničke poruke u UFEBS formatu, nakon čega se elektroničke 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 sustav Banke Rusije.
Kada primi uplate od Banke Rusije, automatizirano radno mjesto KBR-N ih dešifrira i provjerava elektronički potpis. Uspješno obrađena plaćanja u obliku dekriptiranih i potpisanih elektroničkih poruka u UFEBS formatu prenose se u IBM WebSphere MQ, odakle ih prima poslužitelj elektroničkog potpisa.
Poslužitelj elektroničkog potpisa provjerava elektronički potpis primljenih uplata i pohranjuje ih u datoteku u ABS formatu. Nakon toga ovlašteni djelatnik – korisnik ABS-a na propisani način učitava dobivenu datoteku u ABS.
Podudarnost objekata razmatranog dijagrama s elementima modela integracijskog modula:
“Exchange server sa ABS strane” – ABS poslužitelj.
“Exchange poslužitelj sa strane AWS KBR” — računalna radna stanica KBR.
"Posrednik" – ES poslužitelj i IBM WebSphere MQ.
"Softver za obradu podataka" – pretvarač skripti, CIPF SCAD potpis na ES poslužitelju.
Shema 4. Integracija RBS poslužitelja i temeljnog bankovnog sustava putem API-ja koji pruža namjenski poslužitelj za razmjenu
Pretpostavit ćemo da banka koristi nekoliko sustava daljinskog bankarstva (RBS):
- "Internet klijent-banka" za fizička lica (IKB FL);
- "Internet klijent-banka" za pravna lica (IKB LE).
Kako bi se osigurala informacijska sigurnost, sva interakcija između ABS-a i sustava daljinskog bankarstva odvija se putem namjenskog poslužitelja za razmjenu koji djeluje u okviru informacijskog sustava ABS-a.
Zatim ćemo razmotriti proces interakcije između RBS sustava IKB LE i ABS-a.
RBS poslužitelj, nakon što od klijenta primi uredno ovjeren nalog za plaćanje, mora na temelju njega kreirati odgovarajući dokument u ABS-u. Da bi to učinio, pomoću API-ja prenosi informacije poslužitelju za razmjenu, koji zauzvrat unosi podatke u ABS.
Kada se stanje na računu klijenta promijeni, ABS generira elektroničke obavijesti, koje se putem servera za razmjenu prenose na poslužitelj udaljenog bankarstva.
Podudarnost objekata razmatranog dijagrama s elementima modela integracijskog modula:
“Exchange poslužitelj sa strane RBS-a” – RBS server IKB YUL.
“Exchange server sa ABS strane” – poslužitelj za razmjenu.
"Posrednik" - odsutan.
"Softver za obradu podataka" – Komponente RBS poslužitelja odgovorne za korištenje API-ja poslužitelja razmjene, komponente poslužitelja razmjene odgovorne za korištenje API-ja temeljnog bankarstva.
Sigurnosne prijetnje najviše razine
Raspad
U1. Ubacivanje lažnih informacija od strane napadača kroz integracijski modul.
U1. Ubacivanje lažnih informacija od strane napadača kroz integracijski modul
Raspad
U1.1. Neovlaštena izmjena legitimnih podataka kada se prenose preko mrežnih veza:
U1.1.1 Link: .
U1.2. Prijenos lažnih podataka komunikacijskim kanalima u ime legitimnog sudionika razmjene:
U1.1.2 Link: .
U1.3. Neovlaštena izmjena legitimnih podataka tijekom njihove obrade na Exchange poslužiteljima ili posredniku:
U1.3.1. Veza: .
U1.4. Stvaranje lažnih podataka na Exchange poslužiteljima ili posredniku u ime legitimnog sudionika razmjene:
U1.4.1. Veza:
U1.5. Neovlaštena izmjena podataka kada se obrađuju pomoću softvera za obradu podataka:
U1.5.1. <…> zbog napadača koji su neovlašteno mijenjali postavke (konfiguraciju) softvera za obradu podataka.
U1.5.2. <…> zbog napadača koji su neovlašteno mijenjali 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. KRIPTOGRAFSKI SUSTAV ZAŠTITE INFORMACIJA
Objekt zaštite za koji se primjenjuje model prijetnje (opseg).
Predmet zaštite je kriptografski informacijski sustav zaštite koji služi za osiguranje sigurnosti informacijskog sustava.
arhitektura
Temelj svakog informacijskog sustava je aplikativni softver koji implementira njegovu ciljanu funkcionalnost.
Kriptografska zaštita najčešće se provodi pozivanjem kriptografskih primitiva iz poslovne logike aplikacijskog softvera, koje se nalaze u specijaliziranim bibliotekama – kripto jezgrama.
Kriptografske primitive uključuju kriptografske funkcije niske razine, kao što su:
- šifrirati/dešifrirati blok podataka;
- izraditi/provjeriti elektronički potpis bloka podataka;
- izračunati hash funkciju bloka podataka;
- generiranje/učitavanje/učitavanje ključnih informacija;
- itd.
Poslovna logika aplikacijskog softvera implementira funkcionalnost više razine pomoću kriptografskih primitiva:
- šifrirati datoteku pomoću ključeva odabranih primatelja;
- uspostavite sigurnu mrežnu vezu;
- obavijestiti o rezultatima provjere elektroničkog potpisa;
- i tako dalje.
Interakcija poslovne logike i kripto jezgre može se izvesti:
- izravno, poslovnom logikom pozivajući kriptografske primitive iz dinamičkih biblioteka kripto jezgre (.DLL za Windows, .SO za Linux);
- izravno, preko kriptografskih sučelja - omotača, npr. MS Crypto API, Java Cryptography Architecture, PKCS#11 itd. U ovom slučaju poslovna logika pristupa kripto sučelju, a ono prevodi poziv u odgovarajuću kripto jezgru, koja u ovaj slučaj se zove kriptoprovajder. Korištenje kriptografskih sučelja omogućuje apstraktnom softveru da se odvoji od specifičnih kriptografskih algoritama i bude fleksibilniji.
Postoje dvije tipične sheme za organiziranje kripto jezgre:
Shema 1 – Monolitna kripto jezgra
Shema 2 – Split kripto jezgre
Elementi u gornjim dijagramima mogu biti pojedinačni softverski moduli koji se izvode na jednom računalu ili mrežne usluge koje međusobno djeluju unutar računalne mreže.
Kada se koriste sustavi izgrađeni prema shemi 1, aplikacijski softver i kripto jezgra rade unutar jednog operativnog okruženja za kripto alat (SFC), na primjer, na istom računalu, na kojem se izvodi isti operativni sustav. Korisnik sustava, u pravilu, može pokretati druge programe, uključujući i one koji sadrže maliciozni kod, unutar istog operativnog okruženja. U takvim uvjetima postoji ozbiljan rizik od curenja privatnih kriptografskih ključeva.
Kako bi se smanjio rizik, koristi se shema 2, u kojoj je kripto jezgra podijeljena na dva dijela:
- Prvi dio, zajedno s aplikacijskim softverom, radi u nepouzdanom okruženju gdje postoji rizik od zaraze zlonamjernim kodom. Ovaj dio ćemo nazvati "softverski dio".
- 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 jezgre na softverski i hardverski dio vrlo je proizvoljna. Na tržištu postoje sustavi izgrađeni prema shemi s podijeljenom kripto jezgrom, ali čiji je “hardverski” dio predstavljen u obliku slike virtualnog stroja - virtualnog HSM-a ().
Interakcija obaju dijelova kripto jezgre događa se na način da se privatni kriptografski ključevi nikada ne prenose u softverski dio te se, sukladno tome, ne mogu ukrasti zlonamjernim kodom.
Interakcijsko sučelje (API) i skup kriptografskih primitiva koje kripto jezgra daje aplikacijskom softveru isti su u oba slučaja. Razlika je u načinu na koji se provode.
Dakle, kada se koristi shema s podijeljenom kripto jezgrom, interakcija softvera i hardvera provodi se prema sljedećem principu:
- Kriptografske primitive koje ne zahtijevaju korištenje privatnog ključa (na primjer, izračunavanje hash funkcije, provjera elektroničkog potpisa itd.) izvodi softver.
- Kriptografske primitive koje koriste privatni ključ (izrada elektroničkog potpisa, dešifriranje podataka itd.) izvode se hardverski.
Ilustrirajmo rad podijeljene kripto jezgre na primjeru izrade elektroničkog potpisa:
- Softverski dio izračunava hash funkciju potpisanih podataka i prenosi tu vrijednost hardveru putem kanala razmjene između kripto jezgri.
- Hardverski dio pomoću privatnog ključa i hasha generira vrijednost elektroničkog potpisa i putem razmjenskog kanala prenosi je softverskom dijelu.
- Softverski dio vraća primljenu vrijednost aplikacijskom softveru.
Značajke provjere ispravnosti elektroničkog potpisa
Kada primatelj primi elektronički potpisane podatke, mora provesti nekoliko koraka provjere. Pozitivan rezultat provjere elektroničkog potpisa postiže se samo ako su svi stupnjevi provjere uspješno završeni.
Faza 1. Kontrola cjelovitosti podataka i autorstva podataka.
Sadržaj pozornice. Elektronički potpis podataka provjerava se odgovarajućim kriptografskim algoritmom. Uspješan završetak ove faze označava da podaci nisu mijenjani od trenutka kada su potpisani, kao i da je potpis obavljen privatnim ključem koji odgovara javnom ključu za provjeru elektroničkog potpisa.
Lokacija pozornice: kripto jezgra.
Faza 2. Kontrola povjerenja u javni ključ potpisnika i kontrola roka valjanosti privatnog ključa elektroničkog potpisa.
Sadržaj pozornice. Stadij se sastoji od dva srednja podstadija. Prvi je utvrditi je li javni ključ za provjeru elektroničkog potpisa bio pouzdan u trenutku potpisivanja podataka. Drugim se utvrđuje je li privatni ključ elektroničkog potpisa bio valjan u trenutku potpisivanja podataka. Općenito, rokovi valjanosti ovih ključeva ne moraju se podudarati (na primjer, za kvalificirane certifikate ključeva za provjeru elektroničkog potpisa). Načini uspostavljanja povjerenja u javni ključ potpisnika određeni su pravilima upravljanja elektroničkim dokumentima koja su usvojile strane u interakciji.
Lokacija pozornice: aplikacijski softver / kripto jezgra.
Faza 3. Kontrola ovlasti potpisnika.
Sadržaj pozornice. Sukladno utvrđenim pravilima upravljanja elektroničkim dokumentima, provjerava se je li potpisnik imao pravo ovjeriti zaštićene podatke. Kao primjer navedimo situaciju povrede ovlasti. Pretpostavimo da postoji organizacija u kojoj svi zaposlenici imaju elektronički potpis. Interni sustav elektroničkog upravljanja dokumentima prima nalog od voditelja, ali potpisan elektroničkim potpisom voditelja skladišta. Sukladno tome, takav se dokument ne može smatrati legitimnim.
Lokacija pozornice: aplikacijski softver.
Pretpostavke pri opisu predmeta zaštite
- Kanali prijenosa informacija, s izuzetkom kanala za razmjenu ključeva, također prolaze kroz aplikacijski softver, API i kripto jezgru.
- Podaci o povjerenju u javne ključeve i (ili) certifikate, kao i podaci o ovlastima vlasnika javnih ključeva nalaze se u spremištu javnih ključeva.
- Aplikacijski softver radi s pohranom javnih ključeva kroz kripto jezgru.
Primjer informacijskog sustava zaštićenog CIPF-om
Kako bismo ilustrirali prethodno prikazane dijagrame, razmotrimo hipotetski informacijski sustav i označimo sve strukturne elemente na njemu.
Opis informacijskog sustava
Dvije su organizacije odlučile međusobno uvesti pravno značajno upravljanje elektroničkim dokumentima (EDF). Za to su sklopili ugovor u kojem su odredili da će se dokumenti slati mailom, a pritom moraju biti kriptirani i potpisani kvalificiranim elektroničkim potpisom. Kao alati za izradu i obradu dokumenata trebaju se koristiti Office programi iz paketa Microsoft Office 2016, a kao sredstva kriptografske zaštite CIPF CryptoPRO i softver za šifriranje CryptoARM.
Opis infrastrukture organizacije 1
Organizacija 1 odlučila je instalirati CIPF CryptoPRO i CryptoARM softver na korisnikovu radnu stanicu – fizičko računalo. Ključevi za šifriranje i elektronički potpis bit će pohranjeni na ključnom mediju ruToken, koji će raditi u modu povratnog ključa. Korisnik će pripremiti elektroničke dokumente lokalno na svom računalu, zatim ih šifrirati, potpisati i poslati pomoću lokalno instaliranog klijenta e-pošte.
Opis infrastrukture organizacije 2
Organizacija 2 odlučila je premjestiti funkcije šifriranja i elektroničkog potpisa na namjensko virtualno računalo. U tom će se slučaju sve kriptografske operacije izvršiti automatski.
Da biste to učinili, organizirane su dvije mrežne mape na namjenskom virtualnom računalu: “...In”, “...Out”. Datoteke primljene od druge ugovorne strane u otvorenom obliku automatski će se smjestiti u mrežnu mapu “…U”. Te će se datoteke dešifrirati, a elektronički potpis provjeriti.
Korisnik će u mapu “…Out” smjestiti datoteke koje treba šifrirati, potpisati i poslati drugoj ugovornoj strani. Korisnik će sam pripremiti datoteke na svojoj radnoj stanici.
Za izvršavanje funkcija enkripcije i elektroničkog potpisa, CIPF CryptoPRO, CryptoARM softver i klijent e-pošte instalirani su na virtualnom računalu. Automatsko upravljanje svim elementima virtualnog stroja provodit će se pomoću skripti koje su razvili administratori sustava. Rad skripti se bilježi u log datotekama.
Kriptografski ključevi za elektronički potpis bit će smješteni na tokenu s nepovratnim JaCarta GOST ključem koji će korisnik spojiti na svoje lokalno računalo.
Token će biti proslijeđen virtualnom stroju pomoću specijaliziranog USB-over-IP softvera instaliranog na radnoj stanici korisnika i na virtualnom stroju.
Sistemski sat na radnoj stanici korisnika u organizaciji 1 bit će podešen ručno. Sistemski sat namjenskog virtualnog stroja u Organizaciji 2 bit će sinkroniziran sa satom sustava hipervizora, koji će se zauzvrat sinkronizirati preko interneta s javnim vremenskim poslužiteljima.
Identifikacija strukturnih elemenata CIPF-a
Na temelju gornjeg opisa informatičke infrastrukture izdvojit ćemo strukturne elemente CIPF-a i upisati ih u tablicu.
Tablica - Podudarnost elemenata CIPF modela s elementima informacijskog sustava
Naziv stavke
Organizacija 1
Organizacija 2
Aplikacijski softver
CryptoARM softver
CryptoARM softver
Softverski dio kripto jezgre
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Hardver kripto jezgre
ne
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Pohrana javnih ključeva
Radna stanica korisnika:
- HDD;
- standardno Windows spremište certifikata.
Hipervizor:
- HDD.
Virtualni stroj:
- HDD;
- standardno Windows spremište certifikata.
Pohrana privatnog ključa
Nositelj ključeva ruToken radi u modu povratnog ključa
JaCarta GOST nosač ključeva koji radi u načinu rada koji se ne može ukloniti
Javni kanal za razmjenu ključeva
Radna stanica korisnika:
- RADNA MEMORIJA.
Hipervizor:
- RADNA MEMORIJA.
Virtualni stroj:
- RADNA MEMORIJA.
Kanal za razmjenu privatnih ključeva
Radna stanica korisnika:
— USB sabirnica;
- RADNA MEMORIJA.
ne
Kanal razmjene između kripto jezgri
nedostaje (nema hardvera kripto jezgre)
Radna stanica korisnika:
— USB sabirnica;
- RADNA MEMORIJA;
— USB-over-IP softverski modul;
- mrežno sučelje.
Korporativna mreža organizacije 2.
Hipervizor:
- RADNA MEMORIJA;
- mrežno sučelje.
Virtualni stroj:
— mrežno sučelje;
- RADNA MEMORIJA;
— USB-over-IP softverski modul.
Otvoreni podatkovni kanal
Radna stanica korisnika:
— ulazno-izlazna sredstva;
- RADNA MEMORIJA;
- HDD.
Radna stanica korisnika:
— ulazno-izlazna sredstva;
- RADNA MEMORIJA;
- HDD;
- mrežno sučelje.
Korporativna mreža organizacije 2.
Hipervizor:
— mrežno sučelje;
- RADNA MEMORIJA;
- HDD.
Virtualni stroj:
— mrežno sučelje;
- RADNA MEMORIJA;
- HDD.
Siguran kanal razmjene podataka
Internet.
Korporativna mreža organizacije 1.
Radna stanica korisnika:
- HDD;
- RADNA MEMORIJA;
- mrežno sučelje.
Internet.
Korporativna mreža organizacije 2.
Hipervizor:
— mrežno sučelje;
- RADNA MEMORIJA;
- HDD.
Virtualni stroj:
— mrežno sučelje;
- RADNA MEMORIJA;
- HDD.
Vremenski kanal
Radna stanica korisnika:
— ulazno-izlazna sredstva;
- RADNA MEMORIJA;
- mjerač vremena sustava.
Internet.
Korporativna mreža organizacije 2,
Hipervizor:
— mrežno sučelje;
- RADNA MEMORIJA;
- mjerač vremena sustava.
Virtualni stroj:
- RADNA MEMORIJA;
- mjerač vremena sustava.
Kanal za prijenos upravljačkih naredbi
Radna stanica korisnika:
— ulazno-izlazna sredstva;
- RADNA MEMORIJA.
(Grafičko korisničko sučelje softvera CryptoARM)
Virtualni stroj:
- RADNA MEMORIJA;
- HDD.
(Skripte za automatizaciju)
Kanal za primanje rezultata rada
Radna stanica korisnika:
— ulazno-izlazna sredstva;
- RADNA MEMORIJA.
(Grafičko korisničko sučelje softvera CryptoARM)
Virtualni stroj:
- RADNA MEMORIJA;
- HDD.
(Datoteke dnevnika skripti za automatizaciju)
Sigurnosne prijetnje najviše razine
objašnjenja
Pretpostavke prilikom razlaganja prijetnji:
- Koriste se jaki kriptografski algoritmi.
- Kriptografski algoritmi koriste se sigurno u ispravnim načinima rada (npr. ne koristi se za šifriranje velikih količina podataka, uzima se u obzir dopušteno opterećenje ključa itd.).
- Napadači znaju sve algoritme, protokole i javne ključeve koji se koriste.
- Napadači mogu čitati sve šifrirane podatke.
- Napadači mogu reproducirati sve softverske elemente u sustavu.
Raspad
U1. Kompromitacija privatnih kriptografskih ključeva.
U2. Šifriranje lažnih podataka u ime legitimnog pošiljatelja.
U 3. Dešifriranje šifriranih podataka od strane osoba koje nisu legitimni primatelji podataka (napadači).
U 4. Izrada elektroničkog potpisa legitimnog potpisnika pod lažnim podacima.
U5. Dobivanje pozitivnog rezultata provjere elektroničkog potpisa krivotvorenih podataka.
U 6. Pogrešno prihvaćanje elektroničkih dokumenata na izvršenje zbog problema u organizaciji upravljanja elektroničkim dokumentima.
U7. Neovlašteni pristup zaštićenim podacima tijekom njihove obrade od strane CIPF-a.
U1. Kompromitacija privatnih kriptografskih ključeva
U1.1. Dohvaćanje privatnog ključa iz spremišta privatnih ključeva.
U1.2. Dobivanje privatnog ključa od objekata u radnom okruženju kripto-alata, u kojem se može privremeno nalaziti.
Objašnjenja U1.2.
Objekti koji mogu privremeno pohraniti privatni ključ uključuju:
- RADNA MEMORIJA,
- privremene datoteke,
- swap datoteke,
- datoteke hibernacije,
- snapshot datoteke "vrućeg" stanja virtualnih strojeva, uključujući datoteke sadržaja RAM-a pauziranih virtualnih strojeva.
U1.2.1. Izdvajanje privatnih ključeva iz radnog RAM-a zamrzavanjem RAM modula, njihovim uklanjanjem i potom čitanjem podataka (freeze attack).
Objašnjenja U1.2.1.
Primjer .
U1.3. Dobivanje privatnog ključa iz kanala razmjene privatnih ključeva.
Objašnjenja U1.3.
Dat će se primjer provedbe ove prijetnje .
U1.4. Neovlaštena izmjena kripto jezgre, zbog čega privatni ključevi postaju poznati napadačima.
U1.5. Kompromitacija privatnog ključa kao rezultat korištenja kanala curenja tehničkih informacija (TCIL).
Objašnjenja U1.5.
Primjer .
U1.6. Kompromitacija privatnog ključa kao rezultat uporabe posebnih tehničkih sredstava (STS) dizajniranih za tajno dohvaćanje informacija ("bugovi").
U1.7. Kompromitacija privatnih ključeva tijekom njihove pohrane izvan CIPF-a.
Objašnjenja U1.7.
Na primjer, korisnik pohranjuje svoje ključne medije u ladicu radne površine, odakle ih napadači lako mogu dohvatiti.
U2. Šifriranje lažnih podataka u ime legitimnog pošiljatelja
objašnjenja
Ova se prijetnja razmatra samo za sheme šifriranja podataka s provjerom autentičnosti pošiljatelja. Primjeri takvih shema navedeni su u preporukama za standardizaciju . Za druge kriptografske sheme ova prijetnja ne postoji, budući da se enkripcija provodi na javnim ključevima primatelja, a oni su općenito poznati napadačima.
Raspad
U2.1. Ugrožavanje privatnog ključa pošiljatelja:
U2.1.1. Veza: .
U2.2. Zamjena ulaznih podataka u otvorenom kanalu razmjene podataka.
Bilješke U2.2.
Primjeri implementacije ove prijetnje navedeni su u nastavku. и .
U 3. Dešifriranje šifriranih podataka od strane osoba koje nisu legitimni primatelji podataka (napadači)
Raspad
U3.1. Kompromitacija privatnih ključeva primatelja šifriranih podataka.
U3.1.1 Link: .
U3.2. Zamjena kriptiranih podataka u sigurnom kanalu razmjene podataka.
U 4. Izrada elektroničkog potpisa legitimnog potpisnika pod lažnim podacima
Raspad
U4.1. Kompromitacija privatnih ključeva elektroničkog potpisa legitimnog potpisnika.
U4.1.1 Link: .
U4.2. Zamjena potpisanih podataka u otvorenom kanalu razmjene podataka.
Napomena U4.2.
Primjeri implementacije ove prijetnje navedeni su u nastavku. и .
U5. Dobivanje pozitivnog rezultata provjere elektroničkog potpisa krivotvorenih podataka
Raspad
U5.1. Napadači presreću poruku u kanalu za prijenos rezultata rada o negativnom rezultatu provjere elektroničkog potpisa i zamjenjuju je porukom s pozitivnim rezultatom.
U5.2. Napadači napadaju povjerenje u potpisivanje certifikata (SKRIPTA - svi elementi su obavezni):
U5.2.1. Napadači generiraju javni i privatni ključ za elektronički potpis. Ukoliko sustav koristi certifikate ključeva elektroničkog potpisa, tada oni generiraju certifikat elektroničkog potpisa koji je što sličniji certifikatu pošiljatelja podataka čiju poruku žele krivotvoriti.
U5.2.2. Napadači neovlašteno mijenjaju pohranu javnih ključeva, dajući javnom ključu koji generiraju potrebnu razinu povjerenja i autoriteta.
U5.2.3. Napadači potpisuju lažne podatke prethodno generiranim ključem elektroničkog potpisa i ubacuju ga u sigurni kanal razmjene podataka.
U5.3. Napadači provode napad koristeći istekle ključeve elektroničkog potpisa legalnog potpisnika (SKRIPTA - svi elementi su obavezni):
U5.3.1. Napadači su kompromitirali privatne ključeve elektroničkog potpisa legitimnog pošiljatelja s isteklim (trenutačno nevažećim).
U5.3.2. Napadači zamjenjuju vrijeme u kanalu prijenosa vremena s vremenom u kojem su kompromitirani ključevi još bili valjani.
U5.3.3. Napadači potpisuju lažne podatke prethodno kompromitiranim ključem elektroničkog potpisa i ubacuju ga u sigurni kanal razmjene podataka.
U5.4. Napadači izvode napad koristeći kompromitirane ključeve elektroničkog potpisa legalnog potpisnika (SKRIPTA - svi elementi su obavezni):
U5.4.1. Napadač izrađuje kopiju pohrane javnih ključeva.
U5.4.2. Napadači kompromitiraju privatne ključeve jednog od legitimnih pošiljatelja. On uočava kompromitaciju, opoziva ključeve, a informacija o opozivu ključa stavlja se u pohranu javnih ključeva.
U5.4.3. Napadači zamjenjuju pohranu javnog ključa prethodno kopiranom.
U5.4.4. Napadači potpisuju lažne podatke prethodno kompromitiranim ključem elektroničkog potpisa i ubacuju ga u sigurni kanal razmjene podataka.
U5.5. <…> zbog postojanja grešaka u provedbi 2. i 3. stupnja provjere elektroničkog potpisa:
Objašnjenja U5.5.
Dan je primjer provedbe ove prijetnje .
U5.5.1. Provjera povjerenja u certifikat ključa elektroničkog potpisa samo postojanjem 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 ne analiziraju se ovlaštenja za izdavanje certifikata
Objašnjenja U5.5.2.
Primjer napada na SSL/TLS certifikate.
Napadači su kupili legitiman certifikat za svoju e-poštu. Zatim su napravili lažni certifikat stranice i potpisali ga svojim certifikatom. Ako se vjerodajnice ne provjere, tada će se prilikom provjere lanca povjerenja pokazati točnima, a prema tome i lažna potvrda bit će točna.
U5.5.3. Prilikom izgradnje lanca povjerenja certifikata, međucertifikati 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 elektroničkog potpisa donosi se prije nego što se primi OCSP odgovor o statusu certifikata, koji se šalje na zahtjev koji je poslan kasnije od vremena kada je potpis generiran ili prije sljedećeg CRL-a nakon što je potpis generiran.
Objašnjenja U5.5.5.
U propisima većine CA-a, vremenom opoziva certifikata smatra se vrijeme izdavanja najbližeg CRL-a s podacima o opozivu certifikata.
U5.5.6. Prilikom primanja potpisanih podataka ne provjerava se pripadnost certifikata pošiljatelju.
Objašnjenja U5.5.6.
Primjer napada. U vezi sa SSL certifikatima: podudarnost adrese pozvanog poslužitelja s vrijednošću polja CN u certifikatu možda se neće provjeravati.
Primjer napada. Napadači su kompromitirali ključeve elektroničkog potpisa jednog od sudionika platnog sustava. Nakon toga su hakirali mrežu drugog sudionika i u njegovo ime poslali platne dokumente potpisane kompromitiranim ključevima na server za namiru platnog sustava. Ako poslužitelj samo analizira povjerenje, a ne provjerava usklađenost, tada će se lažni dokumenti smatrati legitimnim.
U 6. Pogrešno prihvaćanje elektroničkih dokumenata na izvršenje zbog problema u organizaciji upravljanja elektroničkim dokumentima.
Raspad
U6.1. Primatelj ne otkriva umnožavanje primljenih dokumenata.
Objašnjenja U6.1.
Primjer napada. Napadači mogu presresti dokument koji se šalje primatelju, čak i ako je kriptografski zaštićen, a zatim ga opetovano slati preko sigurnog kanala za prijenos podataka. Ako primatelj ne identificira duplikate, tada će svi primljeni dokumenti biti percipirani i obrađeni kao različiti dokumenti.
U7. Neovlašteni pristup zaštićenim podacima tijekom njihove obrade od strane CIPF-a
Raspad
U7.1. <…> zbog curenja informacija sporednim kanalima (napad sporednog 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. <…>, provedeno zbog prisutnosti ranjivosti u:
U7.2.2.1. <…> sredstva zaštite od neovlaštenog pristupa.
U7.2.2.2. <…> Sam CIPF.
U7.2.2.3. <…> radno okruženje kripto-alata.
Primjeri napada
Scenariji o kojima se raspravlja u nastavku očito sadrže pogreške u sigurnosti informacija i služe samo za ilustraciju mogućih napada.
Scenarij 1. Primjer implementacije prijetnji U2.2 i U4.2.
Opis objekta
Softver AWS KBR i CIPF SCAD Signature instalirani su na fizičkom računalu koje nije spojeno na računalnu mrežu. FKN vdToken se koristi kao nosač ključa u načinu rada s neizmjenjivim ključem.
Propisi o nagodbi pretpostavljaju da stručnjak za nagodbu sa svog radnog računala preuzima elektroničke poruke u čistom tekstu (shema stare KBR radne stanice) s posebnog sigurnog poslužitelja datoteka, zatim ih zapisuje na prijenosni USB flash pogon i prenosi na KBR radnu stanicu, gdje su šifrirani i znakovi. Nakon toga stručnjak prenosi sigurne elektroničke poruke na otuđeni medij, a zatim ih preko svog radnog računala zapisuje na poslužitelj datoteka, odakle one odlaze u UTA, a zatim u platni sustav Banke Rusije.
U tom će slučaju kanali za razmjenu otvorenih i zaštićenih podataka uključivati: poslužitelj datoteka, radno računalo stručnjaka i otuđene medije.
Napad
Neovlašteni napadači instaliraju sustav daljinskog upravljanja na radno računalo stručnjaka i u trenutku ispisivanja naloga za plaćanje (elektroničke poruke) na prijenosni medij sadržaj jednog od njih zamjenjuju čistim tekstom. Specijalist prenosi naloge za plaćanje u automatizirano radno mjesto KBR-a, potpisuje ih i šifrira bez primjećivanja zamjene (npr. zbog velikog broja naloga za plaćanje na letu, umora i sl.). Nakon toga, lažni nalog za plaćanje, nakon što je prošao kroz tehnološki lanac, ulazi u platni sustav Banke Rusije.
Scenarij 2. Primjer implementacije prijetnji U2.2 i U4.2.
Opis objekta
Računalo s instaliranom radnom stanicom KBR, SCAD Signature i povezanim nosačem ključa FKN vdToken radi u namjenskoj prostoriji bez pristupa osoblja.
Stručnjak za izračun povezuje se s CBD radnom stanicom u načinu daljinskog pristupa putem RDP protokola.
Napad
Napadači presreću detalje pomoću kojih se stručnjak za izračun povezuje i radi s 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 platnom sustavu Banke Rusije.
Scenarij 3. Primjer implementacije prijetnje U1.3.
Opis objekta
Razmotrimo jednu od hipotetskih opcija za implementaciju integracijskih modula ABS-KBR za novu shemu (AWS KBR-N), u kojoj se elektronički potpis odlaznih dokumenata pojavljuje na ABS strani. U ovom slučaju pretpostavit ćemo da ABS radi na temelju operativnog sustava koji nije podržan od strane CIPF SKAD Signature, te se sukladno tome kriptografska funkcionalnost prenosi na zasebno virtualno računalo - integracija “ABS-KBR” modul.
Kao nosač ključa koristi se obični USB token koji radi u modu povratnog ključa. Prilikom spajanja ključnog medija na hipervizor pokazalo se da u sustavu nema slobodnih USB portova, pa je odlučeno da se USB token spoji preko mrežnog USB huba, a na virtualni instalira USB-over-IP klijent. stroj, koji bi komunicirao s hubom.
Napad
Napadači su presreli privatni ključ elektroničkog potpisa iz komunikacijskog kanala između USB huba i hipervizora (podaci su se prenosili u čistom tekstu). Posjedujući privatni ključ, napadači su generirali lažni nalog za plaćanje, potpisali ga elektroničkim potpisom i poslali na izvršenje u automatizirano radno mjesto KBR-N.
Scenarij 4. Primjer implementacije prijetnji U5.5.
Opis objekta
Razmotrimo isti krug kao u prethodnom scenariju. Pretpostavit ćemo da elektroničke poruke koje dolaze s radne stanice KBR-N završavaju u mapi …SHAREIn, a one koje se šalju na radnu stanicu KBR-N i dalje u sustav plaćanja Banke Rusije idu u …SHAREout.
Također ćemo pretpostaviti da se prilikom implementacije integracijskog modula popisi opozvanih certifikata ažuriraju samo kada se ponovno izdaju kriptografski ključevi, te da se elektroničke poruke primljene u mapu …SHAREIn provjeravaju samo za kontrolu integriteta i kontrolu povjerenja u javnom ključu Elektronički potpis.
Napad
Napadači su pomoću ključeva ukradenih u prethodnom scenariju potpisali lažni nalog za plaćanje s podacima o prispjeću novca na račun prevarantskog klijenta te ga uveli u sigurni kanal razmjene podataka. Budući da nema provjere da je nalog za plaćanje potpisala Banka Rusije, isti se prihvaća za izvršenje.
Izvor: www.habr.com