Мониторинг событий информационной безопасности
Этапы подключения и оказания услуги:
Сбор информации о структуре информационной системы Заказчика: возможно простое анкетирование, а возможно проведение инвентаризации силами наших сотрудников.
Понимание структуры сети и выдача рекомендаций о количестве и местах установки коннекторов источников событий и устройствах, возможных для подключения к услуге мониторинга.
2. Установка и настройка
Установка и настройка необходимого оборудования и ПО: установка и настройка Системы сбора журналов событий из различных источников на ресурсах Заказчика (или на арендованной платформе), установка и настройка коннекторов источников событий, подключение дополнительных узлов сбора событий (операционные системы, IDS, Антивирусные средства и т.п.)
Система сбора журналов событий настроена, проверена работа системы с коннекторами источников событий. Подтверждается возможность подключения предустановленной системы к услуге мониторинга.
3. Анализ событий информационной безопасности
Анализ событий информационной безопасности, поступающих от различных источников, корреляция событий информационной безопасности и определение инцидентов информационной безопасности, регистрация компьютерных атак и компьютерных инцидентов, приём обращений об инцидентах от персонала и пользователей информационных ресурсов, взаимодействие с НКЦКИ
Мониторинг инцидентов ИБ в режиме 24х7; реагирование на инциденты ИБ в режиме 8х5, передача информации о компьютерных инцидентах в НКЦКИ - при необходимости может быть организована передача, предоставление отчетов в электронном виде.
Предоставление рекомендаций по принятию дополнительных мер.
___________________________________________________________________
Зачем нужен мониторинг?
Следуя тренду автоматизации и цифровизации различных бизнес-процессов мы становимся зависимыми от стабильности и надежности работы таких систем. Одним из критериев стабильности работы является безопасность информации, которая обрабатывается в системе. Своевременное выявление событий, которые сигнализируют о негативном воздействии на систему и защищаемую в ней информацию, необходимо для оперативного реагирования на возникающие угрозы и снижения рисков сбоев в автоматизируемых бизнес-процессах.
Анализ совокупности событий, возникающих при работе автоматизированной системы с целью выделения и обобщения критичных событий информационной безопасности и является основной задачей мониторинга.
Следует отметить, что для ряда автоматизированных систем необходимость мониторинга событий информационной безопасности закреплена на законодательном уровне (например, для значимых объектов критической информационной инфраструктуры - КИИ).
Мониторинг событий информационной безопасности (или просто - "Мониторинг") позволяет постоянно быть в курсе состояния информационной безопасности и поддерживать защищенность контролируемой системы на заранее заданном уровне.
Не все события одинаково полезны
Программное обеспечение и операционные системы пишут свои логи в журналы, эти журналы хранятся долгое время и никем не исследуются, пока не случится инцидент безопасности. С журналами работать удобнее, если они централизованно хранятся, обрабатываются и приводятся к единому виду.
Если открыть журнал операционной системы, начинающему пользователю трудно сориентироваться - среди событий запуска разных служб он с трудом найдет событие входа в систему, событие создания пользователей. А в более сложных событиях типа "смена набора шифрования" не разберется вовсе. А если журнал был очищен, то пользователь об этом может и вовсе не узнать. В центре мониторинга события хранятся и обрабатываются, удалить их из центра мониторинга нельзя.
Как события обрабатываются
События приводятся к единому виду (нормализуются), из события извлекают все поля и заносят в таблицу. Подозрение на инцидент формируется благодаря корреляции: она позволяет нам выбрать несколько различных событий и объединить их по какому-то полю или признаку. Для выявления наиболее распространенных инцидентов разрабатываются правила корреляции.
Примеры
Самый простой пример, как отличить подбор пароля от штатного неудачного входа в систему?
Пользователь вряд ли ошибется в своем пароле более 20 раз за 20 секунд - он даже напечатать столько паролей не успеет. А вот нарушитель может пытаться подобрать пароль таким методом. И если такие попытки входа происходят в локальной сети - это повод исследовать узел-источник, с которого осуществляется подбор пароля.
Другой пример — очистка журнала событий. Сама по себе операционная система журналы событий не очищает, любая очистка журнала уже вызывает подозрения. Нарушитель может очистить журналы событий для сокрытия следов своей деятельности, при этом после очистки появляется сообщение в журнале об его очистке. Такие сообщения обнаруживаются администраторами только по факту расследования инцидента — ведь если ничего не случилось, он и не подумает изучать журналы событий на регулярной основе. А что было до очистки уже никто не восстановит. Если конечно эти события не дублируются в другом месте, например, в центре мониторинга.
Если требуется более сложный пример — можно выявить эксплуатацию Zerologon на контроллере домена, в этом случае удаленный нарушитель без каких-либо сведений сбрасывает пароль учетной записи компьютера, подключается от ее имени и получает доступ к контроллеру домена.
Благодаря правилам корреляции средствами мониторинга такие попытки замести следы будут выявлены, и удаленные журналы всё равно будут переданы в центр мониторинга, инцидент будет исследован, а Заказчик — своевременно уведомлен
И таких правил для различных сценариев действий нарушителей у нас много, некоторые правила связывают различные источники, например, антивирусное ПО и средство обнаружения вторжений.
Какие организационные меры требуются
Нельзя забывать, что максимальная эффективность мониторинга реализуется при полном наборе подключаемых узлов и поддержании базового уровня информационной безопасности в организации путем установки актуальных обновлений безопасности, настройки автоматического обновления, установки актуального антивирусного ПО на все узлы сети и т. д.