Osebno določljivi podatki v varnostnih dnevnikih: priročnik za GDPR, NIS2 in DORA

Varnostni analitik ob 02:17 odpre SIEM. Opozorilo je sprva videti rutinsko: več neuspešnih prijav, uspešna seja z neobičajnega IP-naslova, nato nenaden porast klicev API proti končni točki za izvoz podatkov strank. V nekaj minutah je kanal za incidente poln. Vodja informacijske varnosti želi vedeti, ali gre za prevzem računa. Pravna služba sprašuje, ali dnevniki vsebujejo osebne podatke. Pooblaščenec za varstvo podatkov (DPO) sprašuje, ali so uporabniški ID, IP-naslov, identifikator naprave in URL-ji zahtevkov v SIEM zajeti v obvestilu o zasebnosti in evidencah dejavnosti obdelave. Vodja skladnosti sprašuje, ali je treba dnevnike ohraniti za regulativno poročanje. Ekipa za podporo strankam sprašuje, ali lahko stranka že jutri zahteva izbris istih dnevniških zapisov.

Na tej točki številne organizacije ugotovijo, da sta bila varnostno beleženje in upravljanje zasebnosti vzpostavljena kot ločena svetova.

Varnostne ekipe želijo podrobne dnevnike, dolgo hrambo, nespremenljivo hrambo podatkov in hiter dostop. Ekipe za zasebnost želijo minimizacijo, omejitev namena, dostop na podlagi vlog, disciplino hrambe in izbris, ko podatki niso več potrebni. Ekipe za odzivanje na incidente želijo dokazila ohraniti natanko v stanju, v katerem so bila. Odgovornost po GDPR od organizacije zahteva, da pojasni, zakaj so osebni podatki tam, kdo je do njih dostopal in kako dolgo se hranijo. NIS2 in DORA dodajata nujnost, saj bistveni subjekti, pomembni subjekti in finančne organizacije potrebujejo dovolj dokazil za razvrstitev incidentov, pravočasno poročanje in dokazovanje učinkovitega upravljanja tveganj IKT.

Neprijetna resnica je preprosta: varnostni dnevniki so pogosto repozitoriji osebnih podatkov. Dnevniki avtentikacije lahko vsebujejo uporabniška imena, e-poštne naslove, IP-naslove, prstne odtise naprav in geolokacijo. Dnevniki aplikacij lahko razkrijejo URL-je, iskalne nize, dele vsebine zahtevkov, številke primerov in vsebino sporočil. Dnevniki EDR in dnevniki v oblaku lahko vsebujejo imena gostiteljev, povezana z zaposlenimi, poti datotek z imeni, identifikatorje sej in administratorska dejanja. Dnevniki IAM lahko razkrijejo spremembe privilegijev, članstvo v skupinah in neuspele poskuse dostopa do občutljivih sistemov.

Če dnevniki vsebujejo osebno določljive podatke, niso več samo vprašanje beleženja po ISO 27001. Postanejo vprašanje zasebnosti, hrambe, dokazil, poročanja o incidentih in upravljanja dobaviteljev. Clarysec upravljanje osebno določljivih podatkov v varnostnih dnevnikih obravnava kot vprašanje navzkrižne skladnosti, ne kot vprašanje konfiguracije orodja.

Resnična dilema vodje informacijske varnosti: dokazila za zaznavanje proti minimizaciji podatkov

Vodja informacijske varnosti se v scenariju ob 02:17 sooča z dejanskim operativnim konfliktom. Če so dnevniki preskromni, SOC ne more zaznati kompromitacije, rekonstruirati časovnic ali podpreti poročanja po NIS2 in DORA. Če so dnevniki preobsežni, lahko organizacija zbere več osebnih podatkov, kot je potrebno, jih hrani predolgo, jih izpostavi prevelikemu številu administratorjev ali ne more podpreti pravic po GDPR in obveznosti preglednosti.

GDPR osebne podatke široko opredeljuje kot informacije, ki se nanašajo na določeno ali določljivo osebo. Obdelava vključuje zbiranje, hrambo, uporabo, razkritje, izbris in uničenje. V praksi so lahko dnevniki, ki vsebujejo IP-naslove, uporabniške ID-je, identifikatorje naprav ali zapise dejavnosti, osebni podatki, odvisno od konteksta. Načela GDPR zahtevajo zakonito, pošteno in pregledno obdelavo, omejitev namena, najmanjši obseg podatkov, omejitev shranjevanja, celovitost in zaupnost ter odgovornost.

Vprašanje upravljanja ni: »Ali smemo kadar koli beležiti osebne podatke?« Boljše vprašanje je: »Katere osebno določljive podatke moramo beležiti zaradi varnosti, odzivanja na incidente in skladnosti, katera pravna podlaga to podpira, kateri zaščitni ukrepi veljajo in kdaj jih je treba izbrisati, anonimizirati ali zanje uveljaviti odobreno zadržanje?«

Knjižnica politik zasebnosti za podjetja Clarysec to napetost obravnava neposredno. Politika varstva podatkov in zasebnosti, Zahteve za implementacijo politike, klavzula 6.2.1, določa:

Zbirati in obdelovati se smejo samo podatki, ki so potrebni za določen legitimen poslovni namen.

Za MSP je isto načelo navedeno v Politiki varstva podatkov in zasebnosti za MSP, Zahteve za implementacijo politike, klavzula 6.2.1:

Zbrati in hraniti se smejo samo minimalni potrebni osebni podatki.

Ta stavek mora usmerjati vsako odločitev pri zasnovi beleženja. Ali je vsako polje v vsakem viru dnevnikov potrebno za opredeljen varnostni, operativni, pravni ali pogodbeni namen?

Zakaj ISO 27701 spremeni razpravo o beleženju

ISO/IEC 27001:2022 zagotavlja sistem upravljanja: obseg, zainteresirane strani, oceno tveganj, obravnavo tveganj, operativno obvladovanje, spremljanje, notranjo presojo in nenehno izboljševanje. ISO/IEC 27002:2022 zagotavlja praktične smernice za kontrole beleženja, spremljanja, varstva zasebnosti osebno določljivih podatkov, zbiranja dokazov, zaščite zapisov, izbrisa, nadzora dostopa in upravljanja dobaviteljev. ISO/IEC 27701 razširi model upravljanja na sistem upravljanja informacij o zasebnosti z osredotočenostjo na upravljavce in obdelovalce osebno določljivih podatkov, vloge na področju zasebnosti, evidence obdelave osebno določljivih podatkov, vgrajeno varstvo zasebnosti, obravnavo zahtev za uveljavljanje pravic in obveznosti obdelovalcev.

Za varnostne dnevnike je ISO 27701 pomemben, ker odpira vprašanja, specifična za zasebnost, ki jih varnostne ekipe včasih preskočijo:

• Ali vir dnevnikov obdeluje osebno določljive podatke kot upravljavec, obdelovalec, skupni upravljavec ali podobdelovalec?
• Ali so dnevniški podatki vključeni v popis dejavnosti obdelave?
• Ali organizacija ve, katera dnevniška polja vsebujejo osebno določljive podatke?
• Ali so osebno določljivi podatki v dnevnikih povezani s pravili hrambe in izbrisa?
• Ali so naročniki obdelovalca obveščeni o beleženju dostopa do osebno določljivih podatkov, kadar to zahteva pogodba?
• Ali se dnevniki upoštevajo pri odgovarjanju na zahteve za dostop, izbris ali omejitev obdelave?
• Ali se incidenti v zvezi z osebno določljivimi podatki ocenjujejo glede na sprožilne pogoje za poročanje na področju zasebnosti, kibernetske varnosti in finančnega sektorja?

Clarysecova Politika varnosti osebno določljivih podatkov in nadzora dostopa to prevaja v operativne zahteve. Iz razdelka Beleženje in spremljanje, klavzula 4.6.1:

[Obe vlogi] Lastnik sistema / lastnik aplikacije MORA pred produkcijsko uporabo ali bistveno spremembo v REG12 opredeliti obseg beleženja osebno določljivih podatkov za dogodke avtentikacije, dogodke dostopa, privilegirana dejanja, dejavnost izvoza osebno določljivih podatkov in bistvene spremembe konfiguracije.

Klavzula 4.6.2 nato zapre zanko med beleženjem, nadzorom dostopa in hrambo:

[Obe vlogi] Vodja informacijske varnosti MORA zagotoviti, da so dnevniki, ki vsebujejo osebno določljive podatke, dostopovno omejeni in povezani z odobrenim pravilom hrambe ali izbrisa v REG02 ali REG12 pred začetkom spremljanja dnevnikov.

S tem postane upravljanje PIMS praktično. REG12 določa, katero beleženje osebno določljivih podatkov je dovoljeno in zahtevano. REG02 opredeljuje, kje obstajajo osebno določljivi podatki, vključno z dnevniki. Pravila hrambe in izbrisa niso dokumentacija, dodana naknadno. Postanejo predpogoji za produkcijsko beleženje.

Varnostni dnevniki so zapisi, dokazila in dejavnost obdelave osebno določljivih podatkov

Zrela organizacija dnevnikov ne sme obravnavati kot odpadni tehnični izpuh. Dnevniki so zapisi. Med incidentom lahko postanejo pravni dokazi. Kadar vsebujejo osebno določljive podatke, so tudi podatki obdelave, ki jih ureja zasebnost.

Clarysecova Politika beleženja in spremljanja opredeljuje pričakovanja glede normalizacije dnevnikov. Iz Zahtev upravljanja, klavzula 5.1.4:

Zahteve glede formata in normalizacije dnevnikov (npr. časovni žig, uporabniški ID, vrsta dogodka, izvorni IP)

Prav ta polja naredijo dnevnike uporabne za odzivanje na incidente. Prav ta polja tudi pogosto pomenijo, da so dnevniki osebni podatki. Ista politika za podjetja opozarja, česa nikoli ne sme biti v dnevnikih, iz Zahtev upravljanja, klavzula 5.3.3:

Hramba občutljivih podatkov v nešifriranem besedilu (npr. gesla, kriptografske skrivnosti)

Bistvo ni, da bi se morali dnevniki izogibati vsem identifikatorjem. Bistvo je, da morajo biti identifikatorji namerni, zaščiteni in utemeljeni. Gesla, skrivnosti, celotni žetoni in nepotrebne vsebine zahtevkov se ne smejo beležiti. Uporabniški ID-ji, IP-naslovi in metapodatki dogodkov so lahko potrebni, vendar zahtevajo kontrole.

Za MSP Clarysecova Politika beleženja in spremljanja za MSP v strukturo vlog vključi pregled zasebnosti. Iz razdelka Vloge in odgovornosti, klavzula 4.3.1, zahteva, da organizacija:

Preveri, da se dnevniški podatki, ki se nanašajo na osebne ali občutljive informacije, obravnavajo v skladu z GDPR in drugo zakonodajo o varstvu podatkov.

Različica za MSP določa tudi jasno izhodiščno zahtevo glede hrambe. Iz Zahtev upravljanja, klavzula 5.2.1:

Dnevnike je treba hraniti najmanj 12 mesecev, razen če zakon ali pogodba zahteva daljše obdobje hrambe ali je to utemeljeno kot del aktivnega incidenta ali pravnega spora.

Določa tudi pričakovanje glede zaščite, iz Zahtev upravljanja, klavzula 5.3.1:

Dnevnike je treba hraniti na lokacijah z zaščito pred pisanjem, dostop pa mora biti omejen samo na pooblaščeno osebje.

Za odzivanje na incidente v podjetjih Politika zbiranja dokazov in forenzike, Zahteve za implementacijo politike, klavzula 6.3.1, zahteva:

Dnevnike iz požarnih zidov, SIEM, agentov končnih točk, platform za upravljanje identitet in dostopa (IAM) ter oblačnih platform je treba izvoziti in hraniti v nespremenljivih formatih.

Različica za MSP dodaja varovalo sorazmernosti. Politika zbiranja dokazov in forenzike za MSP, Obravnava tveganj in izjeme, klavzula 7.2.1, določa:

Minimizirajte obseg zbiranja; zberite samo tisto, kar je potrebno.

To je jedro beleženja, skladnega z zasebnostjo: ohranite, kar je potrebno, dokažite, zakaj je potrebno, omejite, kdo lahko to vidi, in izbrišite, ko odobren namen poteče.

Clarysecov kontrolni model za dokazila, varna z vidika zasebnosti

V Zenith Blueprint: revizorjev 30-koračni časovni načrt Clarysec umešča beleženje v fazo Kontrole v praksi, Korak 19: Tehnološki kontrolni ukrepi I. Vodnik pojasnjuje pričakovanje kontrole po ISO/IEC 27002:2022:

A.8.15 – Beleženje: »Dnevniki, ki beležijo dejavnosti, izjeme, napake in druge relevantne dogodke, morajo biti ustvarjeni, shranjeni, zaščiteni in analizirani.«

Isti korak organizacijam nalaga, naj ustvarjajo dnevnike za ključne dogodke, jih varno hranijo tako, da jih ni mogoče spremeniti, jih hranijo določeno obdobje in jih analizirajo prek SIEM ali postopka pregleda. Beleženje povezuje tudi z obveščanjem o kršitvah po GDPR, zapisi o incidentih po DORA, upravljanjem tveganj po NIS2 in analizo varnostnih dnevnikov po COBIT.

Vendar samo beleženje ni dovolj. V isti fazi Kontrole v praksi, Korak 19, Zenith Blueprint obravnava izbris. Opozarja, da podatki, hranjeni dlje od operativne vrednosti, povečujejo izpostavljenost in regulativno tveganje, ter izrecno izpostavlja varnostne kopije, posnetke in arhive. To je pomembno, ker je pravilo hrambe v SIEM brez pomena, če replicirani arhivi dnevnikov ali shranjevalni vsebniki v oblaku iste osebno določljive podatke hranijo za nedoločen čas.

V Koraku 23: Organizacijski ukrepi Zenith Blueprint obravnava zbiranje dokazov. Navaja, da je treba dokazila o incidentih identificirati, zbrati in ohraniti na način, ki je pravno dopusten, zanesljiv in usklajen s potrebami preiskave. Poudarja tudi operativno realnost: dokazila se pogosto izgubijo v prvih minutah odziva, ko se dnevniki prepišejo, sistemi znova zaženejo ali administratorji spremenijo kompromitirane račune, preden so zajeti posnetki stanja.

Korak 23 obravnava tudi zasebnost in varstvo osebno določljivih podatkov. Vodnik osebno določljive podatke obravnava kot vprašanje življenjskega cikla, ki zahteva poznavanje podatkov, razvrščanje, nadzor dostopa, maskiranje, izbris, šifriranje in obveznosti dobaviteljev. Za dnevnike to pomeni, da morajo biti SIEM, EDR, platforma za beleženje v oblaku in sistem za upravljanje zahtevkov del popisa osebno določljivih podatkov.

Preslikava navzkrižne skladnosti za osebno določljive podatke v dnevnikih

Zenith Controls: vodnik za navzkrižno skladnost preslika kontrolo ISO/IEC 27002:2022 8.15, Beleženje, na povezane kontrole, ki so bistvene za upravljanje osebno določljivih podatkov. Te povezave pokažejo, zakaj beleženje ni samo skrb SOC.

Zenith Controls prav tako preslika Beleženje na ISO/IEC 27002:2022 clause 8.15, ISO/IEC 27035-1 in ISO/IEC 27035-2 za upravljanje incidentov, ISO/IEC 27701 za beleženje dejavnosti obdelave osebno določljivih podatkov, ISO/IEC 27017 za revizijske dnevnike v oblaku, ISO/IEC 27018 za beleženje dostopa do osebno določljivih podatkov v oblaku, ISO/IEC 27005 za tveganja zaradi nezadostnega beleženja, ISO/IEC 27033 za beleženje omrežnih dejavnosti in ISO/IEC 15408-2 za revizijsko funkcionalnost v ocenjenih izdelkih.

Posebej za zasebnost Zenith Controls preslika kontrolo ISO/IEC 27002:2022 5.34, Zasebnost in varstvo osebno določljivih podatkov, na evidenco sredstev, maskiranje podatkov, storitve v oblaku, razvrščanje, prenos informacij, nadzor dostopa, upravljanje identitet ter varnostni pregled projektov in sprememb. Za program upravljanja dnevnikov te povezave postanejo praktične zahteve zasnove:

• Popišite repozitorije dnevnikov kot lokacije osebno določljivih podatkov.
• Maskirajte ali tokenizirajte osebno določljive podatke, kadar celotni identifikatorji niso potrebni.
• Preglejte storitve beleženja v oblaku in dobavitelje SIEM v okviru kontrol za oblak in dobavitelje.
• Dnevnike, ki vsebujejo osebno določljive podatke, razvrstite kot občutljive zapise.
• Upravljajte izvoz in prenose dnevnikov kot prenose osebno določljivih podatkov.
• Omejite dostop do dnevnikov z upravljanjem identitet in kontrolami privilegiranega dostopa.
• Preglejte spremembe aplikacijskega beleženja pred objavo v produkcijo.

GDPR, NIS2 in DORA: en dnevnik, trije regulativni pogledi

Isti dnevniški zapis se lahko po GDPR, NIS2 in DORA obravnava različno.

Po GDPR se organizacija vpraša, ali dnevniški zapis vsebuje osebne podatke, katera pravna podlaga podpira obdelavo, ali so podatki potrebni, kako dolgo se hranijo, kdo lahko do njih dostopa, ali se razkrijejo obdelovalcem ali strankam ter ali jih je treba upoštevati pri zahtevi za uveljavljanje pravic ali oceni kršitve.

Po NIS2 se organizacija vpraša, ali dnevniki podpirajo upravljanje tveganj kibernetske varnosti, obravnavanje incidentov, neprekinjeno poslovanje, nadzor dostopa, varnost dobavne verige in oceno učinkovitosti kontrol. NIS2 Article 20 določa odgovornost organov upravljanja za odobritev in nadzor ukrepov za upravljanje tveganj kibernetske varnosti. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, varnim razvojem, obravnavo ranljivosti, oceno učinkovitosti, kibernetsko higieno, nadzorom dostopa in upravljanjem sredstev. Article 23 vzpostavlja postopno poročanje o pomembnih incidentih, vključno z zgodnjim opozorilom v 24 urah, obvestilom v 72 urah in končnim poročilom v enem mesecu.

Po DORA morajo finančni subjekti vzdrževati dokumentiran okvir upravljanja IKT-tveganj. DORA Article 5 dodeljuje odgovornost organu upravljanja. Article 10 obravnava zaznavanje. Article 17 zahteva proces upravljanja incidentov, povezanih z IKT. Article 18 zajema razvrščanje incidentov, povezanih z IKT, in kibernetskih groženj. Article 19 obravnava poročanje o večjih incidentih, povezanih z IKT. Dnevniki podpirajo zaznavanje, razvrščanje, analizo temeljnega vzroka, oceno vpliva, odziv, obnovitev in dokazila o odpravi pomanjkljivosti.

Podrobnejša preslikava kontrol pomaga vodji informacijske varnosti utemeljiti beleženje brez zanašanja na nejasne izjave, kot je »to potrebujemo zaradi varnosti«.

V REG12 vzpostavite obseg beleženja osebno določljivih podatkov

Stranka Clarysec bi incident v SIEM ob 02:17 obravnavala, še preden bi se sploh zgodil. Organizacija začne z aplikacijo, namenjeno strankam, ki obdeluje podatke o računih. Pred produkcijo lastnik aplikacije z REG12 opredeli obseg beleženja osebno določljivih podatkov. Cilj je zajeti dovolj dogodkov za varnostna in regulativna dokazila, ne da bi se beležili nepotrebni osebni podatki ali nepotrebna vsebina zahtevkov.

Nato vodja zasebnosti potrdi, ali organizacija za vsak vir dnevnikov deluje kot upravljavec, obdelovalec ali oboje. Če je organizacija obdelovalec, lahko pogodbena navodila naročnika in razkritja podobdelovalcev omejujejo dostop do dnevnikov in njihovo deljenje. Če je upravljavec, je treba urediti obvestila o zasebnosti, pravno podlago in obravnavo zahtev za uveljavljanje pravic.

Lastnik podatkov nato posodobi REG02 tako, da vključuje aktivne repozitorije dnevnikov, indekse SIEM, arhive, varnostne kopije in začasne forenzične izvoze. To je skladno s Politiko hrambe, izbrisa in odstranjevanja osebno določljivih podatkov, Varnostne kopije, arhivi, replike, dnevniki in začasne datoteke, klavzula 4.4.1:

[Obe vlogi] Lastnik sistema / lastnik aplikacije MORA v REG02 pred prehodom v produkcijo in med vsakim letnim pregledom hrambe identificirati aktivne repozitorije, arhive, varnostne kopije, replike, dnevnike, pripravljalna okolja in začasne datoteke, ki vsebujejo osebno določljive podatke.

Politika hrambe podatkov in odstranjevanja mora nato poslovna pravila hrambe uskladiti z zakonskimi in pogodbenimi zahtevami ter zahtevami glede ohranitve dokazil.

Nazadnje varnostna ekipa konfigurira SIEM tako, da se gesla, skrivnosti in telesa zahtevkov zavržejo ali prikrijejo pred zajemom. Dnevniki, ki vsebujejo osebno določljive podatke, se dodelijo omejenim indeksom. Hramba se samodejno uveljavlja, razen če je odobreno zadržanje zaradi incidenta ali pravno zadržanje. Dejanja izbrisa se beležijo. Forenzični izvozi zahtevajo odobritev in sledenje verigi skrbništva. Nadzorne plošče prikazujejo psevdonimizirane identifikatorje, kadar celotna identiteta ni potrebna. Pridobivanje zgodovinskih dnevnikov se preizkuša med notranjimi presojami.

To je razlika med izjavo »beležimo zaradi varnosti« in dokazom »beležimo samo, kar je potrebno, to zaščitimo, hranimo po odobrenih pravilih in lahko uporabimo kot dokazilo, ne da bi kršili obveznosti zasebnosti«.

DSAR, izbris in dnevniki: odločite pred prejemom zahteve

Eno najtežjih vprašanj je, ali je treba dnevnike preiskati, razkriti ali izbrisati kot odgovor na zahteve posameznika za dostop do osebnih podatkov ali zahteve za izbris. Odgovor je odvisen od vloge, namena, pravne podlage, izvedljivosti, izjem in obveznosti hrambe. Vendar se proces upravljanja ne sme izumljati od zahteve do zahteve.

Politika upravljanja pravic posameznikov, na katere se nanašajo osebno določljivi podatki, Preverjanje identitete, obseg in ocena, klavzula 4.2.3, določa:

[Upravljavec] Lastnik procesa / lastnik podjetja MORA pred oceno izpolnitve iz REG02 identificirati relevantne sisteme, zapise, namene, kategorije osebno določljivih podatkov, prejemnike in omejitve hrambe.

To pomeni, da morajo biti dnevniki v REG02 z jasnimi metapodatki: katere kategorije osebno določljivih podatkov vsebujejo, kateremu namenu služijo, katera omejitev hrambe velja in ali je zahtevo mogoče izpolniti z neposrednim razkritjem, povzetim dostopom, omejitvijo, izbrisom ob poteku ali zavrnitvijo na podlagi dokumentirane pravne podlage.

Clarysec priporoča tristopenjski pristop:

1. Operativni dnevniki z nizkim vplivom na zasebnost, kot so sistemski dnevniki dogodkov, ki uporabljajo psevdonimne uporabniške ID-je, so lahko po potrebi preiskljivi in razkrivni.
2. Varnostni dnevniki z visoko varnostno občutljivostjo, kot so korelacijski podatki SIEM ali kontekst obveščevalnih podatkov o grožnjah, lahko zahtevajo filtriranje, povzetek razkritja ali omejitev, da se ne razkrijejo logika zaznavanja ali podatki tretjih oseb.
3. Forenzični dokazi pod aktivnim zadržanjem zaradi incidenta ali pravnim zadržanjem se ne smejo spreminjati brez ustrezne presoje. Izbris se lahko odloži ali omeji, kadar je to pravno utemeljeno, odločitev pa dokumentirajo deležniki za zasebnost in pravna služba.

Če DPO in SOC o vsakem DSAR razpravljata od začetka, bo organizacija nedosledna in počasna. Če sta REG02 in REG12 vzdrževana, obravnava zahtev za uveljavljanje pravic temelji na dokazilih.

Poročanje o kršitvah in incidentih: en dogodek, več rokov

Opozorilo ob 02:17 lahko sproži več rokov. Ocena kršitve varnosti osebnih podatkov po GDPR lahko zahteva obvestilo nadzornemu organu, kadar so izpolnjeni pragovi tveganja. Poročanje o pomembnem incidentu po NIS2 lahko zahteva zgodnje opozorilo v 24 urah, obvestilo v 72 urah in končno poročilo. DORA lahko zahteva poročanje o večjem incidentu, povezanem z IKT, v začetni, vmesni in končni fazi. Pogodbe s strankami imajo lahko še krajše roke za obveščanje.

Clarysecova Politika upravljanja incidentov in kršitev osebno določljivih podatkov neposredno obravnava problem več sprožilnih pogojev. Iz razdelka Razvrščanje in ocena kršitve, klavzula 4.2.6:

[Pogojno] Vodja zasebnosti / vodja PIMS MORA za vsak incident v zvezi z osebno določljivimi podatki z velikim vplivom oceniti veljavne pravne, sektorske, finančnosektorske, kibernetskovarnostne, pogodbene, naročniške in prejemniške sprožitvene pogoje za poročanje ter rezultat uporabljivosti evidentirati v REG01, REG08 in REG10.

Med triažo mora organizacija vprašati:

• Ali je napadalec dostopal do osebnih podatkov ali samo do metapodatkov?
• Ali so dnevniki dodatne osebno določljive podatke izpostavili nepooblaščenim uporabnikom?
• Ali so dnevniki potrebni za določitev prizadetih oseb, sistemov in časovnega okvira?
• Ali so dnevniki hranjeni nespremenljivo in z omejenim dostopom?
• Ali je zadržanje zaradi incidenta za relevantne dnevnike začasno ustavilo izbris?
• Ali so prizadeti naročniki obdelovalca, stranke iz finančnega sektorja ali prejemniki storitev?
• Kateri roki za poročanje veljajo in kdo je odgovoren za vsako obvestilo?

Dobro upravljani dnevniki pospešijo poročanje, ker odločevalcem zagotavljajo zanesljiva dejstva. Slabo beleženje povzroča zamude. Prekomerno beleženje ustvarja tveganje za zasebnost. Pravi odgovor je ciljno, zaščiteno in preslikano beleženje.

Beleženje pri dobaviteljih in v oblaku: problem obdelovalca, skrit v vašem SIEM

Večina organizacij ne hrani vseh dnevnikov na infrastrukturi, ki jo v celoti nadzoruje. Dnevniki tečejo v platforme SIEM, portale EDR, izvorne storitve beleženja v oblaku, orodja za opazljivost, sisteme za upravljanje zahtevkov in ponudnike upravljanega zaznavanja in odzivanja. Po GDPR so ti ponudniki lahko obdelovalci ali podobdelovalci. Po NIS2 in DORA so lahko tudi neposredni dobavitelji, tretji ponudniki storitev IKT, ponudniki upravljanih storitev ali ponudniki upravljanih varnostnih storitev.

NIS2 Article 21 izrecno vključuje varnost dobavne verige, ranljivosti dobaviteljev in splošne prakse kibernetske varnosti dobaviteljev. DORA dodaja podrobne zahteve glede tveganj tretjih oseb IKT za finančne subjekte, vključno s predpogodbenim skrbnim pregledom, registri informacij, pravicami do presoje in dostopa, pomočjo pri incidentih, lokacijo podatkov, klavzulami o varstvu podatkov, izhodnimi strategijami in pogodbenimi določili za kritične ali pomembne funkcije.

Za osebno določljive podatke v varnostnih dnevnikih morajo pregledi dobaviteljev vključevati naslednja vprašanja:

Pogodba za SIEM ni samo naročnina na programsko opremo. Je odvisnost obdelave osebno določljivih podatkov in dokazil o incidentih.

Revizijski pogled: kako presojevalci preverjajo osebno določljive podatke v varnostnih dnevnikih

Dober presojevalec ne bo sprejel izjave, da so »dnevniki zaščiteni«. Preveril bo verigo od politike do konfiguracije, dokazil in pregleda.

Praktičen revizijski preizkus je preprost, vendar razkrivajoč: SOC naj pridobi dnevniški zapis izpred desetih mesecev, ki prikazuje spremembo privilegiranega dostopa v oblačni platformi, dokaže, kdo je dostopal do tega dnevnika, dokaže, da ni bil spremenjen, pokaže pravilo hrambe, ki je omogočilo njegov obstoj, pokaže polja z osebno določljivimi podatki, ki jih vsebuje, in pokaže, kako bi bil obravnavan v DSAR ali poročilu o incidentu. Če ekipa ne more odgovoriti čez področja varnosti, zasebnosti in skladnosti, je upravljanje nepopolno.

Pogoste ugotovitve pri presojah dnevnikov z osebno določljivimi podatki

Clarysec pogosto opaža iste vzorce:

• Aplikacijske ekipe za odpravljanje napak beležijo celotno vsebino zahtevkov, vključno z imeni, e-poštnimi naslovi, številkami računov ali vsebino sporočil.
• Indeksi SIEM so odprti širokim skupinam IT administratorjev namesto omejenim vlogam SOC.
• Hramba dnevnikov je nastavljena globalno, ne glede na občutljivost osebno določljivih podatkov, pogodbe s strankami ali pravila zadržanja zaradi incidentov.
• Dnevniki ponudnika storitev v oblaku so omogočeni, vendar se administratorski dostop ponudnika do dnevniških podatkov strank ne pregleduje.
• Postopki DSAR ne omenjajo dnevnikov, primerov SIEM ali forenzičnih izvozov.
• Odzivni priročniki za incidente ohranjajo dokazila, vendar ekipe za zasebnost niso vključene v razvrščanje.
• Varnostne kopije in arhivi hranijo osebno določljive podatke iz dnevnikov dlje kot SIEM.
• Razvijalci lahko v produkciji spreminjajo ravni beleženja brez pregleda zasebnosti ali varnosti.
• Testna okolja prejemajo produkcijske dnevnike z osebnimi podatki.
• Organizacija ima obveznosti poročanja po NIS2 ali DORA, vendar ne more hitro pridobiti zanesljivih dokazil.

Te ugotovitve redko izvirajo iz slabih namenov. Izvirajo iz ločenega lastništva. Varnostni dnevniki so na presečišču SOC, platformnega inženiringa, zasebnosti, pravne službe, skladnosti, revizije in dobaviteljev. Če nihče ne prevzame lastništva nad celotnim življenjskim ciklom, nastanejo vrzeli.

Clarysecov kontrolni seznam za upravljanje dnevnikov, pripravljeno za presojo

Ta kontrolni seznam uporabite kot delovno izhodišče za naslednji pregled upravljanja:

1. Opredelite, kateri viri dnevnikov lahko vsebujejo osebno določljive podatke: IAM, aplikacija, prehod API, SIEM, EDR, oblak, podatkovna baza, omrežje, fizični dostop in sistem za upravljanje zahtevkov.
2. Vsak repozitorij dnevnikov evidentirajte v REG02, vključno z aktivnimi repozitoriji, arhivi, varnostnimi kopijami, replikami in začasnimi forenzičnimi izvozi.
3. Pred produkcijsko uporabo ali bistvenimi spremembami opredelite obseg beleženja osebno določljivih podatkov v REG12.
4. Opredelite namen in pravno podlago za obdelavo varnostnih dnevnikov.
5. Prepovejte beleženje gesel, skrivnosti, celotnih žetonov in nepotrebne vsebine zahtevkov.
6. Uporabite maskiranje, zgoščevanje ali psevdonimizacijo, kadar celotni identifikatorji niso potrebni.
7. Dostop do dnevnikov, ki vsebujejo osebno določljive podatke, omejite po vlogah, s pregledom privilegiranega dostopa.
8. Dnevnike visoke vrednosti hranite v nespremenljivih formatih ali formatih z zaščito pred pisanjem.
9. Hrambo določite glede na vrsto dnevnika, zakonsko obveznost, pogodbo, potrebo ob incidentu in tveganje za zasebnost.
10. Uvedite zadržanja zaradi incidentov z odobritvijo, obsegom in datumom poteka.
11. Dnevnike vključite v logiko ocenjevanja DSAR in zahtev za izbris.
12. Dobavitelje SIEM, EDR, oblačnih storitev in MDR preglejte kot obdelovalce ali tretje osebe IKT.
13. Preizkusite pridobivanje zgodovinskih dnevnikov in celovitost dokazil.
14. Beleženje preslikajte na potrebe poročanja po GDPR, ISO 27701, NIS2, DORA, NIST CSF in COBIT.
15. Usposobite ekipe SOC, zasebnosti in aplikacij o tem, kaj se sme in česa se ne sme beležiti.

Ta kontrolni seznam beleženje, skladno z zasebnostjo, pretvori v ponovljiv kontrolni proces.

Od dileme do zaupanja na ravni upravnega odbora

NIS2 določa, da je kibernetska varnost odgovornost vodstva. DORA določa odgovornost organa upravljanja za upravljanje tveganj IKT, strategijo digitalne operativne odpornosti, zaupnost podatkov, komuniciranje o incidentih in politike za storitve tretjih ponudnikov IKT. ISO/IEC 27001:2022 od najvišjega vodstva zahteva, da ISMS uskladi s poslovnimi cilji, dodeli odgovornosti, zagotovi vire in spodbuja nenehno izboljševanje.

Osebno določljivi podatki v varnostnih dnevnikih zato niso ozka tehnična podrobnost. So vprašanje zaupanja na ravni upravnega odbora. Zmožnost organizacije, da zazna incidente, zaščiti osebne podatke, ohrani dokazila, odgovori strankam, zadosti regulatorjem in obnovi poslovanje, je odvisna od odločitev o beleženju, sprejetih mnogo pred incidentom.

Najboljši programi upravljanja ne izbirajo med zasebnostjo in varnostjo. Opredelijo minimalno beleženje, potrebno za robustno varnost, ga po potrebi zaščitijo kot občutljive osebno določljive podatke ter ga povežejo s hrambo, dokazili, obravnavo zahtev za uveljavljanje pravic in obveznostmi dobaviteljev.

Naslednji koraki s Clarysec

Če vaši dnevniki SIEM, IAM, EDR ali dnevniki v oblaku vsebujejo osebne podatke, je zdaj pravi čas, da jih upravljate namensko.

Clarysec vam lahko pomaga:

• Vzpostaviti obseg beleženja osebno določljivih podatkov z REG12 in ga uskladiti s Politiko varnosti osebno določljivih podatkov in nadzora dostopa.
• Popisati repozitorije dnevnikov, arhive, varnostne kopije in forenzične izvoze z REG02 ter Politiko hrambe, izbrisa in odstranjevanja osebno določljivih podatkov.
• Uskladiti kontrole beleženja, spremljanja, dokazil in zasebnosti z Zenith Blueprint.
• Preslikati kontrole čez GDPR, ISO 27701, NIS2, DORA, NIST CSF in COBIT z uporabo Zenith Controls.
• Pripraviti dokazila, pripravljena za presojo, za preglede zagotavljanja zaupanja po ISO, zasebnosti, NIST, COBIT, NIS2 in DORA.

Začnite z enim visoko tveganim sistemom: platformo IAM, SIEM ali aplikacijo, namenjeno strankam. Ugotovite, kateri osebno določljivi podatki vstopajo v dnevnike, zakaj so potrebni, kdo lahko do njih dostopa, kako dolgo se hranijo in kako bi se uporabili med incidentom ali zahtevo za uveljavljanje pravic. Že ta vaja bo pokazala, ali je vaš trenutni program beleženja zgolj operativen ali resnično pripravljen za presojo.