Hivatkozások a kutatás többi részére
- (Itt vagy)
Ez a cikk zárja a banki elektronikus tranzakciók információbiztonságával kapcsolatos cikkek sorát. Itt a szokásos fenyegetési modelleket vizsgáljuk, amelyekre hivatkoztunk a :
- .
- .
- .
- .
HÁBORSZAKASZ-FIGYELMEZTETÉS !!! Tisztelt hűséges olvasók, ez nem egy szórakoztató poszt.
A 40+ oldalas anyagok, amelyek rejtve vannak, hivatottak segíteni a munkában vagy a tanulmányok során azoknak, akik a banki szektorban dolgoznak vagy az információbiztonság területén tevékenykednek. Ezek az anyagok a kutatás végtermékei, formális stílusban íródtak. Szó szerint ez egy belső dokumentum-tervezet az IB-hez.Nos, és a szokásos — „az írásbeli információk jogellenes célú felhasználása törvény által büntetendő”. Hasznos olvasást!
Információ a kutatással most ismerkedő olvasók számára.
Miről szól a kutatás
Ön egy útmutatót olvas, amelyet az elektronikus tranzakciók biztonságáért felelős szakember számára készítettek.
A szöveg logikája
Először és a védelem objektumának leírása. Ezután a beszél arról, hogyan kell felépíteni a védelmi rendszert, és arról, hogy szükséges a fenyegetések modellezésének kialakítása. A áttekinti, hogy milyen fenyegetési modellek léteznek és hogyan alakítják azokat. A és valós támadások elemzését tartalmazza. és tartalmazza a fenyegetési modell leírását, amelyet az összes korábbi részben szereplő információk figyelembevételével alakítottak ki.
TIPIKUS FENYEGETÉSI MODEL. HÁLÓZATI KAPCSOLAT
A védelmi objektum, amelyre a fenyegetési modellt alkalmazzák (scope)
A védelmi objektum az adatok, amelyeket hálózati kapcsolaton keresztül küldenek, működő adatátviteli hálózatokon, amelyek a TCP/IP protokollhalmazon alapulnak.
Architektúra
Az architektúra elemeinek leírása:
- „Végső csomópontok” — olyan csomópontok, amelyek védett információt cserélnek.
- „Közbenső csomópontok” — az adatátviteli hálózat elemei: routerek, switch-ek, hozzáférési szerverek, proxy-szerverek és egyéb berendezések, amelyeken keresztül a hálózati kapcsolat forgalma átfolyik. Általában a hálózati kapcsolat közbenső csomópontok nélkül is működhet (közvetlenül a végső csomópontok között).
A legmagasabb szintű biztonsági fenyegetések
Dekonpozíció
F1. Jogosulatlan betekintés az átkonvertált adatokba.
F2. Jogosulatlan módosítás az odaátadott adatokban.
F3. Az átkonvertált adatok szerzői jogának megsértése.
F1. Jogosulatlan betekintés az átkonvertált adatokba
Dekonpozíció
F1.1. , végrehajtva a végső vagy közbenső csomópontokon:
F1.1.1. az adatok előzetes olvasásával a csomópont memóriájában:
F1.1.1.1. a RAM-ban.
Magyarázat F1.1.1.1-hez.
Például a csomópont hálózati stackjén feldolgozott adatok során.
F1.1.1.2. az energiafüggetlen memóriában.
Magyarázat F1.1.1.2-hez.
Például, amikor az átkonvertált adatokat cache-ben, ideiglenes fájlokban vagy swap fájlokban tárolják.
F1.2. , végrehajtva a hálózati adatátvitel külső csomópontjain:
F1.2.1. az összes csomag elfogásának módszerével, ami a csomópont hálózati interfészére érkezik:
Magyarázat F1.2.1-hez.
Minden csomag elfogása úgy történik, hogy a hálózati kártyát promiszkuitív üzemmódba állítják (promiscuous mode vezetékes adapterekhez vagy monitor mode Wi-Fi adapterekhez).
U1.2.2. a „ember középen (MiTM)“ típusú támadások végrehajtásával, de a továbbított adatok (kivéve a hálózati protokollok szolgáltatási adatait) módosítása nélkül.
U1.2.2.1. Hivatkozás: .
U1.3. , amely technikai csatornákon (TKU) keresztül történik, fizikai csomópontokról vagy kommunikációs vonalakról.
U1.4. , amely végső vagy közbenső csomópontokra specializált technikai eszközök (STK) telepítése révén történik, amelyek titkos információgyűjtésre szolgálnak.
U2. Jogosulatlanul módosított továbbított adatok
Dekonpozíció
U2.1. , végrehajtva végső vagy közbenső csomópontokon:
U2.1.1. a csomópontok tárolóeszközein található adatok olvasásával és módosításával:
U2.1.1.1. a RAM-ban:
U2.1.1.2. az energiatároló memóriában:
U2.2. , harmadik fél adathálózati csomópontjain végrehajtva:
U2.2.1. a „ember középen (MiTM)“ típusú támadásokkal és a forgalom átirányításával a támadó csomópontjára:
U2.2.1.1. A támadók által a hálózati kapcsolat megszakítására csatlakoztatott eszközök fizikai csatlakozása.
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) irányítása:
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Jogosulatlan VLAN beállítások módosítása kapcsolók vagy routerek esetében.
U2.2.1.2.2. forgalomirányítás:
U2.2.1.2.2.1. Jogosulatlan módosítások a routerek statikus forgalomirányítási táblázatában.
U2.2.1.2.2.2. A támadók által hamis útvonalak bejelentése dinamikus forgalomirányító 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év-feloldá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 csomópontfájlokban (hosts, lmhosts stb.)
U3. Jogosultság megsértése a továbbított adatokban
Dekonpozíció
U3.1. Az információ szerzőjének meghatározására szolgáló mechanizmusok semlegesítése hamis szerzői vagy adatforrást jelölő adatok megadásával:
U3.1.1. Az átadott információban található szerzői adatok módosítása.
U3.1.1.1. A továbbított adatok integritásának és szerzőségének kriptográfiai védelme semlegesítése:
U3.1.1.1.1. Hivatkozás: .
U3.1.1.2. A továbbított adatok szerzőségének védelme semlegesítése, amelyet egyszer használatos megerősítő kódokkal valósítottak meg:
U3.1.1.2.1. .
U3.1.2. A továbbított információ forrásának módosítása:
U3.1.2.1. .
U3.1.2.2. .
TIPIKUS FENYEGETÉSI MODEL. KLIEK-SZERVER ARCHITEKTÚRÁRA ÉPÜLŐ INFORMÁCIÓS RENDSZER
A védelmi objektum, amelyre a fenyegetési modellt alkalmazzák (scope)
A védett objektum egy kliens-szerver architektúrára épülő információs rendszer.
Architektúra
Az architektúra elemeinek leírása:
- „Kliens” – az a készülék, amelyen az információs rendszer kliens oldala működik.
- „Szerver” – az a készülék, amelyen az információs rendszer szerver oldala működik.
- „Adattároló” – az információs rendszer szerver infrastruktúrájának része, amely az információs rendszer által feldolgozott adatok tárolására szolgál.
- „Hálózati kapcsolat” – az információ átvitelének csatornája a Kliens és a Szerver között, amely az adatátviteli hálózaton keresztül halad. A sajátos elem modelljének részletesebb leírása található .
Korlátozások
A modellképzés során a következő korlátozásokat állapítottuk meg:
- A felhasználó az információs rendszerrel való interakciója végső időperiódusok keretein belül, munkameneteknek nevezett keretek között történik.
- Minden munkamenet elején a felhasználó azonosítása, hitelesítése és jogosultságának ellenőrzése történik.
- Minden védett információ az információs rendszer szerver oldalán tárolódik.
A legmagasabb szintű biztonsági fenyegetések
Dekonpozíció
U1. Magánszemélyek jogosulatlan cselekedetei egy érvényes felhasználó nevében.
U2. Jogosulatlan módosítás a védett információban, miközben azt az információs rendszer szerver oldala feldolgozza.
U1. Magánszemélyek jogosulatlan cselekedetei egy érvényes felhasználó nevében
Magyarázatok
Általában az információs rendszerekben a cselekvések összekapcsolása azokat végző felhasználóval a következő módon történik:
- a rendszer munkanaplóival (logs).
- adatobjektumok speciális attribútumai, amelyek tartalmazzák a létrehozó vagy módosító felhasználó adatait.
A munkamenet szempontjából ez a fenyegetés az alábbiakra bontható:
- a felhasználó munkamenetének keretein belül végrehajtott műveletek.
- a felhasználó munkamenetén kívül végrehajtott műveletek.
A felhasználói munkamenet az alábbi módokon kezdeményezhető:
- A felhasználó által.
- Gonoszindítók által.
Ezen a ponton a fenyegetés közbülső bontása a következőképpen néz ki:
U1.1. Jogosulatlan műveleteket hajtottak végre a felhasználó munkamenetének keretein belül:
U1.1.1. , amelyet a támadott felhasználó telepített.
U1.1.2. , amelyet a gonoszindítók telepítettek.
U1.2. Jogosulatlan műveletek végeztek a felhasználó munkamenetén kívül.
Információs infrastruktúrára vonatkozóan, amelyre a gonoszindítók hatással lehetnek, a közbülső fenyegetések bontása az alábbiak szerint alakul:
Elemek
Fenyegetések bontása
U1.1.1.
U1.1.2.
U1.2.
Ügyfél
U1.1.1.1.
U1.1.2.1.
Hálózati kapcsolat
U1.1.1.2.
Szerver
U1.2.1.
Dekonpozíció
U1.1. Jogosulatlan műveleteket hajtottak végre a felhasználó munkamenetének keretein belül:
U1.1.1. , amelyet a támadott felhasználó telepített:
U1.1.1.1. A gonoszindítók közvetlenül a Felhasználóból indultak:
U1.1.1.1.1 A gonoszindítók a rendszer normál hozzáférési eszközeit használták:
U1.1.1.1.1.1. A gonoszindítók a Felhasználó fizikai bemeneti-kimeneti eszközeit (billentyűzet, egér, monitor vagy mobil eszköz érintőképernyő) használták:
U1.1.1.1.1.1.1. A gonoszindítók az aktív munkamenet idején, amikor a bemeneti-kimeneti eszközök elérhetők voltak, a felhasználó távollétében léptek működésbe.
U1.1.1.1.1.2. A gonoszindítók távoli adminisztrációs eszközöket (normál vagy rosszindulatú kód által biztosított) használtak a Felhasználó irányítására:
U1.1.1.1.1.2.1. A gonoszindítók az aktív munkamenet idején, amikor a bemeneti-kimeneti eszközök elérhetők voltak, a felhasználó távollétében léptek működésbe.
U1.1.1.1.1.2.2. A gonoszindítók a felhasználó számára észlelhetetlenül működő távoli adminisztrációs eszközöket használtak.
U1.1.1.2. A gonoszindítók megtévesztették az adatokat a Felhasználó és a Szerver közötti hálózati kapcsolatban, módosítva azokat oly módon, hogy azok egy legitim felhasználó cselekedeteiként tűnjenek fel:
U1.1.1.2.1. Hivatkozás: .
U1.1.1.3. A támadó a felhasználót arra kényszerítette, hogy a megadott utasításokat kövesse, szociális mérnöki módszereket alkalmazva.
U1.1.2 <…> a támadók által telepített:
U1.1.2.1. A támadók a Klienst (és):
U1.1.2.1.1. A támadók megszüntették az információs rendszer hozzáférés-ellenőrző rendszerét:
U1.1.2.1.1.1. Link: .
U1.1.2.1.2. A támadók a rendszer hivatalos hozzáférési eszközeit használták.
U1.1.2.2. A támadók más hálózati csomópontokról tevékenykedtek, ahonnan hálózati kapcsolat lehetett létesíteni a Szerverrel (és):
U1.1.2.2.1. A támadók megszüntették az információs rendszer hozzáférés-ellenőrző rendszerét:
U1.1.2.2.1.1. Link: .
U1.1.2.2.2. A támadók nem hivatalos hozzáférési eszközöket használtak az információs rendszerhez.
Magyarázatok U1.1.2.2.2.
A támadók fel tudták telepíteni a hivatalos információs rendszer kliensét egy külső csomópontra, vagy nem hivatalos szoftvert használhatnak, amely az ügyfél és a szerver közötti hivatalos kommunikációs protokollokat megvalósítja.
U1.2 Jogosulatlan tevékenységek valósultak meg a felhasználói munkamenet keretein kívül.
U1.2.1. A támadók jogosulatlan tevékenységeket hajtottak végre, majd jogosulatlan módosításokat végeztek az információs rendszer munkafolyamatainak naplóiban vagy az adatok speciális attribútumain, azt állítva, hogy a végrehajtott tevékenységek egy legitim felhasználó által történtek.
U2. Jogosulatlan módosítás védett információkban az információs rendszer szerver oldali feldolgozása során
Dekonpozíció
U2.1. A támadók a védett információkat a hivatalos információs rendszer eszközeivel módosítják, lényegében egy legitim felhasználó nevében járva el.
U2.1.1. Link: .
U2.2. A támadók módosítják a védett információkat az információs rendszer működési módszerein kívüli adathelyek használatával.
U2.2.1. A támadók módosítják a védett információkat tartalmazó fájlokat:
U2.2.1.1. , a fájlok kezelésére szolgáló operációs rendszer által biztosított mechanizmusokat használva.
U2.2.1.2. a fájlok helyreállításának provokálásával egy jogosulatlanul 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ót (és):
U2.2.2.1. A támadók semlegesítik az adatbázis-kezelő rendszer hozzáférés-ellenőrzési rendszerét:
U2.2.2.1.1. Hivatkozás: .
U2.2.2.2. A támadók az adatkezeléshez használt szabványos interfészeket alkalmazzák az információ módosításához.
U2.3. A támadók jogosulatlan módosítással módosítják a védett információt a feldolgozásért felelős szoftver működése.
U2.3.1. A szoftver forráskódja módosításra kerül.
U2.3.1. A szoftver gépi kódja módosításra kerül.
U2.4. A támadók a védett információt a informatikai rendszer szoftverének sebezhetőségeit kihasználva módosítják.
U2.5. A támadók a védett információt az informatikai rendszer háttérszerverei közötti átvitel során módosítják (például az adatbázis-szerver és az alkalmazás-szerver között):
U2.5.1. Hivatkozás: .
TÍPUS MODEL OF THREATS. Hozzáférés-ellenőrzési RENDSZER
A védelmi objektum, amelyre a fenyegetési modellt alkalmazzák (scope)
A védendő objektum, amelyre ez a fenyegetési modell vonatkozik, megfelel a fenyegetési modell védendő objektumának: „Tipikus fenyegetési modell. Információs rendszer, amely kliens-szerver architektúrára épül”.
A felhasználói hozzáférés-ellenőrző rendszeren azt az informatikai rendszer komponenst értjük, amely a következő funkciókat valósítja meg:
- A felhasználók azonosítása.
- A felhasználók hitelesítése.
- A felhasználók jogosultsági szintjének meghatározása.
- A felhasználók tevékenységeinek naplózása.
A legmagasabb szintű biztonsági fenyegetések
Dekonpozíció
U1. Jogosulatlan munkamenet létesítése egy törvényes felhasználó nevében.
U2. Jogosulatlan felhasználói jogosultságok növelése az informatikai rendszerben.
U1. Jogosulatlan munkamenet létesítése egy törvényes felhasználó nevében
Magyarázatok
A fenyegetés decompozíciója általában a felhasználói azonosítási és hitelesítési rendszerek típusától függ.
Ebben a modellben csak a felhasználók azonosítási és hitelesítési rendszere lesz tárgyalva, amely szöveges bejelentkezési név és jelszó használatával működik. Ezzel együtt feltételezzük, hogy a felhasználó bejelentkezési neve nyilvános információ, amely a támadók számára is ismert.
Dekonpozíció
U1.1. <…> a hitelesítő adatok kompromittálása révén:
U1.1.1. A támadók kompromittálták a felhasználó hitelesítő adatait a tárolásuk során.
Pontosítás U1.1.1.
Például a hitelesítő adatok kerülhettek egy matrica mögé, amely a monitorra volt ragasztva.
U1.1.2. A felhasználó véletlenül vagy szándékosan átadta a hozzáférési adatokat a támadóknak.
U1.1.2.1. A felhasználó hangosan mondta a hitelesítő adatokat beírás közben.
U1.1.2.2. A felhasználó szándékosan átadta a hitelesítő adatait:
U1.1.2.2.1. <…> munkatársaknak.
Pontosítás U1.1.2.2.1.
Például azért, hogy ők helyettesíthessék őt betegség alatt.
U1.1.2.2.2. <…> a munkáltató partnereinek, akik az információs infrastruktúra objektumain dolgoznak.
U1.1.2.2.3. <…> harmadik feleknek.
Pontosítás U1.1.2.2.3.
Az egyik, de nem az egyetlen módja ennek a fenyegetésnek a megvalósítására a támadók által a szociális mérnöki módszerek alkalmazása.
U1.1.3. A támadók a számára a hitelesítő adatokat a próbálkozás módszerével állapították meg:
U1.1.3.1. <…> a standard hozzáférési mechanizmusok alkalmazásával.
U1.1.3.2. <…> a korábban elfogott kódok (például jelszavak hash-jei) segítségével tárolt hitelesítő adatokra.
U1.1.4. A támadók kártékony kódot használtak a felhasználó hitelesítő adatainak elfogására.
U1.1.5. A támadók kiemelték a hitelesítő adatokat az Ügyfél és a Szerver közötti hálózati kapcsolatból:
U1.1.5.1. Hivatkozás: .
U1.1.6. A támadók kiemelték a hitelesítő adatokat a rendszerfigyelő nyilvántartásokból:
U1.1.6.1. <…> videotájékoztató rendszerekből (ha a munka során rögzítették a billentyűleütéseket).
U1.1.6.2. <…> a munkavállalók számítógépen végzett tevékenységeit ellenőrző rendszerekből.
Pontosítás U1.1.6.2.
Egy példa az ilyen rendszerre — .
U1.1.7. A támadók a hitelesítő adatokat a továbbításuk folyamatának hiányosságai miatt kompromittálták.
Pontosítás U1.1.7.
Például a jelszavak nyílt szövegben történő továbbítása e-mailen.
U1.1.8. A támadók megszerezték a hitelesítő adatokat a felhasználó munkamenetének megfigyelésével távoli irányítási rendszerekkel.
U1.1.9. A támadók a hitelesítő adatokat technikai csatornákon (TKUI) bekövetkezett kiszivárgás révén szerezték meg:
U1.1.9.1. A támadók észrevették, ahogy a felhasználó beírja a hitelesítő adatokat a billentyűzeten:
U1.1.9.1.1 A támadók közvetlen közelben voltak a felhasználóhoz, és saját szemükkel látták a hitelesítő adatok beírását.
Magyarázat U1.1.9.1.1
Ilyen esetek lehetnek a munkatársak cselekedetei, vagy ha a felhasználó billentyűzetét a szervezeti látogatók is láthatják.
U1.1.9.1.2 A támadók kiegészítő technikai eszközöket használtak, mint például távcsövet vagy drónt, és látták a hitelesítő adatok beírását az ablakon keresztül.
U1.1.9.2. A támadók a hitelesítő adatokat a billentyűzet és a számítógép rendszergazdai egysége közötti rádióforgalom rögzítésével szerezték meg, ha azokat vezeték nélküli interfészen (például Bluetooth) csatlakoztatták.
U1.1.9.3. A támadók a hitelesítő adatokat a mellékes elektromágneses sugárzás és interferenciák (PÉMINS) csatornáján való kiszivárgással szerezték meg.
Magyarázat U1.1.9.3.
Támadási példák és .
U1.1.9.4. A támadó a hitelesítő adatok billentyűzeten való beírását különleges technikai eszközök (STS) révén figyelte meg, amelyek információk titkos rögzítésére szolgálnak.
Magyarázat U1.1.9.4.
Példák .
U1.1.9.5. A támadók a hitelesítő adatokat a billentyűzeten való beírás során a Wi-Fi jel elemzésével szerezték meg, amelyet a felhasználó billentyűlenyomása modulál.
Magyarázat U1.1.9.5.
Példa
támadásra .
Magyarázat U1.1.9.6.
U1.1.9.7. A támadók a mobil eszköz billentyűzetének beírását az accelerometer adatok elemzésével figyelték meg.
támadásra .
Magyarázat U1.1.9.7.
U1.1.10. , előzetesen a Kliensek által mentett.
támadásra .
Magyarázat U1.1.10.
Például a felhasználó mentheti a böngészőjében a felhasználónevet és a jelszót egy adott weboldalhoz való hozzáféréshez.
U1.1.11. A támadók a hitelesítő adatokat a felhasználói hozzáférések visszavonásának folyamatának hiányosságai miatt kompromittálták.
Magyarázat U1.1.11.
Magyarázat U1.1.11.
Például, a felhasználó elbocsátása után a fiókjai nem maradtak zárolva.
U1.2. <…> a hozzáférés-ellenőrzési rendszer sebezhetőségeinek kihasználásával.
U2. Jogosulatlan felhasználói jogosultságemelés az információs rendszerben.
Dekonpozíció
U2.1 <…> jogosulatlan adatmódosítások végrehajtásával, amelyek a felhasználói jogosultságokkal kapcsolatos információkat tartalmaznak.
U2.2 <…> a hozzáférés-ellenőrzési rendszer sebezhetőségeinek kihasználásával.
U2.3. <…> a felhasználói hozzáférés-vezérlés folyamatának hiányosságai miatt.
Magyarázatok U2.3.
Példa 1. A felhasználónak nagyobb hozzáférést biztosítottak, mint amire a munkájához szüksége volt.
Példa 2. A felhasználó más pozícióra való áthelyezése után az előzőleg megadott hozzáférési jogok nem lettek visszavonva.
TIPIKUS FENYEGETÉSI MODELL. INTEGRÁCIÓS MODUL
A védelmi objektum, amelyre a fenyegetési modellt alkalmazzák (scope)
Az integrációs modul egy információs infrastruktúra objektumok csoportja, amely az információcserét szervezi az információs rendszerek között.
Figyelembe kell venni, hogy a vállalati hálózatokban nem mindig lehetséges egyértelműen elválasztani egymástól az egyes információs rendszereket, így az integrációs modult a belső komponensek közötti kapcsolattartó elemnek is tekinthetjük egy információs rendszeren belül.
Architektúra
A generalizált integrációs modul sémája a következőképpen néz ki:
Az architektúra elemeinek leírása:
- „Csere-szerver (CS)” – csomópont / szolgáltatás / összetevő az információs rendszerben, amely adatcserét végez egy másik információs rendszerrel.
- „Közvetítő” – csomópont / szolgáltatás, amely az információs rendszerek közötti interakció megszervezésére szolgál, de nem része azoknak.
Példák „Közvetítőkre” példák lehetnek e-mail szolgáltatások, vállalati szolgáltatási buszok (enterprise service bus / SoA-architektúra), harmadik fél fájlszerverei stb. Általánosságban az integrációs modul nem feltétlenül tartalmaz „Közvetítőket”. - „Adatfeldolgozó szoftver” – a kommunikációs protokollokat és az adatformátumok átalakítását megvalósító programok összessége.
Például, az UFEBS formátumból ABS formátumba történő átalakítás, az üzenetek státuszának megváltoztatása az átvitel során stb. - „Hálózati kapcsolat” megfelel a tipikus fenyegetési modell „Hálózati kapcsolat” objektumának. A fent látható séma egyes hálózati kapcsolatai nem is létezhetnek.
Integrációs modulok példái
1. ábra. Az ABS és az ARM KBR integrációja egy külső fájlszerveren keresztül
A kifizetések teljesítéséhez a bank felhatalmazott munkatársa az ABS-ből elektronikus kifizetési dokumentumokat tölt le, és elmenti azokat egy fájlba (saját formátumban, például SQL-dump) a fájlszerver egy hálózati mappájába (…SHARE). Ezt a fájlt egy átjáró script segítségével átalakítják UFEBF formátumú fájlok sorozatává, amelyeket az ARM KBR olvas be.
Ezután a felhatalmazott munkatárs — az ARM KBR felhasználója — titkosítja és aláírja a megkapott fájlt, majd elküldi a Bank of Russia kifizetési rendszerének.
A Bank of Russia-tól érkező kifizetések beérkezésekor az ARM KBR végrehajtja azok visszafejtését és az elektronikus aláírás ellenőrzését, majd UFEBF formátumban egy fájlszerverre menti őket. A kifizetési dokumentumok ABS-be történő importálása előtt a UFEBF formátumát átjáró script segítségével ABS formátumra alakítják.
Tegyük fel, hogy ezen a diagramon az ABS egy fizikai szerveren működik, az ARM KBR egy dedikált számítógépen, míg az átjáró script egy fájlszerveren fut.
A vizsgált séma objektumainak megfelelősége az integrációs modul modell elemeivel:
Az ABS oldaláról érkező csere szerverek – ABS szerver.
Az ARM KBR oldaláról érkező csere szerverek – ARM KBR számítógép.
„Közvetítő” – Külső fájlszerver.
„Adatfeldolgozó szoftver” – Átjáró script.
2. ábra. Az ABS és az ARM KBR integrációja közös hálózati mappa létrehozásával az ARM KBR-en a kifizetésekkel
Minden hasonló az 1. ábrához, de külön fájlszerver nem használható, ehelyett a kifizetések elektronikus dokumentumait tartalmazó hálózati mappa (…SHARE) az ARM KBR számítógépén található. Az átjáró script szintén az ARM KBR-en működik.
A vizsgált séma objektumainak megfelelősége az integrációs modul modell elemeivel:
Hasonló az 1. ábrához, de „Közvetítő” nem használható.
3. ábra. Az ABS és az ARM KBR-N integrációja az IBM WebSphere MQ-n keresztül és az elektronikus dokumentumok aláírása "az ABS oldalán"
Az ABS olyan platformon működik, amelyet az SKZSI SKAD Signature nem támogat. A kimenő elektronikus dokumentumok aláírását egy speciális elektronikus aláíró szerveren végzik (EP szerver). Ez a szerver ellenőrzi az Orosz Banktól érkező dokumentumok elektronikus aláírását.
Az ABS elmenti az EP szerverre a kifizetési dokumentumokat tartalmazó fájlt saját formátumában.
Az EP szerver a konverter szkript segítségével átkonvertálja a fájlt UFBBS formátumú elektronikus üzenetekké, majd az elektronikus üzeneteket aláírják és átadják az IBM WebSphere MQ-nak.
A KBR-N ARM az IBM WebSphere MQ-hoz fordul, és ott megkapja az aláírt fizetési üzeneteket, amelyeket az arra jogosult munkatárs — a KBR ARM felhasználója — titkosít, majd továbbít a Orosz Bank fizetési rendszerébe.
Az Orosz Banktól érkező kifizetések esetén a KBR-N ARM dekriptálja ezeket és ellenőrzi az elektronikus aláírást. A sikeresen feldolgozott kifizetések, mint dekriptált és aláírt UFBBS formátumú elektronikus üzenetek átkerülnek az IBM WebSphere MQ-ba, ahonnan az EP szerver megkapja őket.
Az EP szerver ellenőrzi a beérkezett kifizetések elektronikus aláírását, és elmenti őket ABS formátumú fájlba. Ezt követően az arra jogosult munkatárs — az ABS felhasználója — a megszerzett fájlt a megszokott módon feltölti az ABS-be.
A vizsgált séma objektumainak megfelelősége az integrációs modul modell elemeivel:
„ABS oldalról történő csere szerver” – ABS szerver.
„KBR ARM oldalról történő csere szerver” — KBR ARM számítógép.
„Közvetítő” – EP szerver és IBM WebSphere MQ.
„Adatfeldolgozó szoftver” – konverter szkript, SKZI SKAD Aláírás az EP szerveren.
4. ábra. A DBO szerver és az ABS integrációja a dedikált csere szerver által biztosított API-n keresztül
Tegyük fel, hogy a bankban több távoli banki szolgáltató (DBO) rendszer működik:
- „Internet Bank-Kliens” magánszemélyeknek (IKB FL);
- „Internet Bank-Kliens” jogi személyeknek (IKB JL).
Az információbiztonság érdekében az ABS és a DBO rendszerek közötti összes interakciót egy dedikált csereszerveren keresztül végzik, amely az „ABS” információs rendszer keretein belül működik.
Ezután megvizsgáljuk az IKB JL DBO rendszer és az ABS közötti interakció folyamatát.
A DBO szervernek, miután a megfelelő módon hitelesített ügyféltől megkapta a fizetési megbízást, ennek alapján létre kell hoznia a megfelelő dokumentumot az ABS-ben. Ehhez az API segítségével az információt a csereszervernek továbbítja, amely aztán beviszi az adatokat az ABS-be.
Ha a kliens számláján lévő egyenleg megváltozik, az ABS elektronikus értesítéseket generál, amelyeket a csereszerveren keresztül a DBO szerverre továbbítanak.
A vizsgált séma objektumainak megfelelősége az integrációs modul modell elemeivel:
„DBO oldalról történő csere szerver” – DBO IKB JL szerver.
„ABS oldalról történő csere szerver” – csere szerver.
„Közvetítő” – hiányzik.
„Adatfeldolgozó szoftver” – A DBO szerver olyan összetevői, amelyek felelősek a csere szerver API-jának használatáért; az ABS API-jának használatáért felelős csereszerver összetevői.
A legmagasabb szintű biztonsági fenyegetések
Dekonpozíció
1. A rosszindulatú felek által hamis információk infiltrálása az integrációs modulon keresztül.
1. A rosszindulatú felek által hamis információk infiltrálása az integrációs modulon keresztül
Dekonpozíció
1.1. A jogos adatok illetéktelen módosítása a hálózati kapcsolatokon keresztül történő továbbítás során:
1.1.1 Hivatkozás: .
1.2. Hamis adatok továbbítása a kommunikációs csatornákon egy jogos résztvevő nevében:
1.1.2 Hivatkozás: .
1.3. A jogos adatok illetéktelen módosítása az információcsere szerverein vagy közvetítőkön történő feldolgozás során:
1.3.1. Hivatkozás: .
1.4. Hamis adatok létrehozása az információcsere szerverein vagy közvetítőkön a jogos résztvevő nevében:
1.4.1. Hivatkozás:
1.5. Adatok illetéktelen módosítása azok feldolgozása során adatfeldolgozó szoftver segítségével:
1.5.1. a rosszindulatú felek által az adatfeldolgozó szoftver beállításainak (konfigurációjának) illetéktelen módosításával.
1.5.2. a rosszindulatú felek által a feldolgozó szoftver végrehajtó fájljainak illetéktelen módosításával.
1.5.3. a rosszindulatú felek általi interaktív irányítás révén a feldolgozó szoftver működése felett.
TIPIKUS FENYEGETÉSI MODELL. AZ INFORMÁCIÓ VÉDELMÉT SZOLGÁLÓ KRIPTOGRÁFIAI RENDSZER
A védelmi objektum, amelyre a fenyegetési modellt alkalmazzák (scope)
A védett objektum a kriptográfiai információvédelmi rendszer, amelyet az információs rendszer biztonságának biztosítására használnak.
Architektúra
Bármely információs rendszer alapját a célfunkcióit megvalósító alkalmazásprogramok (szoftverek) képezik.
A kriptográfiai védelem általában úgy valósul meg, hogy az alkalmazás szoftver üzleti logikájából hívják meg a kriptográfiai primitíveket, amelyek speciális könyvtárakba - kripto-nyelvekbe - kerülnek.
A kriptográfiai primitívek közé tartoznak az alacsony szintű kriptográfiai funkciók, mint például:
- adatblok titkosítása / visszafejtése;
- elektronikus aláírás létrehozása / ellenőrzése adatblokkon;
- adatblokk hash-funkciójának kiszámítása;
- kulcsinformációk generálása / feltöltése / letöltése;
- stb.
A kriptográfiai primitívek alkalmazási logikájával valósítja meg a magasabb szintű funkcionalitást:
- fájlt titkosítani a kiválasztott fogadókulcsokkal;
- védett hálózati kapcsolat létrehozása;
- a digitális aláírás ellenőrzésének eredményeiről tájékoztatás;
- stb.
Az üzleti logika és a kriptomag közötti kölcsönhatás végezhető:
- közvetlenül, az üzleti logika által a kriptográfiai primitívek hívásával a kriptomag dinamikus könyvtáraiból (.DLL – Windows, .SO – Linux);
- közvetetten, a kriptográfiai interfészeken – wrapper-eken keresztül, például MS Crypto API, Java Cryptography Architecture, PKCS#11 stb. Ekkor az üzleti logika a kriptointerfészt hívja, amely továbbítja a hívást a megfelelő kriptomaghoz, amelyet ebben az esetben kriptoszolgáltatónak neveznek. A kriptográfiai interfészek használata lehetővé teszi az alkalmazási szoftver számára, hogy elvonatkoztasson a konkrét kriptográfiai algoritmusoktól és rugalmasabb legyen.
Két tipikus sémát lehet kiemelni a kriptomag szervezésére:
1. séma – Monolitikus kriptomag
2. séma – Megosztott kriptomag
A megadott sémák elemei lehetnek külön modulok, amelyek egy számítógépen működnek, vagy hálózati szolgáltatások, amelyek számítási hálózaton belül működnek együtt.
Az 1. séma szerint felépített rendszerek használatakor az alkalmazási szoftver és a kriptomag egy egységes kriptográfiai eszköz üzemeltetési környezetén (СФК) belül működnek, például ugyanazon a számítógépen, ugyanazon operációs rendszer alatt. A rendszer felhasználója jellemzően a működési környezet keretein belül más programokat is futtathat, beleértve a rosszindulatú kódot tartalmazókat is. Ilyen körülmények között komoly kockázat áll fenn a titkos kriptográfiai kulcsok kiszivárgására.
A kockázat minimalizálása érdekében a 2. sémát alkalmazzák, amelyben a kriptomag két részre oszlik:
- Az első rész, az alkalmazási szoftverrel együtt, megbízhatatlan környezetben működik, ahol rosszindulatú kód fertőzésének kockázata áll fenn. Ezt a részt nevezzük 'programrésznek'.
- A második rész egy megbízható környezetben működik egy dedikált eszközön, amely zárt kulcsok tárolására is képes. Ezt a részt ezután „hardveres rész”-nek nevezzük.
A kriptográfiai mag szoftveres és hardveres részekre való bontása meglehetősen önkényes. A piacon léteznek rendszerek, amelyek a megosztott kriptográfiai mag elvére épülnek, de a „hardveres” részük virtuális gép képként jelenik meg — virtual HSM ().
A kriptográfiai mag mindkét része között a kapcsolat úgy valósul meg, hogy a zárt kriptográfiai kulcsok soha nem kerülnek át a szoftveres részbe, így nem lophatók el kártékony kód által.
A kapcsolatkezelő felület (API) és a kriptográfiai primitívák készlete, amelyeket a kriptográfiai mag az alkalmazások számára biztosít, mindkét esetben azonos. A különbség a megvalósítás módjában rejlik.
Így a megosztott kriptográfiai mag sémája esetén a szoftveres és hardveres rész közötti kapcsolat a következő elv szerint valósul meg:
- A zárt kulcs használatát nem igénylő kriptográfiai primitívák (például hash-funkciók számítása, digitális aláírás ellenőrzése stb.) a szoftveres rész által hajtódnak végre.
- A zárt kulcsot használó kriptográfiai primitívák (digitális aláírás létrehozása, adatok visszafejtése stb.) a hardveres rész által hajtódnak végre.
Illusztráljuk a megosztott kriptográfiai mag működését a digitális aláírás létrehozásának példáján:
- A szoftveres rész kiszámítja az aláírandó adatok hash-funkcióját, és a kriptográfiai magok közötti csatornán átadja ezt az értéket a hardveres résznek.
- A hardveres rész a zárt kulcsot és a hash-t használva létrehozza a digitális aláírás értékét, és a csatornán keresztül visszaküldi azt a szoftveres résznek.
- A szoftveres rész visszaadja a kapott értéket az alkalmazásnak.
A digitális aláírás érvényességének ellenőrzésének jellemzői
Amikor a fogadó fél adatokat kap, amelyeket digitális aláírás hitelesít, több ellenőrzési lépést kell végrehajtania. A digitális aláírás ellenőrzésének pozitív eredménye csak akkor érhető el, ha az összes ellenőrzési lépést sikeresen lebonyolítják.
1. lépés. Az adatok sértetlenségének és szerzőjének ellenőrzése.
A lépés tartalma. A data electronic signature verification is conducted using the corresponding cryptographic algorithm. Successfully passing this stage indicates that the data has not been modified since it was signed, and that the signature was generated by the private key corresponding to the public key used for verification.
Location of stage execution: crypto core.
Stage 2. Trust control for the signer's public key and verification of the validity period of the electronic signature's private key.
A lépés tartalma. The stage consists of two intermediate sub-stages. In the first, it is established whether the public key used for electronic signature verification was trusted at the time of data signing. In the second, it is determined whether the private key for the electronic signature was valid at the time of signing. Generally, the validity periods of these keys may not coincide (for example, for qualified certificates of public key verification). The methods for establishing trust in the signer's public key are determined by the rules of electronic document flow adopted by the interacting parties.
Location of stage execution: application software / crypto core.
Stage 3. Control over the signer's powers.
A lépés tartalma. According to established electronic document flow rules, it is checked whether the signer had the right to certify the protected data. For example, consider a situation involving breach of authority. Suppose there is an organization where all employees have an electronic signature. An order from a supervisor is received in the internal electronic document flow system, but it is signed with the electronic signature of the warehouse manager. Accordingly, such a document cannot be considered legitimate.
Location of stage execution: application software.
Assumptions made when describing the protection object
- Information transmission channels, except for key exchange channels, also pass through application software, APIs, and the crypto core.
- Information about trust in public keys and/or certificates, as well as information about the authority of the owners of public keys, is stored in a public key repository.
- Application software interacts with the public key repository through the crypto core.
Example of an information system protected by cryptographic protection means.
A hipotetikus információs rendszer áttekintésére, a korábban bemutatott sémák illusztrálása érdekében kiemeljük az összes strukturális elemet.
Az információs rendszer leírása
Két szervezet úgy döntött, hogy jogilag releváns elektronikus dokumentumforgalmat (EDD) vezet be egymás között. Ehhez megállapodást kötöttek, amelyben rögzítették, hogy a dokumentumokat elektronikus úton, titkosítva és minősített elektronikus aláírással ellátva kell átadni. A dokumentumok létrehozásához és kezeléséhez a Microsoft Office 2016 csomag irodai programjait kell használni, míg a kriptográfiai védelemhez a KryptoPRO és a CryptoARM titkosító szoftvereket kell alkalmazni.
1. szervezet infrastruktúrájának leírása
Az 1. szervezet úgy döntött, hogy a KryptoPRO és a CryptoARM szoftvert egy felhasználói ARM-ra — fizikai számítógépre telepíti. A titkosítási és elektronikus aláírási kulcsokat a ruToken kulcstartón kell tárolni, amely kihúzható kulcs üzemmódban működik. A felhasználó helyben készíti el az elektronikus dokumentumokat a számítógépén, ezután titkosítja, aláírja és a helyben telepített levelezőkliense segítségével küldi el azokat.
2. szervezet infrastruktúrájának leírása
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. Mindezeket a kriptográfiai műveleteket automatikus módban végzik el.
Ehhez a dedikált virtuális gépen két hálózati mappa került létrehozásra: "…In", "…Out". A "…In" mappába automatikusan kerülnek az ellenféltől érkezett, nyílt formában lévő fájlok. Ezeket a fájlokat titkosítják, és ellenőrzik rajtuk az elektronikus aláírást.
A "…Out" mappába a felhasználó helyezi el azokat a fájlokat, amelyeket titkosítani, aláírni és az ellenfélnek el kell küldeni. A felhasználó az ARM-ján készíti el ezeket a fájlokat.
A titkosítási és elektronikus aláírási funkciók teljesítéséhez a virtuális gépre telepítve van a KryptoPRO, a CryptoARM szoftver és a levelezőklient. A virtuális gép összes elemének automatikus irányítását a rendszeradminisztrátorok által kidolgozott szkriptek végzik. A szkriptek működése naplózásra kerül a naplófájlokba.
A digitális aláírás kriptográfiai kulcsai a JaCarta ГОСТ, visszavonhatatlan kulcsos tokenen fognak tárolódni, amelyet a felhasználó csatlakoztatni fog a saját számítógépéhez.
A tokent specialistikus USB-over-IP szoftverek segítségével fogják átjuttatni a virtuális gépre, amelyek a felhasználó munkahelyén és a virtuális gépen lesznek telepítve.
A felhasználó munkahelyén lévő rendszeróra kézi módon lesz beállítva. A második szervezetbeli virtuális gép rendszerórái a hipervizor rendszeróráival fognak szinkronizálódni, amelyek ezután az interneten keresztül az időszolgáltatók nyilvános szervereivel történnek.
A SZKZI szerkezeti elemeinek kiemelése
A fentiekben ismertetett IT-infrastruktúra alapján kiemeljük a SZKZI szerkezeti elemeit és rögzítjük egy táblázatba.
Táblázat — A SZKZI modell elemeinek megfeleltetése az informatikai rendszerek elemeivel
Elem megnevezése
1. szervezet
2. szervezet
Alkalmazott szoftver
CryptoARM szoftver
CryptoARM szoftver
A kriptomag program része
CryptoPRO CSP SZKZI
CryptoPRO CSP SZKZI
A kriptomag hardver része
nincs
JaCarta ГОСТ
API
MS CryptoAPI
MS CryptoAPI
Nyilvános kulcsok tárolója
Felhasználó munkahelye:
— merevlemez;
— Windows tanúsítványok szabványos tárolója.
Hipervizor:
— merevlemez.
Virtuális gép:
— merevlemez;
— Windows tanúsítványok szabványos tárolója.
Zárt kulcsok tárolója
ruToken kulcstartó, eltávolítható kulcs üzemmódban működik
JaCarta ГОСТ kulcstartó, visszavonhatatlan kulcs üzemmódban működik
Nyilvános kulcsok átvitelének csatornája
Felhasználó munkahelye:
— RAM.
Hipervizor:
— RAM.
Virtuális gép:
— RAM.
Zárt kulcsok átvitelének csatornája
Felhasználó munkahelye:
— USB busz;
— RAM.
nincs
Csatorna a kriptomagok között
nincs (nincs a kriptomag hardver része)
Felhasználó munkahelye:
— USB busz;
— RAM;
— USB-over-IP szoftvermodul;
— hálózati interfész.
A második szervezet vállalati hálózata.
Hipervizor:
— RAM;
— hálózati interfész.
Virtuális gép:
— hálózati interfész;
— RAM;
— USB-over-IP szoftvermodul.
Nyilvános adatok átvitelének csatornája
Felhasználó munkahelye:
— bemeneti-kimeneti eszközök;
— RAM;
— merevlemez.
Felhasználó munkahelye:
— bemeneti-kimeneti eszközök;
— RAM;
— merevlemez;
— hálózati interfész.
A második szervezet vállalati hálózata.
Hipervizor:
— hálózati interfész;
— RAM;
— merevlemez.
Virtuális gép:
— hálózati interfész;
— RAM;
— merevlemez.
Védett adatok átvitelének csatornája
Internet.
Az első szervezet vállalati hálózata.
Felhasználó munkahelye:
— merevlemez;
— RAM;
— hálózati interfész.
Internet.
A második szervezet vállalati hálózata.
Hipervizor:
— hálózati interfész;
— RAM;
— merevlemez.
Virtuális gép:
— hálózati interfész;
— RAM;
— merevlemez.
Időátviteli csatorna
Felhasználó munkahelye:
— bemeneti-kimeneti eszközök;
— RAM;
— rendszeridőmérő.
Internet.
A második szervezet vállalati hálózata,
Hipervizor:
— hálózati interfész;
— RAM;
— rendszeridőmérő.
Virtuális gép:
— RAM;
— rendszeridőmérő.
A vezérlőparancsok átvitelének csatornája
Felhasználó munkahelye:
— bemeneti-kimeneti eszközök;
— RAM.
(CryptoARM szoftver grafikus felhasználói felülete)
Virtuális gép:
— RAM;
— merevlemez.
(Automatizálási szkriptek)
Az eredmények fogadásának csatornája
Felhasználó munkahelye:
— bemeneti-kimeneti eszközök;
— RAM.
(CryptoARM szoftver grafikus felhasználói felülete)
Virtuális gép:
— RAM;
— merevlemez.
(Automatizálási szkriptek munkanaplói)
A legmagasabb szintű biztonsági fenyegetések
Magyarázatok
Feltételezések a fenyegetések dekompozíciójának során:
- Tartós kriptográfiai algoritmusokat használnak.
- A kriptográfiai algoritmusokat biztonságos módon, a megfelelő működési módokban használják (például, nincs alkalmazva nagy mennyiségű adat titkosítására, figyelembe véve a kulcsra vonatkozó megengedett terhelést stb.).
- A támadók számára ismertek az alkalmazott algoritmusok, protokollok és nyilvános kulcsok.
- A támadók számára az összes titkosított adat olvashatóvá válik.
- A támadók képesek bármely szoftverelemet reprodukálni a rendszerben.
Dekonpozíció
U1. A titkos kulcsok kompromittálása.
U2. Hamis adatok titkosítása egy jogszerű feladó nevében.
U3. Titkosított adatok visszafejtése olyan személyek által, akik nem jogszerű címzettek (támadók).
U4. Egy jogszerű aláíró elektronikus aláírásának létrehozása hamis adatokra.
U5. Pozitív eredmény elérése a hamis adatok elektronikus aláírásának ellenőrzésekor.
U6. Elektronikus dokumentumok téves elfogadása végrehajtásra az elektronikus dokumentumkezelés szervezeti problémái miatt.
U7. Nem engedélyezett betekintés a védett adatokba azok feldolgozása során a KTZK által.
U1. A titkos kulcsok kompromittálása
U1.1. A titkos kulcs megszerzése a titkos kulcsok tárolójából.
U1.2. A titkos kulcs megszerzése a kriptoeszköz működési környezetének objektumaiból, ahol az ideiglenesen tartózkodhat.
U1.2. magyarázatai.
A titkos kulcs ideiglenes tárolására alkalmas objektumok közé tartozik:
- RAM,
- ideiglenes fájlok,
- swap fájlok,
- hibernálási fájlok,
- a virtuális gépek "forró" állapotának pillanatképeinek fájljai, beleértve a virtuális gépek RAM tartalmának fájljait, amelyek szüneteltetve lettek.
U1.2.1. Titkos kulcsok kiemelése a működő RAM-ból a RAM modulok fagyasztásának révén, azok kinyerése, majd az adatok olvasása (freeze attack).
U1.2.1. magyarázatai.
támadásra .
U1.3. A titkos kulcs megszerzése a titkos kulcsok cseréjének csatornájáról.
U1.3. magyarázatai.
E veszély megvalósításának példáját alább található .
U1.4. A kriptoalma nem engedélyezett módosítása, amelynek következtében a titkos kulcsok a támadók számára ismertté válnak.
1.5. A zárt kulcs kompromittálása információszivárgásos technikai csatornák (TCS) használatának következtében.
Magyarázat 1.5.
támadásra .
1.6. A zárt kulcs kompromittálása a titkos információk lehallgatására ("bogarak") szolgáló speciális műszaki eszközök (SME) használatának következtében.
1.7. A zárt kulcsok kompromittálása azok tárolása során, az SKZI-n kívül.
Magyarázat 1.7.
Például, a felhasználó az adatkulcsait az íróasztal fiókjában tárolja, ahonnan ezek könnyen kivehetők a támadók által.
2. Hamis adatok titkosítása a legitim feladó neve alatt.
Magyarázatok
Ez a fenyegetés csak olyan titkosítási sémákra vonatkozik, amelyek autentikálják a feladót. Az ilyen sémák példáit a standardizálási ajánlások tartalmazzák. . Más kriptográfiai sémák esetében nem létezik ilyen fenyegetés, mivel a titkosítást a címzetti nyilvános kulcsok alapján végzik, és ezek általában a támadók számára ismertek.
Dekonpozíció
2.1. A feladó zárt kulcsának kompromittálása:
U2.1.1. Link: .
2.2. Az adatok megváltoztatása a nyílt adatok cseréjének csatornájában.
Megjegyzések 2.2.
A fenyegetés megvalósításának példái az alábbiakban találhatók. és .
3. Titkosított adatok dekódolása olyan személyek által, akik nem jogosultak az adatokra (támadók).
Dekonpozíció
3.1. A titkosított adatok címzettjének zárt kulcsai kompromittálása.
3.1.1 Hivatkozás: .
3.2. A titkosított adatok megváltoztatása a védett adatok cseréjének csatornájában.
4. Elektronikus aláírás létrehozása egy legitim aláíró által hamis adatok alatt.
Dekonpozíció
4.1. A legitim aláíró zárt kulcsainak kompromittálása.
4.1.1 Hivatkozás: .
4.2. A aláírandó adatok megváltoztatása a nyílt adatok cseréjének csatornájában.
Megjegyzés 4.2.
A fenyegetés megvalósításának példái az alábbiakban találhatók. és .
5. A hamis adatok elektronikus aláírásának pozitív ellenőrzési eredménye.
Dekonpozíció
U5.1. A támadók megszerzik az elektronikus aláírás ellenőrzésének negatív eredményéről szóló üzenetet, és azt egy pozitív eredményű üzenetre cserélik a kibocsátás közben.
U5.2. A támadók támadást indítanak a tanúsítványok bizalmának aláásására (FORRÁS — minden elem kötelező):
U5.2.1. A támadók létrehoznak egy nyilvános és egy privát elektronikus aláírás kulcsot. Ha a rendszerben elektronikusan aláíró kulcsok tanúsítványai vannak, akkor a potenciális adatszolgáltató tanúsítványához lehető legjobban hasonlító elektronikus aláírás tanúsítványt generálnak az általuk hamisítani kívánt üzenethez.
U5.2.2. A támadók jogosulatlan módosításokat végeznek a nyilvános kulcsok tárolójában, ellátva a generált nyilvános kulcsot a szükséges bizalmi szinttel és jogosultságokkal.
U5.2.3. A támadók hamis adatokat írnak alá a korábban létrehozott elektronikus aláírás kulccsal, majd ezeket beillesztik a védett adatcsere csatornájába.
U5.3. A támadók lejárt elektronikus aláírás kulcsok segítségével hajtanak végre támadást egy jogos aláíró részéről (FORRÁS — minden elem kötelező):
U5.3.1. A támadók kompromittálják a lejárt (jelenleg már nem érvényes) elektronikus aláírás kulcsokat a jogos küldőtől.
U5.3.2. A támadók megváltoztatják az időt a terjedési csatornában, hogy a kompromittált kulcsok még érvényesek legyenek.
U5.3.3. A támadók hamis adatokat írnak alá a korábban kompromittált elektronikus aláírás kulccsal és ezeket beillesztik a védett adatcsere csatornájába.
U5.4. A támadók kompromittált elektronikus aláírás kulcsok segítségével hajtanak végre támadást egy jogos aláíró részéről (FORRÁS — minden elem kötelező):
U5.4.1. A támadók másolatot készítenek a nyilvános kulcsok tárolójáról.
U5.4.2. A támadók kompromittálják egy jogszerű feladó privát kulcsait. A feladó észreveszi a kompromittálást, visszavonja a kulcsokat, a kulcsvisszavonásról szóló információkat elhelyezik a nyilvános kulcsok tárolójában.
U5.4.3. A támadók kicserélik a nyilvános kulcsok tárolóját a korábban másolt példányra.
U5.4.4. A támadók hamis adatokat írnak alá a korábban kompromittált elektronikus aláírás kulccsal, és ezeket beillesztik a védett adatcsere csatornájába.
U5.5. a 2. és 3. szakasz megvalósításában bekövetkező hibák következtében.
U5.5. magyarázatai.
A veszély ezen megvalósításának példája. .
U5.5.1. Az elektronikus aláírás kulcsának tanúsítványához való bizalom ellenőrzése csak a hozzá tartozó tanúsítvány bizalmának megléte alapján, CRL vagy OCSP ellenőrzések nélkül.
U5.5.1. magyarázatai.
Megvalósítás példa. .
U5.5.2. A kulcs tanúsítványához való bizalom láncolatának felépítése során nem elemzik a kibocsátó tanúsítványok jogosultságait.
U5.5.2. magyarázatai.
Példa SSL/TLS tanúsítványokkal kapcsolatos támadásra.
A támadók megszerezték egy legitim tanúsítványt az e-mail címükhöz. Ezután hamis tanúsítványt állítottak ki egy webhelyre, amit a saját tanúsítványukkal írtak alá. Ha nem történik jogosultság ellenőrzés, a bizalmi lánc ellenőrzése hitelesnek tűnik, így a hamis tanúsítvány is érvényesnek fog számítani.
U5.5.3. A kulcs tanúsítványához való bizalom láncolatának felépítése során nem ellenőrzik az intermediális tanúsítványokat az érvénytelenítésre.
U5.5.4. A CRL frissítése ritkábban történik meg, mint ahogyan azokat a hitelesítésszolgáltató bocsátja ki.
U5.5.5. Az elektronikus aláírásra vonatkozó bizalomról szóló döntést korábban hozzák meg, mint ahogy az OCSP- válasz érkezik a tanúsítvány állapotáról, amelyet a aláírás létrehozásának idején később vagy a következő CRL megérkezése előtt kértek.
U5.5.5. magyarázatai.
A legtöbb CA szabályzata szerint a tanúsítvány visszavonásának időpontjának az a legközelebbi CRL kiadásának ideje számít, amely tartalmazza a tanúsítvány visszavonásáról szóló információt.
U5.5.6. A aláírt adatok átvételekor nem ellenőrzik a tanúsítvány címzetthez való tartozását.
U5.5.6. magyarázatai.
Támadási példa. SSL tanúsítványok vonatkozásában: nem ellenőrizhetik a hívott szerver címének megfelelését a tanúsítvány CN mezőjével.
Támadási példa. A támadók kompromittálták az elektronikus aláírás kulcsait a fizetési rendszer egyik résztvevőjénél. Ezt követően feltörték egy másik résztvevő hálózatát, és az ő nevében küldtek a számviteli szervernek olyan kifizetési dokumentumokat, amelyeket a kompromittált kulcsokkal írtak alá. Ha a szerver csupán a bizalmat elemzi, és nem ellenőrzi a megfelelést, akkor a hamis dokumentumokat érvényesnek fogják tekinteni.
U6. Elektronikus dokumentumok téves elfogadása végrehajtásra az elektronikus dokumentumkezelés szervezeti problémái miatt.
Dekonpozíció
U6.1. A fogadó fél nem észleli a kapott dokumentumok megkettőzését.
U6.1. magyarázatai.
Támadás példa. A támadók elkaphatják a címzett számára továbbított dokumentumot, még ha az kriptográfiai védelemmel is védett, majd többször is elküldhetik azt a biztonságos adatátvitel csatornáján. Ha a címzett nem észleli a duplikációkat, akkor az összes kapott dokumentumot különböző dokumentumokként fogják észlelni és feldolgozni.
U7. Jogosulatlan hozzáférés védett adatokhoz a feldolgozás során SKZI segítségével.
Dekonpozíció
U7.1. az információ kiszivárgása miatt külső csatornákon (side channel attack).
Magyarázata U7.1.
támadásra .
U7.2. a jogosulatlan információhozzáférés védelmét semlegesítő intézkedések következtében, amelyeket SKZI-n dolgoznak fel:
U7.2.1. SKZI eszközök használata a SKZI dokumentációjában leírt követelmények megszegésével.
U7.2.2. végrehajtva a következő sebezhetőségek miatt:
U7.2.2.1. jogosulatlan hozzáférés védelmét szolgáló eszközökben.
U7.2.2.2. magában a SKZI-ban.
U7.2.2.3. a kriptográfiai eszköz működési környezetében.
Támadási példák
Az alább bemutatott forgatókönyvek szándékosan tartalmaznak információbiztonsági szervezési hibákat, és csak a lehetséges támadások illusztrálására szolgálnak.
1. forgatókönyv. Az U2.2 és U4.2 fenyegetések megvalósításának példája.
A tárgy leírása
A KBK ARM és a SKZI SKAD aláírása egy fizikailag elzárt számítógépen található, amely nincs csatlakoztatva a számítógépes hálózathoz. A kulcstartóként a FKN vdToken-t használják, és a kulcsot nem lehet kivenni.
A számítási ügyletekre vonatkozó szabályzat előírja, hogy a számítógépes szakember az ő munkahelyi számítógépéről letölti az elektronikus üzeneteket nyílt formában (a régi KBK ARM séma szerint) egy speciális védett fájlszerverről, majd átírja azokat egy elválasztható USB flash meghajtóra, és átkonvertálja a KBK ARM-ra, ahol titkosítja és aláírja őket. Ezt követően a szakember a védett elektronikus üzeneteket áthelyezi az elválasztható tárolóra, majd a munkahelyi számítógépén keresztül feltölti őket a fájlszerverre, ahonnan a BNR-hez és később a banki fizetési rendszerhez kerülnek.
Ebben az esetben a nyílt és védett adatok cseréjének csatornái a következőkből fognak állni: fájlszerver, a szakember munkahelyi számítógépe és az elválasztható tároló.
Támadás
A támadók engedély nélkül telepítenek egy távoli vezérlő rendszert a munkatárs számítógépére, és amikor kifizetési megbízások (elektronikus üzenetek) rögzítése történik az átadásra kerülő adathordozóra, nyílt formában hamisítják az egyik tartalmát. A szakember átviszi a kifizetési megbízásokat az AРM KBR-re, aláírja őket és titkosítja, anélkül, hogy észrevenné a hamisítást (például a sok kifizetési megbízás miatt a járaton, fáradtság miatt stb.). Ezt követően a hamis kifizetési megbízás a technológiai láncon keresztül bekerül a Oroszországi Bank kifizetési rendszerébe.
2. forgatókönyv. Az U2.2 és U4.2 fenyegetések megvalósításának példája.
A tárgy leírása
Az AРM KBR, a SKAD Szigatúra telepített számítógép, és a FKN vdToken kulcstartó csatlakoztatva, elkülönített helyiségben működik, a személyzet hozzáférése nélkül.
A kifizetési szakember távoli hozzáféréssel csatlakozik az AРM KBR-hez RDP protokollon keresztül.
Támadás
A támadók elfogják az adatokat, amelyeket a kifizetési szakember használ az AРM KBR-hez való kapcsolódáshoz és munkához (például a számítógépén lévő kártékony kód révén). Ezután az ő nevében csatlakoznak, és hamis kifizetési megbízást küldenek az Oroszországi Bank kifizetési rendszerébe.
3. forgatókönyv. Az U1.3 fenyegetés megvalósításának példája.
A tárgy leírása
Vizsgáljunk meg egy hipotetikus példát az „ABS-KBR” integrációs modulok megvalósítására az új séma (AРM KBR-N) számára, ahol a kimenő dokumentumok elektronikus aláírása az ABS oldalán történik. Feltételezzük, hogy az ABS olyan operációs rendszeren működik, amelyet a SKAD Szigatúra nem támogat, így a kriptográfiai funkciót egy külön virtuális gépre helyezzük – az „ABS-KBR” integrációs modulra.
Kulcstartóként egy hagyományos USB-token használatos, amely kivehető kulcs módban működik. Amikor a kulcstartót a hypervisorhoz csatlakoztatták, kiderült, hogy a rendszerben nincs szabad USB-port, ezért úgy döntöttek, hogy a USB-token-t egy hálózati USB-koncentrátoron keresztül csatlakoztatják, és a virtuális gépre USB-over-IP klienst telepítenek, amely kapcsolatot létesít a koncentrátorral.
Támadás
A támadók lehallgatták az elektronikus aláírás titkos kulcsát az USB hub és a hipervizor közötti kommunikációs csatornán (az adatok nyílt formában kerültek továbbításra). A titkos kulccsal a támadók hamisított átutalási megbízást állítottak elő, elektronikus aláírásukkal aláírták, és elküldték az ARМ KBR-N-nek végrehajtásra.
4. forgatókönyv. A 5.5-ös fenyegetések megvalósításának példája.
A tárgy leírása
Tekintsük azt a sémát, mint az előző forgatókönyvben. Legyen feltételezve, hogy az ARМ KBR-N-ből érkező elektronikus üzenetek a …SHAREIn mappába kerülnek, míg azok, amiket az ARМ KBR-N-be küldenek és tovább a Orosz Bank fizetési rendszerébe, a …SHAREout mappába mennek.
Azt is feltételezzük, hogy az integrációs modul megvalósítása során a visszavont tanúsítványok listái csak a kriptográfiai kulcsok újrabekérésénél frissülnek, és hogy az …SHAREIn mappába érkező elektronikus üzenetek csak a sértetlenségi ellenőrzés és a nyílt elektronikus aláírási kulcs iránti bizalom ellenőrzése alapján kerülnek megvizsgálásra.
Támadás
A támadók, kihasználva az előző forgatókönyvben eltulajdonított kulcsokat, aláírták a hamisított átutalási megbízást, amely információkat tartalmazott egy csaló ügyfél számlájára történő pénzbeérkezésről, és elhelyezték azt a védett adatcsere csatornában. Mivel nem végeznek ellenőrzést arra, hogy az átutalási megbízást valóban az Orosz Bank írta alá, azt végrehajtásra fogadják el.
Forrás: habr.com
