- Руководителям ИБ
- Управление функцией ИБ
- Обеспечение ИБ
- Соответствие требованиям ИБ
- Руководителям бизнеса
- Трансформация ИБ в бизнес-функцию
- Пресс-центр
- Новости
- Мероприятия
- Пресс-кит
- Контакты
Тема подачи отчетности по операционной надежности в Банк России особенно актуальна для кредитных организаций. В I квартале 2024 года им предстоит впервые предоставить ее регулятору. В данной статье мы рассматриваем действующую нормативно-правовую базу в сфере операционной надежности, расскажем о структуре отчетности и нюансах ее заполнения, а также затронем процессы мониторинга, учета и управления критичной архитектурой, помогающие в короткие сроки и качественно формировать отчетность для Банка России.
Система нормативных требований
Ядро нормативно-правовой базы в сфере операционной надежности составляют Положения Банка России № 779-П и № 787-П. В первом установлены обязательные требования по операционной надежности для некредитных финансовых организаций, а во втором — для кредитных. С 1 февраля 2022 года введен ГОСТ Р57580.4-2022 «Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер», дополняющий эти нормативные документы Банка России.
В новом Стандарте применяется подход к организации управлением операционной надежностью через идентификацию, управление, работу с инцидентами, взаимодействие с поставщиками услуг. Также в ГОСТ Р57580.4-2022 приводится ряд процессов, которые должны быть внедрены, предусмотрены три уровня мер защиты (минимальный, стандартный, усиленный) в соответствии с нормативными актами Банка России. Несмотря на то, что стандарт пока не является обязательным, мы рекомендуем с ним ознакомиться, оценить свою готовность к внедрению приведенных в нем процессов в деятельность организации.
Далее следует целый ряд Указаний Банка России, посвященных вопросам подготовки и предоставления отчетности по операционной надежности: 6406-У для кредитных организаций, 6282-У для профессиональных участников рынка ценных бумаг, организаторов торговли и клиринговых организаций, 6243-У — для операторов инвестиционных платформ, операторов финансовых платформ, операторов информационных систем, в которых осуществляется выпуск цифровых финансовых активов, и операторов обмена цифровых финансовых активов и для других участников финансовой отрасли.
Также есть масса отдельных требований как по операционной надежности, так и просто по надежности информационных систем в смежных нормативно-правовых актах — федеральных законах и положениях Банка России. И поскольку таких нормативных документов очень много, мы рекомендуем идентифицировать те из них, которых содержат требования по надежности именно для вашей организации и выполнять их. Приведем несколько примеров из НПА различных уровней:
- Федеральный закон № 211-ФЗ «О совершении финансовых сделок с использованием финансовой платформы». Он регулирует отношения, возникающие в области оказания операторами финансовых платформ услуг, связанных с обеспечением возможности совершения финансовых сделок между потребителями финансовых услуг и финансовыми организациями или эмитентами. Для финансовых платформ (маркетплейсов) есть нормы, обязывающие включать требования по операционной надежности в правила финансовой платформы.
- Положение Банка России № 437-П «О деятельности по проведению организованных торгов», в рамках которого они должны внедрять специализированные резервные комплексы технических средств для своих торговых систем — по сути полноценные решения класса «Disaster recovery».
- Для клиринговых организаций в Положении Банка России «О порядке лицензирования бирж, торговых систем и клиринговых организаций...» говорится о необходимости при подаче заявления на получение лицензии предоставлять материалы, подтверждающие наличие программно-аппаратного комплекса по обеспечению непрерывности деятельности — т.е. подготовить своеобразное техническое описание реализуемых мер непрерывности.
Нюансы в заполнении отчетности
Рассмотрим структуру отчетности по операционной надежности на примере 6406-У для кредитных организаций. Она похожа на отчетность для некредитных финансовых организаций, фактически отличия заключаются в дополнительных разделах 11 и 12, где затрагиваются специфичные вопросы, связанные с платежными картами. Также можно отметить минимальные «косметические» отличия в порядке следования некоторых столбцов в таблицах.
В самом Указании Банка России достаточно подробно описана технология заполнения формы, поэтому мы в статье заострим внимание только на тех разделах и столбцах, которые вызывают наибольшее количество вопросов при заполнении, и на которые представители Банка России давали свои дополнительные разъяснения на различных площадках обсуждений.
В первом разделе необходимо привести расчетный показатель количества и продолжительности технологических процессов в планово-отчетный период в часах. Для этого учитываются все рабочие дни по календарю и, если договоры с клиентами предусматривают оказание им услуг в нерабочее время, включить эти часы тоже.
Далее необходимо описать технологические процессы, глубина детализации их описания определяется организацией самостоятельно. Для этого в форме отводится не более 1000 символов. Мы считаем, что это общая задача рабочей группы, объединяющая представителей бизнеса и представителей ИТ, ИБ и службы управления рисками, вместе они грамотно и лаконично опишут технологические процессы в организации и отразят их особенности.
Во второй раздел мы вставляем данные из тех форм внутренней нормативной документации, где определены целевые показатели операционной надежности: допустимая доля деградации наших процессов, допустимое время простоя и другие. Все показатели времени в этом разделе указываются в минутах, к которым должны быть применены правила математического округления. И если мы показываем какие-то дробные доли, например, процентов, то их тоже необходимо округлить до 6-го знака после запятой.
В третий раздел вносятся сведения об объектах информационной инфраструктуры, участвующих во взаимодействии с клиентами и контрагентами и имеющих внешние IP-адреса. К ним относится граничное сетевое оборудование любого вида: например, шлюзы безопасности, граничные шлюзы, криптошлюзы и т.п.
Банк России в своих разъяснениях анонсировал, что в будущем состав параметров, которые необходимо указывать для такого рода оборудования, будет детализирован. Через некоторое время регулятору потребуется информация о производителе, марке оборудования, его версии и, соответственно, определенных характеристиках.
Кроме того, согласно другим разъяснениям Банка России, в этом же разделе можно отмечать системы ДБО («веб-клиент»).
В пятый раздел вносятся сведения о веб-сервисах финансовой организации, имеющих доменные имена. Это могут быть личные кабинеты, различные порталы, сайты, информационные системы, которые участвуют в оказании финансовых услуг. Здесь указывается доменное имя и его IP-адрес.
В седьмом разделе дается подробное описание информационной инфраструктуры, участвующей в технологических процессах. Здесь могут повторяются те сведения, которые приводились в третьем разделе. Степень детализации описания в отчетности пока Банком России не определена, поэтому каждая организация может выбрать ее сама. Мы рекомендуем декомпозировать объекты информационной инфраструктуры и подробно их прописывать вплоть до конкретных единиц оборудования. Но никто не запрещает укрупнить некоторые системы.
Надо ли указывать в этом разделе виртуальные рабочие места, VDI? Банк России в своих комментариях по этому вопросу ответил, что они не указываются.
В десятый раздел вносятся сведения об объектах информационной инфраструктуры, которые нам предоставляет поставщик облачных услуг. Банк России допускает, что организация может не иметь сведений о том оборудовании, которое участвует в технологических процессах, и находится у поставщика облачных услуг. Но если такие сведения имеются, то в этом разделе можно их привести. Многие ЦОДы делают выписки из своих технических паспортов, из моделей угроз, и оттуда можно почерпнуть информацию о том, какие вычислительные средства и какое сетевое оборудование в них используются.
Также в десятом разделе указываются облачные решения резервной инфраструктуры и данные о приложениях по модели SaaS, которые применяются в финансовой организации.
Если мы арендуем пул ресурсов у облачного провайдера и сами на нем разворачиваем виртуальную машину, то она указывается в отчетности в категории «информационная инфраструктура». А готовая виртуальная машина от поставщика облачных услуг относится к категории «вычисления».
Также если мы арендуем инфраструктуру, например, стойку с оборудованием по схеме co-location, то мы тоже указываем категорию «информационная инфраструктура».
Разделы одиннадцатый и двенадцатый заполняют только организации финансовой отрасли, являющиеся прямыми участниками платежных систем, «иные кредитные организации». Все остальные ставят в этих разделах только специальную отметку о том, что не являются прямыми участниками платежной системы.
При изменении в сведениях из одиннадцатого и двенадцатого разделов кредитные организации обязаны в 5-дневный срок подать новую информацию в Банк России по той же форме отчетности, не заполняя разделы с 1 по 10. В случае, если сведения за отчетный период не изменялись, Банк России разрешает ставить определенную отметку о том, что сведения соответствуют актуальным сведениям на предыдущий период, и заново их не вносить.
Мониторинг
Для своевременной подачи актуальной и качественной отчетности важно иметь возможность отслеживать показатели операционной надежности технологических процессов, а также иметь актуальные данные о критичной архитектуре.
Так что первый процесс, о котором мы будем говорить, — мониторинг показателей операционной надежности. Этот комплексный процесс предполагает сбор, обработку, агрегирование и отображение количественных показателей в масштабе времени, близком к реальному, и представляет собой совокупность технических и организационных мер.
Говоря про техническую сторону, нужно отметить, что для мониторинга состояния всех объектов ИТ-инфраструктуры и информационных систем, задействованных в технологически процесах, используется как правило несколько видов мер.
Логирование
Для выделения в структурированном или неструктурированном виде тех событий, которые происходят в информационных системах, с оборудованием логирование необходимо. По результатам анализа логов составляются определенные метрики, назначаются граничные параметры. Обычно для анализа логов используются нативные возможности общесистемного ПО либо серверного оборудования. Для прикладного ПО можно использовать наложенные средства либо архитектурные элементы. Часто для этой цели используются готовые компоненты и программные модули, к примеру, Elastic Stack.
Трейсинг
Отследить, как циркулируют запросы в приложении между микросервисами, нет ли каких-то узких мест, и сигнализировать о том, что требуется какое-то вмешательство инженера, помогает трейсинг. Ведется он с помощью таких инструментов, как Jaeger, Zipkin.
Аллертинг
Оповещение настраивается из значений тех метрик, которые собираются по каким-то граничным или трендовым значениям. Он позволяет сигнализировать административному персоналу, инженерам техподдержки о том, что у нас надвигается аварийная ситуация или что она уже возникла.
Сам непосредственный мониторинг выполняется либо методами черного ящика, либо белого ящика. В первом случае оказывается какое-то внешнее воздействие (это могут быть, к примеру, простейшие сетевые пробы, ping) на нашу систему или на приложения. Во втором — снимается ряд метрик с оборудования, с приложения (метрики утилизации ресурсов CPU, RAM, приложений, их производительность, бизнес метрики — кол-во посетителей, динамика операций).
Примером самых распространенных метрик может служить подход «4 golden signals», позволяющие довольно точно охарактеризовать состояние ИТ-систем и приложений. Это:
- задержка (latency) или время выполнения HTTP запроса, в зависимости от приложения;
- объем трафика (traffic) или какой-то объем нагрузки, который приложение обрабатывает прямо сейчас (обычно это RPS);
- частота ошибок (errors) или количество ошибок. Это могут быть некорректные коды ответа, исключения в приложении и т.д.;
- загруженность или насыщенность (saturation). Эта метрика помогает отвечать на вопрос, на сколько загружено наше приложение или инфраструктура. Допустим оно обрабатывает 150 запросов в секунду, а можем ли мы обработать 200 или 250 или мы уже загружены под 100% и больше не получится? Отметим, что многие приложения и системы сильно деградируют еще до того, как saturation достиг 100%.
Здесь золотым стандартом у ИТ-специалистов стало сочетание инструментов Prometheus и Grafana.
В зависимости от возможностей финансовой организации, можно внедрить инженерные практики, например, формирования смен дежурных инженеров в режиме «24 на 7». Организации, не обладающие такими ресурсами, могут создать дежурные смены из младших технических специалистов в ночное время, с возможностью вызова специалистов во внерабочее время для консультаций или аварийного восстановления систем.
Для того, чтобы вовремя подавать сведения в Банк России, мы рекомендуем осуществлять мониторинг как технической составляющей своей инфраструктуры, о которой мы говорили выше, так и бизнес-составляющей.
Организационные меры сводятся к регламентации действий по анализу статистических данных и показателей по деятельности финорганизации за период (кол-во посетителей, кол-во заключенных Договоров, и т.п.), а также распределению ролей между сотрудниками по анализу, мониторингу и реагированию.
Учет и управление критичной архитектурой
Управление критичной архитектурой, ее идентификация, ее поддержание в актуальном состоянии, применение классификационных меток помогает довольно быстро реагировать на запросы Банка России и ФинЦЕРТ, формировать отчетность так, чтобы долго не требовалась ее актуализация, а также реагировать согласно СТО БР 1.5-2023. Мы рекомендуем внедрять эти процессы в цифровом виде. Особенно это важно для средних и крупных организаций.
Такие компании могут вести карточки активов (рис.1) в системах класса «SGRC» об идентифицированных объектах критичной архитектуры, вносить в них богатую атрибутивную информацию о классификационных метках, статусах жизненного цикла, сведения об SLA и Договорах, а также сведения об амортизации, инвентаризационные данные и данные о владельцах и администраторах активов.
Рисунок 1. Пример карточки актива
Критичные активы важно классифицировать (рис.2), в нормативных документах ЦБ РФ и ГОСТ 57580.4 этому вопросу уделено довольно много внимания. Разработав классификатор, вы сможете помогут строить выборки по активам в различных разрезах. В будущем это поможет ускорить процессы взаимодействия с ФинЦЕРТ при возникновении инцидентов.
Рисунок 2. Пример классификации критичных активов
Не менее важно поддерживать данные об активах в актуальном состоянии. Должна быть одна система «источник правды», например, «SGRC» в которой хранятся данные об изменениях, история изменений (рис.3).
Рисунок 3. Пример учета данных об изменениях
Выводы
Формирование отчетности — это задача кроссфункциональная, в решении которой участвуют команды от бизнеса, ИТ и ИБ. Также в этом могут помочь служба внутреннего аудита и, служба рисков.
Необходимо идентифицировать и постоянно держать на контроле те требования операционной надежности, которые применяются к вашей организации, и при необходимости, оперативно предоставить свидетельства их выполнения.
Система мониторинга сложных приложений для финансовой отрасли — это, по сути, индивидуальное проектное инженерно-техническое решение, и мы рекомендуем основательно подойти к его построению и к выбору тех компонентов, из которых оно будет собираться.
Мы настоятельно рекомендуем оценить объемы работ по внедрению ГОСТ Р 57580.4, распределить приблизительно роли будущих участников этих процессов и потихоньку приступить к их внедрению.
Читать статью на сайте издания «Внутренний контроль в кредитной организации»
ваша подписка
оформлена. Назад
к нам. В ближайшее время
мы с вами свяжемся. Назад
Мы будем оповещать вас
о встречах дискуссионного клуба. Назад
на дегустационную
консультацию