В сентябре 2022 года Управление управления и бюджета США (OMB) опубликовало приказ. знаковая памятка относительно шагов, необходимых для обеспечения безопасности вашей цепочки поставок программного обеспечения до уровня, приемлемого федеральным правительством США. Любая компания, желающая вести бизнес с правительством и любым федеральным агентством, производящим программное обеспечение, должна соблюдать требования и сроки, изложенные в Памятка М-22-18.
М-22-18 сосредоточился на безопасности и целостности цепочки поставок программного обеспечения, уделив особое внимание роли SBOM. Он включал список требований и график реализации необходимых шагов для обеспечения соответствия.
В меморандуме установлены два основных документа, выпущенных NIST: инфраструктура безопасной разработки программного обеспечения (SSDF), СП 800-218 и Руководство по безопасности цепочки поставок программного обеспечения как руководство NIST по безопасной разработке программного обеспечения. В меморандуме также изложена ответственность производителей программного обеспечения за самоподтверждение соответствия рекомендациям NIST, прежде чем федеральные агентства смогут свободно использовать их продукты. Это самоподтверждение должно иметь форму подписанного самоподтверждения «общей формы». Эта форма самоаттестации требуется для трех категорий программного обеспечения: покупка нового программного обеспечения, обновление основных версий и обновление программного обеспечения.
M-22-18 требовал от CISA установить эту стандартную «общую форму» самоаттестации в течение 120 дней с даты этого меморандума (14 сентября 2022 г.). Эти 120 дней прошли в январе 2023 года, но форма все еще в силе. черновик формы хотя период комментариев по нему завершился 26 июня 2023 года. Примерно именно тогда меморандум OMB первоначально предписывал агентствам начать сбор аттестаций для критически важного программного обеспечения.
На основании некоторых комментариев, полученных к этой общей форме аттестации, OMB сочло целесообразным опубликовать поправку к M-22-18 9 июня 2023 года. Эта поправка называется М-23-16. Новый меморандум продлевает сроки, опубликованные на М-22-18, для агентств по сбору аттестаций от производителей программного обеспечения. Агентства теперь обязаны собирать самоаттестация «общей формы» от производителей программного обеспечения для «критического» программного обеспечения не позднее трех месяцев после утверждения OMB общей формы самоаттестации CISA. У всех остальных производителей программного обеспечения есть шесть месяцев после утверждения формы самоаттестации OMB.
Так как это Стандартная форма самоаттестации, похоже, занимает центральное место, давайте рассмотрим, что в нее входит, немного подробнее. Также мы рассмотрим, кто именно должен его подписать и что будет означать такая подпись.
Общая форма самоаттестации безопасного программного обеспечения
Если проследить цепочку правил от EO 14028 до руководящих документов NIST и меморандумов OMB, становится ясно, что правительство стремится защитить всех, как федеральные агентства, так и компании частного сектора, от уязвимости в цепочке поставок программного обеспечения и вторжения. Поскольку частный сектор недостаточно сделал для этого (по мнению правительства), правительство решило создать новые правила, которым должен следовать каждый (кто продает продукцию федеральному правительству).
Конечно, даже если вы не продаете федеральному правительству (пока), в ваших интересах следовать этим правилам и подтверждать, что вы «в безопасности», поскольку такие компании будут более привлекательным деловым партнером. Кто захочет вести бизнес с компанией, которая не может подтвердить, что делает все возможное для защиты своего продукта и пользователей?
Поскольку мы уже установили, что руководство NIST является основой нового регулирования и передового опыта, неудивительно, что те же предложения, которые появляются, например, в SSDF также появляются в форме самоаттестации.
Вот краткий пример из проекта документа:
Взято из проекта общей формы самоаттестации безопасного программного обеспечения.
Слева мы видим требование, за которым следует соответствующий раздел EO, а затем практики и задачи SSDF. Это довольно обширный список требований (полторы страницы), который не обязательно будет полностью ясен, если читатель не занимается кибербезопасностью и/или DevOps или DevSecOps.
Документ требует, чтобы подписавшая компания ЛИЧНО подтвердила, что все требования, изложенные в форме, последовательно соблюдаются, и что компания уведомит соответствующие агентства, если какой-либо элемент в списке перестанет быть действительным.
В документе не указано, кто в компании должен подписывать документ, но поскольку эта форма является требованием для компании для ведения бизнеса с федеральным правительством и его агентствами, само собой разумеется, что генеральный директор является человеком, который должен брать на себя ответственность. здесь. Генеральный директор, вероятно, не станет подписывать его вслепую и попросит своего технического директора и директора по информационной безопасности подтвердить (возможно, в письменной форме), что компания соблюдает все эти рекомендации и требования.
Поскольку не существует установленного продукта или режима работы, который мог бы собрать и подтвердить все эти требования, в некотором смысле каждой подписавшей контракт компании необходимо «заново изобрести велосипед» для себя и надеяться, что ничего плохого не произойдет.
Если произойдет что-то плохое, федеральное правительство будет преследовать подписавшего, чтобы показать и доказать, что оно может подтвердить все требования форм.
Что произойдет, если я не подпишу?
Во-первых, вся эта аттестация в настоящее время актуальна только в том случае, если ваше программное обеспечение используется федеральным агентством, если вы намерены продать свое программное обеспечение федеральному правительству или если ваше программное обеспечение используется поставщиком, чье программное обеспечение либо используется или предназначен для продажи федеральному правительству.
Обратите внимание, что я сказал «в настоящее время», поскольку есть все признаки того, что соответствие SSDF, либо в виде самоаттестации, либо в какой-либо другой поддающейся проверке форме, станет новой «лучшей практикой» в области производства программного обеспечения.
Итак, если предположить, что ваша компания попадает в упомянутую выше группу и вы не можете с чистой совестью подписать этот документ, то еще не все потеряно. Если вы сможете объяснить, в чем заключается недостаток аттестации, и предложить удовлетворительное План действий и основные этапы (POA&M) соответствующее федеральное агентство по-прежнему может покупать/использовать ваш продукт и добиваться расширения вашего программного обеспечения от вашего имени от OMB.
Плохая новость заключается в том, что с планом POA&M или без него вам в конечном итоге потребуется предоставить полную форму аттестации, что означает, что вам нужно иметь возможность подтвердить федеральному суду, что все шаги, требуемые формой, были выполнены вашей компанией и что ваша компания Процесс разработки программного обеспечения по крайней мере так же безопасен, как и требования формы.
Единственное программное обеспечение, которое в настоящее время освобождено от этой формы аттестации, — это программное обеспечение, разработанное федеральным агентством, и свободно доступное программное обеспечение, также известное как программное обеспечение с открытым исходным кодом. Конечно, большинство безопасность цепочки поставок программного обеспечения дыры в вашем коде каким-то образом можно найти в каком-то пакете с открытым исходным кодом, но есть реальная проблема в попытке заставить разработчиков и сопровождающих открытого кода, которые работают бесплатно, предоставить юридически обязывающую гарантию на свое программное обеспечение. Каждый, кто использует программное обеспечение с открытым исходным кодом, должен самостоятельно проверять его безопасность как в целом, так и в отношении программного обеспечения, в которое оно встроено, в частности.
Худший сценарий
Вся эта забота о безопасности цепочки поставок программного обеспечения началась после знаменитого SolarWinds мотыга. Не вдаваясь в подробности, на момент взлома пострадало более 18,000 9 клиентов компании, включая XNUMX федеральных агентств.
Только сейчас, годы спустя, мы начинаем видеть некоторые юридические последствия этого инцидента. SEC, Комиссия по ценным бумагам и биржам США, преследует компанию в целом, а также после нескольких руководителей высшего звена. Это можно рассматривать как пример намерений правительства на случай, если такой или подобный инцидент случится с производителем программного обеспечения, который подтвердил свои методы безопасной разработки, но все же стал жертвой взлома.
В случае с SolarWinds компания полностью поддерживает любого сотрудника, против которого может быть возбужден такой судебный иск. Зная правовую систему США, такие дела, вероятно, займут годы и будут стоить больших денег. Штрафы не исключаются и могут достигать миллионов, по оценкам нанесенный ущерб.
Вы можете себе представить, что не все компании, особенно малые и средние, так решительно защищают своих сотрудников, как SolarWinds. Проблема в том, что если обвиняемой стороной является генеральный директор компании, существует реальная вероятность того, что доверие рынка к компании и ее продукту серьезно пострадает. Столкновение с SEC без поддержки крупной компании с глубокими карманами может разрушить ничего не подозревающего генерального директора, а также его компанию. Конечно, цель состоит в том, чтобы заставить людей серьезно отнестись к своей ответственности за обеспечение развития, но страх может заставить людей совершить ошибку в сторону самосохранения. Это означает, что люди предпочитают скрывать инциденты в области кибербезопасности, если они думают, что не смогут выиграть потенциальное дело SEC, или опасаются, что стоимость и плохая огласка такого дела будут настолько серьезными, что лучше скрывать их независимо от исхода судебного дела.
Как я могу подписать?
Руководство NIST SSDF полно предложений и передового опыта, но мало практических аспектов. Поскольку каждая компания уникальна, довольно сложно создать продукт или систему, которая бы работала для всех. В этом случае частный сектор вмешивается, чтобы заполнить вакуум, создавая экосистему, которая поможет вам следовать требованиям.
Например, Писец построил платформу основан на концепции создания аттестаций, их подписания и предоставления возможности их проверки. Вскоре мы выпустим документ, специально разработанный для Форма самоаттестации CISA, демонстрируя, как решение Scribe может помочь вам в каждом разделе требований. Следите за обновлениями.
Попробовать Платформа Scribe бесплатна. Я призываю вас попробовать и посмотреть, как вы можете адаптировать платформу к своим требованиям и в то же время с чистой совестью подписать форму самоаттестации CISA.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
