Регистрация выполнения субъектами логического доступа ряда неуспешных последовательных попыток аутентификации.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Суть меры заключается в обязательной фиксации в журналах событий всех случаев, когда субъект логического доступа (пользователь, эксплуатационный персонал или программный сервис) совершает ряд неуспешных последовательных попыток аутентификации.
Главная цель меры — создание доказательной базы для:
- своевременного выявления атак на подбор паролей и иных попыток несанкционированного доступа;
- расследования инцидентов безопасности, связанных с компрометацией учётных записей.
Так как речь идёт о чисто технической мере, реализация включает:
- Настройку операционных систем, каталогов (Active Directory, LDAP) и прикладных информационных систем на регистрацию событий каждой неуспешной попытки аутентификации субъекта;
- Настройку правил (например, в SIEM-системе) для выявления последовательных неуспешных попыток аутентификации, указывающих на возможную атаку подбора пароля;
- Обеспечение достаточного срока хранения журналов регистрации таких событий для последующего анализа и расследования инцидентов.
Класс используемых средств — системы управления событиями информационной безопасности (SIEM), встроенные средства аудита операционных систем и служб каталогов.
Примеры таких средств:
- Иностранные: Splunk, Microsoft Active Directory (Audit Logon Events) и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM, RuSIEM и др.
- Открытый код: Wazuh, ELK Stack (Elasticsearch, Logstash, Kibana) и др.
- Итоги интервью с администраторами информационных систем и подразделением информационной безопасности;
- Скриншоты настроек, подтверждающие регистрацию неуспешных попыток аутентификации;
- Выгрузка журналов событий с зафиксированными неуспешными попытками аутентификации за проверяемый период;
- Правила корреляции SIEM-системы (при наличии), настроенные на выявление последовательных неуспешных попыток аутентификации.
- Регистрация неуспешных попыток аутентификации включена не для всех информационных систем;
- События неуспешных попыток аутентификации собираются, но не анализируются на предмет выявления атак подбора пароля;
- Журналы событий хранятся менее срока, необходимого для расследования инцидентов;
- Отсутствуют настроенные оповещения о превышении порогового числа неуспешных попыток аутентификации в единицу времени.
Не выявлены.
Не выявлены.
Регистрация осуществления субъектами логического доступа идентификации и аутентификации.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Мера требует фиксирования в журналах регистрации событий всех фактов идентификации и аутентификации (логина и пароля) при входе субъектов логического доступа в ресурс доступа (СУБД, АС и т. п.), что позволяет впоследствии выявлять факты входа в систему в нехарактерное для субъекта время (например, в нерабочие часы).
Главная цель меры — создание доказательной базы для:
- подтверждения факта входа конкретного субъекта в систему в определённое время;
- расследования инцидентов безопасности;
- обеспечения прозрачности и подотчётности всех действий субъектов логического доступа.
Мера не имеет организационной составляющей — её выполнение обеспечивается техническими средствами:
- Настройку встроенных механизмов аудита операционных систем, СУБД, АС и служб каталогов на регистрацию каждого факта успешной идентификации и аутентификации субъекта;
- Фиксацию в журнале как минимум даты и времени события, идентификатора субъекта и результата (успешно/неуспешно);
- Централизованный сбор данных журналов идентификации и аутентификации из различных источников для последующего анализа.
Класс используемых средств — системы управления событиями информационной безопасности (SIEM), встроенные средства аудита операционных систем, СУБД и служб каталогов.
Примеры таких средств:
- Иностранные: Splunk, Microsoft Active Directory (Audit Logon Events) и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM, RuSIEM и др.
- Открытый код: Wazuh, ELK Stack и др.
- Итоги интервью с администраторами информационных систем;
- Скриншоты настроек аудита, подтверждающие регистрацию фактов идентификации и аутентификации;
- Выгрузка журналов событий идентификации и аутентификации за проверяемый период.
- Регистрация фактов идентификации и аутентификации включена не для всех информационных систем;
- Журналы не содержат достаточного набора атрибутов (например, отсутствует точное время события);
- Журналы событий разных систем не собираются централизованно, что затрудняет их анализ;
- Журналы хранятся менее установленного срока, что не позволяет предоставить свидетельства за требуемый период.
Не выявлены.
Не выявлены.
Регистрация авторизации, завершения и (или) прерывания (приостановки) осуществления эксплуатационным персоналом и пользователями логического доступа, в том числе в АС.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Мера требует фиксирования в журналах регистрации событий всех событий, связанных с предоставлением доступа (авторизацией), с завершением или принудительным прерыванием сеанса работы пользователей и эксплуатационного персонала в ресурсе доступа (СУБД, АС и т. п.), что позволяет восстановить полную и непрерывную цепочку событий в рамках каждой сессии логического доступа.
Главная цель меры — создание полной и непрерывной доказательной базы всех этапов сессии логического доступа: от предоставления прав (авторизация) до её завершения или прерывания.
Реализация носит организационно необременительный, полностью технический характер:
- Настройку АС и иных ресурсов доступа на регистрацию события авторизации сессии (момента предоставления доступа после успешной идентификации и аутентификации);
- Настройку регистрации события завершения сессии — как штатного (выход пользователя), так и принудительного или автоматического прерывания (в том числе в рамках мер РД.13—РД.14);
- Обеспечение возможности сопоставления событий начала и завершения сессии по единому идентификатору (идентификатору сессии), позволяющего восстановить полную хронологию сессии.
Класс используемых средств — системы управления событиями информационной безопасности (SIEM), встроенные средства аудита АС и служб каталогов.
Примеры таких средств:
- Иностранные: Splunk, Microsoft Active Directory (Audit Logon/Logoff Events) и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM, RuSIEM и др.
- Открытый код: Wazuh, ELK Stack и др.
- Итоги интервью с администраторами АС;
- Скриншоты настроек, подтверждающие регистрацию событий авторизации, завершения и прерывания сессии;
- Выгрузка журналов событий, подтверждающая возможность сопоставления начала и завершения одной и той же сессии.
- Регистрация событий завершения (прерывания) сессии реализована не для всех АС, где регистрируется её начало;
- События начала и завершения сессии невозможно сопоставить между собой (отсутствует единый идентификатор сессии);
- Принудительное или аварийное прерывание сессии (например, при сбое) не регистрируется;
- Журналы событий сессий разных систем не собираются централизованно.
Не выявлены.
Не выявлены.
Регистрация запуска программных сервисов, осуществляющих логический доступ.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Суть меры заключается в обязательной фиксации в журналах событий всех случаев запуска программных сервисов, которые осуществляют логический доступ к информационным ресурсам финансовой организации.
Главная цель меры — обеспечить прозрачность и подотчётность всех автоматизированных процессов, которые взаимодействуют с информационными системами. Это критически важно, так как программные сервисы, как правило, обладают высокими привилегиями и их деятельность часто остаётся вне поля зрения администраторов.
Так как организационных мер здесь не предусмотрено, всё сводится к техническим настройкам. Сама регистрация факта запуска сервиса — штатная возможность журнала операционной системы (Windows Event Log, systemd journal), не требующая отдельного средства защиты информации; для централизованного сбора и анализа таких событий по всему парку серверов и АРМ штатного локального журналирования недостаточно, требуется система управления событиями информационной безопасности (SIEM):
- Настройку регистрации события запуска каждого программного сервиса (службы, приложения, скрипта автоматизации), осуществляющего логический доступ к информационным ресурсам от имени технической учётной записи;
- Фиксацию в журнале как минимум даты и времени запуска, идентификатора сервиса и технической учётной записи, от имени которой он запущен;
- Централизованный сбор данных о запуске программных сервисов для последующего анализа на предмет выявления несанкционированного или аномального запуска.
Класс используемых средств — встроенные средства журналирования операционных систем (штатная регистрация запуска сервисов); системы управления событиями информационной безопасности (SIEM) и средства мониторинга процессов — для централизованного сбора и анализа.
Примеры таких средств:
- Иностранные: Microsoft Sysmon (мониторинг запуска процессов), Splunk и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM, RuSIEM и др.
- Открытый код: osquery, Wazuh и др.
- Итоги интервью с администраторами информационных систем;
- Скриншоты настроек, подтверждающие регистрацию событий запуска программных сервисов;
- Выгрузка журналов событий запуска программных сервисов за проверяемый период.
- Регистрация запуска программных сервисов включена не для всех технических учётных записей;
- Журналы запуска сервисов не анализируются на предмет выявления аномального (незапланированного) запуска;
- Запуск сервисов с непредусмотренными правами (эскалация привилегий при старте) не выявляется;
- Журналы запуска программных сервисов хранятся менее установленного срока.
Не выявлены.
Не выявлены.
Регистрация изменений аутентификационных данных, используемых для осуществления логического доступа.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Суть меры заключается в обязательной фиксации в журналах событий всех случаев изменения аутентификационных данных, используемых субъектами логического доступа для входа в информационные системы.
Главная цель меры — создание полной и непрерывной доказательной базы всех изменений аутентификационных данных для:
- расследования инцидентов безопасности, связанных с компрометацией учётных записей;
- выявления аномалий (например, массовая смена паролей, смена пароля администратором без ведома пользователя);
- подтверждения факта выполнения регламентных процедур смены аутентификационных данных.
Мера реализуется исключительно техническими средствами. Сама регистрация факта изменения аутентификационных данных — штатная возможность операционных систем, служб каталогов, СУБД и прикладных информационных систем, не требующая отдельного средства защиты информации; для централизованного сбора и анализа таких событий на предмет аномалий по всей инфраструктуре штатного локального журналирования недостаточно, требуется система управления событиями информационной безопасности (SIEM):
- Настройку операционных систем, каталогов, СУБД и прикладных информационных систем на регистрацию каждого факта изменения аутентификационных данных субъекта (смены пароля, перевыпуска сертификата, привязки/отвязки фактора МФА);
- Фиксацию в журнале как минимум даты и времени изменения, идентификатора субъекта, инициатора изменения (сам субъект или администратор) и результата операции;
- Централизованный сбор данных об изменениях аутентификационных данных для последующего анализа на предмет аномалий.
Класс используемых средств — встроенные средства аудита операционных систем, служб каталогов, СУБД и систем управления учётными записями (IdM) — штатная регистрация; системы управления событиями информационной безопасности (SIEM) — для централизованного сбора и анализа.
Примеры таких средств:
- Иностранные: Microsoft Active Directory (Audit Credential Validation), Splunk и пр.
- Российские сертифицированные (ФСТЭК): Avanpost IDM, MaxPatrol SIEM и др.
- Открытый код: Wazuh, ELK Stack и др.
- Итоги интервью с администраторами информационных систем;
- Скриншоты настроек, подтверждающие регистрацию событий изменения аутентификационных данных;
- Выгрузка журналов событий изменения аутентификационных данных за проверяемый период.
- Регистрация изменений аутентификационных данных включена не для всех информационных систем;
- Журналы не позволяют определить, кто инициировал изменение — сам субъект или администратор от его имени;
- Массовые (аномальные) изменения аутентификационных данных не выявляются автоматически;
- Журналы событий изменения аутентификационных данных хранятся менее установленного срока.
Не выявлены.
Не выявлены.
Регистрация действий пользователей и эксплуатационного персонала, предусмотренных в случае компрометации их аутентификационных данных.
Уровень защиты информации 3-Н, 2-О, 1-О.
Пояснение
Мера требует регистрации (документальной фиксации) действий, которые субъект логического доступа и вовлечённые сотрудники обязаны выполнить в случае компрометации его аутентификационных данных, — то есть действий, предусмотренных мерой РД.29 (сообщение о компрометации, внеплановая смена аутентификационных данных, иные реагирующие мероприятия).
Главная цель меры — обеспечить документальное подтверждение того, что при каждом зафиксированном случае компрометации аутентификационных данных предусмотренные действия были выполнены фактически, а не только формально предписаны регламентом (мера РД.29).
Мера не предусматривает технической составляющей и целиком опирается на организационные меры:
- Фиксацию в журнале (реестре) инцидентов, связанных с компрометацией аутентификационных данных (см. также меру РД.29), не только факта самой компрометации, но и перечня конкретных действий, выполненных субъектом и вовлечёнными сотрудниками в связи с этим случаем;
- Указание в такой записи даты и времени выполнения каждого действия (сообщение о компрометации, смена аутентификационных данных, иные реагирующие мероприятия) и ответственного за его выполнение;
- Периодический контроль подразделением информационной безопасности полноты и своевременности регистрации предусмотренных действий по зафиксированным случаям компрометации.
- Журнал (реестр) инцидентов, связанных с компрометацией аутентификационных данных, содержащий записи о выполненных действиях;
- Акты (отчёты) периодического контроля полноты и своевременности регистрации таких действий.
- В журнале инцидентов фиксируется только факт компрометации, но не перечень выполненных в связи с этим действий;
- Действия, предусмотренные на случай компрометации, регистрируются несвоевременно (со значительной задержкой относительно их фактического выполнения);
- Периодический контроль полноты и своевременности регистрации таких действий не проводится.
Не выявлены.
Не выявлены.