Объекты и критерии аудита » История » Версия 1
С. Антошкин, 04.06.2026 05:58
| 1 | 1 | С. Антошкин | {{>TOC}} |
|---|---|---|---|
| 2 | |||
| 3 | h1. Объекты и критерии аудита информационной безопасности |
||
| 4 | |||
| 5 | h2. Введение |
||
| 6 | |||
| 7 | Аудитор приходит в организацию с конкретным заданием. Но что именно он проверяет? Все документы? Все системы? Всех сотрудников? Очевидно, что полная проверка абсолютно всего невозможна ни по времени, ни по ресурсам. |
||
| 8 | |||
| 9 | Ответ на вопрос «что проверяем» определяется тремя понятиями, которые составляют методологическую основу любого аудита: *объект аудита* (что находится под проверкой), *критерии аудита* (с чем сравниваем) и *свидетельства аудита* (что служит доказательством). Без чёткого понимания всех трёх аудит превращается в неструктурированное хождение по организации. |
||
| 10 | |||
| 11 | bq. Эта тема закладывает понятийный фундамент для всех последующих тем курса. Независимо от того, проводится ли аудит по ISO 27001, PCI DSS или требованиям ФСТЭК — структура «объект → критерий → свидетельство» остаётся неизменной. |
||
| 12 | |||
| 13 | --- |
||
| 14 | |||
| 15 | h2. Объект аудита |
||
| 16 | |||
| 17 | *Объект аудита* — это то, что подвергается проверке: организация, подразделение, процесс, система, продукт или их совокупность. |
||
| 18 | |||
| 19 | В контексте аудита ИБ объектами могут выступать принципиально разные сущности, и от правильного определения объекта зависит вся дальнейшая работа. |
||
| 20 | |||
| 21 | h3. Область аудита |
||
| 22 | |||
| 23 | *Область аудита (Scope)* — чётко определённые границы того, что включено в аудит. Область фиксируется в программе и плане аудита и не может произвольно расширяться в процессе проверки. |
||
| 24 | |||
| 25 | Область аудита определяется по нескольким измерениям: |
||
| 26 | |||
| 27 | |_.Измерение|_.Что фиксируется|_.Пример| |
||
| 28 | |*Организационные границы*|Какие подразделения и юридические лица охвачены|Центральный офис и два филиала; дочерние компании исключены| |
||
| 29 | |*Процессные границы*|Какие бизнес-процессы входят в область|Процессы обработки персональных данных клиентов; HR-процессы исключены| |
||
| 30 | |*Технические границы*|Какие информационные системы и инфраструктура включены|CRM-система, платёжный шлюз, корпоративная почта; тестовые среды исключены| |
||
| 31 | |*Географические границы*|Какие локации охвачены|Серверная в Москве; резервная площадка в Санкт-Петербурге| |
||
| 32 | |*Временные границы*|За какой период проверяются записи и журналы|Период с 01.01.2024 по 31.12.2024| |
||
| 33 | |||
| 34 | Размытая область — одна из наиболее распространённых ошибок при организации аудита. Если область не зафиксирована точно, аудитор рискует либо пропустить критически важные системы, либо потратить время на проверку несущественного. |
||
| 35 | |||
| 36 | bq. Область аудита должна соответствовать области действия СУИБ, зафиксированной в документации организации. Если СУИБ охватывает только процессинговый центр, а аудит проводится для всего банка — это аудит за пределами задекларированной СУИБ, и его результаты не могут служить основой для сертификации по ISO 27001. |
||
| 37 | |||
| 38 | h3. Типы объектов аудита ИБ |
||
| 39 | |||
| 40 | Аудитор работает с объектами четырёх принципиально разных типов, каждый из которых требует собственных методов проверки. |
||
| 41 | |||
| 42 | *Документы и записи* — политики, регламенты, инструкции, журналы, отчёты, планы, договоры. Документы описывают намерения (что должно быть), записи подтверждают факты (что было). Проверка документов отвечает на вопрос «правильно ли это задумано?», проверка записей — «правильно ли это выполнялось?». |
||
| 43 | |||
| 44 | *Процессы и процедуры* — как организована работа: управление доступом, реагирование на инциденты, управление изменениями, резервное копирование. Процесс может быть задокументирован корректно, но выполняться с отклонениями — именно это расхождение чаще всего и выявляет аудит. |
||
| 45 | |||
| 46 | *Технические объекты* — конфигурации систем, сетевая архитектура, параметры межсетевых экранов, настройки аутентификации, журналы систем. Техническая проверка отвечает на вопрос «реализованы ли задуманные контроли в действующих системах?». |
||
| 47 | |||
| 48 | *Люди* — персонал организации: уровень осведомлённости о требованиях ИБ, понимание своих обязанностей, фактическое поведение на рабочем месте. Проверяется через интервью, наблюдение и тестирование. |
||
| 49 | |||
| 50 | --- |
||
| 51 | |||
| 52 | h2. Критерии аудита |
||
| 53 | |||
| 54 | *Критерии аудита* — совокупность требований, политик, процедур или стандартов, с которыми сравниваются собранные свидетельства. Критерии — это эталон, по отношению к которому определяется соответствие или несоответствие. |
||
| 55 | |||
| 56 | Без чётко определённых критериев аудит невозможен по определению. Нельзя сказать «это несоответствие», не ответив на вопрос «несоответствие чему?». |
||
| 57 | |||
| 58 | h3. Источники критериев |
||
| 59 | |||
| 60 | Критерии аудита могут быть внешними (заданными извне) и внутренними (установленными самой организацией). |
||
| 61 | |||
| 62 | *Внешние критерии:* |
||
| 63 | |||
| 64 | |_.Источник|_.Примеры|_.Обязательность| |
||
| 65 | |Международные стандарты|ISO/IEC 27001, ISO/IEC 27002, PCI DSS|Добровольная (для сертификации) или обязательная (по договору)| |
||
| 66 | |Национальные стандарты|ГОСТ Р ИСО/МЭК 27001, ГОСТ 57580.1|Обязательная для финансовых организаций по требованию ЦБ| |
||
| 67 | |Законодательство и нормативные акты|152-ФЗ, 187-ФЗ, приказы ФСТЭК №17/21/239|Обязательная| |
||
| 68 | |Отраслевые требования регуляторов|Положение ЦБ РФ 683-П, требования ФСБ|Обязательная для субъектов регулирования| |
||
| 69 | |Договорные обязательства|Требования клиента к безопасности в контракте|Обязательная в рамках договора| |
||
| 70 | |||
| 71 | *Внутренние критерии:* |
||
| 72 | |||
| 73 | |_.Источник|_.Примеры| |
||
| 74 | |Политика ИБ организации|Требования к парольной политике, классификации данных| |
||
| 75 | |Регламенты и процедуры|Регламент управления доступом, процедура резервного копирования| |
||
| 76 | |Стандарты конфигурации|Базовые конфигурации серверов, рабочих станций, сетевого оборудования| |
||
| 77 | |Планы и программы|План обработки рисков, программа обучения персонала| |
||
| 78 | |||
| 79 | h3. Иерархия критериев |
||
| 80 | |||
| 81 | При проведении аудита критерии выстраиваются в иерархию: внешние требования приоритетны над внутренними, а более специфичные требования конкретизируют общие. Например, при аудите банковской информационной системы иерархия может выглядеть так: положение ЦБ 683-П → ГОСТ 57580.1 → внутренняя политика ИБ банка → инструкция администратора системы. |
||
| 82 | |||
| 83 | Если внутренние критерии противоречат внешним — это само по себе несоответствие, которое фиксируется как находка аудита. |
||
| 84 | |||
| 85 | h3. Критерии и профиль защиты |
||
| 86 | |||
| 87 | Для систем, подлежащих сертификации по Common Criteria(ISO/IEC 15408), критериями аудита служат ПЗ(профили защиты) — типовые наборы требований безопасности для класса продуктов. Связь с оценочными уровнями доверия подробно рассматривалась в курсе [[uib:ISM|«Основы менеджмента ИБ»]]. |
||
| 88 | |||
| 89 | --- |
||
| 90 | |||
| 91 | h2. Свидетельства аудита |
||
| 92 | |||
| 93 | *Свидетельства аудита* — записи, изложение фактов или иная информация, относящаяся к критериям аудита и поддающаяся верификации. |
||
| 94 | |||
| 95 | Ключевое слово — *верификация*. Свидетельство должно быть объективным и проверяемым. «Сотрудник сказал, что всегда блокирует компьютер при уходе» — это не свидетельство. «Журнал событий Windows за последние 30 дней не содержит ни одной записи о сессии длиннее 15 минут без блокировки экрана на рабочей станции сотрудника» — это свидетельство. |
||
| 96 | |||
| 97 | h3. Типы свидетельств |
||
| 98 | |||
| 99 | *Документальные свидетельства* — письменные материалы: политики, регламенты, записи журналов, отчёты, договоры, сертификаты, электронная переписка, скриншоты систем, результаты сканирований. Наиболее надёжный тип — существуют независимо от аудитора и могут быть проверены повторно. |
||
| 100 | |||
| 101 | *Наблюдательные свидетельства* — результаты личного наблюдения аудитора: физическое состояние объекта, поведение персонала, фактически выполняемые операции. Пример: аудитор наблюдает, что посетители входят в серверную без сопровождения, несмотря на требование политики. Достоинство: отражает реальность в момент наблюдения. Ограничение: зависит от наблюдателя, трудно воспроизводим. |
||
| 102 | |||
| 103 | *Свидетельства из интервью* — информация, полученная в ходе опроса персонала. Подтверждают или опровергают понимание сотрудниками своих обязанностей в области ИБ. Важно: сами по себе показания персонала не являются достаточным свидетельством — они должны подтверждаться документальными или наблюдательными данными. |
||
| 104 | |||
| 105 | *Технические свидетельства* — результаты технических проверок: сканирования уязвимостей, анализа конфигураций, проверки журналов, тестирования контролей. Обеспечивают наиболее точный ответ на вопрос о фактическом состоянии технических мер защиты. |
||
| 106 | |||
| 107 | h3. Требования к свидетельствам |
||
| 108 | |||
| 109 | Не каждая информация является приемлемым свидетельством. ISO 19011 устанавливает два требования. |
||
| 110 | |||
| 111 | *Достаточность* — количество и качество свидетельств должны быть достаточными для формулирования вывода о соответствии. Один документ с правильным заголовком не является достаточным свидетельством того, что процесс работает. Нужны записи о его фактическом выполнении. |
||
| 112 | |||
| 113 | *Надлежащий характер* — свидетельства должны относиться к предмету проверки и быть достоверными. Свидетельство, полученное из единственного источника, слабее подтверждённого независимыми источниками. |
||
| 114 | |||
| 115 | h3. Принцип треугольника свидетельств |
||
| 116 | |||
| 117 | На практике аудиторы применяют принцип, который можно назвать треугольником свидетельств: для каждого значимого вывода желательно иметь подтверждение из трёх независимых источников разного типа. |
||
| 118 | |||
| 119 | Пример для проверки выполнения политики парольной защиты: документальное свидетельство (политика паролей утверждена и содержит требование минимальной длины 12 символов), техническое свидетельство (скриншот групповой политики Active Directory показывает минимальную длину пароля 12 символов), наблюдательное или из интервью свидетельство (сотрудник IT-службы подтверждает, что политика применяется ко всем учётным записям, включая сервисные). |
||
| 120 | |||
| 121 | Если все три источника согласуются — вывод о соответствии надёжен. Если между ними есть противоречие — это само по себе сигнал для углублённой проверки. |
||
| 122 | |||
| 123 | --- |
||
| 124 | |||
| 125 | h2. Находки аудита |
||
| 126 | |||
| 127 | *Находки аудита* — результаты оценки собранных свидетельств в сравнении с критериями аудита. Находки бывают трёх видов. |
||
| 128 | |||
| 129 | h3. Несоответствие |
||
| 130 | |||
| 131 | *Несоответствие* — невыполнение требования. Это центральное понятие аудита соответствия. Несоответствия делятся на два класса по серьёзности. |
||
| 132 | |||
| 133 | *Значительное несоответствие* — отсутствие или полный отказ системы управления, влекущий за собой серьёзный риск. Примеры: полное отсутствие процесса управления доступом при наличии требования, систематическое невыполнение ключевого контроля, несоответствие, создающее условия для реализации критического риска. Значительное несоответствие блокирует сертификацию до устранения. |
||
| 134 | |||
| 135 | *Незначительное несоответствие* — единичное или незначительное отклонение от требования, не создающее немедленного серьёзного риска. Примеры: один журнал из двадцати не подписан ответственным лицом, процедура документирована, но не обновлялась последние 13 месяцев вместо требуемых 12. Незначительные несоответствия требуют корректирующих действий, но не блокируют сертификацию. |
||
| 136 | |||
| 137 | h3. Наблюдение |
||
| 138 | |||
| 139 | *Наблюдение (Observation)* — ситуация, которая формально не является несоответствием, но указывает на потенциальный риск или возможность улучшения. Наблюдения не требуют обязательных корректирующих действий, но рекомендуются к рассмотрению руководством. |
||
| 140 | |||
| 141 | Пример: политика ИБ требует ежеквартального пересмотра прав доступа. Пересмотр проводится, документы в порядке. Но аудитор замечает, что в последних трёх пересмотрах не было выявлено ни одного избыточного права — что статистически маловероятно и может указывать на формальный подход к процедуре. |
||
| 142 | |||
| 143 | h3. Подтверждение соответствия |
||
| 144 | |||
| 145 | *Подтверждение соответствия* — вывод о том, что требование выполняется и свидетельства это подтверждают. Важно фиксировать не только несоответствия, но и подтверждённые случаи соответствия: итоговый отчёт должен давать сбалансированную картину состояния СУИБ. |
||
| 146 | |||
| 147 | --- |
||
| 148 | |||
| 149 | h2. Связь объектов, критериев и свидетельств |
||
| 150 | |||
| 151 | Три понятия образуют логическую цепочку, которая лежит в основе каждой проверки в ходе аудита. |
||
| 152 | |||
| 153 | Для каждого требования из области аудита аудитор: определяет, какой объект несёт ответственность за выполнение этого требования; собирает свидетельства о состоянии этого объекта; сравнивает свидетельства с критерием; формулирует вывод о соответствии или несоответствии. |
||
| 154 | |||
| 155 | Рассмотрим пример для требования ISO 27001 контроля 8.5 «Безопасная аутентификация». |
||
| 156 | |||
| 157 | !clipboard-202606040858-izpgi.png! |
||
| 158 | |||
| 159 | |_.Критерий|_.Объект|_.Свидетельства|_.Возможный вывод| |
||
| 160 | |ISO 27001:2022, контроль 8.5: применяться технологии безопасной аутентификации, включая MFA для привилегированного доступа|Конфигурация Active Directory; учётные записи администраторов|Скриншот политики AD (MFA не настроен); список учётных записей с правами Domain Admin (18 записей); журнал событий безопасности (входы без второго фактора)|Значительное несоответствие: MFA не реализован ни для одной из 18 привилегированных учётных записей| |
||
| 161 | |||
| 162 | --- |
||
| 163 | |||
| 164 | h2. Выборка в аудите |
||
| 165 | |||
| 166 | Полная проверка всех объектов невозможна и нецелесообразна. Аудитор работает с *выборкой* — репрезентативным подмножеством объектов, по которому делает вывод о состоянии всей популяции. |
||
| 167 | |||
| 168 | h3. Подходы к формированию выборки |
||
| 169 | |||
| 170 | *Основанная на риске выборка* — приоритет отдаётся объектам с наибольшим риском или наибольшим потенциальным ущербом от несоответствия. Если в организации 200 информационных систем, аудитор начинает с тех, которые обрабатывают наиболее критичные данные. |
||
| 171 | |||
| 172 | *Случайная выборка* — объекты выбираются случайным образом, что обеспечивает статистическую репрезентативность. Применяется для проверки типовых контролей, одинаково применяемых ко всей популяции (например, проверка парольной политики на случайной выборке из 30 учётных записей из общего числа 2000). |
||
| 173 | |||
| 174 | *Целенаправленная выборка* — выбираются специфические объекты, основанные на профессиональном суждении аудитора: новые системы (высокий риск незрелых процессов), системы с историей инцидентов, области, не проверявшиеся в предыдущем аудите. |
||
| 175 | |||
| 176 | h3. Документирование выборки |
||
| 177 | |||
| 178 | Метод формирования выборки и её состав документируются в рабочих материалах аудита. Это необходимо по двум причинам: для защищаемости выводов (вывод о несоответствии, основанный на прозрачной выборке, убедительнее вывода «мы посмотрели несколько систем») и для воспроизводимости (повторный аудит использует сопоставимую выборку). |
||
| 179 | |||
| 180 | --- |
||
| 181 | |||
| 182 | h2. Типичные ошибки при определении объектов, критериев и свидетельств |
||
| 183 | |||
| 184 | |_.Ошибка|_.Последствие| |
||
| 185 | |Область аудита не зафиксирована или сформулирована размыто|Разногласия между аудитором и организацией о том, что должно быть проверено; риск пропустить критические системы| |
||
| 186 | |Критерии не согласованы с организацией до начала аудита|Организация оспаривает выводы, ссылаясь на неприменимость критериев| |
||
| 187 | |Свидетельства основаны только на словах персонала|Низкая надёжность выводов; риск ошибочного подтверждения соответствия| |
||
| 188 | |Не разграничиваются значительные и незначительные несоответствия|Невозможно приоритизировать корректирующие действия; потеря доверия к отчёту| |
||
| 189 | |Выборка смещена в сторону «хороших» объектов|Аудит выявляет только то, что организация готова показать; реальные проблемы остаются скрытыми| |
||
| 190 | |Свидетельства не документируются в момент сбора|Невозможно защитить выводы после завершения аудита; проверяемая сторона может оспорить факты| |
||
| 191 | |||
| 192 | --- |
||
| 193 | |||
| 194 | h2. Что дальше |
||
| 195 | |||
| 196 | Определив объекты и критерии, необходимо понять, *с чего начинать* — какие объекты проверять в первую очередь и насколько глубоко. Ответ даёт риск-ориентированный подход к аудиту. |
||
| 197 | |||
| 198 | * *Следующая тема:* [[Оценка_рисков_в_аудите|3. Риск-ориентированный аудит: связь с ISO 27005]] |
||
| 199 | * *Методы сбора свидетельств:* [[Аудит_безопасности_и_методы_его_проведения|4. Методы проведения аудита]] — интервью, наблюдение, технические проверки |
||
| 200 | * *Оформление находок в отчёте:* [[Отчетная_документация|16. Отчёт об аудите и работа с несоответствиями]] |
||
| 201 | |||
| 202 | --- |
||
| 203 | |||
| 204 | h2. Список литературы и стандартов |
||
| 205 | |||
| 206 | * "ISO 19011:2018":https://www.iso.org/standard/70017.html — разделы 3 (термины), 6.4 (проведение аудита), 6.5 (выборка) |
||
| 207 | * "ISO/IEC 27007:2021":https://www.iso.org/standard/77802.html — руководство по аудиту СУИБ |
||
| 208 | * "ISO/IEC 27001:2022":https://www.iso.org/standard/27001.html — Приложение А: контроли как критерии аудита |
||
| 209 | * ISACA — IS Audit and Assurance Guideline 2205: Evidence |
||
| 210 | * "NIST SP 800-53A":https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final — Assessing Security Controls (методология оценки контролей) |