Организация мониторинга данных регистрации о событиях защиты информации, формируемых техническими мерами, входящими в состав системы защиты информации.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Отдельного мониторинга требуют данные регистрации о событиях защиты информации, формируемые техническими мерами, входящими в состав системы защиты информации (СЗИ от НСД, средствами криптографической защиты, средствами защиты от вредоносного кода, DLP-системой и иными применяемыми техническими средствами защиты).
Главная цель меры — обеспечить непрерывное наблюдение именно за тем массивом событий, который формируют сами средства защиты, поскольку он в первую очередь содержит прямые индикаторы срабатывания защитных механизмов, попыток их обхода или нарушения их штатной работы, и без организованного мониторинга такие индикаторы остаются недоступными для своевременного реагирования.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииТехническая реализация обеспечивается настройкой централизованного сбора событий, формируемых всеми техническими средствами защиты информации, в систему мониторинга (SIEM) с определением правил корреляции и приоритизации, специфичных именно для событий от СЗИ, и организацией круглосуточного наблюдения (силами собственного или привлечённого SOC) за формируемыми оповещениями. Штатная пересылка событий (например, встроенная функция Windows Event Forwarding, syslog-переадресация в Linux) способна централизованно собирать события от отдельных СЗИ без отдельного приобретения; однако для выполнения самой цели меры — корреляции, приоритизации и круглосуточного наблюдения за потоком событий от разнородных средств защиты — штатной пересылки недостаточно, требуется система централизованного сбора и корреляции событий (SIEM).
Класс используемых средств — штатная пересылка событий операционной системы (Windows Event Forwarding, syslog) для базового сбора; система централизованного сбора и корреляции событий (SIEM) и центр мониторинга и реагирования на инциденты (SOC) — для корреляции, приоритизации и круглосуточного наблюдения.
Примеры таких средств:
- Иностранные: Splunk, IBM QRadar и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM, KUMA (Kaspersky Unified Monitoring and Analysis) и др.
- Открытый код: Wazuh, Elastic (ELK Stack) и др.
- Конфигурация SIEM-системы в части сбора событий от технических средств защиты информации.
- Регламент мониторинга событий защиты информации, формируемых СЗИ.
- Итоги интервью с ответственным за мониторинг (SOC).
- Мониторингом охвачены не все технические средства защиты информации, отдельные СЗИ (например, DLP-система) не подключены к централизованному сбору;
- Правила корреляции и приоритизации событий от СЗИ не адаптированы к специфике конкретных средств защиты, используются только общие шаблоны;
- Мониторинг событий организован не в круглосуточном режиме, что создаёт временные окна без наблюдения;
- Оповещения о срабатывании СЗИ формируются, но не имеют установленного регламентом срока и порядка реагирования.
Организация мониторинга данных регистрации о событиях защиты информации, формируемых сетевым оборудованием, в том числе активным сетевым оборудованием, маршрутизаторами, коммутаторами.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Мониторинг должен охватывать данные регистрации, формируемые активным сетевым оборудованием — маршрутизаторами и коммутаторами.
Главная цель меры — своевременно обнаружить несанкционированное изменение конфигурации коммутатора или маршрутизатора (создание скрытого VLAN, изменение маршрутизации), которое иначе способно долгое время оставаться незамеченным на уровне вышестоящих систем мониторинга, ориентированных на иные источники событий.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииТехническая реализация обеспечивается настройкой активного сетевого оборудования (маршрутизаторов, коммутаторов) на журналирование событий, связанных с изменением конфигурации, доступом к устройству и работой протоколов маршрутизации, с последующей передачей событий по протоколу syslog в систему централизованного сбора и корреляции (SIEM).
Класс используемых средств — встроенные средства журналирования сетевого оборудования (syslog), система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Cisco (syslog, NetFlow), Splunk и пр.
- Российские сертифицированные (ФСТЭК): «Континент» (журнал управления конфигурацией), MaxPatrol SIEM, KUMA и др.
- Открытый код: rsyslog/syslog-ng (сбор с сетевого оборудования), Wazuh и др.
- Конфигурация журналирования и передачи событий (syslog) на образце сетевого оборудования.
- Выгрузка зарегистрированных событий изменения конфигурации сетевого оборудования за проверяемый период.
- Итоги интервью с ответственным за администрирование сетевой инфраструктуры.
- Журналирование настроено не на всём активном сетевом оборудовании, часть устройств (в удалённых подразделениях) исключена из мониторинга;
- События изменения конфигурации собираются, но не сопоставляются с перечнем санкционированных изменений (регламентом управления изменениями);
- Локальный буфер журнала на самом сетевом устройстве ограничен по объёму и перезаписывается быстрее, чем события успевают передаваться в SIEM при временном разрыве канала;
- Мониторинг не выявляет факты отключения или изменения самой передачи журнала (syslog) со стороны скомпрометированного устройства.
Организация мониторинга данных регистрации о событиях защиты информации, формируемых сетевыми приложениями и сервисами.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Мониторингом должны быть охвачены и данные регистрации о событиях защиты информации, формируемые сетевыми приложениями и сервисами — веб-серверами, почтовыми серверами, прокси, DNS и другими сервисами инфраструктуры.
Главная цель меры — своевременно обнаруживать случаи компрометации сетевых приложений и сервисов: именно эти компоненты, как правило, непосредственно доступны из внешней или менее доверенной сети и чаще других становятся точкой первичного проникновения, а их собственные журналы содержат специфичные для конкретного протокола или приложения индикаторы атаки, недоступные на уровне сетевого оборудования (мера МАС.2).
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииТехническая реализация обеспечивается настройкой сетевых приложений и сервисов (веб-серверов, почтовых серверов, прокси, DNS-серверов) на журналирование событий доступа, ошибок и административных действий с последующей передачей событий в систему централизованного сбора и корреляции (SIEM) с правилами выявления аномалий, специфичных для каждого типа сервиса (например, признаков SQL-инъекции в журнале веб-сервера).
Класс используемых средств — встроенные средства журналирования сетевых приложений и сервисов, система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: журналы Nginx/Apache/Postfix, Splunk и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM, KUMA и др.
- Открытый код: Wazuh (сбор и правила корреляции для типовых сервисов), ELK Stack и др.
- Конфигурация журналирования на образцах сетевых приложений и сервисов.
- Выгрузка зарегистрированных событий по сетевым приложениям и сервисам за проверяемый период.
- Итоги интервью с ответственным за администрирование сетевых сервисов.
- Мониторингом охвачены не все сетевые приложения и сервисы, отдельные вспомогательные сервисы (внутренний DNS, прокси для тестового контура) исключены;
- Правила выявления аномалий не адаптированы к специфике конкретного приложения, применяются только общие сигнатуры;
- Уровень детализации журналирования на сервисах установлен ниже необходимого для выявления признаков компрометации (например, не фиксируются полные параметры запроса);
- Журналы сетевых приложений хранятся локально дольше, чем передаются в SIEM, что создаёт риск их утраты при компрометации самого сервиса.
Организация мониторинга данных регистрации о событиях защиты информации, формируемых системным ПО, операционными системами, СУБД.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Отдельный объект мониторинга — данные регистрации о событиях защиты информации, формируемые системным ПО: операционными системами и системами управления базами данных (СУБД).
Главная цель меры — своевременно обнаруживать случаи повышения привилегий, несанкционированного изменения данных или компрометации учётной записи администратора на уровне, максимально приближённом к самим защищаемым данным: события аутентификации, изменения прав и операций с данными на уровне ОС и СУБД зачастую являются первым (а иногда единственным) индикатором инцидента, не проявляющимся на сетевом уровне.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииТехническая реализация обеспечивается настройкой аудита операционных систем и СУБД на журналирование событий аутентификации, изменения прав доступа, запуска процессов и операций с данными, с последующей передачей событий в систему централизованного сбора и корреляции (SIEM) и правилами выявления признаков повышения привилегий и аномальных операций с данными.
Класс используемых средств — встроенные средства аудита операционных систем и СУБД, система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Windows Event Log/Sysmon, аудит Oracle/PostgreSQL, Splunk и пр.
- Российские сертифицированные (ФСТЭК): аудит отечественных ОС (Astra Linux, «РЕД ОС»), MaxPatrol SIEM, KUMA и др.
- Открытый код: auditd (Linux), Wazuh (сбор и корреляция) и др.
- Конфигурация аудита на образцах операционных систем и СУБД.
- Выгрузка зарегистрированных событий аутентификации, изменения прав и операций с данными за проверяемый период.
- Итоги интервью с ответственным за администрирование ОС и СУБД.
- Аудит СУБД настроен только на уровне подключения, детальные операции с данными (SELECT/UPDATE/DELETE над критичными таблицами) не журналируются;
- Мониторингом охвачены не все серверы с системным ПО, тестовые и вспомогательные серверы исключены без формального обоснования;
- Учётные записи с максимальными привилегиями (встроенный администратор ОС/СУБД) исключены из аудита как «доверенные», что оставляет наиболее критичные действия вне контроля;
- Правила выявления повышения привилегий не пересматриваются при изменении ролевой модели ОС/СУБД.
Организация мониторинга данных регистрации о событиях защиты информации, формируемых АС и приложениями.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Мониторинг должен распространяться и на данные регистрации о событиях защиты информации, формируемые автоматизированными системами (АС) и прикладными приложениями организации.
Главная цель меры — обеспечить видимость событий на уровне бизнес-логики самих АС (например, финансовых транзакций, изменений клиентских данных), которые не отражаются ни в журналах сетевого оборудования (мера МАС.2), ни в журналах ОС/СУБД (мера МАС.4): именно на этом уровне выявляются мошеннические операции и нарушения бизнес-процессов, невидимые на инфраструктурном уровне.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииТехническая реализация обеспечивается настройкой АС и прикладных приложений на формирование событий защиты информации, связанных с выполнением значимых бизнес-операций (аутентификация в АС, изменение критичных данных, выполнение транзакций), с последующей передачей событий в систему централизованного сбора и корреляции (SIEM) и правилами выявления признаков мошеннических операций и нарушений бизнес-логики.
Класс используемых средств — встроенные механизмы аудита автоматизированных систем и прикладных приложений, система централизованного сбора и корреляции событий (SIEM), в отдельных случаях — специализированные антифрод-платформы.
Примеры таких средств:
- Иностранные: Splunk (сбор прикладных логов), SAS Fraud Management и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM, KUMA и др.
- Открытый код: Wazuh (сбор прикладных логов), ELK Stack и др.
- Конфигурация журналирования событий защиты информации в АС и прикладных приложениях.
- Выгрузка зарегистрированных прикладных событий за проверяемый период.
- Итоги интервью с ответственным за эксплуатацию АС.
- Мониторингом охвачены не все АС организации, унаследованные (легаси) системы формируют события в формате, не интегрированном с SIEM;
- Регистрируются только технические события (вход/выход из АС), но не события уровня бизнес-логики (изменение суммы транзакции, реквизитов получателя);
- Правила выявления мошеннических операций и нарушений бизнес-логики не актуализируются при изменении бизнес-процессов АС;
- Разработчики АС не привлекаются к определению перечня событий, подлежащих регистрации, что приводит к формальному, а не содержательному покрытию.
Организация мониторинга данных регистрации о событиях защиты информации, формируемых контроллерами доменов.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Приоритетным объектом мониторинга данных регистрации о событиях защиты информации мера определяет контроллеры доменов.
Главная цель меры — обеспечить приоритетное наблюдение за наиболее критичным компонентом инфраструктуры аутентификации и авторизации: компрометация контроллера домена предоставляет злоумышленнику контроль над учётными записями и правами доступа в масштабе всей инфраструктуры, что делает своевременное выявление признаков такой компрометации (например, необычной активности встроенных привилегированных групп) задачей повышенного приоритета по сравнению с мониторингом рядового сервера.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииТехническая реализация обеспечивается настройкой расширенного аудита безопасности на контроллерах доменов (события аутентификации, изменения групповых политик, членства в привилегированных группах, репликации каталога) с последующей передачей событий в систему централизованного сбора и корреляции (SIEM) и правилами выявления известных техник атак на инфраструктуру Active Directory (например, Kerberoasting, DCSync).
Класс используемых средств — встроенные средства аудита службы каталогов (Active Directory и аналогичные), система централизованного сбора и корреляции событий (SIEM), специализированные средства обнаружения атак на инфраструктуру каталогов.
Примеры таких средств:
- Иностранные: Microsoft Defender for Identity, Splunk и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM, KUMA (в том числе с готовыми правилами выявления атак на AD) и др.
- Открытый код: Wazuh (сбор событий контроллера домена), BloodHound (анализ путей эскалации привилегий, для аудита конфигурации) и др.
- Конфигурация расширенного аудита безопасности на контроллерах доменов.
- Выгрузка зарегистрированных событий контроллеров доменов за проверяемый период, включая события изменения привилегированных групп.
- Итоги интервью с ответственным за администрирование службы каталогов.
- Расширенный аудит безопасности настроен не на всех контроллерах доменов, часть резервных контроллеров исключена;
- Правила выявления известных техник атак на инфраструктуру каталогов не применяются, мониторинг ограничивается только базовыми событиями входа/выхода;
- Изменения членства в критичных привилегированных группах (Domain Admins и аналогичных) не выделены в отдельную категорию событий повышенного приоритета;
- Мониторинг событий контроллеров доменов не организован в круглосуточном режиме, несмотря на критичность данного компонента инфраструктуры.
Организация мониторинга данных регистрации о событиях защиты информации,
формируемых средствами (системами) контроля и управления доступом.
Уровень защиты информации 3-Н, 2-Н, 1-Т.
Пояснение
Мониторинг событий защиты информации должен охватывать и данные регистрации, формируемые средствами (системами) контроля и управления доступом (СКУД).
Главная цель меры — распространить мониторинг событий защиты информации на физический уровень доступа: события СКУД (проход через контролируемую точку доступа, попытки прохода вне графика, срабатывание тревожных датчиков) необходимы для сопоставления с событиями логического доступа (например, для выявления входа в АС с рабочего места сотрудника, физически не присутствующего в контролируемой зоне в это время).
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииТехническая реализация обеспечивается настройкой системы контроля и управления доступом на журналирование событий прохода через контролируемые точки доступа, попыток несанкционированного прохода и срабатывания тревожных датчиков, с последующей передачей событий в систему централизованного сбора и корреляции (SIEM) и правилами сопоставления с событиями логического доступа к информационным ресурсам.
Класс используемых средств — встроенные средства журналирования систем контроля и управления доступом (СКУД), система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: HID Global (журнал событий СКУД), Splunk и пр.
- Российские сертифицированные (ФСТЭК/аттестация физической защиты): «Sigur», Bolid («Орион») и др.
- Открытый код: полноценных СКУД-платформ данного класса в открытом коде практически не представлено, интеграция с SIEM выполняется через экспорт событий СКУД в Wazuh/ELK.
- Конфигурация журналирования событий системы контроля и управления доступом.
- Выгрузка зарегистрированных событий СКУД за проверяемый период, включая попытки несанкционированного прохода.
- Итоги интервью с ответственным за физическую защиту и администрирование СКУД.
- События СКУД собираются локально в собственной консоли системы, но не передаются в SIEM для сопоставления с событиями логического доступа;
- Мониторингом охвачены не все контролируемые точки доступа, часть второстепенных помещений исключена из системы регистрации;
- Правила сопоставления физического и логического доступа (выявление входа в систему при отсутствии сотрудника в контролируемой зоне) не настроены;
- Срабатывания тревожных датчиков и попытки несанкционированного прохода не имеют установленного регламентом порядка и срока реагирования.