Linkovi na ostale dijelove istraživanja
- (Vi ste ovdje)
Ovaj članak završava niz publikacija posvećenih osiguravanju informacijske sigurnosti bankovnih bezgotovinskih plaćanja. Ovdje ćemo razmotriti tipične modele prijetnji na koje se oslanja :
- .
- .
- .
- .
HABRO-UPOZORENJE !!! Dragi habrovčani, ovo nije zabavna objava.
Skriveni u kategoriji, 40+ stranica materijala osmišljeno je da pomogne u radu ili učenju ljudima koji se specijaliziraju za bankarstvo ili osiguranje informacijske sigurnosti. Ovi materijali predstavljaju konačni proizvod istraživanja i napisani su u suhom službenom tonu. U suštini, to su predlošci za unutarnje dokumente u INFO.I naravno — „upotreba informacija iz članka u nezakonite svrhe kažnjiva je zakonom“. Produktivno čitanje!
Informacije za čitatelje koji se upoznaju s istraživanjem, počinjući od ove objave.
O čemu se radi u istraživanju
Čitate vodič za stručnjaka odgovornog za osiguranje informacijske sigurnosti plaćanja u banci.
Logika izlaganja
Na početku u i predstavljeno je opisivanje objekta zaštite. Zatim u opisuje kako izgraditi sustav zaštite i naglašava potrebu za oblikovanjem modela prijetnji. U opisuje koje vrste prijetnji postoje i kako se formiraju. U i analizira stvarne napade. i sadrže opis modela prijetnji, izgrađenog na temelju informacija iz svih prethodnih dijelova.
TIPIČNI MODEL PRIJETNJI. MREŽNA VEZA
Objekt zaštite za koji se primjenjuje model prijetnji (scope)
Objekt zaštite su podaci koji se šalju putem mrežne veze, koja radi u mrežama prijenosa podataka izgrađenim na bazi TCP/IP stoga.
Arhitektura
Opis elemenata arhitekture:
- «Krajnji čvorovi» — čvorovi koji razmjenjuju zaštićene informacije.
- «Posrednički čvorovi» — elementi mreže prijenosa podataka: usmjerivači, preklopnici, pristupni poslužitelji, proxy poslužitelji i druga oprema, kroz koju prolazi promet mrežne veze. Uopće, mrežna veza može funkcionirati bez posredničkih čvorova (izravno između krajnjih čvorova).
Prijetnje sigurnosti višeg nivoa
Dekonstrukcija
U1. Neovlašteno pregledavanje prenošenih podataka.
U2. Neovlaštena modifikacija prenošenih podataka.
U3. Kršenje autorskih prava prenošenih podataka.
U1. Neovlašteno pregledavanje prenošenih podataka
Dekonstrukcija
U1.1. , izvršeno na krajnjim ili posredničkim čvorovima:
U1.1.1. čitanjem podataka dok su pohranjeni u memorijskim uređajima čvora:
U1.1.1.1. u radnoj memoriji.
Objašnjenja za U1.1.1.1.
Na primjer, tijekom obrade podataka od strane mrežnog staka čvora.
U1.1.1.2. u nevolatilnoj memoriji.
Objašnjenja za U1.1.1.2.
Na primjer, kada se preneseni podaci pohranjuju u predmemoriji, privremenim datotekama ili datotekama s promjenjivim sadržajem.
U1.2. , izvršeno na stranim čvorovima mreže prijenosa podataka:
U1.2.1. metodom hvatanja svih paketa koji prolaze mrežnim sučeljem čvora:
Objašnjenja za U1.2.1.
Hvatanje svih paketa vrši se stavljanjem mrežne kartice u neuredni način rada (promiscuous mode za žičane adaptere ili monitor mode za Wi-Fi adaptere).
U1.2.2. provođenjem napada tipa «čovjek u sredini (MiTM)», ali bez modifikacije prenošenih podataka (osim informacija o uređajima mrežnih protokola).
U1.2.2.1. Link: .
U1.3. , provodi se kroz curenje informacija putem tehničkih kanala (TKUI) s fizičkih čvorova ili komunikacijskih linija.
U1.4. , provodi se postavljanjem na krajnje ili međustepenaste čvorove posebnih tehničkih sredstava (STS) namijenjenih za neprimjetno prikupljanje informacija.
U2. Neovlaštena modifikacija prenesenih podataka
Dekonstrukcija
U2.1. , provodi se na krajnjim ili međustepenim čvorovima:
U2.1.1. čitanjem i izmjenom podataka tijekom njihova boravka u memorijskim uređajima čvorova:
U2.1.1.1. u radnoj memoriji:
U2.1.1.2. u energetski neovisnoj memoriji:
U2.2. , provodi se na stranima čvorovima mreže prijenosa podataka:
U2.2.1. provođenjem napada tipa „čovjek u sredini (MiTM)” i preusmjeravanjem prometa na čvor napadača:
U2.2.1.1. Fizičko povezivanje opreme napadača u prekid mrežne povezanosti.
U2.2.1.2. Provođ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 modifikacija postavki VLAN na prekidačima ili usmjerivačima.
U2.2.1.2.2. usmjeravanje prometa:
U2.2.1.2.2.1. Neovlaštena modifikacija tablica statičkog usmjeravanja usmjerivača.
U2.2.1.2.2.2. Anonimiziranje podložnih rute od strane napadača putem protokola dinamičkog usmjeravanja.
U2.2.1.2.3. automatskog konfiguriranja:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. adresiranja i razrješavanja imena:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Uvođenje neovlaštenih promjena u lokalne datoteke imena čvorova (hosts, lmhosts itd.)
U3. Kršenje autorskih prava prenesenih podataka
Dekonstrukcija
U3.1. Neutralizacija mehanizama za određivanje autorstva informacija putem navođenja podložnih podataka o autoru ili izvoru podataka:
U3.1.1. Promjena podataka o autoru koji su sadržani u prenosivim informacijama.
U3.1.1.1. Neutralizacija kriptografske zaštite integriteta i autorstva prenesenih podataka:
U3.1.1.1.1. Referenca: .
U3.1.1.2. Neutralizacija zaštite autorskih prava prenesenih podataka, implementiranih pomoću jednokratnih kodova potvrde:
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 OPASNOSTI. INFORMACIJSKI SISTEM TEMELJEN NA ARHITEKTURI KLIJENT-SERVER
Objekt zaštite za koji se primjenjuje model prijetnji (scope)
Objekt zaštite je informacijski sistem koji se temelji na arhitekturi klijent-server.
Arhitektura
Opis elemenata arhitekture:
- „Klijent“ – uređaj na kojem funkcionira klijentski deo informacijskog sistema.
- „Server“ – uređaj na kojem funkcionira serverski deo informacijskog sistema.
- „Skladište podataka“ – deo serverske infrastrukture informacijskog sistema namenjen skladištenju podataka koji se obrađuju informacijskim sistemom.
- „Mrežno povezivanje“ – kanal razmene informacija između Klijenta i Servera, koji prolazi kroz mrežu prenosa podataka. Detaljniji opis modela elementa dat je u .
Ograničenja
Pri modeliranju objekta postavljena su sledeća ograničenja:
- Korisnik interaguje s informacionim sistemom unutar konačnih vremenskih intervala, nazvanih radne sesije.
- Na početku svake radne sesije vrši se identifikacija, autentifikacija i autorizacija korisnika.
- Svi zaštićeni podaci čuvaju se na serverskoj strani informacijskog sistema.
Prijetnje sigurnosti višeg nivoa
Dekonstrukcija
U1. Izvođenje neovlaštenih radnji od strane napadača u ime legitimnog korisnika.
U2. Neovlaštena modifikacija zaštićenih informacija tokom njihove obrade serverskom stranom informacijskog sistema.
U1. Izvođenje neovlaštenih radnji od strane napadača u ime legitimnog korisnika
Objašnjenja
Obično se u informacionim sistemima korelacija radnji sa izvršiteljom obavlja putem:
- dnevnika rada sistema (logs).
- specijalnih atributa objekata podataka koji sadrže informacije o korisniku koji ih je stvorio ili promenio.
U odnosu na radnu sesiju, ova pretnja se može dekomponovati na:
- izvedeni u okviru radne sesije korisnika.
- izvedeni van radne sesije korisnika.
Radna sesija korisnika može biti inicirana:
- Sâmim korisnikom.
- Zlonamjernici.
U ovoj fazi, međurezultantna dekompozicija ove prijetnje izgledat će ovako:
U1.1. Neovlaštene radnje izvršene su unutar sesije rada korisnika:
U1.1.1. , postavljenog od strane napadnutog korisnika.
U1.1.2. , postavljenog od strane zlonamjernika.
U1.2. Neovlaštene radnje izvršene su izvan sesije rada korisnika.
S stajališta objekata informacijske infrastrukture na koje mogu utjecati zlonamjernici, dekompozicija međurezultantnih prijetnji izgledat će ovako:
Elementi
Dekompozicija prijetnji
U1.1.1.
U1.1.2.
U1.2.
Klijent
U1.1.1.1.
U1.1.2.1.
Mrežna veza
U1.1.1.2.
Server
U1.2.1.
Dekonstrukcija
U1.1. Neovlaštene radnje izvršene su unutar sesije rada korisnika:
U1.1.1. , postavljenog od strane napadnutog korisnika:
U1.1.1.1. Zlonamjernici su samostalno djelovali s Klijenta:
U1.1.1.1.1 Zlonamjernici su koristili uobičajena sredstva pristupa informacijskom sustavu:
U1.1.1.1.1.1. Zlonamjernici su koristili fizička sredstva ulaza i izlaza Klijenta (tipkovnica, miš, monitor ili dodirni ekran mobilnog uređaja):
U1.1.1.1.1.1.1. Zlonamjernici su djelovali u vremenskim razdobljima kada je sesija aktivna, sredstva ulaza i izlaza su dostupna, a korisnik nije prisutan.
U1.1.1.1.1.2. Zlonamjernici su koristili sredstva daljinskog administriranja (uobičajena ili pružena zlonamjernim kodom) za upravljanje Klijentom:
U1.1.1.1.1.2.1. Zlonamjernici su djelovali u vremenskim razdobljima kada je sesija aktivna, sredstva ulaza i izlaza su dostupna, a korisnik nije prisutan.
U1.1.1.1.1.2.2. Zlonamjernici su koristili sredstva daljinskog administriranja čije djelovanje nije uočljivo napadnutom korisniku.
U1.1.1.2. Zlonamjernici su zamjenjivali podatke u mrežnoj vezi između Klijenta i Poslužitelja, modificirajući ih na taj način da se percipiraju kao radnje legitimnog korisnika:
U1.1.1.2.1. Veza: .
U1.1.1.3. Zlonamjernici su prisilili korisnika na izvršenje radnji koje su im odredili, koristeći metode socijalnog inženjeringa.
U1.1.2 postavljenog od strane zlonamjernika:
U1.1.2.1. Zlonamjernici su djelovali s Klijenta (I):
U1.1.2.1.1. Zlonamjernici su neutralizirali sustav razgraničenja pristupa informacijskom sustavu:
U1.1.2.1.1.1. Veza: .
U1.1.2.1.2. Napadači su koristili standardna sredstva pristupa informacijskom sustavu
U1.1.2.2. Napadači su djelovali s drugih čvorova mreže prijenosa podataka s kojih je moguće uspostaviti mrežnu vezu s Serverom (I):
U1.1.2.2.1. Napadači su neutralizirali sustav kontrole pristupa informacijskom sustavu:
U1.1.2.2.1.1. Link: .
U1.1.2.2.2. Napadači su koristili neodobrena sredstva pristupa informacijskom sustavu.
Objašnjenja U1.1.2.2.2.
Napadači su mogli instalirati standardni klijent informacijskog sustava na strani čvor ili su mogli koristiti neodobreni softver koji provodi standardne protokole razmjene između Klijenta i Servera.
U1.2 Neautorizirane radnje izvršene su izvan radne sesije korisnika.
U1.2.1 Napadači su izvršili neautorizirane radnje, a zatim su unijeli neautorizirane izmjene u dnevnike rada informacijskog sustava ili posebne atribute objekata podataka, navodeći da su radnje koje su izvršili izvršene od strane legitimnog korisnika.
U2. Neautorizirana modifikacija zaštićenih informacija tijekom njihove obrade poslužiteljskom stranom informacijskog sustava
Dekonstrukcija
U2.1. Napadači modificiraju zaštićene informacije koristeći standardna sredstva informacijskog sustava i provode to u ime legitimnog korisnika.
U2.1.1. Link: .
U2.2. Napadači modificiraju zaštićene informacije koristeći mehanizme pristupa podacima koji nisu predviđeni standardnim radnim režimom informacijskog sustava.
U2.2.1. Napadači modificiraju datoteke koje sadrže zaštićene informacije:
U2.2.1.1. , koristeći mehanizme rada s datotekama koje pruža operacijski sustav.
U2.2.1.2. provociranjem oporavka datoteka iz neautorizirano modificirane sigurnosne kopije.
U2.2.2. Napadači modificiraju zaštićene informacije pohranjene u bazi podataka (I):
U2.2.2.1. Napadači neutraliziraju sustav kontrole pristupa DBMS-a:
U2.2.2.1.1. Veza: .
U2.2.2.2. Napadači modificiraju informacije koristeći standardne sučelje DBMS-a 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 podliježe modifikacijama.
U2.3.1. Strojni kod softvera podliježe modifikacijama.
U2.4. Napadači modificiraju zaštićene informacije koristeći ranjivosti u softveru informacijske sustave.
U2.5. Napadači modificiraju zaštićene informacije prilikom njihove prijenosa između komponenti poslužiteljske strane informacijskog sustava (npr. između poslužitelja baza podataka i poslužitelja aplikacija):
U2.5.1. Veza: .
TIPIČAN MODEL PRIJETNJI. SUSTAV KONTROLE PRISTUPA
Objekt zaštite za koji se primjenjuje model prijetnji (scope)
Objekt zaštite za koji se primjenjuje ovaj model prijetnji odgovara objektu zaštite modela prijetnji: 'Tipičan model prijetnji. Informacijski sustav temeljen na klijent-poslužitelj arhitekturi'.
Pod sustavom kontrole pristupa korisnicima u ovom modelu prijetnji podrazumijeva se komponenta informacijskog sustava koja izvršava funkcije:
- Identifikacije korisnika.
- Autentifikacije korisnika.
- Autorizacije korisnika.
- Protokoliranja radnji korisnika.
Prijetnje sigurnosti višeg nivoa
Dekonstrukcija
U1. Neovlašteno uspostavljanje sesije rada u ime legitimnog korisnika.
U2. Neovlašteno povećanje privilegija korisnika u informacijskom sustavu.
U1. Neovlašteno uspostavljanje sesije rada u ime legitimnog korisnika
Objašnjenja
Dekompocicija ove prijetnje općenito će ovisiti o primijenjenom tipu sustava identifikacije i autentifikacije korisnika.
U ovom modelu će se razmatrati samo sustav identifikacije i autentifikacije korisnika, koji koristi tekstualni login i lozinku. Pri tome ćemo pretpostaviti da je korisnički login javno dostupna informacija poznata napadačima.
Dekonstrukcija
U1.1. kroz kompromitaciju korisničkih podataka:
U1.1.1. Napadači su kompromitirali korisničke podatke tijekom njihovog pohranjivanja.
Objašnjenja U1.1.1.
Na primjer, korisnički podaci mogli su biti napisani na naljepnici prilijepljenoj na monitoru.
U1.1.2. Korisnik je slučajno ili zlonamjerno prenio pristupne podatke zlonamjernim osobama.
U1.1.2.1. Korisnik je izgovarao podatke o računu naglas tijekom unosa.
U1.1.2.2. Korisnik je namjerno prenio svoje podatke o računu:
U1.1.2.2.1. kolegama na poslu.
Objašnjenja U1.1.2.2.1.
Na primjer, kako bi mogli zamijeniti korisnika tijekom bolovanja.
U1.1.2.2.2. poslovnim partnerima poslodavca, koji rade na projektima informacijske infrastrukture.
U1.1.2.2.3. trećim stranama.
Objašnjenja U1.1.2.2.3.
Jedna, ali ne i jedina implementacija ove prijetnje je korištenje zlonamjernih tehnika društvenog inženjeringa.
U1.1.3. Zlonamjernici su pogodili podatke o računu metodom pokušaja i pogreške:
U1.1.3.1. korištenjem standardnih mehanizama pristupa.
U1.1.3.2. prema prethodno presretnutim kodovima (na primjer, hash-evima lozinki) pohrane podataka o računu.
U1.1.4. Zlonamjernici su koristili zlonamjerni kod za presretanje podatka o korisničkom računu.
U1.1.5. Zlonamjernici su izvukli podatke o računu iz mrežne veze između Klijenta i Poslužitelja:
U1.1.5.1. Link: .
U1.1.6. Zlonamjernici su izvukli podatke o računu iz zapisa sustava za praćenje rada:
U1.1.6.1. sustava video nadzora (ako su tijekom rada bilježenja pritisci tipki na tipkovnici).
U1.1.6.2. sustava za praćenje aktivnosti zaposlenika na računalima.
Objašnjenja U1.1.6.2.
Primjer takvog sustava — .
U1.1.7. Zlonamjernici su kompromitirali korisničke podatke zbog nedostataka u procesu njihovog prijenosa.
Objašnjenja U1.1.7.
Na primjer, prijenos lozinki u otvorenom obliku putem e-pošte.
U1.1.8. Zlonamjernici su saznali podatke o računu putem promatranja sesije korisnika uz pomoć sustava daljinskog administriranja.
U1.1.9. Zlonamjernici su izvukli podatke o računu kao rezultat njihovog curenja putem tehničkih kanala (TKUI):
U1.1.9.1. Zlonamjernici su promatrali kako korisnik unosi podatke o računu s tipkovnice:
U1.1.9.1.1 Zlonamjernici su se nalazili u neposrednoj blizini korisnika i vidjeli su unos podataka o računu vlastitim očima.
Objašnjenja U1.1.9.1.1
Slične situacije obuhvaćaju radnje kolega ili slučaj kada posjetitelji organizacije mogu vidjeti tipkovnicu korisnika.
U1.1.9.1.2 Napadači su koristili dodatna tehnička sredstva, poput dalekozora ili dronova, i vidjeli unos korisničkih podataka kroz prozor.
U1.1.9.2. Napadači su izvukli korisničke podatke iz zapisa radio komunikacije između tipkovnice i računalne jedinice u slučaju da su bili povezani putem radio sučelja (npr. Bluetooth).
U1.1.9.3. Napadači su izvršili presretanje korisničkih podataka zbog njihove curenja kroz kanal sporednih elektromagnetskih zračenja i smetnji (PEM).
Objašnjenja U1.1.9.3.
Primjeri napada i .
U1.1.9.4. Napadač je izvršio presretanje unosa korisničkih podataka s tipkovnice korištenjem posebnih tehničkih sredstava (PTS) namijenjenih neprimjetnom prikupljanju informacija.
Objašnjenja U1.1.9.4.
Primjeri .
U1.1.9.5. Napadači su izvršili presretanje unosa korisničkih podataka s tipkovnice analizom Wi-Fi signala, modulatornog procesa pritiskanja tipki od strane korisnika.
Objašnjenja U1.1.9.5.
napadi
Primjer .
Objašnjenja U1.1.9.6.
U1.1.9.7. Napadači su izvršili presretanje unosa korisničkih podataka s tipkovnice mobilnog uređaja analizom podataka akcelerometra.
Primjer .
Objašnjenja U1.1.9.7.
U1.1.10. , prethodno spremljenih na Klijentu.
Primjer .
Objašnjenja U1.1.10.
Na primjer, korisnik je mogao spremiti korisničko ime i lozinku u pregledniku za pristup određenoj web stranici.
U1.1.11. Napadači su kompromitirali korisničke podatke zbog nedostataka u procesu opoziva korisničkih prava.
Objašnjenja U1.1.11.
Na primjer, nakon raskida radnog odnosa, korisnički računi nisu bili blokirani.
U1.2. zbog korištenja ranjivosti u sustavu kontrole pristupa.
U2. Neovlašteno povećanje privilegija korisnika u informacijskom sustavu
U2.1 stvaranjem neovlaštenih izmjena u podacima koji sadrže informacije o privilegijama korisnika.
Dekonstrukcija
U2.2 zbog korištenja ranjivosti u sustavu kontrole pristupa.
U2.3. zbog nedostataka u procesu upravljanja pristupom korisnicima.
U2.3. zbog nedostataka u procesu upravljanja pristupom korisnicima.
Objašnjenja U2.3.
Primjer 1. Korisniku je za rad pružen pristup veći od onog koji mu je bio potreban zbog službene potrebe.
Primjer 2. Nakon prebacivanja korisnika na drugu poziciju, prethodno dodijeljena prava pristupa nisu opozvana.
TIPIČNI MODEL PRIJETNJI. MODUL INTIGRACIJE
Objekt zaštite za koji se primjenjuje model prijetnji (scope)
Modul integracije je skup objekata informacijske infrastrukture, namijenjen organizaciji razmjene informacija između informacijskih sustava.
S obzirom na to da u korporativnim mrežama nije uvijek moguće jasno razdvojiti jedan informacijski sustav od drugog, modul integracije se može smatrati i veznim elementom između komponenti unutar jednog informacijskog sustava.
Arhitektura
Generalizirana shema modula integracije izgleda ovako:
Opis elemenata arhitekture:
- «Poslužitelj za razmjenu (PR)» – čvor / servis / komponenta informacijskog sustava koja obavlja funkciju razmjene podataka s drugim informacijskim sustavom.
- «Posrednik» – čvor / servis, namijenjen organizaciji interakcije između informacijskih sustava, ali nije dio njih.
Primjeri «Posrednika» mogu biti servisi elektroničke pošte, servisne sabirnice poduzeća (enterprise service bus / SoA-arhitektura), vanjski poslužitelji datoteka itd. U općem slučaju modul integracije može i ne sadržavati «Posrednike». - «SO obrade podataka» – skup programa koji implementira protokole za razmjenu podataka i prebacivanje formata.
Na primjer, pretvaranje podataka iz formata UFEBS u format ABS, promjena statusa poruka tijekom prijenosa itd. - „Mrežno povezivanje“ odgovara objektu opisanom u tipičnom modelu prijetnji «Mrežna veza». Neki od mrežnih veza prikazanih na gornjoj shemi možda neće postojati.
Primjeri modula integracije
Shema 1. Integracija ABS-a i ARM KBR-a putem vanjskog poslužitelja za datoteke
Za izvršenje plaćanja ovlašteni radnik banke izvozi iz ABS-a elektroničke dokumente plaćanja i sprema ih u datoteku (vlastitog formata, na primjer SQL-dump) na mrežnoj mapi (…SHARE) poslužitelja datoteka. Zatim se ta datoteka pomoću skripte-konvertera pretvara u set datoteka formata UFEBS, koje zatim očitava ARM KBR.
Nakon toga, ovlašteni zaposlenik — korisnik ARM KBR — šifrira i potpisuje primljenu datoteku te je šalje u platni sustav Banke Rusije.
Kada uplati dođu iz Banke Rusije, ARM KBR provodi njihovo dešifriranje i provjeru elektroničkog potpisa, nakon čega ih zapisuje kao skup datoteka formata UFEBS na datotečni poslužitelj. Prije uvoza platnih dokumenata u ABS, oni se pretvaraju pomoću skripta-konvertera iz formata UFEBS u format ABS.
Pretpostavimo da u ovoj shemi ABS funkcionira na jednom fizičkom poslužitelju, ARM KBR funkcioniše na namjenskom računalu, a skript-konverter radi na datotečnom poslužitelju.
Odnos objekata u razmatranoj shemi s elementima modela integracije:
«Poslužitelji razmjene s strane ABS-a» – poslužitelj ABS-a.
«Poslužitelji razmjene s strane ARM KBR» – računalo ARM KBR.
«Posrednik» – vanjski datotečni poslužitelj.
«SO obrade podataka» – skript-konverter.
Shema 2. Integracija ABS-a i ARM KBR-a kod postavljanja zajedničke mrežne mape s platbama na ARM KBR.
Sve je slično Shemi 1, ali se ne koristi odvojeni datotečni poslužitelj, umjesto toga mrežna mapa (…SHARE) s elektroničkim platnim dokumentima postavlja se na računalu s ARM KBR. Skript-konverter također radi na ARM KBR.
Odnos objekata u razmatranoj shemi s elementima modela integracije:
Slično Shemi 1, ali «Posrednik» ne koristi se.
Shema 3. Integracija ABS-a i ARM KBR-N preko IBM WebSphera MQ i potpisivanje elektroničkih dokumenata „na strani ABS-a”.
ABS radi na platformi koja ne podržava SKZI SKAD Signatura. Potpisivanje odlaznih elektroničkih dokumenata vrši se na posebnom poslužitelju elektroničkog potpisa (Poslužitelj EP). Ovaj isti poslužitelj provjerava elektronički potpis pristiglih dokumenata iz Banke Rusije.
ABS šalje na Poslužitelj EP datoteku s platnim dokumentima u vlastitom formatu.
Poslužitelj EP pomoću skripta-konvertera pretvara datoteku u elektroničke poruke formata UFEBS, nakon čega se elektroničke poruke potpisuju i šalju na IBM WebSphere MQ.
ARM KBR-N se obraća IBM WebSphere MQ i prima odatle potpisane platne poruke, nakon čega ovlašteni zaposlenik — korisnik ARM KBR — ih šifrira i šalje u platni sustav Banke Rusije.
Prilikom zaprecećenja plaćanja iz Banke Rusije, ARМ KBR-N ih razlaže i provjerava elektronički potpis. Uspješno obrađena plaćanja u obliku razloženih i potpisanih elektroničkih poruka formata UFEBS šalju se u IBM WebSphere MQ, odakle ih prima Server EP.
Server EP provjerava elektronički potpis pristiglih plaćanja i pohranjuje ih u datoteku formata ABS. Nakon toga, ovlašteni radnik — korisnik ABS-a — učitava rezultat u ABS prema utvrđenim postupcima.
Odnos objekata u razmatranoj shemi s elementima modela integracije:
«Server razmjene s strane ABS-a» – poslužitelj ABS-a.
«Server razmjene s strane ARМ KBR» — računar ARМ KBR.
«Posrednik» — Server EP i IBM WebSphere MQ.
«SO obrade podataka» — skripta-konverter, SKZI SKAD Potpis na Serveru EP.
Shema 4. Integracija Servera DBO i ABS-a putem API-ja koji pruža namjenski server razmjene
Pretpostavimo da banka koristi nekoliko sustava daljinskog bankarstva (DBO):
- «Internet Klijent-Banka» za fizičke osobe (IKB FL);
- «Internet Klijent-Banka» za pravne osobe (IKB JL).
U cilju osiguranja informacijske sigurnosti, sve interakcije ABS-a s DBO sustavima odvijaju se putem namjenskog servera razmjene, koji radi u okviru informatičkog sustava «ABS».
Dalje ćemo razmotriti proces interakcije sustava DBO IKB JL s ABS-om.
Server DBO, primivši od klijenta propisno ovjeren nalog za uplatu, treba na osnovu njega stvoriti odgovarajući dokument u ABS-u. Za to koristi API za prijenos informacija na server razmjene, a on, zauzvrat, unosi podatke u ABS.
Pri promjeni stanja na računu klijenta, ABS generira elektronička obavještenja koja se putem servera razmjene šalju na server DBO.
Odnos objekata u razmatranoj shemi s elementima modela integracije:
«Server razmjene s strane DBO» — server DBO IKB JL.
«Server razmjene s strane ABS-a» — server razmjene.
«Posrednik» — nema podataka.
«SO obrade podataka» — komponente Servera DBO, odgovorne za korištenje API-ja servera razmjene, komponente servera razmjene, odgovorne za korištenje API-ja ABS-a.
Prijetnje sigurnosti višeg nivoa
Dekonstrukcija
U1. Uvođenje lažnih informacija od strane napadača putem integracijskog modula.
U1. Uvođenje lažnih informacija od strane napadača putem integracijskog modula
Dekonstrukcija
U1.1. Neovlaštena modifikacija legitimnih podataka tijekom prijenosa putem mrežnih veza:
U1.1.1 Link: .
U1.2. Prijenos lažnih podataka putem komunikacijskih kanala u ime legitimnog sudionika razmjene:
U1.1.2 Link: .
U1.3. Neovlaštena modifikacija legitimnih podataka tijekom obrade na serverima razmjene ili posredniku:
U1.3.1. Link: .
U1.4. Kreiranje lažnih podataka na serverima razmjene ili posredniku u ime legitimnog sudionika razmjene:
U1.4.1. Link:
U1.5. Neovlaštena modifikacija podataka tijekom obrade pomoću softvera za obradu podataka:
U1.5.1. putem neovlaštenih promjena u postavkama (konfiguraciji) softvera za obradu podataka od strane napadača.
U1.5.2. putem neovlaštenih promjena u izvršnim datotekama softvera za obradu podataka od strane napadača.
U1.5.3. putem interaktivnog upravljanja radom softvera za obradu podataka od strane napadača.
STANDARDNI MODEL PRIJETNJI. SUSTAV KRIPTOGRAFSKE ZAŠTITE INFORMACIJA
Objekt zaštite za koji se primjenjuje model prijetnji (scope)
Objekt zaštite je sustav kriptografske zaštite informacija, koji se koristi za osiguranje sigurnosti informacijskog sustava.
Arhitektura
Osnova svakog informacijskog sustava je aplikativni softver (AS), koji ostvaruje njegov cilj funkcionalnosti.
Kriptografska zaštita se obično ostvaruje pozivanjem kriptografskih primitava iz poslovne logike aplikativnog softvera, koji se nalaze u specijaliziranim bibliotekama - kriptojezgrama.
Kriptografskim primitvima pripadaju nisko-razinski kriptografski funkcije, kao što su:
- kriptirati / dekriptirati blok podataka;
- stvoriti / provjeriti elektronički potpis bloka podataka;
- izračunati hash-funkciju bloka podataka;
- formirati / učitati / izvesti ključne informacije;
- itd.
Poslovna logika aplikativnog softvera ostvaruje viši funkcionalnost putem kriptografskih primitava:
- kriptirati datoteku na ključevima odabranih primatelja;
- postaviti sigurno mrežno povezivanje;
- obavijestiti o rezultatima provjere elektroničkog potpisa;
- itd.
Interakcija poslovne logike i kriptojezgre može se odvijati:
- direktno, pozivajući kriptografske primitivne funkcije poslovnom logikom iz dinamičkih biblioteka kriptojezgre (.DLL – za Windows, .SO – za Linux);
- posredno, putem kriptografskih sučelja - omotača (wrappers), kao što su MS Crypto API, Java Cryptography Architecture, PKCS#11 itd. U tom slučaju, poslovna logika obraća se kripto sučelju, koje prevodi poziv prema odgovarajućoj kriptojezgri, koja se u tom slučaju naziva kriptoprovider. Korištenje kriptografskih sučelja omogućava aplikacijskom softveru da se apstrahira od specifičnih kriptografskih algoritama i da bude fleksibilniji.
Možemo razlikovati dva tipična modela organizacije kriptojezgre:
Model 1 – Monolitna kriptojezgra
Model 2 – Podijeljena kriptojezgra
Elementi u prikazanim modelima mogu biti ili odvojeni softverski moduli, koji rade na jednom računalu, ili mrežne usluge koje komuniciraju unutar računalne mreže.
Kada se koriste sustavi iz modela 1, aplikacijski softver i kriptojezgra rade unutar istog okruženja funkcioniranja kripto sredstva (SFK), na primjer, na istom računalu, pod upravljanjem istog operativnog sustava. Korisnik sustava, u pravilu, može pokretati i druge programe unutar istog okruženja, uključujući one s zlonamjernim kodom. U takvim uvjetima postoji značajan rizik od curenja tajnih kriptografskih ključeva.
Za minimizaciju rizika primjenjuje se model 2, pri čemu se kriptojezgra dijeli na dva dijela:
- Prvi dio zajedno s aplikacijskim softverom radi u nepovjerenom okruženju, gdje postoji rizik od zaraze zlonamjernim kodom. Ovaj dio ćemo nazvati – 'softverskim dijelom'.
- Drugi dio radi u pouzdanom okruženju na odvojenom uređaju, koji sadrži skladište tajnih ključeva. Ovaj dio ćemo nazvati – 'hardverskim dijelom'.
Podjela kriptojezgre na softverski i hardverski dio je prilično arbitrarna. Na tržištu postoje sustavi s podijeljenom kriptojezgricom, ali je „hardverski“ dio predstavljen u obliku slike virtualne mašine — virtual HSM ().
Interakcija između oba dijela kriptojezgre odvija se na način da se tajni kriptografski ključevi nikada ne prenose u softverski dio i, shodno tome, ne mogu biti ukradeni zlonamjernim kodom.
Sučelje za interakciju (API) i set kriptografskih primitativa koje kriptojezgra pruža aplikativnom softveru su u oba slučaja identični. Razlika leži u načinu njihove implementacije.
Tako, prilikom korištenja sheme s podijeljenom kriptojezgricom, interakcija softverskog i hardverskog dijela odvija se prema sljedećem principu:
- Kriptografski primitivni, koji ne zahtijevaju korištenje tajnog ključa (npr. izračun hash funkcije, provjera elektronskog potpisa i dr.), izvode se softverskim dijelom.
- Kriptografski primitivni, koji koriste tajni ključ (izrada elektronskog potpisa, dekriptiranje podataka i dr.), izvode se hardverskim dijelom.
Ilustrirajmo rad podijeljene kriptojezgre na primjeru stvaranja elektronskog potpisa:
- Softverski dio izračunava hash funkciju podataka koji se potpisuju i putem kanala razmjene između kriptojezgra prenosi tu vrijednost u hardverski dio.
- Hardverski dio, koristeći tajni ključ i hash, formira vrijednost elektronskog potpisa i putem kanala razmjene prenosi je nazad u softverski dio.
- Softverski dio vraća dobivenu vrijednost u aplikativni softver.
Karakteristike provjere ispravnosti elektronskog potpisa
Kada primateljska strana dobije podatke koji su potpisani elektronskim potpisom, mora proći kroz nekoliko koraka provjere. Pozitivan rezultat provjere elektronskog potpisa postiže se samo uspješnim završetkom svih koraka provjere.
Korak 1. Kontrola cjelovitosti podataka i autorstva podataka.
Sadržaj koraka. Provodi se provjera elektroničkog potpisa podataka prema odgovarajućem kriptografskom algoritmu. Uspješno prolazak ove faze ukazuje na to da podaci nisu modificirani od trenutka kada su potpisani, te da je potpis napravljen privatnim ključem, koji odgovara javnom ključu za provjeru elektroničkog potpisa.
Mjesto izvođenja faze: kriptokernel.
Faza 2. Kontrola povjerenja u javni ključ potpisnika i kontrola trajanja privatnog ključa elektroničkog potpisa.
Sadržaj koraka. Faza se sastoji od dva međufazna koraka. U prvom se utvrđuje je li javni ključ za provjeru elektroničkog potpisa bio povjeren u trenutku potpisivanja podataka. U drugom se utvrđuje je li privatni ključ elektroničkog potpisa bio valjan u trenutku potpisivanja podataka. U općem slučaju, trajanja ovih ključeva mogu se ne poklapati (na primjer, za kvalificirane certifikate ključeva za provjeru elektroničkog potpisa). Načini utvrđivanja povjerenja u javni ključ potpisnika definirani su pravilima elektroničkog poslovanja koja su usvojili uključeni subjekti.
Mjesto izvođenja faze: aplikacijski softver / kriptokernel.
Faza 3. Kontrola ovlasti potpisnika.
Sadržaj koraka. U skladu s utvrđenim pravilima elektroničkog poslovanja provjerava se je li potpisnik imao pravo ovjeriti zaštićene podatke. Na primjer, uzmimo situaciju kršenja ovlasti. Pretpostavimo da postoji organizacija u kojoj svi zaposlenici imaju elektronički potpis. U unutarnji sustav elektroničkog poslovanja dolazi nalog vođe, ali potpisan elektroničkim potpisom skladištara. Samim tim, takav dokument ne može se smatrati legitimnim.
Mjesto izvođenja faze: aplikacijski softver.
Pretpostavke usvojene prilikom opisivanja objekta zaštite
- Kanali za prijenos informacija, osim kanala za razmjenu ključeva, uključujući prolazak kroz aplikacijski softver, API i kriptokernel.
- Informacije o povjerenju u javne ključeve i (ili) certifikate, kao i informacije o ovlastima vlasnika javnih ključeva, pohranjuju se u skladištu javnih ključeva.
- Aplikacijski softver radi sa skladištem javnih ključeva preko kriptokernela.
Primjer informatičkog sustava zaštićenog pomoću SKZI
Kako bismo ilustrirali prethodno predstavljene sheme, razmotrit ćemo hipotetski informacijski sustav i identificirati sve njegove strukturne elemente.
Opis informacijskog sustava
Dve organizacije su odlučile implementirati pravno značajnu elektroničku razmjenu dokumenata (ERD) između sebe. U tu svrhu su sklopile ugovor u kojem su definirale da će se dokumenti slati putem elektroničke pošte, te da moraju biti šifrirani i potpisani kvalificiranim elektroničkim potpisom. Kao sredstva za izradu i obradu dokumenata trebaju se koristiti kancelarijski programi iz paketa Microsoft Office 2016, dok će se kao sredstva za kriptografsku zaštitu koristiti SKZI CryptoPRO i softver za šifriranje CryptoARM.
Opis infrastrukture organizacije 1
Organizacija 1 je odlučila instalirati SKZI CryptoPRO i softver CryptoARM na radnu stanicu korisnika — fizičko računalo. Ključevi za šifriranje i elektronički potpis bit će pohranjeni na ključnom uređaju ruToken, koji radi u načinu zamjenjivog ključa. Korisnik će lokalno pripremati elektroničke dokumente na svom računalu, nakon čega će ih šifrirati, potpisivati i slati putem lokalno instaliranog klijenta e-pošte.
Opis infrastrukture organizacije 2
Organizacija 2 je odlučila premjestiti funkcije šifriranja i elektroničkog potpisa na dodijeljenu virtualnu mašinu. Sve kriptografske operacije će se provoditi automatski.
Za to su na dodijeljenoj virtualnoj mašini organizirane dve mrežne mape: "…In", "…Out". U mrežnu mapu "…In" će se automatski smještati datoteke primljene od poslovnog partnera u otvorenom obliku. Ove datoteke će biti dešifrirane, a njihov elektronički potpis će biti provjeren.
U mapu "…Out" korisnik će smještati datoteke koje je potrebno šifrirati, potpisati i poslati poslovnom partneru. Sam korisnik će pripremati datoteke na svojoj radnoj stanici.
Za izvršenje funkcija šifriranja i elektroničkog potpisa na virtualnoj mašini instalirani su SKZI CryptoPRO, softver CryptoARM i klijent e-pošte. Automatsko upravljanje svim elementima virtualne mašine će se provoditi uz pomoć skripti koje su razvili sistemi administratori. Rad skripti će se bilježiti u datoteke dnevnika (logs).
Kryptografski ključevi elektroničkog potpisa bit će pohranjeni na tokenu s neizvlačivim ključem JaCarta GOST, koji će korisnik povezati sa svojim lokalnim računalom.
Token će se proslijediti na virtualnu mašinu pomoću specijaliziranih softverskih alata USB-over-IP, instaliranih na korisničkom ARM-u i na virtualnoj mašini.
Sustavni satovi na korisničkom ARM-u u organizaciji 1 će se ispraviti ručno. Sustavni satovi specijalizirane virtualne mašine u organizaciji 2 će se sinkronizirati s sustavnim satovima hipervizora, koji će se, zauzvrat, sinkronizirati putem Interneta s javnim vremenom poslužitelja.
Isticanje strukturnih elemenata SKZI
Na temelju prethodnog opisa IT infrastrukture izdvojit ćemo strukturne elemente SKZI i zapisati ih u tablicu.
Tablica - Suvremeno modeliranje elemenata SKZI u informacijskim sustavima
Naziv elementa
Organizacija 1
Organizacija 2
Aplikativni softver
Softver KryptoARM
Softver KryptoARM
Programski dio kriptojezgre
SKZI KryptoPRO CSP
SKZI KryptoPRO CSP
Hardverski dio kriptojezgre
nema
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Skladište javnih ključeva
Korisnički ARM:
— tvrdi disk;
— standardno skladište certifikata Windows.
Hipervizor:
— tvrdi disk.
Virtualna mašina:
— tvrdi disk;
— standardno skladište certifikata Windows.
Skladište privatnih ključeva
Ključni uređaj ruToken, koji radi u načinu izvučenog ključa
Ključni uređaj JaCarta GOST, koji radi u načinu neizvlačivog ključa
Kanali razmjene javnih ključeva
Korisnički ARM:
— radna memorija.
Hipervizor:
— radna memorija.
Virtualna mašina:
— radna memorija.
Kanali razmjene privatnih ključeva
Korisnički ARM:
— USB sabirnica;
— radna memorija.
nema
Kanali razmjene između kriptojezgri
nema (nema hardverskog dijela kriptojezgre)
Korisnički ARM:
— USB sabirnica;
— radna memorija;
— programski modul USB-over-IP;
— mrežni sučelje.
Korporativna mreža organizacije 2.
Hipervizor:
— radna memorija;
— mrežni sučelje.
Virtualna mašina:
— mrežni sučelje;
— radna memorija;
— programski modul USB-over-IP.
Kanali razmjene otvorenih podataka
Korisnički ARM:
— uređaji za unos-izlaz;
— radna memorija;
— tvrdi disk.
Korisnički ARM:
— uređaji za unos-izlaz;
— radna memorija;
— tvrdi disk;
— mrežni sučelje.
Korporativna mreža organizacije 2.
Hipervizor:
— mrežni sučelje;
— radna memorija;
— tvrdi disk.
Virtualna mašina:
— mrežni sučelje;
— radna memorija;
— tvrdi disk.
Kanali razmjene zaštićenih podataka
Internet.
Korporativna mreža organizacije 1.
Korisnički ARM:
— tvrdi disk;
— radna memorija;
— mrežni sučelje.
Internet.
Korporativna mreža organizacije 2.
Hipervizor:
— mrežni sučelje;
— radna memorija;
— tvrdi disk.
Virtualna mašina:
— mrežni sučelje;
— radna memorija;
— tvrdi disk.
Kanal prijenosa vremena
Korisnički ARM:
— uređaji za unos-izlaz;
— radna memorija;
— sistemski tajmer.
Internet.
Korporativna mreža organizacije 2,
Hipervizor:
— mrežni sučelje;
— radna memorija;
— sistemski tajmer.
Virtualna mašina:
— radna memorija;
— sistemski tajmer.
Kanal prijenosa upravljačkih naredbi
Korisnički ARM:
— uređaji za unos-izlaz;
— radna memorija.
(Grafičko korisničko sučelje softvera KryptoARM)
Virtualna mašina:
— radna memorija;
— tvrdi disk.
(Skripte za automatizaciju)
Kanal prijema rezultata rada
Korisnički ARM:
— uređaji za unos-izlaz;
— radna memorija.
(Grafičko korisničko sučelje softvera KryptoARM)
Virtualna mašina:
— radna memorija;
— tvrdi disk.
(Datoteke s dnevnikom rada skripti za automatizaciju)
Prijetnje sigurnosti višeg nivoa
Objašnjenja
Pretpostavke usvojene prilikom dekompozicije prijetnji:
- Koriste se otporni kriptografski algoritmi.
- Kriptografski algoritmi se koriste na siguran način u pravim radnim režimima (na primjer, ne koristi se za enkripciju velikih količina podataka, uzimajući u obzir dopušteno opterećenje ključa itd.).
- Napadači su upoznati sa svim korištenim algoritmima, protokolima i javnim ključevima.
- Napadačima su dostupni svi šifrirani podaci za čitanje.
- Napadači su sposobni reproducirati sve softverske elemente u sustavu.
Dekonstrukcija
U1. Kompromitacija tajnih kriptografskih ključeva.
U2. Šifriranje lažnih podataka u ime legitimnog pošiljatelja.
U3. Dešifriranje šifriranih podataka od strane osoba koje nisu legitimni primatelji podataka (napadača).
U4. Kreiranje elektroničkog potpisa legitimnog potpisnika na lažnim podacima.
U5. Dobivanje pozitivnog rezultata provjere elektroničkog potpisa lažnih podataka.
U6. Pogrešno prihvaćanje elektroničkih dokumenata na izvršavanje zbog problema u organizaciji elektroničkog poslovanja.
U7. Neovlašteno upoznavanje sa zaštićenim podacima tijekom njihove obrade SKZI-jem.
U1. Kompromitacija tajnih kriptografskih ključeva
U1.1. Dobivanje tajnog ključa iz spremišta tajnih ključeva.
U1.2. Dobivanje tajnog ključa iz objekata okruženja rada kripto-sredstva, u kojima on može privremeno boraviti.
Objašnjenja U1.2.
Objekti u kojima može privremeno biti pohranjen tajni ključ uključuju:
- radnu memoriju,
- privremene datoteke,
- datoteke za zamjenu,
- datoteke hibernacije,
- datoteke snapshot-a 'vrućeg' stanja virtualnih mašina, uključujući datoteke sadržaja radne memorije virtualnih mašina koje su pauzirane.
U1.2.1. Izdvajanje tajnih ključeva iz radne memorije uz pomoć zamrzavanja RAM modula, njihovog izdvajanja i naknadnog čitanja podataka (freeze attack).
Objašnjenja U1.2.1.
Primjer .
U1.3. Dobivanje tajnog ključa iz kanala razmjene tajnih ključeva.
Objašnjenja U1.3.
Primjer implementacije ove prijetnje bit će predstavljen .
U1.4. Neovlaštena modifikacija kripto-jezgre, uslijed koje tajni ključevi postaju poznati napadačima.
U1.5. Kompromitacija tajnog ključa uslijed korištenja tehničkih kanala curenja informacija (TKUO).
Objašnjenja U1.5.
Primjer .
U1.6. Kompromitacija tajnog ključa uslijed korištenja posebnih tehničkih sredstava (STS) namijenjenih za neprimjetno prikupljanje informacija („bube“).
U1.7. Kompromitacija tajnih ključeva tijekom njihove pohrane izvan SKZI.
Objašnjenja U1.7.
Na primjer, korisnik pohranjuje svoje ključne medije u ladicu radnog stola, iz koje ih lako mogu izvući napadači.
U2. Šifriranje lažnih podataka u ime legitimnog pošiljatelja
Objašnjenja
Ova prijetnja razmatra se samo za sheme šifriranja podataka s autentifikacijom pošiljatelja. Primjeri takvih shema navedeni su u preporukama za standardizaciju. . Za ostale kriptografske sheme ova prijetnja ne postoji, budući da se šifriranje vrši na javnim ključevima primatelja, a oni su općenito poznati napadačima.
Dekonstrukcija
U2.1. Kompromitacija tajnog ključa pošiljatelja:
U2.1.1. Link: .
U2.2. Zamjena ulaznih podataka u kanalu razmjene javnih podataka.
Napomene U2.2.
Primjeri implementacije ove prijetnje navedeni su u nastavku. i .
U3. Dešifriranje šifriranih podataka od strane osoba koje nisu legitimni primatelji podataka (napadača)
Dekonstrukcija
U3.1. Kompromitacija tajnih ključeva primatelja šifriranih podataka.
U3.1.1 Referenca: .
U3.2. Zamjena šifriranih podataka u kanalu razmjene zaštićenih podataka.
U4. Stvaranje elektroničkog potpisa legitimnog potpisnika na lažnim podacima
Dekonstrukcija
U4.1. Kompromitacija tajnih ključeva elektroničkog potpisa legitimnog potpisnika.
U4.1.1 Referenca: .
U4.2. Zamjena podataka koji se potpisuju u kanalu razmjene javnih podataka.
Napomena U4.2.
Primjeri implementacije ove prijetnje navedeni su u nastavku. i .
U5. Dobivanje pozitivnog rezultata provjere elektroničkog potpisa na lažnim podacima.
Dekonstrukcija
U5.1. Napadači presreću u kanalu prijenosa rezultata rada poruku o negativnom rezultatu provjere elektroničkog potpisa i zamjenjuju je porukom s pozitivnim rezultatom.
U5.2. Napadači provode napad na povjerenje u certifikate potpisa (SCENARIJ — svi elementi su obavezni):
U5.2.1. Napadači generiraju javni i privatni ključ elektroničkog potpisa. Ako se u sustavu koriste certifikati ključeva elektroničkog potpisa, generiraju certifikat elektroničkog potpisa što je moguće sličniji certifikatu pretpostavljenog pošiljatelja podataka čiju poruku žele falsificirati.
U5.2.2. Napadači unose neautorizirane promjene u skladište javnih ključeva, dajući generiranom javnom ključi potrebnu razinu povjerenja i ovlaštenja.
U5.2.3. Napadači potpisuju lažne podatke ranije formiranim ključem elektroničkog potpisa i ugrađuju ih u kanal za razmjenu zaštićenih podataka.
U5.3. Napadači provode napad koristeći isteknute ključeve elektroničkog potpisa legalnog potpisnika (SCENARIJ — svi elementi su obavezni):
U5.3.1. Napadači kompromitiraju isteknute (neaktivne u ovom trenutku) privatne ključeve elektroničkog potpisa legitimnog pošiljatelja.
U5.3.2. Napadači zamjenjuju vrijeme u kanalu prijenosa vremena s vremenom kada su kompromitirani ključevi još uvijek bili aktivni.
U5.3.3. Napadači potpisuju lažne podatke ranije kompromitiranim ključem elektroničkog potpisa i ugrađuju ih u kanal za razmjenu zaštićenih podataka.
U5.4. Napadači provode napad koristeći kompromitirane ključeve elektroničkog potpisa legalnog potpisnika (SCENARIJ — svi elementi su obavezni):
U5.4.1. Napadači prave kopiju skladišta javnih ključeva.
U5.4.2. Napadači kompromitiraju privatne ključeve jednog od legalnih pošiljatelja. Taj primjećuje kompromitaciju, povlači ključeve, a informacije o povlačenju ključa se pohranjuju u skladište javnih ključeva.
U5.4.3. Napadači zamjenjuju skladište javnih ključeva s ranije kopiranim.
U5.4.4. Napadači potpisuju lažne podatke ranije kompromitiranim ključem elektroničkog potpisa i ugrađuju ih u kanal za razmjenu zaštićenih podataka.
U5.5. zbog prisutnosti grešaka u implementaciji 2. i 3. faze provjere elektroničkog potpisa:
Objašnjenja U5.5.
Primjer implementacije ove prijetnje dan je .
U5.5.1. Provjera povjerenja u certifikat ključa elektroničkog potpisa samo na temelju povjerenja u certifikat kojim je potpisan, bez provjera CRL ili OCSP.
Objašnjenja U5.5.1.
Primjer implementacije .
U5.5.2. Prilikom izgradnje lanca povjerenja u certifikat ne analiziraju se ovlasti certifikata koji izdajemo
Objašnjenja U5.5.2.
Primjer napada u vezi s SSL/TLS certifikatima.
Napadači su kupili legitiman certifikat za svoju e-poštu. Zatim su napravili lažni certifikat za web stranicu i potpisali ga svojim certifikatom. Ako se ovlasti ne provjeravaju, tada će provjera lanca povjerenja biti ispravna i, sukladno tome, lažni certifikat će također biti ispravan.
U5.5.3. Prilikom izgradnje lanca povjerenja u certifikat ne provjeravaju se međucertifikati na povlačenje.
U5.5.4. Ažuriranje CRL događa se rjeđe nego što ih izdaje certifikacijski centar.
U5.5.5. Odluka o povjerenju u elektronički potpis donosi se prije nego što stigne OCSP odgovor o statusu certifikata, poslan na zahtjev podnesen nakon vremena formiranja potpisa, ili prije nego što stigne sljedeći CRL nakon formiranja potpisa.
Objašnjenja U5.5.5.
U regulativama većine CA (certifikacijskih tijela) vrijeme povlačenja certifikata smatra se vremenom izdavanja najbližeg CRL-a, koji sadrži informacije o povlačenju 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: može se ne provjeravati usklađenost adrese pozvanog poslužitelja sa vrijednošću polja CN u certifikatu.
Primjer napada. Napadači su kompromitirali ključeve elektroničkog potpisa jednog od sudionika u platnom sustavu. Nakon toga su hakirali mrežu drugog sudionika i u njegovo ime poslali na obračunski poslužitelj platnog sustava platne dokumente, potpisane kompromitiranim ključevima. Ako poslužitelj analizira samo povjerenje i ne provjerava usklađenost, lažni dokumenti će se smatrati legitimnima.
U6. Pogrešno prihvaćanje elektroničkih dokumenata na izvršavanje zbog problema u organizaciji elektroničkog poslovanja.
Dekonstrukcija
U6.1. Primalac ne otkriva dupliciranje 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 višekratno poslati u kanal prijenosa zaštićenih podataka. Ako primatelj ne otkrije duplicirane kopije, svi primljeni dokumenti će se smatrati i obraditi kao različiti dokumenti.
U7. Neovlašteni pristup zaštićenim podacima tijekom njihove obrade SKZI
Dekonstrukcija
U7.1. uslijed curenja informacija putem bočnih kanala (side channel attack).
Objašnjenja U7.1.
Primjer .
U7.2. uslijed neutralizacije zaštite od neovlaštenog pristupa informacijama koje se obrađuju na SKZI:
U7.2.1. Eksploatacija SKZI s kršenjima zahtjeva opisanih u dokumentaciji za SKZI.
U7.2.2. , koja se provodi zbog prisutnosti ranjivosti u:
U7.2.2.1. sredstvima zaštite od neovlaštenog pristupa.
U7.2.2.2. samom SKZI.
U7.2.2.3. okruženju rada kriptosredstava.
Primjeri napada
Scenariji navedeni u nastavku unaprijed sadrže greške u organizaciji informacijske sigurnosti i služe isključivo za ilustraciju mogućih napada.
Scenarij 1. Primjer realizacije prijetnji U2.2 i U4.2.
Opis objekta
SO APM KBR i SKZI SCAD Potpis su postavljeni na fizičkom računalu koje nije povezano s računalnom mrežom. Kao ključni medij koristi se FKN vdToken u načinu rada s neizvlačivim ključem.
Reglament provođenja proračuna pretpostavlja da stručnjak za proračune sa svog radnog računala preuzima elektroničke poruke u otvorenom obliku (shema starog APM KBR) sa specijalnog zaštićenog datotečnog poslužitelja, zatim ih zapisuje na prijenosni USB uređaj i prenosi na APM KBR, gdje se šifriraju i potpisuju. Nakon toga, stručnjak prenosi na prijenosni uređaj zaštićene elektroničke poruke, a zatim ih putem svog radnog računala zapisuje na datotečni poslužitelj, odakle dolaze na UTA i dalje u platni sustav Središnje banke Rusije.
U ovom slučaju, kanali razmjene otvorenih i zaštićenih podataka uključivat će: datotečni poslužitelj, radno računalo stručnjaka i prijenosni uređaj.
Napad
Napadači bez dozvole instaliraju sustav daljinskog upravljanja na radnom računalu stručnjaka i u trenutku snimanja na odvojeni uređaj s plaćanjem (elektronička poruka) u otvorenom obliku zamjenjuju sadržaj jednog od njih. Stručnjak prenosi naloge za plaćanje na ARM KBR, potpisuje ih i šifrira, ne primjećujući zamjenu (na primjer, zbog velikog broja naloga za plaćanje u obradi, umora itd.). Nakon toga, lažni nalog za plaćanje, prolazeći kroz tehnološki lanac, dolazi u platni sustav Banke Rusije.
Scenarij 2. Primjer realizacije prijetnji U2.2 i U4.2.
Opis objekta
Računalo s instaliranim ARM KBR, SKAD Signatura i priključenim ključnim uređajem FKN vdToken djeluje u odvojenom prostoru bez pristupa osoblja.
Stručnjak za obračune povezuje se s ARM KBR u režimu daljinskog pristupa putem RDP protokola.
Napad
Napadači presreću podatke koji se koriste kako bi se stručnjak za obračune povezao i radio s ARM KBR (na primjer, putem zlonamjernog koda na njegovom računalu). Zatim se povezuju u njegovo ime i šalju u platni sustav Banke Rusije lažni nalog za plaćanje.
Scenarij 3. Primjer realizacije prijetnje U1.3.
Opis objekta
Razmotrit ćemo jedan od hipotetskih scenarija realizacije modula integracije "ABS-KBR" za novu shemu (ARM KBR-N), pri kojoj se elektronički potpis izlaznih dokumenata vrši na strani ABS-a. Pri tome ćemo smatrati da ABS funkcionira na bazi operativnog sustava koji nije podržan od strane SKZI SKAD Signatura, i stoga je kriptografska funkcionalnost premještena na zasebnu virtualnu mašinu - modul integracije "ABS-KBR".
Kao ključni uređaj koristi se obični USB token koji radi u režimu uklonjivog ključa. Prilikom povezivanja ključnog uređaja s hypervisorom ispostavilo se da u sustavu nema slobodnih USB priključaka, pa je odlučeno povezati USB token putem mrežnog USB koncentratora, a na virtualnu mašinu instalirati USB-over-IP klijent koji će uspostaviti vezu s koncentratorom.
Napad
Napadači su presreli privatni ključ elektroničkog potpisa iz komunikacijskog kanala između USB hub-a i hipervizora (podatci su se prenosili u otvorenom obliku). Imajući privatni ključ, napadači su generirali lažni platni nalog, potpisali ga elektroničkim potpisom i poslali ga u ARM KBR-N na izvršenje.
Scenarij 4. Primjer realizacije prijetnji U5.5.
Opis objekta
Razmotrite istu shemu kao u prethodnom scenariju. Pretpostavit ćemo da elektroničke poruke koje dolaze iz ARM KBR-N dolaze u mapu …SHAREIn, dok se one koje se šalju u ARM KBR-N i dalje u platni sustav Banke Rusije šalju u …SHAREout.
Također ćemo pretpostaviti da se prilikom realizacije modula integracije popisi opozvanih certifikata ažuriraju samo prilikom ponovnog izdavanja kriptografskih ključeva, te da se elektroničke poruke koje stižu u mapu …SHAREIn provjeravaju samo s obzirom na kontrolu cjelovitosti i kontrolu povjerenja prema javnom ključu elektroničkog potpisa.
Napad
Napadači, koristeći ukradene ključeve iz prethodnog scenarija, potpisali su lažni platni nalog koji sadrži informacije o prijemu novca na račun klijent-varalicu i ubrizgali ga u kanal razmjene zaštićenih podataka. Budući da se ne provodi provjera je li platni nalog potpisao upravo Banka Rusije, on se prihvaća na izvršenje.
Izvor: habr.com
