Ha megkérdeznénk az információbiztonsággal foglalkozó kollégákat, biztosan számos elhanyagolt területet és témát tudnának mondani a saját területükről, amelyek nagyobb figyelmet igényelnek. Ha engem kérdeznének, az IT asset inventory-k, jelen kontextusban az IT eszköz-, rendszer- és alkalmazás inventory-kat magyarul a nyilvántartásokat említeném, amelyek kis- és középvállalati szinten jellemzően hiányosak, biztonsági szempontból azonban kiemelten fontosnak tartom őket.

Jelen cikkemben ezen nyilvántartások jelentőségét kívánom kifejteni és több kontextusból megközelíteni a korábbi projekttapasztalataim alapján. Ha egy mondatban kellene kifejtenem a téma jelentőségét, akkor így tenném: amiről nem tudunk, azt nem tudjuk megvédeni. Úgy gondolom, hogy ennél mélyebben érdemes vizsgálni ezt a témakört.

Inventory-k, nyilvántartások

Első körben érdemes körüljárni a nyilvántartások fajtáit, hiszen az információbiztonsággal kapcsolatban többféle nyilvántartásról beszélhetünk. Ezek közül az alábbiakat érdemes említeni:

• IT eszköz nyilvántartás (IT asset/device inventory):
  • Az IT eszköz inventory-ba a szervezet „kézzel fogható” informatikai eszközeit rögzítik, például hálózati eszközöket, asztali munkaállomásokat, notebook-okat, mobil eszközöket, szervereket, storage-okat, adathordozókat és még sorolhatnánk.
• IT alkalmazás/rendszer nyilvántartás (IT application/system inventory):
  • Az IT alkalmazás/rendszer inventory-ba a szervezet által üzemeltetett rendszereket és ezek komponenseit (pl. szerverek, adatbázisok), illetve a harmadik felek által üzemeltetett, de a szervezet által felhasznált alkalmazásokat rögzítik. Klasszikus elemei pl. az ERP és CRM rendszerek, levelezés (legyen szó on-premise vagy cloud platformról), fájlszerverek és még folytathatnánk a napi munkánk során használt megoldásokkal.
  • Gyakran tapasztalom, hogy amennyiben egy szervezet rendelkezik egy használható alkalmazás/rendszer inventory-val, abban gyakran nincsenek benne a harmadik felek által üzemeltetett alkalmazások (pl. SaaS-alapúak), amit az egyik legjobb kiindulási alapban, az IP cím nyilvántartásban sem fogunk megtalálni. Ezekben az alkalmazásokban viszont előfordulhatnak védendő személyes- és ügyfél adatok, emiatt ezt problémának és egyben kockázatnak tartom, mert szervezeti szinten ezek kezelésével is vannak feladatok (pl. szervezeti hozzáférések kezelése), hiába üzemelteti másik fél.
• Információs vagyonelemleltár (Information asset inventory):
  • Az információs vagyonelemleltár összeállítása és naprakészen tartása az információbiztonsági kockázatelemzésekhez szükséges, ha a szervezet vagyonelem-fenyegetésen alapuló módszertant választ. Az ISO 27005 szabvány terminológiája alapján (információs) vagyonelem lehet minden olyan dolog, amely értéket képvisel a szervezet számára és amely ezért védelmet igényel.
  • Ebbe a kategóriába tartoznak az IT eszközök, IT rendszerek/alkalmazások is, de ezen kívül üzleti folyamatok, digitális és papíralapú adatok, személyek, telephelyek, szolgáltatások (ideértve az internetszolgáltatást és tápellátást egyaránt) is ide sorolhatók, amelyek szükségesek egy szervezet működéséhez. Az információs vagyonelemek általában besorolásra kerülnek bizalmasság, sértetlenség, rendelkezésre állás szerint, amelyekből kiszámolásra kerül a kritikussági szintjük.
  • IT szolgáltatásmenedzsment szempontból nem azonos, de nagyon közel áll az ITIL configuration item (CI) fogalmához, ami olyan komponens, amelyet az informatikai szolgáltatás nyújtásához kezelni kell.
• Adatvagyonleltár (Data inventory):
  • Az adatvagyonleltár a szervezet adatvagyonának, vagyis az üzleti folyamatokban felhasznált papíralapú és digitális adatainak szisztematikus nyilvántartása. Ha megfelelően van összeállítva, akkor teljes képet adhat a szervezet adatforrásairól, beleértve az adatok gyűjtésének, tárolásának, hozzáférésének és felhasználásának módjára vonatkozó információkat. Az adatvagyon leltár jellemzően tartalmazza az adatok bizalmasság, sértetlenség, rendelkezésre állás szerinti besorolását is.
• +1: Tárgyi eszköz nyilvántartás:
  • A tárgyi eszköz elsődlegesen számviteli kategória, olyan anyagi formában létező eszközök, amelyek tartósan szolgálják a szervezet tevékenységét. Ez azért kapcsolódik a témához, mert az IT eszközök is ebbe a kategóriába tartoznak és ezek gyakran párhuzamos nyilvántartásokban szerepelnek.

A felsorolt nyilvántartásokat tovább lehetne bontani, de az egyszerűség kedvéért ezt most mellőzöm. A cikk folytatásában a nyilvántartás vagy inventory kifejezés alatt az IT eszköz inventory-t és IT alkalmazás/rendszer inventory-t értem.

IT inventory-k fontossága – holisztikus megközelítés

Szinte minden cikkemben kitérek arra a tényre, hogy a megfelelés miatt történő papírgyártás, a felületes, igen-nem válaszokon alapuló „pipálgatós” felmérések mennyire kontraproduktívak. Nem kizárólagosan, de ez is az egyik oka az információbiztonsággal kapcsolatos mémek kialakulásának. A LinkedIn-en jelenlévő olvasók bizonyára találkoztak az alábbi mémmel. Görbe tükröt tartva, de ugyanakkor mégis kifejezi az inventory-k fontosságát, amit biztonsági, üzemeltetési, megfelelési és projektmenedzsment szempontból is vizsgálhatunk.

Biztonság

A mémmel egyetértve, és visszautalva a cikk elejére, jómagam is azt gondolom, hogy teljeskörű (a szervezetet teljesen lefedő), megfelelő tartalmú (elég részletes), naprakész (aktuális állapotot tükröző) inventory-k hiányában nem tudjuk megfelelően biztosítani és védeni a szervezetünk zavartalan működését, mert nem tudjuk megvédeni azokat az eszközöket és rendszereket, amelyekről nincs tudomásunk. Elsősorban azért nem tudunk róluk, mert nem szerepelnek az inventory-ban, de mégis léteznek és közreműködnek a szervezet működésében. Az inventory-ban nem szereplő elemek miatt vakfoltok alakulnak ki, ezt az alábbiakban néhány gyakorlati példával illusztrálom az ISO 27001:2022 szabvány „A” mellékletének pár technológiai kontrollján keresztül:

• Malware elleni védelem (8.7):
  • Szinte nincs olyan szervezet, ami ne használna klasszikus vírusirtót, de az EPP és EDR megoldások is elterjedtek. Ezek végpontokra és szerverekre történő telepítése, vagy ennek a lefedettségének visszaellenőrzése az inventory információk alapján történik. Ha egy eszköz vagy rendszer nem szerepel az inventory-ban, akkor előfordulhat, hogy azon nem lesz alkalmazva a védelem és nem fogja észlelni és megakadályozni a támadásokat.
• Naplózás (8.15):
  • Ha egy szervezet SIEM rendszert használ a naplók központi gyűjtésére és elemzésére, illetve EDR agent-eket telepít a munkaállomásokra a végponti tevékenység monitorozására, akkor ezt forráseszköz lista alapján fogja tenni, ami az inventory-kon alapul. Ha egy eszköz vagy rendszer nem szerepel az inventory-ban, akkor nagy valószínűséggel nem lesz bekötve a SIEM-be és az EDR agent sem fog rákerülni, ami miatt egy potenciálisan bekövetkező biztonsági incidenst sem lehet detektálni. Ugyanide vezethet az is, ha a szervezet által elvárt naplózási követelményeket nem állítják be minden eszközön, rendszeren.
• Biztonsági mentés (8.13):
  • A ransomware támadások trendjei mellett nem kell sokat érvelni a biztonsági mentések kritikussága mellett. A biztonsági mentések teljeskörűségét – vagyis azt, hogy minden rendszerről készül-e mentés – csak az inventory alapján lehet ellenőrizni. Amiről az IT nem tud, azon nagy valószínűséggel nem fognak futni központilag kezelt mentési folyamatok és egy sikeres ransomware támadás esetén vagy más katasztrófahelyzet miatt végzetes adatvesztést is elszenvedhet a szervezet.
• Technikai sérülékenységek kezelése (8.8):
  • Ha egy szervezet rendszeres időközönként sérülékenységvizsgálatot végez a saját üzemeltetésű rendszereken, ritkán, de előfordulhat, hogy nem IP tartomány szinten van meghatározva a sérülékenységvizsgálat hatóköre, hanem egyedi IP címek szerint. Ilyen esetekben szintén az inventory alapján lehet meghatározni a hatókört, hiányos tartalom miatt elképzelhető, hogy egyes rendszerek kimaradnak a vizsgálatból. Ebből kifolyólag megtörténhet, hogy nem kerülnek azonosításra a potenciális sérülékenységek, amelyeket támadások során kihasználhatók lehetnek.
  • Új sérülékenységeket nem csak vizsgálatok útján lehet azonosítani, hanem az IT biztonsággal kapcsolatos hírekből, riasztásokból. Ezek figyelemmel kísérése során, kritikus sérülékenységek esetén ajánlott a szervezeti érintettség felmérése (és szükség esetén patchelés is). A fenti pontok alapján meg lehet tippelni, hogy az érintettséget milyen inventory adatai alapján lehetne felmérni.
  • Végső soron a gyártói támogatással már nem rendelkező – end of life – rendszerek, eszközök teljeskörű azonosítása sem elképzelhető az inventory vagy megfelelő adatok hiányában (pl. operációs rendszer és verzió), ellenben az ilyen rendszerek és eszközök felhasználása és jelenléte is magas kockázatot jelenthet.

Üzemeltetés

Ahogy korábban leírtam, biztonsági szempontból az a lényeges, hogy tudjunk minden eszközről és rendszerről, hogy megfelelően lehessen biztosítani a védelmüket. Üzemeltetési szempontból kardinális, hogy az IT vagyonelemek (eszközök, rendszerek, alkalmazások, harmadik felek által nyújtott szolgáltatások) megfelelően legyenek kezelve a teljes életciklusuk során, hogy az IT szolgáltatásokat az ügyfelek elvárásainak megfelelően és folytonosan biztosítsák. Erről szól az ITIL 4 IT asset management practice.

Az IT vagyonelemek kezeléséhez első körben az szükséges, hogy azokról megbízható adatok álljanak rendelkezésre, ezek pedig az inventory-kban vannak, vagy ott kellene lenniük. Az ITIL 4 egyébként az IT asset register kifejezést használja, de a jelentésük megegyezik, az üzemeltetendő eszközöket és rendszereket tartalmazzák. Ha ez hiányos, vagy nem naprakész, akkor ez üzemeltetési feladatok elmaradásához vezethet, ami üzemeltetési és biztonsági incidenseket idézhet elő, ami SLA sértésekkel járhat és még sorolhatnánk.

Az IT asset management practice-n kívül a Service configuration management is kapcsolódik a témához. Ennek célja, hogy a szolgáltatások konfigurációjáról és az azokat támogató létfontosságú infrastruktúrákról szóló pontos és megbízható információk rendelkezésre állását biztosítsa. Ezeket az információkat egy adatbázisban, configuration management database-ben (CMDB) rögzítik, ahol nem csupán az alapinformációk, hanem az egyes elemek közti kapcsolatok is szerepelnek, tehát bővebb, mint egy inventory.

Megfelelés

A szervezet IT eszközeit és rendszereit tartalmazó, teljeskörű és naprakész inventory rendelkezésre állását szinte az összes információbiztonsági és IT biztonsági szabvány vagy egyéb keretrendszer előírja, tehát ennek hiányában nem lehet(ne) megfelelni. Lássuk a legismertebbeket:

• ISO 27001:2022:
  • 9 Inventory of Information and Other Associated Assets
• NIST CSF:
  • AM-1: Physical devices and systems within the organization are inventoried;
  • AM-2: Software platforms and applications within the organization are inventoried
• NIST SP 800-53 rev 5:
  • CM-8: System Component Inventory
• CIS Controls v8:
  • 1 Establish and Maintain Detailed Enterprise Asset Inventory
• PCI-DSS 4.0:
  • 5.1 An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current.

A szabványon kívül elméleti síkon érdemes kitérni két magyar jogszabályra, a NIS2 irányelvet átültető, a kiberbiztonsági tanúsításról és a kiberbiztonsági felügyeletről szóló 2023. évi XXIII. törvényre (Kibertantv.) és az idén 10 éves, az állami és önkormányzati szervek elektronikus információbiztonságáról szóló 2013. évi L. törvényre (Ibtv.). Mindkét hivatkozott jogszabály részletkövetelményei kitérnek az elektronikus információs rendszerek biztonsági osztályba sorolására, ami szintén teljeskörű és naprakész rendszerekre vonatkozó információt igényel.

Projektmenedzsment

A projektmenedzsment elsőre kakukktojásnak tűnhet a biztonsági és üzemeltetési okok mellett, de korántsem elhanyagolható. Az információbiztonsági felmérési projektekben – legyen szó egyszerű gap assessmentről, kockázatelemzésről, üzleti hatáselemzésről – megkerülhetetlen előfeltétel, hogy rendelkezésre álljon megfelelő tartalmú, teljeskörű, naprakész inventory. Ez egyrészt a projekt hatókörének meghatározásához szükséges, másrészt a megfelelő adatok hiányában a szervezeti alapkontextus IT részét is nehéz lehet megismerni, ami nélkül a releváns kockázatokat is korlátozottan, vagy nem megfelelő súllyal lehet azonosítani. Ha az inventory-t a felmérési projekt részeként kell elkészíteni, akkor a projektben plusz költséggel és hosszabb határidővel kell számolni.

Okok

A nem teljeskörű, hiányos tartalmú, nem naprakész inventory-k létezésének számos oka lehet, amelyek együttesen is jelentkezhetnek:

• Belső szabályozás, elvárás vagy ezek érvényesítésének hiánya,
• Biztonsági és üzemeltetési – különösen változáskezelési – folyamatok hiánya vagy ezektől való eltérés,
• Felelősség meghatározásának vagy ellenőrzésének hiánya,
• Siló-szerű működés, divíziónként eltérő formátumú és tartalmú inventory-k,
• IT tudta nélkül működtetett és használt rendszerek („shadow IT”).

Lehetséges megoldás

A problémafelvetés után itt az ideje, hogy lehetséges gyakorlati megoldásokat javasoljak.

People

Elsőként ajánlott kijelölni az inventory kezelésével és ellenőrzésével kapcsolatos szerepköröket és felelősségeket. Úgy gondolom, hogy a szervezetek informatikai üzemeltetéséért felelős vezetője az elszámoltatható (RACI: A) azért, hogy a szervezeti IT inventory-k megfeleljenek a tartalmi és formai elvárásoknak. Az inventory tartalmának naprakészségéért, megfelelő tartalmáért és felülvizsgálatáért az eszközök, rendszerek üzemeltetője, technikai tulajdonosa a felelős (RACI: R). Az inventory-t nem elég tölteni és felülvizsgálni, ezek megfelelőségét erősen ajánlott ellenőrizni. Ezért a szervezet méretétől függően a szervezet információbiztonsági vagy belső audit funkciója lehet felelős (RACI: R).

Process

A folyamatok kialakítása előtt ajánlott szabályozni az IT inventory-val kapcsolatos követelményeket, amit a szervezet üzemeltetési- és/vagy információbiztonsági szabályzatában célszerű megtenni.

Úgy gondolom, hogy az inventory kezelésére nem szükséges saját folyamatot kialakítani, inkább a meglévő folyamatokba indokolt beépíteni egy lépésként, különös tekintettel az IT változáskezelési folyamatra. Ha egy pillanatra eltekintünk a végpontok kiadásától és visszavételétől, akkor egy közepesen érett szervezetben az IT eszközök (pl. szerverek, hálózati eszközök) és rendszerek a változáskezelési folyamat keretében kerülnek bevezetésre, frissítésre és kivezetésre. E szerint az új rendszerek rögzítésének, a meglévők adatainak frissítésének és a kivonás átvezetésének is – vagyis a kapcsolódó adminisztrációnak – ennek a folyamatnak a részeként kellene megtörténnie, így lenne biztosítható az inventory naprakészsége. Ez a megközelítés megegyezik az ITIL ajánlásával.

Technology

A technológia nem csak az eszközök és rendszerek nyilvántartására, de azok azonosítására is használandó. Tegyük fel, hogy egy szervezetnél kockázatként azonosították a nem megfelelő IT inventory-t és most meg szeretnék oldani, vagyis elfogadható szintre akarják csökkenteni a kockázatot.

Elsőként ajánlott összegyűjteni minden rendelkezésre álló adatot a meglévő eszközökről és rendszerekről. Ezt a meglévő eszköz-, rendszer- és IP cím nyilvántartások, esetleg rack szekrény beszerelési diagrammok átvizsgálásával lehet megtenni. A fizikai eszközöket könnyebb ellenőrizni, elég lehet bejárni a szervertermeket, amennyiben iLO vagy iDRAC távoli menedzsment eszközöket használ a szervezet, akkor onnan is össze lehet gyűjteni a hiányzó információkat (pl. S/N).

A rendszerek összeírása már nehezebb feladat, hiszen nem kézzel foghatók. Erre a feladatra az IP nyilvántartás jó alap lehet, de inkább asset discovery vagy network discovery eszközök használatát javasolja a best practice, pl. Nmap. A sérülékenységvizsgáló szoftvereknek is van host discovery funkciója, ami alkalmazható. A discovery eszközök használata után érdemes összevetni az ismert és az új elemeket, majd elvégezni az adatok bővítését, ha a hálózaton új hostokat fedeztek fel. Ilyen esetben minél előbb be kell azonosítani és biztonsági incidensként kell kezelni, ha megállapították, hogy illetéktelenül csatlakozott a hálózatra. Ha a meglévő inventory-k jelentősen elavultak vagy nem megfelelő a felépítése, akkor célszerű lehet új inventory-t kezdeni. Célszerű rendszeres időközönként feltérképezni a szervezeti hálózatot és összevetni az inventory-val. A CIS Controls v8 is javaslatot tesz erre a 2-es Implementation Group-ba tartozó (közepes érettségű) szervezeteknek:

• 3 Utilize an Active Discovery Tool – Utilize an active discovery tool to identify assets connected to the enterprise’s network. Configure the active discovery tool to execute daily, or more frequently

A harmadik felek által üzemeltetett alkalmazásokat leginkább üzleti területekkel folytatott interjúk során lehet azonosítani, mert egy SaaS-alapú alkalmazást nehezebb azonosítani, mint egy szervezeti hálózatban található vagyonelemet. Ugyanakkor nem lehetetlen, erre a számlák áttekintését, hálózati-, végpont-, alkalmazás- és böngésző szintű adatgyűjtést javasolnak az ezzel foglalkozó blogok.

Platform és tartalom

Egy kisebb méretű szervezetnek megfelelő eszköz- és rendszer nyilvántartási forma lehet egy Excel táblázat, de ennek vannak határai. Ilyenkor érdemes elgondolkozni egy kifejezetten erre a célra kitalált szoftver használatán. Ezeknek rendkívül széles köre van, minden szervezet meg tudja találni a számára megfelelő megoldást. Szűkös budget esetén nem kell egyből elvetni az Excel táblák kiváltásának ötletét, mert sok olyan megoldást lehet találni, amelyek on-premise verziója ingyenes. Érdemes olyan szoftvert választani, amit egyedi mezőkkel és listákkal testre lehet szabni.

Az inventory-k tartalmát illetően minden szervezetnek magának érdemes meghatároznia a nyilvántartandó adatokat. Az alábbiakat tekintem elengedhetetlen adatnak az IT eszköz- és rendszer inventory-kban:

• Megnevezés (egyedi hostname is) és funkció leírása,
• IP cím,
• Operációs rendszer, adatbázis, alkalmazás megnevezése és pontos verzióik, valamint a gyártói támogatás vége,
• Státusz,
• Gyártó és típus (hardver esetén),
• Fejlesztő (szoftver esetén),
• Sorozatszám (hardver esetén),
• Harmadik fél szolgáltató (ha alkalmazandó),
• Lokáció (hardver esetén),
• Üzemeltető (technikai tulajdonos),
• Üzleti tulajdonos.

A felsorolt minimális adattartalom kibővíthető licenszelésre, gyártói támogatásra, kitettségre (pl. publikált-e), kritikussági szintre vonatkozó adatokkal is. Létfontosságú, hogy szervezeten belül csak egy, egységes inventory létezzen, ami lefed minden szervezeti egységet és funkciót (üzemeltetés és security is ugyanazt használja). Ellenkező esetben párhuzamosan létező és törvényszerűen eltérő inventory-val kell dolgozni, amibe bele vannak kódolva a problémák.

Konklúzió

A cikkben igyekeztem rávilágítani arra, hogy mennyire fontos a láthatóság és az, hogy a nem megfelelő inventory-k milyen szintű hiányt tudnak okozni az eszközök és rendszerek kontrolljában. A problémafelvetésen túl igyekeztem egy gyakorlatban kivitelezhető és best practice-nek megfelelő megoldási javaslatot adni azok számára, akik megoldanák a problémát a saját szervezetüknél. A cikkben tett megállapítások alapján talán már nem tűnik „szőrszálhasogatásnak” és üres kérdésnek az inventory-k kezelése és a bemutatott mémre is más szemmel nézünk ezután.

Források

• ITIL 4,
• ISO 27001:2022,
• ISO 27005:2022,
• CIS Controls v8.