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

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

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

И в спокойные времена это не слишком мешало: кто-то реализовывал требования регуляторов, кто-то в своем понимании занимался реальной информационной безопасностью, и пока не было того количества атак, которое мы видим сейчас, отсутствие четкой цели не было столь явным и критичным. Сегодня же такое «самурайство» и его неприемлемость с точки зрения цифровой устойчивости компаний стало явным как никогда. Что делать? Менять средства защиты? Менять себя как «безопасника»? Менять подходы к защите?

СПРОСИ СЕБЯ, ЗАЧЕМ?

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

Топ-менеджмент условного бизнеса (условного, потому что государственные или муниципальные структуры в данном случае тоже бизнес, просто задачи у него немного иные — не заработать все деньги этого мира, а, скажем, оказывать населению услуги с должным качеством и в должные сроки) нередко просто не видит эффективности ИБ с точки зрения своего целеполагания. Им не понятны такие задачи, как «обеспечить соответствие требованиям регуляторов» (ФСТЭК, ФСБ, Минцифры, Центральный банк, Минэнэрго, PCIDSS — все эти аббревиатуры для бизнеса часто просто наборы букв) или обеспечить compliance (который, по большому счету, с точки зрения наказания за его несоблюдения у нас пока скорее никакой — штрафы настолько малы, что расходы на необходимые для обеспечения compliance средства защиты существенно выше). Когда единственным мерилом ИБ оказывается сравнение бюджетов на новые СЗИ, приобретение специфических услуг или запуска новых ИБ-проектов (тех же самых киберучений, к примеру) и потенциальных потерь в случае несоответствия compliance, информационная безопасность конечно же проигрывает в глазах бизнеса. Казалось бы тупик?

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

НЕ НОВОСТЬ, НО НОВЫЙ ВЗГЛЯД

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

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

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

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

КАК ОПРЕДЕЛИТЬ ГЛАВНОЕ И НЕ ОШИБИТЬСЯ

Есть десятки сценариев, которые гипотетически могут привести к краху бизнеса, но в реальности их невозможно реализовать. Поэтому, как я уже писал, необходимо понять, как каждый конкретный сценарий, недопустимое событие, может быть реализовано «плохими парнями» через ИТ-инфраструктуру, какие шаги они должны сделать, чтобы достичь некоей целевой системы, в которой недопустимое событие может быть реализовано. Если речь о краже денег, то это компьютер бухгалтера. Если речь об останове производства, то — какой-нибудь АСУ ТП-шный сервер или контроллер; если это, скажем, срыв контрактных обязательств, то речь может пойти о влиянии на систему контроля поставки товаров, к примеру, как это было в случае с Colonial Pipeline, когда фьючерсы на бензин выросли на 4%; или, например, когда взламываются системы доступа на крупное спортивное мероприятие и не работают системы Fan-ID — это все примеры недопустимых событий, которые ретранслируются на ИТ-инфраструктуру. Задача безопасника, повторюсь, понять, как это может быть реализовано с точки зрения влияния на ИТ. И фокусировка на ключевых системах — а их очевидно гораздо меньше, чем всего узлов на инфраструктуре, позволит оптимизировать ресурсы и затраты, что является одной из ключевых задач в концепции результативной ИБ. Суть не только в том, что ИБ фокусируется на защите действительно важных объектов, но еще и экономит — людей, время и т. д.

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

МЕЖДУ ХАРДЕНИНГОМ И МОНИТОРИНГОМ

Итак, недопустимые события определены, как и системы, в которых эти события могут быть реализованы. Следующий вопрос, на который надо ответить: «Как от всего этого защититься и какие защитные меры применять?». Здесь есть несколько вариантов. Во-первых, можно нейтрализовывать все эти недопустимые события на тех уровнях, на которых они проявляются (или благодаря которым они проявляются) — на уровне бизнес-процессов. Но обычно на этом уровне работает не ИБ, а другие подразделения и традиционно безопасники не слишком «любят» сюда идти. Во-вторых, это можно делать на уровне ИТ, — правильно выбирая технологии, правильно их сегментируя, устанавливая патчи и т. д. Но опять же традиционно это уровень ИТ, а не ИБ. В зоне ответственности ИБ чаще всего оказывается использование различных технологий обнаружения аномалий — EDR, SIEM, VM и т.д. — и с их помощью и надо выявлять то, что может привести к реализации недопустимых событий. Иногда это может тесно перекликаться с ИТ, иногда переплетаться с инжинирингом бизнес-процессов, но ситуация сильно зависит от того, каковы ресурсы, полномочия и зона ответственности конкретного CISO.

В любом случае, какой бы сценарий ни реализовывался — меняются ли бизнес-процессы, ИТ-инфраструктура, меняются ли решения в области информационной безопасности — все равно понадобится мониторинг. Он является неким контрольным мероприятием и позволяет убедиться, что инфраструктура не только правильно реализована (включая средства защиты), но и не допускает реализации недопустимых событий в процессе эксплуатации. Ну, и, конечно, здесь всегда будет некая дилемма — на чем сфокусироваться: закрутить гайки с точки зрения харденинга ИТ-инфраструктуры (и это больше ИТ-шный подход) или сделать фокус на мониторинге и реагировании. Речь о своеобразном бегунке, который в реальности поможет найти баланс в зависимости от возможностей и ресурсов между харденингом, мониторингом и реагированием. В одном случае будут предотвращаться события, которые приводят к недопустимым последствиям, во втором — будет максимально оперативное реагирование на эти события (когда первый шаг атакующим удался, но оперативная реакция на это не дает им шансов развить атаку дальше). Эту задачу решает центр противодействия киберугрозам (ЦПК). В отличие от традиционного SOC, который фокусируется на событиях безопасности, ЦПК базируется на идее недопустимых для бизнеса событий, и концепция выстраивается сверху вниз: определяется, что плохо для бизнеса, как это может быть реализовано в инфраструктуре, на каких системах это может быть реализовано, и мониторинг с реагированием фокусируется уже именно на них, а в ряде случаев делается и харденинг. Эта концепция позволяет достигать быстрых результатов, а не входить в историю, когда проекты растягиваются на 2-3-5 лет: выявили наиболее критичные недопустимые события, оперативно закрыли возможность их реализации, перешли к следующему пулу событий.  В чем интересность такой концепции: закрывая недопустимые события, как правило, в большинстве случаев закрывают и все остальные нежелательные события в том числе. Потому что недопустимое от нежелательного часто отличается только размером ущерба: украли 50% денег со счета или 100 рублей со счета — технологически это одинаковое действие для злоумышленника.

КАК ПОДТВЕРДИТЬ, ЧТО НАМ НЕ ЗРЯ ПЛАТЯТ ЗАРПЛАТУ?

Как подтвердить, что все сделано правильно? Мы потратили немало времени и денег на то, чтобы выяснить, чего опасается бизнес, и сделали так, чтобы эти опасения не реализовались. Но как нам убедиться, что это действительно так? Мало просто сказать, что информационная безопасность реализована верно и соответствует лучшим мировым практикам. Главное — верифицировать невозможность реализации недопустимого события. Это можно сделать разными способами: с помощью пентестов, редтиминга, киберучений, программ bug bounty — называть их можно как угодно, они разные, с разной методологией и командами, с юридически разными подходами и процедурами. Но результат они дают один — уверенность в том, что мы достигли результата, который понятен руководству компании, — хакеры не могут залезть внутрь и реализовать недопустимые для нас события. И в этом случае из самурая, у которого нет цели (только путь), мы превращаемся в службу ИБ, которая в прямом смысле слова готова отвечать за свои слова и демонстрирует это на практике.