Глобальная цепочка поставок программного обеспечения всегда находится под угрозой. угроза со стороны киберпреступников которые угрожают украсть конфиденциальную информацию или интеллектуальную собственность и поставить под угрозу целостность системы. Эти проблемы могут повлиять на коммерческие компании, а также на способность правительства безопасно и надежно предоставлять услуги населению.
Управление управления и бюджета США (OMB) опубликовало в июле 2022 года записку по этому вопросу, который мы рассмотрели. здесь в деталях. В сентябре 2022 года был выпущен новый меморандум, на этот раз посвященный безопасности и целостности цепочки поставок программного обеспечения, подчеркивающий важную роль SBOM. В нем представлен список точных требований и — впервые — указаны фактические сроки внедрения изменений.
В меморандуме содержатся два основных пункта, касающихся Исполнительного указа (EO) 14028 «Улучшение национальной кибербезопасности»:
- Исполнительный директор поручает Национальному институту стандартов и технологий (NIST) поделиться рекомендациями по разработке методов, направленных на повышение безопасности цепочки поставок программного обеспечения. Чтобы помочь в этом, NIST выпустил два документа: Secure Software Development Framework (SSDF), СП 800-218 и Руководство по безопасности цепочки поставок программного обеспечения. Вместе они называются «Руководство NIST» и описывают набор практик, которые составляют основу для создания безопасного программного обеспечения.
- Исполнительный директор также поручает Управлению управления и бюджета начать требовать от агентств соблюдения требований NIST и любых других обновлений.
Самоаттестация является обязательным условием, но все ли это?
Производители программного обеспечения теперь обязаны предоставлять агентствам самоаттестацию, прежде чем они начнут использовать свое программное обеспечение. На самом деле существует три категории, требующие самоаттестации: приобретение нового программного обеспечения, обновление основных версий и обновление программного обеспечения. Цель состоит в том, чтобы снабдить агентства безопасными и отказоустойчивыми программными продуктами, которые защищают их от таких угроз, как SolarWinds опыт, что поставило под угрозу несколько агентств.
Начнем с основ: что такое самоаттестация?
Самоаттестация — это документ, который действует как заявление о соответствии и удостоверяет, что производитель программного обеспечения соблюдает правила, изложенные в рекомендациях NIST. Идея состоит в том, чтобы агентства получали самоаттестацию для каждого стороннего программного продукта или услуги, подпадающего под требования меморандума. Сюда входят обновления программного обеспечения и обновления основных версий.
Еще один важный момент в меморандуме заключается в том, что агентства должны поощрять компании-разработчики программного обеспечения к включению продуктов. Это позволит им предоставлять одинаковую аттестацию всем закупочным агентствам.
Агентство может сохранить документ самоаттестации, если только компания-разработчик программного обеспечения не опубликует его публично и не предложит ссылку на публикацию в своем предложении.
Примечание. В то время как во всех других памятках и руководствах на сегодняшний день утверждается, что самоаттестация достаточно хороша для начала, в данном документе ключевыми целями являются доверие и прозрачность. Основное внимание уделяется цепочке поставок программного обеспечения, а не только кибербезопасности или SSDF (даже если они являются ее частью).
Что произойдет, если компания-разработчик программного обеспечения не сможет предоставить самоаттестацию в стандартном формате?
Производитель программного обеспечения может оказаться не в состоянии подтвердить соблюдение одной или нескольких практик из руководства NIST, указанных в стандартной форме самоаттестации. В этом случае агентство, запрашивающее программное обеспечение, потребует от компании:
- Определите те практики, которые они не могут подтвердить
- Документируйте все методы, используемые для снижения этих рисков.
- Разработайте план действий и основные этапы (POA&M)
Естественно, агентство должно гарантировать, что документация не будет опубликована публично (ни поставщиком, ни самим агентством).
Предположим, поставщик предоставляет всю документацию, и она удовлетворяет агентство. В этом случае последний может использовать программные продукты или услуги, несмотря на отсутствие у производителя полной самоаттестации.
Что должна включать приемлемая самоаттестация?
Документ самоаттестации должен включать следующие минимальные требования:
- Название компании-разработчика программного обеспечения
- Описание программных продуктов, к которым относится заявление (в идеале, этот пункт описывает компанию-разработчика программного обеспечения или уровень линейки продуктов, включая все несекретные продукты, предлагаемые агентствам).
- Заявление, подтверждающее, что поставщик действует в соответствии с практиками и задачами безопасной разработки (перечислено в форме самоаттестации)
Этот тип самоаттестации является минимально необходимым уровнем. Тем не менее, если агентства желают закупить программное обеспечение без него (например, из-за его критичности), они могут провести оценку рисков с помощью сторонней оценки (определенной в М-21-30).
Тем не менее, директива призывает агентства использовать стандартную форму самоаттестации. Совет по регулированию федеральных закупок (FAR) предложит разработать правила использования такой стандартной и единой формы самоаттестации.
Самоаттестация программного обеспечения с открытым исходным кодом
Предположим, агентство желает приобрести программное обеспечение с открытым исходным кодом или программный продукт, включающий компоненты с открытым исходным кодом. В этом случае он может обратиться к сторонней оценке, предоставленной сертифицированной сторонней организацией по оценке FedRAMP (3PAO) или одобренной самим агентством.
Такая оценка приемлема вместо самоаттестации поставщика, если 3PAO использует руководство NIST в качестве основы.
SBOM становятся отраслевым стандартом. Готовы ли вы к этому?
Хотя самоаттестация является минимальным требуемым уровнем, агентствам она может не понадобиться, если продукт или услуга, которые они хотят получить, имеют решающее значение и не могут обеспечить самоаттестацию в стандартной форме.
Важно то, что меморандум поощряет агентства получать артефакты от поставщиков, которые демонстрируют их соответствие практикам безопасной разработки программного обеспечения. Одна из таких практик включает наличие SBOM.
Что такое СБОМ и как он работает?
SBOM — это спецификация программного обеспечения, перечень всех компонентов и зависимостей, которые являются частью разработки и поставки программного продукта.
Агентство может потребовать СБОМ как часть требований к привлечению клиентов, в зависимости от критичности программного обеспечения для агентства.
Меморандум включает следующие рекомендации по закупкам и использованию SBOM агентствами:
- Агентство может сохранить SBOM, если производитель программного обеспечения не опубликует его и не поделится ссылкой на него с агентством.
- SBOM необходимо создавать с использованием одного из форматов данных, определенных в отчет NTIA «Минимальные элементы спецификации программного обеспечения (SBOM)» или новое руководство, опубликованное Агентство кибербезопасности и безопасности инфраструктуры.
- При рассмотрении SBOM агентства должны учитывать взаимность SBOM и других артефактов от производителей программного обеспечения, поддерживаемых другими агентствами. Это основано на прямой применимости и актуальности артефакта.
- При необходимости агентству могут потребоваться артефакты, отличные от SBOM, например, связанные с автоматизированными инструментами и процессами проверки целостности исходного кода или выполнения проверок на наличие уязвимостей.
- Агентство может также потребовать от компании-разработчика программного обеспечения предоставить доказательства того, что они участвуют в Программа раскрытия уязвимостей.
В меморандуме также предлагается, чтобы агентства сообщали поставщикам об этих требованиях как можно раньше в процессе приобретения. Чтобы соответствовать Приказу и рекомендациям NIST, агентствам необходимо соответствующим образом планировать и включать все требования в процесс оценки программного обеспечения. Обратите внимание, что это также должно соответствовать срокам, указанным в памятке (это будет описано в следующем разделе).
Агентства должны указать требования в запросе предложений (RFP) или в других тендерных документах. Идея заключается в том, чтобы агентство обеспечило внедрение и использование поставщиком безопасные методы разработки программного обеспечения в соответствии с рекомендациями NIST на протяжении всего жизненного цикла разработки программного обеспечения.
SBOM, несомненно, является лучшей отраслевой практикой на пути к широкому использованию, особенно для смягчения последствий риски цепочки поставок программного обеспечения.
Чтобы помочь компаниям укрепить доверие к своим программным продуктам, мы недавно запустили простую в использовании платформу, которая помогает создавать SBOM и делиться ими внутри и между организациями. Дайте ему попробовать бесплатно, чтобы увидеть, насколько легко можно создавать, управлять и обмениваться SBOM.
Это уже не просто рекомендация; теперь есть обязательный график, которому нужно следовать
Агентствам необходимо соблюдать требования памятки в соответствии с этим графиком:
- Агентства имеют 90 дней провести инвентаризацию всего своего стороннего программного обеспечения, включая отдельную инвентаризацию «критического программного обеспечения».
- В 120 днейИм необходимо создать «последовательный процесс доведения соответствующих требований, изложенных в этом меморандуме, до поставщиков и обеспечить сбор аттестационных писем, не публикуемых публично поставщиками программного обеспечения, в одной центральной системе агентства».
- У них также есть 270 дней для сбора аттестационных писем, которые не были опубликованы публично для «критического программного обеспечения». В течение года агентства должны были собрать письма на все стороннее программное обеспечение.
- Наконец, в течение 180 дней На момент публикации меморандума (14 сентября 2022 г.) ИТ-директора агентств должны были оценить любые потребности в обучении и разработать планы обучения для проверки и проверки аттестационных документов и артефактов.
Агентства могут запросить продление по крайней мере за 30 дней до любого соответствующего срока, указанного в меморандуме, вместе с планом выполнения невыполненных требований. Также возможно запросить отказ, но только в исключительных обстоятельствах и на ограниченный период времени.
Резюме
OMB предоставит конкретные инструкции по подаче запросов на отказ или продление в течение 90 дней с даты уведомления (до середины декабря 2022 года). Более того, в консультации с CISA и Управлением общих служб он определит требования к «централизованному репозиторию для аттестаций программного обеспечения и артефактов» с правильными механизмами защиты и обмена между агентствами.
Такое центральное место может когда-нибудь стать центральным местом для различных доказательств безопасности и свидетельств, выходящих за рамки формы самоаттестации или SBOM. Размещение всех доказательств в одном общедоступном месте помогает организациям справляться с общими проблемами, такими как появление новых эксплойтов или CVE.
Именно в этом и заключается суть Scribe. Взгляни на эту страницу чтобы узнать больше о нашей комплексной платформе для создания, управления и обмена SBOM внутри и между организациями.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
