PII (лични данни) в журналите за сигурност: наръчник за GDPR, NIS2 и DORA

Анализатор по сигурността отваря SIEM в 02:17. Първоначално предупреждението изглежда рутинно: множество неуспешни входове, успешна сесия от необичаен IP адрес, последвана от серия API заявки към крайна точка за експорт на клиентски данни. След минути каналът за инцидента е пълен. CISO иска да знае дали става дума за компрометиране на акаунт. Правният отдел пита дали журналите съдържат лични данни. Длъжностното лице по защита на данните (DPO) пита дали потребителският идентификатор, IP адресът, идентификаторът на устройството и URL адресите на заявките в SIEM са обхванати от уведомлението за поверителност и регистъра на дейностите по обработване. Мениджърът по съответствието пита дали журналите трябва да бъдат запазени за регулаторно докладване. Екипът за работа с клиенти пита дали клиент може утре да поиска изтриване на същите журнални записи.

Точно тук много организации установяват, че регистрирането за целите на сигурността и управлението на поверителността са изградени като отделни светове.

Екипите по сигурността искат подробни журнали, дълги срокове за съхранение, неизменяемо хранилище и бърз достъп. Екипите по поверителност искат минимизиране, ограничение на целите, ролево базиран достъп, дисциплина при съхранението и изтриване, когато данните вече не са необходими. Екипите за реагиране при инциденти искат доказателствата да бъдат запазени точно във вида, в който са били. Принципът на отчетност по GDPR изисква организацията да може да обясни защо личните данни са там, кой е осъществил достъп до тях и колко дълго се съхраняват. NIS2 и DORA добавят спешност, защото съществените субекти, важните субекти и финансовите организации се нуждаят от достатъчно доказателства, за да класифицират инциденти, да ги докладват навреме и да докажат ефективно управление на ИКТ риска.

Неудобната истина е проста: журналите за сигурност често са хранилища на лични данни. Журналите за автентикация могат да съдържат потребителски имена, имейл адреси, IP адреси, отпечатъци на устройства и геолокация. Журналите на приложения могат да разкриват URL адреси, низове за търсене, фрагменти от съдържанието на заявки, номера на случаи и съдържание на съобщения. EDR и облачните журнали могат да включват имена на хостове, свързани със служители, файлови пътища с имена, идентификатори на сесии и администраторски действия. IAM журналите могат да разкриват промени в привилегиите, членство в групи и неуспешни опити за достъп до чувствителни системи.

Ако журналите съдържат PII, те вече не са само въпрос на регистриране по ISO 27001. Те се превръщат във въпрос на поверителност, съхранение, доказателства, докладване на инциденти и управление на доставчици. Clarysec разглежда управлението на PII в журналите за сигурност като проблем на съответствието между няколко рамки, а не като проблем на конфигурацията на отделен инструмент.

Реалната дилема на CISO: доказателства за откриване срещу минимизиране на данните

CISO в сценария от 02:17 е изправен пред реален оперативен конфликт. Ако журналите са твърде оскъдни, SOC не може да открие компрометиране, да възстанови хронологията или да подпомогне докладването по NIS2 и DORA. Ако журналите са твърде подробни, организацията може да събира повече лични данни от необходимото, да ги съхранява твърде дълго, да ги излага на твърде много администратори или да не успее да изпълни правата по GDPR и задълженията за прозрачност.

GDPR определя личните данни широко като информация, отнасяща се до идентифицирано или идентифицируемо физическо лице. Обработването включва събиране, съхранение, използване, разкриване, изтриване и унищожаване. На практика журнали, съдържащи IP адреси, потребителски идентификатори, идентификатори на устройства или записи за дейност, могат да бъдат лични данни в зависимост от контекста. Принципите на GDPR изискват законосъобразно, добросъвестно и прозрачно обработване, ограничение на целите, свеждане на данните до минимум, ограничение на съхранението, цялостност и поверителност, както и отчетност.

Управленският въпрос не е: „Можем ли изобщо да регистрираме лични данни?“ По-добрият въпрос е: „Каква PII трябва да регистрираме за сигурност, реагиране при инциденти и съответствие, кое правно основание я подкрепя, какви предпазни мерки се прилагат и кога трябва да бъде изтрита, анонимизирана или поставена под одобрено задържане?“

Библиотеката от корпоративни политики за поверителност на Clarysec адресира това напрежение пряко. Политиката за защита на данните и поверителност, изисквания за внедряване на политиката, клауза 6.2.1 гласи:

Могат да се събират и обработват само данни, необходими за конкретна, легитимна бизнес цел.

За МСП същият принцип е посочен в Политиката за защита на данните и поверителност за МСП, изисквания за внедряване на политиката, клауза 6.2.1:

Трябва да се събират и съхраняват само минимално необходимите лични данни

Това изречение следва да ръководи всяко решение при проектирането на регистрирането. Необходимо ли е всяко поле във всеки източник на журнали за конкретна цел, свързана със сигурността, операциите, правните задължения или договора?

Защо ISO 27701 променя разговора за регистрирането

ISO/IEC 27001:2022 предоставя системата за управление: обхват, заинтересовани страни, оценка на риска, третиране на риска, оперативен контрол, мониторинг, вътрешен одит и непрекъснато подобрение. ISO/IEC 27002:2022 предоставя практически насоки за контролите относно регистрирането, мониторинга, защитата на поверителността на PII, събирането на доказателства, защитата на записи, изтриването, контрола на достъпа и управлението на доставчици. ISO/IEC 27701 разширява модела на управление към система за управление на информацията за поверителност, като се фокусира върху администратори и обработващи лични данни по отношение на PII, роли по поверителност, записи за обработване на PII, защита на личните данни още при проектирането, обработване на права и задължения на обработващите лични данни.

За журналите за сигурност ISO 27701 е важен, защото налага специфични за поверителността въпроси, които екипите по сигурността понякога пропускат:

• Обработва ли източникът на журнали PII като администратор, обработващ лични данни, съвместен администратор или подизпълнител по обработване?
• Включени ли са журналните данни в инвентара на дейностите по обработване?
• Знае ли организацията кои полета в журналите съдържат PII?
• Свързана ли е PII в журналите с правила за съхранение и изтриване?
• Информирани ли са клиентите, за които организацията действа като обработващ лични данни, за регистрирането на достъпа до PII, когато това се изисква договорно?
• Вземат ли се предвид журналите при отговор на искания за достъп, изтриване или ограничаване?
• Оценяват ли се инцидентите с PII спрямо критерии за поверителност, киберсигурност и докладване във финансовия сектор?

Политиката за сигурност и контрол на достъпа до PII на Clarysec превежда това в оперативни изисквания. От „Регистриране и мониторинг“, клауза 4.6.1:

[И двете] Собственикът на системата / собственикът на приложението ТРЯБВА да дефинира обхвата на регистриране на PII за събития по автентикация, събития по достъп, привилегировани действия, дейности по експорт на PII и съществени промени в конфигурацията в REG12 преди използване в продукционна среда или съществена промяна.

След това клауза 4.6.2 затваря цикъла между регистриране, контрол на достъпа и съхранение:

[И двете] Ръководителят по информационна сигурност ТРЯБВА да гарантира, че журналите, съдържащи PII, са с ограничен достъп и са свързани с одобрено правило за съхранение или изтриване в REG02 или REG12, преди да започне мониторингът на журналите.

Така управлението на PIMS става практично. REG12 определя какво регистриране на PII е разрешено и изискуемо. REG02 идентифицира къде съществува PII, включително в журналите. Правилата за съхранение и изтриване не са документация, добавена впоследствие. Те се превръщат в предварителни условия за регистриране в продукционна среда.

Журналите за сигурност са записи, доказателства и дейност по обработване на PII

Зрялата организация не следва да третира журналите като еднократен технически отпадък. Журналите са записи. По време на инцидент те могат да се превърнат в правни доказателства. Когато съдържат PII, те са и данни от обработване, управлявано от правилата за поверителност.

Политиката за регистриране и мониторинг на Clarysec определя очакванията за нормализация на журналите. От „Изисквания за управление“, клауза 5.1.4:

Изисквания към формата и нормализацията на журналите (напр. времеви маркер, потребителски идентификатор, тип събитие, IP адрес на източника)

Това са точно полетата, които правят журналите полезни за реагиране при инциденти. Те са и полетата, които често превръщат журналите в лични данни. Същата корпоративна политика посочва какво никога не трябва да се допуска, от „Изисквания за управление“, клауза 5.3.3:

Съхранение на чувствителни данни в открит текст (напр. пароли, криптографски тайни)

Смисълът не е журналите да избягват всички идентификатори. Смисълът е идентификаторите да бъдат умишлено избрани, защитени и обосновани. Пароли, тайни, пълни токени и ненужни данни от съдържанието на заявки не следва да се регистрират. Потребителски идентификатори, IP адреси и метаданни за събития може да са необходими, но изискват контроли.

За МСП Политиката за регистриране и мониторинг за МСП на Clarysec поставя прегледа на поверителността в структурата на ролите. От „Роли и отговорности“, клауза 4.3.1, тя изисква организацията да:

Проверява дали журналните данни, свързани с лична или чувствителна информация, се обработват в съответствие с GDPR и други закони за защита на данните

Версията за МСП също така задава ясно базово изискване за съхранение. От „Изисквания за управление“, клауза 5.2.1:

Журналите трябва да се съхраняват най-малко 12 месеца, освен ако по закон или договор не се изисква по-дълъг срок за съхранение или ако такъв срок е обоснован като част от активен инцидент или правен спор.

И определя очакването за защита, от „Изисквания за управление“, клауза 5.3.1:

Журналите трябва да се съхраняват в местоположения със защита от запис, а достъпът трябва да бъде ограничен само до оторизиран персонал

За корпоративно реагиране при инциденти Политиката за събиране на доказателства и форензика, изисквания за внедряване на политиката, клауза 6.3.1 изисква:

Журналите от защитни стени, SIEM, агенти на крайни точки, платформи за управление на идентичности и достъп (IAM) и облачни платформи следва да бъдат експортирани и съхранявани в неизменяем формат.

Версията за МСП добавя пропорционална предпазна мярка. Политиката за събиране на доказателства и форензика за МСП, „Третиране на риска и изключения“, клауза 7.2.1 гласи:

Минимизирайте обхвата на събирането; събирайте само необходимото.

Това е същността на регистрирането, съобразено с поверителността: запазвайте необходимото, доказвайте защо е необходимо, ограничавайте кой може да го вижда и го изтривайте, когато одобрената цел изтече.

Контролният модел на Clarysec за доказателства, съобразени с поверителността

В Zenith Blueprint: 30-стъпкова пътна карта на одитора Clarysec поставя регистрирането във фазата „Контроли в действие“, стъпка 19: Технологични контроли I. Ръководството обяснява очакването за контрол по ISO/IEC 27002:2022:

A.8.15 – Регистриране: „Журнали, които записват дейности, изключения, откази и други релевантни събития, следва да бъдат създавани, съхранявани, защитавани и анализирани.“

Същата стъпка указва на организациите да генерират журнали за ключови събития, да ги съхраняват сигурно, така че да не могат да бъдат променяни, да ги запазват за определен период и да ги анализират чрез SIEM или процес на преглед. Тя също свързва регистрирането с уведомяването за нарушения по GDPR, записите за инциденти по DORA, управлението на риска по NIS2 и анализа на журналите за сигурност по COBIT.

Но само регистрирането не е достатъчно. В същата фаза „Контроли в действие“, стъпка 19, Zenith Blueprint разглежда изтриването. Ръководството предупреждава, че данните, съхранявани след изчерпване на оперативната им стойност, увеличават експозицията и регулаторния риск, и изрично посочва резервни копия, снимки на състоянието и архиви. Това е важно, защото правило за съхранение в SIEM е безсмислено, ако репликирани архиви на журнали или облачни хранилища продължават да съхраняват същата PII за неопределено време.

В стъпка 23: Организационни контроли, Zenith Blueprint разглежда събирането на доказателства. Ръководството посочва, че доказателствата за инцидент трябва да бъдат идентифицирани, събрани и запазени по начин, който е правно допустим, надежден и съобразен с нуждите на разследването. То също подчертава оперативна реалност: доказателствата често се губят в първите минути на реакцията, когато журналите се презаписват, системите се рестартират или администратори променят компрометирани акаунти, преди да бъдат направени снимки на състоянието.

Стъпка 23 разглежда и поверителността и защитата на PII. Ръководството представя PII като въпрос на жизнения цикъл, който изисква осведоменост за данните, класификация, контрол на достъпа, маскиране, изтриване, шифроване и задължения на доставчиците. За журналите това означава, че SIEM, EDR, облачната платформа за регистриране и системата за билети трябва да бъдат част от инвентара на PII.

Съпоставяне на съответствието между рамки за PII в журналите

Zenith Controls: ръководство за съответствие между рамки съпоставя контрол 8.15 „Регистриране“ от ISO/IEC 27002:2022 със свързани контроли, които са съществени за управлението на PII. Тези връзки показват защо регистрирането не е само грижа на SOC.

Zenith Controls също съпоставя регистрирането с клауза 8.15 от ISO/IEC 27002:2022, ISO/IEC 27035-1 и ISO/IEC 27035-2 за управление на инциденти, ISO/IEC 27701 за регистриране на дейности по обработване на PII, ISO/IEC 27017 за облачни одитни журнали, ISO/IEC 27018 за регистриране на достъп до PII в облак, ISO/IEC 27005 за рискове от недостатъчно регистриране, ISO/IEC 27033 за регистриране на мрежова активност и ISO/IEC 15408-2 за одитна функционалност в оценени продукти.

По-конкретно за поверителността Zenith Controls съпоставя контрол 5.34 „Поверителност и защита на PII“ от ISO/IEC 27002:2022 с инвентар на активите, маскиране на данни, облачни услуги, класификация, предаване на информация, контрол на достъпа, управление на идентичности и преглед на сигурността на проекти и промени. За програма за управление на журналите тези връзки се превръщат в практически изисквания към дизайна:

• Инвентаризирайте хранилищата за журнали като местоположения на PII.
• Маскирайте или токенизирайте PII, когато пълните идентификатори не са необходими.
• Преглеждайте облачните услуги за регистриране и доставчиците на SIEM в рамките на контролите за облачни услуги и доставчици.
• Класифицирайте журналите, съдържащи PII, като чувствителни записи.
• Управлявайте експорта и предаването на журнали като предаване на PII.
• Ограничете достъпа до журнали чрез контроли за идентичност и привилегирован достъп.
• Преглеждайте промените в регистрирането на приложения преди пускане в продукционна среда.

GDPR, NIS2 и DORA: един журнал, три регулаторни гледни точки

Един и същ журнален запис може да бъде разгледан различно по GDPR, NIS2 и DORA.

Съгласно GDPR организацията пита дали журналният запис съдържа лични данни, кое правно основание подкрепя обработването, дали данните са необходими, колко дълго се съхраняват, кой може да осъществява достъп до тях, дали се разкриват на обработващи лични данни или клиенти и дали трябва да бъдат взети предвид при искане за упражняване на права или оценка на нарушение.

Съгласно NIS2 организацията пита дали журналите подпомагат управлението на риска за киберсигурността, обработването на инциденти, непрекъсваемостта на дейността, контрола на достъпа, сигурността на веригата на доставки и оценката на ефективността на контролите. NIS2 Article 20 възлага на ръководните органи отчетност за одобряване и надзор върху мерките за управление на риска за киберсигурността. Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки, включително обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурна разработка, обработване на уязвимости, оценка на ефективността, киберхигиена, контрол на достъпа и управление на активите. Article 23 създава поетапно докладване за значителни инциденти, включително ранно предупреждение в рамките на 24 часа, уведомление в рамките на 72 часа и окончателен доклад в рамките на един месец.

Съгласно DORA финансовите субекти трябва да поддържат документирана рамка за управление на ИКТ риска. DORA Article 5 възлага отговорност на ръководния орган. Article 10 разглежда откриването. Article 17 изисква процес за управление на инциденти, свързани с ИКТ. Article 18 обхваща класификацията на инциденти, свързани с ИКТ, и киберзаплахи. Article 19 разглежда докладването на съществени инциденти, свързани с ИКТ. Журналите подпомагат откриването, класификацията, анализа на първопричините, оценката на въздействието, реакцията, възстановяването и доказателствата за ремедиация.

По-подробно съпоставяне на контролите помага на CISO да обоснове регистрирането, без да разчита на неясни твърдения като „трябва ни за сигурността“.

Изграждане на обхват за регистриране на PII в REG12

Клиент на Clarysec би управлявал SIEM инцидента от 02:17 още преди той да се случи. Организацията започва с клиентско приложение, което обработва данни за акаунти. Преди продукционна среда собственикът на приложението използва REG12, за да дефинира обхвата на регистриране на PII. Целта е да се уловят достатъчно събития за сигурност и регулаторни доказателства, без да се регистрират ненужни лични данни или съдържание на заявки.

След това ръководителят по поверителност потвърждава дали организацията действа като администратор, обработващ лични данни или и двете за всеки източник на журнали. Ако организацията е обработващ лични данни, договорните нареждания на клиента и разкриването на подизпълнители по обработване могат да ограничат достъпа до журнали и споделянето им. Ако е администратор, трябва да бъдат адресирани уведомленията за поверителност, правното основание и обработването на права.

След това собственикът на данните актуализира REG02, за да включи активните хранилища на журнали, SIEM индекси, архиви, резервни копия и временни форензични експорти. Това е съгласувано с Политиката за съхранение, изтриване и унищожаване на PII, „Резервни копия, архиви, реплики, журнали и временни файлове“, клауза 4.4.1:

[И двете] Собственикът на системата / собственикът на приложението ТРЯБВА да идентифицира активни хранилища, архиви, резервни копия, реплики, журнали, среди за тестване и временни файлове, съдържащи PII, в REG02 преди въвеждане в продукционна среда и при всеки годишен преглед на съхранението.

След това Политиката за съхранение на данни и унищожаване следва да съгласува бизнес правилата за съхранение с правните, договорните и доказателствените изисквания за запазване.

Накрая екипът по сигурността конфигурира SIEM така, че пароли, тайни и тела на заявки да бъдат отхвърляни или заличавани преди приемане на журнали. Журналите, съдържащи PII, се насочват към индекси с ограничен достъп. Съхранението се прилага автоматично, освен ако не бъде одобрено задържане по инцидент или правно задържане. Действията по изтриване се регистрират. Форензичните експорти изискват одобрение и проследяване на веригата на съхранение. Таблата показват псевдонимизирани идентификатори, когато пълната самоличност не е необходима. Извличането на исторически журнали се тества по време на вътрешни одити.

Това е разликата между твърдението „регистрираме за сигурност“ и доказването „регистрираме само необходимото, защитаваме го, съхраняваме го по одобрени правила и можем да го използваме като доказателство, без да нарушаваме задълженията за поверителност“.

DSAR, изтриване и журнали: решете преди да пристигне искането

Един от най-трудните въпроси е дали журналите трябва да бъдат претърсвани, разкривани или изтривани в отговор на искания за достъп на субект на данни или искания за изтриване. Отговорът зависи от ролята, целта, правното основание, осъществимостта, изключенията и задълженията за съхранение. Но процесът на управление не може да се измисля отделно за всяко искане.

Политиката за управление на правата на субектите на данни, „Проверка на самоличността, обхват и оценка“, клауза 4.2.3 гласи:

[Администратор] Собственикът на процеса / собственикът на бизнеса ТРЯБВА да идентифицира релевантни системи, записи, цели, категории PII, получатели и ограничения за съхранение от REG02, преди да оцени изпълнението.

Това означава, че журналите трябва да бъдат в REG02 с ясни метаданни: какви категории PII съдържат, каква цел обслужват, какво ограничение за съхранение се прилага и дали искането може да бъде изпълнено чрез пряко разкриване, обобщен достъп, ограничаване, изтриване при изтичане на срока или отказ въз основа на документирано правно основание.

Clarysec препоръчва тристепенен подход:

1. Оперативни журнали с ниско въздействие върху поверителността, като системни журнали за събития, използващи псевдонимни потребителски идентификатори, могат да бъдат претърсвани и разкривани, когато е уместно.
2. Журнали за сигурност с висока чувствителност от гледна точка на сигурността, като SIEM корелационни данни или контекст от разузнаване за заплахи, може да изискват филтриране, обобщено разкриване или ограничаване, за да не се разкрива логика за откриване или данни на трети страни.
3. Форензични доказателства под активен инцидент или правно задържане не следва да се променят небрежно. Изтриването може да бъде отложено или ограничено, когато това е правно обосновано, като решението се документира от заинтересованите страни по поверителност и правни въпроси.

Ако DPO и SOC обсъждат всеки DSAR от нулата, организацията ще бъде непоследователна и бавна. Ако REG02 и REG12 се поддържат, обработването на права става основано на доказателства.

Докладване на нарушения и инциденти: едно събитие, няколко срока

Предупреждението от 02:17 може да задейства няколко срока. Оценката на нарушение на сигурността на личните данни по GDPR може да изисква уведомяване на надзорен орган, когато са изпълнени рисковите прагове. Докладването на значителен инцидент по NIS2 може да изисква ранно предупреждение в рамките на 24 часа, уведомление в рамките на 72 часа и окончателен доклад. DORA може да изисква докладване на съществен инцидент, свързан с ИКТ, чрез първоначален, междинен и окончателен етап. Клиентските договори могат да съдържат още по-кратки срокове за уведомяване.

Политиката за управление на инциденти и нарушения с PII на Clarysec адресира пряко този проблем с множество критерии за задействане. От „Класификация и оценка на нарушението“, клауза 4.2.6:

[Условно] Ръководителят по поверителност / PIMS мениджърът ТРЯБВА да оцени приложимите правни, секторни, финансово-секторни, киберсигурностни, договорни, клиентски и свързани с получателите на услуги критерии за докладване за всеки инцидент с PII с високо въздействие и да запише резултата за приложимост в REG01, REG08 и REG10.

По време на триаж организацията следва да попита:

• Осъществил ли е атакуващият достъп до лични данни или само до метаданни?
• Разкрили ли са журналите допълнителна PII на неоторизирани потребители?
• Необходими ли са журналите за определяне на засегнатите лица, системи и период?
• Съхраняват ли се журналите като неизменяеми и с ограничен достъп?
• Спира ли задържане по инцидент изтриването на релевантни журнали?
• Засегнати ли са клиенти, за които организацията е обработващ лични данни, клиенти от финансовия сектор или получатели на услуги?
• Кои срокове за докладване се прилагат и кой отговаря за всяко уведомление?

Добре управляваните журнали ускоряват докладването, защото дават на вземащите решения надеждни факти. Лошото регистриране причинява забавяне. Прекомерното регистриране създава риск за поверителността. Правилният отговор е целево, защитено и картографирано регистриране.

Регистриране при доставчици и в облака: проблемът с обработващия лични данни, скрит във вашия SIEM

Повечето организации не съхраняват всички журнали върху инфраструктура, която контролират напълно. Журналите се насочват към SIEM платформи, EDR портали, cloud-native услуги за регистриране, инструменти за наблюдаемост, системи за билети и доставчици на управлявани услуги за откриване и реагиране. Съгласно GDPR тези доставчици могат да бъдат обработващи лични данни или подизпълнители по обработване. Съгласно NIS2 и DORA те могат също да бъдат преки доставчици, доставчици на услуги в областта на ИКТ от трета страна, доставчици на управлявани услуги или доставчици на управлявани услуги за сигурност.

NIS2 Article 21 изрично включва сигурността на веригата на доставки, уязвимости на доставчици и общите практики на доставчиците за киберсигурност. DORA добавя подробни изисквания за риска от трети страни в областта на ИКТ за финансовите субекти, включително надлежна проверка преди договор, информационни регистри, права на одит и достъп, съдействие при инциденти, местоположение на данните, клаузи за защита на данните, стратегии за изход и договорни разпоредби за критични или важни функции.

За PII в журналите за сигурност прегледите на доставчици следва да включват следните въпроси:

Договорът за SIEM не е само софтуерен абонамент. Той е зависимост за обработване на PII и доказателства при инциденти.

Одитна гледна точка: как оценителите тестват PII в журналите за сигурност

Добрият одитор няма да приеме твърдение, че „журналите са защитени“. Той ще тества веригата от политика към конфигурация, доказателства и преглед.

Практическият одитен тест е прост, но показателен: поискайте от SOC да извлече журнален запис отпреди десет месеца, показващ промяна на привилегирован достъп в облачна платформа, да докаже кой е осъществил достъп до този журнал, да докаже, че той не е бил променян, да покаже правилото за съхранение, което е позволило съществуването му, да покаже PII полетата, които съдържа, и да покаже как би бил обработен при DSAR или доклад за инцидент. Ако екипът не може да отговори през перспективите на сигурността, поверителността и съответствието, управлението е непълно.

Често срещани констатации при одити на журнали с PII

Clarysec често вижда едни и същи модели:

• Екипите по приложенията регистрират пълно съдържание на заявки за отстраняване на грешки, включително имена, имейли, номера на акаунти или съдържание на съобщения.
• SIEM индексите са отворени за широки групи ИТ администратори вместо за ограничени SOC роли.
• Съхранението на журнали е зададено глобално, без да отчита чувствителността на PII, клиентските договори или правилата за задържане при инцидент.
• Журналите на облачния доставчик са активирани, но администраторският достъп на доставчика до клиентски журнални данни не се преглежда.
• Процедурите за DSAR не споменават журнали, SIEM случаи или форензични експорти.
• Наръчниците за реагиране при инциденти запазват доказателства, но екипите по поверителност не участват в класификацията.
• Резервните копия и архивите съхраняват PII от журнали по-дълго от SIEM.
• Разработчиците могат да променят нивата на регистриране в продукционна среда без преглед по поверителност или сигурност.
• Тестовите среди получават продукционни журнали с лични данни.
• Организацията има задължения за докладване по NIS2 или DORA, но не може бързо да извлече надеждни доказателства.

Тези констатации рядко произтичат от лоши намерения. Те произтичат от изолирана собственост. Журналите за сигурност стоят между SOC, платформено инженерство, поверителност, правни въпроси, съответствие, одит и доставчици. Ако никой не притежава целия жизнен цикъл, възникват пропуски.

Контролен списък на Clarysec за управление на журнали, готово за одит

Използвайте този контролен списък като работна отправна точка за следващия си управленски преглед:

1. Определете кои източници на журнали могат да съдържат PII: IAM, приложение, API gateway, SIEM, EDR, облак, база данни, мрежа, физически достъп и система за билети.
2. Запишете всяко хранилище за журнали в REG02, включително активни хранилища, архиви, резервни копия, реплики и временни форензични експорти.
3. Определете обхвата на регистриране на PII в REG12 преди използване в продукционна среда или съществени промени.
4. Идентифицирайте целта и правното основание за обработването на журнали за сигурност.
5. Забранете пароли, тайни, пълни токени и ненужно съдържание на заявки в журналите.
6. Използвайте маскиране, хеширане или псевдонимизация, когато пълните идентификатори не са необходими.
7. Ограничете достъпа до журнали, съдържащи PII, по роли, с преглед на привилегирован достъп.
8. Съхранявайте високостойностни журнали в неизменяем или защитен от запис формат.
9. Определете съхранението по тип журнал, правно задължение, договор, нужда при инцидент и риск за поверителността.
10. Въведете задържане при инцидент с одобрение, обхват и срок на изтичане.
11. Включете журналите в логиката за оценка на DSAR и изтриване.
12. Преглеждайте доставчиците на SIEM, EDR, облачни услуги и MDR като обработващи лични данни или трети страни в областта на ИКТ.
13. Тествайте извличането на исторически данни и целостта на доказателствата.
14. Съпоставете регистрирането с нуждите за докладване по GDPR, ISO 27701, NIS2, DORA, NIST CSF и COBIT.
15. Обучете SOC, екипите по поверителност и екипите по приложенията какво може и какво не може да се регистрира.

Този контролен списък превръща регистрирането, съобразено с поверителността, в повторяем контролен процес.

От дилема към доверие на равнище ръководен орган

NIS2 превръща киберсигурността в отговорност на ръководството. DORA прави ръководния орган отговорен за управлението на ИКТ риска, стратегията за цифрова оперативна устойчивост, поверителността на данните, комуникацията при инциденти и политиките за ИКТ услуги от трети страни. ISO/IEC 27001:2022 изисква висшето ръководство да съгласува ISMS с бизнес целите, да възлага отговорности, да осигурява ресурси и да насърчава непрекъснатото подобрение.

Затова PII в журналите за сигурност не е тесен технически детайл. Това е въпрос на доверие на равнище ръководен орган. Способността на организацията да открива инциденти, да защитава лични данни, да запазва доказателства, да отговаря на клиенти, да удовлетворява регулатори и да възстановява операциите зависи от решения за регистриране, взети много преди инцидента.

Най-добрите програми за управление не избират между поверителност и сигурност. Те определят минималното регистриране, необходимо за силна сигурност, защитават това регистриране като чувствителна PII, когато е необходимо, и го свързват със съхранение, доказателства, обработване на права и задължения на доставчици.

Следващи стъпки с Clarysec

Ако вашите SIEM, IAM, EDR или облачни журнали съдържат лични данни, сега е моментът да ги управлявате целенасочено.

Clarysec може да ви помогне да:

• Изградите обхват на регистриране на PII чрез REG12 и да го съгласувате с Политиката за сигурност и контрол на достъпа до PII.
• Инвентаризирате хранилища за журнали, архиви, резервни копия и форензични експорти чрез REG02 и Политиката за съхранение, изтриване и унищожаване на PII.
• Съгласувате контролите за регистриране, мониторинг, доказателства и поверителност със Zenith Blueprint.
• Съпоставите контролите си между GDPR, ISO 27701, NIS2, DORA, NIST CSF и COBIT чрез Zenith Controls.
• Подготвите доказателства, готови за одит, за прегледи за уверение по ISO, поверителност, NIST, COBIT, NIS2 и DORA.

Започнете с една високорискова система: вашата IAM платформа, SIEM или клиентско приложение. Идентифицирайте каква PII постъпва в журналите, защо е необходима, кой може да осъществява достъп до нея, колко дълго се съхранява и как би се използвала по време на инцидент или искане за упражняване на права. Това единствено упражнение ще покаже дали текущата ви програма за регистриране е само оперативна, или действително готова за одит.