Linkek a tanulmány más részeihez
- (Te itt vagy)
Ez a cikk a készpénz nélküli banki fizetések információbiztonságának biztosításáról szóló kiadványsorozatot fejezi be. Itt megvizsgáljuk a cikkben említett tipikus fenyegetési modelleket :
- .
- .
- .
- .
HABRO-FIGYELEM!!! Kedves Khabroviták, ez nem egy szórakoztató bejegyzés.
A vágás alatt elrejtett több mint 40 oldalnyi anyag célja segít a munkában vagy a tanulásban banki vagy információbiztonsági szakterületek. Ezek az anyagok a kutatás végtermékei, és száraz, formális hangnemben készültek. Lényegében ezek üresek a belső információbiztonsági dokumentumok számára.Nos, hagyományos... „A cikkből származó információk illegális célú felhasználását törvény bünteti”. Termékeny olvasás!
Tájékoztatás azoknak az olvasóknak, akik megismerkednek a jelen publikációval kezdődő tanulmányokkal.
Miről szól a tanulmány?
Ön egy útmutatót olvas a banki fizetések információbiztonságáért felelős szakember számára.
A bemutatás logikája
Az elején ben и a védett objektum leírása szerepel. Aztán be leírja, hogyan kell felépíteni egy biztonsági rendszert, és beszél a fenyegetési modell létrehozásának szükségességéről. BAN BEN beszél arról, hogy milyen fenyegetési modellek léteznek és hogyan alakulnak ki. BAN BEN и A valós támadások elemzése rendelkezésre áll. и tartalmazza a fenyegetésmodell leírását, amely az összes korábbi rész információinak figyelembevételével készült.
TIPIKUS VESZÉLY MODELL. INTERNETKAPCSOLAT
Védelmi objektum, amelyre a fenyegetési modellt (hatókört) alkalmazzák
A védelem tárgya a TCP/IP veremre épülő adathálózatokban működő hálózati kapcsolaton keresztül továbbított adatok.
építészet
Az építészeti elemek leírása:
- "Vég csomópontok" — védett információkat cserélő csomópontok.
- "Köztes csomópontok" — az adatátviteli hálózat elemei: útválasztók, kapcsolók, hozzáférési szerverek, proxy szerverek és egyéb berendezések – amelyeken keresztül a hálózati kapcsolati forgalom továbbításra kerül. Általánosságban elmondható, hogy a hálózati kapcsolat közbenső csomópontok nélkül is működhet (közvetlenül a végcsomópontok között).
Legfelső szintű biztonsági fenyegetések
Bomlás
U1. Jogosulatlan hozzáférés a továbbított adatokhoz.
U2. A továbbított adatok jogosulatlan módosítása.
U3. A továbbított adatok szerzői jogának megsértése.
U1. Jogosulatlan hozzáférés a továbbított adatokhoz
Bomlás
U1.1. <…>, a végső vagy közbenső csomópontokon végrehajtva:
U1.1.1. <…> az adatok beolvasásával, miközben azok a gazdagép tárolóeszközökön vannak:
U1.1.1.1. <…> a RAM-ban.
Magyarázatok az U1.1.1.1.
Például a gazdagép hálózati veremének adatfeldolgozása során.
U1.1.1.2. <…> a nem felejtő memóriában.
Magyarázatok az U1.1.1.2.
Például, ha a továbbított adatokat gyorsítótárban tárolja, ideiglenes fájlok vagy cserefájlok.
U1.2. <…>, az adathálózat harmadik fél csomópontjain végrehajtva:
U1.2.1. <…> a gazdagép hálózati interfészére érkező összes csomag rögzítésének módszerével:
Magyarázatok az U1.2.1.
Az összes csomag rögzítése a hálózati kártya promiszkuális módba kapcsolásával történik (promiscuous mód vezetékes adaptereknél vagy monitor mód wi-fi adaptereknél).
U1.2.2. <…> man-in-the-middle (MiTM) támadások végrehajtásával, de a továbbított adatok módosítása nélkül (nem számítva a hálózati protokoll szolgáltatás adatait).
U1.2.2.1. Link: .
U1.3. <…>, amelyet a fizikai csomópontokból vagy kommunikációs vonalakból technikai csatornákon (TKUI) keresztül történő információszivárgás miatt hajtanak végre.
U1.4. <…>, speciális technikai eszközök (STS) telepítésével a vég- vagy közbülső csomópontokra, amelyek titkos információgyűjtésre szolgálnak.
U2. A továbbított adatok jogosulatlan módosítása
Bomlás
U2.1. <…>, a végső vagy közbenső csomópontokon végrehajtva:
U2.1.1. <…> az adatok beolvasásával és módosításával, miközben azok a csomópontok tárolóeszközein vannak:
U2.1.1.1. <…> a RAM-ban:
U2.1.1.2. <…> a nem felejtő memóriában:
U2.2. <…>, az adatátviteli hálózat harmadik fél csomópontjain végrehajtva:
U2.2.1. <…> Man-in-the-middle (MiTM) támadások végrehajtásával és a forgalom átirányításával a támadók csomópontjára:
U2.2.1.1. A támadók berendezéseinek fizikai kapcsolata megszakítja a hálózati kapcsolatot.
U2.2.1.2. Hálózati protokollok elleni támadások végrehajtása:
U2.2.1.2.1. <…> virtuális helyi hálózatok (VLAN) kezelése:
U2.2.1.2.1.1. .
U2.2.1.2.1.2. A kapcsolók vagy útválasztók VLAN-beállításainak jogosulatlan módosítása.
U2.2.1.2.2. <…> forgalomirányítás:
U2.2.1.2.2.1. Az útválasztók statikus útválasztási tábláinak jogosulatlan módosítása.
U2.2.1.2.2.2. Hamis útvonalak bejelentése a támadók által dinamikus útválasztási protokollokon keresztül.
U2.2.1.2.3. <…> automatikus konfiguráció:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. <…> címzés és névfeloldás:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Jogosulatlan módosítások végrehajtása a helyi gazdagépnév-fájlokban (hosts, lmhosts stb.)
U3. A továbbított adatok szerzői jogának megsértése
Bomlás
U3.1. Az információ szerzőjének meghatározására szolgáló mechanizmusok semlegesítése a szerzőre vagy az adatforrásra vonatkozó hamis információk feltüntetésével:
U3.1.1. A továbbított információban szereplő, a szerzőre vonatkozó információk megváltoztatása.
U3.1.1.1. A továbbított adatok integritásának és szerzőjének kriptográfiai védelmének semlegesítése:
U3.1.1.1.1. Link: .
U3.1.1.2. A továbbított adatok szerzői jogi védelmének semlegesítése, egyszeri megerősítő kódokkal megvalósítva:
U3.1.1.2.1. .
U3.1.2. A továbbított információ forrására vonatkozó információk módosítása:
U3.1.2.1. .
U3.1.2.2. .
TIPIKUS VESZÉLY MODELL. AZ ÜGYFÉL-SZERVER ARCHITEKTÚRA ALAPJÁN ÉPÍTETT INFORMÁCIÓS RENDSZER
Védelmi objektum, amelyre a fenyegetési modellt (hatókört) alkalmazzák
A védelem tárgya egy kliens-szerver architektúrára épülő információs rendszer.
építészet
Az építészeti elemek leírása:
- "Ügyfél" – olyan eszköz, amelyen az információs rendszer kliens része működik.
- "Szerver" – olyan eszköz, amelyen az információs rendszer szerver része működik.
- "Adattár" — az információs rendszer szerverinfrastruktúrájának része, amelyet az információs rendszer által feldolgozott adatok tárolására terveztek.
- "Internetkapcsolat" — az adathálózaton áthaladó információcsere csatorna az Ügyfél és a Szerver között. Az elemmodell részletesebb leírása a következőben található .
Korlátozások
Egy objektum modellezésekor a következő korlátozások vannak beállítva:
- A felhasználó véges időn belül interakcióba lép az információs rendszerrel, ezeket munkameneteknek nevezzük.
- Minden munkamenet elején a felhasználó azonosítása, hitelesítése és engedélyezése megtörténik.
- Minden védett információ az információs rendszer szerver részén kerül tárolásra.
Legfelső szintű biztonsági fenyegetések
Bomlás
U1. Jogosulatlan műveletek végrehajtása a támadók részéről jogos felhasználó nevében.
U2. A védett információ jogosulatlan módosítása az információs rendszer szerver része általi feldolgozása során.
U1. Jogosulatlan műveletek végrehajtása a támadók részéről jogos felhasználó nevében
magyarázatok
Az információs rendszerekben a műveletek általában összefüggésben vannak azzal a felhasználóval, aki a következőket használta:
- rendszerműködési naplók (naplók).
- az adatobjektumok speciális attribútumai, amelyek információkat tartalmaznak az azokat létrehozó vagy módosító felhasználóról.
A munkamenettel kapcsolatban ez a fenyegetés a következőkre bontható:
- <…> a felhasználói munkameneten belül végrehajtva.
- <…> a felhasználói munkameneten kívül végrehajtva.
Felhasználói munkamenet indítható:
- Maga a felhasználó által.
- Rosszindulatúak.
Ebben a szakaszban ennek a fenyegetésnek a köztes lebontása a következőképpen fog kinézni:
U1.1. Jogosulatlan műveletek történtek egy felhasználói munkameneten belül:
U1.1.1. <…> a megtámadott felhasználó által telepített.
U1.1.2. <…> támadók telepítették.
U1.2. A felhasználói munkameneten kívül jogosulatlan műveleteket hajtottak végre.
A támadók által érintett információs infrastruktúra objektumok szempontjából a köztes fenyegetések lebontása a következőképpen fog kinézni:
elemek
Veszélybomlás
U1.1.1.
U1.1.2.
U1.2.
vásárló
U1.1.1.1.
U1.1.2.1.
Internetkapcsolat
U1.1.1.2.
Сервер
U1.2.1.
Bomlás
U1.1. Jogosulatlan műveletek történtek egy felhasználói munkameneten belül:
U1.1.1. <…> a támadott felhasználó által telepített:
U1.1.1.1. A támadók az Ügyféltől függetlenül cselekedtek:
U1.1.1.1.1 A támadók szabványos információs rendszer-hozzáférési eszközöket használtak:
У1.1.1.1.1.1. A támadók az Ügyfél fizikai beviteli/kimeneti eszközeit (billentyűzet, egér, monitor vagy mobileszköz érintőképernyője) használták:
U1.1.1.1.1.1.1. A támadók olyan időszakokban működtek, amikor a munkamenet aktív volt, I/O-eszközök rendelkezésre álltak, és a felhasználó nem volt jelen.
У1.1.1.1.1.2. A támadók távoli adminisztrációs eszközöket (normál vagy rosszindulatú kód által biztosított) használtak az Ügyfél kezelésére:
U1.1.1.1.1.2.1. A támadók olyan időszakokban működtek, amikor a munkamenet aktív volt, I/O-eszközök rendelkezésre álltak, és a felhasználó nem volt jelen.
У1.1.1.1.1.2.2. A támadók távoli adminisztrációs eszközöket használtak, amelyek működése láthatatlan a támadott felhasználó számára.
U1.1.1.2. A támadók az Ügyfél és a Szerver közötti hálózati kapcsolaton lecserélték az adatokat, oly módon módosítva azokat, hogy azokat egy jogos felhasználó tevékenységének tekintsék:
U1.1.1.2.1. Link: .
U1.1.1.3. A támadók social engineering módszerekkel kényszerítették a felhasználót az általuk meghatározott műveletek végrehajtására.
A támadók által telepített У1.1.2 <…> verzió:
U1.1.2.1. A támadók a kliens felől cselekedtek (И):
U1.1.2.1.1. A támadók hatástalanították az információs rendszer beléptető rendszerét:
U1.1.2.1.1.1. Link: .
У1.1.2.1.2. A támadók szabványos információs rendszer-hozzáférési eszközöket használtak
U1.1.2.2. A támadók az adathálózat más csomópontjairól tevékenykedtek, ahonnan hálózati kapcsolat létesíthető a Szerverrel (И):
U1.1.2.2.1. A támadók hatástalanították az információs rendszer beléptető rendszerét:
U1.1.2.2.1.1. Link: .
U1.1.2.2.2. A támadók nem szabványos eszközöket használtak az információs rendszerhez való hozzáférésre.
Magyarázatok U1.1.2.2.2.
A támadók telepíthetik az információs rendszer szabványos kliensét egy harmadik fél csomópontjára, vagy használhatnak nem szabványos szoftvert, amely szabványos csereprotokollokat valósít meg az Ügyfél és a Szerver között.
U1.2 Jogosulatlan műveletek a felhasználói munkameneten kívül történtek.
U1.2.1 A támadók jogosulatlan műveleteket hajtottak végre, majd jogosulatlanul módosították az információs rendszer működési naplóit vagy az adatobjektumok speciális attribútumait, jelezve, hogy az általuk végrehajtott műveleteket jogos felhasználó hajtotta végre.
U2. A védett információ jogosulatlan módosítása az információs rendszer szerver része általi feldolgozása során
Bomlás
U2.1. A támadók szabványos információs rendszereszközökkel módosítják a védett információkat, és ezt a jogos felhasználó nevében teszik.
U2.1.1. Link: .
U2.2. A támadók az információs rendszer normál működése által nem biztosított adathozzáférési mechanizmusok segítségével módosítják a védett információkat.
U2.2.1. A támadók védett információkat tartalmazó fájlokat módosítanak:
U2.2.1.1. <…>, az operációs rendszer által biztosított fájlkezelési mechanizmusok használatával.
U2.2.1.2. <…> a fájlok visszaállításának kiprovokálásával egy jogosulatlan módosított biztonsági másolatból.
U2.2.2. A támadók módosítják az adatbázisban tárolt védett információkat (И):
U2.2.2.1. A támadók semlegesítik a DBMS hozzáférés-vezérlő rendszert:
U2.2.2.1.1. Link: .
U2.2.2.2. A támadók szabványos DBMS interfészek segítségével módosítják az információkat az adatok eléréséhez.
U2.3. A támadók a védett információkat az azokat feldolgozó szoftver működési algoritmusainak jogosulatlan módosításával módosítják.
U2.3.1. A szoftver forráskódja módosulhat.
U2.3.1. A szoftver gépi kódja módosulhat.
U2.4. A támadók az információs rendszerszoftverek biztonsági réseit kihasználva módosítják a védett információkat.
U2.5. A támadók módosítják a védett információkat, amikor azokat az információs rendszer kiszolgáló részének összetevői (például adatbázis-kiszolgáló és alkalmazásszerver) között továbbítják:
U2.5.1. Link: .
TIPIKUS VESZÉLY MODELL. BELÉPTETŐ RENDSZER
Védelmi objektum, amelyre a fenyegetési modellt (hatókört) alkalmazzák
A védelmi objektum, amelyre ezt a fenyegetési modellt alkalmazzák, megfelel a fenyegetésmodell védelmi objektumának: „Tipikus fenyegetésmodell. Kliens-szerver architektúrára épülő információs rendszer.”
Ebben a fenyegetési modellben a felhasználói beléptetőrendszer egy információs rendszer olyan összetevőjét jelenti, amely a következő funkciókat valósítja meg:
- Felhasználó azonosítása.
- Felhasználói hitelesítés.
- Felhasználói jogosultságok.
- Felhasználói műveletek naplózása.
Legfelső szintű biztonsági fenyegetések
Bomlás
U1. Jogosulatlan munkamenet létrehozása jogos felhasználó nevében.
U2. A felhasználói jogosultságok jogosulatlan növelése egy információs rendszerben.
U1. Jogosulatlan munkamenet létrehozása jogos felhasználó nevében
magyarázatok
A fenyegetés lebontása általában a használt felhasználóazonosító és hitelesítési rendszerek típusától függ.
Ebben a modellben csak a szöveges bejelentkezést és jelszót használó felhasználói azonosítási és hitelesítési rendszer veszi figyelembe. Ebben az esetben azt feltételezzük, hogy a felhasználói bejelentkezés nyilvánosan elérhető információ, amelyet a támadók ismernek.
Bomlás
U1.1. <…> a hitelesítő adatok veszélyeztetése miatt:
U1.1.1. A támadók a tárolás során feltörték a felhasználó hitelesítő adatait.
Magyarázatok U1.1.1.
Például a hitelesítő adatokat fel lehet írni a monitorra ragasztott cetlire.
U1.1.2. A felhasználó véletlenül vagy rosszindulatúan továbbította a hozzáférési adatokat a támadóknak.
U1.1.2.1. A felhasználó hangosan kimondta a hitelesítő adatokat, amikor belépett.
U1.1.2.2. A felhasználó szándékosan osztotta meg hitelesítő adatait:
U1.1.2.2.1. <…> a munkatársaknak.
Magyarázatok U1.1.2.2.1.
Például azért, hogy betegség közben pótolhassák.
U1.1.2.2.2. <…> a munkáltató információs infrastruktúra objektumakon munkát végző vállalkozóknak.
U1.1.2.2.3. <…> harmadik feleknek.
Magyarázatok U1.1.2.2.3.
Az egyik, de nem az egyetlen lehetőség ennek a fenyegetésnek a megvalósítására, hogy a támadók social engineering módszereket alkalmaznak.
U1.1.3. A támadók nyers erő módszerekkel választották ki a hitelesítő adatokat:
U1.1.3.1. <…> szabványos hozzáférési mechanizmusok használatával.
U1.1.3.2. <…> korábban elfogott kódok (például jelszókivonatok) használata a hitelesítő adatok tárolására.
U1.1.4. A támadók rosszindulatú kódot használtak a felhasználói hitelesítő adatok elfogására.
U1.1.5. A támadók hitelesítő adatokat gyűjtöttek ki az Ügyfél és a Szerver közötti hálózati kapcsolatból:
U1.1.5.1. Link: .
U1.1.6. A támadók a munkamegfigyelő rendszerek nyilvántartásaiból szereztek be hitelesítő adatokat:
U1.1.6.1. <…> videó megfigyelő rendszerek (ha működés közben rögzítették a billentyűzet billentyűleütéseit).
U1.1.6.2. <…> rendszerek az alkalmazottak számítógépen végzett tevékenységeinek megfigyelésére
Magyarázatok U1.1.6.2.
Ilyen rendszer például az .
U1.1.7. A támadók az átviteli folyamat hibái miatt veszélyeztették a felhasználói hitelesítő adatokat.
Magyarázatok U1.1.7.
Például jelszavak szöveges elküldése e-mailben.
U1.1.8. A támadók úgy szerezték meg a hitelesítő adatokat, hogy távoli adminisztrációs rendszerekkel figyelték a felhasználó munkamenetét.
U1.1.9. A támadók a technikai csatornákon (TCUI) keresztül történő kiszivárgás eredményeként szereztek hitelesítő adatokat:
U1.1.9.1. A támadók megfigyelték, hogyan adta meg a felhasználó a hitelesítő adatokat a billentyűzetről:
U1.1.9.1.1 A támadók a felhasználó közvetlen közelében tartózkodtak, és saját szemükkel látták a hitelesítő adatok bevitelét.
Magyarázatok U1.1.9.1.1
Ilyen esetek például a munkatársak lépései, vagy az az eset, amikor a felhasználó billentyűzete látható a szervezet látogatói számára.
U1.1.9.1.2 A támadók további technikai eszközöket, például távcsövet vagy pilóta nélküli légijárművet használtak, és egy ablakon keresztül látták a hitelesítő adatokat.
U1.1.9.2. A támadók a billentyűzet és a számítógépes rendszeregység közötti rádiókommunikációból szereztek be hitelesítő adatokat, amikor rádióinterfészen (például Bluetoothon) keresztül csatlakoztak.
U1.1.9.3. A támadók elfogták a hitelesítő adatokat úgy, hogy átszivárogtatták azokat a hamis elektromágneses sugárzás és interferencia (PEMIN) csatornáján.
Magyarázatok U1.1.9.3.
Példák támadásokra и .
U1.1.9.4. A támadó titkos információszerzésre szolgáló speciális technikai eszközök (STS) segítségével elfogta a hitelesítő adatok bevitelét a billentyűzetről.
Magyarázatok U1.1.9.4.
Примеры .
U1.1.9.5. A támadók elfogták a hitelesítő adatok bevitelét a billentyűzetről
a felhasználó billentyűleütési folyamata által modulált Wi-Fi jel elemzése.
Magyarázatok U1.1.9.5.
Példa .
U1.1.9.6. A támadók a billentyűzetről bevitt hitelesítő adatokat a billentyűleütések hangjának elemzésével elfogták.
Magyarázatok U1.1.9.6.
Példa .
U1.1.9.7. A támadók a gyorsulásmérő leolvasásának elemzésével elfogták a hitelesítő adatok bevitelét egy mobileszköz billentyűzetéről.
Magyarázatok U1.1.9.7.
Példa .
U1.1.10. <…>, korábban az Ügyfélben mentve.
Magyarázatok U1.1.10.
Például a felhasználó elmenthet egy bejelentkezési nevet és jelszót a böngészőben egy adott webhely eléréséhez.
U1.1.11. A támadók feltörték a hitelesítési adatokat a felhasználói hozzáférés visszavonására vonatkozó folyamat hibái miatt.
Magyarázatok U1.1.11.
Például egy felhasználó kirúgása után a fiókjai feloldva maradtak.
U1.2. <…> a beléptető rendszer sebezhetőségeinek kihasználásával.
U2. A felhasználói jogosultságok jogosulatlan növelése információs rendszerben
Bomlás
U2.1 <…> a felhasználói jogosultságokkal kapcsolatos információkat tartalmazó adatok jogosulatlan módosításával.
U2.2 <…> a beléptetőrendszer biztonsági résein keresztül.
U2.3. <…> a felhasználói hozzáférés-kezelési folyamat hiányosságai miatt.
Magyarázatok U2.3.
1. példa: Egy felhasználó több hozzáférést kapott a munkához, mint amennyit üzleti okokból igényelt.
2. példa: Miután egy felhasználót áthelyeztek egy másik pozícióba, a korábban megadott hozzáférési jogosultságokat nem vonták vissza.
TIPIKUS VESZÉLY MODELL. INTEGRÁCIÓS MODUL
Védelmi objektum, amelyre a fenyegetési modellt (hatókört) alkalmazzák
Az integrációs modul információs infrastruktúra objektumok halmaza, amelyet az információs rendszerek közötti információcsere megszervezésére terveztek.
Tekintettel arra, hogy a vállalati hálózatokban nem mindig lehet egy információs rendszert egyértelműen elkülöníteni a másiktól, az integrációs modul egy információs rendszeren belüli komponensek közötti összekötő kapcsnak is tekinthető.
építészet
Az integrációs modul általánosított diagramja így néz ki:
Az építészeti elemek leírása:
- "Exchange Server (SO)" – információs rendszer csomópontja/szolgáltatása/komponense, amely egy másik információs rendszerrel való adatcsere funkcióját látja el.
- "Közvetítő" – az információs rendszerek közötti interakció megszervezésére tervezett csomópont/szolgáltatás, de nem része ezeknek.
Példák "Közvetítők" lehetnek e-mail szolgáltatások, vállalati szolgáltatási buszok (vállalati szolgáltatásbusz / SoA architektúra), harmadik féltől származó fájlszerverek stb. Az integrációs modul általában nem tartalmazhat „Közvetítőket”. - "Adatfeldolgozó szoftver" – adatcsere-protokollokat és formátumkonverziót megvalósító programkészlet.
Például adatok konvertálása UFEBS formátumból ABS formátumba, üzenetállapotok megváltoztatása átvitel közben stb. - "Internetkapcsolat" megfelel a szabványos „Hálózati kapcsolat” fenyegetési modellben leírt objektumnak. Előfordulhat, hogy a fenti ábrán látható hálózati kapcsolatok némelyike nem létezik.
Példák integrációs modulokra
1. séma. Az ABS és az AWS KBR integrálása harmadik féltől származó fájlszerveren keresztül
A fizetések lebonyolításához egy felhatalmazott banki alkalmazott letölti az elektronikus fizetési dokumentumokat az alapbanki rendszerből, és elmenti azokat egy fájlba (saját formátumban, például SQL dump) egy fájlszerver hálózati mappájába (...SHARE). Ezután ezt a fájlt egy konverter szkript segítségével UFEBS formátumú fájlkészletekké konvertálják, amelyeket aztán a CBD munkaállomás beolvas.
Ezt követően a felhatalmazott alkalmazott - az automatizált munkahelyi KBR felhasználója - titkosítja és aláírja a kapott fájlokat, és elküldi az Oroszországi Bank fizetési rendszerébe.
Amikor kifizetések érkeznek az Oroszországi Banktól, a KBR automatizált munkahelye visszafejti azokat, és ellenőrzi az elektronikus aláírást, majd UFEBS formátumú fájlkészlet formájában rögzíti őket egy fájlszerveren. A fizetési bizonylatok ABS-be történő importálása előtt konvertáló szkript segítségével UFEBS formátumról ABS formátumra konvertálják azokat.
Feltételezzük, hogy ebben a sémában az ABS egy fizikai szerveren működik, a KBR munkaállomás egy dedikált számítógépen, a konvertáló szkript pedig egy fájlszerveren fut.
A vizsgált diagram objektumainak megfelelése az integrációs modul modell elemeinek:
„Csereszerver ABS oldalról” – ABS szerver.
„Csereszerver az AWS KBR oldaláról” – számítógépes munkaállomás KBR.
"Közvetítő" – harmadik féltől származó fájlszerver.
"Adatfeldolgozó szoftver" – konverter szkript.
2. séma. Az ABS és az AWS KBR integrációja, amikor megosztott hálózati mappát helyez el a fizetésekkel az AWS KBR-n
Minden hasonló a Scheme 1-hez, de nem használnak külön fájlszervert, helyette egy CBD munkaállomással rendelkező számítógépen egy hálózati mappát (...SHARE) helyeznek el az elektronikus fizetési dokumentumokkal. A konverter szkript a CBD munkaállomáson is működik.
A vizsgált diagram objektumainak megfelelése az integrációs modul modell elemeinek:
Hasonló az 1. sémához, de "Közvetítő" nem használt.
3. séma. Az ABS és az automatizált munkahelyi KBR-N integrációja az IBM WebSphera MQ-n keresztül és az elektronikus dokumentumok aláírása „ABS oldalon”
Az ABS olyan platformon működik, amelyet a CIPF SCAD Signature nem támogat. A kimenő elektronikus dokumentumok aláírása speciális elektronikus aláírás szerveren (ES Server) történik. Ugyanez a szerver ellenőrzi az Oroszországi Banktól beérkező dokumentumok elektronikus aláírását.
Az ABS a fizetési bizonylatokat tartalmazó fájlt saját formátumában tölti fel az ES szerverre.
Az ES szerver egy konverter szkript segítségével UFEBS formátumú elektronikus üzenetekké alakítja a fájlt, majd az elektronikus üzeneteket aláírja és továbbítja az IBM WebSphere MQ-nak.
A KBR-N munkaállomás hozzáfér az IBM WebSphere MQ-hoz, és onnan fogadja az aláírt fizetési üzeneteket, majd egy erre jogosult alkalmazott - a KBR munkaállomás felhasználója - titkosítja azokat, és elküldi az Oroszországi Bank fizetési rendszerébe.
Amikor az Oroszországi Banktól fizetés érkezik, a KBR-N automatizált munkahely dekódolja azokat, és ellenőrzi az elektronikus aláírást. A dekódolt és aláírt, UFEBS formátumú elektronikus üzenetek formájában sikeresen feldolgozott fizetések átkerülnek az IBM WebSphere MQ-ba, ahonnan az Elektronikus aláírás szerver fogadja azokat.
Az elektronikus aláírás szerver ellenőrzi a beérkezett fizetések elektronikus aláírását, és ABS formátumú fájlba menti. Ezt követően a felhatalmazott alkalmazott - az ABS felhasználó - az így kapott fájlt az előírt módon feltölti az ABS-be.
A vizsgált diagram objektumainak megfelelése az integrációs modul modell elemeinek:
„Csereszerver ABS oldalról” – ABS szerver.
„Csereszerver az AWS KBR oldaláról” — számítógépes munkaállomás KBR.
"Közvetítő" – ES szerver és IBM WebSphere MQ.
"Adatfeldolgozó szoftver" – script konverter, CIPF SCAD aláírás az ES szerveren.
4. séma. Az RBS szerver és az alapbanki rendszer integrálása egy dedikált csereszerver által biztosított API-n keresztül
Feltételezzük, hogy a bank több távoli banki rendszert (RBS) használ:
- "Internet Client-Bank" magánszemélyek számára (IKB FL);
- „Internet Client-Bank” jogi személyek számára (IKB LE).
Az információbiztonság érdekében az ABS és a távoli banki rendszerek közötti minden interakció az ABS információs rendszer keretein belül működő dedikált csereszerveren keresztül történik.
Ezután megvizsgáljuk az IKB LE RBS rendszere és az ABS közötti interakció folyamatát.
Az RBS szervernek, miután megkapta az ügyféltől megfelelően hitelesített fizetési megbízást, ennek alapján megfelelő bizonylatot kell létrehoznia az ABS-ben. Ennek érdekében az API segítségével információkat továbbít a csereszervernek, amely viszont beviszi az adatokat az ABS-be.
Az ügyfél számlaegyenlegének változása esetén az ABS elektronikus értesítéseket generál, amelyeket a pénzváltó szerver segítségével továbbít a távoli banki szerverre.
A vizsgált diagram objektumainak megfelelése az integrációs modul modell elemeinek:
„Csereszerver RBS oldalról” – az IKB YUL RBS szervere.
„Csereszerver ABS oldalról” – Exchange szerver.
"Közvetítő" - hiányzó.
"Adatfeldolgozó szoftver" – A Exchange Server API használatáért felelős RBS Server komponensek, az alapvető banki API használatáért felelős Exchange szerver komponensek.
Legfelső szintű biztonsági fenyegetések
Bomlás
U1. Támadók hamis információk beszúrása az integrációs modulon keresztül.
U1. Támadók hamis információk beszúrása az integrációs modulon keresztül
Bomlás
U1.1. Jogos adatok illetéktelen módosítása hálózati kapcsolaton keresztül történő továbbításkor:
U1.1.1 link: .
U1.2. Hamis adatok továbbítása kommunikációs csatornákon a csere jogos résztvevője nevében:
U1.1.2 link: .
U1.3. Jogos adatok jogosulatlan módosítása az Exchange szervereken vagy a Közvetítőn történő feldolgozás során:
U1.3.1. Link: .
U1.4. Hamis adatok létrehozása az Exchange Szervereken vagy Közvetítőn jogos cseretag nevében:
U1.4.1. Link:
U1.5. Az adatok jogosulatlan módosítása adatfeldolgozó szoftverrel történő feldolgozás esetén:
U1.5.1. <…> amiatt, hogy a támadók jogosulatlanul módosítják az adatfeldolgozó szoftver beállításait (konfigurációját).
U1.5.2. <…> amiatt, hogy a támadók illetéktelenül módosítják az adatfeldolgozó szoftverek futtatható fájljait.
U1.5.3. <…> az adatfeldolgozó szoftver támadók általi interaktív vezérlése miatt.
TIPIKUS VESZÉLY MODELL. KRIPTOGRÁFIAI INFORMÁCIÓVÉDELMI RENDSZER
Védelmi objektum, amelyre a fenyegetési modellt (hatókört) alkalmazzák
A védelem tárgya az információs rendszer biztonságának biztosítására szolgáló kriptográfiai információvédelmi rendszer.
építészet
Minden információs rendszer alapja az alkalmazási szoftver, amely megvalósítja a cél funkcionalitását.
A kriptográfiai védelmet általában az alkalmazási szoftver üzleti logikájából származó kriptográfiai primitívek meghívásával valósítják meg, amelyek speciális könyvtárakban - kriptomagokban - találhatók.
A kriptográfiai primitívek közé tartoznak az alacsony szintű kriptográfiai funkciók, mint például:
- adatblokk titkosítása/dekódolása;
- adatblokk elektronikus aláírásának létrehozása/ellenőrzése;
- kiszámítja az adatblokk hash függvényét;
- kulcsinformációk generálása / betöltése / feltöltése;
- stb
Az alkalmazásszoftver üzleti logikája magasabb szintű funkcionalitást valósít meg kriptográfiai primitívek segítségével:
- titkosítsa a fájlt a kiválasztott címzettek kulcsaival;
- biztonságos hálózati kapcsolat létrehozása;
- tájékoztatni az elektronikus aláírás ellenőrzésének eredményéről;
- és így tovább.
Az üzleti logika és a kriptomag kölcsönhatása megvalósítható:
- közvetlenül, az üzleti logika segítségével kriptográfiai primitíveket hív a kriptográfiai kernel dinamikus könyvtáraiból (.DLL Windows, .SO Linux esetén);
- közvetlenül, kriptográfiai interfészeken keresztül - burkolók, például MS Crypto API, Java Cryptography Architecture, PKCS#11 stb. Ebben az esetben az üzleti logika hozzáfér a kriptográfiai felülethez, és lefordítja a hívást a megfelelő titkosítási magra, amely ezt az esetet kriptoszolgáltatónak hívják. A kriptográfiai interfészek használata lehetővé teszi az alkalmazásszoftverek számára, hogy elvonatkoztassanak bizonyos kriptográfiai algoritmusoktól, és rugalmasabbak legyenek.
Két tipikus séma létezik a kriptomag megszervezésére:
1. séma – Monolit kriptomag
2. séma – Osztott kriptomag
A fenti diagramok elemei lehetnek egy számítógépen futó egyedi szoftvermodulok vagy számítógépes hálózaton belül kölcsönhatásba lépő hálózati szolgáltatások.
Az 1. séma szerint épített rendszerek használatakor az alkalmazásszoftver és a kriptográfiai mag egyetlen operációs környezetben működik a titkosító eszközhöz (SFC), például ugyanazon a számítógépen, ugyanazt az operációs rendszert futtatva. A rendszer felhasználója általában más programokat is futtathat, beleértve a rosszindulatú kódot tartalmazókat is, ugyanazon a működési környezetben. Ilyen körülmények között fennáll a privát kriptográfiai kulcsok kiszivárgásának komoly veszélye.
A kockázat minimalizálása érdekében a 2. sémát használják, amelyben a kriptomag két részre oszlik:
- Az első rész az alkalmazásszoftverrel együtt nem megbízható környezetben működik, ahol fennáll a rosszindulatú kóddal való fertőzés veszélye. Ezt a részt „szoftver résznek” nevezzük.
- A második rész megbízható környezetben működik egy dedikált eszközön, amely privát kulcstárolót tartalmaz. Mostantól ezt a részt „hardver”-nek nevezzük.
A titkosítási mag felosztása szoftver és hardver részekre nagyon önkényes. A piacon vannak olyan rendszerek, amelyek egy osztott kriptomaggal rendelkező séma szerint épülnek fel, de a „hardver” része egy virtuális gép kép - virtuális HSM (virtuális HSM) formájában jelenik meg.).
A titkosítási mag mindkét részének interakciója úgy történik, hogy a privát kriptográfiai kulcsok soha nem kerülnek át a szoftverrészbe, és ennek megfelelően nem lophatók el rosszindulatú kóddal.
Az interakciós felület (API) és a kriptográfiai mag által az alkalmazásszoftvernek biztosított kriptográfiai primitívek halmaza mindkét esetben ugyanaz. A különbség a megvalósítás módjában rejlik.
Így egy osztott kriptomaggal rendelkező séma használatakor a szoftver és a hardver interakciója a következő elv szerint történik:
- A privát kulcs használatát nem igénylő kriptográfiai primitíveket (például hash-függvény kiszámítása, elektronikus aláírás ellenőrzése stb.) a szoftver végzi el.
- A privát kulcsot használó kriptográfiai primitíveket (elektronikus aláírás létrehozása, adatok visszafejtése stb.) hardver hajtja végre.
Illusztráljuk az osztott kriptomag munkáját az elektronikus aláírás létrehozásának példáján:
- A szoftver rész kiszámítja az aláírt adatok hash függvényét, és ezt az értéket a kriptomagok közötti cserecsatornán keresztül továbbítja a hardvernek.
- A hardver rész a privát kulcs és a hash felhasználásával generálja az elektronikus aláírás értékét, és egy cserecsatornán továbbítja azt a szoftverrésznek.
- A szoftverrész visszaadja a kapott értéket az alkalmazásszoftvernek.
Az elektronikus aláírás helyességének ellenőrzésének jellemzői
Amikor az átvevő fél elektronikusan aláírt adatot kap, több ellenőrzési lépést kell végrehajtania. Az elektronikus aláírás ellenőrzésének pozitív eredménye csak akkor érhető el, ha az ellenőrzés minden szakasza sikeresen befejeződött.
1. szakasz. Az adatok integritásának és az adatok szerzőségének ellenőrzése.
A színpad tartalma. Az adatok elektronikus aláírásának ellenőrzése a megfelelő kriptográfiai algoritmussal történik. Ennek a szakasznak a sikeres befejezése azt jelzi, hogy az adatok az aláírásuk óta nem módosultak, valamint azt is, hogy az aláírás az elektronikus aláírás ellenőrzésére szolgáló nyilvános kulcsnak megfelelő privát kulccsal történt.
A színpad helye: kriptomag.
2. szakasz: Az aláíró nyilvános kulcsába vetett bizalom ellenőrzése és az elektronikus aláírás privát kulcsa érvényességi idejének ellenőrzése.
A színpad tartalma. A színpad két köztes részszakaszból áll. Az első annak meghatározása, hogy az elektronikus aláírás ellenőrzésére szolgáló nyilvános kulcs megbízható volt-e az adatok aláírásakor. A második azt határozza meg, hogy az elektronikus aláírás privát kulcsa érvényes volt-e az adatok aláírásakor. Általában előfordulhat, hogy ezeknek a kulcsoknak az érvényességi ideje nem esik egybe (például az elektronikus aláírás-ellenőrző kulcsok minősített tanúsítványainál). Az aláíró nyilvános kulcsába vetett bizalom kialakításának módjait a felek által elfogadott elektronikus dokumentumkezelési szabályok határozzák meg.
A színpad helye: alkalmazásszoftver / kriptomag.
3. szakasz. Az aláíró jogosultságának ellenőrzése.
A színpad tartalma. Az elektronikus dokumentumkezelés megállapított szabályai szerint ellenőrzik, hogy az aláíró jogosult-e a védett adatok hitelesítésére. Példaként hozzunk fel egy jogsértési helyzetet. Tegyük fel, hogy van egy szervezet, ahol minden alkalmazott rendelkezik elektronikus aláírással. A belső elektronikus dokumentumkezelő rendszer a vezetőtől kap megrendelést, de a raktárvezető elektronikus aláírásával aláírva. Ennek megfelelően egy ilyen dokumentum nem tekinthető jogosnak.
A színpad helye: alkalmazás szoftver.
A védelem tárgyának leírása során megfogalmazott feltételezések
- Az információátviteli csatornák – a kulcscsere csatornák kivételével – alkalmazásszoftveren, API-n és kriptomagon is áthaladnak.
- A nyilvános kulcsokba és (vagy) tanúsítványokba vetett bizalomra vonatkozó információk, valamint a nyilvános kulcsok tulajdonosainak jogosítványaira vonatkozó információk a nyilvános kulcstárolóban vannak elhelyezve.
- Az alkalmazásszoftver a kriptográfiai rendszermagon keresztül működik együtt a nyilvános kulcstárolóval.
Példa egy CIPF-fel védett információs rendszerre
A korábban bemutatott diagramok illusztrálásához vegyünk egy hipotetikus információs rendszert, és emeljük ki rajta az összes szerkezeti elemet.
Az információs rendszer leírása
A két szervezet úgy döntött, hogy egymás között bevezeti a jogilag jelentős elektronikus dokumentumkezelést (EDF). Ennek érdekében megállapodást kötöttek, amelyben rögzítették, hogy a dokumentumokat e-mailben továbbítják, egyúttal titkosítani kell, és minősített elektronikus aláírással kell aláírni. A dokumentumok létrehozásához és feldolgozásához a Microsoft Office 2016 csomagból származó Office programokat, a kriptográfiai védelem eszközeként pedig a CIPF CryptoPRO és a CryptoARM titkosító szoftvert kell használni.
A szervezet infrastruktúrájának leírása 1
Az 1. szervezet úgy döntött, hogy a CIPF CryptoPRO és a CryptoARM szoftvert telepíti a felhasználó munkaállomására – egy fizikai számítógépre. A titkosítási és elektronikus aláírási kulcsok a ruToken kulcs adathordozón lesznek tárolva, visszakereshető kulcs módban. A felhasználó helyileg a számítógépén készíti el az elektronikus dokumentumokat, majd titkosítja, aláírja és elküldi egy helyileg telepített e-mail kliens segítségével.
A szervezet infrastruktúrájának leírása 2
A 2. szervezet úgy döntött, hogy a titkosítási és elektronikus aláírási funkciókat egy dedikált virtuális gépre helyezi át. Ebben az esetben minden kriptográfiai művelet automatikusan végrehajtásra kerül.
Ehhez két hálózati mappa van elrendezve a dedikált virtuális gépen: „...In”, „...Out”. A partnertől nyílt formában kapott fájlok automatikusan a „…In” hálózati mappába kerülnek. Ezeket a fájlokat visszafejtjük, és az elektronikus aláírást ellenőrizzük.
A felhasználó a „…Out” mappába helyezi azokat a fájlokat, amelyeket titkosítani, alá kell írni és el kell küldeni a partnernek. A felhasználó maga készíti el a fájlokat a munkaállomásán.
A titkosítási és elektronikus aláírási funkciók végrehajtásához a CIPF CryptoPRO, a CryptoARM szoftver és egy e-mail kliens telepítve van a virtuális gépen. A virtuális gép összes elemének automatikus kezelése rendszergazdák által kifejlesztett szkriptek segítségével történik. A szkriptek munkája naplófájlba kerül.
Az elektronikus aláíráshoz szükséges kriptográfiai kulcsokat egy nem visszakereshető JaCarta GOST kulccsal ellátott tokenre helyezik, amelyet a felhasználó a helyi számítógépéhez csatlakoztat.
A tokent a felhasználó munkaállomására és a virtuális gépre telepített speciális USB-over-IP szoftverrel továbbítja a virtuális géphez.
A rendszer órája a felhasználó munkaállomásán az 1. szervezetben manuálisan lesz beállítva. A 2. szervezet dedikált virtuális gépének rendszerórája szinkronizálva lesz a hypervisor rendszer órájával, amely viszont az interneten keresztül lesz szinkronizálva a nyilvános időszerverekkel.
A CIPF szerkezeti elemeinek azonosítása
Az informatikai infrastruktúra fenti leírása alapján kiemeljük a CIPF szerkezeti elemeit, és táblázatba foglaljuk azokat.
táblázat - A CIPF modell elemeinek megfelelése az információs rendszer elemeinek
Elem neve
Szervezet 1
Szervezet 2
Alkalmazás szoftver
CryptoARM szoftver
CryptoARM szoftver
A kriptomag szoftver része
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Kriptomag hardver
nincs
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Nyilvános kulcstároló
Felhasználó munkaállomása:
- HDD;
- szabványos Windows tanúsítványtároló.
Hipervizor:
- HDD.
Virtuális gép:
- HDD;
- szabványos Windows tanúsítványtároló.
Privát kulcs tárolása
ruToken kulcshordozó visszakereshető kulcs módban működik
JaCarta GOST kulcstartó, amely nem eltávolítható kulcs módban működik
Nyilvános kulcscsere csatorna
Felhasználó munkaállomása:
- RAM.
Hipervizor:
- RAM.
Virtuális gép:
- RAM.
Privát kulcscsere csatorna
Felhasználó munkaállomása:
- USB busz;
- RAM.
nincs
Csatornacsere a kriptomagok között
hiányzik (nincs kriptomag hardver)
Felhasználó munkaállomása:
- USB busz;
- RAM;
— USB-over-IP szoftvermodul;
- hálózati felület.
A szervezet vállalati hálózata 2.
Hipervizor:
- RAM;
- hálózati felület.
Virtuális gép:
- hálózati felület;
- RAM;
— USB-over-IP szoftvermodul.
Nyissa meg az adatcsatornát
Felhasználó munkaállomása:
— bemeneti-kimeneti eszközök;
- RAM;
- HDD.
Felhasználó munkaállomása:
— bemeneti-kimeneti eszközök;
- RAM;
- HDD;
- hálózati felület.
A szervezet vállalati hálózata 2.
Hipervizor:
- hálózati felület;
- RAM;
- HDD.
Virtuális gép:
- hálózati felület;
- RAM;
- HDD.
Biztonságos adatcsere csatorna
Internet.
A szervezet vállalati hálózata 1.
Felhasználó munkaállomása:
- HDD;
- RAM;
- hálózati felület.
Internet.
A szervezet vállalati hálózata 2.
Hipervizor:
- hálózati felület;
- RAM;
- HDD.
Virtuális gép:
- hálózati felület;
- RAM;
- HDD.
Idő csatorna
Felhasználó munkaállomása:
— bemeneti-kimeneti eszközök;
- RAM;
- rendszer időzítő.
Internet.
2. szervezeti hálózat,
Hipervizor:
- hálózati felület;
- RAM;
- rendszer időzítő.
Virtuális gép:
- RAM;
- rendszer időzítő.
Vezérlőparancs átviteli csatorna
Felhasználó munkaállomása:
— bemeneti-kimeneti eszközök;
- RAM.
(A CryptoARM szoftver grafikus felhasználói felülete)
Virtuális gép:
- RAM;
- HDD.
(Automatizálási szkriptek)
Csatorna a munkaeredmények fogadására
Felhasználó munkaállomása:
— bemeneti-kimeneti eszközök;
- RAM.
(A CryptoARM szoftver grafikus felhasználói felülete)
Virtuális gép:
- RAM;
- HDD.
(Az automatizálási szkriptek naplófájljai)
Legfelső szintű biztonsági fenyegetések
magyarázatok
Feltételezések a fenyegetések lebontása során:
- Erős kriptográfiai algoritmusokat használnak.
- A kriptográfiai algoritmusokat biztonságosan használják a megfelelő működési módokban (pl. nem használják nagy mennyiségű adat titkosításához, figyelembe veszik a kulcs megengedett terhelését stb.).
- A támadók ismerik az összes használt algoritmust, protokollt és nyilvános kulcsot.
- A támadók az összes titkosított adatot elolvashatják.
- A támadók képesek reprodukálni a rendszer bármely szoftverelemét.
Bomlás
U1. A privát kriptográfiai kulcsok veszélyeztetése.
U2. Hamis adatok titkosítása a jogos feladó nevében.
U3. A titkosított adatok visszafejtése olyan személyek által, akik nem jogos címzettek az adatoknak (támadók).
U4. Jogos aláíró elektronikus aláírásának létrehozása hamis adatok mellett.
U5. Pozitív eredmény elérése a hamisított adatok elektronikus aláírásának ellenőrzéséből.
U6. Elektronikus dokumentumok hibás végrehajtásra történő átvétele az elektronikus dokumentumáramlás szervezési problémái miatt.
U7. A védett adatokhoz való jogosulatlan hozzáférés a CIPF általi feldolgozás során.
U1. A privát kriptográfiai kulcsok veszélyeztetése
U1.1. A privát kulcs lekérése a magánkulcs-tárolóból.
U1.2. Privát kulcs beszerzése a titkosítóeszköz működési környezetében lévő objektumoktól, amelyekben az ideiglenesen tartózkodhat.
Magyarázatok U1.2.
Azok az objektumok, amelyek ideiglenesen tárolhatnak privát kulcsot, a következők:
- RAM,
- ideiglenes fájlok,
- fájlcsere,
- hibernált fájlok,
- pillanatfelvételek a virtuális gépek „forró” állapotáról, beleértve a szüneteltetett virtuális gépek RAM-jának tartalmát.
U1.2.1. Privát kulcsok kinyerése a működő RAM-ból a RAM modulok lefagyasztásával, eltávolítása, majd az adatok beolvasása (freeze attack).
Magyarázatok U1.2.1.
Példa .
U1.3. Privát kulcs beszerzése privát kulcscsere csatornából.
Magyarázatok U1.3.
Ennek a fenyegetésnek a végrehajtására adunk példát .
U1.4. A titkosítási mag jogosulatlan módosítása, melynek eredményeként a magánkulcsok a támadók tudomására jutnak.
U1.5. Privát kulcs kompromittálódása a technikai információszivárgási csatornák (TCIL) használata következtében.
Magyarázatok U1.5.
Példa .
U1.6. Privát kulcs kompromittálása az információk titkos lekérésére tervezett speciális technikai eszközök (STS) („hibák”) használata következtében.
U1.7. A privát kulcsok kompromittálódása a CIPF-en kívüli tárolás során.
Magyarázatok U1.7.
Például egy felhasználó a kulcsfontosságú adathordozóit egy asztali fiókban tárolja, ahonnan a támadók könnyen lekérhetik azokat.
U2. Hamis adatok titkosítása törvényes feladó nevében
magyarázatok
Ezt a fenyegetést csak a küldő hitelesítéssel rendelkező adattitkosítási sémák esetében veszi figyelembe. Az ilyen rendszerek példáit a szabványosítási ajánlások tartalmazzák . Más kriptográfiai sémák esetében ez a fenyegetés nem létezik, mivel a titkosítás a címzett nyilvános kulcsain történik, és ezeket általában ismerik a támadók.
Bomlás
U2.1. A feladó privát kulcsának veszélyeztetése:
U2.1.1. Link: .
U2.2. Bemeneti adatok helyettesítése nyílt adatcsere-csatornában.
Megjegyzések U2.2.
Az alábbiakban példákat mutatunk be ennek a fenyegetésnek a megvalósítására. и .
U3. A titkosított adatok visszafejtése olyan személyek által, akik nem jogos címzettek (támadók)
Bomlás
U3.1. A titkosított adatok címzettjének privát kulcsainak kompromittálódása.
U3.1.1 link: .
U3.2. Titkosított adatok helyettesítése biztonságos adatcserecsatornában.
U4. Jogos aláíró elektronikus aláírásának létrehozása hamis adatok mellett
Bomlás
U4.1. A törvényes aláíró elektronikus aláírásának privát kulcsainak veszélyeztetése.
U4.1.1 link: .
U4.2. Aláírt adatok helyettesítése nyílt adatcsere-csatornában.
Megjegyzés U4.2.
Az alábbiakban példákat mutatunk be ennek a fenyegetésnek a megvalósítására. и .
U5. Pozitív eredmény elérése a hamisított adatok elektronikus aláírásának ellenőrzéséből
Bomlás
U5.1. A támadók elfognak egy üzenetet a munkaeredmények továbbítására szolgáló csatornán az elektronikus aláírás ellenőrzésének negatív eredményéről, és lecserélik egy pozitív eredményű üzenetre.
U5.2. A támadók megtámadják a tanúsítványok aláírásába vetett bizalmat (SCRIPT – minden elem szükséges):
U5.2.1. A támadók nyilvános és privát kulcsot generálnak az elektronikus aláíráshoz. Ha a rendszer elektronikus aláírási kulcstanúsítványokat használ, akkor azok egy olyan elektronikus aláírási tanúsítványt állítanak elő, amely a lehető leghasonlóbb az adat küldőjének tanúsítványához, akinek az üzenetét meg akarják hamisítani.
U5.2.2. A támadók jogosulatlan változtatásokat hajtanak végre a nyilvános kulcsok tárolójában, így biztosítva az általuk generált nyilvános kulcsnak a szükséges szintű bizalmat és jogosultságot.
U5.2.3. A támadók hamis adatokat írnak alá egy korábban generált elektronikus aláírási kulccsal, és helyezik be a biztonságos adatcsere-csatornába.
U5.3. A támadók egy törvényes aláíró lejárt elektronikus aláírási kulcsait használva hajtanak végre támadást (SCRIPT – minden elem szükséges):
U5.3.1. A támadók feltörik a jogos feladó elektronikus aláírásának lejárt (jelenleg nem érvényes) privát kulcsait.
U5.3.2. A támadók lecserélik az időátviteli csatornán az időt arra az időpontra, amikor a feltört kulcsok még érvényesek voltak.
U5.3.3. A támadók hamis adatokat írnak alá egy korábban feltört elektronikus aláírási kulccsal, és bejuttatják azt a biztonságos adatcsere-csatornába.
U5.4. A támadók egy törvényes aláíró feltört elektronikus aláírási kulcsait használva hajtanak végre támadást (SCRIPT – minden elem szükséges):
U5.4.1. A támadó másolatot készít a nyilvános kulcstárolóról.
U5.4.2. A támadók feltörik az egyik legitim feladó privát kulcsát. Észreveszi a kompromisszumot, visszavonja a kulcsokat, és a kulcs visszavonásáról szóló információ a nyilvános kulcstárolóba kerül.
U5.4.3. A támadók lecserélik a nyilvános kulcsok tárolóját egy korábban másoltra.
U5.4.4. A támadók hamis adatokat írnak alá egy korábban feltört elektronikus aláírási kulccsal, és bejuttatják azt a biztonságos adatcsere-csatornába.
U5.5. <…> az elektronikus aláírás-ellenőrzés 2. és 3. szakaszának végrehajtása során előforduló hibák miatt:
Magyarázatok U5.5.
Példát adunk ennek a fenyegetésnek a megvalósítására .
U5.5.1. Az elektronikus aláírási kulcs tanúsítványába vetett bizalom ellenőrzése csak az aláírt tanúsítvány megbízhatóságával, CRL vagy OCSP ellenőrzések nélkül.
Magyarázatok U5.5.1.
Megvalósítási példa .
U5.5.2. Amikor egy tanúsítványhoz bizalmi láncot építünk fel, a tanúsítványt kiállító hatóságok nem kerülnek elemzésre
Magyarázatok U5.5.2.
Példa az SSL/TLS-tanúsítványok elleni támadásra.
A támadók jogos tanúsítványt vásároltak az e-mailjeikhez. Ezután készítettek egy csaló webhely tanúsítványt, és aláírták a tanúsítványukkal. Ha a hitelesítő adatokat nem ellenőrzik, akkor a bizalmi lánc ellenőrzésekor az helyesnek bizonyul, és ennek megfelelően a hamis tanúsítvány is helyes lesz.
U5.5.3. Tanúsítvány-megbízhatósági lánc felépítésekor a köztes tanúsítványok visszavonása nem történik meg.
U5.5.4. A CRL-eket ritkábban frissítik, mint amennyit a hitelesítésszolgáltató kiad.
U5.5.5. Az elektronikus aláírásban való megbízásról szóló döntést azelőtt hozzák meg, hogy a tanúsítvány állapotára vonatkozó OCSP-válasz beérkezne, az aláírás generálásának időpontjánál később vagy az aláírás generálása utáni következő CRL-nél korábban benyújtott kérésre.
Magyarázatok U5.5.5.
A legtöbb CA szabályzatában a tanúsítvány visszavonásának időpontja a legközelebbi, a tanúsítvány visszavonásáról szóló információkat tartalmazó CRL kiadásának időpontja.
U5.5.6. Az aláírt adatok fogadásakor a feladóhoz tartozó tanúsítvány nem kerül ellenőrzésre.
Magyarázatok U5.5.6.
Példa támadásra. SSL-tanúsítványokkal kapcsolatban: előfordulhat, hogy a hívott szerver cím és a tanúsítvány CN mező értékének megfelelősége nem ellenőrizhető.
Példa támadásra. A támadók feltörték a fizetési rendszer egyik résztvevőjének elektronikus aláírási kulcsait. Ezt követően feltörték egy másik résztvevő hálózatát, és az ő nevében kompromittált kulcsokkal aláírt fizetési bizonylatokat küldtek a fizetési rendszer elszámolási szerverére. Ha a szerver csak a bizalmat elemzi, és nem ellenőrzi a megfelelőséget, akkor a csalárd dokumentumok jogosnak minősülnek.
U6. Elektronikus dokumentumok hibás végrehajtásra történő átvétele az elektronikus dokumentumáramlás szervezési problémái miatt.
Bomlás
U6.1. A fogadó fél nem észleli a kapott dokumentumok megkettőzését.
Magyarázatok U6.1.
Példa támadásra. A támadók elfoghatják a címzettnek továbbított dokumentumot, még akkor is, ha az kriptográfiailag védett, majd ismételten elküldheti egy biztonságos adatátviteli csatornán. Ha a címzett nem azonosítja az ismétlődéseket, akkor az összes beérkezett dokumentumot különböző dokumentumként észleli és dolgozza fel.
U7. A védett adatokhoz való jogosulatlan hozzáférés a CIPF általi feldolgozás során
Bomlás
U7.1. <…> oldalcsatornákon keresztüli információszivárgás miatt (oldalcsatornás támadás).
Magyarázatok U7.1.
Példa .
U7.2. <…> a CIPF-en feldolgozott információkhoz való jogosulatlan hozzáférés elleni védelem semlegesítése miatt:
U7.2.1. A CIPF működése a CIPF dokumentációjában leírt követelmények megsértésével.
U7.2.2. <…>, amelyet a következő helyeken található sebezhetőségek miatt hajtottak végre:
U7.2.2.1. <…> a jogosulatlan hozzáférés elleni védelem eszközei.
U7.2.2.2. <…> maga a CIPF.
U7.2.2.3. <…> a kripto-eszköz működési környezete.
Példák támadásokra
Az alábbiakban tárgyalt forgatókönyvek nyilvánvalóan tartalmaznak információbiztonsági hibákat, és csak a lehetséges támadások szemléltetésére szolgálnak.
1. forgatókönyv. Példa az U2.2 és U4.2 fenyegetések megvalósítására.
Az objektum leírása
Az AWS KBR szoftver és a CIPF SCAD Signature olyan fizikai számítógépre van telepítve, amely nem csatlakozik a számítógépes hálózathoz. Az FKN vdToken kulcshordozóként használatos a nem eltávolítható kulccsal való munka során.
Az elszámolási szabályzat feltételezi, hogy a települési szakember a munkahelyi számítógépéről az elektronikus üzeneteket tiszta szöveggel (a régi KBR munkaállomás séma) egy speciális biztonságos fájlszerverről letölti, majd egy hordozható USB flash meghajtóra írja és a KBR munkaállomásra továbbítja. ahol titkosítva vannak és aláírják. Ezt követően a szakember a biztonságos elektronikus üzeneteket továbbítja az elidegenített médiumra, majd a munkahelyi számítógépén keresztül fájlszerverre írja, ahonnan az UTA-ra, majd az Oroszországi Bank fizetési rendszerébe kerülnek.
Ebben az esetben a nyílt és védett adatok cseréjének csatornái közé tartozik: fájlszerver, szakember munkagépe és elidegenített adathordozók.
Támadás
Az illetéktelen támadók távirányító rendszert telepítenek a szakember munkahelyi számítógépére, és a fizetési megbízások (elektronikus üzenetek) átruházható adathordozóra írásakor az egyik tartalmát tiszta szöveggel helyettesítik. A szakember átutalja a fizetési megbízásokat a KBR automatizált munkahelyére, aláírja és titkosítja azokat anélkül, hogy észrevenné a helyettesítést (például repülés közbeni nagyszámú fizetési megbízás, fáradtság stb. miatt). Ezt követően a hamis fizetési megbízás a technológiai láncon áthaladva belép az Orosz Bank fizetési rendszerébe.
2. forgatókönyv. Példa az U2.2 és U4.2 fenyegetések megvalósítására.
Az objektum leírása
A telepített KBR munkaállomással, SCAD aláírással és csatlakoztatott FKN vdToken kulcshordozóval rendelkező számítógép egy erre a célra szolgáló helyiségben működik, a személyzet hozzáférése nélkül.
A számítási szakember az RDP protokollon keresztül távelérési módban csatlakozik a CBD munkaállomáshoz.
Támadás
A támadók elkapják a részleteket, amelyek segítségével a számítási szakember csatlakozik a CBD munkaállomáshoz, és dolgozik vele (például rosszindulatú kódon keresztül a számítógépén). Ezután csatlakoznak a nevében, és hamis fizetési megbízást küldenek a Bank of Russia fizetési rendszerébe.
3. forgatókönyv. Példa a fenyegetés megvalósítására U1.3.
Az objektum leírása
Tekintsük az egyik hipotetikus lehetőséget az ABS-KBR integrációs modulok megvalósítására egy új sémához (AWS KBR-N), amelyben a kimenő dokumentumok elektronikus aláírása az ABS oldalon történik. Ebben az esetben feltételezzük, hogy az ABS olyan operációs rendszer alapján működik, amelyet nem támogat a CIPF SKAD Signature, és ennek megfelelően a kriptográfiai funkcionalitás átkerül egy külön virtuális gépre - az „ABS-KBR” integrációra. modult.
A visszakereshető kulcs módban működő szokásos USB-token kulcshordozóként használatos. A kulcs adathordozónak a hypervisorhoz való csatlakoztatásakor kiderült, hogy nincsenek szabad USB portok a rendszerben, ezért úgy döntöttek, hogy az USB tokent hálózati USB hubon keresztül csatlakoztatják, és a virtuálisra telepítenek egy USB-over-IP klienst. gép, amely kommunikálna a hubbal.
Támadás
A támadók elfogták az elektronikus aláírás privát kulcsát az USB-elosztó és a hypervisor közötti kommunikációs csatornáról (az adatokat tiszta szöveggel továbbították). A titkos kulcs birtokában a támadók hamis fizetési megbízást generáltak, azt elektronikus aláírással aláírták és végrehajtásra elküldték a KBR-N automatizált munkahelyére.
4. forgatókönyv. Példa a fenyegetések megvalósítására U5.5.
Az objektum leírása
Tekintsük ugyanazt az áramkört, mint az előző forgatókönyvben. Feltételezzük, hogy a KBR-N munkaállomásról érkező elektronikus üzenetek a …SHAREIn mappába, a KBR-N munkaállomásra és tovább az Oroszországi Bank fizetési rendszerébe küldöttek pedig a …SHAREout mappába kerülnek.
Azt is feltételezzük, hogy az integrációs modul implementálásakor a visszavont tanúsítványok listái csak a kriptográfiai kulcsok újrakibocsátásakor frissülnek, és azt is, hogy a …SHAREIn mappába érkezett elektronikus üzeneteket csak az integritás-ellenőrzés és a megbízhatóság ellenőrzése szempontjából ellenőrizzük a nyilvános kulcsban. Elektronikus aláírás.
Támadás
A támadók az előző forgatókönyvben ellopott kulcsok felhasználásával a csaló ügyfél számlájára pénz beérkezéséről szóló információkat tartalmazó hamis fizetési megbízást írtak alá, és azt bevezették a biztonságos adatcsere-csatornába. Mivel nincs ellenőrzés, hogy a fizetési megbízást a Bank of Russia aláírta-e, azt végrehajtásra elfogadják.
Forrás: will.com