Интеграция систем защиты от утечек конфиденциальной информации (Data Leak Prevention, DLP) и ряда ИБ-решений может оказаться очень полезной для информационной безопасности компании, упростить рутину и дать новые возможности. Какие варианты интеграции видятся специалистам особенно перспективными?
- Введение
- Родом из прошлого
- Чтобы что?
- Как работает DLP-система
- 4.1. OCR
- 4.2. Информационные объекты
- 4.3. Цифровые отпечатки
- Родом из будущего
- 5.1. Интеграции внешнего управления
- 5.2. Интеграции взаимодействия
- 5.2.1. Когда DLP — ведущий
- 5.2.1.1. Источники данных о сотрудниках
- 5.2.1.2. Внешние сервисы
- 5.2.1.3. Управление внешними сервисами
- 5.2.1.4. Средства информирования администраторов
- 5.2.2. Когда DLP — ведомый
- 5.2.2.1. СКУД
- 5.2.2.2. Системы документооборота
- 5.2.2.3. Mobile Device Management
- 5.2.1. Когда DLP — ведущий
- 5.1. Интеграции внешнего управления
- Выводы
Введение
Системы защиты от утечек (DLP) — зрелые и давно зарекомендовавшие себя на рынке решения. Они используются многими компаниями как самодостаточные системы, однако всё чаще появляются запросы на их интеграцию с другими классами решений.
Действительно, DLP может интегрироваться со внешними системами, получая или отдавая им информацию, для того чтобы обеспечить новые варианты защиты. Например, поддержать проверки сообщений искусственным интеллектом, который сможет распознать сарказм, язвительность и хамство — и DLP-система не пропустит такое письмо контрагенту. Также возможна интеграция внешнего управления: она позволяет избавиться от лишней работы по ведению процесса в двух системах, одна из которых — DLP, и ручной синхронизации их настроек и состояний. Например, можно настроить автоматическое внесение реквизитов и значимых параметров нового договора в политику DLP при его появлении в системе документооборота.
Поговорим о том, с какими системами, зачем и как может интегрироваться DLP в настоящем и будущем.
Родом из прошлого
Наверное, всю историю человечества (или хотя бы начиная с появления древних государств) люди стремились ограничить распространение информации. Пока информация передавалась устно, достаточно было следить за собственной речью — и если никто из посвящённых не проговаривался, информация была относительно надёжно защищена. Хотя, конечно, это не слишком защищало её ото всяких злонамеренных действий вроде пыток взятых разведчиками языков.
С появлением письменности возникла новая проблема: папирус, пергамент, глиняная табличка, цера, береста, бумага с критически важной информацией могут попасть к злоумышленнику, а то и к противнику. Зачастую вопрос решался с помощью кодирования информации, шифрования или стеганографии (незаметной передачи ценной информации внутри неценной). Например, можно было, как Цезарь, использовать шифры перестановки или, как Гистией, побрить голову гонцу, нанести на освободившееся пространство несрочное сообщение, дать отрасти шевелюре и отправить гонца по назначению. Авось перехвативший гонца не догадается о таком варианте.
Были и эксперименты с текстом, когда в связном безобидном тексте адресат берёт только отдельные слова в качестве скрытого сообщения (например, только последнее слово из каждого предложения — этот метод упоминался, скажем, у Н. П. Трублаини в повести «Шхуна “Колумб”»).
Ещё можно было сначала написать сообщение на цере и только потом покрыть её воском, как Демарат. А поверх воска написать новый текст, не содержащий ничего подозрительного. Или, как Ленин, писать на бумаге молоком (как вариант, лимонным соком). В общем, вариантов было множество.
Помимо защиты документов при передаче их нужно было хранить. Для этого создавались таблинумы и библиотеки.
Шли годы. Вокруг первичных документов создавались документы вторичные — карточки на допущенных к сведениям, журналы учёта карточек, предписания на выполнения задания и прочее. Но проблема оставалась: человек, допущенный к сведениям, мог сделать копию. И решалась она в основном организационно: преследованием за раскрывшееся преступление и снижением технических возможностей эту самую копию снять. Но всё равно Джоны Ланкастеры Пеки продолжали «щёлкать носом».
И тут грянула цифра!
Цифровизация привела к тому, что получение копии документа упростилось и ускорилось кардинально. Появились и новые варианты утечки информации, что привело к возникновению нового класса средств защиты — DLP.
Их история началась порядка 20 лет назад, и за эти годы они нашли спрос у бизнеса и госорганов, весьма заметно развились, и теперь требования по защите от утечек включены в нормативную документацию регуляторов.
Куда дальше будут развиваться DLP? Этот вопрос не имеет достоверного ответа, можно только строить предположения. У меня есть свои мысли на этот счёт, но сначала — немного о том, зачем нужно интегрировать DLP с другими системами.
Чтобы что?
Зачем защищать информацию, в целом понятно. В случае с DLP это позволяет сократить убытки (прямые или потенциальные) от утечек информации. А вот зачем увязывать DLP с другими системами...
Да с теми же целями, в общем-то. Например, чтобы автоматизировать ряд процессов обнаружения утечек и реагирования на них, а значит, не раздувать штат сотрудников службы ИБ: с интегрированными в единую экосистему ИБ-решениями уже имеющиеся сотрудники начинают успевать больше и снижается вероятность ошибок. Или чтобы снизить риски, например уменьшая количество ложноотрицательных результатов анализа. Либо чтобы быстрее принимать меры реагирования на атаки, когда DLP передаёт данные во внешние системы, где создаётся инцидент и о нём оповещаются все заинтересованные лица. В общем, тут есть много вариантов.
Далее я расскажу, зачем нужны различные виды интеграций.
Как работает DLP-система
DLP-система всегда имеет несколько источников данных, которые направляют в неё поток сообщений. Например, почтовый сервер организации передаёт в DLP поток писем сотрудников. Также это может быть анализатор трафика, который, скажем, следит за трафиком рабочей станции, вычленяет из него фактические сообщения (например, передаваемый по FTP файл) и отдаёт его на анализ.
Это может быть и какая-то другая внешняя система, которая хочет узнать, является ли попавшееся ей сообщение / файл подозрительным, и направляет его на анализ. Система получает от DLP ответ, по результатам которого может пропустить сообщение / файл, заменить его или просто заблокировать. Внутри анализируемого сообщения могут быть как собственно текст, так и разнообразные вложения.
DLP должна уметь находить подозрительные с точки зрения утечек конфиденциальной информации объекты и сигнализировать об этом специально обученным людям (а также, возможно, реагировать как-то иначе и оповещать другие системы). Что является допустимым, а что — нет, определяется настраиваемой в DLP-системе политикой.
Но помимо работы с текстом — поиска заданных слов с учётом всех словоформ (скажем, если слово «карта» является потенциально опасным, надо реагировать также и на формы этого слова: «картой», «карты», «карте» и т. д.) — DLP оперирует и другими объектами.
OCR
Среди сообщений / вложений могут встречаться изображения. Текстовый поиск по файлу, конечно, возможен, но почти бессмысленен: надпись в картинке настолько нетривиально отображается в самом файле, что простой текстовый поиск ничего не обнаружит. И тут задействуются механизмы OCR — оптического распознавания символов. Итак, OCR может быть первой интеграцией со внешней системой. Такие интеграции давно реализованы в имеющихся на рынке DLP-системах.
Информационные объекты
Помимо собственно слов имеет смысл детектировать и определённым образом структурированные данные. Цифры в структурах наподобие +7 (123) 456-78-90 выглядят как телефонный номер, цифры 43 21 123456 — как номер паспорта. В случае с номером 123-456-789-64 или 12345678964 есть вероятность, что это СНИЛС. А вот 12345678965, скажем, под критерии СНИЛС не подходит — контрольное число (у СНИЛС — две последние цифры) данному формату не соответствует. Помимо СНИЛС аналогичные контрольные числа используются в ИНН и номерах банковских карт, VIN и номерах счетов, ISBN, ISIN и других форматах.
Такие распознанные информационные объекты позволяют, в первую очередь, защищать конфиденциальные данные, представленные в виде наборов цифр и букв.
Цифровые отпечатки
Другой вариант — создать некоторый образ документов, например типовых договоров компании, и сравнивать с ним сообщения, а также вложения в них. И если анализируемый документ очень похож на один из образов, то это повод оповестить офицера безопасности. А то и инцидент завести!
Родом из будущего
В целом, возможные интеграции можно разделить на два основных направления: интеграции внешнего управления (где внешняя система перенастраивает DLP) и интеграции взаимодействия (когда DLP и внешняя система взаимодействуют в контексте обработки конкретного сообщения).
Разумеется, при проработке интеграционных решений необходимо обращать особое внимание на вопросы безопасности и надёжной аутентификации внешней системы.
Интеграции внешнего управления
Эти интеграции реализуют управление и перенастройку DLP-системы внешними системами.
Рисунок 1. Схема интеграции внешнего управления
Управление правами пользователей
Пользователи DLP обычно имеют разные роли в системе с разными возможностями. Как правило, сопоставление конкретных пользователей DLP и их ролей производится внутри самой системы. Однако также существуют системы класса IdM (Identity Мanagement), IAM (Identity and Access Management) и IGA (Identity Governance & Administration), которые предназначены для управления правами в других системах.
Поэтому вполне разумной видится интеграция DLP-системы с IdM / IAM / IGA: это позволит уменьшить риски неверного назначения или изменения прав в DLP и связывать эти изменения в правах с их основаниями (приёмом сотрудников, переводами и т. п.).
Такая интеграция неинтересна небольшим компаниям, поскольку они обычно не используют IdM / IAM / IGA, однако в крупном бизнесе подобная интеграция будет востребована. Уже сейчас на ИТ-рынке идут обсуждения целесообразности интеграции защиты от утечек с управлением доступом, и скорее всего в ближайшее время мы увидим её массовую реализацию.
Интеграция с SOAR
SOAR (Security Orchestration, Automation and Response) — это класс систем, которые управляют комплексом средств защиты информации. Они собирают сведения о происходящих событиях по информационной безопасности из разных подчинённых систем и вырабатывают реакции.
Например, в случае обнаружения заражённой флешки на одной из рабочих станций SOAR может инициировать изменения в DLP: скажем, поместить пользователей заражённой машины в группу особого контроля, к которой приковано более пристальное, чем к остальным сотрудникам, внимание. Заявления о таких интеграциях уже звучат, эта функциональность выглядит вполне перспективной. Полагаю, вскоре такой возможностью обзаведутся многие.
Модификация политики, списков слов, настроек
В DLP-системах используется множество настроек, касающихся действий системы, списков слов, правил и т. п. Обычно подобные настройки осуществляются вручную. Но у крупных компаний возникают потребности автоматизировать и эти действия: скажем, вносить в списки слов номера договоров или изменять настройки подключения к Active Directory. Часто удобно делать такие правки изо внешней системы, а заодно и автоматически добавлять в DLP расширенную информацию о причинах перенастройки. Эта возможность выглядит близкой к реализации для многих вендоров.
Интеграции взаимодействия
Эти интеграции ориентированы непосредственно на обработку сообщений DLP и внешней системой, а также на получение данных, необходимых для этого. Возможны два основных варианта такого рода интеграций: инициируемые со стороны DLP (DLP — ведущий) и инициируемые внешней системой (когда DLP — ведомый).
Когда DLP — ведущий
Эти интеграции предполагают получение DLP-решением из других систем информации, полезной в деле обработки сообщений, а также уведомление внешних систем о событиях внутри DLP.
Рисунок 2. Схема интеграции «DLP — ведущий»
Для уведомления внешних систем о событиях по безопасности во многих DLP-решениях используются системные журналы. Эти журналы могут быть настроены на работу через Syslog с последующим перенаправлением событий, например, на SIEM, SOAR или какие-то иные внешние системы. А вот для получения DLP-системой информации из других источников существует много разных вариантов.
Источники данных о сотрудниках
DLP-система нуждается в информации о людях: кто из участников переписки является сотрудником, кто — нет, кто из сотрудников в каком подразделении работает. Понятное дело, что если активную переписку со внешними по отношению к компании людьми ведёт сотрудник отдела закупок, то это — его штатная работа. Если договор отправлен сотрудником отдела продаж — тоже обычное дело. А вот если много писем с договорами исходит от кладовщика, то это как минимум необычно.
Наиболее очевидными источниками информации о сотрудниках компании являются системы кадрового учёта. Но в перспективе для этого могут использоваться и различные репутационные сервисы.
Что касается систем кадрового учёта, то на текущий момент во многих решениях реализовано взаимодействие DLP с LDAP-источниками, например с Active Directory. Однако бывает, что эталонную информацию содержат другие системы, например уже упоминавшиеся ранее IdM / IAM / IGA или даже самописные системы кадрового учёта. Взаимодействие с ними активно осваивается многими российскими DLP-решениями.
А вот с репутационными сервисами всё намного интереснее и экзотичнее. Теоретически данные о персонах могут также обогащаться дополнительными сведениями, например может учитываться репутация пользователя: показатель добропорядочности, учитываемый в некой внешней по отношению к DLP системе.
Сейчас в связи с этим активно обсуждается Китай со своей системой рейтингов, но есть подозрения, что и другие страны, а также корпорации в будущем придут к тому же, отслеживая законопослушность, социальный статус, экономическое положение граждан и тому подобное. Насколько быстро это произойдёт, сказать сложно. Вряд ли через год мы будем жить в таком мире, но нашим детям он вполне может достаться.
Внешние сервисы
Внешние сервисы позволяют DLP-системе получать дополнительную информацию о сообщении (или о его частях) или обрабатывать его.
1. Перед началом обработки сообщения (и / или его вложений) может проводиться его проверка во внешнем антивирусном сервисе. Получив результат, DLP может перейти непосредственно к анализу сообщения или отклонить его как небезопасное. Это есть в большинстве DLP-решений.
2. При отправке документов вовне зачастую теряется возможность контролировать дальнейшее их распространение. В этом деле DLP-системе может помочь интеграция с системой класса DRM (Digital Rights Management).
DRM-системы модифицируют файл: зашифровывают его, оставляя информацию о том, к какому сервису можно обратиться за ключом, позволяющим его расшифровать и отобразить пользователю. Пользователь, желающий просмотреть содержимое файла, запускает ПО, умеющее работать с такими файлами. ПО узнаёт из файла, куда идти за ключом, и обращается туда, передавая информацию о пользователе. Сервер DRM проверяет, можно ли пользователю работать с файлом, и при положительном вердикте пересылает ключ в адрес ПО. ПО расшифровывает файл полученным ключом и отображает его пользователю.
При обнаружении отправки файла дополнительно может учитываться, кто именно отправляет его, в рабочий день это происходит или в выходной, каково время отправки, что содержится в сообщении и тому подобное. В этот момент DLP-система может инициировать обращение к DRM за услугой по защите файла. Тогда в сообщении файл будет заменён на защищённый.
Если получатель не является доверенным и в DRM для него не разрешён доступ к содержимому файла, он получит фактически бесполезный объект, и пересылка файла дальше также становится бесполезной.
Отдельные DLP-системы поддерживают такой режим работы, думаю, вскоре и остальные подтянутся.
3. В переписке иногда могут использоваться зашифрованные сообщения — перед их анализом DLP-системой необходима расшифровка. Внешняя криптографическая система может осуществлять попытку расшифровать сообщение (например, с использованием брутфорса, каталога словарных паролей, радужных таблиц, копий ключей и т. п.) и передавать результат на анализ в DLP.
Также, поскольку агенты DLP-системы, установленные на рабочих станциях, могут собирать вводимые пользователем пароли, возможна передача последних из DLP-решения в словарь паролей, который будет таким образом пополняться.
Пока мне не удалось найти в публичном поле сведений о таких интеграциях, однако выглядит это вполне реализуемо — вероятно появление такого взаимодействия в ближайшие годы.
4. Весьма перспективной выглядит интеграция DLP с инструментами анализа тональности сообщений. Система, способная определять тональность переписки (например, фиксировать признаки гнева или сарказма), может получать от DLP тексты и выдавать свои оценки. Далее эта информация может учитываться в логике обработки сообщения в DLP: например, для постановки на особый контроль переписки невоздержанного сотрудника или направления потенциально эмоционального письма на дополнительный ручной контроль.
Примеры таких интеграций мне неизвестны, но вполне возможно скорое их появление.
5. DLP-системы при обработке сообщений исходят из жёстко заданной логики. При этом некоторые признаки конфиденциальной информации может быть затруднительно описать в условиях и правилах системы. Поэтому для более глубокого разбора сообщений могут применяться и другие внешние инструменты. Это могут быть системы, содержащие сведения не подлежащие внесению в DLP-решение — например, предназначенные только для топ-менеджеров. Или, скажем, искусственный интеллект, который позволяет производить глубокий семантический анализ информации. Результат разбора внешней системой может учитываться DLP и участвовать в судьбе сообщения. Вполне ожидаемо в ближайшее время.
6. Одним из вариантов скрытой передачи информации в сообщениях является стеганография. DLP-системы не ориентированы на такой вариант передачи данных, их задача — хорошо анализировать открытую информацию. Поэтому в случае необходимости поиска скрытых данных в сообщениях придется использовать внешний стеганодетектор.
На текущий момент мне неизвестны коммерческие стеганодетекторы, но в случае их выхода на рынок интеграция выглядит вполне актуальной.
7. В составе сообщений могут пересылаться и исполняемые файлы с различной функциональностью. Это создаёт серьёзный риск того, что извне в периметр компании (или, наоборот, изнутри компании к заказчику) может попасть ПО с ошибками или вредоносными функциями. Как один из вариантов защиты от таких рисков возможна интеграция DLP с песочницей, в которой может осуществляться проверка совместимости файла с некоторой инфраструктурой. В случае если по результатам испытаний файл будет сочтён безопасным, он может быть передан в дальнейшую обработку, в противном случае — заблокирован.
Такая интеграция выглядит потенциально реализуемой хоть сейчас, но пока я о подобном не слышал. Возможно, потому, что ещё не появился спрос.
8. Весьма возможной выглядит утечка информации через акустический / видеоканал, например через сервисы видеоконференций, голосовые сообщения в мессенджерах и проч. Для анализа аудиопотока на предмет утечки конфиденциальной информации могут использоваться технологии «speech-to-text», а для анализа видеоизображений — «video-to-text».
Теоретически также может возникнуть потребность в анализе специфических форматов коммуникации, например передачи информации с помощью азбуки Морзе или сурдоперевода. Конечно, сурдораспознавание или «морзянка» пока выглядят экзотично и вряд ли на них существует платёжеспособный спрос. А вот анализ речевой информации и распознавание текстов в видео — вполне полезная уже сейчас возможность.
Анализ речи может быть реализован уже в ближайшем будущем, видео — с развитием систем распознавания такой информации.
Управление внешними сервисами
При обнаружении нарушений политики безопасности DLP-система может служить инициатором изменений в других системах. Рассмотрим на примерах.
1. Факт пересылки определённых документов может быть основанием для изменения прав доступа пользователя к сетевым ресурсам и / или изменения его прав в информационных системах.
В этом случае срабатывание правила обработки сообщения должно вызывать уведомление межсетевого экрана и / или IdM- / IAM- / IGA-системы, которые могут запустить блокировку какого-либо из доступов пользователя. Такая реализация — не за горами.
2. При обнаружении срабатывания правил обработки сообщений DLP может оповещать систему обнаружения и предотвращения вторжений, IDS / IPS (Intrusion Detection / Prevention System). В этом случае может приниматься решение о перенастройке отслеживаемых IDS / IPS протоколов или их блокирование.
Например, DLP-система может уведомлять IPS, что на определённой рабочей станции обнаружена утечка через протокол FTP. И хотя в целом само использование протокола не является криминальным на этой рабочей станции, уведомление об инциденте может использоваться IPS как основание для блокировки трафика этой станции.
Техническая возможность такой интеграции есть, но мне не доводилось слышать такие истории. Вероятно, на это пока нет спроса.
Средства информирования администраторов
Эта группа интеграций служит для информирования администраторов DLP о критических событиях, таких как обнаружение сбоев или проблем производительности инфраструктуры и / или компонентов DLP, обнаружение критически важных утечек, информирование о переконфигурации и т. п. Такое оповещение может передаваться по различным каналам: электронной почте, мессенджерам, SMS, телефонии. Классический вариант оповещения — через почту — существует во всех DLP-решениях, другие способы не выглядят особо востребованными. Часть из них может реализовываться с использованием почты как промежуточного средства.
Когда DLP — ведомый
Этот тип взаимодействия предполагает оповещение DLP о событиях, которые происходят во внешних системах и могут учитываться системой защиты от утечек при обработке сообщений.
Рисунок 3. Схема интеграции «DLP — ведомый»
СКУД
Система контроля и управления доступом может оповещать DLP о прибытии конкретного лица на рабочее место и уходе с него. Для организаций, в которых не предусмотрен режим удалённой работы, рассылка сообщений от имени пользователя, если СКУД не зарегистрировал его приход на работу, должна инициировать в DLP более критически значимые инциденты, чем когда пользователь находится на рабочем месте. Подключение такого источника данных потенциально возможно в ближайшем будущем, если будет спрос.
Системы документооборота
Системы документооборота могут передавать в DLP новые образцы документов, схожие с которыми надо контролировать. Также система документооборота может запрашивать обработку документа или набора документов системой защиты от утечек для определения, можно ли передавать документ от отправителя получателю и не требуются ли дополнительные визы (например, руководителя отправителя и ответственного за информационную безопасность). Такая интеграция видится реализуемой в краткосрочной перспективе.
Mobile Device Management
Средства контроля мобильных устройств (MDM) могут обнаруживать на устройстве конфиденциальную информацию — переписку, документы, сохранённые изображения — и через контрольный центр направлять их на проверку в DLP-систему. Доступные на мобильном устройстве действия с ними могут зависеть от результатов проверки. Пока таких интеграций обнаружить не удалось, но они вполне могут появиться в ближайшем будущем.
Выводы
Выше я набросал мысли о том, в каких направлениях, возможно, будут расти DLP-системы — с какими классами решений смогут интегрироваться в будущем. Важно отметить: ключевым на российском рынке информационной безопасности сегодня является движение DLP и других ИБ-решений к экосистемности, взаимной интеграции в единую платформу безопасности компании. В идеале заказчик должен иметь возможность без проблем выстроить свою систему безопасности из любого набора решений разных вендоров. Возможно, не везде ростки интеграции дадут всходы, где-то они не смогут укорениться. А что-то, может, и выстрелит. Что именно? Трудно сказать, однако я верю в некоторые из вышеописанных направлений. Время покажет.
