Что нужно и чего не нужно хотеть от ИБ

В основе Positive Technologies лежит фундаментальная стратегия — заказчики наших продуктов и сервисов должны получать понятный результат. А в чем он заключается? Рынок ИБ может предложить в качестве результата множество вариантов: соответствие требованиям регуляторов, зрелость, расчетные параметры, KPI, лучшие практики. Но гарантирует ли это защищенность компании? Некоторые организации, в которых реализованы такие подходы, приходили в Positive Technologies за пентестами, и в большинстве случаев наши хакеры достигали своих целей.

Осознавая несовершенство мира реалий рынка кибербезопасности, мы загорелись идеей: понять, что правильно подразумевать под словом «результат». Очевидный бенчмарк — невозможность взломать компанию. Но что значит «взломать»? Пробить периметр, как его ни защищай, можно всегда: 0-day никто не отменял, как, впрочем, и социалочку. Окей, тогда какую глубину погружения злоумышленника в инфраструктуру можно считать допустимой? Хакерам какой квалификации может быть интересна компания (нет смысла строить защиту от спецслужб иностранных государств, если мы торгуем бананами)? Насколько долго они могут оставаться незамеченными? Эти размышления привели нас к пониманию: наличие хакера в периметре — это неизбежность, гораздо важнее, чтобы он не смог нанести ощутимый ущерб. А насколько ощутимый? С этим вопросом мы обратились к нескольким CISO и обнаружили, что однозначного ответа нет… При этом главный инсайт заключался в том, что бизнес все еще воспринимает безопасность, как очередную бэк-функцию, которая подчиняется принципам «no surprises — главное, чтобы плохие новости не приносили» (Миша Толчельников ©) и «у всех есть ИБ, пусть и у нас будет».

Что точно не должно случиться

Естественно, во время описанных выше изысканий мы думали не только о великом, но и о собственной прибыли. Исторически CISO клиентов формировали бюджеты по принципу «нужно составить достаточно убедительную ИБ-стратегию, чтобы получить финансирование». При этом они пытались защищаться от всего и сразу, потому что в нашей, пока не до конца сформированной киберкультуре пока нет четкого осознания, что безопасность — это процесс (читай: абсолютной безопасности не бывает). Как результат — негативные новости могут стать причиной суровых санкций для CISO, даже если инцидент произошел в границах приемлемого ущерба. Само собой, все совпадения случайны ;)

Ответ на наши изыскания мы нашли у топ-менеджмента. Оказалось, бизнесу гораздо ближе целеполагание в формате «что точно не должно случиться». Значит, требуется найти материю, которая объединит представление бизнеса «на что стоит тратить» и наше понимание результата. Этой материей стали недопустимые события (НС). Соответственно, результат, которого правильно ждать от ИБ, — невозможность реализации недопустимых событий.

Результативная кибербезопасность

Отталкиваясь от недопустимых событий, мы начали разрабатывать концепцию результативной кибербезопасности. Результатом дальнейших исследований, пролитой крови совершенных ошибок и, безусловно, успехов стал полноценный фреймворк, состоящий из трех доменов (см. рис. 2).

В этапности и результатах «Целеполагания» как раз и кроется ответ на вопрос «Что нужно хотеть от ИБ?» Остановимся на них подробнее.

Этап 0: инициация топ-менеджмента. Итак, представитель топ-менеджмента (обычно CEO или собственник) заинтересовался результативной кибербезопасностью. Причины могут быть разными: тренды рынка, «pi**ec driven development» или же громкие атаки. В любом случае, у вас есть примерно месяц, пока руководство не переключится на другие вопросы.

Результат: топ-менеджмент занимает активную позицию: определяет результат проекта РКБ и помогает его достичь.

Этап 1: семинар по определению НС. В душном помещении собирается истеблишмент и при участии модератора формулирует, какие события являются недопустимыми для компании. Про ИТ и ИБ речи пока не идет. Отмечу, что к семинару нужно готовиться: собрать отраслевые примеры НС, сформировать гипотезы в разрезе компании и т.д.

Важно: без должного уровня доверия и общения с топами можно совершить ошибку — сформировать недопустимые события, в которые никто не будет верить.

Результат: сформирован реестр недопустимых событий. За каждым из них закреплен «спонсор» — человек, который больше всего заинтересован в том, чтобы конкретное НС не было реализовано.

Этап 2: формирование сценариев НС. Проводим интервью с каждым «спонсором» и пытаемся понять, при каких обстоятельствах может наступить определенное НС (говорить про ИТ и ИБ все еще рано). Например, причиной остановки склада может стать выход из строя системы управления или классические маски-шоу.

Таким образом мы сформируем список нужных нам киберзависимых сценариев. Остальные кейсы тоже не пропадут: их можно передать в корпоративные риски или, к примеру, сделать основами планов BCP и DRP для ИТ.

Результат: прописаны сценарии НС, которые могут быть реализованы в результате кибератак.

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

Подчеркну, что сформированное описание не претендует на as is, а служит лишь для того, чтобы верхнеуровнево оценить стоимость работ.

Результат: подготовлено актуальное описание ИТ- и ИБ-ландшафта компании.

Этап 4. Условия, ограничения, фазы. На предыдущих этапах мы собирали информацию из серии «С чем работаем?», а теперь пора ответить на вопрос «Как будем делать?». Здесь идет работа со всеми стейкхолдерами и описывается «образ результата». Нам нужна безопасность инсорс или будем использовать сервисный подход? Есть ли legacy-системы, которые нельзя трогать? Каким требованиям безопасности должны соответствовать наши ИТ-решения? И далее по списку.

Кроме того, мы определяем фазы, по окончании которых планируем достичь значимого бизнес-результата — успешно пройти киберучения и вывести недопустимые события на перманентные bug bounty.

Результат: описание результата, который бизнес хочет получить от внедрения РКБ.

Этап 5. Формирование бизнес-требований к ИТ- и ИБ-функциям. Теперь нужно описать, какой же «дом» мы в итоге хотим построить. Бизнес-требования должны содержать:

• Целеполагание через недопустимые события, которые являются отправной точкой для формирования состава и границ проведения работ.
• Желаемый образ конечного результата, который показывает, какие шаги по повышению киберустойчивости компании необходимо реализовать, по мнению топ-менеджмента.
• Критерии приемки результатов работ, которые подтверждают, что образ конечного результата достигнут в полном объеме и удовлетворяет требованиям топ-менеджмента.
• Описание имеющегося ИТ-ландшафта и средств обеспечения ИБ.
• Ограничения, которые нужно учесть потенциальным исполнителям.
• Требования к исполнителям: минимальная квалификация и гарантии, необходимые для успешного завершения работ.
• Этапы и сроки проведения работ.
• Критерии оценки предложений от потенциальных исполнителей (основные параметры, влияющие на выбор партнеров).
• Гарантии и порядок оплаты работ.

Результат: бизнес-требования сформированы и зафиксированы. По сути, это контракт между топ-менеджментом, ИТ и ИБ.

Что дальше?

После утверждения бизнес-требований ИТ- и ИБ-подразделения формируют стратегию их достижения. Здесь важно работать сообща — без помощи ИТ достичь киберустойчивости невозможно. При этом не стоит забывать слова «господина директора»: «Ничто не делает из ИТ кибергестапо лучше, чем ответственность за инциденты». Далее стартуют проекты по описанным фазам, проводятся киберучения, показывающие, что red team с хакерской экспертизой уровня Positive Technologies не способны реализовать недопустимые события, запускаются bug bounty и др.

Бизнес-требования, по нашему мнению, являются единственным правильным инструментом, дающим ответ на вопрос «А что же нужно хотеть от ИБ?». И появление на рынке таких запросов — одна из наших миссий на ближайшее время. Задумав постройку дома, вы вряд ли начнете искать требования, которым надо соответствовать, вы просто позовете архитектора и попросите сделать проект: две спальни, гараж, аквадискотека и комната грязи, — и уж точно не будете начинать с канализационной развязки. Так вот бизнес-требования и есть такой запрос.

На сегодня все! В следующих статьях мы поговорим о других доменах фреймворка РКБ, обсудим киберучения и bug bounty, расскажем, из чего можно строить безопасность и как работать с ИТ в части ИБ (ИТ 2.0), как добиться, чтобы time to attack был меньше, чем time to response, и т.д.