Как выбрать DCAP-систему для своей организации

Рассмотрим ключевые аспекты выбора DCAP-системы (Data-Centric Audit and Protection, управление доступом к неструктурированным данным), включая нюансы бюджетирования, архитектуры, технологий и технического исполнения.

1. Введение
2. Краткий обзор российского рынка DCAP
3. Архитектура
4. Возможности продуктов
   
   1. 4.1. Источники данных
   2. 4.2. Технологии анализа
   3. 4.3. Варианты реагирования
   4. 4.4. Отчёты и аналитика
5. Другие критерии и факторы
   
   1. 5.1. Бюджет
   2. 5.2. Интеграция с другими элементами корпоративной ИБ
6. Выводы

Введение

Мы приведём здесь краткий обзор рынка и возможностей DCAP-систем, которые могут быть важными или, наоборот, избыточными для потребителя. Здесь отсутствуют рекомендации по использованию конкретных продуктов и вендоров, но имеется их перечень для облегчения задачи первичного поиска, а также приведены конкретные факторы, которые позволят сделать взвешенный выбор в пользу того или иного решения.

Краткий обзор российского рынка DCAP

Рынок DCAP в России, хотя он и существует уже несколько лет, трудно назвать зрелым. За последние пару лет он ещё раз кардинально изменился. В отличие от близкого рынка DLP, откуда иностранные игроки были фактически вытеснены уже к 2014 году, среди DCAP-вендоров к началу 2022 года на ведущих ролях были именно иностранные игроки. Крепкие позиции имели Netwrix и вероятный лидер Varonis.

Дальнейший рост рынка прогнозируемо привлёк внимание и более опытных российских компаний, в портфеле которых уже были продукты со схожими возможностями. На рынок вышли Zecurion, SearchInform, а позже, когда иностранные производители свернули свою деятельность в России, — и другие игроки, в т. ч. InfoWatch и Solar Security. Говоря об экстренном появлении последних российских продуктов, стоит иметь в виду, что разработчики торопились не опоздать к переделу перспективного рынка, однако это не свидетельствует о неготовности или недостатках получившихся решений.

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

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

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

Архитектура

Кажется, что архитектура продукта должна мало волновать конечного заказчика, однако именно она определяет многие возможности и ограничения, с которыми потребитель столкнётся во время эксплуатации. 

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

Таким образом, оптимальным выглядит гибридный вариант с использованием и агентов, и сбора по сети. При этом агентская схема будет являться основной в большинстве случаев. 

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

При этом сбор по сети должен сохраняться для инсталляций с небольшим количеством точек сбора, «труднодоступными» узлами, оборудованием, которое не позволяет устанавливать агенты либо где имеется недостаточно локальных ресурсов. Подобная потребность может возникнуть не только в сегменте СМБ, но и в крупных организациях с разветвлённой сетью филиалов и устаревшими системами, которые по ряду причин продолжают эксплуатироваться.

Возможности продуктов

Источники данных

Не только архитектура, но и техническое исполнение определяет качество сбора и анализа данных. В свою очередь, от полноты охвата корпоративных систем зависит то, насколько полезной в целом окажется DCAP-система, сможет ли она дать полную картину хранения данных или только частичную, сохранив некоторую часть «теневых» данных по-прежнему скрытой.

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

Технологии анализа

Широкий охват источников для DCAP — это только первый шаг в сборе информации о том, что хранится в корпоративной сети. Не менее важно получить и классифицировать сами данные, которые находятся в разных местах и разных форматах, во множестве текстовых и графических типов файлов, в архивах, в т. ч. и запароленных. Достать эти данные, проанализировать их и составить понятную сводку помогают технологии контентного анализа. Чем больше технологий находится в арсенале DCAP-системы, тем более точным будет результат. Корректная категоризация важна для последующего применения политик ИБ.

Имеет значение не только количество технологий само по себе, но и способность совместного их применения, т. н. гибридный анализ, поскольку каждая из технологий, которые могут применяться DCAP (словари, цифровые отпечатки, отпечатки изображений, OCR, методы Байеса или опорных векторов и другие) имеет как свои сильные стороны, так и недостатки и ограничения. Гибридный анализ позволяет использовать лучшие возможности каждой технологии.

Варианты реагирования

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

Базовые возможности DCAP предполагают подготовку отчётов (их целесообразно рассмотреть отдельно) и уведомления в адрес офицеров безопасности. Сами уведомления могут приходить непосредственно в консоль или на электронную почту, но более актуальными сегодня могут оказаться сообщения в мессенджерах.

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

Отчёты и аналитика

Отчёты DCAP могут использоваться не только для выявления нарушений политик безопасности: они позволяют увидеть целостную картину хранения данных в корпоративной среде. Среди прочего DCAP позволяет найти: 

• дубликаты файлов;
• часто используемые файлы и папки;
• файлы и папки, к которым не обращаются;
• учётные записи, которые генерируют больше всего операций с файлами (чтения, изменения, удаления);
• папки с наибольшим количеством файлов;
• папки, которые растут быстрее всего, и многое другое. 

Передовые DCAP-системы имеют свыше 100 шаблонов отчётов, подсвечивающих наиболее актуальные проблемы, связанные с хранением корпоративных данных.

Среди этих многочисленных отчётов наиболее интересными могут оказаться:

• «жизнь файла», где в графическом режиме показывается, откуда и когда появился файл, видна история появления версий и форков, отображаются события с файлом внутри корпоративной сети и даже на периметре в случае интеграции с другими средствами ИБ, в частности DLP-системой;
• диаграмма связей, также в графическом режиме отображающая связи файла или папки с учётными записями;
• карточка сотрудника, т. е. информационная сводка, на одном экране объединяющая все ключевые параметры и динамику их изменения, события, риски и аномалии.

Несмотря на обилие предустановленных отчётов, предусмотреть все возможные сценарии и кейсы нереально, поэтому ещё один важный инструмент DCAP — это конструктор отчётов. Конструктор позволяет индивидуализировать имеющиеся шаблоны либо создать собственный отчёт под свои нужды «с нуля».

Отчёты внутри DCAP-системы имеют лишь ограниченный формат применения, поэтому разработчик должен предусмотреть возможность выгрузки в форматы Excel и PDF, вывода графических отчётов на печать.

Анализ данных, которые собирает DCAP-система, позволяет находить не только явные нарушения корпоративных политик ИБ, но и неочевидные угрозы, а также возможные негативные сценарии развития событий.

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

Другие критерии и факторы

Бюджет

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

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

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

Интеграция с другими элементами корпоративной ИБ

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

Совместная работа систем позволяет собирать больше информации, а также обогащать данные от отдельных сенсоров. В результате офицер безопасности видит более полную картину. Целесообразна и дальнейшая интеграция систем. Например, общие политики смогут обеспечить бесшовную защиту данных на разных уровнях и этапах обработки, а трансфер контентных технологий из DLP в DCAP повысит качество анализа. Больше возможностей у интегрированной системы будет и в плане проверки поведения пользователей (UBA) и выявления аномалий. А ещё, как уже отмечалось выше, единое хранилище событий и файлов позволит сэкономить на эксплуатации систем.

Другими задачами DCAP в рамках интеграции с корпоративными средствами ИБ является обеспечение обмена данными: если не политиками, то принципами управления. Идеальным же вариантом будет общая консоль с возможностями расследования инцидентов и сбора доказательств в IRP-системе. Помимо этого, будет полезным развёртывание и обновление системы средствами самого разработчика с учётом вариативности поддерживаемых платформ, а также, конечно, поддержка этих самых платформ, в т. ч. российских операционных систем на конечных точках сети.

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

Выводы

Приведённая ниже таблица может послужить основой для оценки и сравнения DCAP-систем при проектировании систем защиты информации в организации.

Таблица 1. Как оценить и сравнить DCAP-системы

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