Проверка по 716-П. Разберитесь в себе или Как оказаться «на коне», если кажется, что «конь не валялся»?

Проверка по 716-П. Разберитесь в себе или Как оказаться «на коне», если кажется, что «конь не валялся»?

Любая проверка, кем бы и с какой целью она ни проводилась – подразделением внутреннего контроля, внешним контрагентом-аудитором или регулятором, – это всегда возможность посмотреть на инфраструктуру организации под другим углом, обнаружить что-то, что не было заметно «изнутри», причём не всегда это будут только недоработки и несоответствия.

Объективная проверка, какой бы результат она ни показала, –это предупреждение. А предупреждён – значит вооружён. Гораздо лучше, если уязвимость (а по сути, невыполнение регуляторного требования – это слабость защиты, открывающая существующую или создающая новую уязвимость) обнаружит проверяющий, а не злоумышленник. Ну как регулятор накажет? Предписание со сроком устранения даст, штраф по статьям 13.12 и 19.5 КоАП Российской Федерации, возможно, выплатить придётся, но это ни в какое сравнение с ущербом от успешной атаки или мошенничества не идёт. Если вовремя выявили и успели устранить, или даже не успели, но повысили бдительность и стали зорче следить за «слабым местом» – можно считать, повезло.

Так, главным критерием успешности прохождения проверки становится её объективность. А объективность не любит ошибок ни первого, ни второго рода. Иными словами, если что-то делается согласно требованиям, то выявить и корректно оценить это не менее важно, чем то же самое в отношении проблем и несоответствий.

Что проверяем

Соответствие Положению Банка России от 08.04.2020 № 716-П «О требованиях к системе управления операционным риском в кредитной организации и банковской группе» в части риска информационной безопасности (далее – ИБ).

Идём от общего к частному

Деятельность по управлению рисками ИБ, как правило, строится в рамках установленной методологии управления операционным риском с отражением необходимой специфики ИБ в отдельных нормативных актах. А с операционными рисками работа наверняка ведётся. Это значит, по умолчанию всё, что в организации регламентировано для операционных рисков, верно и для рисков ИБ. Если в каком-нибудь локальном нормативном акте организации в явном виде зафиксировано, что риск ИБ – вид операционного риска, ещё лучше.

Ищем свидетельства применения риск-ориентированного подхода в повседневной деятельности

Деятельность по управлению рисками ИБ подразумевает защиту информационных ресурсов и активов и связанных с их использованием бизнес-процессов, обеспечение способности организации производить продукт или предоставлять услугу, а также защиту активов, участвующих в обеспечении функционирования информационных технологий (вычислительных и телекоммуникационных активов, работников и пр.). Если проводится работа по выявлению новых угроз и уязвимостей ИБ (хотя бы регулярно проглядывается база угроз безопасности ФСТЭК России и рассылки Центрального Банка), анализ адекватности и эффективности применяемого комплекса мер защиты клиентов (хотя бы в рамках мозгового штурма в рамках agile-команды), оценивается соотношение возможных потерь в результате реализации какой-то угрозы и затрат на защиту (хотя бы качественная, не количественная экспертная оценка), это оно и есть. Идентификация рисков происходит, как правило, в результате SWOT-анализа, HAZOP-анализа, сценарного анализа, планирования непрерывности бизнеса, анализа бизнес-процессов, анализа результатов проверки и аудита ИБ, расследования событий и инцидентов защиты информации (далее – ЗИ).

А попытка подумать над вопросом руководства «а что у нас будет, если случится как у конкурента такого-то» – это хоть и примитивный, но сценарный анализ рисков. Если свидетельства проработки этих вопросов письменные – отлично, переписка в электронной почте – хорошо. На худой конец и интервью – источник свидетельств проверки. Но в любом случае это означает, что в организации есть практика управления рисками ИБ, которая, возможно, нуждается в большей формализации и систематизации.

Короткий чек-лист деятельности в рамках управления риском ИБ

Установление политики в отношении управления рисками ИБ: за счёт методологии управления операционным риском.

Выявление и идентификация рисков ИБ, оценка остаточных рисков ИБ: даже если этими словами не называется, явно проводится, когда планируется внедрение той или иной защитной меры/средства. Мы же всегда хотим знать, полностью ли проблема решится, если мы что-то там внедрим. Это «полностью ли?» и есть оценка остаточных рисков.

Планирование системы мер, направленных на снижение рисков ИБ: все применяемые меры – это защита от чего-то, в основном того, что ещё не случилось, но может, а не хотелось бы.

Реагирование на риски и инциденты ИБ, в том числе формирование и поддержание в актуальном состоянии комплекса мер и средств защиты в соответствии с принятой политикой обеспечения ЗИ: собственно наличие мер и средств защиты – это и есть реакция на риски. В случае если просто выполняется базовый набор требований регулятора, например, ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый набор организационных и технических мер», подразумевается, что какие-то типовые риски за организацию уже оценил регулятор.

Мониторинг и выявление событий риска ИБ: вспоминаем, например, отчётную форму 0403203 по Положению Банка России от 09.06.2012 № 382-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств».

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

Мониторинг рисков ИБ и анализ соответствия фактических значений контрольных показателей уровня риска ИБ принятым значениям: даже если не установлен официально риск-аппетит организации, неформально градация допустимые/недопустимые потери, «N таких инцидентов в месяц – это уже много» наверняка применяется.

Ищем примеры применения различных способов обработки риска ИБ

Короткий чек-лист вариантов обработки рисков ИБ (реагирования):

• принятие мер минимизации: меры ЗИ, направленные на уменьшение негативного влияния риска ИБ на качество процессов, величину потерь;
• сознательное и объективное принятие рисков ИБ с одновременной подготовкой ресурсов для покрытия ущерба, который может быть понесён в результате реализации принятых рисков: предполагает готовность принять возможные потери в рамках установленного лимита потерь с процедурой контроля соблюдения лимита;
• уклонение от риска ИБ (избежание): отказ от информационной технологии (средства обработки информации), от предоставления соответствующих продуктов и услуг в связи с высоким уровнем риска ИБ; используется, если реализация мер по минимизации риска ИБ не является экономически обоснованной;
• передача риска ИБ: страхование рисков ИБ, передача риска другой стороне – контрагенту и/или клиенту; используется в случае невозможности или нецелесообразности самостоятельного управления риском ИБ самой организацией.

Выделяем других участников процесса управления рисками ИБ объектов информационной инфраструктуры

Анализ и оценка рисков ИБ в отношении отдельных объектов защиты может выполняться только совместно всеми заинтересованными подразделениями. В число указанных подразделений входят:

• подразделение ИБ;
• подразделение, осуществлявшее (самостоятельно или с привлечением сторонних организаций) автоматизацию процесса и(или) внедрение соответствующего объекта защиты (далее – подразделение ИТ);
• подразделение, являющееся заказчиком и (или) владельцем соответствующих объекту защиты ресурсов (далее – подразделение заказчик/владелец);
• подразделение-пользователь, эксплуатирующее объект защиты (если отличается от перечисленных выше).

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

… И таким образом «натягиваем» себе оценку?

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