Шаг №2. От практической безопасности к результативной

Деньги Стратегия

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

Представьте, что у вас в инфраструктуре 500 тысяч устройств. Или даже 100 тысяч. Или даже 10 тысяч. Можно ли на каждом из них выполнить все требования методички ФСТЭК по управлению уязвимостями? Увы. Это малореальная задача. А что делать, если у вас не хватает людей в ИБ (а кому их хватает)? Вам придется приоритизировать свои усилия. Но как?! Как вам разработать шкалу критичности уязвимостей? По CVSS? Но это тупиковый путь, так как он не учитывает роль узла, на котором дыра найдена. По EPSS? По SSVC? Они все оценивают «вещь в себе», то есть уязвимость саму по себе. А инциденты? Как мы формируем шкалу критичности для них?

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

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

Почему не риски и не угрозы ИБ и не компьютерные атаки? А потому что определение недопустимого должно идти сверху вниз, а не снизу вверх. Только бизнес может сказать, что ему недопустимо, что нежелательно, а на что он болт клал (или ложил, как кому удобнее). Он сам выделяет важное, сам все приоритизирует, а задача ИБ не дать произойти тому, что бизнес посчитал для себя недопустимым. С угрозами ведь у нас как? Вы берете методику ФСТЭК и начинаете по ней определять то, от чего потом будете защищаться. Все в этой методике хорошо (особенно в ее невыпущенной новой версии, под которую средство автоматизации есть на сайте регулятора) кроме двух вещей — она не учитывает многих угроз (потому что ФСТЭК за них не отвечает) и они рассчитана именно на ИБшников, не на бизнес. А ИБшники у нас люди приземленные и часто еще законопослушные, чего не скажешь о бизнесе, который умеет прекрасно оценивать, что стоит делать, а чего нет, и делает это на свой страх и риск. И даже определение негативных последствий, с которого начинается новая методика, хоть и является движением в правильном направлении, но не спасает ситуацию до конца, — все равно это определение ложится на ИБшника, которому хоть и рекомендовано идти к бизнесу, но он это игнорирует, считая, что он лучше бизнеса знает, какие негативные последствия у него могут быть, если не будут реализованы меры по нейтрализации актуальных угроз 1-го и 2-го типа по 1119-му Постановлению Правительства.

Да бизнесу пофигу на угрозы хоть 1-го, хоть 2-го, хоть 3-го типа. Он не думает этими категориями в принципе.

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

Посмотрите видео с сессии «Как руководство компании оценивает недопустимые события» на PHDays. Там Борис Симис рассказывает, как в Позитиве сформировали свой перечень из 4-х недопустимых событий. Хотя первоначально их было гораздо больше, но после обсуждения с акционерами в компании пришли к выводу, что многое скорее нежелательно, чем недопустимо.

Поэтому ключевым отличием результативной ИБ от практической (хотя можно спорить о терминах) — это целеполагание, устанавливаемое руководством компании. Если его устраивает термин риски или негативные последствия, да, пожалуйста, используйте их. Тут важен не используемый словарь, а суть. Что тогда будет результатом? Недопущение определенных топами недопустимых событий и вся деятельность ИБ должна быть направлена на это.

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

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

  • харденинг инфраструктуры
  • защита от угроз и реагирование на них.

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

В целом дорожная карта движения в сторону результативной кибербезопасности выглядит так:

Дорожная карта результативного кибербеза
Дорожная карта результативного кибербеза

Реализовав защиту, мы захотим оценить реальную защищенности организации и проверить, возможно ли реализовать недопустимые события или нет. Тут важно отметить, что мы не можем перейти к реальной оценке не выстроив нормально процессы ИБ — управление уязвимостями, мониторинг, управление инцидентами, SecDevOps (если есть своя разработка) и т.п. Да, вы можете закупить сканеры безопасности и даже BAS-решения, вы можете приглашать хоть каждый квартал аудиторов, но если вы не знаете, что делать с выявленными уязвимостями и нарушениями, если ваш бэклог накапливается быстрее, чем вы закрываете косяки, в него попавшие, то вам еще рано говорить о результативной кибербезопасности (и это я еще про эффективность ничего не сказал, сфокусировавшись пока только на результате).

Прелюдия к оценке защищенности
Прелюдия к оценке защищенности

И только выстроив процессы, вы можете переходить к финальному этапу и еще одной отличительной особенности результативной кибербезопасности. Вы должны оценить реальный уровень своей защищенности, пригласив внешних хакеров, которые проверят вас на прочность. И речь идет не просто о пентестах и не просто о багбаунти, а, как минимум, о совмещении этих двух направлений, которое Владимиром Бенгиным, директором департамента кибербезопасности Минцифры, на PHDays было названо «пентестом на максималках«. То есть вы приглашаете не одну компанию попробовать проникнуть в вашу инфраструктуру, а вообще не ограничиваете их число, размещая на платформе багбаунти соответствующую программу (в привате или в паблике, на ваше усмотрение). Ну а вершиной этой истории является багбаунти на недопустимые события, когда хакеры соревнуются не за возможность проникнуть внутрь вашей организации, а за реализацию событий, которые вы для себя определили как недопустимые. В конце концов, какая вам разница, найдут у вас какую-нибудь RCE на веб-сайте или не найдут (как правило всегда находят). Важно простроить из выявленных уязвимостей цепочку, пройти по ней до целевых систем и там попробовать реализовать недопустимое. И если это смогли сделать легальные хакеры, то значит смогут сделать и киберпреступники. А если нет, то с высокой вероятностью и плохие парни не смогут.

Подходы к оценке защищенности
Подходы к оценке защищенности

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

  1. Определяем то, что недопустимо для бизнеса. Это позволяет нам сузить область будущего внимания/защиты/контроля.
  2. Модернизируем инфраструктуру, чтобы она сама нейтрализовывала типовые или более сложные угрозы (харденинг).
  3. Построение центра противодействия угроз (ЦПК), то есть выстраивание процессов мониторинга, реагирования и предотвращения киберугроз.

    2-й и 3-й этапы могут строиться вместе (и это лучший вариант), но могут и независимо друг от друга.

  4. Оценка защищенности в виде банбаунти, пентестов, киберучений и т.п.

Кстати, чтобы не было недопонимания. Результативный кибербез не противоречит практическому. 2-й и 3-й этапы, упомянутые в предыдущем списке, и есть реализация практической ИБ. Поэтому все, что вы делаете в рамках выполнения свежих требований ФСТЭК, ФСБ, Минцифры, не пропадет. Но чтобы перейти на новый уровень и сделать шаг в развитии и своего кибербеза и себя, вам нужно сфокусироваться на том, что важно для бизнеса и доказать, что вы можете это не допустить.

Методологии построения результативного кибербеза посвящен специально созданный портал, на котором выкладываются соответствующие материалы, методички и т.п. При этом речь идет не о проекте конкретной компании, а о комьюнити-проекте, в котором может участвовать любой, предлагая свое видение отдельных этапов результативного кибербеза (можно посмотреть видео о нем). Для общения комьюнити создан телеграм-канал «Рез IN Без» (https://t.me/Rez_in_Bez).

Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

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