Что входит в аудит информационной безопасности
Единого состава работ для всех проектов нет. Однако полноценный аудит обычно включает несколько этапов.
1. Определение целей и критериев
До начала проверки необходимо ответить на вопросы:
- зачем проводится аудит;
- какие требования необходимо проверить;
- какие системы и подразделения входят в область аудита;
- какие объекты исключаются;
- какой уровень детализации нужен;
- кто будет использовать результаты;
- в каком формате должен быть подготовлен итоговый отчет.
Если критерии не определены, аудит рискует превратиться в общий осмотр инфраструктуры без понятного ответа, какие именно требования выполняются и какие риски необходимо устранить.
2. Определение границ проверки
В область аудита могут входить:
- информационные системы;
- серверы и рабочие станции;
- сетевые сегменты;
- сетевое оборудование;
- облачные ресурсы;
- сайты и приложения;
- средства защиты информации;
- подразделения и филиалы;
- подрядчики с доступом к системам;
- документы и локально-нормативные акты;
- отдельные бизнес-процессы.
Граница должна быть зафиксирована однозначно. Формулировки вроде «проверить информационную безопасность компании» недостаточно: стороны могут по-разному понимать объем такой работы.
3. Сбор исходных данных
На этом этапе аудитор получает документы и сведения, необходимые для понимания системы защиты.
В зависимости от состава инфраструктуры сбор исходных данных может включать очный выезд к заказчику. Это особенно актуально, когда значительная часть инфраструктуры размещена в собственных серверных или для оценки требуется доступ к локальным системам, оборудованию и процессам, которые невозможно полноценно проверить дистанционно.
В зависимости от проекта могут запрашиваться:- схема организационной структуры;
- перечень информационных систем;
- реестр информационных активов;
- описание сетевой архитектуры;
- сведения о средствах вычислительной техники и сетевом оборудовании;
- перечень средств защиты;
- модель угроз;
- локальные нормативные акты;
- матрицы доступа;
- сведения об администраторах и привилегированных пользователях;
- регламенты резервного копирования;
- документы по реагированию на инциденты;
- договоры с подрядчиками;
- результаты предыдущих проверок;
- журналы событий и сведения об инцидентах;
- информация о настройках встроенных механизмов обеспечения безопасности и средств защиты.
Если реестр систем или активов отсутствует, в зависимости от согласованной области аудита может потребоваться сначала определить фактический состав инфраструктуры. Это увеличивает трудоемкость проекта и может стать отдельным результатом обследования.
4. Интервью и обследование процессов
Документы не всегда отражают реальную практику. Поэтому аудит может включать интервью с представителями:
- руководства;
- ИТ-службы;
- подразделения информационной безопасности;
- юридического и комплаенс-подразделений;
- HR;
- владельцами информационных систем;
- разработчиками;
- сотрудниками, взаимодействующими с подрядчиками.
Интервью нужны не для формального подтверждения документов, а для восстановления фактической картины: кто выдает доступы, как согласовываются изменения, что происходит при увольнении сотрудника, кто проверяет резервные копии и как организация действует при инциденте.
В одном из проектов Б-152 аудит начался с анкетирования и интервью. Команда зафиксировала используемые системы, места хранения данных, порядок предоставления доступов и взаимодействие с подрядчиками. Это позволило сформировать рекомендации, основанные на реальных процессах, а не только на комплекте документов.
5. Анализ документов
Аудитор проверяет:
- наличие необходимых документов;
- их актуальность;
- соответствие выбранным требованиям;
- согласованность документов между собой;
- распределение ответственности;
- соответствие регламентов реальной практике;
- наличие подтверждений выполнения установленных процедур.
Само наличие политики или регламента еще не означает, что соответствующая мера реализована. Если документ требует регулярно пересматривать права доступа, в ходе аудита необходимо проверить, существуют ли результаты такого пересмотра.
6. Проверка организационных и технических мер
В зависимости от области аудита может оцениваться:
- учет активов;
- управление учетными записями;
- предоставление и отзыв доступа;
- использование привилегированных учетных записей;
- защита удаленного доступа;
- сегментация сети;
- обновление программного обеспечения;
- защита конечных устройств;
- журналирование событий;
- мониторинг;
- резервное копирование и восстановление;
- управление уязвимостями;
- защита облачных ресурсов;
- порядок работы подрядчиков;
- реагирование на инциденты;
- обучение сотрудников.
Методы проверки зависят от задания. Это могут быть изучение документов, интервью, наблюдение, анализ настроек, выборочная проверка подтверждающих материалов и согласованные технические тесты.
7. Фиксация несоответствий и рисков
Аудитор должен не просто перечислить замечания, а объяснить:
- какое требование или правило не выполняется;
- в чем заключается фактическая проблема;
- какие системы и процессы она затрагивает;
- к каким последствиям может привести;
- какие существующие меры снижают риск;
- что рекомендуется изменить;
- насколько срочно нужно принять меры.
Не все недостатки равнозначны. Отсутствующая подпись в одном документе и неотозванный привилегированный доступ бывшего администратора требуют разной реакции. Поэтому рекомендации необходимо приоритизировать с учетом контекста организации.
Когда при аудите рассчитывают Кзи и Узи
Для отдельных информационных систем и значимых объектов КИИ результаты аудита могут использоваться не только для формирования перечня замечаний, но и при расчете показателей, предусмотренных методическими документами ФСТЭК России.
Кзи — показатель защищенности, характеризующий текущее состояние технической защиты информации и обеспечения безопасности информационных систем. Он показывает степень достижения минимально необходимого уровня защиты от типовых актуальных угроз. Нормированному значению соответствует Кзи = 1. Значение от 0,75 до 1 указывает на низкий уровень защищенности, а Кзи ≤ 0,75 — на критический.
При расчете Кзи оцениваются частные показатели, связанные с организацией работ по ИБ, защитой пользователей и информационных систем, мониторингом и реагированием. Выводы должны подтверждаться документами и техническими свидетельствами: распорядительными актами, настройками средств защиты, журналами, отчетами и результатами проверок. Поэтому формального ответа «мера реализована» недостаточно.
Узи — показатель уровня зрелости, отражающий достаточность и эффективность организации деятельности по защите информации. При оценке учитывается не только наличие отдельных мер, но и устойчивость процессов: распределение ролей и ответственности, регулярность мероприятий, контроль результатов и устранение выявленных недостатков.
До 1 сентября 2026 года в приказе ФСТЭК России № 117 использовалось обозначение Пзи. После вступления в силу изменений показатель уровня зрелости обозначается как Узи.
Кзи и Узи не являются обязательными показателями любого аудита информационной безопасности. Их расчет включается в проверку, если это следует из требований, применимых к конкретной организации или информационной системе, либо прямо предусмотрено заданием на аудит.
Результаты интервью, анализа документов, изучения настроек, оценки защищенности и других контрольных мероприятий могут использоваться как исходные данные для расчета показателей. Если полученное значение не соответствует нормированному, выявленные недостатки учитываются при формировании первоочередных мер и дорожной карты.
8. Подготовка отчета и дорожной карты
Результатом аудита обычно становится отчет о текущем состоянии ИБ. В нем фиксируются область и критерии проверки, ограничения, выявленные несоответствия, риски и рекомендации.
Если компании необходимо перейти от диагностики к изменениям, дополнительно формируется дорожная карта. Она может содержать:
- перечень мероприятий;
- приоритет;
- рекомендуемую последовательность;
- ответственные подразделения;
- зависимости между задачами;
- ожидаемый результат;
- подтверждение выполнения.
В практике Б-152 встречались проекты, в которых аудит становился первым этапом более широкой работы. Например, для компании с распределенной инфраструктурой после оценки текущего состояния были подготовлены модель угроз, техническое задание, технический проект на создание системы защиты, локально-нормативные акты и обоснование необходимых мер защиты. Такой объем существенно отличается от проекта, который заканчивается только аудиторским отчетом.