8 Апреля, 2019

DLP и рекомендации ФСТЭК по защите информации: пересекающиеся параллели

SolarSecurity
11 февраля 2014 года ФСТЭК России утвердила методический документ «Меры защиты информации в государственных информационных системах». Этот документ применяется для «выбора и реализации в отношении информации, не относящейся к гостайне и содержащейся в государственных информационных системах (ГИС), мер защиты, направленных на обеспечение конфиденциальности, целостности и доступности информации». Регулятор рекомендует применять данный документ для защиты информации как в ГИС, так и в негосударственных информационных системах, в том числе для обеспечения безопасности ПДн.

В документе указаны рекомендуемые меры защиты информации с отсылкой к определенным классам систем, например, таким как средства аутентификации, антивирусы, IDS/IPS и др. При этом регулятор напрямую не указывает на необходимость применения систем защиты конфиденциальных данных от утечек (DLP). Однако эти системы позволяют выполнить такие требования, как обеспечение конфиденциальности, целостности информации, передаваемой из информационной системы, регистрация событий безопасности и др.



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

Для начала скажем пару слов о назначении DLP-систем. Внедрение DLP преследует следующие базовые цели:

  • Предотвращение утечек конфиденциальной информации.
  • Сбор сведений об инцидентах и нарушениях для формирования доказательной базы в случае передачи дел в суд.
  • Ведение архива действий пользователей и ретроспективный анализ для выявления признаков мошенничества.

По многолетнему опыту можем сказать, что задач, которые заказчики решают с помощью DLP, множество, вплоть до самых узких и специфичных. Их мы оставим за рамками данного материала, здесь же рассмотрим фундаментальные.

Несмотря на то, что DLP-системы не относятся к обязательным для использования средствам защиты информации, продукты данного класса способны обеспечить необходимую функциональность для реализации ряда мер, рекомендуемых ФСТЭК в вышеупомянутом документе.

Обеспечение целостности


Начнем с основных рекомендаций по обеспечению целостности информационной системы и информации (ОЦЛ), приведенных в методическом документе ФСТЭК от 11 февраля 2014 года.
«ОЦЛ.5 — Контроль содержания информации, передаваемой из информационной системы (контейнерный, основанный на свойствах объекта доступа, и контентный, основанный на поиске запрещенной к передаче информации с использованием сигнатур, масок и иных методов), и исключение неправомерной передачи информации из информационной системы».
Какие меры регулятор предлагает применять для контроля содержания информации, и что из этого можно реализовать с помощью систем защиты от утечек?
Неправомерная передача защищаемой информации. Выявление фактов неправомерной передачи защищаемой информации из информационной системы через различные типы сетевых соединений, включая сети связи общего пользования и реагирование на них.
Данная процедура реализуется с помощью разделенного функционала по двум составляющим DLP в зависимости от используемых каналов связи:

  • Проверка информации, передаваемой по протоколам http/https, на предмет неправомерной передачи защищаемых данных может осуществляться с помощью инструментария систем класса веб-прокси.
  • Для анализа внутрисетевого трафика при отправке данных с прокси-сервера или маршрутизаторов можно отслеживать передачу файлов и сообщений по почтовым протоколам.
Неправомерная запись на съемные носители. Выявление фактов неправомерной записи защищаемой информации на неучтенные съемные машинные носители информации и реагирование на них.
DLP-агент, установленный на рабочей станции, помимо контроля действий пользователя, анализирует содержимое файлов и может блокировать попытки пользователя скопировать на USB или отправить на печать конфиденциальные документы. Факт подключения USB-накопителя фиксируется на агенте, по результатам специалист по информационной безопасности может изменить политику DLP-системы, включив данный накопитель в «черные» или «белые» списки.
Контроль хранения защищаемой информации на серверах и автоматизированных рабочих местах.
Выявление фактов хранения конфиденциальной информации на общих сетевых ресурсах (общие папки, системы документооборота, базы данных, почтовые архивы и иные ресурсы).


Обозначенные меры можно реализовать с помощью функциональности сканирования файловых хранилищ, которая с разной степенью проработанности реализована во всех продвинутых DLP-системах. Эта функциональность позволяет проводить инвентаризацию содержимого как на файловых/облачных хранилищах и локальных жестких дисках, так и на почтовых архивах.

Сканирование файловых хранилищ выявляет конфиденциальные данные и нарушения правил их хранения с помощью следующих механизмов (список может варьироваться в зависимости от системы):

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

Дополнительно в требованиях к усилению данной меры приводится блокировка передачи из ИС информации с недопустимым содержанием. Практически все DLP-системы позволяют выполнять данные требования по различным каналам связи – от почтовых сообщений до копирования на USB-носитель.

Регистрация событий безопасности


Вторым важным блоком рекомендаций ФСТЭК по защите информации является регистрация событий безопасности — РСБ. Конечно же, прежде чем приступать к выполнению данных мер, в организации должны быть категорированы все информационные активы (ресурсы). После этого становится возможным выполнение следующих мер:
Определение состава и содержания информации о событиях безопасности, подлежащих регистрации.
Сбор, запись и хранение информации о событиях безопасности в течение основного времени хранения.
Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них.


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

Благодаря сохранению всех событий в базе данных DLP-системы, при обновлении политик можно провести ретроспективный анализ и расследование.

Защита ИС, ее средств и систем связи и передачи данных


Вернемся к базовым целям, стоящим перед DLP-системами. По зрелому размышлению становится очевидным, что для их достижения важна не только возможность сбора и консолидации различного рода логов, но и защита накапливаемых данных при их передаче/обработке и хранении. Собственно, речь идет о том самом понятии неотрекаемости при создании, отправке и получении информации, о которой мы подробно рассказывали в предыдущей статье. Подойти к выполнению этой меры можно с разных сторон. Реализации некоторых DLP-систем подразумевают использование для обеспечения «неотрекаемости» лишь дополнительных коммерческих СЗИ и СКЗИ. Другие же позволяют применять и стандартные возможности операционной системы. Рассмотрим, на что можно опереться, например, в ОС CentOS и БД PostgreSQL:

  • Шифрование тома по секторам, встроенным в ядро ОС «DM_Crypt».
  • Шифрование БД – модуль «pgcrypto» (шифрование таблиц и строчек самой БД, что позволяет в том числе выстроить защиту и от привилегированных пользователей, включая ИТ-персонал).
  • Создание защищенного соединения в кластере между БД «pg_hba.conf».
  • Защита клиент-серверного соединения – фактически необходимо TLS 1.2 и выше.

Несмотря на то, что ФСТЭК не регламентирует использование криптографических средств защиты, дополнительно видится целесообразным применение шифрования для Защиты информационной системы, ее средств и систем связи и передачи данных (ЗИС) с тем, чтобы сама DLP-система в руках грамотного ИТ-персонала не стала объектом утечки закрытой информации. Так как вышеперечисленные средства являются компонентами ОС и сопутствующего ПО, рассмотренный пример носит частный характер. Однако в любом случае при необходимости всегда можно найти opensource/бесплатную альтернативу существующим коммерческим средствам криптографической защиты информации. Но здесь сразу же встает вопрос о сертификации данных решений, а это уже тема для отдельной беседы.

В нашем следующем материале мы расскажем о применимости ключевых DLP-систем по составляющим модулям к рекомендациям американского стандарта NIST US.