Руслан Рахметов, Security Vision
Выполнение организационных и технических мероприятий по кибербезопасности должно приводить к повышению уровня киберзащищенности и киберустойчивости компании и её активов (персонала, процессов, технологий, данных). Для проверки состояния кибербезопасности применяют различные методы анализа защищенности, позволяющие оценить, в каком объеме и с каким качеством реализованы меры защиты, понять достаточность контрмер и разработать рекомендации для их корректировки и повышения уровня защищенности компании. В данной статье расскажем про различные виды анализа защищенности и обсудим этапы его проведения, а также приведем примеры методологий для оценки защищенности.
Анализ защищенности можно определить как процесс проверки того, насколько оцениваемый объект защищен от актуальных для него киберугроз и нарушителей, в рамках которого выявляются недостатки защиты и предоставляются рекомендации по повышению безопасности объекта. Анализ защищенности — это не разовое мероприятие, а непрерывный процесс, соответствующий циклу Деминга PDCA (Plan — Do — Check — Act, т.е. Планирование — Выполнение — Оценка — Корректировка), в котором результаты оценки служат входной информацией для корректировки процесса, что обеспечивает обратную связь. Конечной целью реализации процесса анализа защищенности является формирование списка рекомендаций и планов по устранению уязвимостей и недостатков технических и организационных мер защиты, что способствует повышению уровня кибербезопасности оцениваемого объекта (сотрудника, процесса, технологии, информационной системы, сети, инфраструктуры, отдельного устройства, набора данных) и всей организации в целом. Исходными данными для процесса анализа будут свойства объекта защиты и сведения о текущем состоянии безопасности, нормативные и внутренние требования к защищенности объекта и принимаемым контрмерам, результаты работ по выявлению уязвимостей объекта и недостатков контрмер, отчеты инструментов автоматизированной проверки (сканеров защищенности, эмуляторов кибератак, фреймворков для пентестов) и отчеты о выполненных работах (интервью с ответственными, заполненные опросники, отчеты об обследовании объектов, результаты аудитов ИБ, пентестов, оценок Red Team, киберучений, программ Bug Bounty).
Понятие анализа защищенности используется в ряде нормативных документов. Так, в «Методике оценки показателя состояния технической защиты информации в информационных системах и обеспечения безопасности ЗО КИИ», утвержденной ФСТЭК России 11.11.2025, сказано, что показатель защищенности характеризует степень достижения организацией минимально необходимого уровня защиты информации от типовых актуальных угроз на момент оценивания и в заданных условиях. Данная методика применяется в соответствии с требованиями п. 31 Приказа ФСТЭК России №117 от 11.04.2025 — в нём сказано, что оценка состояния защиты информации должна проводиться на основе показателя защищенности, который характеризует текущее состояние защиты информации от базового уровня киберугроз. В соответствии с положениями указанной методики показатель защищенности определяется путём оценки выполнения требований по организации и управлению ИБ, защите пользователей информационных систем, защите самих информационных систем, мониторингу ИБ и реагированию на киберинциденты. Кроме того, в Указе Президента РФ №250 от 01.05.2022 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации» указано, что ключевым российским организациям требовалось провести мероприятия по оценке уровня защищенности своих информационных систем и предоставить результаты оценки, — это подчеркивает важность мероприятий по оперативному анализу защищенности в условиях резкого всплеска киберугроз и роста интенсивности кибератак.
В специальной публикации NIST SP 800-115 "Technical Guide to Information Security Testing and Assessmen" («Техническое руководство по тестированию и оценке информационной безопасности») сказано, что анализ киберзащищенности — это процесс определения эффективности и полноты выполнения ИБ-требований оцениваемым объектом (хостом, системой, сетью, процедурой, работником), а результаты анализа защищенности используются для определения корректности примененных к объекту мер защиты. Основными типами анализа защищенности в соответствии с NIST SP 800-115 являются:
· тестирование: процесс оценки объекта в определенных условиях для сравнения ожидаемого и фактического поведения;
· оценка: процесс проверки, инспектирования, пересмотра, наблюдения, изучения или анализа объекта для обеспечения понимания и получения подтверждения (доказательства) работы мер защиты;
· интервьюирование (опрос): процесс обсуждения объекта с сотрудниками организации для обеспечения понимания и получения подтверждения (доказательства) работы мер защиты.
Методология проведения анализа защищенности в соответствии с положениями NIST SP 800-115 должна включать в себя как минимум следующие этапы:
1. Планирование:
Разработка подхода к проведению анализа и сбор информации, необходимой для выполнения анализа, включая список объектов, перечень киберугроз для активов и возможные меры защиты для противодействия этим угрозам. Каждая интеграция анализа защищенности должна выполняться в соответствии с принципами проектного менеджмента, включая разработку плана проекта, определение целей, задач и границ проекта, требований, ограничений, критериев успеха, предположений, доступных ресурсов, формирование списка ролей и ответственных лиц, временной шкалы и ожидаемых отчётных материалов. При планировании важно разработать политику проведения анализа защищенности, приоритизировать и запланировать необходимые мероприятия, выбрать и кастомизировать техники и инструменты анализа (с учетом минимизации возможного ущерба для инфраструктуры во время анализа и с учетом обрабатываемых в оцениваемой системе данных), выбрать подходящего специалиста или внешнюю компанию для проведения анализа, определить формат проведения оценки (удаленно или на площадке заказчика), подобрать инструменты и ресурсы для проведения анализа защищенности, проработать юридические вопросы (например, предусмотреть распределение ответственности при случайной утечке защищаемых данных или за нарушение функционирования сервисов при инвазивном тестировании), разработать детальный порядок проведения анализа и/или правила реализации проекта (англ. ROE, Rules of Engagement).
2. Исполнение:
Применение выбранного метода и инструментов анализа защищенности для выявления уязвимостей и проверки их применимости. При исполнении нужно соблюдать координацию между аудиторами/пентестерами/членами Red Team и ответственными за анализируемую систему, что поможет предоставить необходимые полномочия исполнителям, обеспечить осведомленность ответственных, избежать выполнения оценки при обновлении систем или во время их высокой загруженности, а также приостановить проведение анализа в случае возникновения боевого инцидента или при обнаружении вредоносной активности в оцениваемой системе. Выполнение анализа защищенности должно проводиться в соответствии с разработанным порядком проведения анализа и с учетом прогнозируемых последствий от проведения анализа. При выполнении анализа защищенности следует учитывать также такие сложности, как возможное противодействие со стороны ответственных или пользователей системы (что устраняется полученным согласованием от руководителей организации), недостаток реализма при анализе (например, на время оценки к системе применяются более строгие политики безопасности), немедленное устранение выявленных недостатков ответственными (в нарушение установленных корпоративных процедур управления изменениями), выбор временного окна для анализа (что может снизить реализм проверки), возможные негативные последствия от проведенного анализа (поэтому все действия аудиторов должны журналироваться), а также недостаток ресурсов и квалификации для детального анализа, в том числе при работе с новейшими технологиями. В рамках этапа исполнения специалисты, занимающиеся анализом защищенности, проводят первичную оценку выявленных недостатков и уязвимостей для того, чтобы при возникновении сомнений выполнить повторное сканирование или провести ручной анализ. На этапе исполнения важно соблюдать правила защищенной обработки полученных данных, включая собранную информацию об архитектуре и конфигурации проанализированных объектов, а также журналы действий, выполненных аудиторами во время анализа защищенности. Важно также обеспечивать конфиденциальность документов, использующихся в рамках проекта по анализу защищенности: порядок проведения анализа или правила реализации проекта, документация на инфраструктуру и анализируемые объекты, результаты работы сканеров защищенности и отчеты автоматизированных инструментов анализа, отчёт о выполненном анализе и план предлагаемых корректирующих действий. Важно обеспечивать конфиденциальность при передаче и хранении полученных данных, в том числе путем применения методов криптографической защиты информации, а также надежно уничтожать или обезличивать документы после завершения работ, руководствуясь в том числе положениями публикации NIST SP 800-88 "Guidelines for Media Sanitization" («Рекомендации по очистке носителей данных»).
3. Пост-тестировочные действия:
На итоговом этапе выполняется детальный анализ выявленных уязвимостей, определение корневых причин (англ. root cause) их возникновения, разработка рекомендаций по устранению обнаруженных уязвимостей и плана предлагаемых корректирующих действий для повышения уровня киберзащищенности организации, выпуск итогового отчета с результатами проекта по анализу защищенности.
Примерами распространенных корневых причин уязвимостей и недостатков являются:
· Недостатки процесса патч-менеджмента: несвоевременная установка обновлений безопасности, установка патчей не на все уязвимые системы — для повышения качества данного процесса можно воспользоваться рекомендациями документа NIST SP 800-40 "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology" («Руководство по планированию корпоративного управления обновлениями безопасности: Профилактическое обслуживание для ИТ»), о котором мы писали ранее;
· Недостатки процесса управления киберугрозами: некорректные или недостаточно строгие правила на СЗИ, отсутствие сетевой сегментации, недостаточная фильтрация почтового и веб-трафика и т.д.;
· Недостатки в эталонных образах и базовых конфигурациях (Baseline), отсутствие харденинга — т.е. защищенной настройки устройств по рекомендациям производителей и лучшим ИБ-практикам;
· Недостатки в процессах разработки безопасного ПО (SSDLC, Secure Software Development Lifecycle), отсутствие практик AppSec при разработке и кастомизации ПО в организации;
· Архитектурные недостатки информационных систем, включая отсутствие или некорректную интеграцию защитных технологий;
· Недостатки в процессах и процедурах управления киберинцидентами;
· Слабая осведомленность и подготовленность пользователей и администраторов в вопросах киберугроз и инцидентов ИБ.
Описанные в публикации NIST SP 800-115 этапы анализа защищенности можно применять при проведении различных типов оценок защищенности, включая аудиты ИБ, сканирование на наличие уязвимостей, пентесты, оценки Red Team, киберучения, программы Bug Bounty. Расскажем про каждый вид анализа защищенности подробнее.
1. Аудит ИБ — это проверка полноты и эффективности системы управления ИБ (СУИБ), включая проверку реализации организационных и технических мер и оценку состояния соответствия СУИБ требованиям внутренних и внешних нормативных актов. В рамках аудита ИБ проверяется достаточность и корректность организационных мер, включая разработанные политики, стандарты, регламенты, процедуры, инструкции по ИБ, а также оценивается уровень ИБ-осведомленности работников компании. Для оценки технических мер проверяются конфигурации информационных систем, сетевого оборудования, отдельных устройств (серверов, рабочих станций), а также проверяются настройки имеющихся СЗИ-решений класса EDR/XDR, SIEM, DLP, систем фильтрации трафика и т.д. Для оценки степени соответствия проверяется реализация и организационных, и технических мер в соответствии с требованиями нормативных актов (внутренних нормативных документов, отраслевых стандартов, государственных нормативных правовых актов). Аудит может быть внутренним и внешним: внутренний аудит ИБ проводится силами выделенных работников самой организации и является процессом оценки полноты и эффективности СУИБ с корректировкой отдельных контрмер по результатам этих проверок, а внешний аудит ИБ реализуется в виде проекта и проводится по требованиям нормативных актов или по решению руководителей организации.
2. Сканирование на наличие уязвимостей — это процесс автоматизированного обнаружения уязвимостей и недостатков конфигураций в инфраструктуре компании. Уязвимости — это недостатки разработки, внедрения, настройки информационных систем или средств защиты, которые могут быть использованы атакующими для кибератаки. Автоматизировать процесс обнаружения уязвимостей и недостатков конфигураций помогают сканеры уязвимостей, которые выполняют различные типы сканирований (считывание баннеров, аутентифицированное сканирование, сканирование с помощью агента, ретро-сканирование), а также считывают текущие настройки систем и оценивают их безопасность в соответствии с рекомендациями производителей и лучшими ИБ-практиками. Подобное сканирование выполняют, например, продукты Security Vision VM (Vulnerability Management), Security Vision VS (Vulnerability Scanner), Security Vision SPC (Security Profile Compliance). Для работы сканеров уязвимостей используются различные реестры уязвимостей, такие как БДУ ФСТЭК России и база Common Vulnerabilities and Exposures (CVE), в которой CVE-записи связаны с данными классификатора ошибок (CWE), допускаемых при разработке ПО и приводящими к возникновению уязвимостей. Кроме того, важно помнить, что уязвимостями могут быть и недостатки организации корпоративных процессов — их нельзя выявить автоматизированными сканерами защищенности, их можно обнаружить или по результатам расследования случившегося инцидента, или в рамках аудитов ИБ, пентестов, оценок Red Team.
3. Пентест — это тестирование на проникновение (от англ. penetration test, сокращенно pentest), которое представляет собой проведение контролируемой кибератаки с целью обнаружения слабых мест в киберзащите компании и для последующего повышения уровня её защищенности. Пентесты проводятся методами черного, серого и белого ящиков, которые различаются уровнем знаний специалистов-пентестеров об исследуемом объекте (инфраструктуре, сети, системе). Пентесты, по аналогии с аудитами ИБ, могут быть внутренними и внешними: внутренние пентесты позволяют смоделировать атаку, выполняемую инсайдером из корпоративной сети, а внешние позволяют воспроизвести действия стороннего атакующего — хакера, хактивиста, кибернаёмника и т.д.. Кроме того, пентесты могут быть скрытыми и открытыми: скрытые выполняются без предупреждения ИТ-администраторов и ИБ-специалистов (о пентесте должны знать только избранные руководители в проверяемой компании), что позволяет смоделировать внезапную кибератаку в реальных условиях, а открытые предполагают осведомленность работников компании о проводимом тестировании, что позволяет снизить потенциальный негативный ущерб в случае успешной учебной кибератаки, а также помогает специалистам компании наглядно увидеть, как именно действуют атакующие. Автоматизировать пентест-проверки можно за счет применения систем класса BAS (Breach and Attack Simulation), имитирующих взломы и кибератаки, а также с использованием услуги CPT (Continuous Pen Test, непрерывное тестирование не проникновение), которую предлагают некоторые ИБ-игроки. Посмотреть же на свою инфраструктуру глазами хакера можно с использованием систем управления поверхностью атак (EASM, External Attack Surfare Management) — решений для непрерывного поиска, анализа, приоритизации, управления уязвимостями и потенциальными векторами кибератак.
4. Проверки Red Team (или Red Teaming) — это моделирование действий профессиональных и мотивированных киберпреступников, проводимое в течение длительного времени с использованием различных векторов кибератак для достижения заранее согласованных условных целей (например, компрометация привилегированной учетной записи, получение доступа к «секретному документу», несанкционированный перевод 1 рубля на счёт сторонней компании).В рамках Red Teaming «нападающие» эксперты ИБ применяют различные актуальные тактики, техники и процедуры атакующих, которые встречаются в реальных атаках "in the wild", проводят детальную предварительную разведку, используют методы социальной инженерии и физического проникновения на территорию проверяемой компании, ищут новые уязвимости и применяют самописные эксплойты, стараются оставаться незамеченными в течение всего проекта Red Team. Анализ защищенности подобного типа даёт самые актуальные и точные данные о состоянии кибербезопасности компании в условиях, максимально приближенных к боевым, однако проекты Red Teaming длятся долго (до нескольких месяцев), требуют привлечения самых лучших ИБ-экспертов (white hat, т.е. этичных хакеров) и поэтому достаточно затратны, а также могут отвлечь внимание ИБ-команды проверяемой компании от реальной атаки и действий настоящих киберпреступников.
5. Киберучения — это имитация кибератак в масштабе компании для тренировки и повышения слаженности действий защитников, обеспечения осведомленности о различных типах угроз и методах противодействия. Киберучения проводятся в форматах теоретической (Table-top exercise) и практической подготовки, в виде CTF-состязаний (Capture The Flag, "захват флага"), а также иных вариаций, различающихся уровнем реалистичности имитируемых кибератак и действий персонала. Для автоматизации и поддержки киберучений может применяться киберполигон (Cyber Range) — виртуальная инфраструктура, в которой смоделированы элементы реальной компании (сети, серверы, приложения, пользователи) и в рамках которой проводятся атаки и реагирование на них. Кроме команды Red Team (нападающие) в киберучениях участвует команда Blue Team (защитники, ИБ-специалисты SOC-центра или группы реагирования на инциденты) и могут также участвовать команды Purple Team (сборная команда Red Team + Blue Team, в которой атакующие обмениваются данными с защитниками для выработки наиболее эффективных контрмер), Yellow Team (команда разработчиков, которая получает информацию об актуальных векторах и техниках кибератак от Red Team и оптимальных контрмерах от Blue Team), White Team (команда руководителей и менеджеров, которые следят за корректностью работ и действий членов Red и Blue Team, разрабатывают методологию и политики, а также следят за выполнением требований законодательства).
6. Программа Bug Bounty — это способ обнаружения уязвимостей и недостатков в защите путём привлечения ИБ-исследователей (баг-хантеров, «охотников за ошибками») на коммерческой основе. Исследователям предлагается за денежное вознаграждение найти ошибку или уязвимость на веб-сайте, в сервисе, инфраструктуре или в приложении — в рамках определенных правил, с предоставлением исследователями подробных отчётов о найденных недостатках. Подобный способ позволяет компаниям привлечь широкий круг ИБ-специалистов для обнаружения уязвимостей и повышения уровня защищенности, а для этичных хакеров это может стать отличным способом применить свои навыки и заработать на этом.
Кроме публикации NIST SP 800-115, существует ряд других методологий и фреймворков для проведения анализа защищенности:
- OWASP Web Security Testing Guide (WSTG);
- OWASP Mobile Application Security (MAS);
- OWASP Firmware Security Testing Methodology (FSTM);
- PCI DSS Penetration Testing Guidance;
- Open Source Security Testing Methodology Manual (OSSTMM).
Для проведения анализа защищенности можно использовать различные инструменты — от известного дистрибутива Kali Linux до множества Open Source утилит, некоторые из которых приведены на странице проекта OWASP и в различных репозиториях GitHub.
.jpg)
