A CRA 24 órás bejelentési határideje nem jogi, hanem adatkezelési kihívás.

A KEV-bejegyzés reggel 9 órakor jelenik meg. Az EU kiberrezilienciáról szóló rendelete (Cyber Resilience Act, CRA) által 2026. szeptember 11-én bevezetett bejelentési kötelezettség alapján egy digitális elemeket tartalmazó termék gyártójának akár másnap reggel 9 óráig is lehet ideje értesíteni az illetékes hatóságot, ha a sérülékenységet aktívan kihasználják, vagy az incidens súlyosnak minősül. A CSO Online október 2-án megjelent cikke szerint az ezen a területen dolgozó szakemberek arra számítanak, hogy a rendelet véget vet a sérülékenységek manuális osztályozásának és kivizsgálásának.

A legtöbb olvasó ezt úgy értelmezheti, hogy a probléma a használt eszközökkel van. Valójában sokkal inkább arról szól, hogy a szervezet meghatározta-e, mit jelent az „aktívan kihasznált” sérülékenység az adott termék esetében, és hogy hol találhatók az ehhez szükséges bizonyítékok. Ez a különbség aközött, hogy a CRA-t pusztán megfelelőségi dokumentumként kezeljük, vagy mérnöki és működési változtatásként tekintünk rá.

A bizonyítékok szándékosan különböző rendszerekben találhatók

A bejelentési kötelezettség teljesítéséhez több, egymástól függetlenül működő rendszer adatait kell összevetni: a KEV-lista bejegyzését, a sérülékenységvizsgálatok eredményeit, a SIEM-rendszerből származó telemetriai adatokat, az eszköznyilvántartást és a szoftverösszetevők jegyzékét (SBOM). A CSO Online Joe Brinkley-t, a Cobalt szakértőjét idézi, aki szerint nem várható el egy elemzőtől, hogy észre vegye a KEV-riasztást, manuálisan keressen egy statikus SBOM-ban, majd a SIEM-naplókat átvizsgálva állapítsa meg, hogy az adott rendszert valóban aktív támadás éri-e.

Louise Horton, az NCC Group szakértője ugyanezt a kérdést irányítási és szervezeti oldalról közelíti meg. Szerinte az eredményes felkészüléshez érett sérülékenységkezelési folyamatokra, a termékekre és azok függőségeire kiterjedő átláthatóságra, valamint a problémák gyors és pontos azonosítására, értékelésére és bejelentésére van szükség. Van azonban egy kérdés, amelyre sok szervezet még nem adott választ: ki jogosult mindezekről kellően gyorsan dönteni?

Egy olyan szervezetnél, ahol ugyanaz a biztonsági csapat felel a termékekért és a vállalati hálózatért is, nem feltétlenül az a legnagyobb probléma, hogy hiányoznak a megfelelő eszközök. Sokkal inkább az, hogy az SBOM-ot ismerő szakember éppen egy ügyfélpanasz kezelésével foglalkozik, miközben rajta kívül senki sem tudja pontosan, melyik szerveren melyik összetevő fut. A 24 órás határidő nem teszi lehetővé, hogy a csapat megvárja a következő státuszmegbeszélést. Ha a riasztás reggel 9 órakor érkezik, előfordulhat, hogy éppen az az ügyeletes mérnök kapja meg, aki az érintett komponenst fejlesztette. Ez előnyt jelent, ha a szükséges bizonyítékok könnyen hozzáférhetők, de komoly kockázatot hordoz, ha a tudás kizárólag az illető fejében létezik.

A követelmény minden olyan termékre vonatkozik, amelyet az EU piacán értékesítenek, függetlenül attól, hogy a gyártó hol működik. Egy Európán kívüli vállalat termékfejlesztő csapata tehát ugyanúgy érintett, ha európai ügyfeleknek szállít. Ez különösen fontos azokban a régiókban, ahol a CRA-ra még mindig elsősorban európai megfelelőségi kérdésként, nem pedig napi működési feladatként tekintenek.

A triázs szabályokat az integráció előtt kell kidolgozni

Az automatizálás a kívánatos végállapot, de a munkafolyamatokat támogató eszközök csak akkor gyorsítják fel a folyamatot, ha előbb írásban rögzítik a küszöbértékeket és a döntési pontokat. Az első lépés egyszerűbb, mint azt sok csapat gondolná: egyetlen oldalon kell meghatározni, hogy az adott környezetben mi számít aktív kihasználásnak, melyik szerepkör jogosult az egyes adatforrások ellenőrzésére, és mennyi idő áll rendelkezésre az ellenőrzések elvégzésére. Ezután minden feltételt hozzá kell rendelni ahhoz a konkrét rendszerhez, amely az igazolásához szükséges adatokat tartalmazza.

Ez az összerendelés teszi az SBOM-ot a Brinkley által említett „élő adatstruktúrává”. Egy negyedévente frissített, megfelelőségi célú export nem alkalmas arra, hogy este 10 órakor megválaszoljon egy sürgős kérdést. Az SBOM-nak lekérdezhetőnek kell lennie a KEV-bejegyzéseket feldolgozó riasztási folyamatból, az eszköznyilvántartásnak pedig nem csupán a szerver nevét kell visszaadnia, hanem a termék felelősét vagy a build azonosítóját is.

Egy pénteken délután 4 órakor érkező riasztás esetében is 24 óra áll rendelkezésre. Ha a csapat nem működtet éjjel-nappal elérhető biztonsági ügyeletet, a határidő az estét és a hétvégét is érintheti. A folyamatnak ezért olyan ügyeletes mérnök számára is végrehajthatónak kell lennie, aki nem ismeri fejből az összes érintett komponenst és azok kapcsolatait. A dokumentációnak kell biztosítania azt a tudást, amely egyébként csak egy-egy munkatárs fejében lenne meg. Ezt önmagában egyetlen irányítópult sem oldja meg.

Ezen a ponton válik a rendelet egyszerű dokumentumból integrációs projektté. A feladat felépítése hasonló a fenyegetésészlelési és incidenskezelési folyamatok kialakításához: legyen riasztás, legyenek hozzáférhető bizonyítékok, és legyen olyan döntési folyamat, amelyet az ügyeletes mérnök további egyeztetés nélkül is végre tud hajtani. Azoknak a csapatoknak, amelyeknek már most is számos feladatot kell összehangolniuk az ütemtervükben, az ilyen megvalósítási munkákban nyújtanak segítséget megvalósítási szolgáltatásaink. Ezt a munkát most könnyebb indokolni, mint az első elmulasztott határidő után.

A kérdés, amely túlmutat az eszközökön

A jogi kérdés az, hogy mely termékek tartoznak a rendelet hatálya alá, és pontosan mikor kezdődik a határidő. Ezeket a kérdéseket jogi szakértőkkel kell tisztázni. A működési kérdés egyszerűbb: ha egy, a termékben használt összetevővel kapcsolatban KEV-bejegyzés jelenik meg, meg tudja-e találni a szervezet az összes érintett terméket, és még a munkanap végéig meg tudja-e erősíteni, hogy folyamatban van-e a sérülékenység aktív kihasználása?

Ha az őszinte válasz az, hogy ez valószínűleg attól függ, éppen elérhető-e a megfelelő munkatárs, akkor elsőként egyoldalas triázs specifikációt és azoknak a rendszereknek a listáját érdemes elkészíteni, amelyeknek közösen kell megválaszolniuk a szükséges kérdéseket.

Ugyanez a követelmény a beszerző szervezetekkel szemben is magasabb elvárásokat támaszt. Egy beszállítónak képesnek kell lennie bemutatni, hogyan jut el a KEV-riasztás a bejelentésig, és miként történik meg mindez 24 órán belül. Ha ezt nem tudja megmagyarázni, akkor a CRA-ra való felkészültsége egyelőre legfeljebb egy szabályzatban létezik. Ez teljesen jogos kérdés a következő beszállítói felülvizsgálat során, és végső soron a hatóság is ugyanerre lesz kíváncsi.

Ha a CRA-kötelezettségek a NIS2- vagy a DORA-előírásokkal párhuzamosan jelennek meg, érdemes ezeket ugyanabban a keretrendszer-összehangolási folyamatban áttekinteni. Így azonosíthatók az egymást átfedő hiányosságok, például a bejelentési határidők, az ellátási lánc átláthatósága és a felelősségi körök területén. Ezzel elkerülhető, hogy a CRA egy újabb, a többi megfelelőségi feladattól elszigetelt munkafolyamattá váljon.

Amikor reggel 9 órakor megérkezik az első KEV-riasztás az egyik termékükkel kapcsolatban, tegyék fel a kérdést: ki tudja délig megerősíteni, hogy a sérülékenységet aktívan kihasználják-e? Ha a válasz egyetlen ember neve, a folyamat már eleve sérülékeny. Ha viszont egy dokumentált adatforrásra és egyértelmű ellenőrzési folyamatra lehet hivatkozni, egészen más kilátásokkal vághatnak neki a következő negyedévnek.