Что такое аудит информационной безопасности и когда нужно его проводить?

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

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

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

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

В отличие от разового сканирования сети или установки нового средства защиты, аудит ИБ охватывает три слоя одновременно:

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

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

Зачем компании проводить аудит ИБ

Аудит ИБ решает четыре задачи бизнеса, а не только ИТ-отдела.

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

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

Привести инфраструктуру в соответствие требованиям. Для разных отраслей действуют разные обязательные нормы: 152-ФЗ для операторов персональных данных, 187-ФЗ для субъектов критической информационной инфраструктуры, приказы ФСТЭК для государственных систем, ГОСТ Р 57580 для банков. Аудит даёт чёткую картину: что выполнено, что — нет, какие штрафы возможны и как их избежать.

Обосновать бюджет на ИБ. Руководству легче утвердить расходы, когда они опираются не на абстрактные тренды, а на конкретный список рисков с оценкой ущерба и приоритетов. Аудит превращает абстрактный запрос на новый SIEM в конкретное обоснование: 60% инцидентов остаются незамеченными, три из них уже привели к утечкам в этом году.

Дополнительно аудит ИТ-безопасности помогает оптимизировать существующие траты — отказаться от дублирующих средств защиты, отозвать лишние лицензии, упростить процессы. На практике в наших проектах мы регулярно видим, как компания платит за три похожих инструмента, ни один из которых не настроен полностью.

Когда нужно проводить аудит информационной безопасности

Аудит бывает плановым и внеплановым. Плановый стоит проводить регулярно — внутренний 2-4 раза в год, внешний один раз в год. Внеплановый запускается, когда меняются условия, в которых работает ИТ-инфраструктура.

Триггеры, при которых аудит нужен в ближайшие 1-3 месяца:

• Произошёл инцидент — утечка, успешная атака, шифровальщик, инсайдер. Аудит фиксирует, через что атакующий вошёл и какие смежные риски остались.
• Меняется инфраструктура — переезд в облако, переход с зарубежных решений на российские, объединение филиалов, внедрение новой ERP или CRM.
• Идёт реорганизация — слияние или поглощение, продажа подразделения, смена собственника. Аудит помогает оценить риски due diligence и показывает, что наследуется от другой компании.
• Меняется руководитель ИБ или ИТ — новому человеку нужна объективная картина состояния, а не пересказ предшественника.
• Готовится сертификация — ISO/IEC 27001, аттестация по требованиям ФСТЭК, PCI DSS. Перед сертификационным аудитом полезен внутренний gap-аудит, чтобы заранее устранить несоответствия.
• Появились новые требования регулятора — например, компания попала под действие 187-ФЗ как субъект КИИ или Роскомнадзор расширил требования к операторам персональных данных.
• Партнёр или клиент запросил подтверждение защиты — крупные заказчики всё чаще включают аудит ИБ подрядчика в условия контракта.
• Прошло больше года с прошлого аудита — даже если ничего не менялось, изменился ландшафт угроз.

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

Какие бывают виды аудита ИБ

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

По исполнителю

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

Внешний аудит выполняет независимая компания. Выше объективность, шире экспертиза, есть возможность сертифицироваться или получить заключение для регулятора. Стоит дороже и требует подписания NDA, но именно внешнее заключение нужно при проверках ФСТЭК, Роскомнадзора, банковского регулятора и крупных клиентов.

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

По охвату и цели

• Комплексный аудит ИБ — полная оценка всех слоёв: документы, техника, процессы, люди. Подходит, когда нужно получить общую картину или давно не было ревизии.
• Технический аудит — сканирование уязвимостей, проверка конфигураций, анализ сетевой архитектуры, аудит кода приложений. Глубоко, но узко.
• Compliance-аудит, или аудит на соответствие — проверка по конкретному стандарту: 152-ФЗ, требованиям ФСТЭК, ISO 27001, PCI DSS, ГОСТ Р 57580. Цель — подтвердить готовность к проверке или сертификации.
• Аудит процессов ИБ — оценка зрелости управления: как организованы реагирование на инциденты, управление доступом, обучение сотрудников, работа с подрядчиками.
• Аудит конкретных сегментов — например, только облачная инфраструктура, только АСУ ТП, только система ДБО, только корпоративный портал.

По методу

• Документальный (экспертно-документальный) — анализ политик, регламентов, журналов, проектной документации, интервью с сотрудниками.
• Инструментальный — сканирование сети, поиск уязвимостей, анализ конфигураций, проверка прав доступа автоматизированными средствами.
• Активный с имитацией атаки — пентест, фишинговые рассылки сотрудникам, попытки физического проникновения, проверки социальной инженерии.

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

Чем аудит ИБ отличается от пентеста и комплаенса

Три понятия часто путают, хотя у каждого свой смысл.

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

Комплаенс (compliance) — проверка соответствия требованиям нормативных актов и стандартов. Результат: список несоответствий с отсылкой к конкретному пункту 152-ФЗ или приказа ФСТЭК. Комплаенс отвечает на вопрос, соблюдает ли компания требования законодательства.

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

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

Что проверяется в ходе аудита ИБ

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

Организационная база и документация

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

Управление доступом

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

Сетевая инфраструктура

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

Серверы, СХД и базы данных

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

Рабочие места и мобильные устройства

Антивирусная защита, шифрование дисков, политики USB-устройств, обновление операционных систем, права локального администратора, корпоративные мобильные устройства, BYOD-сценарии.

Средства защиты и мониторинг

Состав и настройки SIEM, DLP, EDR, NGFW, IDS/IPS, антивирусов. Покрывают ли они критичные системы. Регистрируются ли события безопасности, есть ли регламент реагирования, кто разбирает инциденты и в какие сроки.

Резервное копирование и восстановление

Что копируется, как часто, где хранится, сколько лет глубина хранения, проверяется ли восстановление, защищены ли копии от шифровальщика (offline-копии, иммутабельные хранилища). Это первое, что спасает после атаки, и первое, что обычно работает не так, как описано в регламенте.

Персонал и осведомлённость

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

Этапы проведения аудита ИБ

Структура и логика этапов одинаковы для внутреннего и внешнего аудита. Различается только глубина проработки.

1. Подготовка и планирование. Определяем цели, объём, границы (какие системы, подразделения, площадки входят в проверку), критерии оценки. Согласовываем NDA, план-график, регламент взаимодействия. Готовим список запрашиваемых документов и ответственных. Длительность: от 3 до 7 рабочих дней.
2. Сбор данных. Аудиторы получают политики, регламенты, журналы, схемы инфраструктуры, конфигурации, выгрузки прав доступа. Параллельно проходят интервью с владельцами процессов, ИТ-специалистами, ответственными за ИБ. Длительность: 5-10 дней.
3. Техническая проверка. Сканирование уязвимостей, анализ конфигураций, проверка прав доступа, при необходимости — пентест и проверки социальной инженерии. На этом этапе аудит ИБ переходит из бумажной плоскости в инфраструктурную. Длительность: 5-15 дней.
4. Анализ и оценка рисков. Все найденные проблемы оцениваются по критичности, вероятности эксплуатации и потенциальному ущербу. Несоответствия группируются и привязываются к конкретным пунктам стандартов или законов. Длительность: 3-5 дней.
5. Подготовка отчёта. Аудит даёт два документа: краткое резюме для руководства (Executive Summary) и подробный технический отчёт со списком уязвимостей, рекомендациями и планом устранения с приоритетами. Длительность: 3-7 дней.
6. Презентация и обсуждение результатов. Аудитор разбирает находки с командой заказчика, отвечает на вопросы, помогает выстроить очерёдность работ. На этом же этапе фиксируется, какие из находок берутся в работу в ближайшие месяцы, а какие требуют отдельных проектов.

По договорённости добавляется седьмой этап — контроль устранения через 3-6 месяцев, когда аудитор возвращается и проверяет, что план выполнен.

Какие стандарты и нормативы применяются

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

На практике крупная компания обычно подпадает под несколько групп одновременно. Например, промышленный холдинг с собственным дата-центром обрабатывает персональные данные сотрудников (152-ФЗ), управляет АСУ ТП (приказ ФСТЭК №31) и может оказаться субъектом КИИ (187-ФЗ). Аудит ИБ помогает разобрать этот клубок требований и понять, какие из них уже выполнены, а какие — нет.

Что получает заказчик по итогам аудита

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

• Управленческое резюме (Executive Summary) — 3-5 страниц для топ-менеджмента. Общая оценка состояния, ключевые риски в денежном или операционном выражении, приоритеты на ближайшие 6-12 месяцев.
• Технический отчёт — детальное описание каждой находки, способ её воспроизведения (для критичных уязвимостей), затронутые активы, оценка по CVSS или иной шкале, конкретная рекомендация по устранению.
• Реестр несоответствий нормативам — таблица с привязкой каждой проблемы к пункту 152-ФЗ, приказа ФСТЭК или другого стандарта. Помогает доказать регулятору, что компания знает о расхождениях и работает над ними.
• Дорожная карта устранения — план-график с приоритетами. Критичные риски — устранение в течение 7-14 дней, высокие — до 30 дней, средние — до 90 дней, низкие — в течение года.
• Обновлённая модель угроз — описание актуальных угроз для инфраструктуры компании с учётом найденных проблем.
• Сертификат или аттестат соответствия — если речь о сертификационном аудите (ISO 27001, аттестация по ФСТЭК, PCI DSS).

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

Типичные ошибки при проведении аудита

Большинство неудачных аудитов проваливаются по одним и тем же причинам.

1. Формальный аудит. Компания заказывает проверку, чтобы показать регулятору или собственнику. Отчёт ложится в стол, рекомендации не выполняются, через год ситуация повторяется. Решение — заранее договариваться с подрядчиком о формате контроля исполнения, а не только о самом аудите.
2. Ограниченный доступ для аудиторов. Команду заказчика просят не показывать одни системы, не открывать другие, не обсуждать третьи — в итоге часть инфраструктуры остаётся серой зоной. Если есть данные, которые нельзя раскрывать, безопаснее работать через NDA и контролируемый доступ, чем скрывать сегменты целиком.
3. Фокус только на технике. Сканеры находят уязвимости, но не покажут, что прошлый администратор уволился полгода назад, а его учётка с правами доменного админа всё ещё активна. Большая часть успешных атак идёт через процессы и людей, а не через CVE.
4. Игнорирование рекомендаций. План есть, бюджет нет, дедлайнов нет, ответственных нет. Через год — следующий аудит с теми же находками. Решение — на этапе планирования аудита договариваться, кто будет владельцем плана устранения и куда уходит отчёт после презентации результатов.
5. Разовый подход. После одного успешного аудита компания считает задачу выполненной на годы вперёд. ИТ-инфраструктура и угрозы меняются быстрее годового цикла, поэтому одноразовый аудит работает только как стартовая точка. Дальше нужен регулярный процесс.

Что делать после аудита

Отчёт получен. Что дальше — определяет, окупится аудит или останется упражнением.

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

Второе — назначить владельцев. У каждой группы рекомендаций должен быть конкретный человек и срок. Задача установить обновления на серверы закрепляется за системным администратором со сроком 14 дней, а не размывается как коллективная ответственность ИТ-отдела.

Третье — выполнить быстрые меры в течение 30 дней. Это создаёт ощущение прогресса и снимает с команды чувство, что задача неподъёмная. Параллельно запускаются проекты на средние и долгие задачи: внедрение SIEM, переработка политик, обучение сотрудников.

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

Пятое — назначить следующий аудит. Не абстрактно в будущем, а с конкретной датой в календаре. Минимум — внутренний аудит через 6 месяцев и внешний через год. Без этой точки следующая итерация откладывается до очередного инцидента.

Аудит ИБ как процесс, а не разовая проверка

Аудит информационной безопасности — это не разовая проверка перед визитом регулятора, а инструмент управления рисками, который превращает разрозненные технические данные в управленческие решения. Регулярный аудит ИБ снижает вероятность инцидентов, помогает соответствовать требованиям 152-ФЗ, 187-ФЗ, приказов ФСТЭК и отраслевых стандартов, обосновывает бюджет и делает работу службы безопасности измеримой.

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