Можно ли вернуть «Минимально жизнеспособный банк»?

Источник: Everpure Blog•

Можно ли вернуть «Минимально жизнеспособный банк»?

Можно ли вернуть «Минимально жизнеспособный банк»? из блога Everpure. Исследование IDC о том, почему банкам следует планировать кибервосстановление вокруг концепции «Минимально жизнеспособного банка». Статья «Можно ли вернуть «Минимально жизнеспособный банк»?» была впервые опубликована в блоге…

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

В новом аналитическом обзоре IDC, спонсируемом Everpure, «Operational Resilience in Banking: From Disaster Recovery to Minimum Viable Bank», утверждается, что планирование аварийного восстановления (DR) основывается на предположении, которое может быть разрушено кибератакой: о том, что существует чистая точка восстановления. IDC рекомендует вместо этого планировать работу вокруг концепции «Минимально жизнеспособного банка» (Minimum Viable Bank, MVB).

Для CISO это меняет две вещи. Банк заранее решает, какие услуги будут восстановлены в первую очередь и что означает «восстановлено» для каждой из них. Он также тестирует восстановление до момента, когда бизнес снова начнет функционировать — это более длительный и дорогостоящий тест, чем те, что проводят большинство организаций.

Почему банки тратят средства на восстановление

В рамках опроса IDC «Будущая устойчивость и расходы предприятий» (FERS) в декабре 2025 года 387 организаций финансового сектора спросили, что стимулирует их инвестиции в кибервосстановление в 2026 году. Почти 70% респондентов назвали текущее решение, которое недостаточно эффективно ограничивает убытки, своим основным или вторичным драйвером.

Требования по соблюдению нормативных актов и киберстрахованию стали одним из двух главных факторов для 53,3% опрошенных, а каждый четвертый заявил, что их основным драйвером стали убытки от успешной кибератаки за последние 12 месяцев. Меньшая доля (27,7%) назвала текущее решение, которое слишком сложно использовать, в качестве одного из двух главных факторов.

Резюме IDC: «Проблема не в осведомленности, а в архитектуре». Расходы отражают сомнения в том, что существующая архитектура восстановления может справиться с событиями, с которыми сейчас сталкиваются банки.

Проблема чистой точки восстановления

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

Атака с использованием программ-вымогателей или вайперов лишает этого контроля. Банк обычно узнает об этом после активации вредоносного ПО, не зная, когда начался взлом. Перед восстановлением команда должна определить, какая копия является чистой, приведет ли ее восстановление к повторному появлению угрозы и как долго после восстановления бизнес сможет безопасно работать. Ответы на эти вопросы означают знание границ заражения: когда злоумышленник проник внутрь, чего он коснулся и были ли повреждены резервные копии в период скрытого присутствия.

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

Что такое «Минимально жизнеспособный банк»?

IDC определяет «Минимально жизнеспособный банк» (MVB) как минимальный набор систем, потоков данных и операционных процессов, необходимых для поддержания критически важных банковских функций во время и сразу после разрушительного события. Критические функции включают платежи, расчеты, доступ к основным депозитам и регуляторную отчетность. Для большинства банков в этот список также входят средства контроля мошенничества.

Большинство банков рассматривают сокращенное рабочее состояние как сбой. IDC рассматривает его как цель: преднамеренная операционная позиция, разработанная заранее, которую банк может достичь и удерживать, пока продолжается полное восстановление. Без этого обязательства по целевой точке восстановления (RPO) и целевому времени восстановления (RTO) остаются «подвешенными» относительно неопределенной конечной точки, а решения по охвату принимаются под давлением инцидента.

Регуляторы движутся в том же направлении. DORA, действующий с января 2025 года, охватывает сбои в сфере ИКТ, выходящие далеко за рамки злонамеренных атак. Управление по пруденциальному регулированию (PRA) и Управление по финансовому регулированию (FCA) Великобритании, Денежно-кредитное управление Сингапура (MAS) и австралийские регуляторы APRA CPS 230 охватывают любые серьезные, но вероятные сбои. В США IDC указывает на руководство FFIEC, ожидания OCC и правила SEC по раскрытию информации об инцидентах.

WRT обычно занимает больше времени

RPO устанавливает допустимую потерю данных, а RTO — скорость возврата систем в работу. IDC добавляет время восстановления рабочих процессов (WRT) — интервал между моментом, когда система доступна, и моментом, когда бизнес начинает на ней работать. Это включает проверку целостности данных, сверку транзакций, восстановление зависимостей, очистку очередей исключений и возвращение персонала к работе.

IDC обнаружила, что WRT часто является более длительным интервалом. Основная банковская система, восстановленная за два часа, может потребовать еще от четырех до шести часов сверки, прежде чем обработка платежей сможет безопасно возобновиться. Расчетные системы нуждаются в последовательной проверке записей контрагентов, прежде чем им можно будет доверять. По словам IDC: «Таймер RTO останавливается, когда система возвращается в строй. Таймер WRT останавливается, когда бизнес возвращается в строй».

4 пробела, которые упускает тестирование восстановления

Тестирование восстановления может показать, можно ли восстановить системы, но оно не обязательно показывает, сможет ли банк возобновить критически важные операции — или сколько времени это займет. Часто на пути стоят четыре пробела:

  • Срок хранения должен превышать время скрытого присутствия.

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

  • Зависимости важнее бизнес-критичности.

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

  • Юридические и страховые процедуры требуют времени.

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

  • У WRT редко есть ответственный.

Восстановление инфраструктуры — это только часть процесса. Бизнес-команды все равно должны проверять данные, сверять транзакции и возвращать операции в рабочее состояние.

Выдержит ли план под давлением?

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

  • Можем ли мы определить проверенную чистую точку восстановления?
  • Можем ли мы восстановить критически важные услуги в правильной последовательности?
  • Можем ли мы доказать, что бизнес может снова функционировать после восстановления систем?

На эти вопросы стоит ответить до того, как инцидент заставит это сделать.

Частью этой задачи является обеспечение того, чтобы самой копии для восстановления можно было доверять и чтобы она была защищена от тех же скомпрометированных учетных данных, которые использовались при атаке.

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

Мерилом плана восстановления является то, сможет ли банк вернуть свой «Минимально жизнеспособный банк» из чистых данных в течение времени, которое примут клиенты и регуляторы.

Прочитайте аналитический обзор IDC

Для более глубокого изучения концепции «Минимально жизнеспособного банка», RPO, RTO, WRT и пробелов в восстановлении, которые необходимо устранить финансовым учреждениям, прочитайте полный аналитический обзор IDC «».

О чём эта статья

Ещё в разделе «Hardware и электроника»

Все →

Ещё от Pure Storage