План мероприятий по информационной безопасности после аудита: как составить и реализовать

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

Что делать сразу после аудита информационной безопасности

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

Разобрать отчет и оценить выявленные проблемы

Начать стоит с общей встречи аудиторов, специалистов по информационной безопасности и IT-отдела. По каждому замечанию нужно уточнить, где и как обнаружена проблема, какие системы и данные она затрагивает, к чему может привести и чем обоснована рекомендация. Формулировку «усилить контроль доступа» нельзя превратить в задачу, пока не будет понятно, идет ли речь об общей учетной записи, избыточных правах или отсутствии двухфакторной аутентификации.

Дальше стоит обработать отчет в три шага:

1. Разделить замечания по типам. Это могут быть технические уязвимости и ошибки настройки, недостатки процессов, несоответствия обязательным или внутренним требованиям, а также возможности для развития системы информационной безопасности.
2. Привести проблемы к «общему знаменателю». Например, действующие учетные записи уволенных сотрудников, несвоевременно отозванные права и доступы «на всякий случай» могут быть следствиями одного недостатка — между HR и IT не выстроен процесс увольнения.
3. Связать каждую проблему с риском для бизнеса. Здесь нужно учесть ценность затронутой системы, доступность уязвимого компонента извне и наличие известных способов эксплуатации, возможные утечки и простои, а также уже действующие меры защиты.

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

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

Сформировать рабочую группу и назначить ответственных

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

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

Как составить план мероприятий по информационной безопасности

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

Что должно входить в план

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

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

Какие мероприятия включить в план

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

Так, мероприятия могут быть:

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

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

Как расставить приоритеты

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

Базовый способ — сопоставить уровень риска и сложность реализации:

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

Обязательные требования проверяют применительно к конкретной организации и информационной системе. Например, для оператора персональных данных учитывают 152-ФЗ и применимые требования приказа ФСТЭК России № 21. Требования ISO/IEC 27001 включают в план, если компания использует стандарт как критерий аудита, сертификации или договорное обязательство. Стоимость и сложность работ при этом не отменяют обязательных сроков.

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

Как оценить ресурсы, обосновать бюджет и составить дорожную карту

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

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

Как реализовать план и проверить результат

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

Организовать выполнение корректирующих действий

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

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

Устранить технические уязвимости без риска для работы систем

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

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

Контролировать прогресс и отчитываться о результатах

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

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

Подтвердить устранение замечаний и актуализировать план

Задачу закрывают не по сообщению исполнителя «готово», а по заранее установленному критерию. Подтверждением могут быть результаты повторного сканирования, настройки системы, журнал событий, утвержденный документ или проверка знаний сотрудников. Например, обновленный регламент не устраняет замечание, пока его не довели до работников и не убедились, что новый порядок выполняется.

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