Не ошибусь, если предположу, что про громкие кибератаки на российский бизнес (целями стали крупнейший авиаперевозчик, ритейлер алкогольной продукции, сети аптек, рестораны, производственные компании и др.) летом 2025 г. не слышал только самый невнимательный, не интересующийся профессиональными новостями руководитель по информационной безопасности (ИБ). В этой статье я хочу поделиться собственными мыслями о практических шагах по профилактике актуальных угроз, задуматься о которых меня, как ИБ-руководителя, заставили эти события.
О реальных предпосылках, технических аспектах и последствиях кибератак для операционной деятельности пострадавших компаний нам, сторонним наблюдателям и аналитикам, остается только догадываться, ориентируясь на официальные сообщения пресс-служб и сводки правоохранительных органов.
Будет крайне непрофессионально без участия представителей профильных подразделений, отвечающих за обеспечение информационной безопасности в компаниях – жертвах кибератак, обсуждать данную тему в публичном пространстве, а также пытаться строить какие-либо гипотезы о допущенных нарушениях – эту роль предлагаю оставить потомкам (или же работникам отраслевых регуляторов). Тем не менее спешу поделиться собственными мыслями о практических шагах по профилактике актуальных угроз, задуматься о которых меня, как ИБ-руководителя, заставили предшествующие события. Надеюсь, что их своевременная реализация принесет практическую пользу и не позволит разделить участь ИБ-коллег из компаний – жертв недавних кибератак.
Итак, несколько мыслей и аргументов по следам громких кибератак в копилку ИБ-руководителю.
Понятно и логично, что этот внутренний сервис должен быть по классике реализован в любой уважающей себя компании. Отказоустойчивость и восстановление – это святое. Но! Как часто в компании проходят реальные практические проверки возможности восстановления данных после инцидента? Как давно/часто ИБ-специалисты или ИБ-руководители лично участвовали в процедуре восстановления данных из резервных копий? Установлены ли на эти бэкапы стойкие пароли? Как долго они шифруются/расшифровываются? Хранятся ли они в защищенном от внешнего воздействия/редактирования/удаления месте? Как быстро можно ими воспользоваться, если что-то пойдет не так? Какое влияние на операционную надежность оказывает процесс, естественным образом растянутый во времени, восстановления данных для неработающей/выведенной из строя одной-единственной автоматизированной системы? А если таких систем несколько десятков, то как правильно с точки зрения выставления приоритетов и сохранения интеграционной связанности следует восстанавливать системы их бэкапов? Кто-то это реально проверял? Этот "кто-то" еще работает в компании или давно уволился, унеся с собой набор уникальных знаний и компетенций?
В части практической реализации процесса резервного копирования сложных (не сразу понятных, без единственного правильного ответа) вопросов у ИБ-практика возникает очень много. Важно до наступления "времени Ч" найти и знать в компании человека, готового и способного правдиво на них ответить, а также принять участие в регулярных испытаниях системы резервного копирования по ключевым компонентам критического бизнес-процесса.
"У нас это реализовано на уровне ситуационного центра" – эта первая фраза возникает в голове, когда видишь/пишешь/читаешь про мониторинг ИБ-инцидентов. Согласен… И опять-таки одно маленькое "но". Думаете, в крупном авиаперевозчике с офисами по всей России, собственными или где-то арендованными ЦОД, в территориально распределенных розничных сетях или фарм-компаниях не был нормально настроен SIEM-мониторинг, не было своего/аутсорсингового ситуационного центра с набором SLA, а может быть, не было обученных ИБ-специалистов, отвечающих за актуальность правил корреляции событий? Конечно же, все это было и есть! Поэтому одного ответа "у меня в компании все это есть", к сожалению, недостаточно!
Важно в любой момент времени понимать, что этот мониторинг работает и способен эффективно собирать, анализировать и выявлять события с признаками инцидентов и что глаза операторов дежурных смен не замылились от регулярных ложных срабатываний. Что каждое подозрение на инцидент проверяется, разбор нечетко классифицированных событий доводится до финальной точки по формализованному процессу управления инцидентами. Что результаты расследований становятся частью новых цепочек и правил корреляции. А теперь можно ли с уверенностью сказать, что в компании "есть мониторинг"?
По данным BI.ZONE, хакеры стали чаще атаковать российские компании для киберразведки – сбора данных об их уязвимостях. В первой половине 2025 г. доля таких атак выросла более чем в пять раз. Самыми популярными отраслями для хакерских атак в России в этом году стали ИТ, телекоммуникации и медиа, а также ритейл.
Как показывает практика, тесты на проникновение со скважностью один-два года, даже при условии регулярной смены команды пентестеров, не позволяют своевременно выявлять и учитывать актуальные уязвимости. Бывает, что инфраструктура компании обновляется чаще, постоянно возникают пилоты, интеграции с внешними источниками, тестовые зоны разработки и пр. Поэтому логично, что тестирование на проникновение "извне" должно чередоваться с внутренними проверками защищенности и проводиться чаще, чем раз в один-два года, еще лучше (в плане эффективного выявления и эксплуатирования во вновь создаваемых компонентах инфраструктуры на периметре) в непрерывном режиме RedTeaming. Да, это дорого, "как крыло от самолета", – рынок тестов на проникновение диктует свои условия.
Да, это крайне эффективно в начале пути (когда RedTeam-команда практически каждый день находит уязвимые компоненты и приносит их на стол ИБ-руководителю) и становится менее показательным после нескольких циклов устранения уязвимостей, с учетом корректировки процессов создания новых сервисов и размещения инфраструктурных компонентов на периметре сети, особенно с обязательным участием ИБ-специалистов. Но такой непрерывный анализ защищенности с учетом особого внимания к российским компаниям со стороны иностранных киберпреступных группировок – это вынужденные меры. И здесь ИБ-руководителю уже рассчитывать на "русский авось" как-то недальновидно.
Безотносительно к форме реализации (собственные силы, OSINT-аналитика или внешний коммерческий сервис, реализуемый профессиональными исследовательскими лабораториями), объема и регулярности поступающей ИБ-руководителю информации, поиск актуальных сведений о готовящихся, реализуемых в моменте или имевших место ранее успешных кибератаках, мониторинг появления запросов на получение расширенных сведений о компании на черном рынке, контроль и подтверждение (путем реализации контрольных закупок) утечек чувствительных данных за пределы защищаемого периметра компании, выявление факта привлечения на коммерческой основе инсайдеров для участия в целевых кибератаках – все эти отдельные элементы киберразведки нацелены на формирование у ИБ-руководителей дополнительных рычагов контроля и инструментов превентивного принятия решений.
Как бы крамольно это ни звучало, но как универсальное средство от всех видов кибератак классический антивирус, увы, неэффективен. Практика, в том числе многочисленных тестирований на проникновение, показывает, что наличие в компании импортозамещенного антивирусного решения из реестра СЗИ, код класса ПО 03.06 (кстати, их, антивирусов, в РФ не только два, как принято думать в ИБ-сообществе, а больше), не обеспечивает гарантированную защиту от всех видов современных атак.
Антивирус хорошо справляется со сканированием на предмет выявления известных вредоносов или признаков зловредов в файловой системе, проверками по сигнатурам скачиваемых файлов, архивов, скриптов, вложений – он выступает одним из, но не единственным компонентом защиты в составе таких модных сейчас решений, как EDR, NDR, XDR и SOAR. Если ничего из "этого новомодного ИБ-сленга" не откликается (кроме нетленного антивируса), то как минимум стоит задуматься о пилотировании/миграции/тестировании одного из продуктов данного класса.
Ну и всегда хорошо, когда есть взаимный контроль и подстраховка различных решений: так, антивирус на периметре, на прокси или на файловых/почтовых серверах может и должен перекрываться, к примеру, EDR-решением на конечных устройствах или XDR на мобильных или в облаках.
Только после крупных сбоев и инцидентов задним числом понимаешь, что зря ранее экономил на создании условного второго, резервного, не связанного с основным, контура для осуществления критичных бизнес-процессов в рамках операционной деятельности. В случае распределенного/дистанционного доступа через Интернет к сосредоточенным где-то в одном месте, в ЦОД, информационным системам количество потенциальных точек отказа всегда больше одной, и даже больше трех.
Поэтому логичным решением кажется создание не только резервной копии данных, но и резервирование компонентов, поддерживающих виртуальную инфраструктуру, для реализации бесшовной миграции и резервирование каналов/провайдеров для доступа к централизованной инфраструктуре, а также вынесение части (ограниченно, согласованно, плавно) функций/сервисов из центрального ЦОД на места ("на землю") для обеспечения бесперебойной работы в масштабах региона в случае возникновения критических инцидентов "в центре".
Конечно же, правильно было об этом думать на этапе проектирования архитектуры, но "история не терпит сослагательного наклонения", имеем и эксплуатируем ту промышленную инфраструктуру, которую имеем, и обеспечивать ее резервирование и отказоустойчивость чаще всего приходится по живому и рабочему процессу, в том числе в процессе восстановления после сбоев. Не верьте консультантам и внедренцам, которые обещают сделать все красиво, без фейлов, быстро и дешево. Проектирование надежной (99,999%) архитектуры, последовательное итеративное превращение уязвимого промышленного контура из стандартного в отказоустойчивый – это долгое и очень недешевое упражнение, крайне востребованное у бизнеса и руководства в текущих реалиях.
Это большая проблема, когда в рамках программы повышения осведомленности по ИБ-вопросам работников всегда возникает некая группа лиц, которая снисходительно и иронично смотрит на все происходящее, лениво листает учебные материалы, с напряжением в глазах изучает сценарии киберучений, иногда пытается этим процессом управлять, предъявляет даже какие-то свои требования ("5 копеек") и в итоге подписывает договоры и счета на оплату, но… не выносит из этого процесса ничего полезного для себя лично, не применяет базовые правила информационной безопасности на рабочем месте, не считает важным/нужным что-либо менять в своих собственных процессах личной кибербезопасности или при работе в Интернете. А ведь такие люди, безразличные, считающие себя выше общих правил и вне системы кибербезопасности в компании, – это фактическая "дыра" в безопасности. Через найденные в них уязвимости, с их неосознанной помощью злоумышленники попадают внутрь самого защищенного периметра и беспрепятственно, с правами привилегированных пользователей, реализуют нетривиальные сценарии кибератак. Как следствие – нарушение операционной деятельности и потери для бизнеса, которых легко можно было избежать (условно) своевременным обновлением версии операционной системы.
Речь тут не про импортозамещение или фактическое наличие межсетевых экранов и сегментированных сетей в инфраструктуре, а про то, что политики межсетевого экранирования должны быть не только актуальными, но и ориентированными на дробление на ограниченные сетевые сегменты по географическому, функциональному принципу или с учетом уровня конфиденциальности обрабатываемой информации, единого адресного пространства внутренней сети компании. Доступ между этими сегментами должен быть выстроен по принципу разумной достаточности и минимальности предоставленных прав. В то же время все попытки расширения предоставленных прав, проходов через межсетевые экраны по нестандартным протоколам или изменения среднесуточных показателей обмена трафиком между сегментами должны анализироваться в ситуационном центре на предмет отнесения к инцидентам ИБ.
Политики межсетевого экранирования (как постоянно растущий список правил) важно регулярно пересматривать, исключая из них незадействованные проходы и неактуальные объекты (делать инвентаризацию). Стоит серьезно задуматься над тем, как часто в компании происходит инвентаризация правил на межсетевых экранах. Есть ли для этого автоматизированные инструменты, разработаны ли методики анализа и критерии исключения? Может быть, сейчас самое время начать это делать превентивно?
Без коммуникации между ИТ и ИБ, выстроенной и поддерживаемой в профессиональном русле взаимного уважения, нельзя рассчитывать на полностью эффективную работу самой современной и надежной системы безопасности. Равно как и найденные в рамках тестирования на проникновения и анализа защищенности уязвимости продолжают оставаться критичными точками компрометации бизнес-процессов без их своевременного закрытия/устранения, что в большинстве компаний реализуется руками ИТ-администраторов.
Поэтому вместо того, чтобы искать крайних и виноватых в конкретном кейсе, намного важнее в стратегическом смысле суметь организовать совместную работу ИТ и ИБ так, чтобы у руководства и представителей бизнеса не было повода искать этих самых крайних. К сожалению, во многих российских компаниях ИБ (как неотделимая часть службы безопасности, как часто говорят коллеги, так сложилось исторически) предпочитает конструктивному сосуществованию с ИТ-подразделениями (и их подрядчиками и сателлитами) непрерывно культивируемый конфликт интересов, ссылаясь на непримиримость во мнениях. А как же тогда в других не менее крупных компаниях у коллег из ИТ и ИБ все же получается находить общие точки? Значит, они есть и всего лишь нужно потратить свой ресурс на поиск этих решений!
Процент исполнения бюджета в отчетный период, количество успешно закрытых проектов, такие показатели, как KPI/SLA, – это не метрики реальной информационной безопасности. Они не могут гарантировать руководству компании минимизацию последствий от критичных ИБ-инцидентов, умение и готовность ИБ-команды успешно отразить современные кибератаки, наличие необходимых профессиональных компетенций у экспертов и руководителей, регулярное устранение уязвимостей или соответствие реальных (действующих) настроек прикладных автоматизированных систем ранее заявленным. Если для смежных с ИБ подразделений (проектного офиса, клиентских продаж, маркетинга) подход к установке KPI себя оправдывает, для внутреннего сервисного блока (хозяйственного обеспечения, транспорта, логистики и пр.) подход с отслеживанием соблюдения SLA также может быть оправдан, то наложение аналогичных метрик на ИБ не даст ровным счетом ничего, кроме введения руководства в заблуждение о "близком к 100%" статусе исполнения и "высоком" качестве обеспечения в компании кибербезопасности и защиты информации.
Подобные прозападные управленческие инструменты целесообразно до применения пересматривать и адаптировать под ИБ-направление. И следующий логически вытекающий из этой мысли вопрос: что тогда может заменить те самые неэффективные/непоказательные метрики в случае с ИБ-подразделением?..
Все написанные выше мысли – это рассуждения и гипотезы одного-единственного ИБ-руководителя, независимого эксперта по практической информационной безопасности в финтехе.
Мысли навеяны ежедневным на протяжении уже месяца прочтением новостей, сводок, отчетов и однозначных выводов уважаемых правоохранителей, отдельных ИБ-экспертов, журналистов и лиц, называющих себя непосредственными участниками (с разных сторон) описываемых событий.
Цель подготовки данного материала была сформулирована мною так: еще раз обратить внимание коллег из ИБ-сообщества на важные практически аспекты обеспечения информационной безопасности в организации, в отношении который злоумышленники планируют или уже реализовывают комплексные кибератаки. Мысли не охватывают всего спектра актуальных проблем, не учитывают отраслевую специфику, но содержат набор векторов и наводящие вопросы. Адекватные и четкие ответы на эти вопросы, а также реализованные по результатам внутреннего обсуждения ИБ-мероприятия в компании позволят затруднить для злоумышленников стандартные (имевшие место ранее) сценарии реализации целевых кибератак на выбранную российскую компанию.
Оставайтесь в безопасности!