Собрать единый взгляд на инфраструктуру — от установленного ПО до бухгалтерских проводок — кажется задачей интеграции: есть пять источников данных, нужно свести их вместе. Вопрос в том, даёт ли такую картину сам слой стандартов. Ниже разобрано, что именно описывают NIST SP 800-53 Rev. 5 и ISO/IEC 19770-2:2015, как каждый из них очерчивает свою зону и почему на их основе единая картина не собирается автоматически.
Что покрывает каталог NIST SP 800-53 Rev. 5
Назначение каталога — защита организационных операций и активов, отдельных лиц, других организаций и Нации от разнообразного набора угроз и рисков. Среди явно перечисленных категорий угроз: враждебные атаки, человеческие ошибки, стихийные бедствия, структурные отказы, иностранные разведывательные организации и риски приватности.
Область применения сформулирована как каталог мер безопасности и приватности для информационных систем и организаций, реализуемых в рамках общеорганизационного процесса управления риском. Меры гибкие и настраиваемые: они отвечают требованиям, вытекающим из миссии и бизнес-потребностей, законов, исполнительных указов, директив, регламентов, политик, стандартов и руководств. Конкретные источники требований включают E-Government Actзакон США, регулирующий электронное правительство и связанные с ним вопросы информационных технологий, Executive Order 14306исполнительный указ президента США, Federal Information Security Modernization Actфедеральный закон США о модернизации информационной безопасности, Homeland Security Presidential Directive 12президентская директива США по безопасности, касающаяся удостоверений личности федеральных служащих и подрядчиков, Homeland Security Presidential Directive 7президентская директива США по защите критической инфраструктуры, OMB Circular A-11циркуляр Административно-бюджетного управления США о подготовке, представлении и исполнении бюджета, OMB Circular A-130циркуляр Административно-бюджетного управления США об управлении федеральными информационными ресурсами.
Каталог рассматривает безопасность и приватность с двух сторон. Функциональность — это сила функций и механизмов, обеспечиваемых мерами. assuranceмера уверенности в том, что мера действительно обеспечивает заявленную способность по безопасности или приватности — это мера уверенности в том, что мера действительно обеспечивает заявленную способность по безопасности или приватности. Совместный учёт обоих аспектов помогает гарантировать, что информационные технологии и системы, которые на них полагаются, достаточно заслуживают доверия.
Семейства контролей: что перечислено и что определено
В каталоге перечислены семейства контролейгруппы мер безопасности и приватности, объединённые по общей области защиты: Access Control; Awareness and Training; Audit and Accountability; Assessment, Authorization and Monitoring; Configuration Management; Contingency Planning; Identification and Authentication; Incident Response; Maintenance; Media Protection; Physical and Environmental Protection; Planning; Program Management; Personnel Security; PII Processing and Transparency; Risk Assessment; System and Services Acquisition; System and Communications Protection; System and Information Integrity; Supply Chain Risk Management.
Существенно, что это именно перечень названий. Определения каждого семейства не приведены — есть только их названия в списке Control Families. В частности, области семейств Access Control и Identification and Authentication не сформулированы, поэтому связь этих семейств с процессами управления доступом по приведённым текстам не устанавливается.
Что описывает ISO/IEC 19770-2:2015
Стандарт устанавливает спецификации для маркировки ПО, чтобы оптимизировать его идентификацию и управление. Он определяет две стороны процесса.
Производители тегов — организации и/или инструменты, которые создают SWID-тегструктурированный набор метаданных о программном продукте: его версии, организациях и лицах, участвовавших в производстве и распространении, артефактах продукта и связях между продуктами для использования другими на рынке. Производитель тега может быть частью организации-создателя ПО, организации-лицензиара или сторонней организацией. Они делятся на три категории: поставщики платформотвечают за компьютер или аппаратное устройство и/или связанную ОС, виртуальную среду или платформу приложений, на которой ПО может быть установлено или запущено, и могут дополнительно предоставлять возможности управления тегами на уровне платформы или ОС, поставщики ПОсоздают, лицензируют или распространяют ПО — например, создатели ПО, независимые разработчики, консультанты и упаковщики ранее выпущенного ПО и поставщики инструментов для создания теговинструменты в средах разработки, генерирующие теги; установочные инструменты, создающие теги в процессе установки; инструменты управления рабочими столами, создающие теги для установленного ПО, изначально не имевшего тега. Различие между этими категориями отражает, на каком этапе жизненного цикла ПО создаётся тег: на уровне платформы или ОС, при разработке и лицензировании самого продукта либо инструментом, который генерирует тег в процессе разработки, установки или управления рабочими столами.
Потребители тегов — инструменты и/или организации, которые используют информацию из тегов. Они делятся на две категории: потребители ПО (покупают, устанавливают и/или иным образом потребляют ПО) и поставщики инструментов обнаружения и обработки (собирают, хранят и обрабатывают теги; могут быть нацелены на разные сегменты рынка, включая безопасность ПО, соответствие требованиям и логистику).
Из чего состоит SWID-тег и как он привязывается к продукту
SWID-тег идентифицирует программный продукт, характеризует его версию, указывает организации и лиц, участвовавших в производстве и распространении, перечисляет артефакты продукта, устанавливает связи между продуктами и содержит другие описательные метаданные. Привязка к конкретному продукту обеспечивается именно тем, что эти данные идентифицируют данный программный продукт и его версию, а также перечисляют составляющие его артефакты. NIST рекомендует использовать последнюю версию стандарта — ISO/IEC 19770-2:2015.
Собранная из тегов информация может собираться и обмениваться как данные инвентаризации ПО, поддерживая процессы управления программными активами и безопасности: оценку уязвимостей на инвентаризованном устройстве, обнаружение отсутствующих патчей, нацеливание оценок настроек конфигурации, проверку целостности ПО, белые или чёрные списки установок и запусков.
Где проходит граница: что стандарт прямо исключает
ISO/IEC 19770-2:2015 прямо указывает, что не предписывает процессы управления ИТ-активами (ITAM) или иные ИТ-процессы, необходимые для сверки лицензионных прав с тегами идентификации ПО либо иными ИТ-требованиями. Стандарт также не предназначен для конфликта с политиками, процедурами или стандартами какой-либо организации, а равно с национальными или международными законами и нормативными актами.
Отсюда видно разделение данных. Через обнаружение ПО по метке доступны сведения о продукте и его версии, об организациях и лицах, участвовавших в производстве и распространении, об артефактах и связях между продуктами — то есть техническая и идентификационная сторона актива. Финансовая и договорная сторона (например, условия лицензирования или стоимость) остаётся за рамками спецификации маркировки.
Что из этого следует на практике
Единая картина из пяти источников не собирается автоматически на уровне стандартов, потому что каждый документ очерчивает свою зону и выводит за неё остальное.
ISO/IEC 19770-2:2015 задаёт формат тегов и роли участников — производителей и потребителей тегов, — но прямо не предписывает процессы ITAM и сверки прав на ПО с тегами. NIST SP 800-53 Rev. 5 даёт каталог мер безопасности и приватности для управления рисками, гибкий и настраиваемый, но не задаёт связки между программными, физическими активами и учётными записями. Документ CSRC по SWID Tagging — это публикация NIST о применении SWID-тегов, дополняющая стандарт ISO/IEC 19770-2:2015: она описывает использование тегов для управления программными активами и безопасности, что само по себе не даёт единой картины.
Сопоставление SWID-тега с финансовой и договорной стороной актива спецификацией маркировки не описывается. Упоминаются лишь категории участников — потребители ПО, которые покупают и устанавливают ПО, и производители тегов, среди которых может быть организация-лицензиар. Связки между программными активами, физическими активами и учётными записями приходится строить поверх стандартов: механизмов для этого ни в NIST SP 800-53 Rev. 5, ни в ISO/IEC 19770-2:2015 не описано.
