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

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

Во время проверки важно получить ответы как минимум на четыре вопроса:

1. Какие активы и процессы необходимо защищать?
2. Какие требования и угрозы для них актуальны?
3. Какие меры должны быть реализованы?
4. Выполняются ли эти меры на практике?

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

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

Человеку сложно сохранять полную объективность при оценке системы, которую он сам проектировал или эксплуатирует. Это не вопрос профессионализма или добросовестности. Сотрудник знает, почему когда-то пришлось сделать исключение, и продолжает воспринимать его как временное и оправданное, даже если оно существует несколько лет.

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

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

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

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

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

Одна из самых распространенных ошибок — строить аудит вокруг перечня документов.

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

Но наличие документов не подтверждает, что установленные процедуры выполняются.

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

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

Для каждого проверяемого требования полезно определить доказательство его фактического выполнения.

Хороший внутренний аудит работает по принципу «покажите, как это выполняется», а не «покажите, где это написано».

Невозможно полноценно оценить защищенность актива, о существовании которого проверяющие не знают.

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

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

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

Перед оценкой мер защиты необходимо проверить сам объект аудита:

1. Сопоставить реестры ИТ, ИБ, закупок и владельцев процессов.
2. Уточнить, какие облачные сервисы используют подразделения.
3. Проверить внешние точки входа.
4. Сопоставить сетевую схему с фактическими подключениями.
5. Выявить системы, появившиеся после последней инвентаризации.
6. Проверить учетные записи сотрудников и подрядчиков.
7. Зафиксировать владельца каждого значимого актива.

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

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

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

NIST рассматривает техническую оценку как совокупность методов с разными возможностями и ограничениями. Отдельная проверка конфигурации, сканирование или анализ документации не дают полной картины сами по себе. Эта логика подробно раскрыта в опубликованном в 2008 году NIST SP 800−115.

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

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

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

Даже качественная проверка не меняет состояние безопасности сама по себе.

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

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

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

• риск или несоответствие;
• затронутые системы;
• требуемое действие;
• приоритет;
• владельца;
• зависимости;
• плановый срок;
• необходимый ресурс;
• подтверждение выполнения;
• необходимость повторной проверки.

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

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

Внешняя проверка нужна не всегда.

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

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

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

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

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

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

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

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

Международные подходы к управлению информационной безопасностью также исходят из комплексного рассмотрения людей, организационных процессов и технологий. Такой подход заложен, в частности, в актуальной международной редакции ISO/IEC 27 001:2022 и его российская версия ГОСТ Р ИСО/МЭК 27 001. ISO описывает стандарт как основу для системы менеджмента информационной безопасности, охватывающей людей, политики и технологии.

Здесь перечисление лучше сохранить: блок предназначен именно для самопроверки перед завершением аудита.

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

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

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

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

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

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

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

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