Три проверенных шага к защите вашей программной цепи поставок

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

Хакеры узнают этот факт и используют его. Недавний профильный пример — атака на FireEye, использовавшая множественные троянизированные обновления ПО SolarWinds. Нацеливаясь на провайдеров ПО, хакеры смогли установить бэкдоры в компании, которые, в свою очередь, позволили им достичь своих истинных целей: госорганов, получавших услуги от этих компаний.

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

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

Держите плохих акторов подальше

Программа управления рисками цепи поставок (SCRM) критична для митигации угроз и уязвимостей, неотъемлемых для принятия и интеграции сторонних продуктов и сервисов. Она охватывает людей, процессы и технологии, и простирается по множественным отделам включая безопасность, IT, HR, закупки и юридический. Особенно важно расширить SCRM-программу компании в жизненный цикл разработки ПО (SDLC). В процессе SCRM-программа создает культуру безопасности, где каждый участник и выровнен к одной цели.

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

Компании, использующие стаффинг-фирмы, должны обеспечить, что фирма понимает их уникальные и специфические требования. Например, компании должны знать, кто их стаффинг-фирмы и есть ли у них присутствие в странах с историей государственно-спонсируемой киберпреступности. Когда компании имеют дело с проприетарной и конфиденциальной информацией, они не хотят, чтобы удаленные офисы стаффинг-фирм кормили их резюме и кандидатов, которые потенциально insider threat plants. Нация-государство атакующие все больше фокусируются на вливании своих людей в целевые организации. У них финансовые ресурсы тренировать людей, демонстрирующие востребованные навыки кодирования и другие искомые кредиалы, поднимающие их резюме на вершину кучи. Это то, о чем HR-команды и наймающие менеджеры должны быть осведомлены.

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

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

Пристально изучайте и контролируйте

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

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

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

Создайте культуру безопасности

Это много для рассмотрения, что подчеркивает, почему SCRM должен быть кросс-организационным усилием. Например, юридический отдел должен обеспечить, что вендорские и партнерские контракты содержат язык относительно аудитов для обеспечения следования всем требованиям. Тем временем HR может помочь разработать и закрепить правила для скрининга кандидатов.

C-level buy-in и лидерство ключевы для достижения такого рода командного усилие и обеспечения того, что ресурсы доступны для внедрения SCRM-программы. Это производит культуру безопасности, простирающуюся по всей организации и трансформирующую безопасность из afterthought в фундаментальную часть процесса разработки.

Майкл Ивановф — главный инженер по информационной безопасности в iconectiv.