The Auditor's Frame: Thinking Like an IS Auditor

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

Риск в первую очередь, технология — во вторую

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

Конкретно: если вы проверяете контроль доступа в системе расчетов заработной платы, первый вопрос — не «включена ли MFA?» А «какой будет последствие, если несанкционированный человек сможет изменить данные зарплаты или просмотреть PII?» Когда вы знаете масштаб влияния, можно оценить, соответствуют ли существующие контроли (MFA, рабочие процессы одобрения, разделение обязанностей) уровню риска.

Доказательства, а не утверждения

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

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

Проектирование и операционная эффективность

Одно из самых полезных различий в этой сфере — разделение дизайна контроля и его операционной реализации. Политика паролей, требующая 14 символов и MFA, хорошо спроектирована на бумаге. Но если последняя проверка доступа была 11 месяцев назад, или если сервисные аккаунты исключены без документации, контроль работает не так, как задумано. Аудиторы проверяют оба: существует ли контроль так, как описано, и действительно ли он соблюдается день за днем?

Отсюда важность выборки. Проверка доступа одного пользователя мало что скажет. Извлечение выборки из 25 уволенных сотрудников и проверка того, были ли их аккаунты отключены в течение SLA (допустим, 24 или 48 часов), дает обоснованное основание для вывода.

Разделение обязанностей как повторяющаяся тема

Большая часть выводов аудита восходит к разделению обязанностей (SoD): один человек запрашивает изменение и одобряет его, или разработчик имеет прямой доступ к production базе данных вместе с правами развертывания. Аудиторы постоянно ищут такие пересечения, потому что отказы SoD — это то, как мошенничество и непреднамеренные ошибки проходят без проверки со стороны второй пары глаз.

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

Написание выводов, которые реализуются

Технически правильный вывод, на который никто не реагирует, — это потраченный аудит. Хорошие выводы содержат условие (что было наблюдаемо), критерии (какую политику или стандарт это нарушает), причину (почему это произошло) и эффект (какой риск это создает) — классическую структуру 4С, используемую многими аудит-командами. Расплывчатые выводы вроде «контроли доступа нужно улучшить» игнорируются. Конкретные вроде «14 из 25 проверенных уволенных сотрудников сохранили доступ VPN более чем на 5 дней после даты увольнения, что нарушает SLA деprovisioning в 24 часа из политики SEC-014» становятся предметом исправления, потому что владелец точно знает, что нужно исправить.

Выработка привычки

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

Если этот вид мышления о контролях и рисках вас интересует, посмотрите материалы Korra Studio по моделям контроля доступа и фреймворкам security governance для более глубокого технического изучения.