Egy láthatatlan hiba, és megállhat a cég: brutális ára lehet egy IT-támadásnak

Egyre több olyan esetről hallani, amikor egy kibertámadás vagy akár egy egyszerűbb IT-incidens túlmutat a technikai problémán, és konkrét üzleti leálláshoz vezet. Egy ilyen esemény ma már egy vállalat hosszú távú működését, akár a létét is veszélyeztetheti?

Szekér Zoltán: Igen, és a legnagyobb probléma, hogy ezt még mindig alábecsülik a cégek. Sok helyen továbbra is technikai kérdésként kezelik a kibertámadásokat, amit majd az IT részleg „megold”. De vajon a vállalat képes-e a kibertámadást követően elfogadható időn belül visszaállítani a működését? Ha nincs friss mentés, tesztelt visszaállítási folyamat, vagy üzletmenet-folytonossági terv, akkor lényegesen több idő eshet ki a termelésből.

Csökken az árbevétel, sérülnek az ügyfélkapcsolatok, akadozik a szerződéses teljesítés, és végső soron veszélybe kerülhet a fennmaradás.

Ezt sokan csak akkor értik meg, amikor már bekövetkezett a baj. Előfordult olyan eset, ahol egy ransomware támadás (a támadók titkosítják a cég adatait, majd pénzt kérnek a visszaállításért – szerk.) után minden titkosításra került, a helyi gépek, a NAS (hálózati adattároló – szerk.) és még a felhőben tárolt állományok is. Továbbra is gyakori tévhit egyébként, hogy ami felhőben van, az automatikusan biztonságban van. Az adott céget végül az mentette meg, hogy két nappal korábban elküldték egy külső partnernek azt az Excel-fájlt, amelyen a teljes működésük alapult. Ez nyilván nem felel meg sem adatvédelmi, sem compliance szempontból, mégis ez lett az egyetlen működő „backup”. 

És itt jön be az üzleti oldal. Amíg nincs incidens, addig egy mentési rendszer, egy redundáns infrastruktúra vagy egy biztonsági oktatás sok vezető szemében pusztán költségtétel. Amikor viszont leáll a működés, kiderül, hogy ezek valójában a működés, és sokszor a túlélés biztosítékai. 

Sükösd Péter: Ami a vállalati compliance-t illeti, korábban a fókusz elsősorban a külső és belső szabályoknak való megfelelésen volt, ma viszont az üzletmenet-folytonosság, az IT-biztonság, az incidenskezelés és a reziliencia ugyanennek a kockázati térnek a része. Egy incidens után már nem elég azt vizsgálni, történt-e jogsértés vagy szükséges-e hatósági bejelentés. Azt is látni kell, hogy a szervezet 

rendelkezik-e olyan működő kontrollokkal, amelyekkel a kár mérsékelhető és az üzletmenet helyreállítható.

Ebben az értelemben a compliance a jogi funkción túl a működés egyik kontrollpontja is lett második védelmi vonalként. A szabályozás is ebbe az irányba mozdult, és a NIS2 vagy a DORA logikája már nem egyszerűen azt kérdezi, hogy van-e szabályzat vagy policy, hanem azt, hogy ténylegesen működik-e a cselekvési lánc: van-e incidenskezelési rend, van-e riportálási kötelezettség, kijelölt felelős, tesztelt visszaállítás. Vagyis ma már önmagában kevés a papíron való megfelelés, azt is bizonyítani kell, hogy a szervezet egy incidens elszenvedése esetén is működőképes tud maradni. 

A szakemberek sokszor azzal érvelnek, hogy egy néhány napos leállás már kritikus határnak számít, de egy pár órás kiesés is jelentős veszteséget okozhat – ezek valós nagyságrendek? Számolnak ezekkel a kockázatokkal a vezetők?

Szekér Zoltán: Ezek nagyon is valós veszélyek. Egy konkrét hazai gyártó cégnél például az egy órás kiesést több tízmillió forintos veszteségre becsülték, és ebben még nincs benne a beszállítói lánc hatása, a szerződéses kötbérek vagy a reputációs kár. A nemzetközi példák ugyanakkor azt mutatják, hogy a tényleges kár ennél jóval nagyobb is lehet, különösen akkor, ha a leállás elhúzódik vagy több rendszert érint. A gond ott kezdődik, hogy ezek a számok ritkán jelennek meg strukturált formában a vállalati döntéshozatalban. A beruházási oldalon egy biztonsági fejlesztés, például egy redundáns rendszer azonnali költségként jelenik meg, míg a kiesés kockázata egy feltételes, jövőbeli esemény. Emiatt a vezetői döntések gyakran torzulnak,

a biztos költséget inkább nem vállalják, a bizonytalan jövőbeni veszteség lehetőségét pedig figyelmen kívül hagyják.

Csakhogy az IT-biztonság és az üzletmenet-folytonosság területén nagyon nehéz klasszikus megtérülést számolni, mert a legnagyobb érték pont az, ami nem történik meg. Egy jól működő phishing-teszt (adathalászat – szerk.), egy időben észlelt támadás, vagy egy sikeres visszaállás nem jelenik meg bevételként, mégis konkrét veszteséget előz meg. Pedig ezek a kockázatok modellezhetők is lennének. Sok vállalkozásnál viszont még az alapok felmérése sincs meg, nem tudják pontosan, melyik rendszerük kritikus, mennyibe kerül egy folyamat kiesése, vagy, hogy egy mentés valóban visszaállítható-e. Így nagyon nehéz bármilyen kockázatarányos döntést hozni. A gyakorlatban a szükséges beruházások sokszor addig maradnak el, amíg egy incidens rá nem kényszeríti a szervezetet a valósággal való szembenézésre. 

Az adatot ma már sokan a gazdaság egyik legfontosabb erőforrásának tartják, gyakran elhangzik, hogy ez a modern kor aranya. A cégek így kezelik a saját adataikat, megtesznek minden szükségeset a védelmükben?

Szekér Zoltán: A gyakorlatban sok esetben nem. A vállalatok jelentős része nem látja át a saját adatvagyonát, sem annak tartalmát, sem az értékét, sem a kitettségét. Kritikus üzleti folyamatok sokszor egyszerű Excel-fájlokban vagy rendezetlen fájlstruktúrákban élnek. Nem tudják hány példány létezik, melyik verzió az érvényes, ki fér hozzá, vagy, hogy ezek az adatok hol jelennek meg a szervezeten kívül. Így az adat gyakorlatilag kontroll nélkül mozog. 

Sükösd Péter: Ez nemcsak adatvédelmi kérdés. Ha ilyen adatok kikerülnek, az közvetlen versenyjogi kockázatot is jelenthet, hiszen szenzitív üzleti információk kerülhetnek illetéktelen kezekbe. Sokszor nem is rosszindulatból történnek az ilyen esetek, hanem azért, mert a szervezet nem határozta meg világosan, ki milyen adatkörökhöz férhet hozzá és milyen célból használhatja azokat. 

Ennek lehet az az egyenes következménye, hogy bárki, így arra nem jogosultak is hozzáférnek olyan információkhoz, amelyek valójában szenzitív adatok – legyen szó akár üzleti titkokról vagy versenyjogi értelemben vett szenzitív információkról. Ha ezek az adatok továbbosztásra kerülnek, például nyilvános AI-rendszerekbe történő feltöltéssel, akkor ez már – a belső szabályzatsértés mellett – kártérítési és/vagy büntetőjogi kockázatokat is felvet.

Ha ez nincs szabályozva, akkor az sem világos, hogy mit kell védeni, és egy incidens után mit kell pontosan helyreállítani.

Ilyenkor derül ki, hogy a működés valójában néhány „láthatatlan” fájlon múlik. És ebben az értelemben az adatvagyon feletti kontroll hiánya IT-, compliance- és alapvető üzleti kockázatot is jelent. 

Shadow IT, illetve Shadow AI jelenségnek nevezzük, ha a munkavállalók kontroll nélkül használnak külső rendszereket, nyilvános felületekre töltenek fel belső céges adatokat, ezzel akaratlanul is új compliance és üzleti kockázatokat generálva. Valóban ez ma az egyik legnagyobb probléma?

Szekér Zoltán: Pontosabban a leggyorsabban növekvő és legnehezebben kezelhető, hiszen nem rosszindulatból fakad, hanem hatékonysági kényszerből. A munkavállaló egyszerűen csak gyorsabban és jobban akarja elvégezni a feladatát, mint amit a vállalati rendszerek lehetővé tesznek. Egy új belépő munkavállaló, különösen a fiatalabb generáció, teljesen természetesnek veszi, hogy AI-eszközöket használ. Nem azt nézi, hogy ez megfelel-e a belső szabályzatoknak, hanem azt, hogy hatékony-e. Ha a céges laptopon nem ér el egy AI-eszközt, akkor kimásolja az adatot, feltölti egy külső rendszerbe, és ott oldja meg a problémát. Ezzel viszont

teljesen kikerülik a vállalati kontrollt, az IT nem látja, a compliance nem tud róla, nincs naplózás, nincs hozzáférés-kezelés, nincs auditálhatóság.

Ez a klasszikus Shadow IT logika, amit az AI csak felerősített: a technológia sokkal gyorsabban terjed, mint ahogy a szervezet képes lenne lekövetni.  

Sükösd Péter: A Shadow IT-AI gyakorlat a konkrét incidensekben válik igazán plasztikussá. Ilyenkor több kockázati szint is megjelenik egyszerre. Egyrészt adatvédelmi kérdésről beszélünk, ha személyes adatok kerülnek ki, másrészt üzleti titok megsértése is egyértelműen felmerülhet, ami büntetőjogi felelősségi kérdésköröket is felvet. Harmadrészt versenyjogi kitettség is kialakulhat, ha szenzitív piaci információk, például árképzési adatok kerülnek mindenféle korlátozás nélkül illetéktelen helyekre feltöltésre. 

A nehézség az, hogy ezek az esetek jellemzően utólag derülnek ki. A compliance klasszikus működése szerint ilyenkor eljárás indul, az egyedi felelősség azonosítható, és szankció is alkalmazható. 

De ez már egy reaktív működés, a jogsértés megtörtént, az adat kikerült, a kockázat realizálódott.

Ezért válik kulcskérdéssé a megelőzés. A compliance-nek ezért – az internal control, mint első védelmi vonalbeli funkcióval együttműködve – szabályzatokat kell alkotnia, és emellett képzéseken, kontrollokon, valamint akár technológiai megoldásokon keresztül is fel kell készítenie a szervezetet arra, hogy ezeket a helyzeteket képes legyen elkerülni. 

Az IT-incidensek kapcsán a legtöbb esetben a technológiai hibák mellett téves emberi döntések és szervezeti hiányosságok is megjelennek. Mi szokott a gyenge láncszem lenni, hol szokott a leggyakrabban hibázni a rendszer? 

Szekér Zoltán: A legtöbb esetben valóban nem a technológia a gyenge pont, hanem az emberek, illetve a szervezet működése. Nagyon szeretünk arról beszélni, hogy milyen támadások vannak, milyen eszközöket használnak a hackerek, de a valóság az, hogy ezek a támadások szinte mindig a kiszámítható emberi viselkedés kihasználásával működnek. Tipikusan kitett helyzet, amikor fáradtan, nyomás alatt dolgozunk. A céges levelezésünkbe érkező, ismerős mintázatú e-mailnél ilyenkor elmarad a feladó hitelességének ellenőrzése, és az ember úgy érzi: „ezt már csináltam”. És elküldi az adatot. Technikailag nem történt semmi különös, mégis megtörtént az incidens. 

A problémakör átfogja a fizikai biztonságot és a szervezeti folyamatokat is. Az irodai tér, és a benne található IT eszközök fizikai védelméről is gondoskodnia kell a szervezetnek. Ugyanakkor egy kilépő munkavállaló esetében korábban az volt a gyakorlat, hogy leadja a laptopot, a telefont, és elköszönünk egymástól. Ma már ez messze nem elég. Nem tudjuk, hogy milyen adatokat mentett le, milyen hozzáférései maradtak, milyen külső rendszerekbe tud belépni. A közös pont mindenhol az, hogy a technológia mellett elsősorban a működő kontroll hiányzik. 

Sükösd Péter: A kockázatok jelentős része rosszhiszeműség helyett inkább abból fakad, hogy a szervezet nem definiálta egyértelműen a működési kereteket. Egy phishing-esetnél például a munkavállalói hiba mellett azt is vizsgálni kell, hogy a szervezet biztosította-e azokat a kontrollokat és képzéseket, amelyekkel ez a hiba megelőzhető lett volna. Ugyanez igaz a fizikai biztonságra vagy a hozzáférések kezelésére is, ha nincsenek arra vonatkozóan egyértelmű vállalati protokollok, akkor a rendszer szükségszerűen sérülékeny lesz. 

A compliance szerepe ebben az, hogy ezeket a pontokat feltárja, strukturálja és segítsen kezelni őket.

Nemcsak utólag, egy incidens után, hanem előzetesen is, kockázatelemzés, képzési programok, megfelelő kontrollpontok kialakítása révén. És ide tartozik az is, hogy a különböző területek – IT, HR, jog, üzemeltetés – közötti együttműködés megvalósuljon, mert ezek a kockázatok tipikusan nem csak egyetlen tevékenységhez köthetők. 

Mindeközben a szabályozói oldal is egyre inkább a működést kéri számon, nem a dokumentációt. Ennek ellenére sok helyen még mindig az úgynevezett „checkbox compliance” dominál. Miért ilyen nehéz ebből kilépni?

Szekér Zoltán: Egy audit során gyakran elegendő bemutatni a szabályzatokat, a folyamatleírásokat, a policy-ket, és ezzel a szervezet kipipálja a követelményeket. Ez egy gyors, jól kommunikálható és viszonylag olcsó megoldás. A valós működés viszont ott kezdődik, ahol a rendszereknek ténylegesen teljesíteniük kell: amikor egy incidens bekövetkezik, amikor vissza kell állni egy mentésből, amikor működnie kell az értesítési láncnak, ahol mindenki pontosan tudja, hogy mi a feladata. Ezeket nem lehet csak papíron megoldani. 

És pont ezek azok a pontok, ahol a legtöbb szervezet elbukik. Nagyon gyakori, hogy a mentések ugyan lefutnak, de soha nem tesztelték őket éles visszaállással. Vagy van incidenskezelési folyamat, de nem egyértelmű, hogy ki, mikor, kinek és mit jelent. Egy komolyabb támadásnál vagy üzemzavarnál derül ki, hogy a rendszer mögött nincs valódi működési képesség. 

Sükösd Péter: A szabályozói környezet egyértelműen ebbe az irányba tolja a szervezeteket. A DORA vagy a NIS2 már nem a dokumentumok meglétét vizsgálja, hanem azt, hogy a kontrollok ténylegesen működnek-e. 

Nem az a kérdés, hogy van-e szabályzat az incidenskezelésre, hanem az, hogy egy incidens esetén valóban megtörténik-e a detektálás, a riportálás, a kivizsgálás és a helyreállítás.

Ez egy alapvető szemléletváltást jelent a compliance számára is. A hangsúly a formális megfelelésről áthelyeződik a működési megfelelésre, ahol a bizonyítás eszköze a dokumentáció helyett egy működő cselekvési lánc. Ide tartozik például az incidensek naplózása, a riportálási határidők betartása, a kontrollok rendszeres tesztelése vagy akár a képzések hatékonyságának mérése. 

Ugyanakkor rövid távon sok szervezet még mindig a könnyebb utat választja. A „checkbox compliance” gyorsabb, olcsóbb és kevesebb szervezeti változást igényel. A működő compliance viszont mélyebb átalakítást követel, együttműködést az IT-val, a HR-rel, az üzleti területekkel, és egy olyan kockázatalapú gondolkodást, amelyben a megfelelés már nem önmagáért, hanem a működés fenntarthatóságáért történik. És valójában itt van a különbség: az egyik modell auditot teljesít, a másik egy incidensnél is működik. 

Jogszabályi szinten a felelősség kérdése is egyre körvonalazottabb, a vezetőket bizonyos témakörök kapcsán direkt felelősség terheli. A valóságban ez mennyire eredményez szemléletváltást?

Sükösd Péter: Jogilag ma már egyértelmű a helyzet, a vezetés felelőssége a stratégiai döntések mellett kifejezetten kiterjed az IT-biztonságra, az üzletmenet-folytonosságra és az incidenskezelésre is. A NIS2 és a DORA nagyon világosan kimondja, hogy a vezetőnek biztosítania kell, hogy 

létezzen működő IT-biztonsági program, legyenek reziliencia-tervek, történjenek képzések, és megfelelő riportálási és kivizsgálási folyamatok működjenek.

Ez nem delegálható teljes mértékben. Természetesen az operatív megvalósítás az IT, a biztonsági terület vagy a compliance feladata, de a felelősség egyértelműen a vezetésnél marad. És ha ezek a rendszerek nem működnek, akkor ez szervezeti hiányosságként, adott esetben vezetői mulasztásként is értelmezhető. A compliance szerepe ebben a helyzetben kettős. Egyrészt biztosítania kell, hogy ezek a kockázatok láthatóvá váljanak a vezetés számára, másrészt adott esetben fel is kell lépnie, ha a szükséges intézkedések elmaradnak.

Szekér Zoltán: A gyakorlatban ez valódi szemléletváltást igényelne, de ez még sok helyen várat magára. Sok vezető még mindig költségként tekint az IT-ra és az IT-biztonságra, nem pedig a működés alapfeltételeként. Ez részben abból fakad, hogy az informatika fejlődése az elmúlt húsz évben folyamatos volt, de a vállalati kultúra nem követte le ezt a változást.

Ma viszont már minden üzleti folyamat az IT-ban végződik.

Egy CRM, egy ERP, egy AI-bevezetés – ezek mind IT-projektek, függetlenül attól, hogy üzleti kezdeményezésként indulnak. Ha a vezető ezt nem érti, akkor olyan döntéseket fog hozni, amelyek alulfinanszírozzák a kritikus területeket, miközben a kockázatok folyamatosan nőnek. 

A cikk megjelenését az OD&IT Solutions Kft. támogatta.

Címlapkép forrása: Portfolio