SOT

Security Orchestration Tools

Напишите нам на sales@securityvision.ru или закажите демонстрацию

Обзор публикации NIST SP 800-161 Rev. 1 (Draft) "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations"

Обзор публикации NIST SP 800-161 Rev. 1 (Draft) "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations"

  |  Слушать на Google Podcasts  |   Слушать на Mave  |   Слушать на Яндекс Музыке  |   


Руслан Рахметов, Security Vision


Ряд резонансных киберинцидентов, произошедших в последнее время (такие как атаки на ИТ-гигантов SolarWinds и Kaseya), поставили мировое сообщество перед фактом: невозможно однозначно доверять даже самым проверенным и изученным информационным системам. Причина заключается в возможности проведения атак на цепочки поставок (англ. "supply chain attacks") путем несанкционированного внедрения атакующими вредоносного кода и/или недекларированных возможностей в программное и/или аппаратное обеспечение, которое поставляется третьим лицом (ИТ-вендором, производителем, сторонними разработчиками).


Не секрет, что современные приложения, информационные системы и высокотехнологичное оборудование настолько сложны и так часто обновляются, что компания-заказчик, как правило, не может самостоятельно проверить отсутствие уязвимостей, вредоносного функционала, бэкдоров (программной или аппаратной закладки) в используемом оборудовании, операционных системах, прикладном ПО и даже в средствах защиты. Вопросы обработки рисков цепочек поставок освещены в документе NIST SP 800-161 Rev. 1 (Draft) "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations" («Практики управления киберрисками цепочки поставок для систем и организаций»), который мы обсудим в данной публикации.


В документе NIST SP 800-161 дается определение цепочки поставок как взаимосвязанному набору ресурсов и процессов между различными уровнями предприятий (включая покупателей, поставщиков, разработчиков, системных интеграторов, сервис-провайдеров), каждый из которых является потребителем продуктов и сервисов с нижележащего уровня с дальнейшим внедрением их в жизненный цикл конечного продукта. Киберриск цепочек поставок определен как потенциальный ущерб или компрометация в результате киберриска со стороны поставщиков, их цепочек поставок и их продуктов или сервисов. Киберриски в цепочках поставок возникают по причине наличия угроз, эксплуатирующих уязвимости и недостатки в продуктах и сервисах в рамках цепочки поставок, а также в самой логике цепочки поставок. В качестве угроз цепочкам поставок могут быть рассмотрены намеренное внедрение вредоносного ПО, создание подделок, промышленный шпионаж, нарушение поставок, перебои в оказании услуг, воздействие спецслужб, а также природные катастрофы, низкокачественные продукты и сервисы, регуляторные и геополитические ограничения (санкции). В качестве уязвимостей цепочек поставок могут быть рассмотрены взаимозависимости в цепочке поставок, ограниченные возможности отдельных элементов цепочки поставок, недостаточные меры кибербезопасности, а также уязвимые системы и компоненты поставщиков, непропатченные системы, недостаточная осведомленность в вопросах обеспечения информационной безопасности.


Например, киберрисками цепочки поставок будут:

  • компрометация репозитория исходного кода проприетарного программного продукта и включение в него бэкдора;

  • выявление уязвимости в распространенном ПО и проведение дальнейших атак на пользователей данного ПО;

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


В документе NIST SP 800-161 признается, что повторное использование программных компонент, включая компоненты с открытым исходным кодом (англ. open source) является экономически эффективным и популярным способом разработки и улучшения ПО, при этом зачастую конечный потребитель не имеет представления о версиях программных модулей, используемых в конечном ПО, которое он использует. Аналогичные киберугрозы актуальны и для внутренней (in-house) разработки ПО, поскольку штатные разработчики могут использовать сторонние библиотеки и модули, которые могут содержать уязвимости. Приведем пример: недавняя опасная уязвимость Log4Shell, обнаруженная в популярной OpenSource-библиотеке логирования операций веб-приложений Apache Log4j, активно эксплуатируется в кибератаках именно по причине её широкого применения в коммерческих платформах по всему миру. Другой пример: при разработке программного продукта для внутренних нужд используется библиотека с открытым исходным кодом, хранящимся в GitHub-репозиторий; данный репозиторий может быть скомпрометирован атакующими (например, путем похищения учетных данных администратора), чтобы в дальнейшем "раздавать" видоизмененный код проекта, содержащий легко эксплуатируемую извне уязвимость, а за этим последуют и атаки на все компании, использовавшие данный GitHub-репозиторий. В результате, NIST SP 800-161 вводит понятие C-SCRM (Cybersecurity Supply Chain Risk Management, управление киберрисками цепочки поставок), обозначающее систематический процесс управления киберрисками цепочки поставок, являющийся частью корпоративной системы управления рисками и включающий в себя практики и меры защиты цепочек поставок для IT и OT-инфраструктур, а также для IoT-устройств. Внедрение процессов C-SCRM может помочь организациям выявить наиболее зависимые от цепочек поставок информационные системы и компоненты ИТ-инфраструктуры, уменьшить вероятность компрометации инфраструктуры за счет эффективного выявления, реагирования и восстановления после инцидентов в цепочках поставок, повысить уверенность в качестве, подлинности, надежности, киберустойчивости и безопасности приобретаемых продуктов, а также в надежности поставщиков и сервис-провайдеров.


Для эффективного и последовательного управления киберрисками цепочки поставок в документе NIST SP 800-161 приводится ряд требований к контрактным обязательствам поставщиков и управлению закупками продуктов/сервисов:

  • Соответствие применимым требованиям кибербезопасности должно быть условием заключения и оплаты контракта;

  • Требования кибербезопасности должны предъявляться также к субподрядчикам и субпоставщикам, с контролем выполнения данных требований;

  • Периодические перепроверки выполнения поставщиками требований кибербезопасности;

  • Установленные процессы и протоколы обмена информацией об уязвимостях, киберинцидентах и иных нарушениях бизнес-процессов, а также критерии категорирования инцидентов;

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

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


При обработке данных о продуктах, сервисах или источниках поставок рекомендуется учитывать следующие их характеристики:

  • Функционал и возможности;

  • Доступ к данным и информации, включая привилегии доступа;

  • Среда установки и функционирования;

  • Безопасность, подлинность и целостность продукта и сервиса и соответствующей цепочки поставки и компиляции;

  • Возможности источника поставок предоставить ожидаемый продукт или сервис требуемого качества;

  • Контроль или влияние на источник поставок со стороны зарубежных законодательных норм или иностранных сущностей;

  • Рыночные альтернативы источнику поставок;

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


Для оценки киберрисков цепочки поставок рекомендуется учитывать следующие риск-индикаторы и результаты анализа:

  • Информацию об киберугрозах, включая индикаторы компрометации, а также тактики, техники и процедуры атакующих;

  • Данные оповещений средств защиты, отчеты с данными киберразведки;

  • Последствия для безопасности инфраструктуры и/или бизнес-процессов, связанных с использованием продукта или сервиса;

  • Уязвимости информационных систем;

  • Уровень угроз и уязвимостей по результатам их оценки;

  • Потенциальное негативное влияние или ущерб, причиненный возможной компрометацией продукта или сервиса бизнес-процессам компании, а также вероятность такого негативного влияния или ущерба, с учетом возможности эксплуатации уязвимостей;

  • Возможности компании по смягчению выявленных киберрисков цепочки поставок.


В документе NIST SP 800-161 приводятся рекомендации по эффективному обеспечению кибербезопасности цепочек поставок, которые разделены на основные (foundational), дополнительные (sustaining) и развивающие (enhancing).


Основные рекомендации включают в себя следующие пункты:

  • Создание выделенного подразделения или группы для управления киберрисками цепочки поставок;

  • Внедрение процессов и иерархии риск-менеджмента в соответствии с рекомендациями NIST SP 800-39 и NIST SP 800-30;

  • Внедрение структуры корпоративного управления для интеграции требований управления киберрисками цепочки поставок в корпоративные политики и процедуры;

  • Разработка процесса определения и оценки критичности корпоративных поставщиков, продуктов и сервисов;

  • Повышение осведомленности ответственных работников в вопросах управления киберрисками цепочки поставок;

  • Разработка и внедрение требований управления киберрисками цепочки поставок в политики и процедуры закупок;

  • Внедрение логически связанного, повторяемого, задокументированного процесса определения уровней негативного воздействия при реализации киберрисков цепочки поставок;

  • Внедрение процессов оценки рисков поставщиков, включая анализ критичности, угроз и уязвимостей;

  • Внедрение программы оценки качества и надежности с методами их контроля и проверки;

  • Выделение достаточных ресурсов функциям информационной безопасности и управления киберрисками цепочки поставок;

  • Обеспечение контролируемого доступа к конфиденциальной информации по управлению киберрисками цепочки поставок;

  • Внедрение применимых защитных мер в соответствии с документом NIST SP 800-53;

  • Внедрение программы реагирования на киберинциденты, включающей возможности по выявлению первопричины киберинцидентов, в том числе произошедших из-за атак на цепочки поставок;

  • Внедрение внутренних процессов для проверки того, что поставщики и сервис-провайдеры активно ищут и оповещают об уязвимостях в своих продуктах;

  • Внедрение корпоративной функции управления и мониторинга каталога компонент программного обеспечения (англ. SBOM, Software Bill Of Materials) для выявления уязвимостей в используемом ПО.


Дополнительные рекомендации включают в себя следующие пункты:

  • Внедрение и взаимодействие в рамках программы обеспечения информационной безопасности с учетом актуальных киберугроз;

  • Использование механизмов построения доверия, включая опросники для оценки третьих лиц, визиты на площадки производителей, формальные сертификации (например, по ISO 27001) для оценки возможностей и практик критичных поставщиков;

  • Внедрение формальных процессов мониторинга и переоценки существующих поставщиков для выявления возможных изменений их риск-профилей;

  • Использование понимания корпоративного риск-профиля для определения аппетита и толерантности к риску для поддержки принятия риск-ориентированных управленческих решений в отношении управления цепочками поставок;

  • Использование согласованного процесса обмена информацией о киберрисках цепочки поставок между компаниями и государственными органами;

  • Эскалация высокоприоритетных киберрисков цепочки поставок на уровень руководства компании (при необходимости);

  • Включение тренингов по вопросам управления киберрисками цепочки поставок в корпоративный процесс внутреннего обучения;

  • Внедрение аспектов управления киберрисками цепочки поставок в жизненный цикл продуктов и систем, а также внедрение соответствующих логически связанных, повторяемых, задокументированных процессов в создание систем, практики обеспечения кибербезопасности, процедуры приобретения ИТ-продуктов и услуг;

  • Внедрение внутрикорпоративных требований по управлению киберрисками цепочки поставок в контрактные требования для поставщиков, разработчиков, системных интеграторов, сервис-провайдеров;

  • Включение критически важных поставщиков в планы и тестирования по реагированию на киберинциденты, обеспечению непрерывности и восстановлению работоспособности;

  • Взаимодействие с поставщиками, разработчиками, системными интеграторами, сервис-провайдерами для повышения их практик обеспечения кибербезопасности;

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


Развивающие рекомендации включают в себя следующие пункты:

  • Автоматизация процессов управления киберрисками цепочки поставок (где применимо и возможно) для повышения логической связности и эффективности, а также высвобождения ресурсов;

  • Применение количественных методов оценки анализа рисков для повышения точности оценки рисков цепочки поставок, повышения возможностей руководства компании для определения оптимальных способов реагирования на киберриски, а также количественного измерения эффективности реагирования на киберриски цепочки поставок;

  • Применение результатов вычисления метрик управления киберрисками цепочки поставок для прогнозирования киберугроз цепочки поставок и перехода от реактивного к проактивному методу реагирования.

Подкасты ИБ NIST Стандарты, ГОСТы и документы ИБ

Похожие статьи

Bug Bounty: как превратить любопытство в заработок
Bug Bounty: как превратить любопытство в заработок
CyBOK. Глава 2. Риск-менеджмент и управление ИБ. Часть 2
CyBOK. Глава 2. Риск-менеджмент и управление ИБ. Часть 2
Как regreSSHion открыл новую главу в старых атаках OpenSSH
Как regreSSHion открыл новую главу в старых атаках OpenSSH
Взлом на заказ: кто и зачем это делает, что чаще всего взламывают
Взлом на заказ: кто и зачем это делает, что чаще всего взламывают
Новые возможности продукта Security Vision Risk Management (RM)
Новые возможности продукта Security Vision Risk Management (RM)
Безопасность использования облачных хранилищ
Безопасность использования облачных хранилищ
Моделирование динамического плейбука. Практика расследования и реагирования, метрики качества
Моделирование динамического плейбука. Практика расследования и реагирования, метрики качества
Разумный комплаенс как способ избежать когнитивных искажений при построении СМИБ
Разумный комплаенс как способ избежать когнитивных искажений при построении СМИБ
IDE для разработки средств защиты в формате no-code
IDE для разработки средств защиты в формате no-code
Взломы в информационной безопасности - что это, как они происходят и как от них защититься
Взломы в информационной безопасности - что это, как они происходят и как от них защититься
XSS, Межсайтовый скриптинг (Cross-Site Scripting)
XSS, Межсайтовый скриптинг (Cross-Site Scripting)

Похожие статьи

Bug Bounty: как превратить любопытство в заработок
Bug Bounty: как превратить любопытство в заработок
CyBOK. Глава 2. Риск-менеджмент и управление ИБ. Часть 2
CyBOK. Глава 2. Риск-менеджмент и управление ИБ. Часть 2
Как regreSSHion открыл новую главу в старых атаках OpenSSH
Как regreSSHion открыл новую главу в старых атаках OpenSSH
Взлом на заказ: кто и зачем это делает, что чаще всего взламывают
Взлом на заказ: кто и зачем это делает, что чаще всего взламывают
Новые возможности продукта Security Vision Risk Management (RM)
Новые возможности продукта Security Vision Risk Management (RM)
Безопасность использования облачных хранилищ
Безопасность использования облачных хранилищ
Моделирование динамического плейбука. Практика расследования и реагирования, метрики качества
Моделирование динамического плейбука. Практика расследования и реагирования, метрики качества
Разумный комплаенс как способ избежать когнитивных искажений при построении СМИБ
Разумный комплаенс как способ избежать когнитивных искажений при построении СМИБ
IDE для разработки средств защиты в формате no-code
IDE для разработки средств защиты в формате no-code
Взломы в информационной безопасности - что это, как они происходят и как от них защититься
Взломы в информационной безопасности - что это, как они происходят и как от них защититься
XSS, Межсайтовый скриптинг (Cross-Site Scripting)
XSS, Межсайтовый скриптинг (Cross-Site Scripting)