Osobné údaje (PII) v bezpečnostných logoch: praktický postup pre GDPR, NIS2 a DORA

Bezpečnostný analytik otvára SIEM o 02:17. Upozornenie najprv vyzerá rutinne: viacero neúspešných prihlásení, úspešná relácia z nezvyčajnej IP adresy a následne séria volaní API voči koncovému bodu na export údajov zákazníka. V priebehu niekoľkých minút je incidentný kanál plný. CISO chce vedieť, či ide o prevzatie účtu. Právne oddelenie sa pýta, či logy obsahujú osobné údaje. DPO sa pýta, či sa na ID používateľa, IP adresu, identifikátor zariadenia a URL požiadaviek v SIEM vzťahuje oznámenie o ochrane osobných údajov a záznamy o spracovateľských činnostiach. Manažér compliance sa pýta, či sa logy musia zachovať na účely regulačného hlásenia. Tím starostlivosti o zákazníkov sa pýta, či zákazník môže zajtra požiadať o výmaz tých istých záznamov v logoch.

Práve tu mnohé organizácie zistia, že bezpečnostné logovanie a riadenie ochrany súkromia boli vybudované ako oddelené svety.

Bezpečnostné tímy chcú detailné logy, dlhé uchovávanie, nemenné úložisko a rýchly prístup. Tímy ochrany súkromia chcú minimalizáciu, obmedzenie účelu, prístup podľa rolí, disciplinované uchovávanie a výmaz, keď údaje už nie sú potrebné. Tímy reakcie na incidenty chcú zachovať dôkazy presne v pôvodnom stave. Preukázateľná zodpovednosť podľa GDPR vyžaduje, aby organizácia vedela vysvetliť, prečo sa v logoch osobné údaje nachádzajú, kto k nim pristupoval a ako dlho sa uchovávajú. NIS2 a DORA zvyšujú naliehavosť, pretože základné subjekty, dôležité subjekty a finančné organizácie potrebujú dostatok dôkazov na klasifikáciu incidentov, ich včasné hlásenie a preukázanie účinného riadenia rizík IKT.

Nepríjemná pravda je jednoduchá: bezpečnostné logy sú často repozitármi osobných údajov. Autentifikačné logy môžu obsahovať používateľské mená, e-mailové adresy, IP adresy, odtlačky zariadení a geolokáciu. Aplikačné logy môžu odhaľovať URL adresy, vyhľadávacie reťazce, fragmenty škodlivých payloadov, čísla prípadov a obsah správ. EDR a cloudové logy môžu zahŕňať názvy hostiteľov prepojené so zamestnancami, cesty k súborom s menami, identifikátory relácií a administrátorské akcie. IAM logy môžu odhaliť zmeny oprávnení, členstvo v skupinách a neúspešné pokusy o prístup k citlivým systémom.

Ak logy obsahujú osobné údaje (PII), už nejde iba o otázku logovania podľa ISO 27001. Stáva sa z toho téma ochrany súkromia, uchovávania, dôkazov, hlásenia incidentov a riadenia dodávateľov. Clarysec pristupuje k riadeniu osobných údajov (PII) v bezpečnostných logoch ako k problému compliance naprieč rámcami, nie ako k problému konfigurácie nástroja.

Skutočná dilema CISO: dôkazy pre detekciu verzus minimalizácia z pohľadu ochrany súkromia

CISO v scenári o 02:17 čelí skutočnému prevádzkovému konfliktu. Ak sú logy príliš obmedzené, SOC nedokáže zistiť kompromitáciu, zrekonštruovať časové osi ani podporiť hlásenia podľa NIS2 a DORA. Ak sú logy príliš bohaté, organizácia môže zbierať viac osobných údajov, než je nevyhnutné, uchovávať ich príliš dlho, sprístupniť ich príliš mnohým administrátorom alebo nedokázať podporiť práva podľa GDPR a povinnosti transparentnosti.

GDPR vymedzuje osobné údaje široko ako informácie týkajúce sa identifikovanej alebo identifikovateľnej osoby. Spracúvanie zahŕňa získavanie, uchovávanie, používanie, poskytovanie, výmaz a zničenie. V praxi môžu byť logy obsahujúce IP adresy, ID používateľov, identifikátory zariadení alebo záznamy aktivít osobnými údajmi v závislosti od kontextu. Zásady GDPR vyžadujú zákonné, korektné a transparentné spracúvanie, obmedzenie účelu, minimalizáciu údajov, obmedzenie uchovávania, integritu a dôvernosť a zároveň preukázateľnú zodpovednosť.

Otázka riadenia neznie: „Môžeme vôbec logovať osobné údaje?“ Správna otázka znie: „Aké osobné údaje (PII) potrebujeme logovať na účely bezpečnosti, reakcie na incidenty a compliance, aký právny základ ich podporuje, aké ochranné opatrenia sa uplatňujú a kedy sa musia vymazať, anonymizovať alebo zaradiť pod schválenú blokáciu výmazu?“

Knižnica podnikových politík ochrany súkromia Clarysec rieši toto napätie priamo. Politika ochrany údajov a súkromia, Požiadavky na implementáciu politiky, bod 6.2.1 uvádza:

Zhromažďovať a spracúvať sa môžu iba údaje nevyhnutné na konkrétny, legitímny účel organizácie.

Pre MSP je rovnaká zásada uvedená v Politike ochrany údajov a súkromia pre MSP, Požiadavky na implementáciu politiky, bod 6.2.1:

Zhromažďovať a uchovávať sa musia iba minimálne nevyhnutné osobné údaje.

Táto veta má riadiť každé návrhové rozhodnutie v oblasti logovania. Je každé pole v každom zdroji logov nevyhnutné na definovaný bezpečnostný, prevádzkový, právny alebo zmluvný účel?

Prečo ISO 27701 mení diskusiu o logovaní

ISO/IEC 27001:2022 poskytuje systém riadenia: rozsah, zainteresované strany, posúdenie rizík, ošetrenie rizík, prevádzkové riadenie, monitorovanie, vnútorný audit a neustále zlepšovanie. ISO/IEC 27002:2022 poskytuje praktické usmernenia ku kontrolám pre logovanie, monitorovanie, ochranu súkromia a osobných údajov (PII), získavanie dôkazov, ochranu záznamov, výmaz, riadenie prístupu a riadenie dodávateľov. ISO/IEC 27701 rozširuje model riadenia na systém manažérstva informácií o ochrane súkromia so zameraním na prevádzkovateľov a sprostredkovateľov osobných údajov (PII), roly v oblasti ochrany súkromia, záznamy o spracúvaní osobných údajov (PII), ochranu súkromia už v návrhu, vybavovanie práv a povinnosti sprostredkovateľov.

Pre bezpečnostné logy je ISO 27701 dôležitá, pretože vynucuje otázky špecifické pre ochranu súkromia, ktoré bezpečnostné tímy niekedy preskočia:

• Spracúva zdroj logov osobné údaje (PII) ako prevádzkovateľ, sprostredkovateľ, spoločný prevádzkovateľ alebo ďalší sprostredkovateľ?
• Sú údaje z logov zahrnuté v evidencii spracovateľských činností?
• Vie organizácia, ktoré polia logov obsahujú osobné údaje (PII)?
• Sú osobné údaje (PII) v logoch prepojené s pravidlami uchovávania a výmazu?
• Sú zákazníci sprostredkovateľa informovaní o logovaní prístupu k osobným údajom (PII), ak sa to zmluvne vyžaduje?
• Zohľadňujú sa logy pri vybavovaní žiadostí o prístup, výmaz alebo obmedzenie spracúvania?
• Posudzujú sa incidenty týkajúce sa osobných údajov (PII) naprieč spúšťačmi hlásenia v oblasti ochrany súkromia, kybernetickej bezpečnosti a finančného sektora?

Politika bezpečnosti osobných údajov (PII) a riadenia prístupu spoločnosti Clarysec premieňa tieto požiadavky na prevádzkové pravidlá. V časti Logovanie a monitorovanie, bod 4.6.1:

[Obe roly] Vlastník systému / vlastník aplikácie MUSÍ pred použitím v produkčnom prostredí alebo pred podstatnou zmenou definovať v REG12 rozsah logovania osobných údajov (PII) pre autentifikačné udalosti, udalosti prístupu, privilegované akcie, export osobných údajov (PII) a podstatné zmeny konfigurácie.

Bod 4.6.2 následne uzatvára väzbu medzi logovaním, riadením prístupu a uchovávaním:

[Obe roly] Vedúci informačnej bezpečnosti MUSÍ zabezpečiť, aby logy obsahujúce osobné údaje (PII) mali obmedzený prístup a boli pred začiatkom monitorovania logov prepojené so schváleným pravidlom uchovávania alebo výmazu v REG02 alebo REG12.

Tým sa riadenie PIMS stáva praktickým. REG12 definuje, aké logovanie osobných údajov (PII) je povolené a vyžadované. REG02 identifikuje, kde osobné údaje (PII) existujú, vrátane logov. Pravidlá uchovávania a výmazu nie sú dokumentáciou doplnenou dodatočne. Stávajú sa podmienkami pre produkčné logovanie.

Bezpečnostné logy sú záznamy, dôkazy a spracovateľská činnosť osobných údajov (PII)

Zrelá organizácia by nemala považovať logy za jednorazový technický odpad. Logy sú záznamy. Počas incidentu sa môžu stať právne prípustnými dôkazmi. Ak obsahujú osobné údaje (PII), ide zároveň o údaje spracúvané v režime riadenia ochrany súkromia.

Politika logovania a monitorovania spoločnosti Clarysec definuje očakávania normalizácie logov. V časti Požiadavky na správu a riadenie, bod 5.1.4:

Požiadavky na formát a normalizáciu logov (napr. časová pečiatka, ID používateľa, typ udalosti, zdrojová IP adresa)

Práve tieto polia robia logy užitočnými pre reakciu na incidenty. Zároveň ide o polia, ktoré často spôsobujú, že logy sú osobnými údajmi. Tá istá podniková politika označuje, čo sa nikdy nemá diať, v časti Požiadavky na správu a riadenie, bod 5.3.3:

Ukladanie citlivých údajov v čitateľnej podobe (napr. heslá, kryptografické tajomstvá)

Pointa nie je v tom, že logy sa majú vyhnúť všetkým identifikátorom. Pointa je v tom, že identifikátory musia byť zámerné, chránené a odôvodnené. Heslá, tajomstvá, úplné tokeny a zbytočné škodlivé payloady sa nesmú logovať. ID používateľov, IP adresy a metadáta udalostí môžu byť nevyhnutné, ale vyžadujú kontroly.

Pre MSP začleňuje Politika logovania a monitorovania pre MSP spoločnosti Clarysec preskúmanie ochrany súkromia do štruktúry rolí. V časti Roly a zodpovednosti, bod 4.3.1, vyžaduje od organizácie, aby:

Overovala, že údaje v logoch týkajúce sa osobných alebo citlivých informácií sa spracúvajú v súlade s GDPR a ďalšími právnymi predpismi o ochrane údajov.

Verzia pre MSP zároveň stanovuje jasnú základnú požiadavku na uchovávanie. V časti Požiadavky na správu a riadenie, bod 5.2.1:

Logy sa musia uchovávať najmenej 12 mesiacov, pokiaľ dlhšiu lehotu uchovávania nevyžaduje zákon alebo zmluva, alebo pokiaľ nie je odôvodnená ako súčasť aktívneho incidentu alebo právneho sporu.

A stanovuje očakávanie ochrany, v časti Požiadavky na správu a riadenie, bod 5.3.1:

Logy sa musia ukladať na miestach chránených proti zápisu a prístup musí byť obmedzený iba na oprávnený personál.

Pre podnikovú reakciu na incidenty vyžaduje Politika zberu dôkazov a forenznej analýzy, Požiadavky na implementáciu politiky, bod 6.3.1:

Logy z firewallov, SIEM, endpoint agentov, platforiem správy identít a prístupov (IAM) a cloudových platforiem sa majú exportovať a ukladať v nemenných formátoch.

Verzia pre MSP pridáva ochrannú hranicu proporcionality. Politika zberu dôkazov a forenznej analýzy pre MSP, Ošetrenie rizík a výnimky, bod 7.2.1 uvádza:

Minimalizujte rozsah zberu; zhromažďujte iba to, čo je nevyhnutné.

To je jadro logovania zohľadňujúceho ochranu súkromia: zachovať to, čo je nevyhnutné, preukázať, prečo je to nevyhnutné, obmedziť, kto to môže vidieť, a vymazať to, keď schválený účel zanikne.

Kontrolný model Clarysec pre dôkazy bezpečné z pohľadu ochrany súkromia

V Zenith Blueprint: 30-kroková cestovná mapa audítora umiestňuje Clarysec logovanie do fázy Kontroly v praxi, krok 19: Technologické kontrolné opatrenia I. Príručka vysvetľuje očakávanie kontroly podľa ISO/IEC 27002:2022:

A.8.15 – Logovanie: „Logy, ktoré zaznamenávajú aktivity, výnimky, poruchy a iné relevantné udalosti, sa majú vytvárať, ukladať, chrániť a analyzovať.“

Ten istý krok organizáciám odporúča generovať logy pre kľúčové udalosti, bezpečne ich ukladať tak, aby ich nebolo možné meniť, uchovávať ich počas definovaného obdobia a analyzovať ich prostredníctvom SIEM alebo procesu preskúmania. Zároveň prepája logovanie s oznámením porušenia ochrany osobných údajov podľa GDPR, záznamami o incidentoch podľa DORA, riadením rizík podľa NIS2 a analýzou bezpečnostných logov podľa COBIT.

Samotné logovanie však nestačí. V tej istej fáze Kontroly v praxi, krok 19, Zenith Blueprint rieši výmaz. Upozorňuje, že údaje uchovávané nad rámec prevádzkovej hodnoty zvyšujú expozíciu a regulačné riziko, a výslovne uvádza zálohy, snapshoty a archívy. Je to dôležité, pretože pravidlo uchovávania v SIEM nemá význam, ak replikované archívy logov alebo cloudové úložné kontajnery uchovávajú tie isté osobné údaje (PII) neobmedzene.

V kroku 23: Organizačné opatrenia sa Zenith Blueprint venuje zberu dôkazov. Uvádza, že incidentné dôkazy musia byť identifikované, zhromaždené a uchované spôsobom, ktorý je právne prípustný, spoľahlivý a zosúladený s potrebami vyšetrovania. Zdôrazňuje aj prevádzkovú realitu: dôkazy sa často stratia v prvých minútach reakcie, keď sa logy prepíšu, systémy sa reštartujú alebo administrátori zmenia kompromitované účty ešte pred vytvorením snapshotov.

Krok 23 rieši aj ochranu súkromia a ochranu osobných údajov (PII). Príručka rámcuje osobné údaje (PII) ako otázku životného cyklu, ktorá vyžaduje povedomie o údajoch, klasifikáciu, riadenie prístupu, maskovanie, výmaz, šifrovanie a povinnosti dodávateľov. Pre logy to znamená, že SIEM, EDR, cloudová platforma na logovanie a tiketovací systém musia byť súčasťou evidencie osobných údajov (PII).

Mapovanie compliance naprieč rámcami pre osobné údaje (PII) v logoch

Zenith Controls: príručka compliance naprieč rámcami mapuje kontrolu ISO/IEC 27002:2022 8.15, Logovanie, na súvisiace kontroly, ktoré sú nevyhnutné pre riadenie osobných údajov (PII). Tieto vzťahy ukazujú, prečo logovanie nie je iba záležitosťou SOC.

Zenith Controls mapuje Logovanie aj na bod ISO/IEC 27002:2022 8.15, ISO/IEC 27035-1 a ISO/IEC 27035-2 pre riadenie incidentov, ISO/IEC 27701 pre logovanie spracovateľských činností osobných údajov (PII), ISO/IEC 27017 pre cloudové auditné logy, ISO/IEC 27018 pre logovanie cloudového prístupu k osobným údajom (PII), ISO/IEC 27005 pre riziká z nedostatočného logovania, ISO/IEC 27033 pre logovanie sieťovej aktivity a ISO/IEC 15408-2 pre auditnú funkcionalitu v hodnotených produktoch.

Špecificky pre ochranu súkromia Zenith Controls mapuje kontrolu ISO/IEC 27002:2022 5.34, Ochrana súkromia a ochrana osobných údajov (PII), na inventarizáciu aktív, maskovanie údajov, cloudové služby, klasifikáciu, prenos informácií, riadenie prístupu, správu identít a bezpečnostné preskúmanie projektov a zmien. Pre program riadenia logov sa tieto väzby menia na praktické návrhové požiadavky:

• Evidujte úložiská logov ako miesta výskytu osobných údajov (PII).
• Maskujte alebo tokenizujte osobné údaje (PII), ak nie sú potrebné úplné identifikátory.
• Preskúmajte cloudové služby logovania a dodávateľov SIEM podľa kontrol pre cloud a dodávateľov.
• Klasifikujte logy obsahujúce osobné údaje (PII) ako citlivé záznamy.
• Riaďte exporty a prenosy logov ako prenosy osobných údajov (PII).
• Obmedzte prístup k logom prostredníctvom kontrol identity a privilegovaného prístupu.
• Preskúmajte zmeny aplikačného logovania pred vydaním do produkčného prostredia.

GDPR, NIS2 a DORA: jeden log, tri regulačné pohľady

Ten istý záznam v logu môže byť podľa GDPR, NIS2 a DORA posudzovaný odlišne.

Podľa GDPR sa organizácia pýta, či záznam v logu obsahuje osobné údaje, aký právny základ podporuje spracúvanie, či sú údaje nevyhnutné, ako dlho sa uchovávajú, kto k nim môže pristupovať, či sa poskytujú sprostredkovateľom alebo zákazníkom a či sa musia zohľadniť pri žiadosti o uplatnenie práv alebo pri posúdení porušenia ochrany osobných údajov.

Podľa NIS2 sa organizácia pýta, či logy podporujú riadenie kybernetických rizík, riešenie incidentov, kontinuitu činností, riadenie prístupu, bezpečnosť dodávateľského reťazca a posúdenie účinnosti kontrol. NIS2 Article 20 zavádza zodpovednosť riadiacich orgánov za schvaľovanie opatrení riadenia rizík kybernetickej bezpečnosti a dohľad nad nimi. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia vrátane riešenia incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, bezpečného vývoja, riešenia zraniteľností, posúdenia účinnosti, kybernetickej hygieny, riadenia prístupu a správy aktív. Article 23 zavádza fázované hlásenie významných incidentov vrátane včasného varovania do 24 hodín, notifikácie do 72 hodín a záverečnej správy do jedného mesiaca.

Podľa DORA musia finančné subjekty prevádzkovať zdokumentovaný rámec riadenia rizík IKT. DORA Article 5 prideľuje zodpovednosť riadiacemu orgánu. Article 10 sa týka detekcie. Article 17 vyžaduje proces riadenia incidentov súvisiacich s IKT. Article 18 upravuje klasifikáciu incidentov súvisiacich s IKT a kybernetických hrozieb. Article 19 rieši hlásenie závažných incidentov súvisiacich s IKT. Logy podporujú detekciu, klasifikáciu, analýzu koreňovej príčiny, posúdenie dopadu, reakciu, obnovu a dôkazy o nápravných opatreniach.

Podrobnejší prechod kontrolami pomáha CISO odôvodniť logovanie bez spoliehania sa na všeobecné tvrdenia typu „potrebujeme to pre bezpečnosť“.

Vytvorte rozsah logovania osobných údajov (PII) v REG12

Klient Clarysec by incident v SIEM o 02:17 riešil ešte predtým, ako by nastal. Organizácia začne zákaznícky orientovanou aplikáciou, ktorá spracúva údaje účtov. Pred produkciou vlastník aplikácie použije REG12 na definovanie rozsahu logovania osobných údajov (PII). Cieľom je zachytiť dostatok udalostí pre bezpečnostné a regulačné dôkazy bez logovania zbytočných osobných údajov alebo obsahu škodlivého payloadu.

Následne vedúci ochrany súkromia potvrdí, či organizácia pri každom zdroji logov koná ako prevádzkovateľ, sprostredkovateľ alebo oboje. Ak je organizácia sprostredkovateľom, pokyny zákazníka a informovanie o ďalších sprostredkovateľoch môžu obmedzovať prístup k logom a ich zdieľanie. Ak je prevádzkovateľom, musia sa riešiť oznámenia o ochrane osobných údajov, právny základ a vybavovanie práv.

Vlastník údajov potom aktualizuje REG02 tak, aby zahŕňal živé úložiská logov, indexy SIEM, archívy, zálohy a dočasné forenzné exporty. To je v súlade s Politikou uchovávania, výmazu a likvidácie osobných údajov (PII), Zálohy, archívy, repliky, logy a dočasné súbory, bod 4.4.1:

[Obe roly] Vlastník systému / vlastník aplikácie MUSÍ pred spustením do produkčného prostredia a počas každého ročného preskúmania uchovávania identifikovať v REG02 živé úložiská, archívy, záložné kópie, repliky, logy, stagingové prostredia a dočasné súbory obsahujúce osobné údaje (PII).

Politika uchovávania a likvidácie údajov by potom mala zosúladiť pravidlá uchovávania organizácie so zákonnými, zmluvnými a dôkaznými požiadavkami na uchovanie.

Nakoniec bezpečnostný tím nakonfiguruje SIEM tak, aby sa heslá, tajomstvá a telá škodlivých payloadov pred prijatím do SIEM zahadzovali alebo začierňovali. Logy obsahujúce osobné údaje (PII) sa priradia do obmedzených indexov. Uchovávanie sa uplatňuje automaticky, pokiaľ nie je schválená incidentná alebo právna blokácia. Akcie výmazu sa logujú. Forenzné exporty vyžadujú schválenie a sledovanie reťazca zverenia. Prehľady zobrazujú pseudonymizované identifikátory tam, kde úplná identita nie je potrebná. Vyhľadávanie v historických logoch sa testuje počas vnútorných auditov.

To je rozdiel medzi tvrdením „logujeme pre bezpečnosť“ a preukázaním „logujeme iba to, čo je nevyhnutné, chránime to, uchovávame podľa schválených pravidiel a môžeme to použiť ako dôkaz bez porušenia povinností ochrany súkromia“.

DSAR, výmaz a logy: rozhodnite ešte pred doručením žiadosti

Jednou z najťažších otázok je, či sa logy musia prehľadávať, poskytovať alebo vymazávať v reakcii na žiadosti dotknutej osoby o prístup k osobným údajom alebo žiadosti o výmaz. Odpoveď závisí od roly, účelu, právneho základu, uskutočniteľnosti, výnimiek a povinností uchovávania. Proces riadenia však nemožno vymýšľať osobitne pri každej žiadosti.

Politika správy práv dotknutých osôb, Overenie identity, rozsah a hodnotenie, bod 4.2.3 uvádza:

[Prevádzkovateľ] Vlastník procesu / vlastník organizácie MUSÍ pred posúdením vybavenia žiadosti identifikovať z REG02 relevantné systémy, záznamy, účely, kategórie osobných údajov (PII), príjemcov a obmedzenia uchovávania.

To znamená, že logy musia byť v REG02 s jasnými metadátami: aké kategórie osobných údajov (PII) obsahujú, akému účelu slúžia, aké obmedzenie uchovávania sa uplatňuje a či možno žiadosť vybaviť priamym poskytnutím, zhrnutým prístupom, obmedzením, výmazom po uplynutí lehoty alebo odmietnutím na základe zdokumentovaného právneho dôvodu.

Clarysec odporúča trojúrovňový prístup:

1. Prevádzkové logy s nízkym dopadom na ochranu súkromia, napríklad systémové event logy používajúce pseudonymné ID používateľov, môžu byť podľa okolností vyhľadateľné a poskytnuteľné.
2. Bezpečnostné logy s vysokou bezpečnostnou citlivosťou, napríklad korelačné údaje SIEM alebo kontext spravodajstva o hrozbách, môžu vyžadovať filtrovanie, zhrnuté poskytnutie alebo obmedzenie, aby sa neodhalila detekčná logika alebo údaje tretích strán.
3. Forenzné dôkazy pod aktívnym incidentom alebo právnou blokáciou sa nemajú rutinne meniť. Výmaz možno odložiť alebo obmedziť, ak je to právne odôvodnené, pričom rozhodnutie zdokumentujú zainteresované strany z oblasti ochrany súkromia a právneho oddelenia.

Ak DPO a SOC diskutujú o každej žiadosti DSAR od začiatku, organizácia bude nekonzistentná a pomalá. Ak sa REG02 a REG12 udržiavajú, vybavovanie práv je založené na dôkazoch.

Porušenie ochrany osobných údajov a hlásenie incidentov: jedna udalosť, viacero lehôt

Upozornenie o 02:17 môže spustiť viacero lehôt. Posúdenie porušenia ochrany osobných údajov podľa GDPR môže vyžadovať oznámenie dozornému orgánu, ak sú splnené prahové hodnoty rizika. Hlásenie významného incidentu podľa NIS2 môže vyžadovať včasné varovanie do 24 hodín, notifikáciu do 72 hodín a záverečnú správu. DORA môže vyžadovať hlásenie závažného incidentu súvisiaceho s IKT v počiatočnej, priebežnej a záverečnej fáze. Zákaznícke zmluvy môžu mať ešte kratšie notifikačné lehoty.

Politika riadenia incidentov a porušení ochrany osobných údajov (PII) spoločnosti Clarysec rieši tento problém viacerých spúšťačov priamo. V časti Klasifikácia a posúdenie porušenia ochrany osobných údajov, bod 4.2.6:

[Podmienené] Vedúci ochrany súkromia / manažér PIMS MUSÍ pri každom incidente s vysokým dopadom týkajúcom sa osobných údajov (PII) vyhodnotiť uplatniteľné právne, odvetvové, finančno-sektorové, kybernetickobezpečnostné, zmluvné, zákaznícke spúšťače hlásenia a spúšťače voči príjemcom služby a zaznamenať výsledok uplatniteľnosti v REG01, REG08 a REG10.

Počas triáže by sa organizácia mala pýtať:

• Pristúpil útočník k osobným údajom alebo iba k metadátam?
• Sprístupnili logy ďalšie osobné údaje (PII) neoprávneným používateľom?
• Sú logy potrebné na určenie dotknutých osôb, systémov a časového rámca?
• Sú logy uložené nemenne a s obmedzeným prístupom?
• Pozastavila incidentná blokácia výmaz relevantných logov?
• Sú dotknutí zákazníci sprostredkovateľa, zákazníci z finančného sektora alebo príjemcovia služby?
• Ktoré lehoty na hlásenie sa uplatňujú a kto vlastní každú notifikáciu?

Dobre riadené logy urýchľujú hlásenie, pretože rozhodujúcim osobám poskytujú spoľahlivé fakty. Slabé logovanie spôsobuje oneskorenie. Nadmerné logovanie vytvára riziko ochrany súkromia. Správnou odpoveďou je cielené, chránené a zmapované logovanie.

Dodávateľské a cloudové logovanie: problém sprostredkovateľa ukrytý vo vašom SIEM

Väčšina organizácií neukladá všetky logy v infraštruktúre, ktorú plne kontroluje. Logy prúdia do platforiem SIEM, portálov EDR, cloudovo natívnych služieb logovania, nástrojov observability, tiketovacích systémov a poskytovateľov riadenej detekcie a reakcie (MDR). Podľa GDPR môžu byť títo poskytovatelia sprostredkovateľmi alebo ďalšími sprostredkovateľmi. Podľa NIS2 a DORA môžu byť zároveň priamymi dodávateľmi, externými poskytovateľmi služieb IKT, poskytovateľmi spravovaných služieb alebo poskytovateľmi spravovaných bezpečnostných služieb.

NIS2 Article 21 výslovne zahŕňa bezpečnosť dodávateľského reťazca, zraniteľnosti dodávateľov a celkové postupy kybernetickej bezpečnosti dodávateľov. DORA pridáva podrobné požiadavky na riziko IKT tretích strán pre finančné subjekty vrátane predzmluvného preverenia, informačných registrov, práv na audit a prístup, podpory pri incidentoch, umiestnenia údajov, doložiek o ochrane údajov, stratégií ukončenia a zmluvných ustanovení pre kritické alebo dôležité funkcie.

Pri osobných údajoch (PII) v bezpečnostných logoch by preskúmania dodávateľov mali zahŕňať tieto otázky:

Zmluva na SIEM nie je iba predplatné softvéru. Je to závislosť spracúvania osobných údajov (PII) a incidentných dôkazov.

Auditný pohľad: ako posudzovatelia testujú osobné údaje (PII) v bezpečnostných logoch

Dobrý audítor neprijme tvrdenie, že „logy sú chránené“. Otestuje reťazec od politiky cez konfiguráciu a dôkazy až po preskúmanie.

Praktický auditný test je jednoduchý, ale veľa odhalí: požiadajte SOC, aby vyhľadal záznam v logu spred desiatich mesiacov, ktorý ukazuje zmenu privilegovaného prístupu v cloudovej platforme, preukázal, kto k tomuto logu pristupoval, preukázal, že nebol zmenený, ukázal pravidlo uchovávania, ktoré umožnilo jeho existenciu, ukázal polia osobných údajov (PII), ktoré obsahuje, a vysvetlil, ako by sa s ním naložilo pri DSAR alebo v incidentnej správe. Ak tím nedokáže odpovedať naprieč bezpečnosťou, ochranou súkromia a compliance, riadenie je neúplné.

Bežné zistenia pri auditoch logov obsahujúcich osobné údaje (PII)

Clarysec často vidí rovnaké vzorce:

• Aplikačné tímy logujú úplné škodlivé payloady požiadaviek na ladenie vrátane mien, e-mailov, čísel účtov alebo obsahu správ.
• Indexy SIEM sú otvorené širokým skupinám IT administrátorov namiesto obmedzených rolí SOC.
• Uchovávanie logov je nastavené globálne bez zohľadnenia citlivosti osobných údajov (PII), zákazníckych zmlúv alebo pravidiel incidentnej blokácie výmazu.
• Logy cloudového poskytovateľa sú povolené, ale administrátorský prístup poskytovateľa k logovým údajom zákazníka sa nepreskúmava.
• Postupy DSAR nespomínajú logy, prípady SIEM ani forenzné exporty.
• Playbooky reakcie na incidenty zachovávajú dôkazy, ale tímy ochrany súkromia nie sú zapojené do klasifikácie.
• Zálohy a archívy uchovávajú osobné údaje (PII) z logov dlhšie než SIEM.
• Vývojári môžu meniť úrovne logovania v produkčnom prostredí bez preskúmania ochrany súkromia alebo bezpečnosti.
• Testovacie prostredia dostávajú produkčné logy s osobnými údajmi.
• Organizácia má oznamovacie povinnosti podľa NIS2 alebo DORA, ale nedokáže rýchlo vyhľadať spoľahlivé dôkazy.

Tieto zistenia zriedka vyplývajú zo zlého úmyslu. Vznikajú zo silového vlastníctva. Bezpečnostné logy ležia medzi SOC, platformovým inžinierstvom, ochranou súkromia, právnym oddelením, compliance, auditom a dodávateľmi. Ak nikto nevlastní celý životný cyklus, vznikajú medzery.

Kontrolný zoznam Clarysec pre riadenie logov pripravené na audit

Použite tento kontrolný zoznam ako pracovný východiskový bod pre vaše ďalšie preskúmanie riadenia:

1. Definujte, ktoré zdroje logov môžu obsahovať osobné údaje (PII): IAM, aplikácia, API brána, SIEM, EDR, cloud, databáza, sieť, fyzický prístup a tiketovací systém.
2. Zaznamenajte každé úložisko logov v REG02 vrátane živých úložísk, archívov, záloh, replík a dočasných forenzných exportov.
3. Definujte rozsah logovania osobných údajov (PII) v REG12 pred produkčným použitím alebo podstatnými zmenami.
4. Identifikujte účel a právny základ spracúvania bezpečnostných logov.
5. Zakážte v logoch heslá, tajomstvá, úplné tokeny a zbytočné škodlivé payloady.
6. Používajte maskovanie, hashovanie alebo pseudonymizáciu tam, kde nie sú potrebné úplné identifikátory.
7. Obmedzte prístup k logom obsahujúcim osobné údaje (PII) podľa rolí vrátane revízie privilegovaného prístupu.
8. Ukladajte vysoko hodnotné logy v nemenných formátoch alebo formátoch chránených proti zápisu.
9. Definujte uchovávanie podľa typu logu, zákonnej povinnosti, zmluvy, incidentnej potreby a rizika ochrany súkromia.
10. Implementujte incidentné blokácie výmazu so schválením, rozsahom a dátumom ukončenia.
11. Zahrňte logy do logiky vyhodnocovania DSAR a výmazu.
12. Preskúmajte dodávateľov SIEM, EDR, cloudu a MDR ako sprostredkovateľov alebo tretie strany IKT.
13. Testujte historické vyhľadávanie a integritu dôkazov.
14. Zmapujte logovanie na potreby hlásenia podľa GDPR, ISO 27701, NIS2, DORA, NIST CSF a COBIT.
15. Školte tímy SOC, ochrany súkromia a aplikačné tímy o tom, čo sa smie a nesmie logovať.

Tento kontrolný zoznam premieňa logovanie zohľadňujúce ochranu súkromia na opakovateľný kontrolný proces.

Od dilemy k dôvere na úrovni riadiaceho orgánu

NIS2 robí z kybernetickej bezpečnosti zodpovednosť manažmentu. DORA robí riadiaci orgán zodpovedným za riadenie rizík IKT, stratégiu digitálnej prevádzkovej odolnosti, dôvernosť údajov, komunikáciu o incidentoch a politiky služieb IKT tretích strán. ISO/IEC 27001:2022 vyžaduje, aby vrcholový manažment zosúladil ISMS s cieľmi organizácie, pridelil zodpovednosti, poskytol zdroje a podporoval neustále zlepšovanie.

Osobné údaje (PII) v bezpečnostných logoch preto nie sú úzkym technickým detailom. Ide o otázku dôvery na úrovni riadiaceho orgánu. Schopnosť organizácie zisťovať incidenty, chrániť osobné údaje, uchovávať dôkazy, reagovať zákazníkom, uspokojiť regulátorov a obnoviť prevádzku závisí od rozhodnutí o logovaní prijatých dávno pred incidentom.

Najlepšie programy riadenia si nevyberajú medzi ochranou súkromia a bezpečnosťou. Definujú minimálne logovanie potrebné pre robustnú bezpečnosť, chránia takéto logovanie ako citlivé osobné údaje (PII), kde sa to vyžaduje, a prepájajú ho s uchovávaním, dôkazmi, vybavovaním práv a povinnosťami dodávateľov.

Ďalšie kroky s Clarysec

Ak vaše SIEM, IAM, EDR alebo cloudové logy obsahujú osobné údaje, teraz je čas riadiť ich zámerne.

Clarysec vám môže pomôcť:

• Vytvoriť rozsah logovania osobných údajov (PII) pomocou REG12 a zosúladiť ho s Politikou bezpečnosti osobných údajov (PII) a riadenia prístupu.
• Evidovať úložiská logov, archívy, zálohy a forenzné exporty pomocou REG02 a Politiky uchovávania, výmazu a likvidácie osobných údajov (PII).
• Zosúladiť logovanie, monitorovanie, dôkazy a kontroly ochrany súkromia so Zenith Blueprint.
• Zmapovať vaše kontroly naprieč GDPR, ISO 27701, NIS2, DORA, NIST CSF a COBIT pomocou Zenith Controls.
• Pripraviť dôkazy pripravené na audit pre preskúmania uistenia podľa ISO, ochrany súkromia, NIST, COBIT, NIS2 a DORA.

Začnite jedným vysoko rizikovým systémom: platformou IAM, SIEM alebo zákaznícky orientovanou aplikáciou. Identifikujte, aké osobné údaje (PII) vstupujú do logov, prečo sú potrebné, kto k nim môže pristupovať, ako dlho sa uchovávajú a ako by sa použili počas incidentu alebo žiadosti o uplatnenie práv. Toto jediné cvičenie odhalí, či je váš súčasný program logovania iba prevádzkový, alebo skutočne pripravený na audit.