NIS2 tapasztalatok

Közösségi kerekasztal

Sziasztok!

 

NIS2 tapasztalatok érdekelnének.

 

Kollégák ezerrel pörögnek NIS2 auditon és rettegnek, hogy ha mindent bevezetünk ami az előírás, akkor megáll a cég mint a szög. :)

Pl. repo maintainer nem lehet ugyanaz mint a reviewer meg a dev. (legalábbis ilyen szabályzattal találkoztam legutóbb), ez egy két fős projektnél azért necces, de van még millió ilyen.

 

Hogy megy ez a gyakorlatban? Mennyire lehet lazítani a szabályozáson, van-e valami minimum szint? 

 

Köszi!

  • 1152 megtekintés

( csardij v | 2025. 08. 12., k – 14:47 )

Itt most alapvetően két dolog van: meg akarsz felelni az auditon, hogy legyen meg a plecsni, de amúgy kit érdekel, vagy tényleg be is akarjátok tartani?

Web, Domain, Tárhely

( locsemege v | 2025. 08. 12., k – 15:11 )

Sokkal egyszerűbb. Nincs maintainer meg reviewer. Van a dev, commitol, amikor úgy látja helyesnek, szól a többieknek, amikor elkészült. Ami nincs, az nem tud ugyanaz lenni, mint a másik, szóval probléma megoldva. Vagy a NIS2 azt is megmondja, hogy hány fokos szögben állhat a monitorod, milyen magas lehet, hányra menj be dolgozni, s mikor mehetsz mosdóba, kávézni és ebédelni? Esetleg a NIS2-ben nincs szabályozva, hogy mit ehet a fejlesztő? A fejlesztő kezében lehet csavarhúzó és forrasztópáka, vagy csak a billentyűzetet püfölheti?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Vagy a NIS2 azt is megmondja, hogy hány fokos szögben állhat a monitorod, milyen magas lehet, hányra menj be dolgozni, s mikor mehetsz mosdóba, kávézni és ebédelni? Esetleg a NIS2-ben nincs szabályozva, hogy mit ehet a fejlesztő?

A NIS2 információbiztonsági, folyamatbiztonsági elvekről szól. Nem konkrétumokról, elvekről. A cégek meg úgy adoptálják ezeket az elveket a saját szabályzatukban, hogy megfeleljenek az előírásnak. Lehetne nagyon szigorú és lazább megfelelések is, az egész arról szól, ha kiberbiztonsági incidens van, akkor legyen egy dokumentum, amiben benne van, hogy "ezt kellett volna csinálni" és a tények ("ez történt valójában").

Ugyebár ha nincsen meg az a bázis, hogy "ezt kellett volna csinálni", akkor minden viselkedés szabályszerű, és az incidens kivizsgálásának az az eredménye, hogy nem történt semmi probléma. Na, ezt elkerülendő van a NIS2, ami előírja, hogy nem lehet az, hogy nincsenek szabályok lefektetve kiberbiztonságilag.

Ugyanúgy, ahogy a GDPR sem konkrétumokat írt elő, hanem azt, hogy ha valaki adatot kezel, akkor azt milyen elvek mentén kell csinálnia.

( persicsb | 2025. 08. 12., k – 17:10 )

Az összes ilyen folyamatokat előíró dokumentum nem arról szól, hogy tatsd be minden pontját mindig.

Hanem arról, hogy ha gebasz van, akkor utólag ki lehessen deríteni, hogy ki és miért nem tartotta be a szabályokat, és lehessen felelőst találni.
A cég ezzel lefedi magát, a felelősség a munkavállalókra terelődik, mert a szabályzat megvan, legfeljebb a melósok nem tartják be.

Ugyanígy, ez egy kétélű fegyver: ha valamivel nagyon bajod van, akkor te is tudsz mutogatni arra, hogy jó, akkor innentől minden szabályzat minden pontját mindig betartod, ha ez azzal jár, hogy 10x annyi ideig tart egy munkafolyamatot elvégezni, akkor ezzel jár és kész.

Akkor valószínűleg megkeresik azt az embert, aki a tartalom elolvasása nélkül aláír mindent, bepipál minden checkbox-ot, persze, ha borul a bili, a management azonnal előhúzza majd a szigorú szabályokat, s sajnálkozva mondják, be kellett volna tartani azokat. :(

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ha borul a bili, a management azonnal előhúzza majd a szigorú szabályokat

Nem a menedzsment, hanem a hatóság. Olyan cégek számára van előírva a NIS2 irányelveknek megfelelés, amik nemzetbiztonságilag fontosak (kritikus termékek gyártása, víz/energiaellátás, közlekedés, egészségügy, pénzügyi szolgáltatások stb.). A jóskapiska bt-k számára nem kell a NIS2 megfelelés, de mondjuk a MOL-nak, a bankoknak, meg a Telekomnak igen.

Melyik részét? A NIS2 hatálya tök jól leírja, hogy kire vonatkozik.
 

Ezt az irányelvet az I. vagy II. mellékletben említett típusú olyan állami vagy magánszervezetekre kell alkalmazni, amelyek a 2003/361/EK ajánlás mellékletének 2. cikke szerint középvállalkozásoknak minősülnek vagy meghaladják az említett cikkben a középvállalkozásokra vonatkozóan előírt küszöbértékeket, és amelyek az Unión belül nyújtják szolgáltatásaikat vagy végzik tevékenységeiket.

Ez az irányelv – méretüktől függetlenül – az I. vagy II. mellékletben említett típusú szervezetekre is alkalmazandó, amennyiben:

a)    a szolgáltatásokat a következők nyújtják:

  1. nyilvános elektronikus hírközlő hálózatok szolgáltatói vagy nyilvánosan elérhető elektronikus hírközlési szolgáltatásokat nyújtó szolgáltatók;
  2. bizalmi szolgáltatók;
  3. legfelső szintű doménnév-nyilvántartók és doménnévrendszer-szolgáltatók;

b)    a szervezet egy tagállamban az egyetlen szolgáltató egy olyan szolgáltatás tekintetében, amely elengedhetetlen a kritikus társadalmi vagy gazdasági tevékenységek fenntartásához;

c)    a szervezet által nyújtott szolgáltatás zavara jelentős hatással lehet a közvédelemre, a közbiztonságra vagy a közegészségre;

d)    a szervezet által nyújtott szolgáltatás zavara jelentős rendszerszintű kockázatot idézhet elő, különösen azokban az ágazatokban, ahol az említett zavarnak határokon átnyúló hatása lehet;

e)    a szervezet kritikus, mivel nemzeti vagy regionális szinten különös fontossággal bír az adott ágazat vagy szolgáltatás típusa, vagy a tagállam más, kölcsönösen függő ágazatai szempontjából;

f)    a szervezet:

  1. valamely tagállam által annak nemzeti jogával összhangban meghatározott, központi kormányzathoz tartozó közigazgatási szerv; vagy
  2. valamely tagállam által annak nemzeti jogával összhangban meghatározott, regionális szintű közigazgatási szerv, amely kockázatalapú értékelés alapján olyan szolgáltatásokat nyújt, amelyek zavara jelentős hatást gyakorolhat kritikus fontosságú társadalmi vagy gazdasági tevékenységekre.

(3)   Ez az irányelv – méretüktől függetlenül – az (EU) 2022/2557 irányelv szerint kritikus szervezetként azonosított szervezetekre is alkalmazandó.

(4)   Ez az irányelv – méretüktől függetlenül – a doménnév-nyilvántartási szolgáltatásokat nyújtó szervezetekre is alkalmazandó.

(5)   A tagállamok rendelkezhetnek úgy, hogy ez az irányelv alkalmazandó a következőkre:

  1. helyi szintű közigazgatási szervek;
  2. oktatási intézmények, különösen, ha kritikus fontosságú kutatási tevékenységeket végeznek.

Az I-II. melléklet meg ezeket sorolja még fel:

  • Energia
  • Szállítás
  • Banki szolgáltatás
  • Pénzügyi piaci infrastruktúrák
  • Egészségügy
  • Ivóvíz
  • Szennyvíz
  • Digitális infrastruktúra
  • IKT-szolgáltatások vállalkozások között
  • Közigazgatás
  • Világűr
  • Postai- és futárszolgáltatások
  • Hulladékgazdálkodás
  • Vegyszerek gyártása, előállítása
  • Élelmiszer-termelés
  • Gyártás, ezen belül orvostechnika, elektronikai, optikai termékek, villamos berendezése, gépjárművek, egyéb szállítóeszközök
  • Digitális szolgáltatók
  • Kutatás

 

Az egész NIS2 a nemzetbiztonságilag fontos kritikus infrastruktúra (szolgáltatás, ellátási lánc) kibervédelméről szól. Az itthon bejegyzett kb. 500 ezer társas vállalkozásból kb. 4000-et érint.

Nezd meg azokat a szolgaltatasokat amit ha nyujtasz, merettol fuggetlenul alkalmazni kell a nis2-t….

pl milyen nemzetbiztonsagi kockazat van annan, hogy xy webfejleszto ceg sajat szerveten tarolja a wboldalt (ezzel meg nem is kerulne be a nis2 ala) meg a hozza tartozo dns zonat (ez mar nis2 ok).

a 4ezer ceg kb ugy jon ki, hogy egy csomo ceget halisten mentesitettek az audit alol, de attol meg vonatkozik ra a nis2…

Web, Domain, Tárhely

meg a hozza tartozo dns zonat (ez mar nis2 ok).

Dehogy, a nemzeti szintű DNS szolgáltatók tartoznak csak ez alá (doménnév-nyilvántartási szolgáltatást nyújtó szervezetek). Az, hogy te menedzseled a saját DNS zónádat, de ezt amúgy nem nyújtod szolgáltatásként senkinek, az nem tartozik ide. Ez szerepel a NIS2 rendeletben:

Ezért ezen irányelvnek alkalmazandónak kell lennie a legfelső szintű doménnév-nyilvántartókra és a DNS-szolgáltatókra, amelyeket az internet végfelhasználói számára nyilvánosan hozzáférhető rekurzív doménnév-feloldási szolgáltatásokat vagy harmadik fél általi használatra szánt hiteles doménnév-feloldási szolgáltatásokat nyújtó szervezeteknek kell tekinteni.

A doménnévrendszer-szolgáltatás esetén is a legfelső szintűek számítanak csak: 

legfelső szintű doménnév-nyilvántartók és doménnévrendszer-szolgáltatók;

Azaz ha te nem vagy .hu regisztrátor, akkor semennyire nem vonatkozik ez rád.

De ez amúgy benne is van a NIS2 szabályzatban:

     

„DNS-szolgáltató”: olyan szervezet, amely a következőket nyújtja:

a) nyilvánosan elérhető rekurzív doménnév-feloldási szolgáltatások az internetes végfelhasználók számára; vagy

b) hiteles doménnév-feloldási szolgáltatások harmadik felek általi felhasználásra, a gyökérnévszerverek kivételével;

„legfelső szintű doménnév-nyilvántartó”: olyan szervezet, amelyre egy meghatározott legfelső szintű domént bíztak, és amely felelős egyrészt a legfelső szintű domén kezeléséért – ideértve a legfelső szintű domén alatti doménnevek nyilvántartásba vételét –, másrészt a legfelső szintű domén technikai üzemeltetéséért, amely magában foglalja a névszervereinek üzemeltetését, adatbázisainak karbantartását és a legfelső szintű domén zónafájlok elosztását a névszerverek között, függetlenül attól, hogy ezen üzemeltetési tevékenységek bármelyikét maga a szervezet végzi vagy azokat kiszervezi, kivéve azonban azon eseteket, amikor a legfelső szintű doménneveket a nyilvántartó kizárólag saját használatra veszi igénybe;

„doménnév-nyilvántartási szolgáltatásokat nyújtó szervezet”: regisztrátor vagy regisztrátorok nevében eljáró ügynök, például titkosított vagy meghatalmazott regisztrációs szolgáltató vagy viszonteladó;

Az, hogy te egy DNS zónát karban tartasz, az nem tartozik ide. Az, hogy ha te nyilvánosan elérhető rekurzív DNS szervert szolgáltatsz a világnak, az ide tartozik. Vagy ha te regisztrátor vagy. Ez utóbbiakat eléggé kevesen csinálják, magyar .hu regisztrátor szerintem nincs több 120 cégnél.

Beletartozik, bár én nem tudok olyan cégről, aki mások számára (ez fontos kitétel, a NIS2-ben is az van benne, hogy 3rd party usage) authoritative DNS szolgáltatást ad, és amúgy nem DNS regisztrátor. Te tudsz ilyet?

Az más, hogy ha valaki a saját DNS zónáját a saját névszerverével szolgálja ki, az nem tartozik ide.

Hány olyan cég van, aki authoritative DNS szolgáltatást ad, de amúgy nem domain regisztrátor? Próbáltam keresni olyan céget, akitől lehetne venni DNS zóna szolgáltatást, de csak olyat találtam, aki amúgy közben domain regisztrátor is.

Az aláírásodban szereplő cég is domain regisztrátor.

Amiket én tudok, ők pl. webfejlesztők. Úgy külön nem árulnak domaint ilyesmit, de ha valaki velük fejleszti le a weboldalát, akkor adnak megoldást amibe, domain tárhely benne van. Értelemszeráen a domaint veszik valahonnét, de a tárhely jellemzően cpanel, aminel a beépített névszervert használják.

Web, Domain, Tárhely

Annak idején, amikor az ISO tanúsítás elkezdődött, ugyanez volt a felfogás, mármint hogy egy könyv kell hozzá, ami leírja a folyamatokat és ha az megvan akkójóvanakkó. Aztán kiderült, hogy a szabvány egy csomó olyan normát ír elő, amelyet normális menedzsment akkor is megcsinál, ha azt szabvány nem írja elő. Ma már könyv sem kell hozzá, anélkül is megkaphatod a plecsnit, kiment a divatból vagy természetes, hogy a működés minőségi normák alapján szerveződik, az ISO szabvány többnyire a vállalati kultúra része.

Nem tudom, hogy az informatikai normának van-e ilyen természete. A norma egy segédlet, ami tapasztalaton alapul és a célja, hogy segítse a vállalat menedzsmentjét egy biztonságos rendszer kialakításában. Nem feladat, hanem a racionális működés része, a kockázat mértékétől és a vállalat méretétől függetlenül. Pláne ott, ahol nem kötelező, inkább segítség kéne legyen az ilyesmi, mint drága, ijesztő és a működést akadályozó követelményrendszer. ISO 27001-gyel foglalkoztunk valamikor ilyen alapon, de aztán elhalt nálunk a projekt, mert nem volt kötelező és mindenki hányt a gondolatától.   

OK, csak ebben a hozzászólásodban az az egy sor nem fedte le azt, amelyet a jogszabályból lejjebb idéztél. A jogszabályban lévő felsorolásba beleesünk. Mondjuk tudtam, mert nem hivatalos tályékoztatásként ugyan, de elhangzott.

Szerk.: Visszatérve az eredeti problémához. Ha a dolgozó feszesen mindent betart, kirúgják a hatékonytalanság miatt. Ha nem, akkor megy a szekér, amíg nincs baj, ha viszont baj van, magára hagyják, miért nem tartotta be a szabályokat, övé a felelősség.

Ezért is mondom jó ideje, és mondtam mindig is, hogy nagyon gyorsan ki kellene lépni az EU-ból!

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha nem, akkor megy a szekér, amíg nincs baj, ha viszont baj van, magára hagyják, miért nem tartotta be a szabályokat, övé a felelősség.

Ez ugye normális helyen úgy megy ám, hogy a dolgozó írásban kéri azt az utasítást, hogy ne tartsa be a szabályokat, hogy hatékony legyen. Ha nem akarják ezt írásba adni, akkor meg nem rúghatják ki hatékonytalanság miatt, a munkaügyi pert szépen elvesztené a vállalat (azért rúgták ki, mert betartotta a céges szabályokat?)

( Mik v | 2025. 08. 12., k – 17:23 )

Csak érdekességnek: GitLabban a repo maintainernek by default van dev joga.

( Vamp | 2025. 08. 12., k – 21:41 )

Szerkesztve: 2025. 08. 12., k – 21:42

Nalunk is duborog a NIS2, bar nem vagyunk fejlsztok (Multi Autoipari beszallito, Tavaly nyomtunk egy TISAX-ot jovore pedig egy ISO27001-et)

 

Elegge benne vagyok a temaban, (A heten kezdem irni a Kritikus EiR-ek re a DRP-ket...)

 

Szoval ugye alapvetoen a NIS2 nem ir elo semmit. ezek az auditok maskepp mukodnek. (ahogy azt mar fontebb masok is kifejtettek). Adott alapvetoen egy javaslat gyujtemeny, amit a ceged atvehet es ebbol szabalyzast alkothat. Ezt a szabalyzast neked mar be kell tartanod onnantol kezdve es ennek a betartasat (es betartatasat!) ellenorzi az auditor.

 

Tehat ha teszem azt van egy belepteto rendszered, ami nem felel meg biztonsagilag egy belepteto rendszernek (mert pl titkositatlan proximity 125kHz kartyakat hasznal) azt egesz egyszeruen NE nevezd belepteto rendszernek es akkor problem solved :) 

 

A NIS2 nem azt irja elo, hogy milye legyen egy cegnek (semmi sem kotelezo!) hanem azt, ha valamilye van es azt valaminek nevezi, akkor az tenylegesen biztositsa azt aminek "nevezve van" (kicsit nyakatekert mondat lett, de remelem ertheto)

Ha azt mondod, hgy az adatod nem eri el azt a kritikussagi szintet, hogy backupolni kelljen, akkor nem kell backup. Nyilvan ezek olyan dolgok , amik egymas elott "gordulnek" Ha az adatod nem tudod ugy "eladni", hogy az nem kritikus, akkor az Auditor atlat a szitan...

 

Amugy meg, valoban nem ir elo semmit a szo "konkret" ertelmeben :) A NIS2 nem mondja hogy "igy csinald, vagy ugy csinald" azt mondja, hogy HA igy csinalod, vagy HA ezed vagy azod az adatod van AKKOR azt igy KELL csinalni. 

Tudsz egy példát mondani egy nis2 kötelezett cég esetében, hogy semmilyen adata nem éri ezt a kritikussági szintet, hogy backupolni kelljen?

Én nem állitottam, hogy nis2-ben benne lenne, hogy igy vagy úgy csináld, de az költői túlzás, hogy emiatt bármit "ki lehet magyarázni". Nem lehet. Egy rakás macerás dolognak meg kell legyen (amiből a backup a legkönnyebb) ami nélkül tök kizárt, hogy átmenj egy auditon.

Termeszetesen ilyen (komoly) ceg nem letezik :) 

 

A hozzaszolasom arra iranyul, hogy a NIS2 magaban nem ir elo semmit, termeszetesen viszont egy ceg alapveto mokodese (napjainkban) elkepzelhetetlen anelkul hogy ne legyen benne olyan resz, amit a NIS2 megkovetelhet (rendes backup, access management etc...)

Amire en gondolok, egy peldaval leirva:

A NIS2 nem koveteli meg azt, hogy teszem azt informatikai rendszerben tarold a dolgozok adatait, te ezt tarolhatod sima kartotekokban, mappakban is, mint a 50 es evekben... Nyilvan 2025-ben ez nem eletszeru, a pelda azt mutatja, nem kotelezo semmi, ha az alternativ megoldas tudja hozni ugyanazt a biztonsagi szintet.

Vagy mas pelda: 

Ha te uzemeltetsz egy "profi" kulcsos rendszert, ami megfelel minden kitetelnek, akkor nem kell megfeleloen titkositott kartyakkal dolgozo door sec. rendszert beepiteni. DE ha neked vagy egy rosszul mukodo door sec. rendszered, akkor az Audit mar megkoveteli a helyes mukodest.

Vagy pl:

1. Van egy AD, amiben a jelszo policy eloirja a 3 havi jelszo modositasi a kotelezettseget

2. Nincs AD, de hozol egy szabalyt, hogy minden felhasznalo koteles 3 havonta jelszot valtoztatni (ennek elmulasztasa meg akar fegyelmit is vonhat maga utan), ezt leoktatod a munkavallaloknak, lejegyzokonyvezed az oktatast, ezt ala is iratod. 

 

Ez a ket pont audit szempontjabol egyarant elfogadhato, mig a valosagban a 2. bont sokkal tobb biztonsagi kockazatot jelent.

Ez jogos de:

- Elso esetben ez egy automatikus dolog, amit nem tud a dolgozo megkerulni

- A masodik esetben viszont ott az "emberi tenyezo", ami a lagnagyobb hibafaktor minden esetben... 

Ha belegondolsz ha megtortent a baj es valaki jelszava kompromittalodott, mert nem valtoztatta meg idoben, akkor johet a felelossegre vonas meg minden, de az a helyzeten mar nem valtoztat sajna...

Detto. 

Főleg mikor a dolgozó szarrá van szopatva szekuritivel, de a munkáltató semmilyen segítséget nem akar nyújtani h. az a kurva szekuriti a dolgozó oldalán ne életnehezítő napi szintű gyötrelem legyen. Pl. nem megjegyezhető (sem a humán fejében, sem a browser form-ban) 24 hosszú nem-nyomtatható karakterek, de password manager nincs hozzá v. nem használhatsz. A session meg lejár 180 másodperc(!) után.

Ez alkoholpazarlás! A jelszót fekete grafittal a fekete billentyűzet aljára írjuk, hogy jó szögben tartva látszódjon, a filcet pedig megisszuk.

3 havonta pedig billentyűzet csere a szomszéddal, mert az AD azt mondja, hogy változtatni kell. Hát, jó. :-)

Policy-ra: Ilyenkor szoktak jellemzően "elővenni" külföldi (USA) biztonsági ajánlásokat/szabványokat és azokat "majmolni". ;)

Azért, papíros vagy nem papíros valami... "papírozni" (működtetni) kell menedzsment és kontroll/audit rendszert is, ha egyszer megfelelt valami - nem csak letudni az indulást. :)

van igen. 

 

nalunk:

 

- nem lehet ugyanaz mint az elozo harom

- Kis/nagybetu, spec karakter, szam kell bele

- legalabb 8 karakteres legyen

- nem tartalmazhat a ceges "blacklist"-en es a szemelyesen talalhato kifejeseket (mint cegnev, telephely nev, vagy keresztnev, vezeteknev, etc...)

 

Ez az Auditra felkeszito ceg szerint mar megfelelo.

Erzem en az ironiat a kommentjeidben de azert ezeket a szabalyokat nem en hoztam :) (csak probalom betarthatova tenni, hogy megfeleljunk az auditon) 

 

Nalunk az egyik leanyvallalatunknal 1-2 eve volt egy komolyabb zsarolovirusos tema, ami azon a site-on leallitotta hetekre a termelest... Azota erosen biztonsag kozpontu lett a ceg, elkezdett fosni az osszes leanyvallalat meg az anyaceg is...

( ssikiss | 2025. 08. 13., sze – 07:40 )

Már onnan kezdődik a játék, hogy mit/miket értesz EIR alatt a definíció alapján...

(Mert az nem egy *informatikai*, hanem jogi szöveg.) :)

Ez nagy eséllyel az öntökönlövés esete akkor, ha ez nem egy globális vállalat. (eir != informatikai rendszer)

Szerintem érdemes lenne újra megtekinteni az eir fogalmát nem informatikus szemmel, mert igazából az kellene az épp eszű célnak lenni, hogy minél kevesebb EIR legyen. ;)