Как защитить персональные данные и не «положить» бизнес-процессы

На одной из прошлых встреч мы разбирали нововведения в КоАП, которые увеличили ответственность за нарушение требований обеспечения безопасности персональных данных и ввели оборотные штрафы за утечку ПДн. Теперь — встречаемся, чтобы разобрать технологии для защиты персональных данных, которые позволят предотвратить их утечку и избежать штрафов.

Глядя на разнообразные возможности для защиты ПДн, представленные на рынке, возникают здравые вопросы и сомнения. А именно: системы либо недостаточно качественно детектируют ПДн в трафике, или же буквально заваливают специалиста ИБ сотнями ложных срабатываний на зарплатные листки и подписи в письмах, напрочь блокируя легитимные бизнес-процессы. Если вам знакома эта ситуация или вы только выбираете средства для защиты персональных данных, участвуйте в сегодняшней встрече и ознакомьтесь с возможностями InfoWatch Traffic Monitor — российской DLP-системой со специализированными запатентованными технологиями для защиты персональных данных и возможностями проверки допустимости получателя. Это позволит качественно защищать ПДн без ущерба бизнес-процессам и затрат времени служб ИБ на ложные срабатывания. Обсудим, почему персональные данные — наиболее сложный информационный актив для защиты Расскажем про технологию InfoWatch для защиты персональных данных, которая позволяет моментально находить кражу даже одной записи ПДн Разберем, как при этом не блокировать ежедневные бизнес-процессы.

Сегодня с нами спикер Александр Клевцов, руководитель по развитию продукта InfoWatch и Traffic Monitor.

Сегодня мы поговорим о том, как защитить персональные данные. У нас такое немного провокационное название «Как защитить персональные данные и не «положить» бизнес-процессы». Как сделать защиту персональных данных эффективной?

В вводной части я напомню о важности защиты персональных данных, расскажу про роль продукта DLP в защите персональных данных. Мы поговорим о проблемах, связанных с защитой персональных данных и проблемах с DLP, почему не все DLP одинаково полезны. Сначала создадим проблему, а потом расскажем про ее решение и рассмотрим конкретные действия.

О важности защиты персональных данных и, самое главное, защиты от утечки персональных данных сказано многое. Проблемы с персональными данными могут приводить к финансовым потерям. По результатам исследований нашего научного центра InfoWatch совместно с одним агентством, мы пришли к выводу, что средний ущерб от утечки составляет от 11,5 до 42 млн рублей.

Здесь имеется в виду как прямой, так и косвенный ущерб, и штрафы, и затраты на расследование утечек, связанных с персональными данными, и затраты на устранение последствий, в общем, это комплексная цифра. Согласно статистике, за 2024 год рост числа скомпрометированных, украденных персональных данных, разного рода утечек, связанных с персональными данными, вырос на 30%. И отдельно хочется подчеркнуть, что 20 % из этих утечек - это умышленные действия сотрудников, внутренних злоумышленников. То есть угроза исходила от сотрудника, он ее и осуществил. Собственный сотрудник украл персональные данные. Разумеется, ужесточилось законодательство по штрафам, связанным с потерей персональных данных.

Давайте вкратце разберем, какие меры необходимо предпринять компании, чтобы организовать защиту персональных данных.

Это комплексная вещь. Она связана и с аттестацией системы, и с сертификациями, и с обучением сотрудников, и с такими техническими мерами, как обеспечение защищенных каналов коммуникации, шифрование, разграничение прав доступа и на уровне систем, где эти персональные данные хранятся, и на уровне операционной системы, и аудит мест хранения этих данных и многое, многое другое. Какие тут акценты хочется расставить? В любой компании всегда есть и будут сотрудники, которые совершенно легитимно имеют доступ к персональным данным в рамках своих производственных обязанностей.

И как ни защищайся от внешнего злоумышленника, как ни организуй каналы шифрования, разграничение прав доступа, кто-то из собственных сотрудников может все равно эти данные похитить. Есть такая стандартная практика на примере банка, когда организуют обработку персональных данных в закрытых контурах. Когда помещают критичные для бизнеса системы, например ABS, в какой-то закрытый контур, из которого нет доступа к Интернету, и вроде бы тем самым снижают риск утечки нарушений, связанных с персональными данными. Но всегда есть сотрудники, которые имеют доступ одновременно к рабочим местам и к закрытому контру, и к открытому контру с Интернетом, и потенциальный риск утечки всегда существует. То есть нужно понимать, что без DLP – никуда. И чтобы мы ни сделали, но без контроля каналов, где эти персональные данные могут быть куда-то переданы, нам не обойтись.

Я анализировал, что говорит рынок, что говорит Интернет нам про проблемы с защитой персональной данных при помощи DLP. Говорят, что достаточно внедрить DLP, как-то произвести аудит, сконфигурировать DLP, и вроде бы персональные данные можно защищать. На самом деле это не совсем так. Я сейчас выражу такую грубую мысль, о том, что DLP в его классическом понимании персональные данные защищают очень плохо. Сейчас объясню почему. Потому что BDN это на самом деле тяжелый такой функционный актив, который сложно защищать.

Вот на слайде, обратите внимание, приведен пример, есть два сообщения. В одном из них - утечка данных под видом безобидного какого-то сообщения. А другое - просто болтовня сотрудников. Два совершенно похожих друг на друга сообщения, но одно из них - утечка, а другое - нет. И это кейс из реальной жизни, когда в одном банке под видом каких-то безобидных сообщений, просто якобы сообщалось о репетиторах по иностранному языку. А на самом деле сотрудник передавал на сторону в таких коротких сообщениях данные по vip-клиентам. Как эти данные потом использовались? Клиенту звонили, представлялись, предлагали более выгодные условия по банковским продуктам. И в итоге заканчивалось тем, что клиент с каким-то очень серьезным финансовым активом переводил обслуживание этих активов в другой банк. Вот такую утечку в классическом дизайне DLP отловить очень трудно. Потому что, как мы будем отлавливать фамилию, имя и номер телефона? Регулярку создадим на фамилию и телефон, тогда у нас будут ЛПСы, вот как на этом слайде, например, на любую подпись в письме. Словари тоже не создашь. Учитывая то, что этих персональных данных могут быть сотни тысяч, если мы говорим про банк, и миллион данных. Получается, что мы никак не можем классифицировать такое сообщение. Если мы, допустим, попытаемся с помощью DLP отлавливать любое сообщение, где упоминаются такие комбинации, как номер телефона, фамилия и имя, то это будет приводить к огромным ложным положительным срабатываниям. Замучаемся потом разгребать такие события. Плюс еще отдельная проблема. Давайте представим себе такую ситуацию, что все-таки настроили так, что система реагирует на любое упоминание о персональных данных, на номер телефона, на упоминание фамилии, имени, то безопасник, глядя на перехваченные события, на потенциальный инцидент с таким текстом, никогда в жизни не поймет, является это утечкой или нет, если только он наизусть не помнит все контактные данные клиентов банка.

Будет в сообщении, например, написано: «Привет! Передаю тебе данные репетитора по французскому языку». Как офицеру безопасности определить, что это утечка? Другое дело, когда сливается реально явная утечка в фотографиях, какая-то таблица Excel или какой-то отчет, где видно, что перечисляются ФИО, адреса, телефоны. Это понятно. И любая DLP на это легко среагирует. И офицер безопасности, глядя на такой массив данных, поймет, что это какой-то набор баз данных. А когда такое маленькое сообщение ни DLP, ни безопасник определить это не могут как утечку.

На самом деле дела еще хуже. Я уже сказал, что DLP хорошо определяет массовые утечки через фильтр, не дает табличку слить.

А вот одно маленькое сообщение, которое неотличимо от любой подписи, определить не может. Такую мелкую утечку очень тяжело отловить. Но, тем не менее, даже такая маленькая утечка может принести прямую финансовую потерю, о которой мы даже, возможно, и не узнаем. Это не те большие утечки, где слили какую-то базу, где-то это всплыло в СМИ, как-то, может быть, специально эту утечку сделали, чтобы скомпрометировать, дискредитировать компанию. А это маленькая тайная утечка, которую как-то использовали, а в итоге мы про нее ничего не знаем. Ни система про нее ничего не знает, ни человек.

Но проблема у нас еще хуже. Проблема в том, что почти в любой компании есть процессы, где передача персональных данных, в том числе за периметр компании, абсолютно легитимный процесс. Всегда есть такие процессы, когда какие-то персональные данные передаются за периметр компании. Это могут быть, например, такие вещи, как почтовые рассылки, где клиентам финансовых организаций предлагают какие-то персональные продукты, какие-то персональные предложения. И вот там рассылают какую-то информацию, вот там тоже передается все это. Но и внутри компании тоже персональные данные часто передаются. Это могут быть зарплатные листки и полисы ДМС, много передается персональных данных как внутри компании, так и за ее периметром. Я это говорю к тому, что не получится так сильно закрутить гайки, чтобы вообще никакие персональные данные передавать было никому и никуда нельзя. Есть куча легитимных процессов, где передаются персональные данные.

И вот тут есть еще более сложная задача. Что делать, если нам нужно определить, что порция персональных данных передается именно их владельцу.

Что, например, персональное предложение клиента банка передается именно клиенту банка. Что персональные чувствительные данные сотрудника передаются конкретно сотруднику. Вот как эту задачу решить, что не просто офицер безопасности видит информацию, и должен понять, что данные передаются, например, клиенту банка. Вот он видит, например, сообщение: «Уважаемый Иван Иванович, мы хотим предложить вам по таким-то продуктам такие-то изменения.» И видит какой-то email личной почты, например, Alex.34@gmail.com. Как безопаснику определить, что это именно email клиента, к которому идет обращение? Это невозможно. Как бы это можно было сделать по идее в DLP-системе?

В DLP-системе, в ее классическом исполнении, нам бы пришлось завести, например, на 1000 порций персональных данных 1000 правил. Конкретная порция персональных данных - конкретный получатель. Конкретная порция - конкретный получатель. Но, если у тебя миллион клиентов, задача опять не решаема.

Давайте подведем итог, какие у нас проблемы с защитой персональных данных?

Персональные данные плохо поддаются классификации. Потому что все персональные данные это часто именованные данные. Это конкретный номер телефона, конкретные ФИО, конкретный адреса и пр. То есть, когда мы говорим про защиту персональных данных, нам важно не отловить какой-то номер телефона, какой-то адрес. Нам нужно отловить конкретный адрес, конкретный номер телефона, конкретное упоминание человека. Это основная проблема защиты перс-данных. Вот тут такой блок стоит: конфиденциальная информация, похожая на публичную. Это продолжение этой же проблемы, что трудно отличить чувствительные персональные данные от публичных.

Вторая проблема – это огромные объемы данных. Это мелкие данные, которые могут исчисляться миллионами записей. И третья принципиальная проблема состоит в том, что у DLP, в ее классическом дизайне, слишком общие правила. Нельзя гранулировано настроить на конкретную порцию данных конкретное правило для конкретного получателя, чтобы определить, что персональные данные получает именно их владелец. То есть, теоретически можно, но тебе придется заводить сотни тысяч правил, и все это поддерживать в актуальном состоянии. Поэтому реализовать его в той парадигме, к которой мы все привыкли, очень трудно.

Поэтому компания InfoWatch, исходя из этих проблем, создала технологию, которая предлагает перейти от анализа контента, который как-то классифицирует персональные данные: номера телефонов, номера счетов, ФИО, адреса, от контента с определением, что это за данные, к контексту, то есть пониманию, что это конкретная порция персональных данных, у которых есть конкретный владелец, у этих данных есть конкретный старт.

Переход к гранулированному определению ценностей персональных данных для каждого владельца, т.е. от контента к контексту. Достигается это путем индексации данных из корпоративных информационных систем. То есть в данном случае DLP система – трафик - монитор интегрируется с корпоративной ERP или CRM, или даже системой электронного документооборота, извлекает оттуда персональные данные, индексирует их. И, если говорить простым языком, создает как бы автоматическую политику, которая включает и может включать в себя сотни тысяч правил, миллионы правил. Руками эту политику не надо поддерживать в актуальном состоянии. Данные индексируются из корпоративных информационных систем и защищаются.

Я предлагаю рассмотреть конкретный пример. Он был реализован с помощью этой технологии.

Есть банк, в котором работают 20 тысяч сотрудников. В этом примере пойдет речь о защите персональных данных этих сотрудников. Необходимо защищать любые данные сотрудников. Это могут быть полисы добровольного медицинского страхования, договоры, зарплатные листы. Защищать нужно следующим образом: чтобы данные по сотруднику отправлялись строго только сотруднику и никому другому. То есть, например, если полис ДМС Иванова по ошибке уйдет Петрову, то это уже нарушение. Но при этом есть нюанс, нужно сделать так, чтобы сотрудник своими персональными данными сам распоряжался как захочет, и мы его не должны ограничивать. И такой важный момент в этой задаче, которую мы решили, это, если данные отправляются не тому сотруднику, то такие письма, такую корпоративную коммуникацию нужно заблокировать. Т.е., что получается, если отдел кадров отправляет полис ДМС сотруднику, владельцу этого полиса, то это нормально. Если, например, потом сотрудник возьмет и перешлет этот полис ДМС себе на личную почту, т.е. распорядится своими персональными данными так, как он хочет, перешлет к себе на личную почту или отправит этот полис своей жене, это тоже не считается нарушением, потому что он этим распоряжается сам.

Как это было реализовано с помощью этой технологии? Была интеграция с DLP-системой. Оттуда вытягивались все данные по каждому сотруднику, данные, по которым можно идентифицировать этого сотрудника. И плюс вытягивался email, который был указан в карточке сотрудника. Как была реализована защита? Определялась конкретная порция персональных данных с помощью автоматической политики. И сравнивались фактический получатель этих персональных данных и тот email, который был проиндексирован из карточки сотрудников. И, если фактический email не совпадал с тем проиндексированным email из DLP-системы, то это считалось нарушением. Поддерживать эту политику руками никак не нужно. Она постоянно автоматически актуализируется по десять раз в день. Синхронизация происходила. Осуществлялась гранулированная защита персональных данных сотрудников. В этом кейсе мы решили элементарную задачу такую, как рассылка зарплатных листов. Потому что до этого DLP система два раза в месяц становилась красной, спровоцированная от рассылки зарплатных листов, потому что система считала, что это финансовая информация, утечка, и не могла определить, кто получает этот зарплатный листок, владелец или не владелец.

Вопрос. А если отправляется не на почту, а через мессенджер?

Ответ. Нужно определить, в нашей практике, если он отправляется на мессенджер, вряд ли такой существует длительный процесс. Вряд ли HR отправляет на мессенджер. В этом сценарии отправка всех перс-данных, как регламентированных только через корпоративную почту. Если мы, конечно, допускаем тот момент, что перс-данные у нас рассылаются, не пойми как, через все каналы, то, конечно, это DLP в данном случае будет как какая-то стена метр на метр в чистом поле. Поэтому речь идет о правильной организации каналов, надо прописать это в локальных правовых актах компании, что все перс-данные, все чувствительные информации по сотруднику отправляются только по данному корпоративному каналу.

Вопрос. Учитывать ли направление передачи сообщений, когда можно отсеять пересылку внутри организации?

Ответ. Но вот опять же, если HR по ошибке отправил к такому же сотруднику, то мы такую утечку не поймаем. Поэтому направление, к сожалению, не поможет решить такую задачу гранулированной защиты перс-данных.

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

Ответ. Если вы решили, что это регламентированный канал, то проблем нет. И не важно, какой канал. Технология отрабатывает на любом канале коммуникации. Разницы никакой нет. Если говорится про почту, то подразумевается, что технология отрабатывается на любом канале.

Вопрос. А если расчетные листы упакованы в архивы с паролем? Наименование архива обезличено просто «хрешбуком» цифр.

Ответ. Смотрите, если у вас так допускается, что можно пересылать парольную информацию внутри компании, то, конечно, никакой DLP вам не поможет. Если, например, у вас эти пароли для каждого сотрудника индивидуальные, то, возможно, такой проблемы у вас нет. То есть сотрудник знает, что этот пароль есть только у него, тогда, конечно, это будет актуально.

Вопрос. Вот Андрей спрашивает, как реализовать защиту, если сама страховая компания каждому делает рассылку ДМС?

Ответ. Тогда нужно попросить страховую компанию внедрить DLP. Если она индивидуально рассылает ДМС, то, конечно, потенциально страховая компания в данном случае точка отказа. Это решается так. Берем, индексируем также из RIP-данные клиентов и контролируем входящую почту. Если идет входящая почта, даже можно прописать от конкретного домена этой страховой компании, идет полис, и мы идентифицируем этот полис как определенный полис определенного сотрудника, и не совпадает фактически получатель сотрудника на входящей почте, то мы можем это письмо как-то, значит, купировать. То есть, да, можно решить задачу и не внедрением DLP в страховой компании, а в рамках вашей внутренней DLP.

Вопрос. В этом кейсе нужно заранее создать список легитимных email, чтобы он нормально работал?

Ответ. Да. Здесь расчет на то, что когда мы защищаем гранулированную защиту данных, конкретную порцию персональных данных, то, конечно, мы откуда-то должны взять этот легитимный email. Тут мы брали его из DLP-системы. Потому что не то что часто, а всегда в таких системах указывается контакт email сотрудника. Мы здесь немножко даже обречены на успех, потому что всегда такие данные в корпоративных системах хранятся.

Вопрос. Есть ли какие-либо инструменты, защищающие от фотографирования экрана? Ответ. Есть инструмент, который позволяет, якобы, увидеть, что сотрудник наводит камеру на телефоне на экран монитора, или наводит свой смартфон на экран. Но, как показала практика, это не очень эффективно. Он, к сожалению, не очень это умеет делать. А вот когда мы говорим про фотографирование экрана, особенно когда у нас нет никаких камер, то здесь стоит вопрос о том, что нужно защищать не утечки данных, а нужно контролировать, какие данные сотрудник, представляет на своем рабочем месте. Надеюсь, ответил на вопросы. Давайте теперь расскажу о деталях. Повторюсь, реализован кейс. В банке 20 тысяч сотрудников. Данные по сотруднику нельзя отправить никому другому, только ему самому. А сотрудник уже может распоряжаться этими данными, как хочет. Вот эта автоматическая политика проверяет, что, если отправитель этих персональных данных сам владелец персональных данных, то его уже не нужно никак ограничивать. То есть автоматическая политика реализует два автоматических правила: то, что получать персональных данных соответствует владельцу персональных данных и то, что отправитель персональных данных соответствует владельцу.

Теперь давайте уже больше деталей разберем.

Весь этот кейс решался с учетом блокировки, то есть никаких отложенных обработок. Перехватили письмо, поняли, что фактический получатель и владелец персональных данных не соответствуют друг другу, и тут же заблокировали. Все это делается очень быстро. Есть такой показатель, мы часто про него говорим, что проверка любого сообщения, даже мелкого, в мессенджерах, сравнение этого сообщения с десятимиллионной базой персональных данных занимает не больше одной десятой секунды. Каждое сообщение, каждое письмо мы можем проверить, нет ли там упоминания конкретных персональных данных из какой-то базы. Я повторюсь, потому что мы фиксируем эти данные из систем, где эти данные хранятся.

Иллюстрации предоставлены пресс-службой InfoWatch

Иллюстрации предоставлены пресс-службой InfoWatch

предоставлено пресс-службой InfoWatch