План внутреннего аудита ИБ: структура документа и что в нём должно быть

План ИБ-аудита — документ, который превращает абстрактное намерение проверить безопасность в работу с границами, сроками и проверяемым результатом. Состав плана задан в пункте 6.3.2.2 ГОСТ Р ИСО 19011-2021, и там довольно короткий перечень из восьми обязательных элементов плюс необязательные, часть которых для ИБ-аудита обязательна на практике.

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

Программа и план: как они связаны

Это два документа, и путать их не стоит. Программа аудитов составляется на период, обычно на год, и отвечает на вопросы, что компания проверяет, в каком порядке, кто проверяет и какими ресурсами. План составляется под каждую проверку из программы отдельно.

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

Состав программы задан пунктом 5.1 того же стандарта: цели программы, её риски и возможности, объём каждого аудита, график, типы аудитов, критерии, методы, критерии отбора аудиторов и относящаяся к программе документированная информация. Если программы пока нет, план первого аудита можно составить и без неё, но тогда в плане придётся определить и область, и критерии с нуля.

Структура плана: обязательные разделы

Восемь разделов из пункта 6.3.2.2 стандарта. Объём готового документа для одного аудита среднего масштаба — три-пять страниц, и раздувать его не нужно: план читают перед работой и во время неё.

Шапка и идентификация

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

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

Цели аудита

Главный раздел и чаще всего самый слабый. Цель формулируется как утверждение, которое по итогам проверки будет либо подтверждено, либо опровергнуто. Целей в одном плане стоит ставить одну-три: четыре цели означают, что в один аудит упаковали три.

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

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

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

Область аудита

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

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

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

Критерии аудита

Критерий — требование, с которым сравнивается фактическое состояние. В плане критерии либо перечисляются, либо даются ссылкой на реестр применимых требований, если он в компании есть.

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

Плохо: «парольная политика должна быть достаточной». Хорошо: «для всех учётных записей домена установлена минимальная длина пароля не менее 12 символов, блокировка после 5 неудачных попыток, запрет повторного использования последних 5 паролей».

Если по какому-то участку области критериев нет ни в одном из четырёх источников, это фиксируется в плане как ограничение. Вердикт по такому участку вынести нельзя, а сам факт отсутствия требования станет находкой аудита.

Документированная информация к рассмотрению

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

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

Методы и объём выборки

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

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

• привилегированные и сервисные учётные записи — 100%, их обычно десятки;
• учётные записи уволенных за период — 100%, это и есть предмет проверки;
• обычные пользовательские записи — выборка, например 10% или не меньше 30 записей, в зависимости от того, что больше;
• заявки на доступ за период — выборка по 5–10 заявок на каждый месяц;
• рабочие места — выборка по одному-двум на подразделение и площадку.

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

Места, даты и график работ

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

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

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

Состав группы, роли и ресурсы

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

Здесь же фиксируется независимость: по каждому аудитору одна строка о том, почему он независим от объекта проверки. Назначать аудитором ответственного за эксплуатацию проверяемой системы не стоит — по спорным местам вердикт предсказуемо будет в его пользу. Если в компании один специалист по ИБ, рабочих вариантов три: перекрёстная проверка между ИТ и ИБ, привлечение внутреннего аудита или службы безопасности, ротация аудиторов между участками.

Ресурсы — время участников, доступы, которые нужно выдать заранее, и инструменты. Доступы перечисляются конкретно: учётная запись с правами чтения в каталоге, доступ к консоли резервного копирования, права на запуск сканера в согласованном сегменте.

Разделы, которые стандарт называет дополнительными

Стандарт разрешает включить в план дополнительные пункты. Для ИБ-аудита три из них обязательны практически, потому что без них проверка создаёт риск сама по себе.

Обращение с материалами проверки

Материалы ИБ-аудита — это модель доступа, схема сети, перечень уязвимостей и выгрузки с учётными данными. По сути вы собираете в одном месте инструкцию по взлому собственной инфраструктуры.

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

Меры снижения рисков самой проверки

Инструментальная проверка способна уронить сервис, а активное сканирование в промышленном сегменте — вызвать срабатывание средств защиты и ночной звонок дежурному.

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

Действия по итогам предыдущих аудитов

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

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

«В плане обычно подробно расписаны цели и область, а выборка и правила обращения с материалами отсутствуют. Между тем по итогам аудита у вас на руках оказывается файл с полной моделью доступа компании, и вопрос, где он лежит, важнее формулировки целей. Мы просим определить это до начала работ, а не после», — Олег Власенко, руководитель отдела информационной безопасности ОБИТ.

Как выглядит заполненный план

Короткий пример по аудиту управления доступом, чтобы было видно уровень детализации, достаточный для работы.

Такой план занимает три страницы и заполняется за один рабочий день, если перечень активов и реестр требований уже есть. Если их нет, подготовка займёт больше времени, чем сам аудит.

Ошибки, из-за которых план не работает

Повторяются от компании к компании почти дословно.

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

«Проверить план перед первым аудитом можно одним приёмом: дайте его человеку, который проверку не проводил, и попросите сказать, что именно он должен сделать, в какие дни и как поймёт, что требование нарушено. Если он не отвечает на все три вопроса по документу, план ещё не готов», — Олег Власенко, руководитель отдела информационной безопасности ОБИТ.

Как составить план

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

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

Если нужно составить программу аудитов под свой режим требований или проверить готовый план перед первым циклом, приходите на бесплатную консультацию: разберём, какие требования к вам применимы, и покажем, каких разделов в документе не хватает.