ИБ по-американски. Часть 2. А можно поподробнее о NIST 800-53 и причём тут управление рисками?

  • Tutorial

*Как ни посмотри, безопасность — это и твоя ответственность*

В прошлой своей статье «ИБ по-американски. Часть 1. Что такое NIST 800-53 и как выглядят контроли безопасности?» я рассказал об основе, вокруг которой и строится весь документ NIST SP 800-53, а именно о контролях безопасности. Т.е. тех самых мерах, реализация которых и позволяет снизить риски ИБ. Таким образом я, надеюсь, заинтересовал часть аудитории. Однако полноценный процесс работы с контролями безопасности гораздо шире и включает в себя массу других принципов, помимо самих мер. О том, как это всё должно работать мы сегодня и поговорим.

Ссылки на все части статьи:
ИБ по-американски. Часть 1. Что такое NIST 800-53 и как выглядят контроли безопасности?
ИБ по-американски. Часть 2. А можно поподробнее о NIST 800-53 и причём тут управление рисками?
ИБ по-американски. Часть 3. Что из себя представляет базовый набор контролей и как определять критичность систем?
ИБ по-американски. Часть 4. Разбираемся с «подгонкой» и «перекрытиями» и завершаем этот обзор


О чём же этот NIST SP 800-53 rev4?


Прежде всего я позволю себе сделать краткую ремарку, ещё раз напомнив читателю, что речь пойдет о самой свежей версии документа NIST Special Publication 800-53 Revision 4 (а вот и ссылка для самых интересующихся). Можно сказать, что документ «свежак» — ему всего-то чуть больше года. Тот же ISO 27001 (снова и снова сравниваем с ним, ну а с кем же ещё?) обновлялся до актуальной на настоящий момент версии целых 8 лет и только в прошлом году увидел свет. Но там и процессы более глобальные. Поэтому, наверное, простительно…
Итак, официальное название документа можно перевести как «Контроли безопасности и приватности для федеральных информационных систем и организаций» («Security and Privacy Controls for Federal Information Systems and Organizations»). Отсюда сразу становится понятен вектор дальнейшего повествования: разговор пойдет не о высокоуровневых принципах и концепциях информационной безопасности, но о конкретных, хорошо детализированных мерах обеспечения ИБ, в чём мы и убедились, разобравшись с устройством контроля в предыдущей части. Всё очень подробно и с большим вниманием даже к самым мелочам.
Также стоит немного отвлечься, чтобы пояснить применение слова Privacy. Авторы используют этот термин не только в названии, но и достаточно часто в теле документа при упоминании контролей (а именно, в такой формулировке — «security and privacy controls») – это говорит о том, что приватности (читай защите персональных дынных) уделяется в США самое пристальное внимание, только вот iCloud подкачал… кому-то на радость.... Однако далее я буду опускать это слово повсюду, где оно употребляется совместно с безопасностью, дабы избежать излишней громоздкости текста.


*Что есть мусор для одного, может стать настоящим кладом для другого*

Стандартная рубрика: от автора


Максимально избегая прямого перевода, мне всё же стоит обратить внимание читателя на то, как сами авторы определяют назначение данной публикации. Это поможет немного лучше понять о чём пойдёт речь дальше и возможное позиционирование документа в процессе обеспечения ИБ.
Данный документ представляет собой каталог контролей безопасности и приватности, предназначенных для использования в федеральных информационных системах и организациях, а также включает в себя процедуру выбора контролей, необходимых для обеспечения защиты организации и её функционирования, соответствующих активов и отдельных лиц, а также прочих организаций и Нации от разнообразных угроз, включая изощрённые кибер-атаки, стихийные бедствия, инфраструктурные проблемы и человеческий фактор (как умышленный, так и неумышленный). Контроли являются гибко настраиваемым инструментом процесса управления рисками информационной безопасности и могут быть использованы в масштабах организации. Также данная публикация описывает процесс разработки специализированных наборов контролей безопасности, подогнанных под специфические задачи и функции бизнеса, технологии и рабочее окружение. Помимо этого, необходимо отметить, что каталог контролей безопасности обеспечивает безопасность как с точки зрения функциональности (стойкость и надёжность предлагаемых функций, механизмов безопасности, технологий и т.д.), так и с точки зрения гарантий (уверенность в том, что каждый контроль реализован корректно, функционирует как запланировано и предоставляет ожидаемый результат).


Многоуровневое управление рисками


Поскольку документ не просто претендует на совместимость с другими публикациями NIST по безопасности, но и разработан для применения в рамках «organization-wide approach», т.е. подхода в масштабах организации, то и все процессы рассматриваются соответствующим образом. В том числе и управление рисками, которое является необходимым компонентом для построения полноценной системы управления ИБ в организации. Итак, рассматривая процесс управления рисками, авторы выделяют три уровня, действующих в различном масштабе (схематически изображены на Рисунке 1):
Уровень 1: Организация
Уровень 2: Бизнес процессы
Уровень 3: Информационные системы

Рисунок 1. Схема многоуровневого управления рисками

Подобный подход позволяет обеспечить эффективное всеобъемлющее управление рисками со следующими явными преимуществами:
  1. Прозрачность и простота отслеживания решений, основанных на рисках
  2. Осведомлённость о рисках в масштабах организации
  3. Взаимодействие как внутри, так и между различными уровнями
  4. Цикл обратной связи для обеспечения непрерывного совершенствования

Уровень 1

Предоставляет возможность определения приоритетов бизнес задач и функций организации, которые выливаются в инвестиционную стратегию и решения по бюджетированию, тем самым обеспечивая финансово-выгодные («cost-effective») и эффективные ИТ решения, соответствующие требованиям производительности, а также целям и задачам организации.

Уровень 2

Включает:
  1. Определение бизнес-процессов, необходимых для обеспечения бизнес задач и функций организации;
  2. Определение категорий безопасности выделенных информационных систем, необходимых для исполнения бизнес-процессов;
  3. Включение требований ИБ в бизнес-процессы;
  4. Выбор ИТ архитектуры (включая ИБ) для способствования реализации требований ИБ в информационных системах организации и среде их функционирования.

Уровень 3

Для обработки рисков на уровне информационных систем используется Risk Management Framework (или сокращённо RMF) — набор инструментов по управлению рисками, представленный ниже на Рисунке 2. Этот Фреймворк является одним из основополагающих и связующих звеньев многих публикаций NIST, посвящённых тематике информационной безопасности, ИТ и управления рисками. Более подробно информация о его внедрении представлена в документе NIST SP 800-37. Публикация NIST SP 800-53 (и соответственно весь цикл этих статей) посвящена в частности второму шагу RMF: выбору контролей безопасности.

Risk Management Framework



Рисунок 2. Risk Management Framework

Хотя полноценное описание и руководство по применению Фреймворка управления рисками является отдельным документом (а если быть совсем точным, то это именно вот эта публикация NIST SP 800-37), считаю необходимым предоставить читателю краткий обзор данного инструмента, для улучшения понимания процесса выбора контролей и его месте среди других процессов при управлении рисками. Итак, RMF отвечает на вопросы безопасности, возникающие в организации в процессе проектирования, разработки, реализации, работы и утилизации ИС и среды их функционирования. В качестве входных данных Фреймворк использует данные об имеющейся архитектуре и данные об организации (чуть более подробно это раскрыто в перечнях, представленных на Рисунке 2).
Кратко рассмотрим шаги этого цикла:
  • Шаг 1. Категорирование ИС основываясь на FIPS Publication 199 «оценка угроз»;
  • Шаг 2. Выбор набора исходных контролей безопасности, основываясь на результатах категорирования ИС, и применение руководства по «подгонке» («tailoring») *адаптация*;
  • Шаг 3. Внедрение контролей безопасности, документирование процессов проектирования, разработки и реализации контролей;
  • Шаг 4. Оценка контролей безопасности для определения того, в какой степени контроли корректно внедрены, работают как положено, и предоставляют необходимый результат в смысле достижения требований ИБ, предъявляемых к ИС.
  • Шаг 5. Авторизация эксплуатации ИС, основывающаяся на рисках, возникающих для организации, отдельных лиц и т.д. в результате функционирования и использования ИС, и решении о принятии этих рисков;
  • Шаг 6. Мониторинг контролей безопасности в ИС и среде функционирования на постоянной основе для определения эффективности контролей, необходимости изменений ИС и среды функционирования и соответствия требованиям законодательства.



*Возможно они и сменили работу, но они по прежнему в деле*

И ещё кратко о FIPS 200


Как видно на рисунке, второй шаг Фреймворка ссылается помимо уже известной нам публикации (ради которой мы, собственно, здесь и собрались), на документ FIPS 200 (Federal Information Processing Standards Publication “Minimum security requirements for federal information and information systems”). Этот документ посвящён определению минимальных требований безопасности, предъявляемых к конфиденциальной информации и информационным системам. По сути, документ оперирует мерами безопасности, разбитыми на те же семейства контролей, которые мы рассмотрели в первой части. Однако, так как суть документа в минимальных требованиях, то и меры обеспечения ИБ там фигурируют только самые основные и они описаны простым текстом всего в нескольких предложениях на каждое семейство. Далее же идёт пояснение, что определение категории безопасности необходимо производить в соответствии с документом FIPS 199 (о нём подробнее будет рассказано позже). После чего, на основе полученной категории, необходимо разработать набор контролей безопасности, взяв за основу один из базовых наборов контролей, которые представлены в NIST 800-53. Более подробно этот процесс будет разобран далее. Вот такой получился у FIPS небольшой документ, который, однако, играет большую роль, обязуя всех соответствовать актуальным лучшим практикам, поскольку ссылается на регулярно обновляемый NIST 800-53.

Вместо заключения


В этой статье мы ознакомились с базисом, необходимым для понимания того, как процесс обеспечения информационной безопасности путём реализации контролей коррелирует с другими процессами, протекающими в организации.
В следующих статьях будет рассказано о том, как категоризировать информационные системы, выбирать корректные наборы контролей безопасности и прочие активности, связанные с непростым делом обеспечения ИБ.
  • +4
  • 10,2k
  • 1
Поддержать автора
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 1

    0
    читаю ради постеров))

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

    Самое читаемое