Каждый руководитель службы безопасности в банке, страховой компании или компании по управлению активами сталкивался с подобной ситуацией: служба безопасности стремится устранить определенный класс уязвимостей. Инженерный отдел объясняет, что потребуется для обновления платформы, на которой они находятся. Кто-то рассчитывает стоимость регрессионного тестирования. Кто-то другой поднимает вопрос о графике заморозки изменений. Для обнаруженной уязвимости предусматривается исключение, компенсационный контроль и дата устранения через восемнадцать месяцев в рамках дорожной карты.
Никто из участников этого разговора не ведет себя неразумно. В сфере финансовых услуг используется больше устаревшего программного обеспечения, чем почти в любой другой отрасли, и на то есть несколько причин: десятилетиями накопленная инфраструктура, нормативные требования, поощряющие стабильность, и приложения, для которых даже час простоя неприемлем. В таких условиях минимизация изменений — это и есть управление рисками. Каждое обновление зависимости, каждая замена базового образа, каждая миграция — это шанс сломать что-то, что обрабатывает сделки или перемещает деньги.
Поэтому стремление сохранить статус-кво было вполне обоснованным. Проблема в том, что сейчас этот инстинкт применяется к не той проблеме.
Наличие накопившихся уязвимостей больше не является «нормальным»
На протяжении многих лет терпение накопившихся известных уязвимостей было обычным компромиссом, на который шли организации финансового сектора ради стабильности. Уязвимости были известны, но не проявлялись. К тому же для их эксплуатации требовались навыки, время, затраты и мотив. Вероятность того, что какая-либо уязвимость из базы Common Vulnerability and Exposure (CVE) в устаревшем приложении будет использована против вас до следующего запланированного обновления, была настолько низкой, что достаточно было просто принять этот факт и двигаться дальше.
Модели типа Frontier радикально изменили эту логику. Такие системы, как Mythos, могут анализировать код, находить неактивные уязвимости и связывать их воедино быстрее, чем люди способны проводить расследования и исправлять уязвимости. Разрыв между «общеизвестными» и «практически эксплуатируемыми» уязвимостями сокращается, и сокращается именно там, где финансовые учреждения до сих пор несли отложенный риск: в цепочке поставок программного обеспечения.
Впервые за всю историю наблюдений эксплуатация уязвимостей обогнала фишинг и стала ведущим вектором первоначального доступа при нарушениях безопасности в сфере финансовых услуг. Кроме того, более половины поставщиков финансовых услуг имеют в своём арсенале как минимум одну уязвимость CVE высокой степени опасности. Для регулируемого учреждения скомпрометированный пакет означает операционное происшествие, переговоры с регулирующими органами и проблему с доверием клиентов.
Что это означает на практике: отставание никогда не было статичным, но допущения, использовавшиеся для его оправдания, оставались неизменными. Исключение, утвержденное 18 месяцев назад, основано на устаревшей модели угроз.
Разница между приложениями и цепочкой поставок программного обеспечения
Когда команда по безопасности говорит: «Нам нужно провести модернизацию», руководители инженерных подразделений понимают под этим модернизацию приложений: рефакторинг монолита, обновление среды выполнения, миграцию уровня данных, повторное тестирование всего последующего кода. Это многолетняя, требующая участия нескольких команд и значительных капиталовложений программа, сопряженная с реальным операционным риском. Руководители инженерных подразделений часто сопротивляются такого рода изменениям — и, вероятно, имеют на то веские основания.
Но риск, который несут передовые модели, заключается не столько в коде приложения. Он кроется в лежащей в его основе цепочке поставок программного обеспечения: базовые образы со множеством уязвимостей, библиотеки с открытым исходным кодом, взятые из общедоступных реестров без указания происхождения, и инструменты сборки, которые никогда не были должным образом инвентаризированы. Входные данные приложения стали уязвимыми.
При этом входные данные можно изменить, не переписывая то, что их использует.
Обновление этих входных данных — это более разумная «модернизация», с которой сейчас считаются многие организации, предоставляющие финансовые услуги. Модернизация цепочки поставок программного обеспечения не требует такого же уровня инвестиций, как модернизация приложений. Вы можете изменить то, на чём вы строите, задолго до того, как измените то, что вы строите.
Как это выглядит без миграции
Подход Chainguard основан на обеспечении безопасности исходных компонентов. Упрочнённые минималистичные образы контейнеров и библиотеки с открытым исходным кодом постоянно пересобираются, чтобы предотвратимые уязвимости изначально не попадали в среду. Меньшее количество компонентов означает меньше объектов для сканирования, меньше задач по сортировке уязвимостей и меньшую поверхность атаки за счёт самой архитектуры, а не за счёт исправлений.
Для программного обеспечения, которое ещё не готово к обновлению, Chainguard обратно портирует исправления безопасности в версии, которые организации используют сегодня. Команда, работающая с более старой версией среды выполнения языка или фреймворка, получает исправленные и проверенные артефакты для этой версии. Совместимость сохраняется, а план миграции реализуется по своему графику.
В любом случае команды, использующие устаревшие версии, снижают свою уязвимость.
Для команд, отвечающих за платформы, операционные изменения оказываются меньше, чем ожидалось. Большинство крупных финансовых учреждений уже используют внутреннюю программу «золотых образов» для стандартизации базовой инфраструктуры, на которой работают сотни команд разработчиков приложений. Обслуживание этих образов — процесс медленный и дорогостоящий.
Но когда команды, отвечающие за платформу, заменяют исходный источник этих образов, они один раз создают зеркальные копии защищенных артефактов и распространяют их в качестве утвержденных строительных блоков через реестры и конвейеры, которые команды уже используют. В результате управление уязвимостями переходит от ситуации, когда каждая команда разработчиков приложений самостоятельно исследует и пересоздает базовые образы, к ситуации, когда одна команда, отвечающая за платформу, поддерживает надежный набор образов. Команды разработчиков приложений получают готовое исправление, а не выполняют эту работу самостоятельно.
Более того, каждый артефакт содержит подписанные списки компонентов программного обеспечения (SBOM) и проверяемую информацию о происхождении, что позволяет командам отвечать на типичные вопросы аудиторов, такие как «Что запущено?», «Откуда это взялось?» или «Как это поддерживается?». Ответы на эти вопросы позволяют командам, отвечающим за платформу и безопасность, вернуться к созданию и поддержке основного бизнеса для своих клиентов.
Скрытые издержки отказа от модернизации
Важно переосмыслить модернизацию с точки зрения цепочки поставок программного обеспечения, поскольку «сохранение статус-кво» никогда не было вариантом с нулевым риском. Это был просто вариант, затраты по которому распределялись достаточно широко, чтобы не попадать в реестр рисков.
Инженерные ресурсы, затрачиваемые на повторяющуюся сортировку уязвимостей CVE вместо работы над дорожной картой, представляют собой реальные затраты. Запуск циклов реагирования на чрезвычайные ситуации каждый раз, когда новая кампания нацелена на широко используемый пакет, отнимает огромное количество времени и ресурсов. Результаты аудита, которые с каждым циклом становится все сложнее устранить, вызывают усталость и замедляют работу вашей организации. А вся работа по модернизации может полностью остановиться, если ваша команда слишком занята исправлением уязвимостей, чтобы реально внедрять новые системы. Все эти задержки означают, что ваша инженерная команда не сосредоточена на том, для чего она существует: на разработке функций, приносящих доход.
На фоне этих затрат внедрение безопасной программной основы представляет собой сравнительно небольшое, обратимое изменение с четко очерченным объемом работ. Оно затрагивает процесс сборки, а не бизнес-логику. Начать можно с одной платформенной команды и нескольких образов. Платформенные команды могут централизованно совершенствовать программную основу и развертывать эти проверенные артефакты через реестры и конвейеры, которые уже используют другие команды.
Самое важное, что нужно понять о модернизации в организациях финансового сектора, — это то, что преимущества в области безопасности проявляются по ходу процесса, а не только тогда, когда работа «завершена». Начиная с цепочки поставок программного обеспечения, вы можете значительно повысить уровень безопасности, при этом продолжая безопасно продвигаться в рамках общей модернизации. Со временем, по мере того как все больше компонентов инфраструктуры будет построено на основе надежных настроек по умолчанию, ваш общий уровень безопасности изменится: вместо постоянного реагирования на уязвимости вы с самого начала будете избегать большинства из них. Именно это на практике означает «безопасность по умолчанию».
Узнайте больше о том, как Chainguard может помочь вам обеспечить безопасность цепочки поставок программного обеспечения вашей организации, предоставляющей финансовые услуги, уже сегодня.
Примечание: эта статья была написана и предоставлена Мэттом Стидом (Matt Stead), менеджером по маркетингу продуктов в Chainguard.