а инфраструктуру — не только стойким к атакам, но и к ситуациям, когда атаки оказались успешными.

Уважаете ISO/IEC 27001, CIS и NIST CSF? Мы тоже. Фреймворков по кибербезу на свете лучше нет, но их недостаточно. Кибербезу, который застрял в догматической недопустимости событий и оторванном от ИТ-службы пузыре, нужен новый герой.

Рассказываем, как наша методология CyberYool делает акцент на киберустойчивости, а не кибербезопасности; помогает не только соответствовать требованиям регуляторов, но и делать так, чтобы эти меры реально защищали; и напоминает, что, вообще-то ИБ и ИТ должны развиваться в компании вместе, а не играть в догонялки.

Да, мы решили сделать ещё одну методологию. Да, можете говорить, что мы придумываем велосипед, ведь на свете есть ISO 27k, CIS, NIST, РКБ/РезБез, ISF SoGP, PCI DSS и ещё пара десятков неплохих фреймворков разных моделей, гранулярности, концептуальности и практичности. Многие даже предлагают измеримые метрики эффективности, маппинги и конкретные инструкции «делай раз, делай два». 

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

Главная проблема — существующие фреймворки не связывают кибербез с непрерывностью и отказоустойчивостью ИТ-процессов. 

Обычной кибербезопасности не хватает

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

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

Никакие меры не могут гарантировать защищённость просто потому, что никто не знает, какой новый вид атаки может появиться завтра. 

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

Вместе повторим мантру:

• меня в любой момент могут атаковать;

• успешность некоторой части атак неизбежна;

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

Умение обнаруживать атаки, нивелировать их последствия и оперативно восстанавливаться важнее способности просто защищаться. 

Киберустойчивость > кибербезопасность

В целом на рынке всё работает нормально: требования соблюдаются, средства защиты внедряются. Но компании взламывают, проникновения и утечки всё равно происходят. И такое shit happens встречается, даже если всё делать правильно.

Повторим: существующие методики — топ. Кибербезопасность — это хорошо. Но нет ли у вас ощущения, что все меры по кибербезу как будто бы ведут к какой-то конечной точке, финишу, постройке Грааля, после которой никакая Red Team и Bug Bounty не страшны? Если возникают мысли в духе «вот сейчас внедрим и заживём» — у нас для вас плохие новости. 

Абсолютной киберустойчивости, как и абсолютной кибербезопасности, достичь нельзя. Но к ней можно идти. Поэтому наша методология и называется CyberYool — «юл» переводится с татарского как «дорога» (центральный офис Innostage — в Казани).

«ИТ создаёт риски» vs «Безы не приносят деньги» 

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

Нельзя просто взять и внедрить новый контур/систему/процесс таким образом, чтобы всё было идеально с точки зрения кибербеза — слишком разные цели, приоритеты и KPI у ИТ и ИБ. ИТ-команда не будет думать о безопасности, отрываясь от производства. А безам бы с приказами ФСТЭК, 152- и 187-ФЗ разобраться, а не вникать в разработку. 

Или можно?

Можно, но извне. Бизнесу изнутри сложно оценить самого себя на разных уровнях. А сделать это объективно — и вовсе невозможно, тем более без готовых методичек.

CyberYool помогает сменить оптику, оценить уровень зрелости ИТ и ИБ и декомпозировать задачи до технического уровня. Методика не панацея, но помогает реализовывать подходящие меры для текущего уровня. 

Вот классическая ситуация. К CISO приходят интеграторы и вендоры, которые предлагают свои космические корабли, на которых бизнес будет бороздить просторы кибербеза. И, как правило, прогибают на пилот, внедрение, поддержку. Но на деле этой кампании не EDR/XDR нужно, а антивирус обновить. Ну зачем этой компании строить драконьи скалы, если в оплоте ещё нет капитолия?

Или другая проблема. Когда ИБ попадает в тиски требований ФСТЭК, ЦБ, ФСБ, Роскомнадзора и прочих регуляторов, безопасникам приходится бегать с молотком и прибивать кротов, наслаивая и наслаивая разные системы. Всё защищено, но как поддерживать и развивать все эти костыли — непонятно. CyberYool позволяет сразу понять, как каждое из последующих решений будет взаимосвязано. 

В чём вообще суть методологии 

В основе CyberYool лежат рекомендации CIS Controls, NIST Cybersecurity Framework, ISOIEC 27001 и РКБ/РезБеза — мы пересобрали их под требования отечественных регуляторов, разложили на несколько направлений, привязали к конкретным ИТ-активам. И расширили: включили не только защитные меры, но и меры по обеспечению отказоустойчивости и её проверке.

Теперь по порядку.  

Выделяем 5 уровней киберустойчивости

Делим всё на несколько уровней зрелости компании. Каждому уровню — свои меры.

• Гигиенический уровень;

• Киберустойчивость ИТ-инфраструктуры;

• Киберустойчивость информационных систем;

• Непрерывность бизнес-процессов;

• Киберустойчивость организации. 

Надо пройти 5 этапов

От аудита через трансформацию к независимой оценке защищённости. Это должно выглядеть знакомо.

Сначала оцениваем текущее состояние и определяем цель достижения киберустойчивости. Глобально понятно — «стать киберустойчивее». Но её надо на что-то приземлять: фундаментом могут быть как недопустимые события из РКБ, так и классическая модель угроз или оценка рисков.

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

Рисуем high-level дизайн, где определяем целевое состояние. Определили недостатки инфраструктуры, определили возможный ущерб для бизнеса, придумали, как его избежать и создали дорожную карту трансформации инфраструктуры. 

Трансформация. Самая мякотка — внедряем практические меры как для существующей инфраструктуры, так и для новых объектов.

Подготовка и обучение сотрудников. Обучаем внедрённым технологиям и процессам весь персонал — от линейных сотрудников до CEO.

Независимая оценка. Надо непрерывно проверять, что всё созданное и внедрённое реально работает. Для начала — пентестами и киберучениями. Компаниям со зрелым ИБ — функциональным и нагрузочным тестированием безопасности и сетевой инфраструктуры. Бизнесу с самым матёрым ИБ — с помощью багбаунти. 

Мы сами использовали CyberYool, чтобы подготовить Innostage к открытым кибериспытаниям

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

Немного цифр:

• с конца мая по начало декабря наши спецы отбили порядка 780 тысяч атак;

• 930 исследователей ломало нас;

• если бы сломали — получили до 10 млн рублей.

5 декабря 2024 мы получили сертификат №0001 и стали первой кибериспытанной компанией в России. Программа идёт и дальше — сейчас в ней уже больше 1100 участников.

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

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

Поэтому мы решили развивать наработки, доказавшие эффективность на нашем примере, и вышли на рынок с CyberYool.

Выбираем среди >200 мер ИТ/ИБ с примерами решения

Вот так, например, они будут выглядеть для уровня ОС.

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

Как использовать Суberyool

Как справочник, как шпаргалку для классификации и структурирования своих инициатив.

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

Как модель оценки зрелости процессов, чтобы понимать, что компании пора переходить на новый уровень и использовать другие инструменты.

Как стратегию, которая поможет проще адаптироваться к изменяющимся условиями за счёт проработанной связи ИБ и ИТ.

Чего сейчас не хватает в такой методологии и куда мы хотим её развивать

CyberYool — это не волшебная палочка. И тем более не говорим, что это самая великолепная и прекрасная методология. И ей есть куда развиваться.

Финансовое обоснование. В чём измеряется эффективность кибербезопасности? В широком смысле — в сэкономленных деньгах на предотвращении атак. В чём измеряется эффективность киберустойчивости? В сэкономленных деньгах на предотвращении атак и минимизации их воздействия. Но сколько это денег именно — непонятно. 

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

Отраслевая специфика. Металлургия, медицина, финансы — везде есть свои приколы и разное понимание критичности процессов. Будем дополнять.

Маппинги на другие стандарты. Мы говорим про связь ИБ и ИТ, про устойчивость, но под условный ITIL переложить CyberYool пока не можем. Работаем над этим. 

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

CyberYool осилит идущий!