Переосмысляем ИБ-продукты в терминах результата

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

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

Кто виноват несет ответственность?

Современная ИБ-парадигма держится на трех китах (читай — запросах). Первый — запрос на человеко-дни ИБ-специалистов. В этом случае исполнитель — вендор или интегратор — просто предоставляет клиенту экспертов для решения задачи и не несет ответственности за реальное повышение уровня защищенности компании.

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

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

А теперь представьте: как изменилась бы ситуация, если бы при запуске ИБ-проектов все участники рынка изначально ориентировались на результат? Четко определяли и фиксировали свои ожидания как от точечных внедрений, так и от масштабных кейсов в рамках всей компании. А заодно делили ответственность за достижение и, что немаловажно, непрерывное удержание обозначенных результатов. Какие решения в этом случае предлагали бы вендоры и интеграторы? Какие требования к ИБ-продуктам выдвигали бы клиенты? Давайте разбираться.

Контракт, ориентированный на результат

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

1. Сформулировать понятный и измеримый результат. Клиент (самостоятельно или с ИБ-партнером) должен четко описать, чего именно он ждет от конкретного проекта и его участников.
2. Определить качественные и количественные метрики достижения и удержания результата. Это может быть своего рода SLA на результат, где четко описаны условия, при которых система ИБ или отдельный продукт находится в результативном состоянии.
3. Установить требования, критерии и методику оценки непрерывности обеспечения результата. Нужно уходить от привычных, но морально устаревших технических заданий: как правило, они оторваны от практической безопасности и не отражают реальных потребностей заказчика в защите.
4. Подготовить инфраструктуру, выбрать продукты и определить процессы. Будем честны: не всех важных для бизнеса результатов получится достичь с имеющейся инфраструктурой и/или процессами. Результативная кибербезопасность должна строиться на безопасной ИТ-инфраструктуре: с микросегментацией, описанными и внедренными ролями и полномочиями учетных записей, контролем подключения новых устройств, настроенными механизмами ИБ и т. д.
5. Детализировать, внедрить и автоматизировать процессы. Отработать первое достижение результата. Чтобы добиться первого результата в новой парадигме, потребуется сплоченная работа специалистов из смежных подразделений. Важно, чтобы подобные проекты поддерживал топ-менеджмент компании.
6. Непрерывно удерживать результат, оценивать заявленные метрики и управлять изменениями. Помните, что ответственность за удержание результата лежит не только на клиенте, но и на всех участниках проекта, будь то производитель ИБ-продукта, сервис-провайдер или интегратор, обеспечивающий поддержку и сопровождение. Определите и выразите ответственность за результат соразмерно вовлеченности всех сторон. При этом могут быть предусмотрены как штрафы за отклонение от результата, так и поощрения за его удержание в рамках согласованного SLA.

Новые требования к старым решениям

Приведем несколько примеров требований, которые можно (и нужно) предъявлять к проектам по внедрению ИБ-продуктов в терминах результата.

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

Как определить метрики

Чтобы описать все возможные метрики для разных ИБ-решений, понадобится несколько выпусков Positive Research, поэтому остановимся на одном — сканерах уязвимостей. Подойти к снаряду можно несколькими способами.

Во-первых, метрики могут опираться на статистику реальных атак. Например, согласно отчету Palo Alto Networks хакеры начинают сканировать инфраструктуру организации уже через 15 минут после появления информации об уязвимости в базе CVE. Т.е. можно использовать в качестве метрики показатель «15 минут».

Второй вариант — ориентироваться на характеристики, которые производители закладывают в свои ИБ-продукты. Мы в MaxPatrol VM, к примеру, гарантируем доставку информации о трендовых уязвимостях в течение 12 часов. Соответственно, можно зафиксировать «12 часов» в качестве метрики.

Еще одной отправной точкой может стать методический документ ФСТЭК России от 17.05.23. В нем указаны следующие рекомендуемые сроки устранения уязвимостей:

• критический уровень опасности — до 24 часов;
• высокий уровень — до 7 дней;
• средний уровень — до 4 недель;
• низкий уровень — до 4 месяцев.

При формировании результативных метрик ИБ рекомендуем:

• обращать внимание на статистику реальных атак;
• следить, чтобы метрики не были ниже показателей, указанных в нормативных документах (если они существуют и применимы к вашей организации).

Достижение и удержание результата

Теперь, когда у нас есть контракт, четкие требования и метрики, можно приступать к достижению результата. При этом особенно важно договориться о сотрудничестве со смежными подразделениями компании: силами одних ИБ-специалистов здесь не обойтись. Нужно будет найти общий язык с ИТ и бизнесом, обсудить возможные изменения внутренних процессов, модернизацию инфраструктуры, вопросы выявления shadow IT и распределения обязанностей. Процесс достижения первого результата включает следующие этапы.

1. Определение и приоритизация активов. Выделите область, в которой требуется достижение результата, а затем приоритизируйте содержащиеся в ней активы. Вы должны четко понимать их принадлежность к информационным системам и бизнес-процессам компании.
2. Планирование и дизайн процессов. На этом этапе важно определить верхнеуровневый дизайн процессов для достижения результата и сформировать команду, включающую специалистов из всех вовлеченных подразделений.
3. Проектирование систем и описание процессов. Сформулируйте требования к средствам автоматизации, которые позволят реализовать процессы с заданными метриками. Подготовьте проектную документацию на внедряемые системы и детализируйте процессы.
4. Поставка, модернизация, пусконаладка. Сюда входят технические работы: приобретение средств защиты, интеграция с другими ИС, модернизация имеющихся решений для достижения установленных метрик и т. д.
5. Подготовка персонала и ввод в действие средств автоматизации. Здесь важно работать с командой и активно погружать сотрудников, ответственных за результат, в процесс работы со средствами автоматизации.
6. Достижение первого результата. Ура, все получилось! Теперь нужно отработать процессы, оценить и зафиксировать узкие места, вычислить фактические показатели (насколько они отличаются от заявленных метрик) и обработать фидбэк от команды.

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

***

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