*Оставьте свою работу на рабочем месте!*

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

Итак, в этой статье будет наконец-то поведано о выборе набора контролей безопасности, подгонке его под нужды конкретной организации и создании так называемых перекрытий «overlays», применимых вне масштабов отдельной организации.

Ссылки на предыдущие статьи:

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

Выбор базового набора контролей

В предыдущей статье я представил своё видение методики определения критичности ИС, представленное в документе FIPS 199 и выполняемое на первом шаге Фреймворка управления рисками, рассмотренного во второй статье. Что же предстоит сделать дльше?
После определения уровня критичности ИС начинается процесс определения необходимых контролей безопасности. Первым шагом является выбор базового набора контролей, основываясь на результатах категоризации. Выбирается один из трех наборов, соответствующий низкому, среднему и высокому уровню критичности. Безусловно, стоит отметить, что далеко не все контроли входят в эти наборы. Меньше всего их представлено в наборе для низкого уровня, что очевидно. В очередной раз осмелюсь напомнить, что базовые наборы являются лишь отправной точкой дальнейшего процесса по создание подходящего набора контролей. В дальнейшем, в процессе «подгонки», контроли могут быть добавлены, убраны или уточнены для соответствия требованиям безопасности организации.
Также важным является тот факт, что в силу своей универсальности базовые наборы, представленные в документе, имеют определённые допущения, в рамках которых они являются актуальными. Иначе говоря, эти наборы создавались для определённых, вполне конкретных условий применения. Однако не стоит упрекать авторов в узости взглядов, ведь эти условия специально подобраны таким образом, чтобы охватить самый массовый сегмент ИС. Итак, представляю вам эти допущения:

1. ИС расположены на физических объектах (изначально наборы не заточены под виртуализацию);
2. Информация пользователей в ИС организации относительно постоянна (пользователи не создают и не уничтожают информацию в значительных количествах на регулярной основе);
3. ИС функционируют в многопользовательском режиме;
4. Некоторая пользовательская информация в ИС организации недоступна другим пользователям, имеющим авторизованный доступ в те же ИС (ведь разграничение доступа — это базовый принцип, не так ли?);
5. ИС существуют в сетевом окружении;
6. ИС являются по сути системами общего назначения (т.е. не пытаемся защитить иранские центрифуги по обогащению урана);
7. Организация обладает необходимыми структурой, ресурсами и инфраструктурой для реализации контролей.

В случае если некоторые из этих допущений не соответствуют действительности – необходимо производить дополнительную «подгонку» контролей под нужды организации (о чём будет рассказано подробно чуть ниже).

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

1. Существует инсайдерская угроза в организации (как говорится, «против лома нет приёма»);
2. В отношении организации существуют постоянные угрозы со стороны серьёзных нарушителей (речь идёт, например, о банковском секторе);
3. Отдельные типы информации требуют дополнительной защиты в соответствии с требованиями законодательства, регуляторов и т.д. ;
4. ИС должны взаимодействовать с другими системами через среды, отличающиеся уровнем защищённости (например, через публичный сегмент сети).

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


*Санта может отдохнуть… А ты нет! У безопасности не бывает выходных*

«Подгонка» базовых наборов контролей

Напомню, что под «подгонкой» («tailoring») понимается процесс оптимизации, доработки или совершенствования набора контролей таким образом, чтобы он соответствовал требованиям безопасности конкретной ИС или организации. Этот активность обычно осуществляется после выбора базового набора контролей и включает в себя:

1. Выявление и определение характеристик общих контролей безопасности в базовом наборе (здесь имеется ввиду тип: общий/системный/гибридный) ;
2. Анализ возможных сфер применения оставшихся контролей базового набора;
3. Выбор компенсирующих контролей безопасности при необходимости;
4. Установка значений параметров контролей безопасности, уже определённых в организации;
5. Дополнение базового набора дополнительными контролями и «усилениями» контролей при необходимости;
6. Предоставление дополнительной информации по внедрению контролей при необходимости.

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


*Безопасность — необходимая забота в любое время года*

Разработка «перекрытий» («overlays»)

Итак, кратко ознакомившись с процессом «подгонки» базовых наборов контролей, который предоставляет возможность получения более точных и отвечающие реальности мер по обеспечению информационной безопасности, необходимо обратить свой взор на ещё одну очень полезную возможность применения публикации NIST SP 800-53.
В определённых ситуациях для организации может быть выгодно использовать инструмент «подгонки» для получения обобщенного набора контролей, именуемого «перекрытием», применимого в масштабах какой-либо отрасли, или, например, необходимого для соответствия каким-либо специфическим требованиям, технологиям или задачам функционирования (далее будем называть такие «перекрытия» отраслевыми). Разработка такого набора может быть выполнена как самой организацией, так и федеральными органами в рамках какой-либо отрасли. Так, например, правительство может выпустить набор контролей, обязательный к реализации во всех федеральных учреждениях, в которых осуществляется использование инфраструктуры PKI. Таким образом набор контролей безопасности может разрабатываться любым заинтересованным лицом для адекватного реагирования на риски информационной безопасности и затем распространяться среди других участников какой-либо отрасли или пользователей каких-либо технологий, или оборудования. Такая особенность применения методологии «подгонки» предоставляет хороший базис для обеспечения стандартизации возможностей по обеспечению информационной безопасности в различных технологических областях или в конкретных условиях функционирования (здесь находят своё применение универсальность и единообразие подхода, заложенные авторами в самых основах публикации NIST SP 800-53).
Концепция «перекрытий» вводится для обеспечения возможности разработки как отраслевых, так и специализированных наборов компенсирующих мер ИБ для информационных систем и организаций. «Перекрытие» – это полностью определённый набор контролей безопасности, «усилений» и дополнительной информации по их реализации, разработанный в соответствии с правилами проведения процесса «подгонки».
«Перекрытия» дополняют базовые наборы контролей безопасности путём:

1. Предоставления возможности добавления и удаления контролей;
2. Обеспечивая применимость контролей безопасности и их трактовку для специализированных информационных технологий, компьютерных парадигм, типов информации, сред выполнения, технологических отраслей, требований законодательства и регуляторов и так далее.
3. Установки в масштабах отрасли значений параметров контролей безопасности и «усилений»;
4. Расширения дополнительной информации о применении контролей при необходимости.

Обычно организации используют «перекрытия» в случае наличия расхождений с допущениями, в рамках которых созданы базовые наборы контролей безопасности (мы уже говорили об этих допущениях ранее в соответствующем разделе). В случае отсутствия у организации значительных расхождений с допущениями базовых наборов, чаще всего не возникнет необходимости для создания и использования «перекрытия».
«Перекрытия» предоставляют возможность достижения единогласия внутри какой-либо отрасли (иначе говоря, области интереса) и разработать план безопасности для ИС организации, который получит поддержку среди других участников, несмотря на специфичные условия и обстоятельства в конкретной отрасли. Категории перекрытий могут быть полезны для различных областей интереса, например:

1. Индустриальные отрасли, коалиции и корпорации (здравоохранение, энергетика, транспортная отрасль и т.д.);
2. Информационные технологии/компьютерные парадигмы (облачные сервисы, BYOD, PKI, кросс-доменные решения и т.д.);
3. Среда функционирования;
4. Типы ИС и режимов функционирования (промышленные/тестовые системы, однопользовательские системы, системы вооружения, изолированные системы);
5. Типы задач/функционирования (контртеррор, экстренное реагирование, исследования, разработка, тестирование, оценка и т.д.);
6. Требования законодательства и регуляторов (здесь американские требования к нам не применимы).

При разработке «перекрытий» авторы публикации советуют для достижения большей эффективности использовать концепции управления рисками, заложенные в документе NIST SP 800-39. Успешная разработка «перекрытия» требует обязательного участия:

• Профессионалов в области ИБ, которые понимают специфику области, являющейся целью разработки «перекрытия»;
• Экспертов предметной области, для которой осуществляется разработка перекрытия, имеющих понимание сути контролей безопасности, назначения базовых наборов контролей и структуры разработки «перекрытий».

К одному набору контролей может быть применено несколько «перекрытий». «Подогнанный» («tailored») набор контролей, полученный в результате разработки перекрытия может быть как более, так и менее стойким (сильным) по отношению к исходному. Оценка рисков помогает определить является ли риск реализации «подогнанного» набора приемлемым в рамках стратегии принятия рисков, принятой в организации или «области интереса», разрабатывавшей перекрытие. В случае внедрения нескольких «перекрытий» не исключена ситуация, в которой различные перекрытия противоречат друг другу в отдельных моментах. В случае обнаружения такого противоречия, которое может вылиться в конфликт при реализации или даже в отказ от какого-либо конкретного контроля безопасности, спорная ситуация должна решаться с привлечением ответственных лиц, разработчиков перекрытия, владельцев информации и бизнеса.
В общем виде «перекрытия» призваны сократить необходимости проведения «подгонки» наборов контролей на ходу (на скорую руку), путём разработки набора контролей и «усилений», наиболее полно отвечающего конкретным условиям, обстоятельствам и/или ситуации. Таким образом должен достигаться более зрелый и в перспективе единый подход к обеспечению ИБ. В то же время использование «перекрытий» не избавляет от необходимости производить дальнейшую «подгонку» для соответствия нуждам организации, действующим в ней ограничениям и допущениям. «Подгонка» «перекрытия» также допускается и производится с одобрением и согласованием ответственных лиц и разработчиков. Однако в общем случае ожидаемое количество изменений в структуре наборов контролей безопасности, осуществляемых на скорую руку, значительно снижается.


*Игнорируя безопасность вы ходите по тонкому льду*

Документирование процесса выбора контролей

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

Дополнительные заключения

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


*Безопасность требует внимания к деталям*

Новые разработки и унаследованные системы

Процесс выбора контролей безопасности, о котором шла речь в данном статье, может быть применен к информационным системам организации с двумя различными подходами: как к унаследованным системам или как к новым разработкам.
Для разрабатываемых систем процесс выбора контролей безопасности производится с точки зрения «определения требований на этапе проектирования», поскольку система ещё не существует в конченом виде и осуществляется лишь предварительная категоризация ИС. В данном случае контроли, включенные в план по безопасности информационной системы, служат требованиями по безопасности и включаются в систему на этапах разработки и внедрения. В остальном же просто применяется полный цикл RMF.
Для унаследованных систем, напротив, процесс выбора контролей производится с точки зрения gap-анализа, когда организация планирует произвести значительные изменения в информационной системе (например, в ходе обновления или модификации). Поскольку унаследованность обозначает, что ИС уже используется, скорее всего организацией уже производилась категоризация системы и выбор контролей безопасности выльется в корректировку подобранного ранее набора контролей, который уже должен присутствовать в согласованном плане по безопасности для данной системы, и в последующую реализацию этих контролей в ИС. Следовательно, gap-анализ может быть произведен следующим образом:

1. Производится подтверждение или же обновление значения критичности и уровней негативного влияния на ИС, исходя из информации, которая на настоящий момент обрабатывается, хранится или передается системой;
2. Осуществляется анализ существующего плана по безопасности, описывающего реализованные контроли безопасности. Берутся в расчёт любые изменения категорий безопасности, уровней негативного воздействия, а также другие изменения в организации, бизнес-процессах, системах и среде функционирования. Повторная оценка рисков и плана по безопасности обязательны, также, как и документирование любых дополнительных контролей безопасности, которые должны быть реализованы для того, чтобы риски остались на приемлемом для организации уровне.
3. Производится реализация контролей, представленных в обновлённом плане по безопасности, а также документирование плана действий и ключевых моментов не реализованных контролей.
4. Также осуществляются шаги, представленные в цикле Фреймворка управления рисками в той же манере, как это делается для вновь разрабатываемых систем.

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

На этом, пожалуй, можно и закончить обзор публикации NIST SP 800-53. За пределами данного цикла статей осталось ещё много интересного, ведь документ содержит более 450 страниц печатного текста. Однако со всеми подробностями и тонкостями использования данного документа не возможно ознакомится за 4 коротких статьи на Хабре, тем более без опыта реального применения представленных в документе принципов и реализации описанных контролей.
Я надеюсь, что у меня получилось заинтересовать кого-либо публикацией NIST SP 800-53, а тем, кто уже что-то слышал о ней, рассказать чуть подробнее о её устройстве.
И напоследок ещё один плакат:

*Добавьте щепотку безопасности. Это ключевой ингридиент!*

За сим с вами прощаюсь. Если будут вопросы, замечания и предложения — не стесняйтесь использовать комментарии и личку.
Спасибо за внимание!