Регистрация информации о событиях защиты информации, потенциально связанных с инцидентами защиты информации, в том числе НСД, выявленными в рамках мониторинга и анализа событий защиты информации.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
События, выявленные в ходе мониторинга и анализа (меры МАС.17—МАС.20) и потенциально указывающие на инцидент защиты информации, включая НСД, должны регистрироваться отдельно — как алерты, требующие дальнейшей обработки, а не растворяться в общем потоке рядовых событий.
Главная цель меры — не допустить, чтобы конкретное критическое событие или потенциальный инцидент оказались потеряны среди тысяч рядовых событий: без выделенной регистрации таких событий их обработка целиком зависит от того, заметит ли их аналитик вручную, что при большом объёме потока событий защиты информации практически неосуществимо.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииОрганизационная реализация предполагает:
- Регламентацию критериев, по которым событие защиты информации признаётся потенциально связанным с инцидентом (в том числе с НСД) и подлежит отдельной регистрации;
- Определение порядка передачи зарегистрированного потенциального инцидента от системы мониторинга к группе реагирования на инциденты защиты информации (ГРИЗИ, меры РИ.7—РИ.9).
Техническая реализация обеспечивается настройкой системы централизованного сбора и корреляции событий (SIEM) на автоматическое формирование отдельной карточки (тикета) при срабатывании корреляционного правила или иного признака потенциального инцидента (мера МАС.18), с выделением такой карточки в отдельную очередь обработки, не пересекающуюся с общим потоком сырых событий.
Класс используемых средств — система централизованного сбора и корреляции событий (SIEM) с модулем управления инцидентами (Incident Response / Case Management), нередко реализуемым в виде отдельной SOAR-платформы.
Примеры таких средств:
- Иностранные: Splunk (Notable Events), IBM QRadar (Offenses) и пр.
- Российские сертифицированные (ФСТЭК): MaxPatrol SIEM/KUMA (карточки инцидентов), R-Vision SOAR и др.
- Открытый код: TheHive (платформа управления инцидентами) в сочетании с Wazuh/ELK Stack.
- Регламент (порядок), определяющий критерии отнесения события к потенциальному инциденту и порядок его передачи в ГРИЗИ.
- Итоги интервью с ответственным за организацию реагирования на инциденты.
- Конфигурация SIEM-системы в части выделения потенциальных инцидентов в отдельную очередь обработки.
- Выгрузка зарегистрированных карточек потенциальных инцидентов за проверяемый период.
- Итоги интервью с ответственным за администрирование SIEM-системы.
- Критерии отнесения события к потенциальному инциденту не формализованы, решение принимается аналитиком по своему усмотрению в каждом отдельном случае;
- Отдельная очередь обработки потенциальных инцидентов не выделена, аналитик вынужден вручную выискивать значимые события в общем потоке;
- Не все источники, охваченные мониторингом (мера МАС.1—МАС.7), подключены к формированию потенциальных инцидентов, часть источников фактически не порождает алертов;
- Передача зарегистрированного потенциального инцидента группе реагирования (ГРИЗИ) происходит с задержкой, не соответствующей критичности выявленного события.
Регистрация информации, потенциально связанной с инцидентами защиты информации, в том числе НСД, полученной от работников, клиентов и (или) контрагентов финансовой организации.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Информация о потенциальных инцидентах защиты информации, поступающая не из технических средств мониторинга, а от людей — работников, клиентов, контрагентов финансовой организации (например, жалоба клиента на подозрительную операцию, сообщение сотрудника о фишинговом письме), должна фиксироваться с указанием источника и характера обращения.
Главная цель меры — не упустить сигналы о потенциальном инциденте, поступающие по каналам, не охваченным автоматизированным мониторингом (меры МАС.1—МАС.7): сообщение клиента о подозрительной операции или устное сообщение сотрудника о замеченной подозрительной активности нередко становится первым и единственным индикатором инцидента, который затем может быть использован при последующем расследовании, если он был своевременно зафиксирован.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииОрганизационная реализация предполагает:
- Определение перечня каналов получения информации о потенциальных инцидентах от работников, клиентов и контрагентов (телефон горячей линии, форма обратной связи, электронная почта, личное обращение);
- Регламентацию обязанности работников незамедлительно сообщать о замеченных признаках инцидента защиты информации (мера РИ.4 в части единых правил получения такой информации);
- Обучение работников, взаимодействующих с клиентами, распознаванию признаков потенциального инцидента в обращениях клиентов.
Техническая реализация дополняет организационные каналы регистрацией поступивших сообщений в той же системе управления инцидентами (мера РИ.1), что и события, выявленные автоматизированным мониторингом, с фиксацией источника обращения (работник/клиент/контрагент), канала поступления и содержания сообщения.
Класс используемых средств — система управления инцидентами (Incident Response / Case Management), интегрированная с каналами приёма обращений (форма на портале, интеграция с CRM/контакт-центром).
Примеры таких средств:
- Иностранные: ServiceNow (Case Management) и пр.
- Российские сертифицированные (ФСТЭК): R-Vision SOAR, MaxPatrol SIEM/KUMA (регистрация ручных обращений) и др.
- Открытый код: TheHive (ручное создание карточки инцидента по обращению) и др.
- Внутренний нормативный документ, регламентирующий обязанность и порядок сообщения работниками о признаках инцидента защиты информации;
- Свидетельства проведения обучения работников, взаимодействующих с клиентами, распознаванию признаков потенциального инцидента;
- Перечень каналов получения информации о потенциальных инцидентах от клиентов и контрагентов.
- Конфигурация системы управления инцидентами в части регистрации обращений от работников, клиентов и контрагентов.
- Выгрузка зарегистрированных обращений о потенциальных инцидентах за проверяемый период с указанием источника.
- Итоги интервью с ответственным за приём обращений о потенциальных инцидентах.
- Обращения клиентов о подозрительных операциях фиксируются в системе контакт-центра, но не передаются в систему управления инцидентами защиты информации;
- Работники не осведомлены об обязанности и порядке сообщения о замеченных признаках инцидента, обращения происходят стихийно, без единого канала;
- Устные сообщения сотрудников о подозрительной активности не документируются, фиксируются только письменные обращения;
- Обучение работников, взаимодействующих с клиентами, распознаванию признаков инцидента проводится нерегулярно, без контроля усвоения материала.
Классификация инцидентов защиты информации с учетом степени их влияния (критичности) на предоставление финансовых услуг, реализацию бизнес-процессов и (или) технологических процессов финансовой организации.
Уровень защиты информации 3-О, 2-О, 1-Т.
Пояснение
Инциденты защиты информации должны классифицироваться по степени критичности — с учётом их влияния на предоставление финансовых услуг, реализацию бизнес-процессов и (или) технологических процессов организации, а не обрабатываться по единому шаблону независимо от масштаба последствий.
Главная цель меры — обеспечить приоритизацию реагирования соразмерно фактической критичности инцидента: без формализованной классификации инцидент с существенным влиянием на предоставление финансовых услуг рискует быть обработан с той же очерёдностью, что и рядовое малозначимое событие, что приводит к неоправданной задержке реагирования именно там, где скорость реакции наиболее важна.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииОрганизационная реализация предполагает:
- Разработку и утверждение шкалы критичности инцидентов защиты информации с чёткими критериями отнесения инцидента к каждому уровню исходя из его влияния на предоставление финансовых услуг, бизнес-процессы и технологические процессы;
- Определение для каждого уровня критичности соответствующих сроков и порядка реагирования (мера РИ.6);
- Закрепление ответственности за первичную классификацию инцидента непосредственно на этапе его регистрации (роль оператора-диспетчера ГРИЗИ, мера РИ.9).
Техническая реализация обеспечивается настройкой системы управления инцидентами на автоматическое или полуавтоматическое присвоение уровня критичности карточке инцидента исходя из типа затронутого события, критичности актива (см. классификацию ресурсов доступа) и заданных правил, с возможностью последующей ручной корректировки аналитиком.
Класс используемых средств — система управления инцидентами (Incident Response / Case Management) с функцией автоматической приоритизации по критичности.
Примеры таких средств:
- Иностранные: ServiceNow (правила приоритизации инцидентов) и пр.
- Российские сертифицированные (ФСТЭК): R-Vision SOAR, MaxPatrol SIEM/KUMA (правила присвоения критичности) и др.
- Открытый код: TheHive (ручная/полуавтоматическая классификация по степени тяжести) и др.
- Внутренний нормативный документ (шкала критичности) с критериями классификации инцидентов защиты информации по степени влияния.
- Конфигурация системы управления инцидентами в части автоматической приоритизации по критичности.
- Выгрузка карточек инцидентов за проверяемый период с указанием присвоенного уровня критичности и сопоставлением критериям.
- Итоги интервью с ответственным за администрирование системы управления инцидентами.
- Шкала критичности инцидентов не увязана с реальным влиянием на предоставление финансовых услуг, критерии сформулированы абстрактно и допускают произвольную трактовку;
- Присвоенный уровень критичности не пересматривается при получении новой информации в ходе расследования инцидента, хотя фактическое влияние может измениться;
- Классификация инцидента выполняется формально, без учёта фактической критичности затронутого актива;
- Инциденты с изначально заниженной критичностью не подлежат последующему контролю (аудиту) правильности присвоенного уровня.
Установление и применение единых правил получения от работников, клиентов и (или) контрагентов финансовой организации информации, потенциально связанной с инцидентами защиты информации.
Уровень защиты информации 3-О, 2-О, 1-О.
Пояснение
Мера требует установления и применения единых правил получения от работников, клиентов и (или) контрагентов финансовой организации информации, потенциально связанной с инцидентами защиты информации.
Главная цель меры — формализовать процесс, лежащий в основе меры РИ.2: без единых, документально закреплённых правил получения такой информации сам факт наличия канала для обращений (телефон, форма обратной связи) не гарантирует, что поступившее сообщение будет обработано единообразно и своевременно доведено до группы реагирования, вне зависимости от того, кто из сотрудников его принял.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииМера реализуется исключительно организационными методами и предполагает:
- Разработку и утверждение внутреннего нормативного документа, устанавливающего единые правила приёма, первичной обработки и передачи в ГРИЗИ информации, потенциально связанной с инцидентами защиты информации, поступающей от работников, клиентов и контрагентов;
- Определение обязательного минимального состава сведений, фиксируемых при приёме такого обращения (дата, источник, канал, содержание, контактные данные обратившегося);
- Установление предельного срока передачи зарегистрированного обращения от лица, принявшего его, в ГРИЗИ.
- Внутренний нормативный документ, устанавливающий единые правила получения информации, потенциально связанной с инцидентами, от работников, клиентов и контрагентов;
- Выборочная проверка зарегистрированных обращений на предмет соответствия установленному составу фиксируемых сведений и срокам передачи в ГРИЗИ.
- Единые правила приёма обращений установлены только для одного канала (например, для контакт-центра), тогда как обращения по иным каналам обрабатываются без формализованного порядка;
- Обязательный минимальный состав фиксируемых сведений об обращении соблюдается не в полном объёме, отдельные обращения регистрируются без указания источника или содержания;
- Предельный срок передачи обращения в ГРИЗИ не соблюдается на практике, фактическая передача происходит с существенной задержкой;
- Работники, непосредственно принимающие обращения от клиентов и контрагентов, не ознакомлены с установленными правилами под подпись.
Установление и применение единых правил регистрации и классификации инцидентов защиты информации в части состава и содержания атрибутов, описывающих инцидент защиты информации, и их возможных значений.
Уровень защиты информации 3-О, 2-Т, 1-Т.
Пояснение
Для регистрации и классификации инцидентов должен применяться единый, заранее определённый состав атрибутов (идентификатор, дата и время, тип, источник, степень критичности, статус) с закреплёнными допустимыми значениями каждого атрибута, а не произвольное описание инцидента в свободной форме.
Главная цель меры — обеспечить, чтобы разные операторы заполняли карточки инцидентов единообразно: без единого справочника атрибутов и их допустимых значений накапливающиеся записи об инцидентах становятся несопоставимыми между собой, что не позволяет вести содержательную отчётность и выполнять автоматический поиск инцидентов по типу или уровню критичности.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииОрганизационная реализация предполагает:
- Разработку и утверждение внутреннего нормативного документа, устанавливающего состав обязательных атрибутов карточки инцидента защиты информации и справочник допустимых значений для каждого атрибута;
- Регламентацию порядка пересмотра и пополнения справочника допустимых значений атрибутов при появлении новых типов инцидентов.
Техническая реализация обеспечивается настройкой системы управления инцидентами на использование структурированной формы (карточки) инцидента со справочными (выпадающими) полями атрибутов, исключающей ввод значений, не входящих в утверждённый справочник, и не допускающей регистрацию инцидента с незаполненными обязательными атрибутами.
Класс используемых средств — система управления инцидентами (Incident Response / Case Management) со структурированной (справочной) моделью карточки инцидента.
Примеры таких средств:
- Иностранные: ServiceNow (структурированные поля Case) и пр.
- Российские сертифицированные (ФСТЭК): R-Vision SOAR, MaxPatrol SIEM/KUMA (структурированная карточка инцидента) и др.
- Открытый код: TheHive (настраиваемая структура карточки инцидента) и др.
- Внутренний нормативный документ, устанавливающий состав атрибутов карточки инцидента и справочник их допустимых значений.
- Конфигурация системы управления инцидентами в части структурированных полей карточки инцидента.
- Выборочная проверка карточек зарегистрированных инцидентов на предмет заполнения всех обязательных атрибутов допустимыми значениями.
- Итоги интервью с ответственным за администрирование системы управления инцидентами.
- Справочник допустимых значений атрибутов не пересматривался длительное время, что вынуждает операторов подбирать неточно соответствующее значение из устаревшего перечня;
- Отдельные атрибуты карточки инцидента допускают ввод произвольного текста вместо выбора из справочника, что снижает единообразие данных;
- Обязательность заполнения всех атрибутов технически не контролируется, часть карточек инцидентов сохраняется с неполным составом сведений;
- Состав атрибутов карточки инцидента не пересматривался при появлении новых типов инцидентов, характерных для организации.