PII v bezpečnostních logech: playbook pro GDPR, NIS2 a DORA

Bezpečnostní analytik otevírá ve 02:17 SIEM. Upozornění na první pohled vypadá rutinně: několik neúspěšných přihlášení, úspěšná relace z neobvyklé IP adresy a následně série volání API na koncový bod pro export zákaznických dat. Během několika minut je incidentní kanál plný. Ředitel informační bezpečnosti chce vědět, zda jde o převzetí účtu. Právní oddělení se ptá, zda logy obsahují osobní údaje. Pověřenec pro ochranu osobních údajů se ptá, zda se na uživatelské ID, IP adresu, identifikátor zařízení a URL požadavků v SIEM vztahuje oznámení o ochraně osobních údajů a záznamy o činnostech zpracování. Manažer compliance se ptá, zda musí být logy uchovány pro regulatorní oznámení. Tým péče o zákazníky se ptá, zda může zákazník zítra požádat o výmaz stejných záznamů v logu.

Právě v této situaci mnoho organizací zjistí, že bezpečnostní protokolování a správa ochrany soukromí byly vybudovány jako oddělené světy.

Bezpečnostní týmy chtějí podrobné logy, dlouhou dobu uchování, neměnné úložiště a rychlý přístup. Týmy ochrany soukromí chtějí minimalizaci, účelové omezení, přístup podle rolí, disciplinované uchovávání a výmaz, jakmile údaje již nejsou potřeba. Týmy reakce na incidenty chtějí důkazy uchované přesně v původním stavu. Odpovědnost podle GDPR vyžaduje, aby organizace uměla vysvětlit, proč se osobní údaje v logu nacházejí, kdo k nim přistupoval a jak dlouho jsou uchovávány. NIS2 a DORA zvyšují naléhavost, protože základní subjekty, důležité subjekty a finanční organizace potřebují dostatek důkazů pro klasifikaci incidentů, včasné oznámení a prokázání účinného řízení rizik v oblasti ICT.

Nepříjemná skutečnost je jednoduchá: bezpečnostní logy jsou často úložišti osobních údajů. Autentizační logy mohou obsahovat uživatelská jména, e-mailové adresy, IP adresy, otisky zařízení a geolokaci. Aplikační logy mohou zpřístupňovat URL, vyhledávací řetězce, fragmenty payloadů, čísla případů a obsah zpráv. Logy EDR a cloudové logy mohou zahrnovat názvy hostitelů přiřaditelné zaměstnancům, cesty k souborům se jmény, identifikátory relací a administrátorské akce. Logy IAM mohou odhalovat změny oprávnění, členství ve skupinách a neúspěšné pokusy o přístup k citlivým systémům.

Pokud logy obsahují osobní údaje (PII), nejde již pouze o otázku protokolování podle ISO 27001. Stává se z nich otázka ochrany soukromí, uchovávání, důkazů, oznamování incidentů a řízení dodavatelů. Clarysec přistupuje ke správě osobních údajů (PII) v bezpečnostních logech jako k problému souladu napříč rámci, nikoli jako k problému konfigurace nástroje.

Skutečné dilema CISO: důkazy pro detekci versus minimalizace z hlediska ochrany soukromí

CISO ve scénáři z 02:17 čelí skutečnému provoznímu konfliktu. Pokud jsou logy příliš chudé, SOC nedokáže detekovat kompromitaci, rekonstruovat časové osy ani podpořit oznamování podle NIS2 a DORA. Pokud jsou logy příliš bohaté, organizace může shromažďovat více osobních údajů, než je nezbytné, uchovávat je příliš dlouho, zpřístupnit je příliš mnoha administrátorům nebo nedokázat zajistit práva podle GDPR a povinnosti transparentnosti.

GDPR vymezuje osobní údaje široce jako informace vztahující se k identifikované nebo identifikovatelné fyzické osobě. Zpracování zahrnuje shromažďování, ukládání, používání, zpřístupnění, výmaz a zničení. V praxi mohou být logy obsahující IP adresy, uživatelská ID, identifikátory zařízení nebo záznamy aktivit osobními údaji v závislosti na kontextu. Zásady GDPR vyžadují zákonné, korektní a transparentní zpracování, účelové omezení, minimalizaci údajů, omezení uložení, integritu a důvěrnost a také odpovědnost.

Otázka správy a řízení nezní: „Můžeme někdy protokolovat osobní údaje?“ Správnější otázka zní: „Jaké osobní údaje (PII) potřebujeme protokolovat pro bezpečnost, reakci na incidenty a soulad, jaký právní základ to podporuje, jaká ochranná opatření se uplatní a kdy musí být údaje vymazány, anonymizovány nebo zařazeny do schváleného pozastavení mazání?“

Knihovna podnikových politik ochrany soukromí Clarysec toto napětí řeší přímo. Politika ochrany dat a soukromí, Požadavky na implementaci politiky, ustanovení 6.2.1 stanoví:

Shromažďovat a zpracovávat lze pouze údaje nezbytné pro konkrétní legitimní obchodní účel.

Pro SME je stejný princip uveden v Politice ochrany dat a soukromí pro SME, Požadavky na implementaci politiky, ustanovení 6.2.1:

Shromažďovat a uchovávat se musí pouze minimální nezbytný rozsah osobních údajů.

Tato věta musí řídit každé návrhové rozhodnutí v oblasti protokolování. Je každé pole v každém zdroji logů nezbytné pro definovaný bezpečnostní, provozní, právní nebo smluvní účel?

Proč ISO 27701 mění diskusi o protokolování

ISO/IEC 27001:2022 poskytuje systém řízení: rozsah, zainteresované strany, posouzení rizik, ošetření rizik, provozní řízení, monitorování, interní audit a neustálé zlepšování. ISO/IEC 27002:2022 poskytuje praktické pokyny k opatřením pro protokolování, monitorování, ochranu soukromí a ochranu osobních údajů (PII), sběr důkazů, ochranu záznamů, výmaz, řízení přístupu a řízení dodavatelů. ISO/IEC 27701 rozšiřuje model správy a řízení na systém řízení informací o soukromí se zaměřením na správce a zpracovatele PII, role v ochraně soukromí, záznamy o zpracování PII, ochranu osobních údajů již od návrhu, vyřizování práv a povinnosti zpracovatele.

U bezpečnostních logů je ISO 27701 důležitá, protože vynucuje otázky specifické pro ochranu soukromí, které bezpečnostní týmy někdy opomíjejí:

• Zpracovává zdroj logů osobní údaje (PII) jako správce, zpracovatel, společný správce nebo dílčí zpracovatel?
• Jsou data v logech zahrnuta v evidenci činností zpracování?
• Ví organizace, která pole logů obsahují osobní údaje (PII)?
• Jsou osobní údaje (PII) v logech navázány na pravidla uchovávání a výmazu?
• Jsou zákazníci zpracovatele informováni o protokolování přístupu k PII, pokud to vyžaduje smlouva?
• Zohledňují se logy při odpovědích na žádosti o přístup, výmaz nebo omezení zpracování?
• Jsou incidenty týkající se PII posuzovány napříč spouštěči pro oznamování v oblasti ochrany soukromí, kybernetické bezpečnosti a finančního sektoru?

Politika zabezpečení PII a řízení přístupu od Clarysec převádí tyto otázky do provozních požadavků. Z části Protokolování a monitorování, ustanovení 4.6.1:

[Obě role] Vlastník systému / vlastník aplikace MUSÍ v REG12 před produkčním použitím nebo významnou změnou definovat rozsah protokolování PII pro autentizační události, přístupové události, privilegované akce, exportní činnost PII a významné konfigurační změny.

Ustanovení 4.6.2 následně uzavírá vazbu mezi protokolováním, řízením přístupu a uchováváním:

[Obě role] Vedoucí informační bezpečnosti MUSÍ zajistit, aby logy obsahující PII měly omezený přístup a byly před zahájením monitorování logů navázány na schválené pravidlo uchovávání nebo výmazu v REG02 nebo REG12.

Tím se správa PIMS stává praktickou. REG12 definuje, jaké protokolování PII je povoleno a vyžadováno. REG02 identifikuje, kde se PII nachází, včetně logů. Pravidla uchovávání a výmazu nejsou administrativou doplněnou později. Stávají se předpokladem produkčního protokolování.

Bezpečnostní logy jsou záznamy, důkazy a činnost zpracování PII

Vyspělá organizace by neměla zacházet s logy jako s jednorázovým technickým odpadem. Logy jsou záznamy. Během incidentu se mohou stát právními důkazy. Pokud obsahují osobní údaje (PII), jde zároveň o data zpracování řízená pravidly ochrany soukromí.

Politika protokolování a monitorování od Clarysec definuje očekávání pro normalizaci logů. Z části Požadavky na správu a řízení, ustanovení 5.1.4:

Požadavky na formát a normalizaci logů (např. časové razítko, uživatelské ID, typ události, zdrojová IP adresa)

Právě tato pole činí logy užitečnými pro reakci na incidenty. Zároveň jde často o pole, kvůli nimž se z logů stávají osobní údaje. Stejná podniková politika upozorňuje na to, co se nikdy nemá stát, v části Požadavky na správu a řízení, ustanovení 5.3.3:

Ukládání citlivých dat v prostém textu (např. hesla, kryptografická tajemství)

Smyslem není, aby logy neobsahovaly žádné identifikátory. Smyslem je, aby identifikátory byly záměrné, chráněné a odůvodněné. Hesla, tajemství, úplné tokeny a zbytečné payloady se do logů zapisovat nemají. Uživatelská ID, IP adresy a metadata událostí mohou být nezbytné, ale vyžadují opatření.

Pro SME začleňuje Politika protokolování a monitorování pro SME od Clarysec přezkum ochrany soukromí do struktury rolí. V části Role a odpovědnosti, ustanovení 4.3.1, vyžaduje, aby organizace:

Ověřovala, že data logů vztahující se k osobním nebo citlivým informacím jsou zpracovávána v souladu s GDPR a dalšími právními předpisy o ochraně údajů.

Verze pro SME také stanoví jasný výchozí požadavek na dobu uchování. Z části Požadavky na správu a řízení, ustanovení 5.2.1:

Logy musí být uchovávány alespoň 12 měsíců, pokud právní předpis nebo smlouva nevyžaduje delší dobu uchovávání nebo pokud delší uchovávání není odůvodněno aktivním incidentem či právním sporem.

A stanoví očekávání ochrany v části Požadavky na správu a řízení, ustanovení 5.3.1:

Logy musí být uloženy v umístěních chráněných proti zápisu a přístup musí být omezen pouze na oprávněný personál.

Pro podnikovou reakci na incidenty vyžaduje Politika sběru důkazů a forenzního šetření, Požadavky na implementaci politiky, ustanovení 6.3.1:

Logy z firewallů, SIEM, agentů koncových bodů, platforem pro řízení identit a přístupů (IAM) a cloudových platforem se exportují a ukládají v neměnných formátech.

Verze pro SME přidává mantinel přiměřenosti. Politika sběru důkazů a forenzního šetření pro SME, Ošetření rizik a výjimky, ustanovení 7.2.1 stanoví:

Minimalizujte rozsah sběru; shromažďujte pouze to, co je nezbytné.

To je podstata protokolování zohledňujícího ochranu soukromí: uchovat to, co je nezbytné, prokázat, proč je to nezbytné, omezit, kdo to může vidět, a vymazat to, jakmile schválený účel skončí.

Model opatření Clarysec pro důkazy bezpečné z hlediska ochrany soukromí

V dokumentu Zenith Blueprint: 30kroková roadmapa auditora zařazuje Clarysec protokolování do fáze Opatření v praxi, krok 19: Technická opatření I. Průvodce vysvětluje očekávání opatření podle ISO/IEC 27002:2022:

A.8.15 – Protokolování: „Logy, které zaznamenávají aktivity, výjimky, poruchy a další relevantní události, mají být vytvářeny, ukládány, chráněny a analyzovány.“

Stejný krok organizacím ukládá generovat logy pro klíčové události, bezpečně je ukládat tak, aby nemohly být změněny, uchovávat je po definovanou dobu a analyzovat je prostřednictvím SIEM nebo procesu přezkumu. Zároveň propojuje protokolování s oznamováním porušení zabezpečení podle GDPR, záznamy incidentů podle DORA, řízením rizik podle NIS2 a analýzou bezpečnostních logů podle COBIT.

Samotné protokolování však nestačí. Ve stejné fázi Opatření v praxi, krok 19, Zenith Blueprint řeší výmaz. Upozorňuje, že data uchovávaná nad rámec provozní hodnoty zvyšují expozici a regulatorní riziko, a výslovně zmiňuje zálohy, snapshoty a archivy. To je důležité, protože pravidlo uchovávání v SIEM je bezvýznamné, pokud replikované archivy logů nebo cloudová objektová úložiště uchovávají stejné PII neomezeně dlouho.

V kroku 23: Organizační opatření se Zenith Blueprint věnuje sběru důkazů. Uvádí, že důkazy o incidentu musí být identifikovány, shromážděny a uchovány způsobem, který je právně přípustný, spolehlivý a sladěný s potřebami vyšetřování. Zdůrazňuje také provozní realitu: důkazy se často ztrácejí v prvních minutách reakce, když se logy přepisují, systémy se restartují nebo administrátoři mění kompromitované účty dříve, než jsou pořízeny snapshoty.

Krok 23 se věnuje také ochraně soukromí a ochraně PII. Průvodce rámuje PII jako otázku životního cyklu vyžadující znalost dat, klasifikaci, řízení přístupu, maskování, výmaz, šifrování a povinnosti dodavatelů. U logů to znamená, že SIEM, EDR, cloudová platforma pro protokolování a systém pro správu tiketů musí být součástí evidence PII.

Mapování souladu napříč rámci pro PII v logech

Zenith Controls: průvodce souladem napříč rámci mapuje opatření ISO/IEC 27002:2022 8.15, Protokolování, na související opatření, která jsou nezbytná pro správu PII. Tyto vazby ukazují, proč protokolování není pouze záležitostí SOC.

Zenith Controls také mapuje protokolování na ISO/IEC 27002:2022 ustanovení 8.15, ISO/IEC 27035-1 a ISO/IEC 27035-2 pro řízení incidentů, ISO/IEC 27701 pro protokolování činností zpracování PII, ISO/IEC 27017 pro cloudové auditní logy, ISO/IEC 27018 pro protokolování přístupu k PII v cloudu, ISO/IEC 27005 pro rizika z nedostatečného protokolování, ISO/IEC 27033 pro protokolování síťových aktivit a ISO/IEC 15408-2 pro auditní funkcionalitu v hodnocených produktech.

Konkrétně pro ochranu soukromí mapuje Zenith Controls opatření ISO/IEC 27002:2022 5.34, Ochrana soukromí a ochrana PII, na evidenci aktiv, maskování dat, cloudové služby, klasifikaci, předávání informací, řízení přístupu, správu identit a bezpečnostní přezkum projektů a změn. Pro program správy logů se tyto vazby stávají praktickými návrhovými požadavky:

• Evidujte úložiště logů jako umístění PII.
• Maskujte nebo tokenizujte PII tam, kde úplné identifikátory nejsou nezbytné.
• Přezkoumávejte cloudové služby protokolování a dodavatele SIEM v rámci cloudových a dodavatelských opatření.
• Klasifikujte logy obsahující PII jako citlivé záznamy.
• Řiďte exporty a předávání logů jako předávání PII.
• Omezte přístup k logům prostřednictvím řízení identit a řízení privilegovaných přístupů.
• Přezkoumávejte změny aplikačního protokolování před nasazením do produkce.

GDPR, NIS2 a DORA: jeden log, tři regulatorní pohledy

Na stejný záznam v logu lze podle GDPR, NIS2 a DORA nahlížet odlišně.

Podle GDPR se organizace ptá, zda záznam v logu obsahuje osobní údaje, jaký právní základ podporuje zpracování, zda jsou údaje nezbytné, jak dlouho jsou uchovávány, kdo k nim může přistupovat, zda jsou zpřístupněny zpracovatelům nebo zákazníkům a zda musí být zohledněny v žádosti o uplatnění práv nebo při posouzení porušení zabezpečení osobních údajů.

Podle NIS2 se organizace ptá, zda logy podporují řízení rizik kybernetické bezpečnosti, zvládání incidentů, kontinuitu činností, řízení přístupu, zabezpečení dodavatelského řetězce a posouzení účinnosti opatření. NIS2 Article 20 činí vedoucí orgány odpovědnými za schvalování opatření řízení rizik kybernetické bezpečnosti a dohled nad nimi. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného vývoje, řešení zranitelností, posouzení účinnosti, kybernetické hygieny, řízení přístupu a správy aktiv. Article 23 zavádí vícestupňové oznamování významných incidentů, včetně včasného varování do 24 hodin, oznámení do 72 hodin a závěrečné zprávy do jednoho měsíce.

Podle DORA musí finanční subjekty provozovat dokumentovaný rámec pro řízení rizik v oblasti ICT. DORA Article 5 přisuzuje odpovědnost vedoucímu orgánu. Article 10 se týká detekce. Article 17 vyžaduje proces řízení incidentů souvisejících s ICT. Article 18 upravuje klasifikaci incidentů souvisejících s ICT a kybernetických hrozeb. Article 19 se týká oznamování závažných incidentů souvisejících s ICT. Logy podporují detekci, klasifikaci, analýzu kořenové příčiny, posouzení dopadů, reakci, obnovu a důkazy o nápravě.

Podrobnější mapování opatření napříč rámci pomáhá CISO odůvodnit protokolování bez obecných tvrzení typu „potřebujeme to pro bezpečnost“.

Vytvořte rozsah protokolování PII v REG12

Klient Clarysec by incident v SIEM z 02:17 řešil ještě dříve, než vůbec nastane. Organizace začíná zákaznickou aplikací, která zpracovává údaje o účtech. Před produkčním provozem vlastník aplikace použije REG12 k definování rozsahu protokolování PII. Cílem je zachytit dostatek událostí pro bezpečnostní a regulatorní důkazy bez protokolování zbytečných osobních údajů nebo obsahu payloadů.

Následně vedoucí ochrany soukromí potvrdí, zda organizace u každého zdroje logů vystupuje jako správce, zpracovatel nebo obojí. Pokud je organizace zpracovatelem, smluvní pokyny zákazníků a zpřístupnění dílčím zpracovatelům mohou omezovat přístup k logům a jejich sdílení. Pokud je správcem, musí být řešena oznámení o ochraně osobních údajů, právní základ a vyřizování práv.

Vlastník dat poté aktualizuje REG02 tak, aby zahrnoval živá úložiště logů, indexy SIEM, archivy, zálohy a dočasné forenzní exporty. To je v souladu s Politikou uchovávání, výmazu a likvidace PII, Zálohy, archivy, repliky, logy a dočasné soubory, ustanovení 4.4.1:

[Obě role] Vlastník systému / vlastník aplikace MUSÍ před spuštěním do produkčního prostředí a při každém každoročním přezkumu uchovávání v REG02 identifikovat živá úložiště, archivy, záložní kopie, repliky, logy, staging prostory a dočasné soubory obsahující PII.

Politika uchovávání údajů musí následně sladit obchodní pravidla uchovávání s právními, smluvními požadavky a požadavky na uchování důkazů.

Nakonec bezpečnostní tým nakonfiguruje SIEM tak, aby hesla, tajemství a těla payloadů byla před příjmem logů zahozena nebo začerněna. Logům obsahujícím PII jsou přiřazeny omezené indexy. Uchovávání je vynucováno automaticky, pokud není schváleno pozastavení mazání z důvodu incidentu nebo právní blokace. Akce výmazu jsou protokolovány. Forenzní exporty vyžadují schválení a sledování řetězce svěření. Řídicí panely zobrazují pseudonymizované identifikátory tam, kde není potřeba úplná identita. Na interních auditech se testuje historické vyhledání logů.

To je rozdíl mezi tvrzením „protokolujeme kvůli bezpečnosti“ a prokázáním „protokolujeme pouze to, co je nezbytné, chráníme to, uchováváme to podle schválených pravidel a můžeme to použít jako důkaz bez porušení povinností v oblasti ochrany soukromí“.

DSAR, výmaz a logy: rozhodněte dříve, než žádost dorazí

Jednou z nejobtížnějších otázek je, zda musí být logy prohledány, zpřístupněny nebo vymazány v reakci na žádost subjektu údajů o přístup k osobním údajům nebo žádost o výmaz. Odpověď závisí na roli, účelu, právním základu, proveditelnosti, výjimkách a povinnostech uchovávání. Proces správy a řízení však nelze pro každou žádost vymýšlet znovu.

Politika řízení práv subjektů PII, Ověření identity, rozsah a vyhodnocení, ustanovení 4.2.3 stanoví:

[Správce] Vlastník procesu / vlastník společnosti MUSÍ před vyhodnocením vyřízení identifikovat relevantní systémy, záznamy, účely, kategorie PII, příjemce a retenční omezení z REG02.

To znamená, že logy musí být v REG02 uvedeny s jasnými metadaty: jaké kategorie PII obsahují, jakému účelu slouží, jaké retenční omezení se uplatní a zda lze žádost vyřídit přímým zpřístupněním, souhrnným přístupem, omezením, výmazem po uplynutí lhůty nebo odmítnutím na základě dokumentovaného právního důvodu.

Clarysec doporučuje tříúrovňový přístup:

1. Provozní logy s nízkým dopadem na ochranu soukromí, například systémové logy událostí používající pseudonymní uživatelská ID, mohou být podle okolností prohledatelné a zpřístupnitelné.
2. Bezpečnostní logy s vysokou bezpečnostní citlivostí, například korelační data SIEM nebo kontext informací o hrozbách, mohou vyžadovat filtrování, souhrnné zpřístupnění nebo omezení, aby nedošlo k odhalení detekční logiky nebo údajů třetích stran.
3. Forenzní důkazy pod aktivním pozastavením mazání z důvodu incidentu nebo právní blokace nesmí být nahodile měněny. Výmaz může být odložen nebo omezen, pokud je to právně odůvodněné, přičemž rozhodnutí dokumentují zainteresované strany z oblasti ochrany soukromí a práva.

Pokud pověřenec pro ochranu osobních údajů a SOC diskutují každou DSAR od nuly, organizace bude nekonzistentní a pomalá. Pokud jsou REG02 a REG12 udržovány, vyřizování práv se opírá o důkazy.

Oznamování porušení zabezpečení a incidentů: jedna událost, více lhůt

Upozornění z 02:17 může spustit několik lhůt. Posouzení porušení zabezpečení osobních údajů podle GDPR může vyžadovat oznámení dozorovému úřadu, pokud jsou splněny rizikové prahové hodnoty. Oznamování významných incidentů podle NIS2 může vyžadovat včasné varování do 24 hodin, oznámení do 72 hodin a závěrečnou zprávu. DORA může vyžadovat oznamování závažného incidentu souvisejícího s ICT v úvodní, průběžné a závěrečné fázi. Zákaznické smlouvy mohou mít ještě kratší lhůty pro oznámení.

Politika řízení incidentů a porušení zabezpečení PII od Clarysec tento problém více spouštěčů řeší přímo. Z části Klasifikace a posouzení porušení zabezpečení, ustanovení 4.2.6:

[Podmíněně] Vedoucí ochrany soukromí / manažer PIMS MUSÍ pro každý incident s významným dopadem týkající se PII vyhodnotit použitelné právní, odvětvové, finanční, kyberbezpečnostní, smluvní, zákaznické spouštěče oznamování a spouštěče oznamování příjemcům služeb a zaznamenat výsledek použitelnosti v REG01, REG08 a REG10.

Během triáže by se organizace měla ptát:

• Přistoupil útočník k osobním údajům, nebo pouze k metadatům?
• Zpřístupnily logy další PII neoprávněným uživatelům?
• Jsou logy potřebné k určení dotčených osob, systémů a časového rámce?
• Jsou logy uloženy neměnně a s omezeným přístupem?
• Pozastavilo pozastavení mazání z důvodu incidentu výmaz relevantních logů?
• Jsou dotčeni zákazníci zpracovatele, zákazníci z finančního sektoru nebo příjemci služeb?
• Které oznamovací lhůty se uplatní a kdo vlastní každé oznámení?

Dobře řízené logy urychlují oznamování, protože poskytují osobám s rozhodovací pravomocí spolehlivá fakta. Špatné protokolování způsobuje zpoždění. Nadměrné protokolování vytváří riziko pro ochranu soukromí. Správnou odpovědí je cílené, chráněné a namapované protokolování.

Dodavatelské a cloudové protokolování: problém zpracovatele skrytý ve vašem SIEM

Většina organizací neukládá všechny logy na infrastruktuře, kterou plně ovládá. Logy proudí do platforem SIEM, portálů EDR, cloudově nativních služeb protokolování, nástrojů observability, systémů pro správu tiketů a k poskytovatelům řízené detekce a reakce. Podle GDPR mohou být tito poskytovatelé zpracovateli nebo dílčími zpracovateli. Podle NIS2 a DORA mohou být také přímými dodavateli, poskytovateli služeb IKT z řad třetích stran, poskytovateli řízených služeb nebo poskytovateli řízených bezpečnostních služeb.

NIS2 Article 21 výslovně zahrnuje zabezpečení dodavatelského řetězce, zranitelnosti dodavatelů a celkové postupy kybernetické bezpečnosti dodavatelů. DORA přidává pro finanční subjekty podrobné požadavky na rizika třetích stran v oblasti ICT, včetně předběžné smluvní náležité péče, registrů informací, práv na audit a přístup, součinnosti při incidentech, umístění dat, doložek o ochraně údajů, strategií ukončení a smluvních ustanovení pro kritické nebo důležité funkce.

U PII v bezpečnostních logech musí přezkumy dodavatelů zahrnovat tyto otázky:

Smlouva na SIEM není pouze předplatné softwaru. Je to závislost pro zpracování PII a důkazy o incidentech.

Auditní pohled: jak hodnotitelé testují PII v bezpečnostních logech

Dobrý auditor nepřijme tvrzení, že „logy jsou chráněny“. Otestuje řetězec od politiky přes konfiguraci a důkazy až po přezkum.

Praktický auditní test je jednoduchý, ale výmluvný: požádejte SOC, aby vyhledal záznam v logu z doby před deseti měsíci, který ukazuje změnu privilegovaného přístupu v cloudové platformě, prokázal, kdo k tomuto logu přistoupil, prokázal, že nebyl změněn, ukázal pravidlo uchovávání, které umožnilo jeho existenci, ukázal pole PII, která obsahuje, a ukázal, jak by byl zpracován v DSAR nebo ve zprávě o incidentu. Pokud tým nedokáže odpovědět napříč bezpečností, ochranou soukromí a souladem, správa a řízení nejsou úplné.

Častá zjištění při auditech PII v logech

Clarysec často pozoruje stejné vzorce:

• Aplikační týmy protokolují úplné payloady požadavků pro ladění, včetně jmen, e-mailů, čísel účtů nebo obsahu zpráv.
• Indexy SIEM jsou otevřeny širokým skupinám správců IT namísto omezených rolí SOC.
• Uchovávání logů je nastaveno globálně bez ohledu na citlivost PII, zákaznické smlouvy nebo pravidla pozastavení mazání z důvodu incidentu.
• Logy poskytovatele cloudových služeb jsou zapnuté, ale administrátorský přístup poskytovatele k zákaznickým datům logů se nepřezkoumává.
• Postupy DSAR nezmiňují logy, případy SIEM ani forenzní exporty.
• Playbooky reakce na incidenty uchovávají důkazy, ale týmy ochrany soukromí nejsou zapojeny do klasifikace.
• Zálohy a archivy uchovávají PII v logech déle než SIEM.
• Vývojáři mohou měnit úrovně protokolování v produkčním prostředí bez přezkumu ochrany soukromí nebo bezpečnosti.
• Testovací prostředí dostávají produkční logy s osobními údaji.
• Organizace má oznamovací povinnosti podle NIS2 nebo DORA, ale nedokáže rychle získat spolehlivé důkazy.

Tato zjištění zřídka vycházejí ze špatného úmyslu. Vycházejí ze silového vlastnictví. Bezpečnostní logy leží mezi SOC, platformovým inženýrstvím, ochranou soukromí, právním oddělením, compliance, auditem a dodavateli. Pokud nikdo nevlastní celý životní cyklus, vznikají mezery.

Kontrolní seznam Clarysec pro správu logů připravenou na audit

Použijte tento kontrolní seznam jako pracovní výchozí bod pro další přezkum správy a řízení:

1. Definujte, které zdroje logů mohou obsahovat PII: IAM, aplikace, API brána, SIEM, EDR, cloud, databáze, síť, fyzický přístup a ticketing.
2. Zaznamenejte každé úložiště logů v REG02, včetně živých úložišť, archivů, záloh, replik a dočasných forenzních exportů.
3. Definujte rozsah protokolování PII v REG12 před produkčním použitím nebo významnými změnami.
4. Identifikujte účel a právní základ pro zpracování bezpečnostních logů.
5. Zakažte v logech hesla, tajemství, úplné tokeny a zbytečné payloady.
6. Používejte maskování, hashování nebo pseudonymizaci tam, kde nejsou vyžadovány úplné identifikátory.
7. Omezte přístup k logům obsahujícím PII podle role a zahrňte přezkum privilegovaných přístupů.
8. Ukládejte vysoce hodnotné logy v neměnných formátech nebo formátech chráněných proti zápisu.
9. Definujte uchovávání podle typu logu, právní povinnosti, smlouvy, incidentní potřeby a rizika pro ochranu soukromí.
10. Zaveďte pozastavení mazání z důvodu incidentu se schválením, rozsahem a datem ukončení.
11. Zahrňte logy do logiky vyhodnocení DSAR a výmazu.
12. Přezkoumávejte dodavatele SIEM, EDR, cloudu a MDR jako zpracovatele nebo třetí strany v oblasti ICT.
13. Testujte historické vyhledání a integritu důkazů.
14. Namapujte protokolování na potřeby oznamování podle GDPR, ISO 27701, NIS2, DORA, NIST CSF a COBIT.
15. Školte týmy SOC, ochrany soukromí a aplikační týmy v tom, co se smí a nesmí protokolovat.

Tento kontrolní seznam mění protokolování zohledňující ochranu soukromí v opakovatelný proces opatření.

Od dilematu k důvěře na úrovni řídicích orgánů

NIS2 činí kybernetickou bezpečnost odpovědností vedení. DORA činí vedoucí orgán odpovědným za řízení rizik v oblasti ICT, strategii digitální provozní odolnosti, důvěrnost dat, komunikaci při incidentech a politiky pro služby ICT poskytované třetími stranami. ISO/IEC 27001:2022 vyžaduje, aby vrcholové vedení sladilo ISMS s obchodními cíli, přiřadilo odpovědnosti, poskytlo zdroje a podporovalo neustálé zlepšování.

PII v bezpečnostních logech proto nejsou úzkým technickým detailem. Jde o otázku důvěry na úrovni řídicích orgánů. Schopnost organizace detekovat incidenty, chránit osobní údaje, uchovat důkazy, reagovat vůči zákazníkům, uspokojit regulatorní orgány a obnovit provoz závisí na rozhodnutích o protokolování učiněných dávno před incidentem.

Nejlepší programy správy a řízení si nevybírají mezi ochranou soukromí a bezpečností. Definují minimální protokolování potřebné pro robustní bezpečnost, chrání toto protokolování jako citlivé PII tam, kde je to vyžadováno, a propojují je s uchováváním, důkazy, vyřizováním práv a povinnostmi dodavatelů.

Další kroky s Clarysec

Pokud vaše SIEM, IAM, EDR nebo cloudové logy obsahují osobní údaje, je nyní čas řídit je záměrně.

Clarysec vám pomůže:

• Vytvořit rozsah protokolování PII pomocí REG12 a sladit jej s Politikou zabezpečení PII a řízení přístupu.
• Evidovat úložiště logů, archivy, zálohy a forenzní exporty pomocí REG02 a Politiky uchovávání, výmazu a likvidace PII.
• Sladit protokolování, monitorování, důkazy a opatření ochrany soukromí se Zenith Blueprint.
• Mapovat vaše opatření napříč GDPR, ISO 27701, NIS2, DORA, NIST CSF a COBIT pomocí Zenith Controls.
• Připravit důkazy připravené pro audit pro přezkumy ujištění podle ISO, ochrany soukromí, NIST, COBIT, NIS2 a DORA.

Začněte jedním vysoce rizikovým systémem: vaší platformou IAM, SIEM nebo zákaznickou aplikací. Identifikujte, jaké PII vstupují do logů, proč jsou potřebné, kdo k nim může přistupovat, jak dlouho jsou uchovávány a jak by byly použity během incidentu nebo žádosti o uplatnění práv. Toto jediné cvičení odhalí, zda je váš současný program protokolování pouze provozní, nebo skutečně připravený na audit.