Нарушения на сигурността на личните данни: не спирайте решението за уведомяване

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

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

Разпознайте нарушението, преди да обсъждате уведомяването

Нарушението на сигурността на личните данни е по-широко понятие от откраднатите данни. Член 4, точка 12 от ОРЗД обхваща нарушение на сигурността, което води до случайно или неправомерно унищожаване, загуба, промяна, неразрешено разкриване или достъп до лични данни.

Три измерения имат значение:

Едно събитие може да засяга и трите. Рансъмуерът може да прекъсне достъпа, да повреди записи и да разкрие информация. Възстановяването от резервно копие решава само част от този инцидент.

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

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

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

Установете узнаването и посочете собственика на решението

Съгласно член 33 от ОРЗД администраторът трябва да уведоми компетентния надзорен орган без ненужно забавяне и, когато това е осъществимо, не по-късно от 72 часа, след като е разбрал за нарушението на сигурността на личните данни, освен ако не съществува вероятност нарушението да породи риск за правата и свободите на хората.

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

Дръжте трите времеви отметки отделно:

• Настъпване: кога е станал инцидентът, ако е известно.
• Откриване: кога някой за първи път е забелязал или докладвал възможен инцидент.
• Узнаване: кога организацията е имала достатъчна сигурност, че лични данни са компрометирани.

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

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

Определете координатор на инцидента, който да поддържа хронологията и оставащите въпроси. Техническите ръководители установяват фактите; експертите по защита на данните оценяват последиците и правните изисквания; упълномощен представител на администратора носи отговорност за решението за уведомяване. Когато е определено длъжностно лице по защита на данните (ДЛЗД), включете го своевременно в независимата му консултативна и наблюдаваща роля. Не правете ДЛЗД отговорно за ограничаването на инцидента и не приемайте, че то замества отговорността на администратора.

Посочете заместници. Процес, който зависи от наличността на един ръководител, не е работещ процес извън работно време.

Създайте готов за решение набор от доказателства през първите часове

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

Следващото е практическа последователност за реагиране, а не законов график.

Стабилизирайте инцидента

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

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

Изгответе минималния пакет с факти

Предоставете на проверяващите по защита на данните кратко, структурирано описание, което съдържа:

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

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

Поддържайте опашка с въпроси

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

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

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

Оценявайте вредата за хората, а не само въздействието върху бизнеса

Изключението по член 33 е, че не съществува вероятност от риск за правата и свободите. То не е правило, че трябва да се докладват само големи нарушения, данни от специални категории или доказана вреда.

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

Разглеждайте тези измерения заедно:

Криптирането изисква технически анализ. Диск, криптиран в покой, не защитава непременно информация, до която е осъществен достъп чрез компрометиран акаунт в приложение. Установете слоя на криптиране, разделянето на ключовете, правата на нападателя и дали е бил наличен използваем некриптиран текст. Същата логика се прилага и за хешираните идентификационни данни: защитата им зависи от метода и обстоятелствата, а не от етикета „хеширано“. Вижте криптиране и управление на ключове.

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

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

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

Вземете две отделни решения за комуникация

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

Уведомете с това, което е известно

Член 33 изисква уведомлението да описва естеството на нарушението, включително, ако е възможно, категориите и приблизителния брой на засегнатите лица и записи. То трябва също да съдържа данни за контакт с ДЛЗД или друга точка за контакт, да описва вероятните последици и да описва предприетите или предложените мерки, включително мерките за смекчаване, когато е уместно.

Не чакайте точни бройки, ако са налични надеждни оценки и ясни уговорки. Член 33, параграф 4 позволява информацията да се предоставя на етапи, когато не може да бъде предоставена едновременно, без по-нататъшно ненужно забавяне. Пазете копие от подаденото уведомление, потвърждението за получаване, референтния номер и списък с обещаните актуализации.

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

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

Съобщете, когато има вероятност от висок риск

Член 34 от ОРЗД изисква ясно съобщение на прост език до засегнатите лица без ненужно забавяне, когато има вероятност от висок риск. Съдържанието му включва естеството на нарушението, данни за контакт, вероятните последици и съответните мерки.

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

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

Обработвайте инциденти при обработващи лица, без да губите контрол върху оценката

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

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

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

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

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

Поддържайте следа от решенията, която надживява инцидента

Член 33, параграф 5 изисква документиране на нарушенията на сигурността на личните данни, включително фактите, последиците и предприетите действия за справяне с тях, така че надзорният орган да може да провери спазването. Това включва нарушения, за които не е направено уведомление.

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

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

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

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

Определяйте достъпа и съхранението съзнателно. Член 33 не предвижда универсален срок за съхранение на записите за нарушения. Изберете обоснован график, като вземете предвид отчетността, приложимите задължения и свеждането на данните до минимум. Когато е възможно, пазете препратки към доказателствата, вместо да дублирате обширни набори от лични данни.

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

Практически пример: разкрит експорт от процеса по подбор

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

Да приемем, че една организация открива в петък в 16:00 ч., че експорт от процеса по подбор на персонал може да е достъпен чрез публична връзка към хранилище. Файлът съдържа имената, данните за контакт, бележките по кандидатурите и някои прикачени файлове на 240 кандидати. В 16:20 ч. инженер потвърждава достъпа без удостоверяване и проверява, че файлът съдържа лични данни. Координаторът записва 16:20 ч. като подкрепения момент на узнаване. Крайната 72-часова отправна точка е понеделник в 16:20 ч., въпреки че уведомяването все пак трябва да се извърши без ненужно забавяне.

До 16:35 ч. екипът е премахнал публичния достъп и е запазил историята на конфигурацията и наличните логове за достъп. Тези логове обхващат само част от периода на разкриване. Екипът не може отговорно да заключи, че никой не е осъществил достъп до файла.

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

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

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

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

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

Проследявайте другите задължения за докладване в същата хронология

Един и същ инцидент може да задейства докладване по ОРЗД, по договор, по секторни правила и в областта на киберсигурността. Използвайте една фактическа хронология, но отделни оценки на задълженията, получатели, собственици и срокове.

Член 23 от NIS2 урежда значителните инциденти за обхванатите субекти, независимо дали са засегнати лични данни. Структурата на докладване в ЕС включва ранно предупреждение в рамките на 24 часа, уведомление за инцидента в рамките на 72 часа и по правило окончателен доклад в срок от един месец след уведомлението. NIS2 се прилага чрез националното право: проверете приложимостта, националните процедури и съответните секторни правила, вместо да приемате, че всяка организация има тези задължения.

За обхванатите финансови субекти DORA може да предвижда секторни изисквания. Не дублирайте докладването автоматично и не третирайте едно подаване като изпълняващо всеки режим.

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

Подгответе предаването на задачите преди следващия инцидент

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

Проверете дали екипът може:

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

Когато отговорът зависи от намирането на неизвестно лице или възстановяването на недостъпни идентификационни данни, създайте задача за готовност. Отговорностите на CISO и ДЛЗД трябва да са достатъчно ясни, за да може установяването на техническите факти и независимите съвети по защита на данните да протичат едновременно.

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

Въпроси, които възникват по време на реагирането

Можем ли да изчакаме потвърждение за изтриване, преди да решим?

Потърсете го своевременно, но продължете оценката паралелно. Значението му зависи от получателя, съдържанието и възможния последващ достъп. Искане без отговор не е доказателство, че разкриването е приключило.

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

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

Кога може да бъде закрит инцидентът?

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