Light mode

Эволюция защиты в PT Data Security: от регулярных выражений к ML

  • #PTDataSecurity
  • #ML

О чем материал

Рассказываем о применении ML-моделей для поиска и классификации чувствительных данных в PT Data Security.

В прошлом году мы представили MVP платформы для защиты данных PT Data Security. На тот момент наш продукт использовал для поиска и классификации чувствительных данных регулярные выражения и формальную экспертизу. Это стандарт индустрии, который применяется в IBM Guardium, Oracle Data Safe и других решениях. Тем не менее у этого подхода есть недостатки: качество обнаружения данных напрямую зависит от культуры их хранения. Например, проблемы могут вызвать неинформативные названия колонок (col1, value, field123), шумы или пропуски, сокращенные записи, опечатки и т. д. Чтобы усилить экспертизу продукта: увеличить число определяемых сущностей (классов данных) и сократить количество ложных срабатываний, — мы решили внедрить в PT Data Security алгоритмы ML.

На текущей стадии развития продукта мы сфокусировались на работе с текстовыми данными (это самый распространенный тип информации) и выделили два формата их представления:

  • структурированные данные — организованные в виде таблиц;
  • неструктурированные данные — документы, переписки, логи, отчеты и др.

В рамках программы «Ранние ПТашки» мы изучили, как российские компании на самом деле хранят и используют информацию. Анализ показал, что структурированные данные — это не всегда реляционные БД. В некоторых случаях это могут быть полуструктурированные файлы .xlsx или .csv. Кроме того, в инфраструктурах часто встречаются атомарные БД, развернутые для решения конкретных задач: одни обслуживают самописные приложения заказчиков, другие — CRM-системы отделов, связанных с бухгалтерией, и т. д. Причем каждая из баз может состоять из десятков и даже сотен таблиц. Все это нужно учитывать при реализации механизмов классификации данных.

Рисунок 1. Распределение типов текстовых данных в хранилищах

По итогам исследования мы сформулировали онтологию текстовых данных, в рамках которой PT Data Security должен в первую очередь покрывать два класса информации:

  • персональные данные (ПДн) — любая информация, связанная с определенным или определяемым физическим лицом;
  • информация об ИТ-ресурсах (IT Info) — данные об информационных системах, их конфигурациях, учетных записях и доступах к ним.

Почему регулярных выражений недостаточно?

Для начала мы проверили реальную эффективность регулярных выражений в части выявления чувствительной информации. Для тестов использовали ПДн: составили список сущностей (см. табл. 1) и подготовили отложенный набор размеченных данных с текстами на русском и английском языке. Итоговый датасет насчитывал свыше 3000 колонок (более 300 тыс. ячеек в совокупности).

СущностиОписаниеПримеры
1PERSONЛюбая информация, позволяющая прямо или косвенно идентифицировать конкретного человека по имени или ФИОИван Иванов
2DATEЛюбые даты в различных форматах (день/месяц/год, месяц/день/год и т. п.), включающие календарные даты, даты рождения, даты транзакций и пр.

12.05.2021

2021-05-12

3PHONE_NUMBERНомера телефонов в национальном или международном форматах, включая коды стран и городов, с добавочным номером или без него

+7 (495) 123-45-67

8 800 555-35-35

4EMAILЭлектронные адреса в стандартном формате имени пользователя и домена (user@domain)info@ptsecurity.com
5ORGANIZATIONНазвания компаний, учреждений и организаций (государственных или коммерческих)АО Позитив Текнолоджиз
6IBANМеждународный номер банковского счетаDE89370400440532013000
7LICENSE_PLATEРегистрационные номера транспортных средств

А123ВС 77

B202XT 98

Таблица 1. Список сущностей

Мы просканировали датасет тремя сторонними продуктами (коммерческими и open source): все они используют для поиска и классификации данных регулярные выражения и формальную экспертизу. При этом в каждом из этих решений применяется один или сразу два вида классификации: по содержимому и метаданным (наименования колонок).

Рисунок 2. Результаты сканирования: система 1
Рисунок 3. Результаты сканирования: система 2
Рисунок 4. Результаты сканирования: система 3
  • PII — тип персональной информации (сущности из табл. 1)
  • TP — True Positive (верно распознанные сущности) 
  • FN — False Negative (пропущенные сущности)
  • FP — False Positive (ошибочно найденные сущности)

В рамках исследования мы отслеживали два показателя:

  • recall (полнота) — сколько чувствительных данных обнаруживает система;
  • precision (точность) — как редко система принимает безопасные данные за чувствительные и выдает ложные срабатывания.

При расчете метрик мы использовали макроусреднение (macro). Оно позволяет равномерно учитывать вклад каждого класса в общий результат и избежать смещения в сторону доминирующего класса. Результаты тестов представлены в табл. 2.

 macro-precisionmacro-recallmacro-f1
Система 10,48270,44160,4110
Система 20,99470,15040,2470
Система 30,56600,36320,4042
Таблица 2. Результаты исследования

Тесты показывают, что регулярные выражения успешно справляются только с сущностями EMAIL и IBAN, с остальными все не так гладко. С чем это связано:

  • Ограниченная применимость шаблонов. Регулярные выражения не могут охватить все возможные вариации данных, особенно если речь идет о свободно записываемых сущностях (например, ФИО, названии организаций и пр.).
  • Высокий риск ложных срабатываний. Случайные числовые последовательности могут быть ошибочно интерпретированы как номера телефонов (как у системы 1).
  • Нестабильность в обработке редких и нестандартных форматов данных.

Резюмируем: регулярные выражения хороши для сущностей с четкими паттернами и низкой вариативностью. Любое отклонение от заранее заданного формата (например, пробелы в номере карты или необычное написание даты) приводит к пропуску данных.

Эксперименты с ML

Начнем с основных подходов, которые можно использовать при реализации ML-моделей для поиска и классификации ПДн.

Рисунок 5. Схема возможных способов интеграции машинного обучения в PT Data Security

CASSED

Для успешного обнаружения чувствительной информации в табличных данных важно не только корректно интерпретировать отдельные значения полей, но и учитывать контекст соседних ячеек (см. рис. 5). По сути, главная идея CASSED заключается в формировании контекста столбца: метаданные и значения ячеек объединяются в один вход для модели BERT (см. рис. 6). Это позволяет одновременно анализировать несколько ячеек одной колонки и присваивать ей одну или несколько сущностей. Таким образом, классификация становится более точной: помимо отдельных значений, мы учитываем их взаимосвязи и общую структуру данных.

Рисунок 6. Формирование контекста колонки таблицы в классификации CASSED

Named Entity Recognition (NER)

Распознавание именованных сущностей — классическая задача в области естественного языка. Суть в том, чтобы находить и классифицировать отдельные фрагменты любых текстов. Проще говоря, метод NER можно применять и к структурированным, и к неструктурированным данным (см. рис. 5).

Сравнение ML-моделей

Мы сравнили эффективность CASSED- и NER-моделей на отложенном наборе данных, на котором ранее тестировали регулярные выражения (см. рис. 7–8). Отметим, что мы исключили из экспериментов сущности, которые успешно обрабатываются регулярными выражениями, и сосредоточились на оставшихся: `PERSON`, `PHONE_NUMBER`, `ORGANIZATION`, `DATE` и `LICENSE_PLATE`.

Рисунок 7. Результаты классификации: CASSED
Рисунок 8. Результаты классификации: NER
ML/Metricsmacro-precisionmacro-recallmacro-f1
CASSED0,74610,75690,7499
NER0,90170,96250,9293
Таблица 3. Результаты теста

Несмотря на то, что CASSED специально проектировался для определения чувствительных данных в БД, более универсальный NER отработал лучше. Кроме того, CASSED показал слабые результаты с данными на русском языке, что критично для PT Data Security и отечественного рынка в целом.

  • CASSED подходит только для структурированных данных и не учитывает отдельные разнородные записи внутри одной таблицы. Среди плюсов метода можно отметить более высокую производительность, чем у NER.
  • NER универсален, хорошо работает на русском и английском и требует меньше данных для обучения модели. Кроме того, метод позволяет выделять участки текста, содержащие чувствительную информацию (это можно использовать для внедрения в продукт функционала анонимизации).

Мы провели отдельные тесты, чтобы узнать, как CASSED и NER отрабатывают на неструктурированных столбцах (например, в датасете были сложные примеры json’ов). В итоге NER-модель показала уникальные детекты, а CASSED не обнаружил ни одного класса в тестовой подвыборке такого формата.

По итогам исследования мы решили внедрять в PT Data Security ML-модели на базе NER! Тем не менее исключать регулярные выражения из экспертизы продукта мы не планируем: они все еще остаются важной частью PT Data Security. Продукт использует оба подхода для достижения высокой точности классификации.

***

Напоследок обозначим ключевые векторы развития PT Data Security в части ML:

  1. Улучшение механизмов доставки экспертизы. Мы обнаружили, что анализ только первых или последних N записей столбца — не самый эффективный подход. Можно добиться большей точности, если модифицировать семплирование получаемых данных.
  2. Продолжение экспериментов с ПДн и расширение количества сущностей для данных IT Info.
  3. Разработка модуля для определения общего класса документа (финансовые, медицинские, юридические документы и др.) вместо обнаружения отдельных сущностей.

Мы дěлаем Positive Research → для ИБ-экспертов, бизнеса и всех, кто интересуется ✽ {кибербезопасностью}