Az adatvédelmi incidensek valódi próbája: mikor értesít a beszállító?

Amikor egy külső elemzési szolgáltatónál ügyfélkapcsolati adatok szivárognak ki, a szabályozó hatóságok, az újságírók és az aggódó felhasználók előtt jellemzően nem a szolgáltatónak kell magyarázkodnia. Hanem annak a vállalatnak, amelynek a neve az incidenshez kapcsolódik, és amelynek a bejelentési kötelezettségei már akkor életbe lépnek, amikor elegendő információval rendelkezik ahhoz, hogy megkezdje a szükséges intézkedéseket.

A TradingView október 30-án arról számolt be, hogy a Coinbase megerősített egy, az elemzési szolgáltatóját, az Amplitude-ot érintő incidenst. Az eset a Coinbase ügyfeleinek egy kisebb csoportjához kapcsolódó elérhetőségi adatokat érintett. A Coinbase közlése szerint saját rendszereihez nem történt jogosulatlan hozzáférés, és „az ügyfelek pénzeszközei biztonságban maradtak”. A vállalat azt is jelezte, hogy az érintett felhasználók megkapják a szükséges tájékoztatást.

Érdemes elidőzni ennél a helyzetnél. Nem történt jogosulatlan hozzáférés a kriptotőzsde rendszereihez, nem ürítettek ki digitális pénztárcákat, és a letétkezelési rendszerek sem kerültek közvetlenül veszélybe. Ennek ellenére nyilvános tájékoztatásra, az érintett felhasználók értesítésére és a vállalat megítélését befolyásoló piaci kommunikációra is szükség van. A TradingView megjegyzi, hogy a vállalat egyelőre nem tett közzé átfogó tájékoztatást arról, pontosan milyen adatmezők érintettek, illetve hány ügyfelet érintett az incidens.

Az adatkezelés felelőssége az adatokkal együtt mozog

Egy ilyen hír hallatán könnyű arra a következtetésre jutni, hogy ha a szolgáltatói incidens nem érintette az ügyfelek pénzét, akkor a megszokott biztonsági intézkedések elegendőek. A cikk azonban egy fontos mechanizmusra világít rá: a kiszivárgott elérhetőségi adatok attól még nem veszélytelenek, hogy egyetlen pénzösszeg sem tűnt el.

A csalók felhasználhatják az e-mail-címeket vagy telefonszámokat arra, hogy meggyőző megszemélyesítő üzeneteket küldjenek, megpróbálják visszaszerezni a fiókok feletti hozzáférést, vagy ügyfélszolgálati munkatársnak adják ki magukat. A tényleges kár sokszor csak később jelentkezik: egy adathalász üzenetben vagy egy hitelesítési kódot kérő megkeresésben, amely éppen annyi valós információt tartalmaz, hogy ismerősnek és megbízhatónak tűnjön.

Egy több ezer beszállítóval dolgozó szervezet számára éppen ez a később jelentkező kockázat jelenti a legnagyobb kihívást. A saját informatikai infrastruktúrán belül nem feltétlenül észlelhető, ha egy csaló egy kiszivárgott elérhetőségi adat felhasználásával felhívja a pénzügyi osztály munkatársait. Amit viszont a szervezet ellenőrzése alatt tarthat, az az, hogy a beszállító eleve mennyi és milyen részletességű adatot kezel, illetve milyen gyorsan értesíti a vállalatot, ha ezek az adatok illetéktelen kezekbe kerülnek.

Az adatmezőket már a szerződéskötés során térképezze fel

A legtöbb szervezet még a szerződés aláírása előtt feltesz bizonyos információbiztonsági kérdéseket a beszállítónak. Arra azonban jóval kevesebben tekintenek önálló biztonsági kontrollként, hogy pontosan milyen adatmezőket adnak át a szolgáltatónak.

A TradingView által említett területek – az elemzés, a kommunikáció és az ügyféltámogatás – mind olyan adatokat kezelnek, amelyek nemcsak az ügyfelek azonosítására, hanem a velük fennálló kapcsolat előzményeinek feltérképezésére is alkalmasak. Egy elemzési szolgáltató például ügyfélazonosítókat, időbélyegeket, eszközadatokat vagy fiókbeállításokat is tárolhat. Egy ügyféltámogatási szolgáltató pedig olyan beszélgetéseket őrizhet, amelyekben az ügyfelek rendelési számokat vagy akár fiók-helyreállításhoz kapcsolódó kódokat is megosztottak.

Minden további adatmező újabb lehetőséget ad arra, hogy a támadók még meggyőzőbb pszichológiai manipulációs kísérleteket hajtsanak végre. Egyúttal az is változik, hogy egy esetleges adatszivárgás esetén milyen kötelezettségei keletkeznek a szervezetnek.

Éppen ezért a beszállítóknál kezelt adatok feltérképezését nem egyszeri táblázatkitöltésként, hanem folyamatosan működtetett programként érdemes kezelni. Egy menedzselt harmadik fél kockázatkezelési program lehetővé teszi, hogy a korlátozott kapacitással rendelkező csapatok elsősorban azokra a beszállítókra összpontosítsák az ellenőrzési erőforrásaikat, amelyeknél a kezelt adatok kombinációja a legsúlyosabb következményekkel járhat. Mindezt úgy, hogy az egyes megállapítások ellenőrzése is megtörténik, mielőtt azok eljutnának a szervezethez.

A bejelentési kötelezettséget meghatározó szerződéses megfogalmazás maga a kontroll

A legtöbb beszállítói szerződés tartalmaz valamilyen rendelkezést az incidensek bejelentéséről. A valódi biztonsági kontroll és az egyszerű ígéret közötti különbség azonban a fogalmak pontos meghatározásában rejlik.

Egy olyan szervezet esetében, amely nem rendelkezik éjjel-nappal elérhető beszállítói információbiztonsági csapattal, a szerződésnek egyértelműen meg kell határoznia, mit jelent a haladéktalan értesítés akkor, ha a szolgáltató péntek este észlel egy gyanús eseményt.

Mikor kezdődik a bejelentési határidő? Már akkor, amikor a szolgáltatóban megalapozott gyanú merül fel, vagy csak akkor, amikor a kiváltó okot is sikerült teljes bizonyossággal azonosítani? A szerződés kiterjed a vállalat ügyfeleinek és munkavállalóinak adataira is, vagy kizárólag a szolgáltató saját adatállományát védi? Mennyi lehet a legnagyobb időeltérés a megerősített adatkitettség és aközött, hogy a szolgáltató értesíti azt a szervezetet, amelynek az incidens következményeiért helyt kell állnia?

Az európai szabályozás ezek közül több kérdést is konkrétan rendez. A GDPR a személyes adatok feldolgozását végző adatfeldolgozók számára is előírja, hogy indokolatlan késedelem nélkül értesítsék az adatkezelőt a tudomásukra jutott adatvédelmi incidensről. A DORA pedig megköveteli a pénzügyi szervezetektől, hogy az információs és kommunikációs technológiai (IKT) külső szolgáltatókkal kötött szerződéseikben meghatározzák az incidensek bejelentésére vonatkozó kötelezettségeket. Az, hogy ezek az előírások egy adott beszállítói kapcsolatra pontosan hogyan alkalmazandók, többek között az érintett ágazattól, az adatkezelési szerepköröktől és a vállalat méretétől is függ. Ezért a szervezeteknek saját szerződéseikre vonatkozóan kell ellenőrizniük a követelményeket, nem pedig ellenőrzés nélkül átvenniük egy általános sablont.

Az egyes beszállítói szintekre vonatkozó kötelezettségek feltérképezése végső soron ugyanahhoz a szerződéses adatjegyzékhez kapcsolódik, amelyre az információbiztonsági munka is épül.

Amikor legközelebb egy beszállítónál ügyfélkapcsolati adatok szivárognak ki, a nyilvánosságot nem fogja megnyugtatni az az érv, hogy az ügyfélpénzek és az alapvető rendszerek érintetlenek maradtak. A kérdés az lesz, hogy a szervezet miért nem tudta néhány órán belül megmondani, kiket érintett az incidens, és pontosan milyen adatokat tárolt a szolgáltató.

A következő szerződéshosszabbítás előtt tegyen fel minden elemzési, ügyféltámogatási és kommunikációs szolgáltatónak egyetlen kérdést: ha ügyfélkapcsolati adatok kerülnek illetéktelen kezekbe, mennyi időn belül értesítik erről a szervezetet?