Кадр аудитора: мислення як IS-аудитор

IS-аудитора найймають не для того, щоб знайти кожну баг або неправильну конфігурацію в системі. Робота вужча і, якщо чесно, складніша: з'ясувати, чи контролі, які є на місці, дають розумну впевненість у тому, що ризики для бізнесу управління. Це розмежування змінює підхід до майже кожного завдання, від читання набору правил брандмауера до інтерв'ю з власником системи.

Ризик спочатку, технологія потім

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

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

Докази замість тверджень

Власники систем вам щось розповідатимуть. Робота аудитора — перевірити, а не довіряти. Це означає запитування артефактів: скріншот екрана конфігурації, експорт прав доступу користувачів, квиток на зміну з позначками часу затвердження, записи журналу, що показують, що контроль справді спрацював. Якщо хтось каже «ми переглядаємо доступ щоквартально», аудитор просить показати останні три записи про перегляд, а не просто політику, що це вимагає.

Цей навик на основі доказів — це те, що відрізняє висновок аудиту від розмови в коридорі. Висновок повинен витримати дослідження: що було протестовано, яка сукупність була вибрана, які критерії були використані, і що насправді спостерігалося. Невизначені твердження, як-от «контролі здаються адекватними», не витримають у звіті, який читатимуть керівництво та регулятори.

Дизайн або операційна ефективність

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

Отже, вибірка важлива. Тестування доступу одного користувача не дає багато інформації. Вибір вибірки з 25 звільнених співробітників і перевірка того, чи були їхні облікові записи вимкнені протягом вікна SLA (скажімо, 24 або 48 годин), дає вам захищену основу для висновку.

Розподіл обов'язків як повторна тема

Значна частина висновків аудиту сходить до розподілу обов'язків (SoD): та сама особа, яка запитує зміну, також затверджує її, або розробник має прямий доступ до виробничої бази даних разом з правами розгортання. Аудитори постійно шукають такі перекриття, тому що відмови SoD — це те, як шахрайство та ненавмисні помилки просковзують без другого набору очей, які їх ловлять.

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

Написання висновків, які отримають виправлення

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

Вироблення звички

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

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