Isikut tuvastav teave turbelogides: GDPR-i, NIS2 ja DORA tegevusjuhis

Turbeanalüütik avab SIEM-i kell 02:17. Teavitus näib alguses tavapärane: mitu ebaõnnestunud sisselogimist, õnnestunud seanss ebatavaliselt IP-aadressilt ja seejärel API-päringute puhang kliendi ekspordi lõpp-punkti vastu. Mõne minutiga on intsidendi koordineerimiskanal täis. CISO soovib teada, kas tegemist on konto ülevõtmisega. Õigusosakond küsib, kas logid sisaldavad isikuandmeid. Andmekaitseametnik küsib, kas SIEM-is olev kasutaja ID, IP-aadress, seadme identifikaator ja päringu URL-id on kaetud privaatsusteate ning töötlemistoimingute registriga. Vastavusjuht küsib, kas logid tuleb regulatiivse aruandluse jaoks säilitada. Kliendisuhete meeskond küsib, kas klient võib homme taotleda samade logikirjete kustutamist.

Just siin avastavad paljud organisatsioonid, et turbelogimine ja privaatsuse juhtimine on üles ehitatud eraldi maailmadena.

Turbemeeskonnad soovivad detailseid logisid, pikka säilitamist, muutmatut salvestamist ja kiiret juurdepääsu. Privaatsusmeeskonnad soovivad andmete minimaalsust, eesmärgi piirangut, rollipõhist juurdepääsu, säilitamisdistsipliini ja kustutamist, kui andmeid enam vaja ei ole. Intsidentidele reageerijad soovivad säilitada tõendusmaterjali täpselt sellisena, nagu see oli. GDPR-i vastutuse põhimõte nõuab, et organisatsioon suudaks selgitada, miks isikuandmed seal on, kes neile juurde pääses ja kui kaua neid säilitatakse. NIS2 ja DORA lisavad kiireloomulisuse, sest olulistel üksustel, tähtsatel üksustel ja finantsorganisatsioonidel peab olema piisavalt tõendusmaterjali intsidentide klassifitseerimiseks, õigeaegseks teatamiseks ja tõhusa IKT-riski juhtimise tõendamiseks.

Ebamugav tõde on lihtne: turbelogid on sageli isikuandmete hoidlad. Autentimislogid võivad sisaldada kasutajanimesid, e-posti aadresse, IP-aadresse, seadme sõrmejälgi ja geolokatsiooni. Rakenduslogid võivad avaldada URL-e, otsingustringe, sõnumikehade fragmente, juhtuminumbrerid ja sõnumisisu. EDR-i ja pilvelogid võivad sisaldada töötajatega seotud hostinimesid, nimesid sisaldavaid failiteid, seansi identifikaatoreid ja administraatori toiminguid. IAM-i logid võivad näidata õiguste muudatusi, grupikuuluvust ja ebaõnnestunud juurdepääsukatseid tundlikele süsteemidele.

Kui logid sisaldavad isikut tuvastavat teavet, ei ole need enam ainult ISO 27001 logimise küsimus. Need muutuvad privaatsuse, säilitamise, tõendusmaterjali, intsidentidest teatamise ja tarnijate juhtimise küsimuseks. Clarysec käsitleb isikut tuvastavat teavet turbelogides raamistikeülese vastavusprobleemina, mitte tööriista konfiguratsiooniprobleemina.

CISO tegelik dilemma: tuvastamise tõendusmaterjal versus privaatsuse minimaalsus

02:17 stsenaariumis seisab CISO silmitsi tegeliku operatiivse konfliktiga. Kui logid on liiga napid, ei suuda SOC kompromiteerimist tuvastada, ajajoont taastada ega toetada NIS2 ja DORA aruandlust. Kui logid on liiga mahukad, võib organisatsioon koguda rohkem isikuandmeid kui vajalik, säilitada neid liiga kaua, teha need kättesaadavaks liiga paljudele administraatoritele või mitte toetada GDPR-ist tulenevaid õigusi ja läbipaistvuskohustusi.

GDPR määratleb isikuandmeid laialt kui teavet, mis on seotud tuvastatud või tuvastatava isikuga. Töötlemine hõlmab kogumist, salvestamist, kasutamist, avalikustamist, kustutamist ja hävitamist. Praktikas võivad IP-aadresse, kasutaja ID-sid, seadme identifikaatoreid või tegevuskirjeid sisaldavad logid olla kontekstist sõltuvalt isikuandmed. GDPR-i põhimõtted nõuavad seaduslikku, õiglast ja läbipaistvat töötlemist, eesmärgi piirangut, andmete minimaalsust, säilitamise piirangut, terviklust ja konfidentsiaalsust ning vastutust.

Juhtimisküsimus ei ole: „Kas me tohime kunagi isikuandmeid logida?” Parem küsimus on: „Millist isikut tuvastavat teavet peame logima turvalisuse, intsidentidele reageerimise ja vastavuse jaoks, milline õiguslik alus seda toetab, millised kaitsemeetmed kohalduvad ning millal tuleb see kustutada, anonüümida või panna heakskiidetud säilitamiskohustuse alla?”

Clarysec ettevõtte privaatsuspoliitikate kogu käsitleb seda pinget otse. Andmekaitse- ja privaatsuspoliitika, poliitika rakendamise nõuded, punkt 6.2.1 sätestab:

Koguda ja töödelda võib ainult andmeid, mis on vajalikud konkreetse õiguspärase ärieesmärgi jaoks.

VKE-de puhul on sama põhimõte esitatud Andmekaitse- ja privaatsuspoliitikas VKE-dele, poliitika rakendamise nõuded, punkt 6.2.1:

Koguda ja säilitada tuleb ainult minimaalselt vajalikud isikuandmed.

See lause peab suunama iga logimise disainiotsust. Kas iga väli igas logiallikas on vajalik määratletud turbe-, operatiivsel, õiguslikul või lepingulisel eesmärgil?

Miks ISO 27701 muudab logimise käsitlust

ISO/IEC 27001:2022 annab juhtimissüsteemi: kohaldamisala, huvitatud osapooled, riskihindamise, riskikäsitluse, operatiivse ohje, seire, siseauditi ja pideva täiustamise. ISO/IEC 27002:2022 annab praktilised kontrollisuunised logimise, seire, isikut tuvastava teabe privaatsuskaitse, tõendite kogumise, kirjete kaitse, kustutamise, juurdepääsukontrolli ja tarnijahaldus kohta. ISO/IEC 27701 laiendab juhtimismudeli privaatsusteabe haldussüsteemiks, keskendudes isikut tuvastava teabe vastutavatele töötlejatele ja volitatud töötlejatele, privaatsusrollidele, isikut tuvastava teabe töötlemise kirjetele, lõimitud andmekaitse põhimõttele, õiguste käsitlemisele ja volitatud töötlejate kohustustele.

Turbelogide puhul on ISO 27701 oluline, sest see sunnib esitama privaatsusspetsiifilisi küsimusi, mille turbemeeskonnad mõnikord vahele jätavad:

• Kas logiallikas töötleb isikut tuvastavat teavet vastutava töötleja, volitatud töötleja, kaasvastutava töötleja või alltöötlejana?
• Kas logiandmed on lisatud töötlemistoimingute registrisse?
• Kas organisatsioon teab, millised logiväljad sisaldavad isikut tuvastavat teavet?
• Kas logides olev isikut tuvastav teave on seotud säilitamis- ja kustutamisreeglitega?
• Kas volitatud töötleja kliendid on lepingulise nõude korral teavitatud isikut tuvastavale teabele juurdepääsu logimisest?
• Kas logisid arvestatakse juurdepääsu-, kustutamis- või piiramistaotlustele vastamisel?
• Kas isikut tuvastava teabega seotud intsidente hinnatakse privaatsuse, küberturbe ja finantssektori aruandluse käivitavate asjaolude lõikes?

Clarysec isikut tuvastava teabe turbe- ja juurdepääsukontrolli poliitika teisendab selle tegevusnõueteks. Logimine ja seire, punkt 4.6.1:

[Mõlemad] Süsteemiomanik / rakenduse omanik PEAB määratlema isikut tuvastava teabe logimise kohaldamisala autentimissündmuste, juurdepääsusündmuste, privilegeeritud toimingute, isikut tuvastava teabe eksporditegevuse ja oluliste konfiguratsioonimuudatuste jaoks REG12-s enne tootmiskasutust või olulist muudatust.

Punkt 4.6.2 sulgeb seejärel logimise, juurdepääsukontrolli ja säilitamise vahelise tsükli:

[Mõlemad] Infoturbe juht PEAB tagama, et isikut tuvastavat teavet sisaldavatele logidele on juurdepääs piiratud ning need on seotud heakskiidetud säilitamis- või kustutamisreegliga REG02-s või REG12-s enne logide seire alustamist.

See muudab PIMS-i juhtimise praktiliseks. REG12 määratleb, milline isikut tuvastava teabe logimine on lubatud ja nõutav. REG02 tuvastab, kus isikut tuvastav teave asub, sealhulgas logides. Säilitamis- ja kustutamisreeglid ei ole hiljem lisatav paberitöö. Need muutuvad tootmiskeskkonna logimise eeltingimusteks.

Turbelogid on kirjed, tõendusmaterjal ja isikut tuvastava teabe töötlemistoiming

Küps organisatsioon ei tohiks käsitleda logisid ühekordselt kasutatava tehnilise jäägina. Logid on kirjed. Intsidendi ajal võivad neist saada õiguslik tõendusmaterjal. Kui need sisaldavad isikut tuvastavat teavet, on need ka privaatsusnõuetega hõlmatud töötlemisandmed.

Clarysec logimis- ja seirepoliitika määratleb logide normaliseerimise ootused. Juhtimisnõuded, punkt 5.1.4:

Logivormingu ja normaliseerimise nõuded (nt ajatempel, kasutaja ID, sündmuse tüüp, lähte-IP)

Need on täpselt need väljad, mis muudavad logid intsidentidele reageerimisel kasulikuks. Need on ka väljad, mis teevad logidest sageli isikuandmed. Sama ettevõtte poliitika nimetab selgelt, mida ei tohi juhtuda. Juhtimisnõuded, punkt 5.3.3:

Tundlike andmete salvestamine lihttekstina (nt paroolid, krüptograafilised saladused)

Eesmärk ei ole vältida logides kõiki identifikaatoreid. Eesmärk on, et identifikaatorid oleksid teadlikult valitud, kaitstud ja põhjendatud. Paroole, saladusi, täistokeneid ja mittevajalikke sõnumikehi ei tohi logida. Kasutaja ID-d, IP-aadressid ja sündmuse metaandmed võivad olla vajalikud, kuid need nõuavad kontrollimeetmeid.

VKE-de puhul asetab Clarysec logimis- ja seirepoliitika VKE-dele privaatsuse läbivaatamise rollistruktuuri. Rollid ja vastutused, punkt 4.3.1 nõuab organisatsioonilt:

Kontrollib, et isikuandmete või tundliku teabega seotud logiandmeid käideldakse kooskõlas GDPR ja muude andmekaitseseadustega.

VKE versioon annab ka selge säilitamise baastaseme nõude. Juhtimisnõuded, punkt 5.2.1:

Loge tuleb säilitada vähemalt 12 kuud, välja arvatud juhul, kui seadus või leping nõuab pikemat säilitustähtaega või kui see on põhjendatud aktiivse intsidendi või õigusvaidluse osana.

Ja see määrab kaitseootuse. Juhtimisnõuded, punkt 5.3.1:

Loge tuleb säilitada kirjutuskaitstud asukohtades ning juurdepääs peab olema piiratud ainult volitatud personalile.

Ettevõtte intsidentidele reageerimise puhul nõuab tõendite kogumise ja kohtuekspertiisi poliitika, poliitika rakendamise nõuded, punkt 6.3.1:

Tulemüüride, SIEM-i, lõppseadme agentide, identiteedi- ja juurdepääsuhalduse (IAM) platvormide ning pilveplatvormide logid tuleb eksportida ja säilitada muutmatutes vormingutes.

VKE versioon lisab proportsionaalsuse kaitsepiirde. Tõendite kogumise ja kohtuekspertiisi poliitika VKE-dele, riskikäsitlus ja erandid, punkt 7.2.1 sätestab:

Minimeeri kogumise ulatus; kogu ainult seda, mis on vajalik.

See on privaatsust arvestava logimise tuum: säilita vajalik, tõenda, miks see on vajalik, piira juurdepääsu ning kustuta see, kui heakskiidetud eesmärk lõpeb.

Clarysec kontrollimudel privaatsust säilitava tõendusmaterjali jaoks

Zenith Blueprint: auditeerija 30-sammuline teekaart paigutab Clarysec logimise etappi „kontrollimeetmed praktikas”, samm 19: tehnilised kontrollimeetmed I. Juhend selgitab ISO/IEC 27002:2022 kontrolliootust:

A.8.15 – logimine: „Tuleb luua, säilitada, kaitsta ja analüüsida loge, mis registreerivad tegevusi, erandeid, tõrkeid ja muid asjakohaseid sündmusi.”

Sama samm juhendab organisatsioone looma loge võtmesündmuste kohta, säilitama neid turvaliselt nii, et neid ei saaks muuta, hoidma neid määratletud aja jooksul ning analüüsima neid SIEM-i või läbivaatamisprotsessi kaudu. See seob logimise ka GDPR-i rikkumisest teavitamise, DORA intsidendikirjete, NIS2 riskijuhtimise ja COBIT turbelogide analüüsiga.

Kuid logimisest üksi ei piisa. Samas etapis „kontrollimeetmed praktikas”, samm 19, käsitleb Zenith Blueprint kustutamist. See hoiatab, et andmete säilitamine pärast nende operatiivse väärtuse lõppemist suurendab kokkupuudet ja regulatiivset riski, ning nimetab selgelt varukoopiad, kettatõmmised ja arhiivid. See on oluline, sest SIEM-i säilitamisreegel on sisutu, kui replikeeritud logiarhiivid või pilve objektisalvestuse konteinerid hoiavad sama isikut tuvastavat teavet määramata aja.

Samm 23: organisatsioonilised kontrollimeetmed käsitleb Zenith Blueprint tõendite kogumist. See sätestab, et intsidendi tõendusmaterjal tuleb tuvastada, koguda ja säilitada viisil, mis on õiguslikult vastuvõetav, usaldusväärne ja kooskõlas uurimisvajadustega. Samuti rõhutab see operatiivset tegelikkust: tõendusmaterjal kaob sageli reageerimise esimestel minutitel, kui logid üle kirjutatakse, süsteemid taaskäivitatakse või administraatorid muudavad kompromiteeritud kontosid enne tõmmiste tegemist.

Samm 23 käsitleb ka privaatsust ja isikut tuvastava teabe kaitset. Juhend käsitleb isikut tuvastavat teavet elutsükli küsimusena, mis nõuab andmeteadlikkust, klassifitseerimist, juurdepääsukontrolli, maskeerimist, kustutamist, krüptimist ja tarnijakohustusi. Logide puhul tähendab see, et SIEM, EDR, pilvelogimise platvorm ja piletihaldussüsteem peavad kuuluma isikut tuvastava teabe registrisse.

Raamistikeülene vastendus isikut tuvastava teabe jaoks logides

Zenith Controls: raamistikeülene vastavusjuhend seob ISO/IEC 27002:2022 kontrolli 8.15, logimine, seotud kontrollimeetmetega, mis on isikut tuvastava teabe juhtimiseks hädavajalikud. Need seosed näitavad, miks logimine ei ole ainult SOC-i küsimus.

Zenith Controls seob logimise ka ISO/IEC 27002:2022 punktiga 8.15, ISO/IEC 27035-1 ja ISO/IEC 27035-2-ga intsidendihalduse jaoks, ISO/IEC 27701-ga isikut tuvastava teabe töötlemistoimingute logimise jaoks, ISO/IEC 27017-ga pilve auditilogide jaoks, ISO/IEC 27018-ga pilves isikut tuvastavale teabele juurdepääsu logimise jaoks, ISO/IEC 27005-ga ebapiisavast logimisest tulenevate riskide jaoks, ISO/IEC 27033-ga võrgutegevuse logimise jaoks ja ISO/IEC 15408-2-ga hinnatud toodete auditifunktsionaalsuse jaoks.

Privaatsuse osas seob Zenith Controls ISO/IEC 27002:2022 kontrolli 5.34, privaatsus ja isikut tuvastava teabe kaitse, varade registri, andmete maskeerimise, pilveteenuste, klassifitseerimise, teabe edastamise, juurdepääsukontrolli, identiteedihalduse ning projektide ja muudatuste turbeülevaatusega. Logide haldusprogrammi jaoks muutuvad need seosed praktilisteks disaininõueteks:

• Kanna logihoidlad registrisse isikut tuvastava teabe asukohtadena.
• Maskeeri või tokeniseeri isikut tuvastav teave, kui täielikud identifikaatorid ei ole vajalikud.
• Vaata pilvelogimise teenused ja SIEM-i tarnijad üle pilve- ja tarnijakontrollide alusel.
• Klassifitseeri isikut tuvastavat teavet sisaldavad logid tundlike kirjetena.
• Juhi logieksporte ja -edastusi isikut tuvastava teabe edastustena.
• Piira logidele juurdepääsu identiteedi- ja privilegeeritud juurdepääsu kontrollide kaudu.
• Vaata rakenduse logimise muudatused enne tootmiskeskkonda viimist üle.

GDPR, NIS2 ja DORA: üks logi, kolm regulatiivset vaadet

Sama logikirjet võib GDPR, NIS2 ja DORA alusel vaadelda erinevalt.

GDPR-i alusel küsib organisatsioon, kas logikirje sisaldab isikuandmeid, milline õiguslik alus töötlemist toetab, kas andmed on vajalikud, kui kaua neid säilitatakse, kellel on juurdepääs, kas neid avalikustatakse volitatud töötlejatele või klientidele ning kas neid tuleb arvestada õiguste taotluse või rikkumise hindamise käigus.

NIS2 alusel küsib organisatsioon, kas logid toetavad küberturbe riskijuhtimist, intsidentide käsitlemist, talitluspidevust, juurdepääsukontrolli, tarneahela turvet ja kontrollimeetmete tõhususe hindamist. NIS2 Article 20 paneb juhtorganitele vastutuse küberturbe riskijuhtimismeetmete heakskiitmise ja järelevalve eest. Article 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja organisatsioonilisi meetmeid, sealhulgas intsidentide käsitlemist, talitluspidevust, tarneahela turvet, turvalist arendust, haavatavuste käsitlemist, tõhususe hindamist, küberhügieeni, juurdepääsukontrolli ja varahaldust. Article 23 loob oluliste intsidentide astmelise aruandluse, sealhulgas varajase hoiatuse 24 tunni jooksul, teavituse 72 tunni jooksul ja lõpparuande ühe kuu jooksul.

DORA alusel peavad finantsüksused käitama dokumenteeritud IKT-riski juhtimise raamistikku. DORA Article 5 määrab vastutuse juhtorganile. Article 10 käsitleb tuvastamist. Article 17 nõuab IKT-ga seotud intsidentide haldusprotsessi. Article 18 käsitleb IKT-ga seotud intsidentide ja küberohtude klassifitseerimist. Article 19 käsitleb olulistest IKT-ga seotud intsidentidest teatamist. Logid toetavad tuvastamist, klassifitseerimist, algpõhjuse analüüsi, mõjuhindamist, reageerimist, taastamist ja parandusmeetmete tõendusmaterjali.

Üksikasjalikum kontrollimeetmete vastendustabel aitab CISO-l põhjendada logimist ilma ebamääraste väideteta nagu „vajame seda turvalisuse jaoks”.

Koosta REG12-s isikut tuvastava teabe logimise kohaldamisala

Clarysec klient käsitleks 02:17 SIEM-i intsidenti juba enne selle tekkimist. Organisatsioon alustab kliendile suunatud rakendusest, mis töötleb kontoandmeid. Enne tootmiskeskkonda viimist kasutab rakenduse omanik REG12-t, et määratleda isikut tuvastava teabe logimise kohaldamisala. Eesmärk on koguda piisavalt sündmusi turbe- ja regulatiivse tõendusmaterjali jaoks ilma mittevajalikke isikuandmeid või sõnumikeha sisu logimata.

Järgmiseks kinnitab privaatsusjuht, kas organisatsioon tegutseb iga logiallika puhul vastutava töötleja, volitatud töötleja või mõlemana. Kui organisatsioon on volitatud töötleja, võivad kliendi lepingulised juhised ja alltöötlejate avalikustused piirata logidele juurdepääsu ja nende jagamist. Kui organisatsioon on vastutav töötleja, tuleb käsitleda privaatsusteateid, õiguslikku alust ja õiguste käsitlemist.

Seejärel ajakohastab andmete omanik REG02-t, et lisada aktiivsed logihoidlad, SIEM-i indeksid, arhiivid, varukoopiad ja ajutised kohtuekspertiisi ekspordid. See on kooskõlas isikut tuvastava teabe säilitamise, kustutamise ja kõrvaldamise poliitika, varukoopiad, arhiivid, replikad, logid ja ajutised failid, punkt 4.4.1:

[Mõlemad] Süsteemiomanik / rakenduse omanik PEAB tuvastama aktiivsed hoidlad, arhiivid, varukoopiad, replikad, logid, vahekeskkonnad ja ajutised failid, mis sisaldavad isikut tuvastavat teavet, REG02-s enne tootmiskeskkonda kasutuselevõttu ja iga-aastase säilitamise läbivaatamise käigus.

Andmete säilitamise ja kõrvaldamise poliitika peaks seejärel viima ärilised säilitamisreeglid kooskõlla õiguslike, lepinguliste ja tõendusmaterjali säilitamise nõuetega.

Lõpuks konfigureerib turbemeeskond SIEM-i nii, et paroolid, saladused ja sõnumikehad jäetakse enne andmete sissevõttu välja või redigeeritakse. Isikut tuvastavat teavet sisaldavatele logidele määratakse piiratud indeksid. Säilitamist rakendatakse automaatselt, välja arvatud juhul, kui intsident või õiguslik säilitamiskohustus on heaks kiidetud. Kustutamistoimingud logitakse. Kohtuekspertiisi ekspordid nõuavad heakskiitu ja tõendite valduse ahela jälgimist. Juhtpaneelid kuvavad pseudonüümitud identifikaatoreid seal, kus täielik identiteet ei ole vajalik. Ajalooliste logide päringuid testitakse siseauditite käigus.

See on erinevus väite „logime turvalisuse jaoks” ja tõenduse „logime ainult vajaliku, kaitseme seda, säilitame seda heakskiidetud reeglite alusel ning saame seda kasutada tõendusmaterjalina privaatsuskohustusi rikkumata” vahel.

DSAR-id, kustutamine ja logid: otsusta enne taotluse saabumist

Üks keerulisemaid küsimusi on, kas andmesubjekti tutvumistaotluse või kustutamistaotluse korral tuleb loge otsida, avalikustada või kustutada. Vastus sõltub rollist, eesmärgist, õiguslikust alusest, teostatavusest, eranditest ja säilitamiskohustustest. Kuid juhtimisprotsessi ei saa leiutada iga taotluse jaoks uuesti.

Isikuandmesubjekti õiguste haldamise poliitika, isikusamasuse tuvastamine, kohaldamisala ja hindamine, punkt 4.2.3 sätestab:

[Vastutav töötleja] Protsessiomanik / ettevõtte omanik PEAB tuvastama REG02-st asjakohased süsteemid, kirjed, eesmärgid, isikut tuvastava teabe kategooriad, vastuvõtjad ja säilitamispiirangud enne täitmise hindamist.

See tähendab, et logid peavad olema REG02-s koos selgete metaandmetega: milliseid isikut tuvastava teabe kategooriaid need sisaldavad, millist eesmärki need teenivad, milline säilitamispiirang kohaldub ja kas taotlust saab täita otsese avalikustamise, kokkuvõtliku juurdepääsu, piiramise, tähtaja saabumisel kustutamise või dokumenteeritud õigusliku aluse põhjal keeldumise kaudu.

Clarysec soovitab kolmeastmelist lähenemist:

1. Madala privaatsusmõjuga operatiivlogid, näiteks süsteemisündmuste logid, mis kasutavad pseudonüümseid kasutaja ID-sid, võivad olla otsitavad ja asjakohasel juhul avalikustatavad.
2. Kõrge turbetundlikkusega turbelogid, näiteks SIEM-i korrelatsiooniandmed või ohuteabe kontekst, võivad nõuda filtreerimist, kokkuvõtlikku avalikustamist või piiramist, et vältida tuvastusloogika või kolmanda osapoole andmete avaldumist.
3. Aktiivse intsidendi või õigusliku säilitamiskohustuse all olevat kohtuekspertiisi tõendusmaterjali ei tohi kergekäeliselt muuta. Kustutamist võib seaduslikult põhjendatud juhul edasi lükata või piirata, dokumenteerides otsuse privaatsuse ja õigusvaldkonna sidusrühmade poolt.

Kui andmekaitseametnik ja SOC arutavad iga DSAR-i algusest peale, on organisatsioon ebajärjekindel ja aeglane. Kui REG02 ja REG12 on ajakohased, muutub õiguste käsitlemine tõenduspõhiseks.

Rikkumisest ja intsidendist teatamine: üks sündmus, mitu kella

02:17 teavitus võib käivitada mitu tähtaega. GDPR-i isikuandmetega seotud rikkumise hindamine võib nõuda järelevalveasutuse teavitamist, kui riskilävendid on täidetud. NIS2 olulise intsidendi aruandlus võib nõuda varajast hoiatust 24 tunni jooksul, teavitust 72 tunni jooksul ja lõpparuannet. DORA võib nõuda olulisest IKT-ga seotud intsidendist teatamist esialgse, vahe- ja lõppetapi kaudu. Kliendilepingutes võivad olla veel lühemad teavitamisaknad.

Clarysec isikut tuvastava teabe intsidendi- ja rikkumishalduse poliitika käsitleb seda mitme käivitava asjaolu probleemi otse. Klassifitseerimine ja rikkumise hindamine, punkt 4.2.6:

[Tingimuslik] Privaatsusjuht / PIMS-i juht PEAB hindama iga suure mõjuga isikut tuvastava teabega seotud intsidendi puhul kohaldatavaid õiguslikke, sektoripõhiseid, finantssektori, küberturbe, lepingulisi, kliendi- ja teenusesaaja aruandlust käivitavaid asjaolusid ning dokumenteerima kohaldatavuse tulemuse REG01-s, REG08-s ja REG10-s.

Triaaži käigus peaks organisatsioon küsima:

• Kas ründaja pääses juurde isikuandmetele või ainult metaandmetele?
• Kas logid avaldasid täiendavat isikut tuvastavat teavet volitamata kasutajatele?
• Kas loge on vaja mõjutatud isikute, süsteemide ja ajavahemiku kindlakstegemiseks?
• Kas logid on salvestatud muutmatult ja piiratud juurdepääsuga?
• Kas intsidendiga seotud säilitamiskohustus peatas asjakohaste logide kustutamise?
• Kas mõjutatud on volitatud töötleja kliendid, finantssektori kliendid või teenusesaajad?
• Millised teatamistähtajad kohalduvad ja kes vastutab iga teavituse eest?

Hästi juhitud logid kiirendavad aruandlust, sest annavad otsustajatele usaldusväärsed faktid. Halb logimine põhjustab viivitusi. Ülelogimine tekitab privaatsusriski. Õige vastus on sihitud, kaitstud ja vastendatud logimine.

Tarnijate ja pilve logimine: SIEM-is peituv volitatud töötleja probleem

Enamik organisatsioone ei säilita kõiki loge taristul, mida nad täielikult kontrollivad. Logid liiguvad SIEM-i platvormidesse, EDR-portaalidesse, pilvepõhistesse logimisteenustesse, jälgitavusvahenditesse, piletihaldussüsteemidesse ning hallatud tuvastus- ja reageerimisteenuse pakkujate juurde. GDPR-i alusel võivad need teenuseosutajad olla volitatud töötlejad või alltöötlejad. NIS2 ja DORA alusel võivad nad olla ka otsesed tarnijad, kolmandast isikust IKT-teenuse osutajad, hallatud teenusepakkujad või hallatud turbeteenuse osutajad.

NIS2 Article 21 hõlmab sõnaselgelt tarneahela turvet, tarnijate haavatavusi ja tarnijate üldisi küberturbepraktikaid. DORA lisab finantsüksuste jaoks üksikasjalikud IKT kolmandate osapoolte riskinõuded, sealhulgas lepingueelne hoolsuskontroll, teaberegistrid, auditeerimis- ja juurdepääsuõigused, intsidendiabi, andmete asukoht, andmekaitseklauslid, väljumisstrateegiad ning lepingusätted kriitiliste või oluliste funktsioonide jaoks.

Turbelogides oleva isikut tuvastava teabe puhul peaks tarnijate ülevaatus hõlmama järgmisi küsimusi:

SIEM-i leping ei ole ainult tarkvaratellimus. See on isikut tuvastava teabe töötlemise ja intsidendi tõendusmaterjali sõltuvus.

Auditi vaade: kuidas hindajad testivad isikut tuvastavat teavet turbelogides

Hea audiitor ei aktsepteeri väidet, et „logid on kaitstud”. Ta testib ahelat poliitikast konfiguratsiooni, tõendusmaterjali ja läbivaatamiseni.

Praktiline audititest on lihtne, kuid paljastav: palu SOC-il tuua välja kümne kuu tagune logikirje, mis näitab privilegeeritud juurdepääsu muudatust pilveplatvormil, tõendada, kes sellele logile juurde pääses, tõendada, et seda ei muudetud, näidata säilitamisreeglit, mis lubas selle olemasolu, näidata selles sisalduvaid isikut tuvastava teabe välju ning selgitada, kuidas seda käsitletaks DSAR-i või intsidendiaruande puhul. Kui meeskond ei suuda vastata turbe, privaatsuse ja vastavuse lõikes, on halduskorraldus puudulik.

Levinud leiud isikut tuvastava teabe logide auditites

Clarysec näeb sageli samu mustreid:

• Rakendusmeeskonnad logivad silumiseks täielikke päringukehi, sealhulgas nimesid, e-posti aadresse, kontonumbreid või sõnumisisu.
• SIEM-i indeksid on avatud laiadele IT-administraatorite gruppidele, mitte piiratud SOC-i rollidele.
• Logide säilitamine on seadistatud globaalselt, arvestamata isikut tuvastava teabe tundlikkust, kliendilepinguid või intsidendi säilitamiskohustuse reegleid.
• Pilveteenuse pakkuja logid on lubatud, kuid teenuseosutaja administraatorite juurdepääsu kliendi logiandmetele ei vaadata läbi.
• DSAR-i protseduurid ei maini loge, SIEM-i juhtumeid ega kohtuekspertiisi eksporti.
• Intsidentidele reageerimise tegevusjuhised säilitavad tõendusmaterjali, kuid privaatsusmeeskonnad ei osale klassifitseerimises.
• Varukoopiad ja arhiivid säilitavad logides olevat isikut tuvastavat teavet kauem kui SIEM.
• Arendajad saavad muuta logimistasemeid tootmiskeskkonnas ilma privaatsus- või turbeülevaatuseta.
• Testkeskkonnad saavad tootmiskeskkonna loge koos isikuandmetega.
• Organisatsioonil on NIS2 või DORA aruandluskohustused, kuid ta ei suuda kiiresti usaldusväärset tõendusmaterjali välja tuua.

Need leiud tekivad harva halvast tahtest. Need tekivad killustunud vastutusest. Turbelogid paiknevad SOC-i, platvormitehnika, privaatsuse, õiguse, vastavuse, auditi ja tarnijate vahel. Kui keegi ei vastuta kogu elutsükli eest, tekivad lüngad.

Clarysec kontrollnimekiri auditiks valmis logide halduseks

Kasuta seda kontrollnimekirja oma järgmise juhtimisülevaatuse praktilise lähtekohana:

1. Määratle, millised logiallikad võivad sisaldada isikut tuvastavat teavet: IAM, rakendus, API-lüüs, SIEM, EDR, pilv, andmebaas, võrk, füüsiline juurdepääs ja piletihaldus.
2. Kanna iga logihoidla REG02-sse, sealhulgas aktiivsed hoidlad, arhiivid, varukoopiad, replikad ja ajutised kohtuekspertiisi ekspordid.
3. Määratle isikut tuvastava teabe logimise kohaldamisala REG12-s enne tootmiskasutust või olulisi muudatusi.
4. Tuvasta turbelogide töötlemise eesmärk ja õiguslik alus.
5. Keela paroolide, saladuste, täistokenite ja mittevajalike sõnumikehade logimine.
6. Kasuta maskeerimist, räsimist või pseudonüümimist seal, kus täielikud identifikaatorid ei ole nõutavad.
7. Piira juurdepääsu isikut tuvastavat teavet sisaldavatele logidele rollipõhiselt koos privilegeeritud juurdepääsu läbivaatamisega.
8. Säilita kõrge väärtusega logid muutmatus või kirjutuskaitstud vormingus.
9. Määratle säilitamine logitüübi, õigusliku kohustuse, lepingu, intsidendivajaduse ja privaatsusriski alusel.
10. Rakenda intsidendi säilitamiskohustused koos heakskiidu, kohaldamisala ja lõpptähtajaga.
11. Lisa logid DSAR-i ja kustutamise hindamisloogikasse.
12. Vaata SIEM-i, EDR-i, pilve ja MDR-i tarnijad üle volitatud töötlejate või IKT kolmandate osapooltena.
13. Testi ajalooliste andmete päringut ja tõendusmaterjali terviklust.
14. Vii logimine vastavusse GDPR, ISO 27701, NIS2, DORA, NIST CSF ja COBIT aruandlusvajadustega.
15. Koolita SOC-i, privaatsus- ja rakendusmeeskondi selle osas, mida võib ja mida ei või logida.

See kontrollnimekiri muudab privaatsust arvestava logimise korratavaks kontrolliprotsessiks.

Dilemmast juhatuse tasandi usalduseni

NIS2 muudab küberturbe juhtimisvastutuseks. DORA muudab juhtorgani vastutavaks IKT-riski juhtimise, digitaalse operatsioonilise toimepidevuse strateegia, andmete konfidentsiaalsuse, intsidendikommunikatsiooni ja kolmanda osapoole IKT-teenuste poliitikate eest. ISO/IEC 27001:2022 nõuab tippjuhtkonnalt ISMS-i kooskõlastamist ärieesmärkidega, vastutuste määramist, ressursside tagamist ja pideva täiustamise suunamist.

Seetõttu ei ole isikut tuvastav teave turbelogides kitsas tehniline detail. See on juhatuse tasandi usalduse küsimus. Organisatsiooni suutlikkus tuvastada intsidente, kaitsta isikuandmeid, säilitada tõendusmaterjali, vastata klientidele, rahuldada regulaatorite nõudeid ja taastada tegevus sõltub logimisotsustest, mis tehakse ammu enne intsidenti.

Parimad juhtimisprogrammid ei vali privaatsuse ja turvalisuse vahel. Need määratlevad tugeva turbe jaoks vajaliku minimaalse logimise, kaitsevad seda logimist nõutud juhul tundliku isikut tuvastava teabena ning seovad selle säilitamise, tõendusmaterjali, õiguste käsitlemise ja tarnijakohustustega.

Järgmised sammud Claryseciga

Kui sinu SIEM-i, IAM-i, EDR-i või pilvelogid sisaldavad isikuandmeid, on nüüd aeg neid teadlikult juhtida.

Clarysec saab aidata sul:

• Koostada isikut tuvastava teabe logimise kohaldamisala REG12 abil ja viia see kooskõlla isikut tuvastava teabe turbe- ja juurdepääsukontrolli poliitikaga.
• Inventeerida logihoidlad, arhiivid, varukoopiad ja kohtuekspertiisi ekspordid REG02 abil ning isikut tuvastava teabe säilitamise, kustutamise ja kõrvaldamise poliitika alusel.
• Viia logimise, seire, tõendusmaterjali ja privaatsuse kontrollimeetmed kooskõlla Zenith Blueprint-iga.
• Vastendada kontrollimeetmed GDPR, ISO 27701, NIS2, DORA, NIST CSF ja COBIT nõuete lõikes, kasutades Zenith Controls-i.
• Valmistada ette auditiks valmis tõendusmaterjal ISO, privaatsuse, NIST, COBIT, NIS2 ja DORA kindluse andmise ülevaatusteks.

Alusta ühest kõrge riskiga süsteemist: sinu IAM-platvormist, SIEM-ist või kliendile suunatud rakendusest. Tuvasta, milline isikut tuvastav teave logidesse jõuab, miks seda vaja on, kes sellele juurde pääseb, kui kaua seda säilitatakse ja kuidas seda kasutataks intsidendi või õiguste taotluse ajal. See üks harjutus näitab, kas sinu praegune logimisprogramm on üksnes operatiivne või tõepoolest auditiks valmis.