Есть не один нюанс: что учесть при работе SOC с отечественными СЗИ
Кадры из мультфильмов «Винни-Пух» (СССР,1969) и «Приключения Винни Пуха» (США, 1977)
Всем привет! Активно развивающийся тренд на импортозамещение привел к разработке большого количества разнообразных отечественных СЗИ и ОС, которые мы нередко встречаем в ходе мониторинга ИБ-событий в инфраструктурах наших заказчиков. При работе со средствами защиты и операционными системами появляются интересные аномалии и особенности — о самых интересных из них мы расскажем в этом материале.
1. Баги в конфигурации системы аудита
В ряде unix-подобных операционных систем при загрузке хоста существует определенный порядок запуска демонов в зависимости от типа выполняемой задачи. Однако после настройки аудита событий безопасности и перезагрузки ОС демоны, отвечающие за аудит и за пересылку событий, могут запуститься в некорректной последовательности. Это, в свою очередь, может повлечь за собой ошибки в сборе событий.
Другой пример — низкая аппаратная и/или программная пропускная способность подсистемы аудита. Это приводит к ошибкам работы модулей передачи событий, значительному запаздыванию в передаче событий между источником и SIEM. В нашем случае такое запаздывание доходило до нескольких месяцев. В итоге мы обратились к вендору, который выпустил патч, устраняющий ошибку.
2. Недостаточная проработка формата и содержимого событий
Данная проблема характерна для многих источников, но в отечественных СЗИ она выражена ярче и шире.
На ряде СЗИ, особенно в FW и криптошлюзах, аудит событий происходит исходя из своих внутренних логик вендора — например, в явном виде могут отсутствовать события построения или завершения VPN-сессий пользователей.
В итоге осуществлять мониторинг легитимности подключений можно лишь по событиям изменения информации о сетевых характеристиках источника подключения.
Например:
Если с хоста А с порта B произошло VPN-подключение, то говорящее об этом событие источника сообщит, что для данного пользователя актуален белый адрес A и порт B. Далее — если в рамках соединения порт будет изменен на C, то придет новое событие о том, что данному пользователю соответствует белый IP A и порт С, но при этом подключение все то же, оно не прекращалось и не создавалось заново.
Аналогичных ситуаций, когда вендор закладывает в аудит отличную от общих принципов логику, множество. При этом на источнике не предусмотрена возможность регулировать этот поток. Итог — много избыточной технической информации, которая не имеет большого значения для мониторинга инцидентов ИБ.
3. Слабо проработанная документация на СЗИ
В технической документации по части СЗИ отсутствуют или недостаточно подробно описаны возможности логирования событий и механизмы их получения в SIEM или другие внешние системы сбора событий. Какую-либо информацию об этом можно получить через официальные запросы или в ходе прямой коммуникации с представителями вендора. В этих случаях мы нередко обращаемся с вендором и вместе с ним тестируем и дорабатываем механизмы сбора событий.
4. Аудит на сертифицированных продуктах
В нашей практике мы нередко используем дополнительные инструменты аудита операционных систем, помимо стандартных средств. Для использования их необходимо установить из репозитория или автономного установочного пакета. Однако на сертифицированных ОС и в официальных репозиториях используемого нами софта нет, а установка из неофициальных источников может повлечь нарушение сертификации, что усложняет процесс настройки аудита источника.
5. Применение open-sourse продуктов
За последний год российские компании все чаще используют open-source продукты, замещающие проверенное практикой иностранное ПО. Но каждый из них имеет свои особенности и возможности аудита ИБ-событий. В итоге система может вовсе не иметь средств мониторинга инцидентов ИБ, необходимых для ее полноценного аудита, либо иметь механизмы, на изучение которых требуется длительное время.
Рост ИБ-инцидентов на UNIX-подобных ОС
Тренд по переходу российских компаний с Windows на UNIX-подобные операционные системы отразился и на динамике инцидентов информационной безопасности, которые фиксируются сервисом мониторинга центра противодействия кибератакам Solar JSOC. Разумеется, не все из них попадают в ежеквартальные отчеты — там мы учитываем инциденты только после тщательной обработки и проверки. Например, по нашим данным, за 2022 год число таких инцидентов на UNIX-системах отечественного производства выросло в 7,6 раз, а с января 2022 года по апрель 2024 — в 85 раз. При этом число инцидентов за аналогичные периоды на ОС Windows увеличилось лишь в 2,4 раза и 3,8 раза соответственно. Отдельно отметим, что на ОС Windows по-прежнему приходится основная доля инцидентов, и речь идет лишь о динамике роста.
Динамика хорошо прослеживается по графику ниже, который отражает рост числа инцидентов по хостам на UNIX-подобных ОС.
Ниже отражена поквартальная динамика по количеству инцидентов в зависимости от операционной системы:
По словам Геннадия Сазонова, инженера группы расследования инцидентов Solar 4RAYS ГК «Солар», рост инцидентов на UNIX-подобных системах связан в первую очередь с трендом на импортозамещение и постоянно нарастающем количестве установок отечественных ОС в инфраструктурах российских организаций. Это, в свою очередь, стало причиной переориентации хакеров, которые сегодня все чаще пишут вредоносы или используют другие инструменты для кибератак на подобные ОС.
Интерес дополнительно обусловлен тем, что именно под управлением Linux зачастую функционируют системы, представляющие наиболее важную ценность как для российских организаций, так и для самих атакующих.
При этом среди ряда ИБ-специалистов по-прежнему существует миф, что UNIX-подобные системы невозможно взломать, и по своей халатности могут реже ставить обновления безопасности. Также системные администраторы не всегда разбираются в Linux так же хорошо, как в Windows, и от этого UNIX-подобные системы могут быть неправильно настроены. Помимо этого, на UNIX-системах нередко работают серверы, в рамках которых можно встретить приложения с уязвимостями — этой лазейкой тоже могут воспользоваться хакеры.
Выводы
Несмотря на нюансы мониторинга событий различных ОС или СЗИ российского производства, есть неоспоримый плюс — готовность вендоров к сотрудничеству. Все они охотно идут на контакт, принимают и исправляют найденные недочеты, а также дают рекомендации и патчи.
Итог — с каждым обновлением возможности для мониторинга событий улучшаются, что позволяет заказчику быстрее и эффективнее реагировать на атаки.
Артем Шурховецкий, руководитель группы аналитического обеспечения сервиса мониторинга центра противодействия кибератакам Solar JSOC, ГК «Солар»
