Ультимативный гайд по защите инфраструктуры от шифровальщиков и вайперов
Атаки с применением шифровальщиков и вайперов — одни из самых разрушительных инцидентов для бизнеса. Они приводят к финансовым потерям из‑за утечки данных, остановки работы, ущерба репутации. Причиной же становятся ошибки, допущенные при построении инфраструктуры и системы ее защиты.
В 90% компаний встречаются одни и те же критические проблемы, которые создают идеальные условия для атакующего. Такую статистику показали расследования инцидентов, связанных с шифрованием или уничтожением данных (вайпом), которые провела команда BI.ZONE DFIR (BI.ZONE Digital Forensics and Incident Response) в 2025 году. Эти данные подтверждаются и результатами работы команды BI.ZONE Compromise Assessment в компаниях, которые не знали, что уже были скомпрометированы.
В гайде мы разбираем фазы успешной атаки, в рамках которых злоумышленники эксплуатируют ошибки в защите, а также рассматриваем последствия.
Внутри каждого раздела последовательно разбираются ошибки безопасности. Закрывая эти пункты, организация значительно снижает вероятность шифрования или уничтожения данных.
Ниже представлена матрица рисков, которая систематизирует уязвимости по нескольким ключевым параметрам: фазе атаки, соответствующим тактикам MITRE ATT&CK, вероятности наличия проблемы в типовой инфраструктуре и приоритетности устранения.
| Проблема | Фаза атаки | Тактики MITRE ATT&CK | Вероятность наличия проблемы |
Приоритет исправления |
|---|---|---|---|---|
| Неконтролируемый периметр |
Initial access |
T1190 Exploit Public‑Facing Application, T1133 External Remote Services |
70% |
Критический |
| Отсутствие фильтрации в почте (фишинг) |
Initial access |
T1566.001 Phishing: Spearphishing Attachment, T1204 User Execution |
85% |
Критический |
| Отсутствие 2FA при подключении к VPN |
Initial access |
T1078 Valid Accounts |
65% |
Высокий |
| Риски при работе с партнерами (trusted relationship) |
Initial access |
T1199 Trusted Relationship |
15% |
Средний |
| Плоская сеть |
Lateral movement |
T1021 Remote Services |
80% |
Критический |
| Неполное покрытие средствами защиты конечных точек |
Defense evasion |
T1562.001 Impair Defenses: Disable or Modify Tools |
75% |
Критический |
| Невыстроенный процесс реагирования на инциденты |
Во всех фазах |
Все тактики |
80% |
Критический |
| Устаревшие протоколы и популярные уязвимости |
Initial access / privilege escalation |
T1133 External Remote Services, T1190 Exploit Public‑Facing Application, T1068 Exploitation for Privilege Escalation |
55% |
Высокий |
| Отсутствие контроля привилегированных пользователей |
Privilege escalation |
T1078 Valid Accounts, T1550.002 Use Alternate Authentication Material: Pass the Hash, T1484.001 Domain or Tenant Policy Modification: Group Policy Modification |
70% |
Критический |
| Злоупотребление легитимным ПО (RAT/PsExec/LOLBins) |
Execution / lateral movement |
T1021 Remote Services, T1569 System Services |
65% |
Высокий |
| Отсутствие мониторинга изменений в AD |
Persistence / privilege escalation |
T1484.001 Domain or Tenant Policy Modification: Group Policy Modification |
50% |
Высокий |
| Переиспользование паролей во всех сервисах |
Credential access / lateral movement |
T1078 Valid Accounts, T1110 Brute Force |
60% |
Высокий |
| Отсутствие 2FA в критических системах, некорректная архитектура доступа |
Lateral movement / impact |
T1486 Data Encrypted for Impact, T1021 Remote Services |
70% |
Критический |
| Отсутствие изоляции систем управления IT |
Lateral movement / impact |
T1486 Data Encrypted for Impact |
65% |
Высокий |
| Незащищенные или отсутствующие бэкапы |
Impact/recovery |
T1490 Inhibit System Recovery |
75% |
Критический |
| Отсутствие логов |
Impact/recovery |
T1070 Indicator Removal, T1562.002 Impair Defenses: Disable Windows Event Logging |
70% |
Высокий |
| Отсутствие DRP |
Recovery |
— |
60% |
Высокий |
| Отсутствие тестирования DRP |
Recovery |
— |
55% |
Высокий |
В этой части мы рассматриваем ключевые ошибки, которые допускают при выстраивании самой инфраструктуры и ее защиты: неконтролируемый периметр, отсутствие фильтрации в почте, отсутствие 2FA при подключении к VPN и незащищенный доступ для подрядчиков.
Оставленные на периметре тестовые серверы, устаревшие VPN‑шлюзы и незащищенные веб‑приложения часто остаются без внимания и становятся удобной точкой входа в инфраструктуру для злоумышленника. Как правило, такие системы не получают обновлений и содержат уязвимости и ошибки конфигурации, которые легко эксплуатировать. Их часто используют для первоначального доступа, хотя обычно злоумышленник комбинирует разные сценарии проникновения. Например, сначала подбирает пароль к админ-панели, а затем использует уязвимость в приложении, позволяющую выполнить код на уровне системы. В итоге атака выглядит как сочетание брутфорса и эксплуатации уязвимости.
Одна из самых распространенных ошибок конфигурации — доступный из публичной сети порт для удаленного рабочего места (Remote Desktop Protocol, RDP). По данным интернет-сканера Shodan, в России насчитывается около 80 тысяч хостов с таким портом:
Часть из них — это honeypot-ловушки, но более ста серверов содержат в названии DC или AD, что может указывать на их критически важную роль в инфраструктуре.
Само по себе наличие открытого порта не несет риска, но только при выполнении двух условий:
- Есть уверенность в надежности паролей всех пользователей, или внедрена 2FA. Как показывает практика, у каждого 50‑го локального пользователя и каждого 13‑го доменного — слабый пароль.
- Все программное обеспечение, включая ОС, регулярно обновляется. Впрочем, это не исключает риск использования 0‑day‑уязвимостей — тех, для которых обновление еще не выпустили (как недавние уязвимости в SharePoint — CVE‑2025‑53770 и CVE‑2025‑53771).
Тем не менее, даже если оба условия соблюдены, все равно раскрываются внутренние доменные имена, что дает злоумышленнику ценную информацию на этапе пассивной разведки.
Но часто условия не соблюдаются. Мы не раз сталкивались с ситуацией, когда пароли в открытом виде хранились на ресурсах, доступных извне. Причины могли быть разные. Например, ошибки в настройке веб‑сервера, которые позволяют получить доступ к данным:
Иногда проблема кроется в публично доступном Git‑репозитории, в том числе размещенном на основном сайте компании:
Часто в инфраструктуре встречаются забытые и уже устаревшие тестовые приложения. На периметре можно обнаружить не только RDP, но и различные сервисы без какой-либо аутентификации: Prometheus Node Exporter, Elasticsearch, ClickHouse, а также устаревшие версии Proxmox Virtual Environment и многое другое, что оказалось неучтенным.
Проблемы, связанные с неконтролируемым периметром:
- Неучтенные активы. Публично доступные серверы, приложения или устройства не внесены в реестр и не защищены, что делает их легкой мишенью.
- Открытые порты и сервисы. Незащищенные порты (RDP, SMB, HTTP) или уязвимые сервисы открыты для внешнего доступа, позволяя злоумышленникам получить первоначальный доступ.
- Слабые учетные данные. Отсутствие строгой парольной политики или двухфакторной аутентификации во внешних интерфейсах (VPN, веб‑приложения) упрощает атаки подбором паролей, особенно через RDP.
- Уязвимости в публичных приложениях. Непропатченные системы на внешнем периметре служат точкой входа для атакующих.
- Отсутствие мониторинга. Непрерывное сканирование и оповещение о появлении новых активов или изменении старых не ведется. Это позволяет злоумышленникам использовать сервисы для незаметного проникновения.
MITRE ATT&CK
| ID | Техника |
|---|---|
| T1190 | |
| T1133 |
Рекомендации по обеспечению безопасности внешнего периметра
Чтобы обезопасить внешний периметр организации, к защите важно подходить системно и проактивно. Ниже мы даем восемь рекомендаций, которые помогут идентифицировать внешние активы, управлять ими, защищать их, минимизируя риски эксплуатации уязвимостей и других атак.
1. Проведите полную инвентаризацию активов
В основе защиты периметра — полная и точная инвентаризация внешних активов.
Что нужно сделать:
- Первым делом создайте базу данных управления конфигурацией (configuration management database, CMDB), которая включает:
- публично доступные IP‑адреса и домены, принадлежащие организации;
- список сервисов и приложений, работающих на этих IP, с указанием портов, протоколов и версий ПО;
- информацию о владельцах активов (например, ответственных командах или подразделениях).
- Используйте инструменты автоматического обнаружения (например, Nmap, Shodan, Censys или коммерческие EASM‑решения), чтобы определить внешнюю поверхность атаки.
- Сопоставьте результаты с внутренними записями для выявления теневого IT (shadow IT) или забытых активов.
- Занесите данные в CMDB, обеспечив доступ для ответственных команд, а также регулярное обновление.
Почему это важно. Без четкого понимания, какие активы доступны извне, невозможно приоритизировать защиту или обнаружить несанкционированные сервисы.
2. Создайте процесс публикации сервисов в интернете
Любые сервисы, публикуемые в интернете, должны проходить обязательный процесс согласования:
- специалистами кибербезопасности. Они проверяют, не содержит ли сервис уязвимостей с известными эксплоитами, подключен ли хост к системе мониторинга, логируется ли доступ к веб‑ресурсам;
- сотрудниками IT‑подразделений. Они отвечают за комплексный мониторинг: observability, availability, maintainability и другие типы мониторинга.
Что нужно сделать:
- Выстройте процесс согласования публикации сервисов.
- Назначьте ответственного за контроль исполнения регламента.
Почему это важно. Публикация несогласованных сервисов в интернете кратно увеличивает риски появления shadow IT и расширяет поверхность атаки.
3. Минимизируйте поверхность атаки
После завершения инвентаризации сначала оцените необходимость каждого открытого сервиса:
- Отключите неиспользуемые порты и протоколы или заблокируйте к ним внешний доступ с помощью межсетевого экрана, внешнего либо встроенного в ОС. Оставьте открытыми только необходимые порты (например, 443 для веб‑сервисов).
- Не публикуйте в интернете протоколы удаленного управления: SSH, RPD и подобные. Если необходимо предоставить доступ к протоколам управления, используйте решения класса privileged access management (PAM).
- Используйте VPN‑подключение для всего, что возможно. Определите, какие сервисы можно переместить во внутреннюю сеть, а для каких — ограничить доступ, разрешив его только через VPN.
- Организуйте выделенную DMZ для всех сервисов, к которым необходим доступ из интернета. Ограничьте эту зону межсетевыми экранами как со стороны интернета, так и со стороны внутренней сети. Сетевой доступ в DMZ из внутренней сети и наоборот должен быть реализован по модели нулевого доверия (zero trust) — только к необходимым сервисам.
На следующем этапе рекомендуется сделать следующее:
- Проведите оценку рисков с участием заинтересованных сторон, чтобы обосновать необходимость каждого внешнего сервиса.
- Замените небезопасные протоколы (например, Telnet) на защищенные альтернативы, SSH или VPN, с использованием 2FA.
- Используйте обратные прокси или балансировщики нагрузки для маскировки серверных служб и снижения прямого воздействия извне.
Почему это важно. Сокращение поверхности атаки уменьшает возможности для злоумышленников и делает их действия более предсказуемыми. Это упрощает обнаружение атак и позволяет останавливать их на раннем этапе.
4. Настройте непрерывный мониторинг и оповещения
Внешний периметр динамичен: новые сервисы или некорректные настройки появляются регулярно. Поэтому необходим независимый источник информации о нем. Непрерывный мониторинг помогает оперативно обнаруживать несанкционированные изменения.
Что нужно сделать:
- Настройте автоматическое сканирование (ежедневное или еженедельное) для обнаружения новых IP‑адресов, сервисов или портов.
- Настройте оповещения о несанкционированных изменениях, например о новых сервисах, не внесенных в CMDB.
- Интегрируйте систему мониторинга с платформой SIEM (security information and event management) для централизованного анализа и корреляции событий безопасности. Например, правило корреляции сообщит о появлении на периметре сервиса удаленного управления или базы данных без аутентификации.
- Регулярно проводите ручной OSINT‑анализ, чтобы выявлять неучтенные и непокрытые IP‑адреса и домены.
Почему это важно. Своевременное обнаружение новых или несанкционированных сервисов предотвращает их эксплуатацию злоумышленниками.
Другая группировка — Rainbow Hyena — также применяет легитимные учетные данные (чаще всего подрядчиков) для установления первоначального доступа.
5. Внедрите проактивное управление уязвимостями
Регулярные проверки на уязвимости критически важны для выявления и устранения слабых мест в открытых сервисах. Эту работу можно совместить с непрерывным мониторингом.
Что нужно сделать:
- Чтобы выявить известные уязвимости, используйте специализированные сканеры.
- Выстройте процесс управления уязвимостями:
- Приоритизируйте устранение уязвимостей на основе их критичности и доступности эксплоитов.
- Внедрите процесс управления обновлениями. Установка патчей должна выполняться в заранее определенные сроки.
- Периодически проводите тестирование на проникновение (пентест) для выявления сложных уязвимостей, которые не обнаруживаются автоматическими сканерами.
Почему это важно. Многие атаки, в том числе с использованием шифровальщиков, нацелены на уязвимости периметра (устаревшие CMS, уязвимые серверы Exchange). Проактивное управление этими уязвимостями помогает предотвратить их.
6. Разместите внешние веб‑приложения за WAF
Даже при исправных настройках серверов и регулярных обновлениях приложения могут содержать уязвимости, через которые злоумышленники получат доступ во внутреннюю сеть.
Что нужно сделать:
- Разместите все внешние веб‑приложения, включая корпоративные порталы, API и панели администрирования, за решением web application firewall (WAF).
- Включите режим блокировки, а не только мониторинга.
- Настройте централизованный сбор логов WAF в SIEM, чтобы анализировать аномалии и выявлять попытки эксплуатации уязвимостей.
- Обеспечьте непрерывный мониторинг состояния и политики WAF.
- Регулярно обновляйте сигнатуры и политики WAF, чтобы защита учитывала новые типы атак.
Почему это важно. Даже единичная уязвимость в веб‑приложении может привести к утечке данных или компрометации инфраструктуры. WAF снижает риск эксплуатации таких уязвимостей и обеспечивает контроль над трафиком, который проходит через него.
7. Регулярно проводите аудит и обновляйте меры защиты
Безопасность достигается не разовыми мерами, а комплексной непрерывной работой. Регулярные аудиты гарантируют, что применяемые меры защиты остаются эффективными против новых угроз.
Что нужно сделать:
- Проводите ежеквартальные проверки CMDB на актуальность и полноту данных.
- Анализируйте правила межсетевых экранов, настройки доступа и мониторинга на соответствие политикам безопасности.
- Отслеживайте новые угрозы через каналы киберразведки (например, с помощью BI.ZONE Threat Intelligence), чтобы своевременно корректировать систему защиты, а также быть в курсе уязвимостей, которые активно эксплуатируются.
Почему это важно. Ландшафт угроз постоянно меняется: появляются новые уязвимости, злоумышленники внедряют новые инструменты и методы атак. Без системного и проактивного подхода к защите внешнего периметра есть риск упустить новые векторы атак, не успеть своевременно нейтрализовать угрозы.
8. Развивайте багбаунти‑программу
Привлекайте внешних исследователей к поиску уязвимостей в инфраструктуре компании. В отличие от разовых аудитов или пентестов, багбаунти-программа работает постоянно и обеспечивает непрерывный мониторинг. Этот пункт применим для компаний со зрелыми и выстроенными процессами кибербезопасности.
Что нужно сделать:
- Определите границы программы (какие сервисы, приложения, элементы инфраструктуры доступны для проверки).
- Выберите модель работы: публичная программа (для всех исследователей) или приватная (для ограниченного круга специалистов).
- Сформулируйте правила взаимодействия: что считается уязвимостью, какие векторы атак запрещены (например, социальная инженерия).
- Определите приоритеты и размер вознаграждения.
- Интегрируйте багбаунти-процессы во внутреннюю систему управления уязвимостями (vulnerability management).
Почему это важно. Багбаунти позволяет в реальных условиях эксплуатации обнаруживать уязвимости, которые остаются незамеченными для сканеров. Это также обеспечивает постоянный внешний аудит периметра свежим взглядом.
Вывод
Защита внешнего периметра требует многоуровневого подхода, включающего управление активами, непрерывный мониторинг, устранение уязвимостей и усиление контроля доступа. Использование решений класса EASM позволяет организациям значительно снизить риски атак через внешний периметр.
Атакующие часто проникают в инфраструктуру с помощью вредоносных почтовых сообщений, имитирующих легитимные. По данным исследования Threat Zone 2025, фишинг остается самым популярным методом получения первоначального доступа — его используют в 57% атак.
До сих пор более 3% сотрудников компаний переходят по фишинговой ссылке в кампаниях, нацеленных на конечного пользователя (содержат посылы «вы выиграли», «скидка скоро сгорит» и подобные). Об этом говорят данные BI.ZONE Security Fitness. Обычно цель таких кампаний — выманить персональные данные или данные платежных карт.
Чем ниже эффективность фильтрации в электронной почте, тем выше риск успешного фишинга.
Проблемы, связанные с отсутствием фильтрации:
- Пропуск фишинговых писем. Без современных систем фильтрации (например, антиспам- и антифишинг-решений) вредоносные письма достигают пользователей, увеличивая вероятность компрометации учетных данных или заражения систем.
- Отсутствие анализа вложений и ссылок. Ненастроенные или устаревшие фильтры не проверяют вложения (например, PDF, DOCX) и URL‑адреса на наличие вредоносного кода, что приводит к его исполнению.
- Недостаточная защита от целевых атак (spear phishing). Отсутствие машинного обучения или анализа поведения — технологий, применяемых в песочницах, — позволяет целевым атакам, замаскированным под легитимные письма, проходить незамеченными.
- Отсутствие DMARC/DKIM/SPF. Неправильная настройка или отсутствие этих протоколов увеличивает риск спуфинга домена, когда атакующие подделывают отправителя.
Одна из разновидностей фишинга — атаки типа fake boss через Telegram. Злоумышленники притворяются руководителями компании, чтобы подтолкнуть сотрудников выполнить указания: перевести деньги, раскрыть конфиденциальную информацию или запустить вредоносное ПО.
MITRE ATT&CK
| ID | Техника |
|---|---|
| T1566.001 | |
| T1204 |
Рекомендации по настройке фильтрации электронной почты
Для эффективной защиты почты необходимы не только технические меры, которые не позволят вредоносным письмам дойти до конечных пользователей, но и регулярное обучение сотрудников.
1. Внедрите современные антиспам- и антифишинг‑решения
Чтобы не допустить доставки вредоносных писем, используйте современные системы фильтрации, способные анализировать входящую почту в реальном времени.
Что нужно сделать:
- Разверните облачные или локальные решения для фильтрации спама и фишинга.
- Внедрите решение с функцией машинного обучения для анализа аномалий в письмах: необычных отправителей, шаблонов текста или поведенческих паттернов.
- Настройте правила для автоматического помещения в карантин подозрительных писем на основе сигнатур, репутации отправителя и содержания.
- Регулярно обновляйте базы данных угроз в используемых решениях, чтобы защититься от новых фишинговых кампаний.
- Используйте песочницу для анализа вложений в изолированной среде перед доставкой пользователю.
- Настройте сканирование URL‑ссылок для их проверки на наличие вредоносного кода или редиректов.
- Применяйте репутационные базы данных для блокировки известных вредоносных доменов.
- Настройте системы для выявления подозрительных изменений в метаданных писем (например, в заголовках или геолокации отправителя).
Почему это важно. По данным BI.ZONE Mail Security, в карантин попадает больше писем, чем доходит до пользователей. Например, в сфере финансов разрыв между числом писем в карантине и доставленных писем превысил 280%. Это говорит об огромном объеме входящей вредоносной почты, с обработкой которого сложно справиться без продвинутой системы фильтрации.
2. Настройте протоколы DMARC, DKIM и SPF
Отсутствие или неправильная настройка этих протоколов увеличивает риск спуфинга домена, когда злоумышленники подделывают отправителя.
Что нужно сделать:
- Внедрите SPF (Sender Policy Framework), чтобы указать разрешенные почтовые серверы для вашего домена.
- Настройте DKIM (DomainKeys Identified Mail) для подписи писем, что будет подтверждать их подлинность.
- Активируйте DMARC (Domain‑based Message Authentication, Reporting, and Conformance) с политикой карантина или отклонения для защиты от спуфинга.
- Регулярно анализируйте отчеты DMARC, чтобы выявлять попытки подделки домена.
Почему это важно. Отсутствие или неправильная настройка протоколов проверки подлинности позволяют атакующим маскировать фишинговые письма под легитимные, увеличивая вероятность успешной атаки.
3. Обучайте сотрудников и проводите симуляции атак
Даже при наличии качественной фильтрации угрозу представляет человеческий фактор — низкая киберграмотность сотрудников. Регулярное обучение повышает их устойчивость к фишингу.
Что нужно сделать:
- Проводите тренинги по распознаванию фишинга, обучая сотрудников выявлять подозрительные письма (например, по орфографическим ошибкам, призывам сделать что‑либо срочно).
- Регулярно проводите фишинговые симуляции, чтобы оценить бдительность коллег и скорректировать обучение.
- Внедрите политику, обязывающую сотрудников проверять подозрительные письма через отделы кибербезопасности или IT.
Почему это важно. После прохождения тренировок поведение сотрудников меняется. Согласно данным BI.ZONE Security Fitness, 37% сотрудников открывают таргетированные фишинговые письма, а 79% из открывших совершают впоследствии небезопасные действия. После обучения 49% сотрудников из тех, кто ранее открывал фишинговые письма, перестают это делать.
4. Внедрите мониторинг и реагирование на инциденты
Эффективная фильтрация требует постоянного контроля и быстрого реагирования на обнаруженные угрозы.
Что нужно сделать:
- Интегрируйте почтовые шлюзы с SIEM‑системами, чтобы мониторить подозрительную активность в реальном времени.
- Настройте оповещения о попытках доставки вредоносных писем или обхода фильтров.
- Разработайте план реагирования на инциденты, включающий изоляцию скомпрометированных учетных записей (УЗ) и анализ последствий.
Почему это важно. Быстрое обнаружение и реагирование сокращают время воздействия атаки и снижают ущерб от компрометации.
Вывод
Эффективная фильтрация электронной почты — ключевой элемент защиты от фишинга, который остается одним из основных векторов получения первоначального доступа в инфраструктуру. Внедрение современных антиспам-решений, настройка протоколов проверки подлинности отправителя, использование машинного обучения, обучение сотрудников и регулярный аудит фильтров значительно снижают вероятность успешных атак.
Использование VPN‑сервисов без 2FA значительно увеличивает риск компрометации внешнего периметра, особенно через атаки методом подбора паролей (брутфорс) или украденные учетные данные. Согласно статистике BI.ZONE Compromise Assessment, в 72% компаний не внедрена 2FA при подключении к VPN для всех пользователей. Это позволяет злоумышленникам легко получать доступ к внутренним сетям после компрометации учетных данных.
Проблемы, связанные с отсутствием 2FA:
- Уязвимость к брутфорсу. Однофакторная аутентификация, основанная только на пароле, уязвима к атакам методом подбора паролей, особенно если используются слабые или повторяющиеся.
- Компрометация учетных данных. Злоумышленники могут применять учетные данные, полученные через фишинг или утечки данных, для прямого доступа к VPN. При этом, по данным BI.ZONE Digital Risk Protection, каждая 15‑я корпоративная УЗ хотя бы раз подвергалась утечке. 2FA добавляет второй уровень проверки, что существенно затрудняет несанкционированный доступ, даже если пароль скомпрометирован.
MITRE ATT&CK
| ID | Техника |
|---|---|
| T1133 | |
| T1110 | |
| T1078 | |
| T1621 |
Рекомендации по внедрению 2FA для VPN
Для защиты VPN от несанкционированного доступа необходимо внедрить двухфакторную аутентификацию и правильно ее настроить. Это значительно снижает риски атак, использующих внешние удаленные сервисы.
1. Сделайте двухфакторную аутентификацию обязательной
Любое подключение к корпоративной VPN должно быть возможно только после успешного прохождения 2FA.
Что нужно сделать:
- Выберите подходящее решение 2FA: программные аутентификаторы (например, Google Authenticator, Microsoft Authenticator, «Яндекс Ключ»), аппаратные токены (YubiKey) или биометрические методы.
- Настройте 2FA на VPN‑серверах с использованием стандартов TOTP (time‑based one‑time password) или RADIUS.
Почему это важно. 2FA снижает вероятность успешного брутфорса или использования украденных учетных данных, блокируя доступ без второго фактора.
2. Настройте строгие политики паролей
Даже с 2FA надежные пароли остаются важной частью защиты.
Что нужно сделать:
- Внедрите политику сложных паролей (не менее 12 символов, включая буквы верхнего и нижнего регистров, цифры и специальные символы).
- Настройте регулярную смену паролей (например, каждые 90 дней) для всех УЗ VPN.
Почему это важно. Слабые пароли увеличивают вероятность успешного брутфорса, даже если внедрена 2FA.
3. Ограничьте доступ к VPN
Это поможет минимизировать поверхность атаки.
Что нужно сделать:
- C помощью GeoIP настройте мониторинг сетевых подключений к VPN из нетипичных регионов.
- Используйте клиентские сертификаты в дополнение к другим методам 2FA.
Почему это важно. Ограничение доступа снижает количество потенциальных точек входа, особенно для VPN, доступных из интернета.
4. Подключите мониторинг подозрительной активности
Непрерывный мониторинг помогает своевременно выявлять попытки брутфорса или несанкционированного доступа.
Что нужно сделать:
- Интегрируйте VPN‑логи с SIEM‑системами, чтобы анализировать события безопасности в реальном времени.
- Реализуйте в SIEM правила корреляции о многократных неудачных попытках подключения к VPN и массовых запросах второго фактора.
- Рассмотрите возможность реализации правил корреляции на подключения из нетипичных для пользователей геолокаций, быструю смену геолокации, а также подключение с нового устройства. Данные правила могут быть применимы не для всех инфраструктур и генерировать большое количество ложных срабатываний, однако могут стать полезны для выявления скомпрометированных УЗ VPN.
- Регулярно проверяйте учетные данные на предмет утечек.
Почему это важно. Оперативное обнаружение подозрительной активности, связанной с учетными записями, позволяет блокировать атаки до того, как они достигнут успеха.
Вывод
Отсутствие двухфакторной аутентификации в VPN открывает путь для атак, использующих подбор паролей и украденные учетные данные. Внедрение 2FA, строгой парольной политики, ограничения доступа, непрерывного мониторинга и регулярного аудита значительно повышает уровень защищенности VPN‑подключения.
Сложно представить, чтобы современная организация не привлекала внешних партнеров для работы в своей инфраструктуре. Однако такие доверительные отношения (trusted relationship) несут в себе риски, поскольку партнеры, подрядчики и поставщики получают доступ к инфраструктуре. Компрометация одного из них может привести к очень быстрой компрометации самого заказчика.
Проблемы, связанные с доверительными отношениями:
- Неконтролируемый доступ для подрядчиков. Внешние компании часто имеют прямой доступ к администрируемым ими хостам (VPN, RDP), причем на их УЗ нередко отсутствует мониторинг или MFA. Это позволяет злоумышленникам использовать их как точку входа.
- Использование облачной инфраструктуры. Хотя само по себе это не является проблемой, важно быть уверенным, что провайдер обеспечивает достаточный уровень безопасности. Отсутствие мониторинга со стороны провайдера создает прямые риски для компании-клиента.
- Скрытая компрометация. Подрядчик может быть уже заражен, что позволяет злоумышленникам использовать его учетные данные для проникновения в вашу сеть.
MITRE ATT&CK
| ID | Техника |
|---|---|
| T1199 |
Рекомендации при работе с подрядчиками
Для минимизации рисков, связанных с доверительными отношениями, необходимо внедрить строгий контроль доступа, а также регулярный аудит и мониторинг действий партнеров.
1. Проведите аудит партнеров и зависимостей
Начните с полной инвентаризации внешних связей и предоставленных доступов.
Что нужно сделать:
- Создайте реестр подрядчиков, поставщиков и SaaS‑сервисов (внешних хостингов, облачных CRM) с указанием уровня доступа, условий контрактов и сроков их действия.
- Оцените риски каждого партнера, например, с помощью скоринга: история инцидентов, соответствие стандартам вроде ISO 27001 и другие параметры.
- Проводите ежегодный аудит доступов, включая проверку на наличие уязвимостей в инфраструктуре партнеров.
Почему это важно. По данным BI.ZONE DFIR, за первые три квартала 2025 года более 31% атак начинались через уже скомпрометированных подрядчиков.
2. Внедрите строгий контроль доступа
Применяйте принцип наименьших привилегий (least privilege) для минимизации рисков.
Что нужно сделать:
- Предоставляйте временный доступ (just‑in‑time) через решения класса PAM.
- Используйте персонифицированные УЗ для пользовательских подключений из сетей подрядных организаций, поставщиков или дочерних структур.
- Используйте MFA и клиентские сертификаты для всех подключений подрядчиков (VPN, API).
- Сегментируйте сеть — изолируйте зоны для подрядчиков, а также используйте гранулярное управление сетевым доступом в точках сопряжения с сетями сторонних организаций.
Почему это важно. Атаки с использованием шифровальщиков часто эксплуатируют избыточные доступы подрядчиков, чтобы проникнуть в сеть компании-жертвы.
3. Подключите мониторинг активности подрядчиков
Непрерывно отслеживайте действия подрядчиков в вашей инфраструктуре.
Что нужно сделать:
- Интегрируйте логи доступа в SIEM‑систему, чтобы выявлять подозрительные действия (например, необычные IP или объемы данных).
- Настройте оповещения о подозрительной активности (например, вход с необычных IP или несанкционированные изменения).
- Мониторьте сетевой трафик из сетей подрядчиков с помощью решений NTA (network traffic analysis).
- Мониторьте информационное пространство на предмет сообщений о компрометации компаний, которые имеют доступ к вашей сети.
Почему это важно. Активный мониторинг позволит выявить подозрительные события до того, как атакующие выполнят деструктивные действия.
4. Закрепите безопасность на юридическом уровне
Обезопасьте отношения с подрядчиками через четкие договорные обязательства.
Что нужно сделать:
- Включите в контракты требования к кибербезопасности: обязательные аудиты, уведомления об инцидентах в течение 24 часов и соответствие отраслевым стандартам.
- Используйте страхование от киберрисков, покрывающее риски компрометации через подрядчика (trusted relationship).
Почему это важно. Юридические меры снижают финансовые риски для компании.
5. Проводите регулярный аудит и обновляйте политики
Политики безопасности должны успевать за изменениями в работе с подрядчиками и новыми угрозами.
Что нужно сделать:
- Проводите ежеквартальный аудит реестра подрядчиков и их доступов.
- Своевременно обновляйте политики безопасности в соответствии с новыми угрозами (например, 0‑day‑уязвимостями в цепочке поставок).
- Интегрируйте результаты аудита в общий план реагирования на инциденты (disaster recovery plan, DRP).
Почему это важно. Отсутствие аудита действий подрядчиков создает значительные риски, поскольку скомпрометированный партнер может стать точкой входа для атакующих.
Вывод
Внедрение регулярных аудитов, строгого контроля доступа, непрерывного мониторинга и юридических мер защиты снижает вероятность атак trusted relationship. Решения класса PAM помогают организовать безопасный доступ подрядчиков в инфраструктуру.
После того как злоумышленник проник внутрь периметра, его главная цель — расширить контроль, захватить критические системы и создать условия, чтобы нанести максимальный ущерб. Успех атакующего напрямую зависит от того, насколько устойчива инфраструктура. В этой главе мы рассматриваем ошибки защиты, ускоряющие компрометацию: плоские сети, неконтролируемые привилегии и слепые зоны в мониторинге.
Отсутствие сегментации сети — или плоская сеть — позволяет злоумышленникам, получившим первоначальный доступ, быстро перемещаться по инфраструктуре и наносить максимальный ущерб при деструктивных атаках. Такая сеть характеризуется минимальными барьерами между системами, что существенно упрощает киберпреступникам этап горизонтального перемещения (lateral movement).
Проблемы, связанные с плоской сетью:
- Отсутствие барьеров для перемещения и закрепления. Если не применять методы сегментации, например VLAN, ACL или FW, злоумышленники могут беспрепятственно использовать такие протоколы, как SMB, WMI, RPC/DCOM, WinRM / PowerShell Remoting, RDP, SSH, для доступа к любым системам в инфраструктуре.
- Упрощенный доступ к критическим системам. Доменные контроллеры, серверы баз данных или системы управления (например, ESXi) становятся доступными без каких-либо дополнительных ограничений.
- Сложности мониторинга. Из‑за плоской сети труднее выявлять аномалии, поскольку трафик между различными сегментами не фильтруется.
- Неэффективное использование сетевых СЗИ. Так как сетевые потоки не разделяются, невозможно корректно настроить сетевые СЗИ. Из‑за этого системы либо генерируют чрезмерное количество ложных срабатываний, либо пропускают критические сигнатуры. Кроме того, возникает нехватка технических ресурсов, необходимых для обработки трафика со всей инфраструктуры, а не из конкретного сегмента.
MITRE ATT&CK
| ID | Техника |
|---|---|
| T1021 | |
| T1210 | |
| T1550 | |
| T1557 |
Рекомендации по устранению рисков, связанных с плоской сетью
Внедрение сегментации, контроля доступа и мониторинга затрудняют этап горизонтального перемещения для злоумышленников. Это снижает вероятность успеха атак с применением шифровальщиков и вайперов, а также минимизирует потенциальный ущерб.
1. Сегментируйте сеть
Разделение сети на изолированные сегменты ограничивает свободу перемещения злоумышленников.
Что нужно сделать:
- Разделите рабочие станции, серверы, критические системы и зоны для подрядчиков на сетевые сегменты.
- Рассмотрите возможность ограничения сетевого доступа между пользовательскими рабочими станциями по следующим протоколам: DCOM, SMB, RDP, WinRM. Такое ограничение усложнит перемещение атакующего между хостами корпоративной сети в случае компрометации.
- Создайте отдельный сегмент (DMZ) для сервисов, опубликованных в интернете, с ограничением доступа из него во внутреннюю сеть.
- Настройте списки контроля доступа (ACL) на маршрутизаторах и межсетевых экранах, чтобы фильтровать трафик между сегментами. Избегайте слишком широких политик, стремитесь к гранулярным правилам.
- Проанализируйте, какой ущерб может быть нанесен инфраструктуре в случае компрометации каждого сервиса. Если компрометация одного сервиса ставит под удар другие, необходимо пересмотреть его архитектуру.
Почему это важно. Сегментация снижает вероятность развития атаки и масштаб потенциального деструктивного воздействия.
2. Внедрите jump‑хосты для администраторов
Привилегированный доступ нужно изолировать и строго контролировать. Для этого рекомендуется настроить jump‑хосты.
Что нужно сделать:
- Настройте выделенные jump-хосты для доступа администраторов к серверам и критическим системам.
- Внедрите 2FA и сертификаты клиентов для входа на jump‑хосты.
- Обеспечьте логирование всех действий на jump-хостах и интеграцию этих логов с SIEM‑системами.
Почему это важно. По статистике BI.ZONE DFIR, 95% атак с шифрованием используют скомпрометированные учетные данные администраторов. Jump‑хосты ограничивают прямой доступ к критическим системам, снижая риск компрометации доменных контроллеров или систем управления вроде ESXi.
3. Внедрите мониторинг сетевого трафика
Непрерывные логирование и мониторинг сетевого трафика помогают своевременно обнаруживать подозрительные перемещения в сети.
Что нужно сделать:
- Разверните системы обнаружения и предотвращения вторжений (IDS/IPS) или анализа аномалий трафика (NTA/NDR).
- Интегрируйте сетевые логи с SIEM‑системой для корреляции событий и выявления аномалий.
- Интегрируйте сетевые логи с TI‑платформой для выявления подключений к серверам управления (C2) или прокси‑серверам.
- Настройте алерты на подозрительные события — например, на массовые попытки подключения по RDP или SMB, доступы из DMZ к интерфейсам управления (SMB, RDP, SSH, WMI и т. п.) на хостах внутри сети.
Почему это важно. Обнаружение атаки на этапе перемещения позволяет устранить угрозу до того, как наступят критические для бизнеса события.
4. Обучите сотрудников и администраторов
Человеческий фактор напрямую влияет на эффективность сетевой защиты, поскольку администраторы часто открывают излишние сетевые каналы, чтобы упростить себе работу.
Что нужно сделать:
- Регулярно проводите для администраторов тренинги, посвященные принципам сегментации и безопасному использованию jump‑хостов.
- Внедрите политику администрирования.
Почему это важно. Даже после архитектурных изменений систему продолжит эксплуатировать человек, который постарается упростить себе задачи. Сотрудники должны понимать значимость и обоснованность внедренных ограничений.
Вывод
Плоская сеть — критическая архитектурная уязвимость, которая позволяет злоумышленникам быстро распространяться по инфраструктуре и компрометировать важные системы. Сегментация, ограничение использования сетевых протоколов, внедрение jump-хостов и регулярный мониторинг значительно снижают эти риски.
Если в инфраструктуре нет полного покрытия антивирусными решениями (AV) или системами обнаружения и реагирования на конечных точках (EDR), в ней возникают слепые зоны. В них злоумышленники могут незаметно закрепляться и перемещаться. Под неполным покрытием подразумевается не только отсутствие агентов на всех хостах, но и неэффективное использование существующих инструментов из‑за недостаточной квалификации команды безопасности.
Типичный набор проблем в таких организациях:
- При вопросе о прошлых инцидентах выясняется, что сотрудники получают много фишинга с троянами.
- СЗИ — даже антивирусное решение — часто отсутствуют.
- Нет ни одного специалиста по кибербезопасности.
- Руководитель решает развивать направление безопасности только после инцидента.
Проблемы, связанные с AV‑/EDR‑решением:
- Неполнота покрытия. Хосты без EDR (например, устаревшие серверы или элементы shadow IT) становятся идеальной площадкой для запуска таких инструментов, как Cobalt Strike Beacon или gsocket. Действия атакующего на таких хостах остаются незамеченными.
- Устаревшие или неактуальные решения. Стремление сэкономить и использовать бесплатные антивирусы может повлечь за собой куда более серьезные финансовые потери, чем расходы на реальную защиту. Даже коммерческие продукты, в которых базы правил EDR и антивирусные базы обновляются нерегулярно, не способны распознавать новые угрозы, включая шифровальщики (такие как LockBit или Conti), которые активно развиваются для обхода защиты.
- Отсутствие ответственных за мониторинг. Журналы AV‑систем нужно регулярно просматривать: часто успешной компрометации предшествует множество неудачных попыток или отключение AV‑системы.
- Некорректные настройки AV‑/EDR‑решений. Ради производительности критически важные модули детектирования часто отключают или добавляют излишне широкие исключения, что не позволяет системе функционировать полноценно.
- Отсутствие ограничений на отключение AV‑/EDR‑агентов. Это позволяет атакующему легко отключить AV‑/EDR‑агент и таким образом обойти защиту конечных точек.
- Отсутствие централизованного мониторинга. Разрозненные AV‑системы без единой консоли затрудняют корреляцию событий, позволяя атакующим оставаться в сети неделями.
MITRE ATT&CK
| ID | Техника |
|---|---|
| T1562.001 |
Рекомендации, как обеспечить полное покрытие AV‑/EDR‑решением
Чтобы повысить устойчивость к атакам, необходимо обеспечить полное покрытие инфраструктуры СЗИ с учетом критичности систем. Ключевыми факторами безопасности остаются централизованный мониторинг и постоянное развитие компетенций команды. В совокупности эти меры существенно снижают риск успешного закрепления злоумышленников.
1. Обеспечьте полное покрытие агентами
Убедитесь, что AV- и EDR‑агенты установлены на всех хостах, включая рабочие станции, серверы и виртуальные машины.
Что нужно сделать:
- Проведите аудит инфраструктуры, чтобы выявить все устройства (включая shadow IT). В этом помогут такие инструменты, как NetBox, Active Directory или средства сетевого сканирования.
- Разверните AV- и EDR‑агенты на 100% хостов.
- Настройте автоматическое развертывание агентов для новых устройств через следующие средства массовой доставки приложений: GPO (group policy objects) в Active Directory, SCCM и Ansible. Также добавьте установочный файл в золотой образ, используемый для развертывания новых хостов.
- Настройте самозащиту AV‑/EDR‑агентов, чтобы пользователи или злоумышленники не могли отключить средства защиты.
Почему это важно. По нашим данным, в 65% компаний не установлено даже централизованное антивирусное решение. EDR‑решение работает только в 10% компаний.
2. Внедрите централизованное управление и мониторинг
Единая консоль упрощает анализ угроз и реагирование на них. Необходимость переключаться между несколькими консолями снижает скорость реакции аналитика и усложняет контроль происходящих событий.
Что нужно сделать:
- Внедрите централизованную консоль для AV- и EDR‑решений.
- Настройте сбор логов со всех средств защиты в едином месте для удобства корреляции событий.
- Настройте автоматизированные оповещения о срабатываниях, аномалиях и статусе агентов (например, об их отключении или устаревших базах данных).
- Регулярно обновляйте базы сигнатур и модели машинного обучения для распознавания новых угроз.
Почему это важно. Наша практика показывает: если отсутствует централизация, срабатывания игнорируются. AV‑решение может в течение дней и недель сигнализировать о вредоносном ПО, но аналитики просто не замечают уведомления.
3. Развивайте компетенции команды реагирования
Прокачанные навыки обороняющейся команды — ключевой фактор эффективности стратегии защиты, поэтому важно инвестировать в обучение и отлаженные процессы.
Что нужно сделать:
- Проводите регулярные тренинги по анализу срабатываний, включая распознавание ложных срабатываний (false positive) и реальных угроз.
- Внедрите разбор каждого срабатывания с обязательным вынесением вердикта.
- Организуйте командные учения (tabletop exercises) и симуляции атак (red teaming), чтобы отработать реагирование на реалистичных сценариях, включая случаи пропущенных срабатываний.
- Используйте BAS‑фреймворки, такие как Caldera, OpenBAS, Infection Monkey или их коммерческие аналоги, чтобы дополнить регулярные учения и проверить процессы реагирования.
Почему это важно. Постоянный рост компетенций команды позволяет ей выявлять актуальные и новые угрозы.
4. Настройте мониторинг статуса агентов СЗИ и интеграцию с SIEM
Активный контроль предотвращает отключение или модификацию средств защиты злоумышленниками.
Что нужно сделать:
- Настройте ежедневный отчет о статусе агентов (активность, версия баз, HealthCheck) и автоматическую блокировку хостов без активного агента (например, по принципам ZTNA).
- Интегрируйте СЗИ с SIEM‑системами для корреляции событий с другими источниками (логи AD, сетевой трафик).
Почему это важно. Если злоумышленник отключит СЗИ, команда вовремя не получит с него логи и может пропустить атаку.
Вывод
Злоумышленникам проще незаметно закрепляться в сети и перемещаться по ней, если инфраструктура не полностью покрыта СЗИ или защита отсутствует вовсе, а сотрудники недостаточно компетентны в области реагирования. Полное покрытие, централизация управления, развитие навыков команды и регулярное тестирование защиты значительно снижают эти риски.
Злоумышленники могут оставаться в сети месяцами или даже годами, распространяя ВПО и готовя финальный ущерб. Бывают и обратные ситуации, когда атака развивается стремительно. В обоих случаях, если в компании не выстроено реагирование на инциденты кибербезопасности, ущерб от атак увеличивается.
Проблемы, вызванные неналаженным процессом реагирования:
- Запоздалое обнаружение атаки. Если нет четких процедур, как EDR- и SIEM‑решения реагируют на события безопасности, оповещения обрабатываются постфактум, когда данные уже зашифрованы.
- Недостаток компетенций в реагировании у сотрудников. Даже при наличии СЗИ их срабатывания могут игнорироваться. Нам известны случаи, когда антивирус более месяца ежедневно сигнализировал о ВПО, но в логи никто не заглядывал из‑за перегруженности команды или отсутствия квалифицированных специалистов. В другом инциденте срабатывание ошибочно квалифицировалось как false positive без должного анализа. Это позволило атаке развиться и привело к полному уничтожению данных в инфраструктуре.
- Нескоординированное реагирование. Отсутствие плана приводит к хаотичным действиям. Например, к отключению систем без предварительного анализа, что может помешать полноценному расследованию.
- Отсутствие эскалации. Без четкой цепочки уведомлений и распределения ролей (например, кто отвечает за анализ, а кто — за коммуникацию) инциденты часто остаются без внимания руководства. Это мешает в полной мере оценить критичность атаки и ее влияние на бизнес.
- Стремление как можно быстрее восстановить систему, а не расследовать инцидент. Это повышает риск повторного инцидента. Мы часто наблюдали ситуации, когда компания восстанавливала инфраструктуру после компрометации, но не проводила расследование. В результате через несколько месяцев инфраструктура вновь оказывалась недоступна.
Рекомендации по выстраиванию реагирования
Чтобы сократить время пребывания злоумышленников в сети и снизить вероятность успеха атак, необходимо структурировать подход к обнаружению, анализу и устранению инцидентов.
1. Разработайте процесс реагирования и задокументируйте его
Что нужно сделать:
- Формализуйте процесс реагирования (incident response, IR), включающий следующие этапы: обнаружение, анализ, изоляция, устранение, восстановление и постанализ (основываясь на таких фреймворках, как NIST SP 800‑61 или SANS IR).
- Определите роли и зоны ответственности сотрудников (например, аналитик SIEM, координатор IR, ответственный за коммуникацию с руководством).
Почему это важно. Заранее сформированный план с разделением ролей позволяет в момент инцидента сосредоточиться на реагировании, а не решать организационные вопросы.
2. Развивайте компетенции CSIRT
Обучите сотрудников корректному анализу и реагированию на инциденты.
Что нужно сделать:
- Организуйте для команды кибербезопасности и руководства практические занятия по симуляции сценариев атак (например, с шифровальщиками).
- Проводите тестирования на проникновение, чтобы выявить и закрыть слепые зоны, где активность атакующих осталась незамеченной.
- Проводите тестирования red team.
- Тестируйте IR‑план на различных сценариях, таких как компрометация учетной записи или запуск PsExec.
- Анализируйте ключевые метрики: среднее время до обнаружения (MTTD) и среднее время реагирования (MTTR).
Почему это важно. Чем выше компетенция команды, тем раньше будет выявлена атака и тем менее серьезными окажутся последствия.
3. Интегрируйте процесс реагирования с DRP
Обеспечьте связь IR‑процесса с планом аварийного восстановления, чтобы минимизировать ущерб от атак.
Что нужно сделать:
- Интегрируйте IR‑план с DRP, включив процедуры восстановления из резервных копий.
- Разработайте регламенты коммуникации с регуляторами и партнерами на случай инцидента.
- Регулярно проверяйте готовность DRP с помощью симуляций восстановления после атак.
Почему это важно. Заранее спланированные действия и четкие инструкции позволяют тратить меньше времени на согласования в критической ситуации.
Вывод
Внедрение четкого IR‑плана, централизованного мониторинга, регулярного обучения команды и тестирования помогает сократить время присутствия злоумышленников и минимизировать ущерб.
Устаревшие сетевые протоколы (такие как SMBv1 или RDP без аутентификации на уровне сети — NLA), известные уязвимости вроде EternalBlue или PrintNightmare, а также мисконфигурации (например, техники ESC) позволяют злоумышленникам легко закрепиться в сети и перемещаться по ней. Как и в случае с внешним периметром (см. раздел «Неконтролируемый периметр»), где уязвимости публичных сервисов служат точкой входа, внутренние уязвимости позволяют злоумышленникам повышать привилегии и перемещаться по инфраструктуре.
Проблемы, связанные с ошибками в управлении уязвимостями и мисконфигурациями:
- Устаревшие протоколы. SMBv1 (используемый в атаке EternalBlue, CVE‑2017‑0144) или RDP без NLA позволяют выполнять код удаленно и перемещаться между системами. Эти протоколы часто остаются включенными, чтобы обеспечивать совместимость между системами. Их эксплуатация внутри сети может привести к массовому заражению, как это произошло с WannaCry.
- Распространенные уязвимости для повышения привилегий и перемещения:
- EternalBlue (CVE‑2017‑0144). Использует уязвимость в SMB для распространения ВПО по сети;
- PrintNightmare (CVE‑2021‑34527 и CVE‑2021‑1675). Уязвимость в Print Spooler, позволяющая повысить привилегии до уровня SYSTEM;
- другие известные уязвимости. BlueKeep (CVE‑2019‑0708) для RDP, ProxyShell (CVE‑2021‑34473) для Exchange или Log4Shell (CVE‑2021‑44228) в Java-приложениях — все они дают злоумышленникам возможность закрепляться в системе и перемещаться по ней.
- Нерегулярные обновления. Неналаженный процесс управления обновлениями (patch management) приводит к эксплуатации известных уязвимостей. В плоской сети это увеличивает риски.
MITRE ATT&CK
| ID | Техника |
|---|---|
| T1190 | |
| T1210 | |
| T1212 | |
| T1068 |
Рекомендации по устранению устаревших протоколов и уязвимостей
Для предотвращения атак, использующих устаревшие протоколы и известные уязвимости, необходимо регулярно обновлять ПО, отключать неиспользуемые протоколы и обеспечивать постоянный мониторинг. Эти меры во многом перекликаются с мерами по защите периметра.
1. Отключите устаревшие протоколы
Минимизируйте использование уязвимых протоколов, чтобы предотвратить их эксплуатацию.
Что нужно сделать:
- Отключите SMBv1 и RDP без NLA с помощью GPO в Active Directory или через реестр Windows.
- Замените устаревшие протоколы на их современные аналоги (SMBv3 с шифрованием, RDP с NLA и 2FA).
Почему это важно. Уязвимости в SMB остаются актуальными и в настоящий момент. Чем меньше в сети уязвимых протоколов, тем ниже риск полномасштабной компрометации инфраструктуры.
2. Управляйте уязвимостями и мисконфигурациями проактивно
Регулярно сканируйте системы и устраняйте известные уязвимости.
Что нужно сделать:
- Используйте сканеры уязвимостей (Nessus, OpenVAS, функциональные возможности EDR‑агентов), чтобы своевременно выявлять угрозы.
- Обновляйте ПО в установленные сроки: для защиты от критических уязвимостей — в течение семи дней.
- Исправляйте выявленные мисконфигурации в зависимости от их критичности и важности бизнес-систем.
- Отключите ненужные сервисы, такие как Print Spooler, на серверах, где они не требуются, — например, на контроллерах домена.
Почему это важно. Большинство инцидентов можно предотвратить, своевременно обновляя хосты.
3. Сегментируйте сеть и настройте контроль доступа
Изолируйте уязвимые системы, чтобы ограничить возможность их эксплуатации. Если обновить технологический сегмент невозможно, строго ограничьте к нему доступ.
Что нужно сделать:
- Ограничьте доступ к сегментам сети с устаревшими системами, которые нельзя обновить. Используйте для этого jump-хосты с 2FA.
- Внедрите сегментацию сети (VLAN, ACL) для ограничения трафика, использующего устаревшие протоколы, такие как Telnet, SNMP v1/v2c, NetBIOS/SMBv1.
Почему это важно. Сегментация снижает радиус автоматизированного сканирования и поиска новых хостов для закрепления. Таким образом она предотвращает перемещение злоумышленника внутри сети.
4. Внедрите мониторинг
Настройте мониторинг, чтобы выявлять попытки использования уязвимостей.
Что нужно сделать:
- Настройте сбор и корреляцию событий в SIEM‑системе для обнаружения атак, использующих популярные уязвимости.
- Настройте оповещения о подозрительном трафике (например, использовании SMBv1 или активности службы Print Spooler) с помощью систем IDS/IPS или решений класса NTA/NDR.
Почему это важно. Обнаружение массовых сканирований и попыток эксплуатации уязвимостей позволяет выявить атаку до того, как она приведет к критическим последствиям.
Вывод
Устаревшие протоколы и известные уязвимости, такие как EternalBlue или PrintNightmare, остаются актуальными угрозами в 2025 году и повышают риск полной компрометации инфраструктуры. Чтобы сократить количество критических уязвимостей, которые атакующие могут использовать для перемещения и закрепления в сети, рекомендуем использовать следующие меры:
- отключение опасных протоколов,
- своевременное обновление ПО,
- сегментация сети,
- непрерывный мониторинг.
Недостаточный контроль над учетными записями администраторов доменов или IT‑персонала с высокими правами создает в инфраструктуре критические уязвимости. Компрометация таких УЗ позволяет злоумышленникам получить полный контроль над сетью, включая доменные контроллеры, системы управления (например, ESXi) и другие критически важные сервисы.
Проблемы, связанные с отсутствием контроля привилегированных пользователей:
- Некорректная настройка restricted groups. Администраторы домена часто входят на рабочие станции или некритические серверы (например, терминальные), где их учетные данные кешируются и могут быть скомпрометированы с помощью таких инструментов, как Mimikatz. Часто встречается практика, когда учетные данные администратора, оставшиеся в памяти терминального сервера, приводят к полной компрометации домена.
- Некорректная настройка Protected Users. Если критические УЗ не включены в эту группу или используются в некритических системах, их аутентификационные данные могут быть скомпрометированы и использованы для полного доступа к домену.
- Отсутствие разделения учетных записей. Использование одной УЗ для повседневных задач и для административных функций многократно увеличивает риск компрометации.
- Недостаточный мониторинг действий. Если не собирать логи и не анализировать активность привилегированных пользователей, такие атаки, как pass‑the‑ticket, остаются незамеченными.
- Незавершаемые RDP‑сессии. Открытые или неразорванные сеансы удаленного доступа позволяют злоумышленникам использовать активные токены и сессии, чтобы получить привилегированный доступ к системам и домену.
- Слабые пароли или отсутствие 2FA. Привилегированные УЗ часто защищены слабыми паролями или не имеют двухфакторной аутентификации, что упрощает брутфорс-атаки и использование украденных данных. Например, в 25% компаний, с которыми работала команда BI.ZONE Compromise Assessment, обнаружили как минимум одну УЗ доменного администратора со слабым паролем.
MITRE ATT&CK
| ID | Техника |
|---|---|
| T1078 | |
| T1003 | |
| T1550.003 | |
| T1484.001 |
Domain or Tenant Policy Modification: Group Policy Modification |
Рекомендации по контролю привилегированных пользователей
Для предотвращения атак, нацеленных на привилегированные УЗ, необходимо внедрить строгие политики доступа и непрерывный мониторинг, а также обучить сотрудников. Эти меры снижают риск компрометации и помогают защитить инфраструктуру от шифровальщиков и вайперов.
1. Внедрите политику restricted groups в Active Directory
Чтобы предотвратить компрометацию учетных данных привилегированных пользователей, ограничьте им вход в некритические системы.
Что нужно сделать:
- Настройте политику групп с ограниченным доступом в Active Directory через GPO, чтобы запретить вход привилегированных групп на рабочие станции и некритические серверы.
- Определите, какие группы нужно ограничить (например, администраторов домена), и настройте GPO для автоматического удаления этих УЗ из локальных групп администраторов на хостах.
- Регулярно проверяйте корректность настроек GPO с помощью аудита (например, через PowerShell-скрипты).
Почему это важно. Ненастроенная политика групп с ограниченным доступом может приводить к компрометации учетных данных администратора на терминальном сервере. Это позволяет атакующим получить доступ к доменному контроллеру за считаные часы с момента попадания в инфраструктуру.
2. Разделяйте учетные записи
Используйте отдельные УЗ для административных и повседневных задач.
Что нужно сделать:
- Создайте отдельные УЗ для административных функций (например, с суффиксом
-admin) с усиленными мерами защиты. - Запретите использовать привилегированные УЗ для входа на рабочие станции, в почтовые клиенты или другие некритические системы.
- Внедрите функцию Windows LAPS для управления уникальными паролями локальных администраторов.
Почему это важно. Такие настройки не позволят критическим УЗ кешировать пароли в общедоступных системах. А внедрение Windows LAPS предотвращает компрометацию всей инфраструктуры при взломе одного локального администратора.
3. Внедрите двухфакторную аутентификацию
Защитите привилегированные УЗ дополнительным уровнем аутентификации.
Что нужно сделать:
- Настройте 2FA (например, через Microsoft Authenticator, YubiKey) для всех привилегированных УЗ при входе на jump-хосты или в критические системы.
- Чтобы усилить контроль, используйте сертификаты клиентов в дополнение к 2FA.
- Настройте временные коды (TOTP) или пуш‑уведомления, чтобы минимизировать риск перехвата.
Почему это важно. Внедрение 2FA не позволит злоумышленнику, получившему пароль из утечки или текстового файла, получить доступ к критической системе.
4. Внедрите мониторинг и аудит действий привилегированных пользователей
Непрерывный контроль активности помогает выявить несанкционированные действия.
Что нужно сделать:
- Собирайте в SIEM‑систему логи входов и действий привилегированных пользователей.
- Включите оповещения о подозрительных действиях, таких как вход с необычных IP‑адресов или массовое изменение политик.
- Используйте анализ поведения пользователей и объектов (user and entity behavior analytics, UEBA), чтобы выявлять аномалии, например вход в нерабочее время (часто шифрование данных запускается вечером в пятницу или на выходных).
Почему это важно. По нашим данным, ни одна атака с полным шифрованием инфраструктуры не обходится без захвата УЗ доменного администратора.
5. Внедрите защиту от атак, направленных на похищение учетных данных привилегированных пользователей из памяти или системных хранилищ
Скомпрометировав хост, атакующий может извлечь из памяти или системных хранилищ аутентификационные данные УЗ, в том числе привилегированных пользователей.
Что нужно сделать:
- Включите на всех доменных хостах принудительную очистку памяти от учетных данных при выходе пользователя из системы.
- В групповой политике запретите хранение в штатном менеджере паролей Windows учетных данных для сетевой аутентификации.
- Активируйте защиту системных процессов от несанкционированного доступа, если такая функция есть в решении для защиты конечных точек (например, «Защита памяти системных процессов» в Kaspersky Endpoint Security).
- Используйте на всех доменных хостах механизм LSA protection, чтобы защитить память процесса LSASS от доступа со стороны недоверенных процессов. Более эффективный вариант — включить защиту памяти процесса LSASS в решении для защиты конечных точек или использовать Credentials Guard в современных версиях Windows.
- Отключите или ограничьте кеширование учетных данных пользователей, чтобы снизить риск их компрометации при недоступности контроллера домена. Для стационарных хостов с постоянным подключением к корпоративной сети кеширование рекомендуется отключить, для мобильных — оставить не более 1–2 записей.
Почему это важно. Недостаточная защита памяти и системных хранилищ позволяет злоумышленникам извлечь учетные данные привилегированных пользователей и получить полный контроль над доменом.
6. Внедрите архитектуру Enhanced Security Admin Environment (ESAE)
Создайте изолированную среду для администрирования.
Что нужно сделать:
- Разверните ESAE (или аналогичную модель, например Active Directory enterprise access model) с выделенными jump-хостами для администраторов.
- Настройте изолированные рабочие станции (privileged access workstations, PAW) с минимальным доступом к внешним ресурсам.
- Обеспечьте строгую сегментацию сети для jump-хостов, исключив их из общей плоской сети.
Почему это важно. ESAE снижает риск компрометации привилегированных учетных данных в некритических системах.
7. Регулярно тестируйте и проводите аудит привилегированных учетных записей
Проверяйте настройки и выявляйте уязвимости с помощью симуляции атак.
Что нужно сделать:
- Проводите ежеквартальный аудит GPO, включая проверку привилегированных групп и политик паролей.
- Используйте инструменты вроде BloodHound, чтобы анализировать векторы атак в Active Directory.
- Проводите тестирования red team для симуляции атак, таких как pass‑the‑ticket или golden ticket.
Почему это важно. Регулярное тестирование на проникновение помогает выявить возможные пути компрометации домена.
Вывод
Отсутствие контроля привилегированных пользователей — особенно при некорректной настройке политик restricted groups — создает критические уязвимости. Они позволяют злоумышленникам в кратчайшие сроки захватить контроль над доменом. Чтобы снизить подобные риски, необходимо внедрить принцип наименьших привилегий: каждый пользователь или сервис должен обладать минимальным набором прав, необходимым для выполнения задачи. Чем меньше действующих привилегированных УЗ, тем меньше и поверхность атаки.
Корректная настройка групп с ограниченным доступом, разделение административных и пользовательских УЗ, использование 2FA, постоянный мониторинг действий привилегированных пользователей и развертывание ESAE — все это значительно снижает риски.
Злоумышленники часто маскируют свои атаки под легитимную деятельность, используя популярные инструменты удаленного доступа (remote access tools, RAT), такие как AnyDesk и TeamViewer, утилиту PsExec и ей подобные (например, PAExec) инструменты. С их помощью они перемещаются по сети и выполняют вредоносные действия. Эти же программы часто используются IT‑администраторами для рабочих задач. Из‑за этого системы мониторинга генерируют поток легитимных оповещений, и различить среди них вредоносную активность крайне сложно. В этом «шуме» злоумышленник может спокойно действовать: красть учетные данные, распространять вредоносное ПО или шифровать данные.
Проблемы, связанные со злоупотреблением легитимным ПО:
- Маскировка атак. Частое использование RAT администраторами приводит к большому количеству срабатываний в EDR- и SIEM‑системах. Среди множества оповещений легко пропустить действия злоумышленника.
- «Зоопарк инструментов». Одновременное использование различных RAT, например TeamViewer, AnyDesk, VNC, Ammyy Admin, Radmin, RustDesk (эти утилиты были встречены в рамках одного проекта), или утилит из набора Sysinternals, таких как PsExec, усложняет контроль и мониторинг, создавая хаос в управлении.
- Отсутствие строгих политик. Если не ограничивать использование RAT или PsExec (и ей подобных), злоумышленники могут беспрепятственно применять их под видом легитимной активности.
- Недостаточный мониторинг. Отсутствие поведенческого анализа позволяет злоумышленникам использовать легитимное ПО для выполнения команд.
MITRE ATT&CK
| ID | Техника |
|---|---|
| T1219 | |
| T1569.002 |
Рекомендации по ограничению злоупотребления легитимным ПО
Для предотвращения атак, использующих RAT или PsExec (и ей подобные), необходимо жестко контролировать применение этих инструментов, стандартизировать их и внедрить мониторинг.
1. Ограничьте использование RAT и PsExec
Запретите несанкционированное использование инструментов удаленного доступа и системных утилит.
Что нужно сделать:
- Создайте белый список разрешенных приложений с помощью таких инструментов, как Microsoft AppLocker, исключив из него неутвержденные RAT и системные утилиты.
- Ограничьте выполнение PsExec и других утилит (например, PowerShell) через GPO, разрешив их запуск только привилегированным УЗ.
- Настройте межсетевые экраны для блокировки трафика RAT, исходящего за пределы сети.
Почему это важно. Строгий контроль ПО позволит быстрее обнаруживать нелегитимные действия и сразу же на них реагировать.
2. Стандартизируйте инструменты
Сведите разнообразие используемых RAT и утилит к одному утвержденному решению.
Что нужно сделать:
- Выберите единый инструмент для удаленного доступа и закрепите его использование в корпоративной политике.
- Запретите установку альтернативных RAT (TeamViewer, VNC и др.) с помощью списков разрешенного ПО.
- Документируйте утвержденные инструменты и обучайте сотрудников, как их правильно использовать.
Почему это важно. Стандартизация упрощает мониторинг и снижает риски, связанные с применением неконтролируемых инструментов.
Вывод
Злоупотребление легитимным ПО, таким как RAT или PsExec, позволяет злоумышленникам маскировать атаки под обычную административную активность. Жесткий контроль, стандартизация инструментов и достаточный мониторинг позволяют снизить эти риски.
Эта небольшая глава посвящена фактору, определяющему масштаб финального ущерба, — отсутствию контроля доступа к критическим системам управления, например к VMware ESXi или контроллерам домена. Эти системы становятся первостепенными целями атакующих, поскольку их компрометация позволяет одновременно вывести из строя или зашифровать значительную часть инфраструктуры.
Когда нет ограничений на доступ к критическим системам управления, таким как контроллер домена (DC), VMware ESXi, SCCM, MDM, Zabbix или серверы управления средствами защиты конечных точек (например, Kaspersky Security Center), это создает условия для быстрого и масштабного воздействия злоумышленников. Если эти системы скомпрометированы, атакующие могут отключать защиту, распространять ВПО по всей инфраструктуре и шифровать виртуальные машины.
Эта проблема является следствием ранее описанных уязвимостей: плоской сети, отсутствия контроля привилегированных УЗ и недостаточной защиты аутентификации (например, когда не используются 2FA или jump-хосты).
Проблемы, ведущие к беспрепятственному доступу к системам управления:
- Плоская сеть. Из‑за отсутствия сегментации злоумышленник, получивший доступ к одному хосту, может свободно подключаться к ESXi, серверам управления средствами защиты конечных точек (например, Kaspersky Security Center), DC, SCCM, MDM через RDP или веб‑интерфейсы.
- Некорректно настроенные СЗИ. Шифрование данных становится возможным, когда атакующий, получив доступ к хосту, может отключить или обойти средства защиты.
- Неконтролируемые привилегированные УЗ. Доменные УЗ администраторов, используемые для входа в системы управления, часто не ограничены (например, через restricted groups) и могут быть скомпрометированы в некритических системах.
- Отсутствие 2FA и jump-хостов. Это упрощает атакующим доступ, особенно если учетные данные украдены через фишинг или Mimikatz.
MITRE ATT&CK
| ID | Техника |
|---|---|
| T1078 | |
| T1021.001 | |
| T1489 | |
| T1486 | |
| T1561 |
Рекомендации по ограничению доступа к критическим системам управления
Важно устранить корневые проблемы, описанные в предыдущих разделах, и внедрить дополнительные меры защиты. Так как большинство решений уже подробно рассмотрены выше, повторим ключевые рекомендации.
1. Сегментируйте сеть
Изолируйте системы управления в отдельные сетевые сегменты.
Что нужно сделать:
- Изолируйте ESXi и серверы управления средствами защиты конечных точек в отдельные сетевые сегменты.
- Разрешите доступ к системам управления только с выделенных jump-хостов.
Почему это важно. Сегментация снижает возможности для атаки, предотвращая прямой доступ к ESXi и серверам управления средствами защиты конечных точек (например, KSC).
2. Контролируйте привилегированные УЗ
Ограничьте использование доменных УЗ для входа в системы управления.
Что нужно сделать:
- Внедрите механизмы вроде restricted groups и ESAE, чтобы запретить вход доменных администраторов в некритические системы.
- Для доступа к ESXi и серверам управления средствами защиты конечных точек (например, KSC) используйте локальные УЗ с уникальными сложными паролями вместо доменных.
Почему это важно. Без привилегированной УЗ злоумышленник не сможет нанести инфраструктуре критический ущерб.
3. Внедрите 2FA и jump‑хосты
Защитите доступ к системам управления дополнительными барьерами.
Что нужно сделать:
- Настройте 2FA для всех входов в ESXi и на серверы управления средствами защиты конечных точек (например, KSC).
- Разверните изолированные от остальной сети jump-хосты для администрирования.
- Чтобы усилить защиту, используйте клиентские сертификаты вместе с 2FA.
Почему это важно. 2FA и jump-хосты снижают риск использования украденных учетных данных.
4. Настройте мониторинг и аудит доступа
Регулярно контролируйте действия в системах управления, чтобы своевременно обнаруживать атаки.
Что нужно сделать:
- Интегрируйте логи ESXi и серверов управления средствами защиты конечных точек (например, KSC) с SIEM‑системой для мониторинга входов и изменений конфигураций.
- Настройте оповещения о несанкционированных попытках доступа или подозрительных изменениях.
Почему это важно. По нашим данным, 95% злоумышленников при атаках, нацеленных на шифрование и удаление данных, используют довольно «шумные» и хорошо детектируемые инструменты. Их можно обнаружить до критического события.
Вывод
Беспрепятственный доступ к критическим системам управления (ESXi, DC, серверы управления средствами защиты конечных точек) — это прямое следствие плоской сети, слабого контроля привилегированных УЗ и отсутствия 2FA и jump-хостов. Чтобы устранить эти риски, сегментируйте сеть, ограничьте использование учетных записей, внедрите 2FA и регулярный мониторинг.
В этой части мы рассматриваем главные ошибки, которые препятствуют восстановлению после атаки: уязвимости в системе резервного копирования, отсутствие корректного логирования и готового плана аварийного восстановления (DRP).
Если во время проектирования системы резервного копирования будут допущены ошибки, инцидент может привести к серьезным последствиям для бизнеса. Системы бэкапа остаются одной из главных целей для атакующих, поскольку компрометация этих ресурсов позволяет надолго вывести инфраструктуру из строя. Это дает злоумышленникам дополнительный рычаг давления в переговорах о выкупе.
Проблемы, связанные с ошибками в проектировании системы бэкапов:
- Доступность из общей сети. Если резервные копии хранятся в той же сети, что и рабочие системы, их легко обнаружить и зашифровать.
- Слабая защита учетных данных. С помощью украденных данных злоумышленники могут получить контроль над общими или ненадежными УЗ, которые используются для доступа к системам резервного копирования.
- Непротестированные резервные копии. Если не проверять бэкапы, то выяснить, что они повреждены или неактуальны, можно только после атаки. Восстановление оказывается невозможным из‑за поврежденных копий или затруднительным — из‑за устаревших данных.
- Недостаточный мониторинг. Вы не заметите атакующих, если в системе отсутствуют логи и оповещения о несанкционированном доступе к бэкапу, а также о входах под сервисной УЗ.
MITRE ATT&CK
| ID | Техника |
|---|---|
| T1561 | |
| T1490 | |
| T1486 |
Рекомендации по защите бэкапов
1. Создавайте резервные копии в соответствии с принципом «3–2–1»
Что нужно сделать:
- Храните как минимум три резервные копии.
- Используйте как минимум два разных физических формата хранения (например, локальный диск и NAS/лента).
- Разместите как минимум одну копию в удаленном хранилище (вне офиса, например в облаке).
Почему это важно. Этот принцип обеспечивает достаточную отказоустойчивость резервных копий и значительно повышает безопасность инфраструктуры.
2. Проводите аудит доступов к системам резервного копирования
Периодическая проверка и анализ учетных записей, прав доступа и журналов активности позволяют выявить избыточные или несанкционированные доступы.
Что нужно сделать:
- Регулярно проводите аудит УЗ, имеющих доступ к серверам и консолям управления резервным копированием.
- Не подключайте к домену серверы резервного копирования.
- Для доступа к консолям таких серверов не используйте доменные УЗ.
- Регулярно проводите аудит сетевых доступов к серверам резервного копирования.
Почему это важно. Корректно настроенные права доступа существенно затрудняют для злоумышленника получение контроля над системами бэкапа.
3. Регулярно тестируйте восстановление из резервных копий
Проверяйте целостность и актуальность бэкапов, чтобы гарантировать возможность восстановления.
Что нужно сделать:
- Регулярно проводите тестовое восстановление систем из резервных копий, чтобы убедиться в их целостности и пригодности для восстановления.
- Убедитесь, что в бэкапах содержатся актуальные данные критически важных систем (например, доменных контроллеров, баз данных).
- Фиксируйте результаты тестирования и своевременно устраняйте выявленные недостатки.
Почему это важно. Без регулярных проверок в критический момент может выясниться, что резервное копирование было настроено некорректно и восстановление невозможно.
Вывод
Грамотно выстроенный процесс резервного копирования кратно снижает риски тяжелых последствий для бизнеса при потенциальном инциденте, а также ускоряет восстановление инфраструктуры.
Отсутствие централизованного хранения логов и некорректно настроенный аудит — распространенная проблема. Если логи хранятся некорректно, в случае инцидента повышается риск не обнаружить точку первоначального проникновения и, как следствие, не устранить его причину. В дальнейшем это может привести к повторному шифрованию инфраструктуры.
Проблемы, связанные с логированием:
- Некорректно настроенный аудит. Отсутствие необходимых для анализа событий затрудняет как проверку на компрометацию, так и расследование инцидентов.
- Отсутствие централизованного хранения логов. В этом случае появляется риск потерять логи, если системы выйдут из строя.
- Недостаточная глубина хранения. Слишком частая ротация логов может привести к безвозвратной потере информации, необходимой для расследования.
- Недостаточная детализация. Логи, в которых отсутствуют ключевые события (например, входы в систему, изменения конфигураций) или важные поля (такие как process command line), не позволяют быстро и в полной мере восстановить картину произошедшего.
MITRE ATT&CK
| ID | Техника |
|---|---|
| T1070 | |
| T1562.002 | |
| T1490 |
Рекомендации по настройке логирования
Чтобы минимизировать риски, связанные с отсутствием логов, необходимо централизованно собирать, защищать и анализировать эти логи. А также интегрировать эти процессы в систему реагирования. Большинство рекомендаций похожи на советы, которые указаны в предыдущих разделах. Ниже — только самое важное.
1. Определите источники логов
Важно определить минимально необходимый набор источников.
Начните собирать логи:
- с ОС на всех хостах;
- служб каталогов (Active Directory, FreeIPA и т. д.);
- СЗИ;
- периметральных сетевых устройств;
- критических для компании прикладных систем (например, почтовых серверов).
- Настройте логирование событий в Active Directory и на серверах управления.
- Используйте агенты для расширенного аудита конечных точек, например Sysmon/Auditbeat/osquery или EDR‑решения.
- Во всех системах, где настроено логирование, установите срок ротации логов.
- Если логи хранятся централизованно (например, в SIEM‑системе), убедитесь, что дискового пространства хватает для необходимой глубины хранения.
- Непонимание критичности бизнес-систем. В этом случае сложно расставить приоритеты для их восстановления, что увеличивает время простоя.
- Отсутствие плана аварийного восстановления. Это не только увеличивает время восстановления, но и чревато ошибками, которые могут повлечь еще большие убытки и репутационный ущерб.
- Непонимание конкретных вовлеченных сторон. Отсутствие DRP приводит к неопределенности в том, какие команды отвечают за те или иные этапы восстановления. Нескоординированность действий увеличивает время простоя и убытки компании.
- Непротестированный план. DRP, не проверенный на учениях, зачастую оказывается неработоспособным. Распространенный пример — когда восстановление из резервных копий невозможно из‑за их повреждения.
- Проведите аудит систем в компании, чтобы понять их количество и взаимосвязи.
- Оцените влияние чрезвычайных ситуаций на бизнес (business impact analysis, BIA). Эта процедура поможет корректно приоритизировать системы и процессы, то есть определить, какие из них требуют восстановления в первую очередь, а какие могут подождать.
- Определите два показателя:
- целевое время восстановления (recovery time objective, RTO) — максимально допустимое время на восстановление IT‑системы после сбоя;
- целевую точку восстановления (recovery point objective, RPO) — максимально допустимый объем данных, который компания готова потерять. RPO определяет период времени до сбоя, на момент которого должны быть сохранены все данные.
- Проанализируйте, какие негативные события могут произойти с каждой системой и процессом.
- Разработайте пошаговый план восстановления и определите, какие технические и организационные ресурсы для этого потребуются.
- Проведите учения, чтобы выявить слабые места в DRP и отработать межкомандное взаимодействие.
- Включите в план процедуры коммуникации с руководством, регуляторами и партнерами.
Почему это важно. Сбор всех логов создаст избыточную нагрузку на IT‑службы и перегрузит дежурную смену подразделений кибербезопасности. При незрелых процессах мониторинга лучше начать со сбора базовых событий безопасности.
2. Настройте корректный аудит
Зачастую системы по умолчанию регистрируют минимальный набор событий. Этих данных бывает недостаточно для проведения глубокого анализа, поэтому требуется дополнительно настроить аудит, чтобы получать все значимые события.
Что нужно сделать:
Почему это важно. Если аудит настроен некорректно, расследовать атаку практически невозможно. Без регистрации необходимых событий нельзя ни установить вектор проникновения, ни зафиксировать перемещение злоумышленников внутри сети. Все это приводит к пробелам в хронологии инцидента.
3. Увеличьте глубину хранения логов до 90 дней
Нередки случаи, когда между проникновением злоумышленника в инфраструктуру и нанесением ущерба проходит несколько месяцев. В такой ситуации достаточная глубина хранения логов критически важна, чтобы определить первоначальную точку проникновения и устранить причину инцидента.
Что нужно сделать:
Почему это важно. Если события удаляются или перезаписываются до того, как атака будет обнаружена, следы компрометации теряются безвозвратно. Увеличение глубины хранения логов до 90 дней позволяет восстановить цепочку событий, предшествовавших атаке, и определить момент начала инцидента.
Вывод
Корректно настроенное централизованное логирование с достаточной глубиной хранения позволяет не только расследовать инциденты, но и более качественно, проактивно проверять инфраструктуру на признаки компрометации.
DRP (disaster recovery plan) — план аварийного восстановления. Для него необходимо определить потенциальные негативные события для бизнеса и разработать стратегию по минимизации их воздействия. Такой план позволяет сократить время на восстановление бизнес-процессов, а также снизить финансовые и репутационные потери.
Проблемы, связанные с отсутствием DRP:
Рекомендации по созданию DRP
Чтобы минимизировать риски, необходимо разработать и протестировать план аварийного восстановления, а затем интегрировать его с процессами кибербезопасности.
1. Определите уровень критичности систем и процессов
Это поможет правильно расставить приоритеты при формировании DRP.
Что нужно сделать:
Почему это важно. Когда все системы недоступны, восстановить их одновременно невозможно. Заранее определенные приоритеты позволяют сосредоточить усилия на главном.
2. Сформируйте план аварийного восстановления
Создайте стратегии восстановления для различных систем и процессов в соответствии с их критичностью.
Что нужно сделать:
Почему это важно. После расстановки приоритетов необходимо понять, как именно восстанавливать каждую систему после инцидента. Для этого нужно учитывать ее специфику, тип обрабатываемых данных и способы хранения бэкапов.
3. Определите ответственные команды
Они должны работать скоординированно в рамках DRP, а также четко понимать зоны ответственности и взаимодействия.
Почему это важно. Если четко не определить ответственных команд, восстановление после атаки превращается в хаос. Неясность ролей приводит к дублированию работы, потере времени и неверным приоритетам, что увеличивает время простоя и риск повторного заражения.
4. Проведите учения в рамках DRP
Что нужно сделать:
Почему это важно. Тестирование плана позволяет выявить и устранить его недостатки до возникновения реального инцидента.
Вывод
Грамотно разработанный план аварийного восстановления позволяет в разы быстрее вернуться к работе во время нештатной ситуации, а также избежать паники.
Шифровальщики и вайперы по‑прежнему остаются одними из ключевых угроз для организаций. Задача такого вредоносного ПО — нанести бизнесу максимальный ущерб: парализовать процессы и уничтожить критически важные данные. При этом атакующие действуют все более целенаправленно и продуманно, а цена любой ошибки защищающейся стороны становится выше.
Традиционная реактивная модель безопасности, при которой к активным действиям переходят лишь после инцидента, уже не работает. Единственная эффективная альтернатива — проактивная защита, которая строится на следующих принципах:
- Постоянный аудит конфигураций и устранение мисконфигураций.
- Строгий контроль привилегий и сегментация сети.
- Надежная система резервного копирования и отлаженная процедура восстановления.
- Мониторинг событий кибербезопасности и их анализ в реальном времени.
- Регулярные учения и аудиты кибербезопасности.
Проактивная стратегия не только снижает вероятность успешной атаки, но и позволяет сохранить контроль над ситуацией, если инцидент все же произойдет. Такой подход формирует зрелую систему кибербезопасности, в которой уязвимости выявляются и устраняются до, а не после их использования злоумышленниками. Настоящая защита строится не на отдельных «заплатках», а на целостной системе, где все элементы — от человеческого фактора до технических барьеров — работают согласованно, усиливая друг друга.
В 2025 году ландшафт угроз продолжает усложняться. Рост числа атак, эволюция программ-вымогателей и интеграция AI с инструментами злоумышленников требуют от компаний не реакции, а упреждающих действий. Не стоит дожидаться инцидента — лучше начать с самооценки уровня защищенности по чек‑листу, внедрить ключевые рекомендации и регулярно проверять защитные механизмы.
Главный вывод очевиден: компании, которые выстраивают проактивную оборону, приобретают не только технологическое, но и стратегическое преимущество. Это уже не вопрос удобства или следования трендам — это вопрос устойчивости бизнеса и его способности выживать в условиях непрерывно растущих киберугроз.