Это краткое изложение исследовательской работы SoK: анализ безопасности цепочки поставок программного обеспечения путем установления свойств безопасного дизайна, опубликованной на ACM:SCORED 2022. Эту работу возглавили Чиненье Окафор и Тейлор Р. Шорлеммер. Полный текст статьи здесь. Тейлор Р. Шорлеммер написал это краткое изложение, которое я слегка отредактировал.

Примечание. «SoK» означает «обобщение/систематизация знаний». Описанная здесь работа представляет собой новую организацию работы многих предшествующих исследователей. Нашей целью было дать согласованные определения и выявить пробелы, которые могут устранить исследователи или практики. Мы, конечно, не первые, кто идентифицирует эти понятия (см. библиографию нашей статьи!), но мы надеемся, что наше представление о них будет полезно для будущей работы.

Краткое содержание

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

Фон

Что такое цепочка поставок программного обеспечения?

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

Мы можем разделить компоненты цепочки поставок программного обеспечения на три категории: действующие лица, операции и артефакты. На рис. 1 показана взаимосвязь между этими компонентами.

  • Актеры управляют цепочкой поставок. Они контролируют операции, артефакты и других участников цепочки поставок. Они также несут ответственность за связи между субъектами в цепочке поставок.
  • Артефакты — это продукты и субпродукты в цепочке поставок. Примеры артефактов включают код, инфраструктуру и зависимости.
  • Операции — это процессы, происходящие в цепочке поставок. Операции могут носить производственный, защитный или издательский характер. То есть операции могут способствовать созданию, защите или распространению артефакта.

Цепочки поставок обязательно содержат связи и зависимости между компонентами и звеньями. Компоненты взаимодействуют друг с другом с целью создания и доставки продукта или подпродукта.
Нисходящие ссылки зависят от продуктов и услуг восходящих ссылок. На макроуровне эти связи и зависимости позволяют цепочкам поставок создавать конечный программный продукт.

Атаки на цепочку поставок программного обеспечения

В последнее время атаки на цепочку поставок стали популярным вектором атаки.
Эти атаки могут иметь разрушительные последствия — например, рассмотрим компрометацию SolarWinds, в которой злоумышленники скомпрометировали множество частных и государственных организаций, скомпрометировав артефакт, на котором организации зависели.

Из-за растущей угрозы атак на цепочку поставок несколько усилий в промышленности, правительстве и научных кругах были сосредоточены на усилении мер безопасности. Эти усилия включают в себя новые фреймворки (см. Cloud Native Computing Foundation (CNCF) Оптимальные методы цепочки поставок программного обеспечения), новые федеральные требования (см. Распоряжение президента 14028) и новые методы безопасности (см. в целом).

Проблема

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

Эта проблема существует по двум основным причинам:

  1. Несоответствия в определении атак на цепочку поставок программного обеспечения; и
  2. Отсутствие принципов для описания безопасной цепочки поставок программного обеспечения.

Наш подход

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

Схема атаки цепочки поставок

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

Наш шаблон атаки (показан на рис. 2) состоит из четырех этапов: компрометация, изменение, распространение и эксплуатация. Вместе эти этапы составляют основные отличительные элементы атаки на цепочку поставок.

  1. Компрометация.Злоумышленник компрометирует существующую уязвимость в цепочке поставок программного обеспечения.
  2. Изменение. Злоумышленник использует компрометацию, чтобы изменить цепочку поставок программного обеспечения.
  3. Распространение: изменение злоумышленника распространяется вниз по течению к другим элементам в цепочке поставок программного обеспечения.
  4. Эксплуатация. Злоумышленник использует изменение в нисходящем элементе цепочки поставок программного обеспечения.

Давайте рассмотрим два гипотетических примера, чтобы проиллюстрировать, что ЯВЛЯЕТСЯ и НЕ ЯВЛЯЕТСЯ атакой на цепочку поставок программного обеспечения в соответствии с этим определением.

  1. Log4J не был атакой на цепочку поставок программного обеспечения. В случае с Log4J инженеры представили функцию, которую можно было использовать. Это свойство делало зависимые от Log4J (например, многие веб-сервисы) уязвимыми. Однако не было атаки на цепочку поставок программного обеспечения, поскольку никто не скомпрометировал Log4J. Вместо этого мы бы определили это как «обычный» эксплойт уязвимости, который использовал элемент Log4J поверхности атаки службы.
  2. SolarWinds была атакой на цепочку поставок программного обеспечения. В этом случае злоумышленники скомпрометировали системы SolarWinds, изменили артефакт, добавив бэкдор, подождали, пока он будет распространен среди нижестоящих пользователей, а затем использовали бэкдор в своем эксплойте. Эта атака следовала четырехэтапной схеме атаки, показанной на рис. 2.

Принципы безопасности цепочки поставок

Инженеры-программисты стремятся создавать безопасные цепочки поставок программного обеспечения — это нетривиально, поскольку цепочки поставок представляют собой сложные системы подсистем.
Кроме того, инженеры должны выбирать, какие методы обеспечения безопасности они могут себе позволить реализовать. У инженеров могут возникнуть проблемы с эффективной защитой своих цепочек поставок или аудитом охвата без стандарта для анализа методов безопасности. По этой причине мы предлагаем три всеобъемлющих принципа безопасности: прозрачность, валидность и разделение.

  1. Прозрачность. Участники должны иметь доступ к знаниям обо всех элементах и ​​связях в цепочке поставок. Такие знания позволяют участникам снижать риск, применяя контрмеры против слабых мест в цепочке поставок.
  2. Действительность. Элементы цепочки поставок должны оставаться правильными.
    Действующие лица, артефакты и операции не должны изменяться неуполномоченными сторонами. Субъекты должны быть аутентифицированы, а целостность должна обеспечиваться для всех артефактов и операций.
  3. Разделение. Связи в цепочке поставок должны быть сведены к минимуму.
    Хотя связи между элементами цепочки поставок важны, разделение ограничивает возможность распространения злонамеренных изменений в системе.

Эти три свойства безопасности обеспечивают базовое понимание того, как должна выглядеть безопасная цепочка поставок. Репрезентативная реализация свойств изображена золотым цветом на рисунке 1 (глаз — прозрачность, замок — достоверность, клапан — разделение).

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

Сопоставление предложений со свойствами безопасности

Несколько методов безопасности уже помогают защитить цепочку поставок программного обеспечения. В нашем документе мы обсуждаем несколько известных методов и проводим четыре тематических исследования для аудита охвата принципов безопасности.
Для этого блога мы предоставляем тематическое исследование Уровни цепочки поставок для программных артефактов (SLSA) и обзор тенденции в современных методах обеспечения безопасности.

SLSA обеспечивает четыре уровня гарантии (т. е. SLSA 1-4) для описания состояния безопасности цепочки поставок, аналогично модели зрелости возможностей (CMM) для разработки программного обеспечения. Фреймворк начинается с базовой безопасности на уровне SLSA 1 и добавляет требования на каждом уровне до последнего уровня, SLSA 4. Каждый уровень документирует источник, сборку, происхождение и общие требования.

  • Прозрачность.SLSA способствует прозрачности, требуя файлов подтверждения происхождения на самом низком уровне соответствия.
    Эти файлы содержат метаданные сборки, которые информируют пользователей об используемых ими артефактах.
  • Действительность.Согласно SLSA 2–4 предъявляются требования к достоверности для разработчиков. На этих уровнях SLSA требует контроля версий, целостности происхождения, возможности аудита и двусторонней проверки всех изменений в артефакте. Такие спецификации гарантируют, что артефакты и операции в цепочке поставок защищены от несанкционированного доступа.
  • Разделение:SLSA 3 требует изолированных сборок в эфемерных средах (выделенные ресурсы для этой конкретной сборки), а SLSA 4 требует герметичного процесса сборки. Эти требования обеспечивают надежную защиту от атак с перекрестным заражением.

Фреймворки помимо SLSA также существуют. Например, Модель целостности цепочки поставок Microsoft (SCIM) (которая недавно устарела в пользу Целостности, прозрачности и доверия цепочки поставок IETF) и Оптимальные методы цепочки поставок программного обеспечения Фонда облачных вычислений (CNCF) установить стандарты безопасности для цепочек поставок программного обеспечения.

Таблица 1 суммирует охват каждой из структур. Мы видим, что SCIM обеспечивает значительно меньшее покрытие, чем SLSA 4 или CNCF. Однако в этой таблице не учитываются относительные затраты на внедрение каждой платформы — мы предполагаем, что существует компромисс между затратами и охватом.

Тенденции в технике

В нашей бумаге мы рассмотрели несколько существующих техник на основе наших принципов безопасности. Таблица 2 показывает охват этих методов. Хотя эта таблица не является всеобъемлющей (и не предназначена для этого), мы заметили акцент на защите артефактов и недостаточное внимание на операциях и субъектах. Хотя в центре внимания исследований в области безопасности, скорее всего, останутся артефакты, мы рекомендуем больше инвестировать в исследования операций и действующих лиц.

Заключение

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