Проект

Общее

Профиль

Действия
История

Sidebar »

Технический аудит и тестирование на проникновение

Введение

Аудит соответствия отвечает на вопрос «выполняются ли требования стандарта?». Технический аудит отвечает на принципиально другой вопрос: «можно ли взломать систему?»

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

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

Технический аудит является самостоятельным видом проверки и одновременно важным источником данных для аудита соответствия. Выявленная критическая уязвимость — это не просто техническая проблема; это свидетельство несоответствия контролям управления уязвимостями (ISO 27001, контроль 8.8) или требованиям патч-менеджмента.

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

Виды технического аудита

Технический аудит — это не единственная процедура, а семейство взаимосвязанных проверок с разными целями, методами и глубиной воздействия на проверяемую систему.

Анализ конфигураций

Наименее инвазивный вид технической проверки. Аудитор получает конфигурационные файлы, выгрузки настроек или доступ к консолям управления и сравнивает фактические настройки с эталонными.

Типичные объекты: групповые политики Active Directory, конфигурации межсетевых экранов и NGFW, параметры веб-серверов (nginx, Apache, IIS), настройки СУБД, конфигурации облачных окружений (AWS Security Hub, Azure Security Center).

Эталоны сравнения: CIS Benchmarks — наиболее распространённый открытый стандарт конфигурации для более чем 100 технологий; DISA STIG — военные стандарты конфигурации США, нередко используемые как ориентир; внутренние baseline-документы организации.

Автоматизация: инструменты CIS-CAT, Lynis, Microsoft Security Compliance Toolkit позволяют автоматически сравнивать конфигурацию с эталоном и генерировать отчёт о расхождениях.

Сканирование уязвимостей

Автоматизированное обнаружение известных уязвимостей в программном обеспечении и сетевых сервисах. Сканер отправляет зонды на целевые системы, анализирует ответы и сопоставляет результаты с базой уязвимостей (CVE, NVD).

Сетевое сканирование — обнаружение активных хостов, открытых портов, работающих сервисов и их версий. Базовый инструмент: Nmap. На основе обнаруженных версий ПО сопоставляются известные уязвимости.

Сканирование уязвимостей — углублённая проверка с активными зондами для верификации наличия конкретных уязвимостей. Инструменты: Nessus, OpenVAS, Qualys, MaxPatrol 8, ScanFactory. Результат — отчёт с ранжированием уязвимостей по CVSS.

Сканирование веб-приложений — специализированные инструменты для выявления уязвимостей OWASP Top 10 в веб-интерфейсах. Инструменты: OWASP ZAP, Burp Suite (пассивный режим), Acunetix, Nikto.

CVSS — стандартизированная система оценки серьёзности уязвимостей по шкале от 0 до 10. Три диапазона имеют практическое значение для аудитора: критические (9.0–10.0) требуют немедленного устранения; высокие (7.0–8.9) — устранения в течение SLA (обычно 30 дней); средние (4.0–6.9) — плановые обновления. Уязвимость с CVSS 9.8 при отсутствии патча дольше SLA — значительное несоответствие контролю 8.8 ISO 27001.

Анализ защищённости (Security Assessment)

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

Например, критическая уязвимость в сервисе, доступном только из внутренней сети за несколькими межсетевыми экранами, имеет значительно меньший реальный риск, чем та же уязвимость в публично доступном сервисе. Это суждение требует человека, а не только инструмента.

Тестирование на проникновение

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

Чёрный ящик (Black Box) — тестировщик имеет только публично доступную информацию об организации, имитируя внешнего злоумышленника без предварительных знаний. Наиболее реалистичная модель внешней атаки, но наименее эффективная с точки зрения охвата за единицу времени.

Серый ящик (Grey Box) — тестировщик имеет частичные знания о системе: учётные данные рядового пользователя, схему сети или описание архитектуры. Имитирует инсайдера с ограниченными правами или злоумышленника, уже получившего первичный доступ. Наиболее распространённая модель для корпоративных пентестов.

Белый ящик (White Box) — тестировщик имеет полную документацию: исходный код, схемы сетей, учётные данные администратора. Максимальный охват за счёт отказа от реалистичности. Применяется для глубокого анализа конкретного приложения или компонента.

Red Team / Blue Team

Red Team — расширенная форма пентеста, имитирующая реальную APT-атаку (Advanced Persistent Threat). Команда атакующих (Red Team) действует скрытно в течение длительного времени (недели или месяцы), используя весь арсенал техник: социальную инженерию, физическое проникновение, эксплуатацию технических уязвимостей.

Цель Red Team — не найти уязвимости, а достичь конкретных бизнес-целей: получить доступ к данным клиентов, скомпрометировать AD, выгрузить финансовую отчётность. Это позволяет оценить не только наличие отдельных уязвимостей, но и эффективность всей системы обнаружения и реагирования.

Blue Team — команда защитников (SOC, ИБ-специалисты), которая в реальном времени обнаруживает и реагирует на действия Red Team. По итогам упражнения проводится разбор (Purple Team exercise): что удалось обнаружить, что прошло незамеченным и почему.

Методология пентеста

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

PTES — наиболее распространённый открытый стандарт, описывающий семь фаз пентеста.

OWASP Testing Guide — специализированная методология для веб-приложений, описывающая более 90 тестовых случаев.

MITRE ATT&CK — база знаний тактик и техник реальных атак, используемая для планирования сценариев пентеста и Red Team.

PTES выделяет следующие фазы.

Фаза 1: Подготовка и согласование

До начала любых технических действий подписывается детальный договор, определяющий: область тестирования (конкретные IP-диапазоны, домены, приложения), запрещённые действия (например, атаки на доступность, социальная инженерия конкретных лиц), временные окна проведения тестирования, правила экстренной остановки (kill switch), порядок уведомления при обнаружении критической уязвимости и ответственность сторон.

Тестирование на проникновение без надлежащего письменного разрешения является уголовно наказуемым деянием вне зависимости от намерений. Статья 272 УК РФ («Неправомерный доступ к компьютерной информации») не делает исключений для «этичных хакеров» без документального разрешения владельца системы.

Фаза 2: Сбор информации

Аудитор собирает максимум информации о цели из открытых источников (OSINT) без активного взаимодействия с системами. Техники и инструменты:

Пассивная разведка: Shodan, Censys (поиск публично доступных сервисов), Maltego (графический анализ связей), TheHarvester (сбор email-адресов, поддоменов), анализ WHOIS и DNS-записей, изучение LinkedIn для составления оргструктуры.

Активная разведка: сканирование портов Nmap, определение версий сервисов, трассировка маршрутов, анализ поддоменов.

Результат фазы — детализированная карта атаки: какие системы доступны, какое ПО запущено, какие сотрудники работают в организации, какие технологии используются.

Фаза 3: Анализ угроз и моделирование атак

На основе собранных данных определяются наиболее вероятные и перспективные векторы атаки. Аудитор приоритизирует цели исходя из вероятности успеха и потенциального ущерба.

Фаза 4: Анализ уязвимостей

Систематическое выявление уязвимостей в обнаруженных системах и приложениях: автоматическое сканирование, ручной анализ, изучение публичных баз (CVE, Exploit-DB, NVD).

Фаза 5: Эксплуатация

Активная попытка использовать выявленные уязвимости для получения несанкционированного доступа. Инструменты: Metasploit Framework, Burp Suite (активные атаки), ручные техники эксплуатации.

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

Фаза 6: Постэксплуатация

После получения первоначального доступа исследуется возможность дальнейшего развития атаки: горизонтальное перемещение (lateral movement) по сети, повышение привилегий (privilege escalation), закрепление в системе (persistence), доступ к целевым данным.

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

Фаза 7: Отчётность

Документирование всех находок с детализацией для двух аудиторий: технической (точные векторы атаки, инструменты, рекомендации по устранению) и управленческой (бизнес-риски, приоритеты, общий уровень защищённости).

Тестирование веб-приложений

Веб-приложения — наиболее распространённая поверхность атаки для внешних злоумышленников. OWASP Top 10 (рассмотренный в курсе «Основы менеджмента ИБ») является стандартным чек-листом для аудитора веб-приложений.

Ключевые техники тестирования

SQL-инъекции — попытки внедрить произвольный SQL-код через поля ввода. Обнаруживаются автоматически (sqlmap) и вручную. Пример: ввод `' OR 1=1 --` в поле логина.

XSS — внедрение вредоносного JavaScript в страницы приложения. Проверяется отражение пользовательского ввода без санитизации. Пример: `<script>alert(document.cookie)</script>` в полях форм.

Broken Access Control — проверка возможности получить доступ к данным или функциям, недоступным текущему пользователю. Техники: изменение ID ресурса в URL (IDOR — Insecure Direct Object Reference), доступ к функциям администратора без соответствующей роли.

Небезопасная аутентификация — проверка стойкости механизмов аутентификации: брутфорс логинов без блокировки, перехват сессионных токенов, небезопасное управление паролями.

Тестирование API — проверка REST/GraphQL API на предмет тех же классов уязвимостей, что и веб-интерфейс, с учётом специфики OWASP API Security Top 10.

Инструменты аудита веб-приложений

Инструмент Назначение Тип
Burp Suite Professional Комплексный анализ веб-приложений: перехват, модификация запросов, активное и пассивное сканирование Коммерческий
OWASP ZAP Сканирование веб-уязвимостей, proxy для ручного тестирования Open Source
sqlmap Автоматизированное обнаружение и эксплуатация SQL-инъекций Open Source
Nikto Быстрое сканирование веб-серверов на типичные уязвимости Open Source
ffuf / gobuster Перебор директорий и параметров (fuzzing) Open Source

Социальная инженерия в рамках аудита

Технические уязвимости — не единственный вектор атаки. Социальная инженерия эксплуатирует человеческий фактор и нередко является наиболее эффективным способом проникновения в хорошо защищённую техническую инфраструктуру.

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

Фишинговые симуляции

Отправка тестовых фишинговых писем сотрудникам для оценки уровня осведомлённости. Метрики: процент открывших письмо, процент перешедших по ссылке, процент введших учётные данные. Инструменты: GoPhish, King Phisher.

Результаты фишинговой симуляции — ценное свидетельство для аудита соответствия контролю «Осведомлённость, образование и обучение» (ISO 27001, контроль 6.3).

Вишинг

Звонки сотрудникам под видом IT-поддержки, контрагентов или регуляторов с целью получения учётных данных или выполнения действий (например, «перезагрузите VPN-клиент по инструкции, которую я пришлю»). Проверяет эффективность обучения по социальной инженерии.

Физическое проникновение

Попытка получить несанкционированный физический доступ на объект: «tailgating» (проход за сотрудником через турникет), представление подрядчиком без проверки документов, оставление «заражённых» USB-носителей. Требует наиболее жёсткого документального оформления во избежание конфликтов.

Правовые и этические аспекты

Технический аудит и пентест — область с повышенным правовым риском. Несоблюдение формальных требований превращает легитимное тестирование в уголовно наказуемое деяние.

Обязательная документация

*Разрешение на тестирование * — детальный документ, подписанный уполномоченным представителем организации-владельца систем. Должен содержать точный перечень систем, временные окна, допустимые техники, ограничения и контактные данные для экстренной связи.

NDA — соглашение о конфиденциальности: данные об уязвимостях не разглашаются третьим сторонам.

Юридическая цепочка владения. Если тестируется облачная инфраструктура (AWS, Azure, GCP) или арендованные каналы, требуется дополнительное разрешение от провайдера — большинство крупных провайдеров имеют официальную политику проведения тестирования на их платформах.

Ответственное раскрытие

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

Минимальный ущерб

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

Отчёт о техническом аудите

Отчёт о пентесте или техническом аудите структурирован для двух разных аудиторий.

Управленческое резюме

Написано для руководства без технических деталей. Содержит: общий уровень защищённости (качественная оценка), количество и распределение уязвимостей по критичности, три-пять ключевых находок с бизнес-ориентированным описанием риска, общую рекомендацию по приоритетам.

Технический раздел

Написан для IT-специалистов и специалистов по ИБ. Для каждой уязвимости: название и идентификатор CVE (если применимо), оценка CVSS, затронутые системы, описание техники эксплуатации с доказательством (скриншоты, логи), бизнес-риск, конкретные шаги по устранению, ссылки на патчи или конфигурационные рекомендации.

Матрица уязвимостей

Сводная таблица всех находок с приоритизацией:

Критичность Количество Примеры Срок устранения
Критическая (CVSS 9+) N RCE в публичном API, неаутентифицированный доступ к БД Немедленно
Высокая (CVSS 7–8.9) N SQL-инъекция, отсутствие MFA на VPN 30 дней
Средняя (CVSS 4–6.9) N Устаревшие версии ПО без публичных эксплойтов 90 дней
Низкая (CVSS < 4) N Информационные уязвимости, заголовки HTTP 180 дней

Связь технического аудита с аудитом соответствия

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

Находка технического аудита Соответствующее несоответствие ISO 27001
Критическая уязвимость, не закрытая 90+ дней Контроль 8.8: управление техническими уязвимостями
Открытые порты сервисов, не задокументированных в архитектуре Контроль 8.20: сетевая безопасность
Учётные данные в открытом виде в конфигурационных файлах Контроль 8.6: управление конфигурацией
Возможность перемещения по сети без аутентификации Контроль 8.22: сегрегация сетей
Слабые или стандартные пароли на сервисах Контроль 5.17: информация для аутентификации
Утечка внутренних данных через HTTP-заголовки Контроль 8.12: предотвращение утечки данных

Что дальше

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

Список литературы и стандартов

Обновлено С. Антошкин около 14 часа назад · 1 изменени(я, ий)