Автоматизированное стандартное решение для соблюдения (COMPASS), Часть 1 Персоны и Роли

Автоматизированное стандартное решение для соблюдения (COMPASS), Часть 1

(Примечание: Список ссылок на все статьи в этой серии можно найти в заключении этой статьи.)

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

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

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

• Обзор DeepBrain AI Лучший генератор искусственного интеллекта? (2023)
• PaaS4GenAI Подключение генеративного искусственного интеллекта (WatsonX) на платформе IBM Cloud из Oracle Integration Cloud
• Каково быть инженером Prompt

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

Значимость непрерывного соответствия требованиям

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

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

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

Персонажи соответствия требованиям

Рисунок 1: Действия персонажей соответствия требованиям в рамках управления, рисков и соответствия требованиям

Как показано на рисунке 1, основными участниками соответствия требованиям, вовлеченными в рамки управления, рисков и соответствия требованиям (GRC), и потоком действий от этих персонажей являются:

1. Регуляторы определяют регуляции, законы и стандарты в виде каталогов с контролями и параметрами. Они также устанавливают предопределенные требования соответствия требованиям в виде базовых или профилей.
2. Архитекторы предприятия, инженеры безопасности и сотрудники по соответствию требованиям отвечают за интерпретацию регуляций, определение, настройку и ассоциирование руководств с выбранными профилями и контролями для своих сред и эталонных архитектур.
3. Поставщики контроля – такие как производители продуктов, поставщики услуг и поддерживающие проекты с открытым исходным кодом – реализуют контроли из каталогов регуляций в своих продуктах (например, оборудование, программное обеспечение, услуги, процессы), следуя интерпретации и руководству архитектора предприятия и сотрудника по соответствию требованиям. Для объявления того, как реализованы контроли, им необходимо преобразовать каждый контроль в технические правила, применяемые к параметрам конфигурации и поведению продукта, чтобы отразить руководство по контролю. Это преобразование выполняется путем установления соответствия между контролем и техническими правилами. Поставщики контроля также могут определять характер связанного с каждым правилом доказательства (например, схема, шаблон, передаваемые данные API).
4. Технические правила должны быть протестированы или применены для проверки или обеспечения настроек и поведения регулируемых сред или эт

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

   Таблица 1: Персоны и их действия в процессах соответствия всем предприятию

   Ключевые артефакты соответствия

   Рисунок 2: Иллюстративные примеры различных артефактов соответствия и их программное представление. Регламенты в формате PDF (вверху) против контролей и правил, выраженных в виде Compliance as Code (в середине) против скриптов проверок в виде Policy as Code для тестирования систем (внизу).

   Рисунок 2 изображает ключевые артефакты соответствия с конкретными примерами и их представление на естественном языке, а также в виде Compliance as Code или Policy as Code. Он иллюстрирует следующие ключевые аспекты артефактов соответствия:

   1. Регламенты и контроли регламентов с государственной стороны выражены в виде широких утверждений на естественном языке (например, «SC-28 Информационная система защищает [конфиденциальность; целостность] [информации в покое]»), тогда как технические правила на технической стороне выражены в виде конкретных утверждений для продуктов и процессов, реализующих контроли (например, “Убедитесь, что Cloud Object Storage зашифрован с помощью KYOK”). В большинстве случаев формулировка технического правила косвенно отражает утверждение контроля, требуя от эксперта по продукту генерировать правила и делая сложным оценку охвата утверждения контроля неквалифицированным специалистом или искусственным интеллектом. В одной из следующих статей мы покажем, как искусственный интеллект (ИИ) может помочь эксперту по соответствию навигировать по утверждениям регламентов с помощью перекрестных ссылок.
   2. Формат представления этих артефактов соответствия эволюционирует от PDF, свободного текста и электронных таблиц к Compliance as Code (например, NIST OSCAL) и Policy as Code (например, OPA – Open Policy Agent) для достижения автоматизации. С одной стороны, хотя нам все еще нужны PDF, свободный текст и электронные таблицы для облегчения создания и использования пользователями каталогов, профилей и правил продуктов поставщиков и описаний параметров, нам нужно перейти к Compliance as Code, чтобы позволить инструментам и сервисам соответствия непрерывно обмениваться, применять и контролировать эти артефакты соответствия в средах. С другой стороны, нам также необходимо перейти от ручной оценки доказательств к Policy as Code – таким как скрипты на Python, JavaScript или OPA Rego – для непрерывного тестирования технических правил продуктов, развернутых в регулируемой среде. В следующей статье мы покажем, как фреймворк NIST OSCAL и его стандартный язык могут быть использованы для представления типичных артефактов GRC в виде кода.
   3. Ключом к достижению автоматизации соответствия и непрерывного соответствия является программное представление соответствия от широких утверждений контроля на естественном языке до конкретных технических правил и связанных с ними параметров и проверок. Многократный процесс создания этого ключевого артефакта, его регистрация в рамках фреймворка GRC и использование для предоставления позиции соответствия будет предметом нашей статьи о протоколе обмена GRC.

   Заключение

   В этой первой статье из многочастевой серии блогов мы рассмотрели основные персоны, ожидаемые в рамках управления управлением, рисками и соответствием (GRC). Как вы без сомнения заметили, мы определили конкретный набор действий, сосредоточенных на теоретическом разделении обязанностей для каждой персоны. Однако в реальной организации одно лицо может занимать несколько ролей – в этом случае она будет выполнять действия, связанные со всеми этими персонами.

   Что будет следующим?

   В нашей следующей статье мы планируем предоставить вам подробное описание артефактов соответствия, обрабатываемых в конечном потоке соответствия – от представления регламентов до позиции соответствия и отчетов аудитора. Мы также предоставим их представление в виде кода с использованием стандарта NIST OSCAL, с готовыми примерами для вашей непрерывной реализации соответствия каталогов, представляющих стандарты (например, NIST 800-53), профили, представляющие базовые уровни, результаты оценки и многое другое, вместе с их взаимосвязями в рамках системы управления управлением, рисками и соответствием (GRC) и отношениями к ролям и действиям персон, представленным в этом блоге.

   Ниже приведены ссылки на другие статьи в этой серии:

   • Автоматизированное стандартное решение для соответствия (COMPASS), Часть 2: Trestle SDK
   • Автоматизированное стандартное решение для соответствия (COMPASS), Часть 3: Артефакты и персоны
   • Автоматизированное стандартное решение для соответствия (COMPASS), Часть 4: Топологии центров администрирования политики соответствия
   • Автоматизированное стандартное решение для соответствия (COMPASS), Часть 5: Отсутствие сетевых границ приглашает отсутствие соответствия
   • Автоматизированное стандартное решение для соответствия (COMPASS), Часть 6: Соответствие политике для нескольких кластеров Kubernetes
   AI,architecture,Artifact (UML),Blog,Persona (user experience),POST (HTTP),Profile (engineering),security,systems,Virtual screening