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

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

Угроза №1. Ransomware 2.0 – вымогательство как сервис

Если раньше ransomware воспринимали как атаку на данные, то теперь это полноценная модель давления на бизнес. Классический шифровальщик работал по простой схеме: проникновение в инфраструктуру, блокировка данных, требование выкупа за расшифровку. Основной ущерб был связан именно с потерей доступа.

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

Отсюда и сервисная логика. Одни группы хакеров выступают как операторы: предоставляют платформу, инструменты и инфраструктуру для атаки. Другие работают как аффилиаты, то есть используют эту модель против конкретной компании. Это делает рынок ransomware масштабнее и снижает порог входа для атакующих.

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

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

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

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

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

Угроза №2. Атаки на цепочки поставок и доверенное ПО

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

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

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

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

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

Угроза №3. Фишинг и атаки с использованием ИИ

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

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

Дополнительный риск создают новые сценарии социальной инженерии. Используются поддельные профили в социальных сетях, сообщения от «знакомых» контактов, ссылки, замаскированные под рабочие или личные запросы. Отдельное направление – использование дипфейков в голосовых и видеокоммуникациях, когда злоумышленник имитирует конкретного сотрудника или руководителя. Еще один сценарий – рассылка ссылок через QR-коды, ведущие на поддельные сайты. Все это расширяет набор точек входа далеко за пределы электронной почты.

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

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

Угроза №4. Компрометация облаков и гибридной инфраструктуры

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

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

Отдельная зона риска – отсутствие полноценного мониторинга. Если компания не видит, что происходит в облачной части инфраструктуры, атака может остаться незамеченной и использоваться как точка входа в основной контур. Это особенно критично для гибридных сред, где облако и внутренняя инфраструктура связаны между собой: компрометация одного сегмента быстро переходит в другой.

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

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

Угроза №5. DDoS и атаки на критическую инфраструктуру

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

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

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

Уязвимость к DDoS чаще всего связана не с отсутствием отдельных средств защиты, а с архитектурными просчетами. К ним относятся недостаточный запас ресурсов, слабая сегментация инфраструктуры, отсутствие балансировки нагрузки и мониторинга, а также игнорирование малых атак, которые могут накапливаться и приводить к перегрузке. Если инфраструктура не разделена на изолированные сегменты, атака на один участок способна вывести из строя всю систему.

В гибридных средах добавляется еще один риск – распространение атаки между ИТ-системами и АСУ ТП. Без четкого разграничения и изоляции такие сценарии могут затрагивать уже не только цифровые сервисы, но и производственные процессы.

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

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

Заключение. Управляемость как ключевой фактор киберустойчивости

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

Это меняет сам подход к защите. Уже недостаточно закрывать отдельные классы угроз или усиливать отдельные средства безопасности. Уязвимость возникает на стыках – между системами, контрагентами, облачной и внутренней инфраструктурой, технологиями и людьми. Именно там атака быстрее всего находит слабое звено.

Поэтому ключевая задача сегодня – не столько «предотвратить атаку», сколько обеспечить управляемость в момент инцидента. Насколько быстро компания способна выявить проблему, локализовать ее, сохранить критичные сервисы и восстановить работу – именно это становится главным показателем устойчивости.

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

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