«Что происходит, когда вы покупаете компанию и вместе с активами получаете приложение на PHP 5.3, пароли в таблице ‘users’ и открытый RDP-шлюз в корпоративную сеть? Как за два дня понять, что скрывается под слоем маркетинговых презентаций и не стать заложником чужих долгов в виде уязвимостей и инцидентов?»
Что такое кибердилдженс и почему 48 часов — не абсурд
Кибердилдженс, это слияние юридического аудита и технического сканирования. Его цель — оценить не финансовые показатели, а цифровую инфраструктуру: от кода приложений до настроек межсетевых экранов. Срок в 48 часов кажется нереальным для классического аудита, но в условиях сделки, когда время на принятие решения сжато, он становится необходимым компромиссом. Это не попытка провести глубокий пентест, а скорее экспресс-диагностика: обнаружить «красные флаги», которые могут сделать сделку экономически невыгодной или опасной.
Такой анализ не требует полного доступа к системам, это работа на основе открытой информации, документации и ограниченных тестов. Фокус смещается с «как всё идеально защитить» на «что немедленно угрожает бизнесу и репутации». Невыполненные требования 152-ФЗ или предписания ФСТЭК — не просто штрафы, а сигнал о системных проблемах в управлении ИБ.
Этап 1: Карта цифровых активов и открытый разведка
Первые часы уходят на составление карты того, что покупаете. Это не только список доменов и IP-адресов, но и понимание их значимости.
- Домены и субдомены: Используются инструменты пассивного сбора (типа amass, subfinder) для поиска всех связанных имен. Критично найти забытые поддомены для тестирования (например, test.company.ru, dev.api.company.ru), которые часто становятся лазейкой в основную инфраструктуру.
- IP-пространство: Определение сетевых блоков компании через WHOIS и RIR. Сканирование этих диапазонов на открытые порты (Nmap) помогает выявить неучтённые сервисы: базы данных, удалённые админ-панели, устаревшие веб-серверы.
- Утечки данных и публичные инциденты: Поиск в специализированных базах (типа Have I Been Pwned для корпоративных email) и на теневых форумах. Наличие слитых учетных данных сотрудников цели — прямое указание на прошлые проблемы с безопасностью.
Этап 2: Внешний периметр и «низко висящие плоды»
Анализ видимой извне инфраструктуры часто даёт самые быстрые и тревожные результаты. Фокус — на ошибках конфигурации, которые не требуют взлома.
- Веб-приложения: Автоматизированное сканирование основных доменов на распространённые уязвимости (OWASP Top 10). Особое внимание — к публичным API и клиентским порталам.
- Электронная почта: Проверка записей SPF, DKIM, DMARC. Их отсутствие или ошибки не только повышают риск фишинга, но и говорят о небрежности в администрировании.
- Удалённый доступ: Поиск открытых RDP, SSH, VNC, VPN-шлюзов. Их наличие на стандартных портах без дополнительного фактора аутентификации — критический риск.
- Облачные сервисы: Определение используемых платформ. Проверка публичных S3-ведёр или Blob-контейнеров, настроенных на полный доступ — частая находка, ведущая к утечке внутренних данных.
Этап 3: Анализ документации и соответствия требованиям
Технические уязвимости — лишь часть риска. Вторая — административная. Запрос и анализ внутренних документов по ИБ позволяет оценить зрелость процессов.
| Документ | Что оценивать | Красный флаг |
|---|---|---|
| Политика информационной безопасности | Актуальность, утверждение руководством, доведение до сотрудников | Документ существует только формально, последнее обновление — 5+ лет назад |
| Приказ о назначении ответственного за ИБ (152-ФЗ) | Наличие, соответствие должности реальным полномочиям | Ответственный — системный администратор без выделенных функций по ИБ |
| Реестр информационных систем (РИС) | Полнота, актуальность, классификация ИСПДн | В реестре учтено 3 системы, при этом сканирование выявляет 15+ |
| Акты обследования ФСТЭК/ФСБ | Наличие, статус (пройдены/есть замечания), срок действия | Отсутствие актов для систем, подлежащих обязательной аттестации |
| Политика резервного копирования и планы восстановления | Регулярность тестов восстановления, географическое разделение копий | Последний успешный тест восстановления не проводился |
Этап 4: «Софтовая» гигиена и технический долг
Состояние используемого программного обеспечения — индикатор технической культуры. Устаревшие компоненты несут риски эксплуатации известных уязвимостей.
- Стек технологий: Определение версий ОС (Windows Server 2008 R2), веб-серверов (IIS 7.0), СУБД, фреймворков. Сравнение с актуальными и поддерживаемыми версиями.
- Открытый исходный код: Проверка зависимостей проектов (например, через SCA-сканеры) на известные уязвимости (CVE). Наличие библиотек с критическими проблемами, для которых есть патчи, но они не применены.
- Кастомная разработка: Запрос отчётов статического/динамического анализа кода (если есть). Большое количество высокоуровневых предупреждений может указывать на системные проблемы архитектуры.
Этап 5: Инцидент-ответ и история сбоев
Прошлое — лучший прогнозер будущего. Важно понять, как компания реагировала на проблемы.
- Запрос журналов инцидентов ИБ за последние 2-3 года (даже в обезличенном виде). Частота и тип инцидентов (DDoS, утечки, вредоносное ПО) говорят об уровне угроз.
- Наличие выделенной команды или прописанных процедур реагирования (playbooks). Их отсутствие означает, что при серьёзной атаке хаос будет гарантирован.
- Проверка участия компании в отраслевых ISAC (Information Sharing and Analysis Center) или подобных сообществах. Это косвенный признак зрелости.
Сводный отчёт и оценка влияния на сделку
Итог 48-часовой работы — не технический отчёт на 100 страниц, а сфокусированная матрица рисков с привязкой к бизнес-последствиям. Каждая находка оценивается по двум осям: вероятности эксплуатации и потенциальному ущербу (финансовому, репутационному, операционному).
Например, критический риск (открытый RDP) требует немедленного устранения как условия закрытия сделки. Высокий риск (незакрытая критическая CVE в публичном API) становится пунктом для пересмотра цены или создания резерва на remediation. Средние и низкие риски формируют дорожную карту интеграции после поглощения.
Главный результат такого анализа — переход от неопределённости «что мы покупаем?» к конкретному плану действий: «мы покупаем, но с условием немедленного исправления X, Y, Z, и с бюджетом на исправление A, B, C в первый квартал». Это превращает киберриски из скрытой угрозы в управляемый параметр сделки.