A szervezetben keringő információk ellenőrzése a legfontosabb feladatok egyike a szervezési és irányítási dokumentumok (információbiztonsági politika és más alacsonyabb szintű belső dokumentumok) gyakorlati megvalósításakor.
Az informatikai rendszerből származó bizalmas információk szivárgásának megelőzésére szolgáló rendszerek (Data Leak Prevention, DLP) nagyrészt képesek megoldani ezt a problémát.
A mai piacon elegendő fajta ilyen rendszer létezik, például: SearchInform DLP, Infowatch Traffic Monitor DLP, Zecurion DLP, Symantec DLP és mások. De ma ennek a cikknek a témája az LLC "SearchInform" terméke lesz.
A SearchInform információbiztonsági keretrendszer (KIB SearchInform) egy komoly és rugalmasan konfigurálható szoftverkomplexum, amely funkcióival és széleskörű elemzőeszközeivel komoly versenytársat jelent a piacon. Mint minden terméknek, a KIB SearchInformnak is van egy hátránya, amiről most szó lesz.
1. ábra – A KIB SearchInform logója
A KIB SearchInformban az információgyűjtés egyik forrása az ügynök (Windows/Linux). A Windows és Linux operációs rendszerekhez is egy moduláris információgyűjtő rendszer tartozik, amelynek elemei szükség esetén be- vagy kikapcsolhatók. Megvizsgáljuk a Device modult (külső eszközök, hálózati eszközök, folyamatok stb. ellenőrzése). A termék demóverzióját hivatalosan kérheti a fejlesztő weboldalán (a teljes funkcióval). A további lépéseket a megkapott licenckulcs segítségével hajtják végre — az EndPointController 5.51.0.9 verziója (ügynök verziója 5.51.0.9).
A modul működésének fő problémája az információk titkosításának algoritmusa a külső eltávolítható eszközökön. Vizsgáljuk meg a titkosítási algoritmus működési elvét a KIB SearchInform környezetében.
Telepítjük az ügynököt a munkaállomásra, és a munkahelyi környezetben beállítjuk a külső eszközök ellenőrzését (Device modul) az EndPointController 5.51.0.9 "Hálózati környezet" részében.
2. ábra – A modul telepítése és aktiválása
Konfiguráljuk a titkosítást a Device modul beállításaiban a "Titkosítás" fül alatt: generálunk egy kulcsot, és aktiváljuk a titkosítást minden adathordozóra (lehetséges a titkosítás aktiválása csak bizonyos információs adathordozókra).
3. ábra – A fehérlista beállítása
4. ábra – Titkosítási konfiguráció
Most kezdjük el a fájlok titkosítási algoritmusának bontását. Másoljuk az „Install.exe” és a „Jogi alapok.rtf” fájlokat az irányított munkaállomásról „WINOC” egy külső, eltávolítható tárolóra „Eltávolítható lemez (E:)”. Ahogy az az 5. ábrán látható, a „System Volume Information” rejtett mappában létrejöttek az „Install.exe” és a „Jogi alapok.rtf” objektumok. Ez alapján arra következtethetünk, hogy a „System Volume Information” mappa az eltávolítható tárolón található titkosított objektumok listáját tartalmazza.
5. ábra – a „System Volume Information” mappa
6. ábra – Az eltávolítható tároló gyökérmappája
Mint ismeretes, három szempont van, amelyre az információbiztonság épül – ezek az integritás, hozzáférhetőség és titkosság. E szempontok megsérülnek ennek a titkosítási megközelítésnek a használatával, mivel a titkosított objektumokról való rendszerinformációnak magában az objektum fejléceiben kell lennie.
A jelenlegi algoritmus felépítése lehetőséget ad a „System Volume Information” mappa objektumainak véletlenszerű módosítására/törlésére az eltávolítható tárolón, továbbá a titkosított eredeti objektumok elvesztésére is, valamint az objektumok módosítására ellenőrizetlen állomásokon (például: az „Install.exe” objektum átnevezése a „E:Install.exe” hálózati úton egy ügynök nélküli számítógépen, miközben a programtermék információs fájlja a KIB SearchInform „Install.exe” a „System Volume Information” mappában, hálózati úton „E:System Volume InformationInstall.exe” változatlan marad, mivel hiányzik az ügynök, amely megváltoztatná a rendszerinformációt, és az adott fájl megnyitása lehetetlenné válik).
Reméljük, hogy a fejlesztő figyelembe veszi ezt a hiányosságot a KIB SearchInform információs tárolók titkosítási funkciójának működésében, és módosítja az algoritmust.
Forrás: habr.com
