Awareness FedRAMP

Запросы на отклонения и существенные изменения в FedRAMP: подробное руководство

by Альянс Лазаря 0 комментарий
Оценки авторизации FedRAMP от Lazarus Alliance.

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

Здесь в игру вступают запросы на отклонения и запросы на существенные изменения.

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

 

Понимание структуры FedRAMP

FedRAMP Устанавливает три уровня воздействия (низкий, умеренный и высокий), каждому из которых соответствуют базовые уровни контроля безопасности, основанные на стандарте NIST SP 800-53. Эти меры охватывают всё: от управления доступом и шифрования до реагирования на инциденты и мониторинга системы. Таким образом, они кажутся всеобъемлющими, хотя и не слишком жёсткими.

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

 

Что такое запросы на отклонение?

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

Запросы на отклонение Речь не идёт о снижении стандартов безопасности. Напротив, они признают, что различные технические архитектуры, операционные среды или бизнес-модели могут требовать альтернативных подходов для достижения одних и тех же целей безопасности. Ключевым моментом является демонстрация того, что предлагаемое отклонение обеспечивает адекватное управление рисками и не создаёт неприемлемых уязвимостей.

К распространенным сценариям, которые могут послужить основанием для запроса на отклонение, относятся:

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

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

 

Процесс запроса отклонения

Оценки авторизации FedRAMP от Lazarus Alliance.

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

Ключевые аспекты этого запроса включают в себя:

  • Техническое обоснование: Поставщик услуг безопасности должен объяснить, почему стандартная реализация мер безопасности проблематична или нецелесообразна в данном контексте. Это выходит за рамки простого констатирования сложности… необходимо продемонстрировать фундаментальную несовместимость или несоразмерность последствий. В документации также должно быть подробно описано предлагаемое альтернативное внедрение, с указанием того, как именно будет обеспечиваться безопасность с помощью других средств. 
  • Анализ рисков: Это критически важный компонент любого запроса на отклонение. Поставщик услуг по сертификации (CSP) должен оценить риски, возникающие в случае неисполнения указанного средства контроля, и то, как предлагаемая альтернатива снижает эти риски. Этот анализ должен быть тщательным и честным, признавая любые остаточные риски и демонстрируя, что они остаются в приемлемых пределах. 
  • Участие в процессе утверждения: Запросы на отклонения рассматриваются несколькими заинтересованными сторонами. В отношении авторизации агентства окончательное решение принимает уполномоченное должностное лицо (AO), часто консультируясь с отделом информационной безопасности агентства. В отношении авторизации JAB запрос проходит процедуру технического рассмотрения JAB. Сторонние организации, проводящие оценку, также могут участвовать в оценке.

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

Понимание запросов на существенные изменения

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

Сложность заключается в определении того, что можно считать «значительным» изменением. Изменения, которые явно соответствуют этому пороговому значению, включают:

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

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

 

Процесс запроса на существенное изменение

Когда поставщик услуг связи (CSP) выявляет необходимость в изменении, которое представляется существенным, процесс начинается с документирования. CSP готовит подробный запрос на изменение, описывающий предлагаемое изменение, его цель, бизнес-обоснование и потенциальные последствия для безопасности. Это требует тщательного анализа того, как изменение влияет на средства управления безопасностью системы, потоки данных и общую оценку рисков.

Строгая документация по запросам на изменение охватывает несколько ключевых областей. Она чётко описывает изменения как на техническом, так и на функциональном уровне. Анализирует влияние на безопасность, определяет, какие элементы управления могут быть затронуты и как именно. Предлагает необходимые обновления для документации по безопасности, включая SSP.

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

Этот обзор может включать:

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

Сроки утверждения зависят от сложности изменений и реагирования заинтересованных сторон. 

 

Лучшие практики управления обоими процессами

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

  • Поддерживайте открытое общение. Выстраивайте отношения с вашими уполномоченными по вопросам (AO) до того, как запросы станут срочными. Когда вы заранее предвидите изменения или отклонения, у вас есть время для вдумчивого обсуждения и совместной работы, а не для поспешного принятия решений. 
  • Отдайте приоритет качеству документации. Как запросы на отклонения, так и запросы на существенные изменения требуют чёткой, полной и технически точной документации. Неопределённые или неполные заявки приводят к задержкам, отклонениям и бесконечным вопросам. Уделите время составлению подробной первоначальной документации. 
  • Разработать внутренние процессы идентификации. Создайте механизмы распознавания отклонений или необходимости внесения существенных изменений. Обучите технические команды выявлять потенциальные проблемы на этапах проектирования и внедрения системы. Разработайте чёткие пути эскалации при возникновении вопросов, чтобы ничто не ускользнуло от внимания. 
  • Ведите подробные записи. Ведите подробный учёт всех утверждённых отклонений и существенных изменений для обеспечения постоянного соответствия требованиям. Ссылайтесь на эти утверждения в вашем Плане безопасности системы и других документах авторизации, чтобы будущие оценщики и рецензенты понимали, как в полной мере реализована безопасность вашей системы.

Доверьте Lazarus Alliance помощь в вашем пути FedRAMP

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

Чтобы узнать больше о том, как Lazarus Alliance может помочь, напишите нам. 

Загрузите брошюру нашей компании.

Нет изображения Пусто

Альянс Лазаря

Веб-сайт: