MOL Limo - Ötszáz, bizony, dalolva ment...

Az adatszivárgás védelemmel (DLP) kapcsolatos előadásaimon mindig sok kérdést kapok azzal kapcsolatban, hogy mi az hogy vétlen adatszivárgás. Persze csak kellően steril példákat szoktam felhozni, most viszont a MOL Limo (szomorú) segítségével egy kellően élettel teli példát is tudok hozni itthonról. 

Vétlen adatszivárgás

Vétlen adatszivárgásnak tekinthetők az elkövető biztonságtudatosság-hiányosságából bekövetkezett incidensek, de ide tartozhatnak az olyan események is, például amikor a felhasználó rossz címzettnek küld el egy levelet, vagy egy levél minden címzettjének válaszol anélkül, hogy azt ellenőrizné, hogy a küldendő információ megismerésére valóban rendelkezik-e minden címzett jogosultsággal.

A „vétlen” kifejezés megtévesztő lehet, hiszen a biztonságtudatosság hiánya felróható a felhasználónak, azonban a vétlen jelző ebben az esetben a nem szándékosságból, azaz a nem akaratszerű elkövetésből fakad.

MOL Limo példa

A vétlen adatszivárgás példagyűjteménye kiegészíthető azzal, hogy egy figyelmetlen munkavállaló, vagy egy rosszul konfigurált automata úgy küld ki levelet a cég/szolgáltatás ügyfeleinek, hogy BCC "titkos" másolatként akarja szerepelteti a címzetteket (hogy azok csak a saját címüket lássák), azonban hiba csúszik a számításba, és 500 email cím kerül a levél rendes címzetti mezőbe (TO), így a levelet megkapó 500 felhasználó is látja egymás email címeit. 

Szerintem ilyet a legtöbben követtek már el, még ha nem is 500 címzett esetében, de tényleg triviális hiba. Ha a BCC mezőben landolnak a címek...dehát nem ott landoltak, ötszáz, bizony, dalolva ment.

Meg lehetett volna ezt fogni?

Az ehhez hasonló vétlen adatszivárgások észlelésére és megállítására tökéletesen alkalmasak az adatszivárgás védelmi megoldások, azonban akár az email biztonsági megoldás (vagy akár a levelezőszerver) is képes lett volna ezt a malőrt megakadályozni: a legtöbb SMTP kapcsolatokra vonatkozó szabályban definiálható az egy levélen belüli címzettek száma (TO mező), azaz, hogy legfeljebb 4-5 címzett szerepelhet a TO mezőben, így az egész levelet eldobta volna az eszköz és nem kézbesíti a címzettek felé. 

Sok esetben már akkor is adatszivárgás elleni védelmi intézkedéseket valósítunk meg, amikor körültekintően konfiguráljuk a meglévő biztonsági eszközeinket, vagy ha jobb hatékonysággal használjuk ki a meglévő eszközeink képességeit. 

A MOL Limo részéről most sokkal kellemetlenebb élmények következnek. Gyorsan megírták az érintetteknek, hogy elnézést kérnek és kivizsgálják, hogyan is következhetett be ez az incidens. 

Merthogy ez az, incidens, ráadásul két kategóriába is tartozó:

  • Adatszivárgás történt, tehát IT biztonsági incidensről beszélünk, 
  • Ugyanakkor személyes adatok bizalmassága sérült, azaz adatvédelmi incidens is bekövetkezett, amely maga után vonhatja a NAIH reagálását.

Mennyire problémás ez?

Mivel biztonsági és adatvédelmi incidens, mindenképpen problémás, mert foglalkozni kell vele. Meg kellett írni az elnézést kérő levelet az érintettek felé, és hát alighanem a NAIH felé is kellett valamilyen bejelentést tenni, szóval dolgozik a DPO rendesen. 

Az érintettekkel kapcsolatban inkább magánszemélyekről van szó, mintsem vállalati címekről, legalábbis láthatóan a felhős platformok viszik a prímet.

Ha tényleg csak IT biztonsági szempontból nézem, akkor gyakorlatilag 500 újabb email címmel szaporodott a sokmilliárdos címlista, azaz főleg kéretlen levél és adathalászat következménye lehet egy ilyen eseménynek.