Вопросы на собеседовании: GRC-аналитик

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

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

Управление превращает решения руководства в документированные полномочия, правила и процедуры надзора.

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

Это разные уровни требований, от обязательного намерения до необязательной рекомендации.

• Политика устанавливает обязательное управленческое правило, например требование предоставлять доступ по принципу наименьших привилегий.
• Стандарт задает обязательные измеримые детали, например требование MFA для всех привилегированных учетных записей.
• Процедура перечисляет шаги выполнения задачи, например процесс проверки доступа в Okta.
• Руководство рекомендует полезный подход, но допускает обоснованные альтернативы, например рекомендуемые правила работы с менеджером паролей.

Я размещу измеримое требование в стандарте управления доступом и свяжу его с более общей политикой доступа.

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

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

• Цель может требовать, чтобы доступ к продакшену имели только авторизованные сотрудники.
• Связанной деятельностью может быть ежеквартальная проверка доступа в Okta, утверждаемая владельцем каждого приложения.
• Описание контроля должно связывать деятельность, периодичность, владельца, доказательства и популяцию с целью.

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

• Владелец подтверждает описание контроля, периодичность, системы в области действия и исполнителей или ревьюеров.
• Владелец предоставляет доказательства, например экспорт из Okta и подписанную запись проверки за запрошенный период.
• Если тестирование выявило исключение, владелец согласует исправление, срок и временный контроль.
• GRC-аналитик координирует и тестирует запись, но не становится молча владельцем каждого контроля.

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

• Ежеквартальная проверка отчета о доступах из Okta является ручной, потому что решение принимает руководитель.
• Правило Okta, которое блокирует доступ без MFA, является автоматизированным, поэтому при тестировании проверяют его настройки, историю изменений и журналы.
• В гибридном контроле AWS Config может выявить публичный бакет, после чего аналитик проверит и устранит проблему.
• Автоматизация сокращает повторяющуюся работу, но не делает эффективным контроль с неверной областью действия или настройкой.

Да, но в записи контроля следует разделить виды деятельности и доказательства для каждой функции.

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

Эффективность дизайна показывает, способен ли контроль при выполнении по описанию обоснованно достичь своей цели.

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

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

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

Проверка SOC 2 является независимым подтверждением контролей, относящихся к выбранным критериям доверительных услуг.

• Руководство определяет систему сервисной организации, область проверки, обязательства и контроли.
• Лицензированная аудиторская фирма CPA проводит проверку по стандартам подтверждения AICPA и выпускает отчет.
• Отчет обычно предназначен для ограниченного использования и передается клиентам и другим сторонам, которые понимают сервис.
• SOC 2 не является государственной сертификацией или гарантией отсутствия у сервиса слабых мест.

Type I оценивает дизайн контролей на конкретную дату, а Type II также тестирует операционную эффективность за период.

• Отчет Type I может быть первым этапом готовности, поскольку его заключение привязано к состоянию на определенную дату.
• Отчет Type II охватывает указанный период, часто несколько месяцев, и включает тесты контролей с результатами.
• Доказательства для Type II должны подтверждать регулярную работу, например каждую ежеквартальную проверку в пределах периода.
• Ни один тип не охватывает автоматически системы или критерии, исключенные из области отчета.

Это безопасность, доступность, целостность обработки, конфиденциальность и приватность.

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

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

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

Система менеджмента информационной безопасности представляет собой управляемый набор процессов для работы с риском информационной безопасности в определенной области.

• ISMS включает область, обязанности руководства, оценку и обработку рисков, цели, компетенции, документацию и оценку эффективности.
• Такие записи, как реестр рисков, Statement of Applicability, внутренний аудит и анализ со стороны руководства, показывают работу системы.
• Постоянное улучшение означает, что несоответствия и изменяющиеся риски приводят к корректирующим действиям и обновлениям.
• ISMS шире папки с политиками безопасности или списка технических контролей.

Разделы 4-10 содержат сертифицируемые требования к ISMS, а Annex A предоставляет эталонный набор контролей информационной безопасности.

• Разделы охватывают контекст, лидерство, планирование, поддержку, работу, оценку эффективности и улучшение.
• Обработка рисков определяет, какие контроли Annex A и другие контроли нужны организации.
• Аудитор может зафиксировать несоответствие требованию раздела, даже если отдельный контроль Annex A не нарушен.
• Если считать Annex A всем стандартом, требования к системе менеджмента будут упущены.

Statement of Applicability фиксирует все необходимые контроли из Annex A и других источников, статус их внедрения и основания для выбора.

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

NIST CSF 2.0 группирует результаты кибербезопасности по функциям Govern, Identify, Protect, Detect, Respond и Recover.

• Govern задает контекст организации, стратегию, роли, политику, надзор и направление работы с риском цепочки поставок.
• Identify охватывает активы и риски, а Protect меры защиты, включая учетные записи, защиту данных и обучение.
• Detect отвечает за обнаружение событий, Respond за реагирование, а Recover за восстановление работы и коммуникацию.
• GRC-аналитик сопоставляет существующие контроли и доказательства с результатами, а не считает функции шестью этапами проекта.

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

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

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

• Среда данных держателей карт включает людей, процессы и технологии, которые хранят, обрабатывают или передают данные держателей карт либо чувствительные данные аутентификации.
• Связанные и влияющие на безопасность системы остаются в области, если эффективная сегментация и сокращение области не доказаны.
• Организация, управляющая комплаенсом, подтверждает право на конкретный SAQ или путь ROC, включая возможность провести оценку силами QSA или Internal Security Assessor (ISA).
• Attestation of Compliance фиксирует результат, но не заменяет обязательные доказательства и тестирование.