Аудит / Учебный курс

{{>TOC}}

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

h2. Введение

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

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

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

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

bq. Эта тема опирается на знание технических мер защиты из курса «Основы менеджмента ИБ», в частности на темы [[uib:Программно-технические_меры_обеспечения_информационной_безопасности|Управление доступом]] и [[uib:Протоколирование_и_аудит_шифрование_контроль_целостности|Аудит и криптография]]. Понимание того, как работают атаки, необходимо для понимания того, как их тестировать.

---

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

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

!clipboard-202606040939-1jyoy.png!

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

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

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

Эталоны сравнения: CIS(Center for Internet Security) Benchmarks — наиболее распространённый открытый стандарт конфигурации для более чем 100 технологий; DISA(Defense Information Systems Agency) STIG(Security Technical Implementation Guides) — военные стандарты конфигурации США, нередко используемые как ориентир; внутренние baseline-документы организации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

h3. Red Team / Blue Team

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

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

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

---

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

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

*PTES(Penetration Testing Execution Standard)* — наиболее распространённый открытый стандарт, описывающий семь фаз пентеста.

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

*MITRE ATT&CK(Adversarial Tactics, Techniques, and Common Knowledge)* — база знаний тактик и техник реальных атак, используемая для планирования сценариев пентеста и Red Team.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

*XSS(Cross-Site Scripting)* — внедрение вредоносного 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.

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

|_.Инструмент|_.Назначение|_.Тип|

|Burp Suite Professional|Комплексный анализ веб-приложений: перехват, модификация запросов, активное и пассивное сканирование|Коммерческий|

|OWASP ZAP|Сканирование веб-уязвимостей, proxy для ручного тестирования|Open Source|

|sqlmap|Автоматизированное обнаружение и эксплуатация SQL-инъекций|Open Source|

|Nikto|Быстрое сканирование веб-серверов на типичные уязвимости|Open Source|

|ffuf / gobuster|Перебор директорий и параметров (fuzzing)|Open Source|

---

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

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

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

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

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

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

h3. Вишинг

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

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

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

---

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

|_.Критичность|_.Количество|_.Примеры|_.Срок устранения|

|Критическая (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 дней|

---

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

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

|_.Находка технического аудита|_.Соответствующее несоответствие ISO 27001|

|Критическая уязвимость, не закрытая 90+ дней|Контроль 8.8: управление техническими уязвимостями|

|Открытые порты сервисов, не задокументированных в архитектуре|Контроль 8.20: сетевая безопасность|

|Учётные данные в открытом виде в конфигурационных файлах|Контроль 8.6: управление конфигурацией|

|Возможность перемещения по сети без аутентификации|Контроль 8.22: сегрегация сетей|

|Слабые или стандартные пароли на сервисах|Контроль 5.17: информация для аутентификации|

|Утечка внутренних данных через HTTP-заголовки|Контроль 8.12: предотвращение утечки данных|

---

h2. Что дальше

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

* *Следующая тема:* [[Стандарты_информационной_безопасности|Обзор стандартов и фреймворков]] — сравнительный обзор ISO 27001, NIST CSF, COBIT, PCI DSS, ГОСТ 57580

* *Оформление результатов:* [[Отчетная_документация|Отчёт об аудите и работа с несоответствиями]] — как интегрировать технические находки в аудиторский отчёт

* *Практика:* [[Практика_аудита|Практика: программа, план, чек-листы]] — как включить технический аудит в программу проверки

---

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

* "OWASP Testing Guide v4.2":https://owasp.org/www-project-web-security-testing-guide/ — методология тестирования веб-приложений

* "PTES — Penetration Testing Execution Standard":http://www.pentest-standard.org/ — стандарт проведения пентеста

* "MITRE ATT&CK":https://attack.mitre.org — база тактик и техник атак

* "CIS Benchmarks":https://www.cisecurity.org/cis-benchmarks — эталоны конфигурации

* "NIST SP 800-115":https://csrc.nist.gov/publications/detail/sp/800-115/final — Technical Guide to Information Security Testing and Assessment

* "OWASP API Security Top 10":https://owasp.org/www-project-api-security/

* Georgia Weidman — Penetration Testing: A Hands-On Introduction. No Starch Press, 2014

* Kim D., Solomon M. — Fundamentals of Information Systems Security. 3rd ed. Jones & Bartlett, 2018

* "БДУ ФСТЭК России":https://bdu.fstec.ru — банк данных угроз и уязвимостей