Обзор Solar MultiDozor, обновлённого модуля DLP-системы Solar Dozor 7.11

1. Введение
2. Функциональные возможности модуля MultiDozor
   1. 2.1. Хранение информации в системе
   2. 2.2. Раздельное хранение данных
   3. 2.3. Настройка организационных единиц
   4. 2.4. Распределение прав доступа пользователей в MultiDozor
   5. 2.5. Быстрый сквозной поиск
   6. 2.6. Отчётность
   7. 2.7. Работа с персонами и Досье
   8. 2.8. Политика безопасности
   9. 2.9. Управление агентами Dozor Endpoint Agent
   10. 2.10. Multi-Crawler
   11. 2.11. Multi-UBA
3. Архитектурные схемы работы модуля MultiDozor
   1. 3.1. Распределённая схема
   2. 3.2. Централизованная схема
   3. 3.3. Комбинированная схема
4. Системные требования модуля MultiDozor
5. Выводы

Введение

DLP-система Solar Dozor поддерживает работу в географически распределённом режиме и отвечает за предотвращение утечек конфиденциальных данных, выявление признаков корпоративного мошенничества, профилактику и расследование инцидентов в информационной и экономической безопасности. Она концентрируется не на движении данных, а на действиях сотрудников, их связях и поведении. Иными словами, Solar Dozor занимается превентивным реагированием на ИБ-инциденты. Такой подход снижает количество ложных срабатываний и отвлекающих уведомлений, благодаря чему офицеры безопасности могут сосредоточиться на главном — расследованиях и профилактике критических инцидентов.

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

Основные из них — следующие:

• недостаточно ясное представление о рисках и уровне безопасности в компании в целом;
• неполнота и несвоевременность информации из филиалов;
• проблема обнаружения инцидентов при межфилиальных конфликтных ситуациях;
• отсутствие возможности проводить сквозные расследования инцидентов;
• недостаточный контроль работы специалистов по безопасности со стороны головного офиса;
• слабые каналы связи в филиалах организации.

Эти проблемы призван решить модуль MultiDozor DLP-системы Solar Dozor 7.11. Первый его анонс состоялся при выпуске версии 7.2 в 2020 году.

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

Рассмотрим, как изменилась функциональность модуля MultiDozor.

Функциональные возможности модуля MultiDozor

Хранение информации в системе

Начнём с ресурсов, где выполняется обработка информации. В MultiDozor это — площадки с серверами, на которых работает DLP-система. Тип хранения данных напрямую зависит от архитектуры внедрения модуля.

Централизованные ресурсы называются общими. На них располагается основная точка входа в MultiDozor — центральный узел управления и центральный вход в интерфейс.

Рисунок 1. Классификация ресурсов в модуле MultiDozor

Распределённые ресурсы подразумевают наличие у филиалов своих технических возможностей для развёртывания DLP и называются подкластерами.

Отметим, что на общих ресурсах могут размещаться также сервисы совместного с MultiDozor использования: поведенческий анализ (UBA), оптическое распознавание (OCR), а также централизованное хранилище данных.

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

Раздельное хранение данных

Раздельное хранение данных — это их размещение в подкластерах.

Рисунок 2. Хранение в подкластерах

Такая организация хранения позволяет решить две задачи:

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

Настройка организационных единиц

Филиалы в терминологии MultiDozor называются организационными единицами. При распределённых ресурсах организационные единицы описываются через относящиеся к ним подкластеры.

Рисунок 3. Настройка организационной единицы по подкластерам в MultiDozor

При централизации ресурсов, если они являются общими, разделение данных организационной единицы происходит через логику организационно-штатной структуры. Эта информация находится в разделе «Досье» (модуль Dossier Solar Dozor для расширенной аналитики).

Рисунок 4. Настройка организационной единицы по веткам досье

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

Рисунок 5. Ограничение доступа к информации о сотрудниках

Распределение прав доступа пользователей в MultiDozor

Для правильного и легитимного доступа к информации предусмотрена настройка прав трёх категорий пользователей.

1. Пользователь с полными правами доступа. Может следить за картиной безопасности в компании целиком, а также отслеживать состояние ИБ любого из филиалов и работать с ним.

Рисунок 6. Пользователь без ограничений прав доступа

2. Пользователь с правами доступа к ограниченному кругу филиалов, но не одному. Эта возможность позволяет, к примеру, компенсировать нехватку ИБ-специалистов в филиалах. Также такой пользователь может проводить анализ ситуации и расследование инцидентов в рамках филиалов, за которые он отвечает.

Рисунок 7. Пользователь с правами доступа к нескольким филиалам

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

Рисунок 8. Пользователь с правами доступа исключительно к своему филиалу

Пользователи 1-го и 2-го типов имеют расширенный доступ к данным; для этого им нужно входить в систему через центральную точку. Пользователю 3-го типа достаточно локальной точки входа; запросы к локально хранящимся данным DLP-системы выполняются напрямую в подкластере.

Быстрый сквозной поиск

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

Рисунок 9. Окно поиска в системе с параметрами

Рисунок 10. Поиск ИБ-событий и инцидентов сразу по нескольким филиалам

Рисунок 11. Результат поиска инцидентов в двух филиалах за последние 30 дней

Отчётность

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

Рисунок 12. Формирование данных для отчёта

Рисунок 13. Результат отчёта в графическом представлении в MultiDozor

Рисунок 14. Подробное описание инцидентов

Рисунок 15. Вид выгруженного из MultiDozor отчёта

Работа с персонами и «Досье» 

Карточка сотрудника («персоны» в терминологии Solar Dozor) отображает сводную информацию о характере его коммуникаций, нарушениях политики безопасности по уровням критической значимости, содержит показатель уровня доверия, отображает его граф связей и т. д. При активации модуля MultiDozor на карточках персон появляется информация о филиалах, в которых числятся сотрудники. При этом доступ для безопасников гибко разграничивается: любой офицер безопасности видит общие сведения, такие как должность, подразделение и контактный телефон, руководитель видит статус, адрес электронной почты и перечень групп организационно-штатной структуры, в которые входит персона, а информация о группах особого контроля и уровне доверия доступна только офицерам соответствующего филиала. 

Рисунок 16. Отображение организационной единицы в карточке персоны

Политика безопасности 

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

Рисунок 17. Настройка временных условий в политике безопасности

Важной составляющей политики является информационный объект –– защищаемая Solar Dozor сущность, информационный актив. Информационные объекты также могут быть общими для всей компании или уникальными для конкретных филиалов. 

Рисунок 18. Настройка информационного объекта

Управление агентами Dozor Endpoint Agent

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

Рисунок 19. Отображение агентов определённой группы

Multi-Crawler

Модуль File Crawler является одной из отличительных особенностей DLP-системы Solar Dozor. В свою очередь, Multi-Crawler обеспечивает полнофункциональную работу в  географически распределённых инфраструктурах.  

Multi-Crawler осуществляет мониторинг файловых ресурсов филиалов и выявляет нарушения правил хранения защищаемой информации с учётом следующих сценариев:

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

Рассмотрим настройку функции сканирования из модуля MultiDozor.

Рисунок 20. Окно настройки обходчика (краулера) в модуле MultiDozor

При настройке из MultiDozor происходит сканирование ресурсов той организационной единицы, которая указана в задании.

Рисунок 21. Выбор организационной единицы для осуществления сканирования

Multi-UBA

В обновлённом MultiDozor функциональность модуля поведенческого анализа (UBA) также была расширена для работы в территориально распределённом режиме.

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

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

На рисунке ниже демонстрируется настройка часовых поясов для приведения  результатов анализа действий и коммуникаций сотрудников в корректный вид.

Рисунок 22. Настройка часовых поясов

Рисунок 23. Отображение результата работы функции

Данные UBA рассчитываются по всем коммуникациям сотрудников, но при этом результаты анализа поведения можно фильтровать по филиалам. Работники распределяются по филиалам в соответствии с данными из модуля «Досье». 

Архитектурные схемы работы модуля MultiDozor

Модуль MultiDozor подразумевает три архитектурные схемы внедрения.

Распределённая схема

Данные хранятся и обрабатываются в филиалах, не нагружая центральный архив.

Рисунок 24. Распределённая архитектурная схема внедрения

Централизованная схема

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

Рисунок 25. Централизованное архитектурное решение

Комбинированная схема

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

Рисунок 26. Комбинированное архитектурное решение

Системные требования модуля MultiDozor

Системные требования модуля соответствуют требованиям самой DLP-системы:

• совместимость с серверными ОС CentOS (RHEL) 7.9, РЕД ОС 7.3, Astra Linux 1.7 Common Edition / Special Edition;
• поддержка агентских ОС всех популярных производителей;
• количество ядер процессора — 8, тактовая частота — 2,2 ГГц, объём оперативной памяти — 24 ГБ, объём жёсткого диска — 600 ГБ.

Подробные технические характеристики и требования можно найти на сайте производителя.

Выводы

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

Также хочется отметить наличие нескольких архитектурных решений для развёртывания продукта. Это даёт возможность подобрать оптимальное решение под ИТ-инфраструктуру любой компании. Преемственность функциональности других модулей позволяет сделать MultiDozor универсальным.

Достоинства:

• Гибкость архитектуры.
• Регулирование нагрузки на центральное хранилище.
• Гибкость лицензирования.
• Снижение нагрузки на каналы передачи данных.
• Централизация управления информационной безопасностью организации в целом.
• Возможность разграничения доступа к данным сотрудников внутри территориально распределённой организации.

Недостатки:

• Для понимания интерфейса нужно знать терминологию продукта.