Думаю, многие уже слышали про такую концепцию как «результативная кибербезопасность», суть которой можно кратко изложить в следующих тезисах:
- Кибербезопасность давно стала бизнес-задачей и топ-менеджмент должен быть вовлечен в ее решение.
- Топ-менеджмент не будет погружаться во все глубины, привычные ИБшникам, и заниматься оценкой угроз, атак, рисков ИБ, которые незначимы в глазах любого руководителя и не наносят никакого значимого ущерба организации.
- Для описания событий, влекущих неприемлемые последствия для бизнеса, не надо использовать старые термины «угроза» и «риск ИБ». Лучше использовать новый термин, такой как «недопустимое событие», которое определяется не специалистами по ИБ, а самим бизнесом, и им же и утверждается. Таких событий не может быть много.
- Недопустимые события «приземляются» на ИТ-инфраструктуру компании за счет выделения ключевых и целевых систем, воздействие на которые и приводит к недопустимым событиям. Также определяются сценарии реализации недопустимых событий в ИТ-инфраструктуре.
- Выстраивается система защиты (это уже традиционная ИБ-история) против указанных сценариев, либо предотвращающая их реализацию (харденинг ИТ-инфраструктуры и уменьшение площади атаки), либо реагирующая (построение SOC) на них.
- Руководство получает подтверждение, что недопустимые события не могут быть реализованы за счет вывода компании на bug bounty 2.0, в рамках которой оценивается наличие не отдельных уязвимостей, а возможности или невозможности реализации того, что может привести к нанесению ранее определенного катастрофического ущерба, который для данной организации недопустим.
Рассказывая эту концепцию на разных мероприятиях я нередко слышу, что «опять Позитив что-то свое придумал». Так вот хочу сказать, что развитие традиционной ИБ в сторону результативной подсказывает не только здравый смысл. Этот же подход сегодня применяется и в других странах, например, в Великобритании.
Управление по финансовому регулированию и надзору (FCA), в 2021-м году выпустило и в 2022-м году обновило документ, по названию которого может сложиться впечатление, что оно никакого отношения к ИБ не имеет, а касается темы операционной надежности, которая ближе к непрерывности бизнеса, восстановлению после катастроф и тому подобной ИТ-шной тематике.Департамент ИБ Банка России, выпуская свои положения и ГОСТы по операционной надежности, ровно этот смысл туда и закладывал. Ну или еще какой-то, — там все так наворочено и непонятно, что и сами авторы не могут нормально объяснить, что же они хотят от финансового рынка России.
А вот англичане смысл вкладывали совсем иной. Понимая, что традиционные подходы к построению защитных мер не дают эффекта (а я напомню, что именно Туманный Альбион был родиной для стандарта BS7799 из которого родилась вся серсия ISO 27ххх), подданые Его Величества подняли проблему выше уровня, на котором ее решить оказалось невозможно, — на уровень руководства компаний.
Они потребовали от него вовлекаться в разработку и согласовывать стратегию ИБ, которая должна была отвечать на следующие вопросы:
- Какие сервисы критичны для бизнеса (Important Business Service)? Они представляют собой важные сервисы, предоставляемые клиентам, которые, в случае прерывания или иного нарушения, могут привести к ущербу для клиентов, финансовой системы Великобритании или повлиять на работу финансовых рынков. Эти сервисы позволяют обеспечивать минимально возможное функционирование компании и они должны быть защищены в первую очередь.
- Каков уровень допустимого ущерба для каждого критического бизнес-сервиса? Недопустимые события могут быть определены согласно как бинарной логике (например, отзыв лицензии у финансовой организации), так и на базе пороговых значений (например, время недоступности ИТ-актива или сервиса или сумма похищенных денежных средств). Превышение определенного топ-менеджментом уровня приводит к нежизнеспособности критического бизнес-сервиса.
- Какие компоненты (сервера, базы данных, приложения, сетевое оборудование и т.п.) обеспечивают каждый сервис? Выделяются критические системы, которые должны обеспечивать минимальный уровень жизнеспособности критического бизнес-сервиса. Также должны быть выделены сценарии, могущие привести к достижению уровня допустимого ущерба.
- Каков уровень инвестиций позволит обеспечить функционирование организации на минимальном уровне жизнеспособности критического бизнес-сервиса?
- Какие уязвимые места существуют в обеспечении операционной устойчивости организации? Речь идет не о классических уязвимостях в программном или аппаратном обеспечении, конфигурациях или архитектуре, а о слабостях, приводящих к реализации недопустимого ущерба в соответствии с заданным его уровнем.
- Как проверяется способность противостоять реализации недопустимых для бизнеса событий? Иными словами, как проводятся киберучения, демонстрирующие возможность организации восстанавливаться в случае попытки реализации недопустимых событий и достигать как можно быстрее хотя бы минимального уровня жизнеспособности критического бизнес-сервиса.
- Как будет сообщено заинтересованным лицам в случае нарушения функционирования критических бизнес-сервисов?
Чтобы вы не думали, что я это все придумал, вот вам фрагмент с сайта регулятора, который говорит, что обязаны сделать организации, на которых распространяются эти требования:
Одно отличие — у нас используется термин «недопустимые события», а у англичан «допустимый ущерб«. Суть одна, но у нас у этого термина негативная коннотация, а в Великобритании пытаются придать ей позитивную окраску.
Самое интересное, что требования по результативной кибербезопасности операционной надежности англичане разрабатывали в тесном контакте с теми, на кого эти требования будут распространяться. Сначала Служба по финансовому контролю и надзору вместе с Банком Англии и Службой по пруденциальному контролю и надзору разработали проект требований и разослали его по всем «подопечным», попросив обратную связь. А уже потом выпустили финальный документ. При этом все комментарии были также опубликованы.
Кроме того, английские регуляторы давали комментарии и пояснения к каждому требованию. Например, они описали возможные критические бизнес-сервисы и виды допустимого ущерба, да еще и увязали это с различными сценариями реализации недопустимых событий, ой, допустимого ущерба.
Также были опубликованы расчеты стоимостного анализа от принимаемых мер, например:
Всегда удивлялся, почему зарубежные регуляторы могут нормально оформлять свои документы, а наши ссылаются на «Минюст не пропустит». Есть у меня возможное объяснение этому, но это уже выходит за рамки статьи. В конце концов, никто не мешает выпускать разъясняющие методички, которые не надо согласовывать с Минюстом, и там уже нормально все объяснять и визуализировать. И нагрузка на регулятора была бы меньше — никто бы не писал «что за херню вы тут придумали» и не надо было бы писать сотни ответов на одни и те же вопросы и потом путаться в показаниях, почему у служащего Иванова и служащего Петрова из одного подразделения на один и тот же вопрос ответы отличаются, а иногда и вовсе по смыслу противоположны.
Все описанные требования должны быть реализованы у англичан до 31 марта 2025 года!
Описанный подход целиком и полностью повторяет то, что Positive Technologies называет «результативной кибербезопасностью» и что пыталось реализовать в своих документах Минцифры. В менеджменте, да и не только, есть правило:
Если ты не достигаешь нужного результата — нужно менять действия. Делая все тоже самое, ты будешь получать те же результаты, что и раньше. Если тебе важно получить новый результат — измени отношение и делай по-другому!
Если уже не получается бороться с киберугрозами привычными методами, не надо пытаться повторять их из раза в раз, пытаться выстраивать из тех же самых защитных мер новые комбинации. Это не сильно поможет — только выход за границы, в которых проблема возникла, можно решить ее. Тут нобелевский лауреат Альберт Эйнштейн был прав! Почему бы не последовать его совету?
Заметка
Как англичане переходили на недопустимые события или как Эйнштейн связан с ИБ? была впервые опубликована на Бизнес без опасности .
