С 1 февраля 2023 года вводится в действие новый стандарт ГОСТ Р 57580.4-2022 «Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер», который детализирует ряд требований к основным процессам обеспечения операционной надежности финансовых организаций (ФО), закрепленных в Положениях Центробанка — 787-П и 779-П. Данный стандарт призван помочь минимизировать риски операционной надежности. В новом стандарте по аналогии с ГОСТ Р 57580.1 устанавливается три уровня защиты: 3 — «минимальный», 2 — «стандартный», 1 — «усиленный».
В дополнение к данному стандарту ТК 122 разрабатывает стандарт, содержащий методику оценки соответствия (т. н. «математику») процессов планирования, реализации, контроля и совершенствования системы обеспечения операционной надежности (СООН). Предполагается, что данная оценка должна будет проводиться посредством внешнего аудита, с привлечением лицензиата ФСТЭК России по технической защите конфиденциальной информации: аудиторской или консалтинговой организации.
С выходов новых стандартов по операционной надежности, а также по управлению рисками (ГОСТ Р 57580.3-2022), система нормативной документации для финансовых организаций охватит область управления рисками (УР) реализации информационных угроз, управления защитой информации (ЗИ) и обеспечения операционной надежности (ОН), а также затронет элементы непрерывности бизнеса и восстановление деятельности (ОНиВД).
Основные сложности, возникающие при внедрении процессов обеспечения операционной надежности
- В ИТ-инфраструктурах и информационных системах (ИС) организаций финансовой отрасли большое количество элементов критичной архитектуры (КА) и задача их идентификации, учета, отслеживания их статусов жизненного цикла весьма объемна и требует привлечения большого количества ресурсов (кадровых, временных, финансовых, технологических).
- Регулятор в 787-П и 779-П установил довольно жесткие временные параметры, направленные на обеспечение не превышение пороговых уровней допустимого времени деградации ТП. Многие ТП, к примеру обеспечивающие работу ДБО или ведение реестра участников торгов, необходимо будет восстановить в пределах 2 часов (120 минут).
- Для создания СООН требуется разработка большого количества документации: положений, регламентов, методик, инструкций и т. п.
- В отличии от безопасников сотрудники отделов ИТ как правило не горят желанием разрабатывать документацию, вести записи и отметки по процессам для кого-то кроме себя, а это грозит привлечением технических писателей.
- Большая часть процессов обеспечения ОН в организациях традиционно не регламентирована, службы ИТ действуют по наитию, а с ротацией кадров теряется преемственность и история данных вопросов, и для решения даже небольшого вопроса необходимо зачастую размотать целый клубок проблем условно лет за пять «до».
- Помимо ресурсов, еще одной сложностью становится распределение ролей и границ ответственности между подразделениями ИТ, ИБ, основными структурными подразделениями, менеджментом, а также учет интересов многих сторон.
ГОСТ приводит восемь процессов
Объем данной статьи позволяет привести 6 из 8 основных процессов ОН и тезисно описать их ключевые особенности, процессы «управления риском внутреннего нарушителя» и «обеспечение осведомленности об угрозах» требуют отдельного освещения.
1. «Идентификация критичной архитектуры»
В рамках данного процесса осуществляется прежде всего систематическая работа по централизованному учету и классификации всех элементов КА, а также подержанию в актуальном состоянии «Перечней..», «Реестров..»: БП и ТП (в т. ч. переданных на аутсорисинг); составляющих их технологических участков ТП; персонала финансовой организации; ОИИ (прикладного и инфраструктурного уровней), учет их лицензионных политик и ограничений, а также инвентарный учет; сервисов сторонних поставщиков услуг (по моделям SaaS, PaaS, IaaS).
Вторым важным направлением работ по данному процессу является документирование и техническое описание элементов КА в стандартизированных нотациях (BPMN, IDEF0, TOGAF и т. п. ), а также поддержание данной документации в актуальном состоянии.
2. «Управление изменениями»
В рамках данного процесса осуществляется комплекс организационных и технических работ следующего характера: планирование и управление изменения конфигурации элементов КА, и информирование о них персонала; проведение анализ влияния на бизнес изменений, их приоритизация на «критичные» и «срочные», а также привлечение службы ИБ по согласованию, оценке и разработке минимизирующих риск мероприятий; протоколирование всех изменений и возможность их «отката»; разделение сред «разработки», «тестирования», «эксплуатации».
Также с учетом лучших практик производится разработка стандартов конфигурирования (в т. ч. обеспечение их версионности): ОИИ; правил обновлений; планов управления конфигурацией.
Достаточно большой объем работ в рамках данного процесса осуществляется в отношении управления уязвимостями и проверки обновлений ПО: сканирование уязвимостей и проведение регулярных пентестов «внутренних» ОИИ, а также на «границе» контура безопасности; ведение «Реестров уязвимостей», проведение антивирусных проверок; заблаговременная подготовка процедур быстрого восстановления БП и ТП в случае неудачного применения обновлений; ограничение в применении несогласованных должным порядком обновлений; кроме того на этапах жизненного цикла разработки прикладного ПО применяются такие проверки безопасности как статический и динамический анализ кода, код ревью; симуляция действий команды нарушителей (Red team) в отношении ОИИ.
3. «Обработка инцидентов и восстановление после них»
Работы в рамках данного процесса являются самыми объемными с точки зрения инженерных работ ИТ и ИБ специалистов, по каждому из направлений необходим расчет и установление целевых показателей: реагирования (ограничение степени тяжести последствий (СТП) инцидентов и соблюдения допустимого уровня деградации БП и ТП), восстановления (устранения причин и восстановление данных в соответствии с целевым временем восстановления (ЦВВ) и целевой точкой восстановления данных (ЦТВД)), анализа свидетельств (определения сценариев реализации инцидентов и выявления маркеров скрытого несанкционированного управления ОИИ, т. н. «бэкдоров»), и комплексный показатель эффективности реагирования и восстановления (оперативность выявления, своевременность и корректность предварительной оценки, эффективность взаимодействия с причастными сторонами), которые включаются в состав проектной и эксплуатационной документации.
Мониторинг и фиксация технических данных о событиях реализации информационных угроз выстраивается в соответствии с ГОСТ Р 57580.1 по принципу «эшелонированной обороны» в целях своевременного выявления компьютерных атак, аномальной активности сотрудников и поставщиков услуг, а также фактов утечки информации.
Реагирование на инциденты в отношении КА должно проводиться в соответствии с заблаговременно разработанным порядком реагирования, распределенными ролями (в т. ч. владельцев инцидентов), правилами и процедурами, сведенными в playbook; в рамках снижения СТП также должны быть проработаны варианты изоляции или отключения ОИИ (т. н. «управляемая деградация») и установление лимитов на финансовые операции при использовании каналов дистанционного обслуживания клиентов.
В процессах восстановления функционирования БП, ТП и ОИИ следует отметить два момента: первый — это заблаговременную проработку резервных (альтернативных) каналов предоставления финансовых и информационных услуг, второй — это обеспечение юридической значимости всех технических данных и свидетельств для последующего анализ причин возникновения инцидента.
И последним в данном разделе является проработка вопросов оповещения топ-менеджмента ФО, партнеров и клиентов, и предоставления отчетности регулятору.
4. «Взаимодействие с поставщиками услуг»
Основной комплекс работ по данному направлению включает в себя минимизацию компьютерных атак со стороны инфраструктуры поставщиков услуг путем: установления требований к обнаружению и предотвращению вторжений в сетях поставщиков; установление обязанностей поставщиков по прохождению аудита зрелости процессов обеспечения безопасности всей цепи поставок; проработка содержаний Соглашений об уровне оказания услуг (SLA), проработке основных и альтернативных поставщиков на случай возникновения у них кризисных ситуаций.
Также необходимо проработать вопросы технологической зависимости от поставщиков и их диверсификация. Сюда же можно отнести вопросы связанные с сопровождением и технической поддержкой ОИИ: включение данных положений в договоры (контракты); систематическое выявление ОИИ, ТП и выпуск обновлений которых прекращен их поставщиками, и по которым необходимо принять решение о продолжении или об отказе от эксплуатации и замене; контроль удаленной ТП и обслуживания;
5. «Тестирование ОН бизнес- и технологических процессов»
Немаловажны является тестирование разработанных мероприятий ОН, и тут наиболее важным является: определение возможных финансовых потерь, разработка программ по сценарному анализу и тестированию готовности организации, а также вовлечение в данный процесс топ-менеджмента организации; тестирование эффективности реагирование на ИОН в соответствии с ЦВВ; включение таких сценариев как социальная инженерия, фишинг и стресс-тестирование.
6. «Защита критичной архитектуры от угроз при организации удаленной работы»
Мероприятия последнего процесса хорошо знакомы всем организациям после пандемии 2020 года и заключаются: в разработке модуля Плана ОНиВД в части перевода сотрудников на удаленную работу из дома; планирование пропускной способности СЗИ, реализующих удаленный доступ; обеспечение и контроль мер по «Процессу 8» ГОСТ Р 57580.1.
Рекомендации, на что стоит обратить особое внимание
Исходя из анализа требований ГОСТ, оцениваемого объема работ по нему, его специфики (ИТ/ИБ, аутсорс), зависимости всех элементов КА и целого направления, связанного с управлением изменениями на основе системного (инженерного) подхода, при подведении итогов можно выделить следующие особенности:
- Многие меры ОН ГОСТ Р 57580.4 пересекаются с мерами ЗИ ГОСТ Р 57580.1, а в ряде случаев имеет место быть прямое указание, следовательно, необходимо проверить полноту и качество их выполнения в ФО.
- Необходимо пересмотреть стек, имеющихся в организации, ИТ-технологий и ИС на предмет обеспечения временных параметров пороговых уровней из 787-П и 779-П, и рассчитать по ним ряд целевых показателей (реагирования, восстановления, анализа свидетельств, ЦВВ, ЦТВД и т. п. ).
- Также можно отметить, что ключевые решения в отношении проработки альтернативных поставщиков ИТ-услуг и применяемых ОИИ, а также управлению санкционными рисками и рисками технологической зависимости ляжет на топ-менеджмент организации.
- Для кредитных организаций также необходимо учесть особенности обработки инцидентов ОН в составе «Базы событий» по 716-П, она должна быть дополнена уникальными полями.
- Стоит отметить, что эффективно управлять ОН в режиме «бумажной» документации крайне затруднительно. Организациям требуется заранее заложить подходы, позволяющие реализовывать процессы ОН в «электронном» виде в существующих корпоративных информационных системах, согласно 63-ФЗ «Об электронной подписи».
Формат статьи не дает нам возможность подробно разобрать вопросы, касающиеся выполнения требований ГОСТ 57580.4, поэтому мы разберем их на отдельном вебинаре.