Pull to refresh

ИБ по-американски. Часть 1. Что такое NIST 800-53 и как выглядят контроли безопасности?

Reading time 9 min
Views 44K

*Виновен в разглашении конфиденциальной информации! Ваш ТЕЛЕФОН говорит только то, что говорите ВЫ...*

В последний раз я освещал вопрос обеспечения ИБ в США почти год назад в материале, посвящённом разработке Фреймворка управления рисками ИБ. Настало время более подробно рассказать о том, как устроена ИБ в Америке. По крайней мере на бумаге, изданной вполне авторитетной организацией NIST.
Стоит обратить отдельное внимание на то, что дальше речь пойдет о теоретической ИБ, так называемых best practices, которые, как известно большинству специалистов по практической безопасности, в жизни встречаются редко. Однако это не умаляет их значимости при построении реальной системы обеспечения ИБ.

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

Почему Америка?


Ни для кого не секрет, что США впереди планеты всей во многих сферах. Это утверждение в определённой мере относится и к сфере информационной безопасности.
Так исторически сложилось, что взрывной рост и распространение компьютерных технологий произошло именно в США. Так же, как и популяризация персональных компьютеров, создание Интернета и изобретение гнущегося iPhone. В этой стране традиционно пристальное внимание уделяется безопасности как государственных, так и национальных интересов, а также соблюдению прав граждан. С приходом информационных технологий этот интерес перекинулся и на новую область.
Как у пионеров отрасли и страны с хорошо развитыми спецслужбами, у Америки всегда было определённое преимущество в сфере ИТ и, соответственно, ИБ. Так, например, было с алгоритмами шифрования на заре их массового применения в компьютерах (например, длинна ключа алгоритма шифрования DES составляла 56 бит, однако экспортный вариант алгоритма для всего мира имел ключ, ограниченный длинной 40 бит, гарантируя заведомо недостаточную стойкость в интересах АНБ). Это же относится к процессам обеспечения информационной безопасности внутри страны. В США очень серьёзные требования к защите информации и разработано много интересных документов по ИБ.
Конечно можно предположить, что организации сами утруждают себя внедрением средств защиты информации, однако сдаётся мне, что стимуляция, в том числе и законодательная, приходит со стороны спецслужб и регулирующих органов, а также под давлением общественности, стремящейся обезопасить себя и свои персональные данные.
Кстати, интересно обратить внимание на следующий момент: в документах по ИБ, подготовленных американскими специалистами, в формулировках регулярно встречается термин Nation, т.е. нация. Документы пишутся с учётом интересов нации США. Это помимо интересов отдельных лиц, организаций и государства. У нас сразу и не припомню в каком официальном документе можно найти упоминание об интересах народа России. Вот такая небольшая ремарка о менталитете.


*Прежде чем выехать на шоссе информационных технологий — подумай о рисках!*

Специальная публикация под кодом 53.


Далее речь пойдёт об одном из, пожалуй, самых применимых документов в условиях, отличных от законов и реалий США.
NIST — National Institute of Standards and Technology. Серьёзная организация, на счету которой невероятное количество публикаций по самым разным тематикам. Для публикаций по ИБ в NIST выделили специальную серию под номером 800. В этой серии представлено уже множество документов разной направленности. Однако среди всех них я выделил самую интересную и на мой взгляд приближенную к реальности публикацию NIST Special Publication 800-53 “Security and Privacy Controls for Federal Information Systems and Organizations”. Переводя дословно получаем «Контроли безопасности и приватности для федеральных информационных систем и организаций». Этот документ пережил уже три переработки и нынче представлен в 4 версии.
Суть документа заключается в описании контролей безопасности, а также инструкциях о том, как ими грамотно пользоваться. Стоит заметить, что документ очень объёмный и описание контролей занимает почти 250 страниц, а общее их количество насчитывает несколько сотен (учитывая control enhancements, но об этом чуть позже)
В сравнении с тем же ISO 27001 контроли безопасности представляют собой гораздо более детализированные компенсирующие меры, поскольку ISO всё же больше ориентирован на управление ИБ, а не на конкретные компенсирующие меры.


*Надёжное сочетание — это безопасность и вы.*

Краткий обзор контролей


Документ очень хорошо структурирован, в нём имеется масса наглядных примеров, полезных таблиц, упрощающих работу и т.д. Обо всём этом ещё год назад в своём блоге писал Андрей Прозоров, сравнивая документы ФСТЭК и NIST.
Естественно, что все контроли в стандарте разбиты на семьи, отвечающие различным областям обеспечения ИБ. Итак, NIST оперирует следующими семействами контролей (перевод мой собственный, а потому не обессудьте. Сам предпочитаю использовать оригинальные названия во избежание лишней путаницы и кривотолков):
Abbr Control family Адаптированный перевод
AT Awareness and Training Осведомлённость и обучение
AU Audit and Accountability Аудит и отчётность
CA Security Assessment and Authorization Авторизация и оценка безопасности
CM Configuration Management Управление конфигурацией
CP Contingency Planning Планирование непрерывности бизнеса
IA Identification and Authentication Идентификация и аутентификация
IR Incident Response Реагирование на инциденты
MA Maintenance Обслуживание/техническая поддержка
MP Media Protection Защита носителей информации
PE Physical and Environmental Protection Защита от стихийных бедствий и физическая безопасность
PL Planning Планирование
PS Personnel Security Безопасность персонала
RA Risk Assessment Оценка рисков
SA System and Services Acquisition Приобретение систем и сервисов
SC System and Communications Protection Защита систем и коммуникаций
SI System and Information Integrity Целостность систем и информации
PM Program Management Управление программой ИБ



*Не играйте в игры с компьютерной безопасностью!*

Что представляет из себя контроль безопасности


Теперь самое время рассказать о том, что же из себя представляет контроль безопасности. Ниже представлен типичный контроль с описанием среднего размера.
AU-3 CONTENT OF AUDIT RECORDS
Control: The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event.
Supplemental Guidance: Audit record content that may be necessary to satisfy the requirement of this control includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred).
Related controls: AU-2, AU-8, AU-12, SI-11.
Control Enhancements:
(1) CONTENT OF AUDIT RECORDS | ADDITIONAL AUDIT INFORMATION
The information system generates audit records containing the following additional
information: [Assignment: organization-defined additional, more detailed information].

Supplemental Guidance: Detailed information that organizations may consider in audit
records includes, for example, full-text recording of privileged commands or the individual
identities of group account users. Organizations consider limiting the additional audit
information to only that information explicitly needed for specific audit requirements. This
facilitates the use of audit trails and audit logs by not including information that could
potentially be misleading or could make it more difficult to locate information of interest.

(2) CONTENT OF AUDIT RECORDS | CENTRALIZED MANAGEMENT OF PLANNED AUDIT RECORD CONTENT
The information system provides centralized management and configuration of the content
to be captured in audit records generated by [Assignment: organization-defined information
system components].

Supplemental Guidance: This control enhancement requires that the content to be captured
in audit records be configured from a central location (necessitating automation). Organizations
coordinate the selection of required audit content to support the centralized management and
configuration capability provided by the information system.
Related controls: AU-6, AU-7.
References: None.
Priority and Baseline Allocation:
P1 LOW AU-3 MOD AU-3 (1) HIGH AU-3 (1) (2)


Описание контроля соответствует следующему шаблону.
Прежде всего идёт код семейства контроля и номер – AU-3. Далее указано название контроля безопасности: «Содержимое записей аудита».
После этого идут следующие разделы:
  1. Control. Описание особых действий или активностей, относящихся к безопасности, исполняемых в организации или ИС. Для некоторых контролей предусмотрены возможности гибкой настройки, предоставляя возможность организации определять некоторые параметры, связанные с контролем. Например, таким параметром может быть частота проведения аудита, срок хранения логов или количество неудачных попыток авторизации пользователя. Таким образом можно подгонять контроль под конкретные нужды, основываясь на требованиях, предъявляемых к безопасности со стороны бизнес целей организации, результатах оценки рисков и приемлемости рисков, а также требованиях законов и регуляторов.
  2. Supplemental Guidance. Дополнительная информация для конкретного контроля. Может включать пояснительную информацию по реализации или использованию контроля и т.д. Также могут указываться ссылки на другие связанные контроли.
  3. Control Enhancements. В данной секции представлены возможности по «улучшению» контроля, путём добавления к нему дополнительной функциональности или его усилению. Получается своеобразные подконтроли, которые можно использовать только совместно с основным. В данном примере контроль AU-3 (1)(2) фактически состоит из самого контроля AU-3, определяющего необходимость генерирования записей аудита и базовый состав таких записей, «усиления» (1) фиксирующего перечень дополнительной информации о регистрируемых события и «усиления» (2) описывающего организацию централизованного управления содержимым записей аудита. Как видно – эти расширения нельзя внедрить без самого контроля, однако и выделять в отдельные контроли не рационально. Также стоит отметить, что эти расширения также предоставляют организации возможности по гибкой настройке путём определения, например, полного перечня необходимой информации в записях аудита и определении перечня ИС, записи аудита которых должны управляться централизованно.
  4. References. Здесь собраны ссылки на законодательство (естественно американское), стандарты, требования регуляторов, различные руководства и т.д. Для нас это скорее справочная информация.
  5. Priority and Baseline Allocation. В табличке представлена информация о рекомендуемом приоритете при упорядочивании в процессе принятия решений о реализации контролей (в примере выше это P1) а также первоначальное распределение контроля и его «усилений» по базовым наборам для систем различной критичности (о которых чуть дальше). Приоритет внедрения позволяет организации осуществлять реализацию контролей в более эффективной и своевременной последовательности, в первую очередь внедряя основополагающие меры.



*Некоторые профессионалы никогда не раскрывают свои секреты.*

Типы контролей безопасности


Для упорядочивания и обеспечения структурного подхода авторы документа предусмотрели разделение контролей на разные типы, в зависимости от их назначения:
  1. Common. Основные контроли, которые могут наследоваться различными системами и имеют воздействие вне масштабов отдельно взятой ИС. Система наследует контроль безопасности в случае, если он осуществляет свою функцию безопасности в этой ИС, однако был разработан, реализован, оценен, авторизован вне этой ИС.
  2. System-specific. Контроль находится в зоне ответственности владельцев конкретной ИС.
  3. Hybrid. Часть контроля функционирует в качестве общего, а часть в качестве системного контроля. Например, контроль IR-1 может определять политики реагирования на инциденты в масштабах всей организации, однако конкретные процедуры реагирования определяются для отдельных систем.

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

А теперь краткое сравнение NIST 800-53 и ISO 27001


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

Чтобы наглядно сравнить соотношение контролей безопасности из NIST SP 800-53 и ISO/IEC 27001 ниже представлены два фрагмента из таблиц с соответствием этих стандартов. (Таблица взята из документа NIST 800-53 и исключает наличие моих субъективных суждений о соотношении контролей двух стандартов).

Таблица 1. Слева представлены контроли ISO 27001, справа соответствующие им контроли из NIST 800-53


Таблица 2. Обратное соответствие:


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

Вот так выглядит типичный контроль безопасности ISO 27001. В частности этот перекрывает область действия контроля AU-3 «Содержимое записей аудита», приведённого в качестве образца, на котором мы изучали структуру контроля. Сравните это описание с тем, что из себя представляет контроль из NIST, описанный выше.


Что дальше


В следующей статье я попробую в простой форме описать процесс работы с контролями безопасности, представленный в стандарте NIST 800-53.
Надеюсь кому-то это будет полезно или хотя бы интересно.
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+19
Comments 6
Comments Comments 6

Articles