Personoplysninger (PII) i sikkerhedslogs: GDPR-, NIS2- og DORA-playbook

En sikkerhedsanalytiker åbner SIEM kl. 02:17. Alarmen ser først rutinemæssig ud: flere mislykkede loginforsøg, en vellykket session fra en usædvanlig IP-adresse og derefter en række API-kald mod et endpoint til kundeeksport. Inden for få minutter er hændelseskanalen fyldt. CISO’en vil vide, om der er tale om kontoovertagelse. Juridisk afdeling spørger, om logfilerne indeholder personoplysninger. Den databeskyttelsesansvarlige (DPO) spørger, om bruger-ID’et, IP-adressen, enhedsidentifikatoren og anmodnings-URL’erne i SIEM er omfattet af privatlivsmeddelelsen og fortegnelsen over behandlingsaktiviteter. Den complianceansvarlige spørger, om logfilerne skal bevares med henblik på regulatorisk rapportering. Kundeteamet spørger, om en kunde kan anmode om sletning af de samme logposter i morgen.

Det er her, mange organisationer opdager, at sikkerhedslogning og databeskyttelsesstyring er etableret som adskilte verdener.

Sikkerhedsteams ønsker detaljerede logs, lang opbevaring, uforanderlig lagring og hurtig adgang. Databeskyttelsesteams ønsker dataminimering, formålsbegrænsning, rollebaseret adgang, disciplineret opbevaring og sletning, når data ikke længere er nødvendige. Hændelseshåndterere ønsker bevismateriale bevaret præcis, som det forelå. GDPR’s ansvarlighedsprincip kræver, at organisationen kan forklare, hvorfor personoplysningerne findes, hvem der har tilgået dem, og hvor længe de opbevares. NIS2 og DORA øger tidspresset, fordi væsentlige enheder, vigtige enheder og finansielle organisationer har brug for tilstrækkeligt bevismateriale til at klassificere hændelser, rapportere dem rettidigt og dokumentere effektiv styring af IKT-risiko.

Den ubehagelige sandhed er enkel: Sikkerhedslogs er ofte lagre for personoplysninger. Autentifikationslogs kan indeholde brugernavne, e-mailadresser, IP-adresser, enhedsfingeraftryk og geolokationsdata. Applikationslogs kan eksponere URL’er, søgestrenge, fragmenter af payloads, sagsnumre og meddelelsesindhold. EDR- og cloudlogs kan indeholde værtsnavne knyttet til medarbejdere, filstier med navne, sessionsidentifikatorer og administratorhandlinger. IAM-logs kan afsløre ændringer i rettigheder, gruppemedlemskaber og mislykkede adgangsforsøg til følsomme systemer.

Hvis logs indeholder PII, er de ikke længere kun et ISO 27001-spørgsmål om logning. De bliver et spørgsmål om databeskyttelse, opbevaring, bevismateriale, hændelsesrapportering og leverandørstyring. Clarysec behandler styring af PII i sikkerhedslogs som et tværgående complianceproblem, ikke som et spørgsmål om værktøjskonfiguration.

CISO’ens reelle dilemma: detektionsbevis kontra dataminimering

CISO’en i 02:17-scenariet står over for en reel driftsmæssig konflikt. Hvis logfilerne er for sparsomme, kan SOC ikke detektere kompromittering, rekonstruere tidslinjer eller understøtte NIS2- og DORA-rapportering. Hvis logfilerne er for detaljerede, kan organisationen indsamle flere personoplysninger end nødvendigt, opbevare dem for længe, eksponere dem for for mange administratorer eller undlade at understøtte registreredes rettigheder og gennemsigtighedsforpligtelser efter GDPR.

GDPR definerer personoplysninger bredt som oplysninger, der vedrører en identificeret eller identificerbar fysisk person. Behandling omfatter indsamling, opbevaring, brug, videregivelse, sletning og destruktion. I praksis kan logs, der indeholder IP-adresser, bruger-ID’er, enhedsidentifikatorer eller aktivitetsregistreringer, være personoplysninger afhængigt af konteksten. GDPR-principperne kræver lovlig, rimelig og gennemsigtig behandling, formålsbegrænsning, dataminimering, opbevaringsbegrænsning, integritet og fortrolighed samt ansvarlighed.

Styringsspørgsmålet er ikke: “Må vi nogensinde logge personoplysninger?” Det bedre spørgsmål er: “Hvilke personoplysninger skal vi logge af hensyn til sikkerhed, hændelseshåndtering og compliance, hvilket behandlingsgrundlag understøtter det, hvilke sikkerhedsforanstaltninger gælder, og hvornår skal oplysningerne slettes, anonymiseres eller underlægges godkendt bevaring?”

Clarysecs enterprise-bibliotek for databeskyttelsespolitikker adresserer denne spænding direkte. Databeskyttelses- og privatlivspolitik, krav til implementering af politikken, klausul 6.2.1 fastslår:

Kun data, der er nødvendige til et specifikt og legitimt forretningsformål, må indsamles og behandles.

For SMV’er er samme princip angivet i Databeskyttelses- og privatlivspolitik for SMV’er, krav til implementering af politikken, klausul 6.2.1:

Kun de mindst nødvendige personoplysninger skal indsamles og opbevares

Den sætning bør styre enhver designbeslutning om logning. Er hvert felt i hver logkilde nødvendigt for et defineret sikkerhedsmæssigt, driftsmæssigt, juridisk eller kontraktligt formål?

Hvorfor ISO 27701 ændrer samtalen om logning

ISO/IEC 27001:2022 giver ledelsessystemet: omfang, interessenter, risikovurdering, risikobehandling, operationel styring, overvågning, intern revision og løbende forbedring. ISO/IEC 27002:2022 giver praktisk kontrolvejledning for logning, overvågning, beskyttelse af PII, indsamling af bevismateriale, beskyttelse af registreringer, sletning, adgangsstyring og leverandørstyring. ISO/IEC 27701 udvider styringsmodellen til et ledelsessystem for databeskyttelse ved at fokusere på PII-dataansvarlige og PII-databehandlere, databeskyttelsesroller, registreringer over PII-behandling, databeskyttelse gennem design, håndtering af registreredes rettigheder og databehandlerforpligtelser.

For sikkerhedslogs er ISO 27701 vigtig, fordi den gennemtvinger databeskyttelsesspecifikke spørgsmål, som sikkerhedsteams undertiden springer over:

• Behandler logkilden PII som dataansvarlig, databehandler, fælles dataansvarlig eller underdatabehandler?
• Indgår logdata i fortegnelsen over behandlingsaktiviteter?
• Ved organisationen, hvilke logfelter der indeholder PII?
• Er PII i logs koblet til regler for opbevaring og sletning?
• Informeres databehandlerkunder om adgangslogning vedrørende PII, hvor det er kontraktligt påkrævet?
• Indgår logs ved besvarelse af anmodninger om indsigt, sletning eller begrænsning?
• Vurderes PII-hændelser på tværs af udløsere for databeskyttelse, cybersikkerhed og rapportering i den finansielle sektor?

Clarysecs Politik for PII-sikkerhed og adgangsstyring omsætter dette til operationelle krav. Fra logning og overvågning, klausul 4.6.1:

[Begge] Systemejeren / applikationsejeren SKAL definere omfanget af PII-logning for autentifikationshændelser, adgangshændelser, privilegerede handlinger, PII-eksportaktivitet og væsentlige konfigurationsændringer i REG12 før produktionsbrug eller væsentlig ændring.

Klausul 4.6.2 lukker derefter kredsløbet mellem logning, adgangsstyring og opbevaring:

[Begge] Den informationssikkerhedsansvarlige SKAL sikre, at logfiler, der indeholder PII, er adgangsbegrænsede og koblet til en godkendt regel for opbevaring eller sletning i REG02 eller REG12, før logovervågning påbegyndes.

Det gør PIMS-styring praktisk anvendelig. REG12 definerer, hvilken PII-logning der er tilladt og påkrævet. REG02 identificerer, hvor PII findes, herunder i logs. Regler for opbevaring og sletning er ikke papirarbejde, der tilføjes senere. De bliver forudsætninger for produktionslogning.

Sikkerhedslogs er registreringer, bevismateriale og PII-behandlingsaktivitet

En moden organisation bør ikke behandle logs som disponibel teknisk udstødning. Logs er registreringer. Under en hændelse kan de blive juridisk bevismateriale. Når de indeholder PII, er de også behandlingsdata underlagt databeskyttelsesstyring.

Clarysecs Lognings- og overvågningspolitik definerer forventninger til lognormalisering. Fra styringskrav, klausul 5.1.4:

Krav til logformat og normalisering (f.eks. tidsstempel, bruger-ID, hændelsestype, kilde-IP)

Det er netop de felter, der gør logs nyttige for hændelseshåndtering. Det er også de felter, der ofte gør logs til personoplysninger. Den samme enterprise-politik markerer, hvad der aldrig bør ske, fra styringskrav, klausul 5.3.3:

Lagring af følsomme data i klartekst (f.eks. adgangskoder, kryptografiske hemmeligheder)

Pointen er ikke, at logs skal undgå alle identifikatorer. Pointen er, at identifikatorer skal være tilsigtede, beskyttede og begrundede. Adgangskoder, hemmeligheder, fulde tokens og unødvendige payloads bør ikke logges. Bruger-ID’er, IP-adresser og hændelsesmetadata kan være nødvendige, men de kræver kontroller.

For SMV’er placerer Clarysecs Lognings- og overvågningspolitik for SMV’er databeskyttelsesgennemgang i rollemodellen. Fra roller og ansvar, klausul 4.3.1, kræver den, at organisationen:

Verificerer, at logdata vedrørende personlige eller følsomme oplysninger håndteres i overensstemmelse med GDPR og anden databeskyttelseslovgivning

SMV-versionen angiver også et klart baselinekrav til opbevaring. Fra styringskrav, klausul 5.2.1:

Logfiler skal opbevares i mindst 12 måneder, medmindre en længere opbevaringsperiode kræves efter lov eller kontrakt eller er begrundet som led i en aktiv hændelse eller retlig tvist.

Og den fastsætter beskyttelsesforventningen, fra styringskrav, klausul 5.3.1:

Logfiler skal lagres på skrivebeskyttede lokationer, og adgang skal være begrænset til autoriseret personale

For hændelseshåndtering i enterprise-miljøer kræver Politik for indsamling af bevismateriale og digital efterforskning, krav til implementering af politikken, klausul 6.3.1:

Logfiler fra firewalls, SIEM, endpoint-agenter, Identitets- og adgangsstyring (IAM)-platforme og cloudplatforme skal eksporteres og lagres i immutable formater.

SMV-versionen tilføjer en proportionalitetsafgrænsning. Politik for indsamling af bevismateriale og digital efterforskning for SMV’er, risikobehandling og undtagelser, klausul 7.2.1 fastslår:

Minimer omfanget af indsamlingen; indsamling må kun omfatte det nødvendige.

Det er kernen i logning med indbygget databeskyttelse: Bevar det nødvendige, dokumentér hvorfor det er nødvendigt, begræns hvem der kan se det, og slet det, når det godkendte formål udløber.

Clarysecs kontrolmodel for bevismateriale med databeskyttelse

I Zenith Blueprint: An Auditor’s 30-Step Roadmap placerer Clarysec logning i fasen Controls in Action, Step 19: Technological Controls I. Vejledningen forklarer kontrolforventningen i ISO/IEC 27002:2022:

A.8.15 – Logging: “Logfiler, der registrerer aktiviteter, undtagelser, fejl og andre relevante hændelser, bør produceres, lagres, beskyttes og analyseres.”

Det samme trin instruerer organisationer i at generere logs for centrale hændelser, lagre dem sikkert, så de ikke kan ændres, opbevare dem i en defineret periode og analysere dem via et SIEM eller en gennemgangsproces. Det kobler også logning til underretning om brud efter GDPR, DORA-hændelsesregistreringer, NIS2-risikostyring og COBIT-analyse af sikkerhedslogs.

Men logning alene er ikke nok. I den samme Controls in Action-fase, Step 19, adresserer Zenith Blueprint sletning. Den advarer om, at data, der opbevares ud over den driftsmæssige værdi, øger eksponering og regulatorisk risiko, og den nævner eksplicit sikkerhedskopier, snapshots og arkiver. Det er vigtigt, fordi en SIEM-opbevaringsregel er uden værdi, hvis replikerede logarkiver eller cloud object storage-buckets opbevarer den samme PII på ubestemt tid.

I Step 23: Organizational controls dækker Zenith Blueprint indsamling af bevismateriale. Den fastslår, at bevismateriale fra hændelser skal identificeres, indsamles og bevares på en måde, der er retsligt anvendelig, pålidelig og afstemt med efterforskningsbehov. Den fremhæver også en operationel realitet: Bevismateriale går ofte tabt i de første minutter af responsen, når logs overskrives, systemer genstartes, eller administratorer ændrer kompromitterede konti, før snapshots er taget.

Step 23 adresserer også databeskyttelse og beskyttelse af PII. Vejledningen beskriver PII som et livscyklusspørgsmål, der kræver databevidsthed, klassificering, adgangsstyring, maskering, sletning, kryptering og leverandørforpligtelser. For logs betyder det, at SIEM, EDR, cloudlogningsplatformen og helpdesk-sagsstyringssystemet skal være en del af PII-fortegnelsen.

Kortlægning på tværs af compliancekrav for PII i logs

Zenith Controls: The Cross-Compliance Guide kortlægger ISO/IEC 27002:2022-kontrol 8.15, Logging, til relaterede kontroller, der er afgørende for styring af PII. Disse relationer viser, hvorfor logning ikke kun er et SOC-anliggende.

Zenith Controls kortlægger også Logging til ISO/IEC 27002:2022-klausul 8.15, ISO/IEC 27035-1 og ISO/IEC 27035-2 for hændelsesstyring, ISO/IEC 27701 for logning af PII-behandlingsaktiviteter, ISO/IEC 27017 for cloudrevisionslogs, ISO/IEC 27018 for cloudbaseret adgangslogning vedrørende PII, ISO/IEC 27005 for risici fra utilstrækkelig logning, ISO/IEC 27033 for logning af netværksaktivitet og ISO/IEC 15408-2 for revisionsfunktionalitet i evaluerede produkter.

For databeskyttelse specifikt kortlægger Zenith Controls ISO/IEC 27002:2022-kontrol 5.34, Databeskyttelse og beskyttelse af PII, til aktivfortegnelse, datamaskering, cloudtjenester, klassificering, informationsoverførsel, adgangsstyring, identitetsstyring og sikkerhedsgennemgang af projekter og ændringer. For et program til styring af logs bliver disse koblinger til praktiske designkrav:

• Registrér loglagre som PII-lokationer.
• Maskér eller tokenisér PII, hvor fulde identifikatorer er unødvendige.
• Gennemgå cloudlogningstjenester og SIEM-leverandører under cloud- og leverandørkontroller.
• Klassificér logs, der indeholder PII, som følsomme registreringer.
• Styr logeksporter og overførsler som PII-overførsler.
• Begræns adgang til logs gennem identitetskontroller og kontroller for privilegeret adgang.
• Gennemgå ændringer i applikationslogning før produktionssætning.

GDPR, NIS2 og DORA: én logpost, tre regulatoriske perspektiver

Den samme logpost kan vurderes forskelligt efter GDPR, NIS2 og DORA.

Efter GDPR spørger organisationen, om logposten indeholder personoplysninger, hvilket behandlingsgrundlag der understøtter behandlingen, om dataene er nødvendige, hvor længe de opbevares, hvem der kan tilgå dem, om de videregives til databehandlere eller kunder, og om de skal indgå i en rettighedsanmodning eller vurdering af brud på persondatasikkerheden.

Efter NIS2 spørger organisationen, om logs understøtter cybersikkerhedsrisikostyring, hændelseshåndtering, forretningskontinuitet, adgangsstyring, forsyningskædesikkerhed og vurdering af kontroleffektivitet. NIS2 Article 20 gør ledelsesorganer ansvarlige for at godkende og føre tilsyn med risikostyringsforanstaltninger for cybersikkerhed. Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger, herunder hændelseshåndtering, forretningskontinuitet, forsyningskædesikkerhed, sikker udvikling, sårbarhedshåndtering, vurdering af effektivitet, cyberhygiejne, adgangsstyring og aktivstyring. Article 23 etablerer trinvis rapportering for væsentlige hændelser, herunder tidlig varsling inden for 24 timer, underretning inden for 72 timer og en slutrapport inden for én måned.

Efter DORA skal finansielle enheder drive en dokumenteret ramme for styring af IKT-risiko. DORA Article 5 placerer ansvaret hos ledelsesorganet. Article 10 omhandler detektion. Article 17 kræver en proces for styring af IKT-relaterede hændelser. Article 18 dækker klassificering af IKT-relaterede hændelser og cybertrusler. Article 19 omhandler rapportering af større IKT-relaterede hændelser. Logs understøtter detektion, klassificering, rodårsagsanalyse, konsekvensvurdering, respons, genopretning og bevismateriale for afhjælpning.

En mere detaljeret kontrolkortlægning hjælper CISO’en med at begrunde logning uden at støtte sig på vage udsagn som “vi har brug for det af sikkerhedshensyn”.

Opbyg et omfang for PII-logning i REG12

En Clarysec-kunde ville håndtere 02:17-SIEM-hændelsen, før den overhovedet opstår. Organisationen starter med en kundevendt applikation, der behandler kontodata. Før produktionssætning bruger applikationsejeren REG12 til at definere omfanget af PII-logning. Målet er at registrere nok hændelser til sikkerhed og regulatorisk bevismateriale uden at logge unødvendige personoplysninger eller payloadindhold.

Dernæst bekræfter den databeskyttelsesansvarlige, om organisationen fungerer som dataansvarlig, databehandler eller begge dele for hver logkilde. Hvis organisationen er databehandler, kan kundens kontraktlige instrukser og videregivelse om underdatabehandlere begrænse adgang til og deling af logs. Hvis den er dataansvarlig, skal privatlivsmeddelelser, behandlingsgrundlag og håndtering af rettigheder adresseres.

Dataejeren opdaterer derefter REG02, så live loglagre, SIEM-indekser, arkiver, sikkerhedskopier og midlertidige forensiske eksporter indgår. Dette er i overensstemmelse med Politik for opbevaring, sletning og bortskaffelse af PII, sikkerhedskopier, arkiver, replikaer, logfiler og midlertidige filer, klausul 4.4.1:

[Begge] Systemejeren / applikationsejeren SKAL identificere live lagre, arkiver, sikkerhedskopier, replikaer, logfiler, stagingområder og midlertidige filer, der indeholder PII, i REG02 før idriftsættelse i produktionsmiljøet og ved hver årlig gennemgang af opbevaring.

Dataopbevarings- og bortskaffelsespolitik bør derefter afstemme forretningens opbevaringsregler med juridiske, kontraktlige og bevismæssige bevaringskrav.

Til sidst konfigurerer sikkerhedsteamet SIEM, så adgangskoder, hemmeligheder og payloadindhold frasorteres eller redigeres før indtag. Logs, der indeholder PII, placeres i begrænsede indekser. Opbevaring håndhæves automatisk, medmindre en hændelse eller et bevaringspålæg godkendes. Slettehandlinger logges. Forensiske eksporter kræver godkendelse og sporing af beviskæde. Dashboards viser pseudonymiserede identifikatorer, hvor fuld identitet ikke er nødvendig. Historisk hentning af logs testes under interne revisioner.

Det er forskellen mellem at sige “vi logger af sikkerhedshensyn” og at dokumentere “vi logger kun det nødvendige, beskytter det, opbevarer det efter godkendte regler og kan bruge det som bevismateriale uden at tilsidesætte databeskyttelsesforpligtelser”.

DSAR, sletning og logs: træf beslutningen, før anmodningen kommer

Et af de vanskeligste spørgsmål er, om logs skal gennemsøges, videregives eller slettes som svar på anmodninger om indsigt eller sletning fra registrerede. Svaret afhænger af rolle, formål, retsgrundlag, gennemførlighed, undtagelser og opbevaringsforpligtelser. Men styringsprocessen kan ikke opfindes fra anmodning til anmodning.

Politik for håndtering af registreredes rettigheder, identitetsverifikation, omfang og evaluering, klausul 4.2.3 fastslår:

[Dataansvarlig] Procesejeren / virksomhedsejeren SKAL identificere relevante systemer, registreringer, formål, PII-kategorier, modtagere og opbevaringsbegrænsninger fra REG02, før opfyldelse vurderes.

Det betyder, at logs skal indgå i REG02 med klare metadata: hvilke PII-kategorier de indeholder, hvilket formål de tjener, hvilken opbevaringsbegrænsning der gælder, og om en anmodning kan opfyldes gennem direkte videregivelse, opsummeret indsigt, begrænsning, sletning ved udløb eller afslag baseret på et dokumenteret retsgrundlag.

Clarysec anbefaler en tredelt tilgang:

1. Driftslogs med lav databeskyttelsespåvirkning, såsom systemhændelseslogs med pseudonyme bruger-ID’er, kan være søgbare og videregives, hvor det er relevant.
2. Sikkerhedslogs med høj sikkerhedsfølsomhed, såsom SIEM-korrelationsdata eller kontekst fra trusselsintelligens, kan kræve filtrering, summarisk videregivelse eller begrænsning for at undgå eksponering af detektionslogik eller tredjepartsdata.
3. Forensisk bevismateriale under aktiv hændelse eller bevaringspålæg bør ikke ændres uforsigtigt. Sletning kan udsættes eller begrænses, hvor det er juridisk begrundet, med beslutningen dokumenteret af interessenter inden for databeskyttelse og jura.

Hvis DPO’en og SOC drøfter hver DSAR fra bunden, bliver organisationen inkonsistent og langsom. Hvis REG02 og REG12 vedligeholdes, bliver håndtering af rettigheder evidensbaseret.

Rapportering af brud og hændelser: én hændelse, flere ure

02:17-alarmen kan starte flere ure. Vurdering af brud på persondatasikkerheden efter GDPR kan kræve underretning til en tilsynsmyndighed, hvor risikotærskler er opfyldt. Rapportering af væsentlige hændelser efter NIS2 kan kræve tidlig varsling inden for 24 timer, underretning inden for 72 timer og slutrapport. DORA kan kræve rapportering af større IKT-relaterede hændelser i indledende, mellemliggende og afsluttende faser. Kundekontrakter kan have endnu kortere underretningsfrister.

Clarysecs Politik for PII-hændelses- og brudstyring adresserer direkte dette problem med flere udløsere. Fra klassificering og vurdering af brud, klausul 4.2.6:

[Betinget] Den databeskyttelsesansvarlige / PIMS-ansvarlige SKAL evaluere relevante juridiske, sektorielle, finanssektorrelaterede, cybersikkerhedsmæssige, kontraktlige, kunde- og tjenestemodtagerrelaterede rapporteringsudløsere for hver PII-hændelse med højt konsekvensniveau og registrere anvendelighedsresultatet i REG01, REG08 og REG10.

Under triage bør organisationen spørge:

• Fik angriberen adgang til personoplysninger eller kun metadata?
• Eksponerede logfilerne yderligere PII for uautoriserede brugere?
• Er logs nødvendige for at fastslå berørte personer, systemer og tidsrum?
• Er logs lagret uforanderligt og adgangsbegrænset?
• Har hændelsesbaseret bevaring sat sletning på pause for relevante logs?
• Er databehandlerkunder, kunder i den finansielle sektor eller tjenestemodtagere berørt?
• Hvilke rapporteringsure gælder, og hvem ejer hver underretning?

Velstyrede logs fremskynder rapportering, fordi de giver beslutningstagere pålidelige fakta. Svag logning skaber forsinkelse. Overlogning skaber databeskyttelsesrisiko. Det rigtige svar er målrettet, beskyttet og kortlagt logning.

Leverandør- og cloudlogning: databehandlerproblemet, der gemmer sig i dit SIEM

De fleste organisationer lagrer ikke alle logs på infrastruktur, de selv kontrollerer fuldt ud. Logs flyder til SIEM-platforme, EDR-portaler, cloud-native logningstjenester, observability-værktøjer, helpdesk-sagsstyringssystemer og udbydere af Managed Detection and Response (MDR). Efter GDPR kan disse udbydere være databehandlere eller underdatabehandlere. Efter NIS2 og DORA kan de også være direkte leverandører, IKT-tredjepartstjenesteudbydere, udbydere af administrerede tjenester eller udbydere af administrerede sikkerhedstjenester.

NIS2 Article 21 omfatter eksplicit forsyningskædesikkerhed, leverandørsårbarheder og leverandørernes samlede cybersikkerhedspraksis. DORA tilføjer detaljerede krav til IKT-tredjepartsrisiko for finansielle enheder, herunder due diligence før kontraktindgåelse, informationsregistre, revisions- og adgangsrettigheder, hændelsesbistand, datalokation, databeskyttelsesklausuler, exitstrategier og kontraktbestemmelser for kritiske eller vigtige funktioner.

For PII i sikkerhedslogs bør leverandørgennemgange omfatte disse spørgsmål:

En SIEM-kontrakt er ikke kun et softwareabonnement. Den er en afhængighed for PII-behandling og bevismateriale ved hændelser.

Revisionsperspektiv: hvordan vurderingsparter tester PII i sikkerhedslogs

En god revisor accepterer ikke udsagnet “logs er beskyttet”. Revisor tester kæden fra politik til konfiguration, til bevismateriale og til gennemgang.

En praktisk revisionstest er enkel, men afslørende: Bed SOC om at hente en logpost fra ti måneder siden, der viser en ændring af privilegeret adgang i en cloudplatform, dokumentere hvem der tilgik logposten, dokumentere at den ikke er ændret, vise den opbevaringsregel der tillod, at den eksisterede, vise hvilke PII-felter den indeholder, og vise hvordan den ville blive håndteret i en DSAR eller hændelsesrapport. Hvis teamet ikke kan svare på tværs af sikkerhed, databeskyttelse og compliance, er styringen ufuldstændig.

Almindelige konstateringer i revisioner af PII-logs

Clarysec ser ofte de samme mønstre:

• Applikationsteams logger fulde request-payloads til fejlsøgning, herunder navne, e-mailadresser, kontonumre eller meddelelsesindhold.
• SIEM-indekser er åbne for brede IT-administratorgrupper i stedet for begrænsede SOC-roller.
• Logopbevaring fastsættes globalt uden hensyn til PII-følsomhed, kundekontrakter eller regler for hændelsesbaseret bevaring.
• Cloududbyderlogs er aktiveret, men udbyderadministratorers adgang til kundelogdata gennemgås ikke.
• DSAR-procedurer nævner ikke logs, SIEM-sager eller forensiske eksporter.
• Playbooks for hændelseshåndtering bevarer bevismateriale, men databeskyttelsesteams inddrages ikke i klassificeringen.
• Sikkerhedskopier og arkiver opbevarer PII fra logs længere end SIEM.
• Udviklere kan ændre logningsniveauer i produktion uden databeskyttelses- eller sikkerhedsgennemgang.
• Testmiljøer modtager produktionslogs med personoplysninger.
• Organisationen har rapporteringsforpligtelser efter NIS2 eller DORA, men kan ikke hurtigt hente pålideligt bevismateriale.

Disse konstateringer skyldes sjældent dårlige intentioner. De skyldes siloopdelt ejerskab. Sikkerhedslogs befinder sig mellem SOC, platform engineering, databeskyttelse, jura, compliance, revision og leverandører. Hvis ingen ejer hele livscyklussen, opstår der huller.

En Clarysec-tjekliste for revisionsklar styring af logs

Brug denne tjekliste som praktisk udgangspunkt for jeres næste styringsgennemgang:

1. Definér, hvilke logkilder der kan indeholde PII: IAM, applikation, API-gateway, SIEM, EDR, cloud, database, netværk, fysisk adgang og helpdesk-sagsstyring.
2. Registrér hvert loglager i REG02, herunder live lagre, arkiver, sikkerhedskopier, replikaer og midlertidige forensiske eksporter.
3. Definér omfanget af PII-logning i REG12 før produktionsbrug eller væsentlige ændringer.
4. Identificér formål og behandlingsgrundlag for behandling af sikkerhedslogs.
5. Forbyd adgangskoder, hemmeligheder, fulde tokens og unødvendige payloads i logs.
6. Brug maskering, hashing eller pseudonymisering, hvor fulde identifikatorer ikke er påkrævet.
7. Begræns adgang til logs, der indeholder PII, efter rolle og med gennemgang af privilegeret adgang.
8. Lagre logs med høj værdi i uforanderlige eller skrivebeskyttede formater.
9. Definér opbevaring efter logtype, retlig forpligtelse, kontrakt, hændelsesbehov og databeskyttelsesrisiko.
10. Implementér hændelsesbaseret bevaring med godkendelse, omfang og udløb.
11. Medtag logs i vurderingslogikken for DSAR og sletning.
12. Gennemgå SIEM-, EDR-, cloud- og MDR-leverandører som databehandlere eller IKT-tredjeparter.
13. Test historisk hentning og bevismaterialets integritet.
14. Kortlæg logning til rapporteringsbehov efter GDPR, ISO 27701, NIS2, DORA, NIST CSF og COBIT.
15. Uddan SOC-, databeskyttelses- og applikationsteams i, hvad der må og ikke må logges.

Denne tjekliste gør logning med indbygget databeskyttelse til en gentagelig kontrolproces.

Fra dilemma til tillid på bestyrelsesniveau

NIS2 gør cybersikkerhed til et ledelsesansvar. DORA gør ledelsesorganet ansvarligt for styring af IKT-risiko, strategi for digital operationel robusthed, datafortrolighed, hændelseskommunikation og politikker for tredjeparts-IKT-tjenester. ISO/IEC 27001:2022 kræver, at øverste ledelse tilpasser ISMS til forretningsmål, tildeler ansvar, stiller ressourcer til rådighed og driver løbende forbedring.

PII i sikkerhedslogs er derfor ikke en snæver teknisk detalje. Det er et tillidsspørgsmål på bestyrelsesniveau. Organisationens evne til at detektere hændelser, beskytte personoplysninger, bevare bevismateriale, svare kunder, tilfredsstille tilsynsmyndigheder og genetablere driften afhænger af logningsbeslutninger truffet længe før hændelsen.

De bedste styringsprogrammer vælger ikke mellem databeskyttelse og sikkerhed. De definerer den minimale logning, der er nødvendig for robust sikkerhed, beskytter denne logning som følsom PII, hvor det kræves, og kobler den til opbevaring, bevismateriale, håndtering af rettigheder og leverandørforpligtelser.

Næste skridt med Clarysec

Hvis jeres SIEM-, IAM-, EDR- eller cloudlogs indeholder personoplysninger, er det nu, de skal styres bevidst.

Clarysec kan hjælpe jer med at:

• Opbygge et omfang for PII-logning ved hjælp af REG12 og afstemme det med Politik for PII-sikkerhed og adgangsstyring.
• Registrere loglagre, arkiver, sikkerhedskopier og forensiske eksporter ved hjælp af REG02 og Politik for opbevaring, sletning og bortskaffelse af PII.
• Afstemme logning, overvågning, bevismateriale og databeskyttelseskontroller med Zenith Blueprint.
• Kortlægge jeres kontroller på tværs af GDPR, ISO 27701, NIS2, DORA, NIST CSF og COBIT ved hjælp af Zenith Controls.
• Forberede revisionsklart bevismateriale til ISO-, databeskyttelses-, NIST-, COBIT-, NIS2- og DORA-assurancegennemgange.

Start med ét højrisikosystem: jeres IAM-platform, SIEM eller kundevendte applikation. Identificér, hvilken PII der kommer ind i logfilerne, hvorfor den er nødvendig, hvem der kan tilgå den, hvor længe den opbevares, og hvordan den ville blive brugt under en hændelse eller en rettighedsanmodning. Den ene øvelse vil afsløre, om jeres nuværende logningsprogram blot er driftsmæssigt, eller reelt revisionsklart.