Цепляйтесь к словам и называйте вещи своими именами

Цепляйтесь к словам и называйте вещи своими именами

Почему корректная терминология – залог эффективной реализации процессов обеспечения операционной надёжности.

23 августа стартовали публичные обсуждения проекта положения Банка России «Об обязательных для кредитных организаций требованиях к операционной надёжности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг» (далее – Положение). Документ устанавливает обязательные для кредитных организаций требования к операционной надёжности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг. Планируется, что Положение вступит в силу в октябре 2022 года.

Под операционной надёжностью в проекте Положения понимается способность кредитной организации (далее – КО) обеспечить непрерывность функционирования критически важных процессов <…> в случае возникновения отказов и (или) нарушений функционирования применяемых КО информационных, технологических и других систем, оборудования и (или) несоответствия их функциональных возможностей и характеристик потребностям КО и (или) реализации киберриска в значении, установленном в пункте 7.2 Положения Банка России № 716-Пот 08.04.2020 «о требованиях к системе управления операционным риском в кредитной организации и банковской группе» (далее – Положение Банка России № 716-П).

Интересно, что параллельно Банком России в рамках деятельности ТК122 разрабатывается проект ГОСТ Р «Безопасность финансовых (банковских) операций. Обеспечение операционной надёжности. Базовый состав организационных и технических мер», в котором до последнего времени операционная надёжность была определена как «должная реализация процессов обеспечения операционной надёжности в условиях возможной реализации информационных угроз», а по плану выход данного документа планировался на IV квартал 2021 года.

Похоже, что выставленный на обсуждение проект Положения мы видим далеко не в окончательной редакции, некоторые формулировки однозначно требуют уточнения.

Например, ссылка из пункта 7 (буллит 4) Положения на пункт 7.5 Положения Банка России № 716-П дана, чтобы определить, что именно следует понимать под службой информационной безопасности (подразделение/работник, ответственные за организацию и контроль обеспечения защиты информации) или что должно включать в себя взаимодействие службы информационной безопасности, функционирующей в оперативном режиме работы, с Банком России (но об этом в п. 7.5 Положения Банка России № 716-П ничего нет).

Гораздо интереснее (и важнее) разобраться с терминологической развилкой «инцидент – событие риска».

Понятие «инцидент» до масштабного внедрения риск-ориентированного подхода в деятельность КО было хоть и заимствованным из международных стандартов, но интуитивно понятным, означавшим «беда». Оно явно призывало принять срочно хоть какие-то меры (что на начальном этапе зрелости процессов уже неплохо), но никак не помогало прояснить, кому надо принимать меры и на что они должны быть направлены. Мы все помним разъясняющую блок-схему «угрозы используют уязвимости…», в которую ещё как-то следовало вписать нарушителя (он помогал угрозе реализоваться), не антропогенные движущие факторы (приводящие к реализации угроз различных стихийных бедствий и прочих катастроф), а также события (которые ещё не инциденты, но могут ими стать по результатам соответствующего анализа). Разобраться с источниками событий/инцидентов/угроз, а значит, и с зонами ответственности за их устранение было сложно, сделать чёткий классификатор событий и отделённых от них инцидентов – ещё сложнее. И многие в это просто не углублялись, действуя в каждом конкретном случае с организационной точки зрения во многом стихийно.

В современных реалиях подобная тактика решения проблем стала ненадёжна и расточительна в плане ресурсов. В соответствие пришли и регуляторные подходы, управление риском гораздо более структурировано, в нём разделение ответственности прозрачно.

Положение Банка России №716-П (пункт 1.4) вводит и чётко разделяет понятия риска информационных систем (далее – ИС) и риска информационной безопасности (далее – ИБ). Один и тот же источник риска может дать начало событиям обоих типов. Но зоны ответственности подразделений КО при этом не смешиваются, поскольку привязываются к типу события, «завязанному» на категории актива, несущему потери, получающему ущерб, а у каждого актива есть владелец, ответственное за его использование и функционирование лицо/подразделение КО, провести «водораздел», даже с учётом специфики оргштатной структуры каждой конкретной КО, гораздо легче.

В проекте Положения терминологию, в частности, по указанным выше причинам целесообразно гармонизировать с Положением Банка России № 716-П как с основополагающим документом. Это означает, что вместо понятия «инциденты операционной надёжности»(согласно п. 3 проекта Положения те инциденты, которые привели к неоказанию или ненадлежащему оказанию банковских услуг (в случае превышения допустимой доли деградации технологических процессов) надо будет использовать термин «события риска ИС». Не будет никакой путаницы с инцидентами ИБ (в Положении Банка России №716-П – события риска ИБ, РС ИБ), не будет «перетягивания каната» по вопросу ответственности за реализацию требований проекта Положения между подразделениями ИТ и ИБ КО. 

Но и с текущей редакцией проекта следует принимать во внимание тот факт, что обеспечение операционной надёжности существенным образом связано с обеспечением непрерывности деятельности КО и её восстановлением после возможных прерываний. При этом на обеспечение операционной надёжности значительное влияние оказывают проектирование, реализация и управление критичными активами в соответствии с установленными показателями операционной надёжности, в том числе разработка и (или) применение отказоустойчивых решений, а это практически всегда зона ответственности подразделения информационных технологий КО.

Безусловно, участие подразделения ИБ КО в процессах обеспечения операционной надёжности есть, в том же объёме и того же характера, что и в процессах автоматизации, процессах обеспечения непрерывности и восстановления деятельности КО, в которых вроде бы зоны ответственности подразделений давно уже должны быть поделены.

Из описанного в текущей версии проекта Положения к деятельности подразделения ИБ в общем случае можно отнести задачи:

• доводить до сведения подразделения, ответственного за управление событиями операционного риска (к которому относится и риск ИБ) КО, информацию о специфике (при её наличии) методологии выявления и обработки РС ИБ, выявляемых подразделением ИБКО (п. 5 буллит 4 проекта Положения);
• поддерживать в актуальном состоянии нормативно-методическое обеспечение процессов управления правами доступа к ИС КО, модель нарушителя ИБ КО, контролировать доступ работников контрагентов и иных сторонних организаций к информационно-телекоммуникационной среде КО, соблюдение требований ИБ к передаче конфиденциальной информации третьим лицам по телекоммуникационным каналам связи (п. 5 буллиты 5, 7, п. 5.6, п. 6проекта Положения);
• поддерживать взаимодействие с ФинЦерт Банка России, представлять интересы КО в профильных объединениях по ИБ, поддерживать в актуальном состоянии политику ИБ КО и комплекс нормативных актов КО, описывающих её требования (п. 5 буллит 8 проекта Положения);
• проводить экспертизу поступающих на согласование в подразделение ИБ-решений по информатизации на предмет их соответствия политике ИБКО, требованиям законодательства и уполномоченных регуляторов в области ИБ, идентификации присущих указанным решениям рисков ИБ (п. 5 буллит 7, п. 5.1 буллиты 4, 8, п. 5.6, п. 5.7, п. 6, п. 7 буллит 1 проекта Положения);
• принимать участие в процессе согласования предоставления прав доступа к ИС КО (п. 5.1 буллит 6 проекта Положения), осуществлять аудит прав доступа к ИС КО (п. 5.6 проекта Положения);
• принимать участие в процессе управления уязвимостями ИС и информационной инфраструктуры КО в части выявления уязвимостей ИБ и согласования решений по их устранению в установленном в КО порядке (п. 5.2 буллиты 1, 4 проекта Положения);
• принимать участие в согласовании договоров КО с контрагентами, если участие подразделения ИБ в процессе согласования договора предусмотрено нормативными актами КО (п. 5.4 проекта Положения);
• принимать участие в сценарном анализе рисков ИБ в зоне компетенции подразделения ИБ по запросу подразделения, ответственного за управление событиями операционного риска (к которому относится и риск ИБ) КО, в установленном в КО порядке (п. 5.5, п. 7 буллит 2, 3 проекта Положения);
• осуществлять мониторинг, выявление и управление обработкой РС ИБ в зоне ответственности подразделения ИБ КО (п. 7 буллит 1 проекта Положения);
• принимать участие в проверках со стороны подразделения внутреннего контроля КО, выполнять поручения в адрес подразделения ИБ КО, выданные по результатам данных проверок (п. 7 буллит 3 проекта Положения).

И вряд ли в долгосрочной перспективе, не сиюминутно, кто-то выиграет от того, что ответственность за формальное соответствие документам, регулирующим фундаментальные требования по реализации критичных для КО процессов и задач, в силу большой нагрузки, нехватки ресурсов или любых других объективных причин будут пытаться перекладывать на непрофильные подразделения, вопреки функциям этих подразделений, духу регуляторных установок и здравому смыслу.