erid 2SDnje4KwUm

Как международные и российские эксперты оценивают безопасность open source

Премия Securitymedia
Как международные и российские эксперты оценивают безопасность open source
Как международные и российские эксперты оценивают безопасность open source
19.07.2022

Специалисты Linux Foundation совместно с другими участниками рынка выпустили исследование по состоянию безопасности в открытом коде (open source software, OSS). Cyber Media обсудило с экспертами по ИБ и разработке ПО, как озвученные риски и угрозы меняются в условиях отечественного ИТ-ландшафта и на какие факторы стоит обратить внимание российским компаниям.

По данным Linux Foundation, OSS составляет от 70 % до 90 % современного стека приложений. Здесь и операционные системы, и облачные контейнеры, средства криптографии и сетевые функции. Сами предприятия в большинстве своём не знают, какие ресурсы они используют в своих ИТ-продуктах, особенно в той части, насколько они уязвимы.

Эта неопределённость уже не раз приводила к последствиям поистине глобального масштаба. Один из недавних примеров – уязвимость Log4Shell, которая затронула миллионы проектов по всему миру. Эксперты Linux Foundation подсчитали, что с прямой зависимостью от кодовой базы log4j-core связано более половины обнаруженных ими уязвимостей.

Среднее количество незакрытых критических уязвимостей в корпоративных приложениях:
  • .Net – 23 уязвимости на проект
  • Go – 34
  • Java – 90
  • JavaScript – 47
  • Python – 36

Чтобы устранить уязвимость, разработчикам в среднем требуется больше трёх месяцев (97,8 дней). Но в проектах с небольшим коммьюнити этот процесс может растянуться на годы – ИТ-общественность просто не будет знать о существующей угрозе. В том числе и потому, что популярный проект с большей вероятностью попадёт в новости профессиональной прессы.

При этом Анастасия Худоярова, ведущий специалист по безопасной разработке Awillix, призывает не ставить знак равенства между открытым кодом и угрозами ИБ:

«Может показаться, что в open source находят больше уязвимостей, чем в enterprise-продуктах. Это связано лишь с тем, что код Open Source доступен всем, а это упрощает анализ и поиск недостатков. В этом есть и свои плюсы – безопасность продукта почти постоянно находится в тонусе».

Российские компании под особой угрозой

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

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

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

Игорь Корчагин, руководитель департамента ИБ Группы компаний «ИВК», дополняет, что возросший спрос российских компаний на свободное ПО спровоцирует появление всё большего количества «закладок» в свободном софте. Недружественные стране структуры могут пытаться не только инициировать, но и контролировать этот процесс.

«Яркий пример – программа Gyrfalkon 2.0», – уточнил эксперт. «Это подробная инструкция ЦРУ, описывающая внедрение “закладок” в операционные системы, созданные на основе крупнейших мировых репозиториев свободного ПО. Инструкция объясняет, как интегрировать “закладки” в программные продукты и организовать скрытый канал утечки данных. С документом можно ознакомиться в интернете».

Обсуждать – не всегда значит делать

Бизнес волей-неволей реагирует на угрозы OSS, но недостаточно активно. Политика безопасности, связанная с разработкой и использованием OSS, есть почти у половины организаций (49 %). Эксперты подчёркивают, что это очень слабый результат, особенно учитывая, что такой документ пока не разработали почти 30 % организаций из крупного сегмента.

«Небольшие организации могут рационализировать повышенный финансовый, репутационный и юридический риск, – рассуждают авторы исследования. – Но для компаний с более чем 5000 сотрудников это просто неприемлемо. Удивительно, но причиной, по которой они не уделяют должного внимания требованиям безопасности OSS, крупные компании чаще всего называют недостаточную информированность о существующих методах ИБ».

  • 59 % организаций считают, что их компоненты с открытым кодом либо очень безопасны, либо безопасны в некоторой степени;
  • 70 % – среди организаций с политикой безопасности OSS;
  • 45 % – среди компаний без такой политики безопасности;
  • 59 % считают, что их процессы разработки в некоторой степени либо очень безопасны, либо безопасны в некоторой степени;
  • 73 % – среди организаций с политикой безопасности OSS; 47 % – среди компаний без такой политики безопасности .

Кто должен определять политику безопасности OSS? Только 31 % компаний указывают на директора по информационной безопасности и/или службу безопасности. На втором месте по популярности (16 %) – мнение, что политика развивается в течение жизненного цикла разработки программного обеспечения (SDLC) в зависимости от направления деятельности команды.

С этими доводами согласилась Анастасия Худоярова (Awillix):

«Компания – это огромная экосистема со множеством разнородных команд. Безопасники должны задавать жесткие требования для работы со внешним миром, чтобы какие-нибудь неаккуратные сотрудники не причинили колоссальный вред всей компании. Есть жесткие рамки, за которые никак нельзя выходить, например, для удаленной работы ты должен использовать VPN. И точка, никаких отступлений. Не работает VPN – нужно починить, обратиться к безопасникам, найти решение».

«Однако, – продолжает эксперт, – компромиссы нужны. Например, на проекте необходимо скачать конкретную библиотеку из конкретного репозитория. Здесь идет обсуждение с безопасниками, и они устанавливают какие-то новые правила, например, фаервола. Тимлиды и техдиректора лучше всех знают, чего требует их приложение и от чего никак нельзя отступить. Этот техдир спускает вниз правила, которых обязаны придерживаться все: правила ведения разработки, требования к коду и т.д.»

От владения информацией к работающим методам

Следующий важный вопрос для компаний – как быстро понять, что в корпоративном продукте есть небезопасные компоненты. Ведущий подход, который практикуют 53 % организаций, – это подписка на каталоги уязвимостей. Участники исследования называли такие источники, как CISA (US-CERT), NIST (NVD), MITRE (CVE), фиды поставщиков продуктов и услуг безопасности.

Второй ведущий подход (49 %) – это автоматизированный мониторинг или сканирование пакетов на наличие известных уязвимостей. Однако, как отмечают авторы исследования, компаниям бывает трудно сопоставить отчеты об уязвимостях с компонентами, содержащими уязвимости.

«Например, в каком-то компоненте foo может обнаружиться уязвимость, – рассуждают они. – Но компонентов и ответвлений с именем foo существует много, поэтому пользователи часто не могут быть уверены, когда отчет актуален. Хотя лучше всего сканировать код по шаблону, основываясь на времени, изменениях в кодовой базе и выявлении соответствующих уязвимостей, комплексный подход к этому методу все еще впереди».

Однако для российских компаний такие потоки данных несут меньшую ценность. Как уточнила Анастасия Худоярова (Awillix), подписка на каталоги уязвимостей не решит всех проблем, т.к. в связи с последними событиями уязвимые компоненты носят «локальный» характер, и их не вносят в базы NVD, MITRE и других организаций.

«Основной ориентир для российских разработчиков – банк данных угроз ФСТЭК России, – отметил Игорь Корчагин (Группа компаний ИВК). – Он предназначен для заказчиков, операторов, разработчиков информационных систем и их систем защиты, разработчиков и производителей средств защиты информации, испытательных лабораторий и органов по сертификации средств защиты информации. В нём собираются сведения об основных угрозах безопасности информации и уязвимостях, которые, в первую очередь, характерны для государственных информационных систем и автоматизированных систем управления производственными и технологическими процессами критически важных объектов».

Александр Буравцов («МойОфис») указывает, что, за исключением БДУ ФСТЭК доступные в России подписки больше направлены на инфраструктурную безопасность. Бизнесу остаётся надеяться на появление российских коммерческих компаний, которые возьмутся за подобные каталоги.

Статические проверки безопасности приложений (SAST) применяют 39 % организаций. Эти инструменты очень полезны во время разработки, поскольку их можно встроить в процесс непрерывной интеграции (CI), а по итогу анализа можно определить конкретные строки кода, в которых скрывается уязвимость. SAST также можно использовать в среде IDE, предоставляя разработчику более оперативный подход к ручному тестированию безопасности. Недостаток автоматизации с лихвой компенсируется непосредственным и своевременным участием разработчиков. Так поступают 30 % организаций.

Многие респонденты (33 %) также используют анализ состава ПО (SCA). Эти инструменты позволяют автоматически выявлять в портфеле компонентов и зависимостей организации уязвимости и проблемы с лицензиями. Наконец, 29 % организаций выявляют уязвимости через экспертную оценку.

Что делать с безопасностью продуктов с открытым кодом

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

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

С другой стороны, 52 % организаций хотели бы владеть передовыми практиками безопасной разработки ПО. Эксперты приветствуют этот тренд – он показывает прямую заинтересованность компаний в безопасности OSS.

При этом Участники исследования рассчитывают, что в ближайшее время безопасность разработки и использования open source улучшится. Сейчас средневзвешенная оценка безопасности по рынку составляет 65 баллов. Респонденты полагают, к концу 2022 года она должна вырасти 72, в к концу 2023 года – достигнуть 77. Александр Азаров (WaveAccess) полагает, что для такого оптимизма есть сразу несколько предпосылок:

«Это повышение осознанности разработчиков за счет активного распространения информации по ИБ и доступности дополнительного обучения. Развивается доступность сервисов вроде Snyk и SonarQube, растёт число таких фондов как, например, Eclipse Foundation и Apache, где часто разрабатываются решения с открытым кодом и получают применение практики ИБ. Дополнительные возможности появляются в платформах хранения исходного кода».

Игорь Корчагин, Группа компаний «ИВК»:

«Отечественные регуляторы и сообщество разработчиков хорошо осознают эти угрозы и принимают превентивные меры, – подчеркнул эксперт. – Государство рассматривает разработку отечественных безопасных операционных систем как одну из ключевых задач национальной информационной безопасности. Для консолидации усилий в этой области организован Технологический центр исследования безопасности ядра Linux. Он работает над повышением качества и безопасности ядра Linux, развитием отечественных средств разработки и тестирования ПО, повышением квалификации специалистов, нормативным и методическим обеспечением процессов безопасной разработки в РФ».

А что делать прямо сейчас?

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

Анастасия Худоярова, Awillix:

«Чтобы обезопасить себя, лучше делать песочницы, в которых можно прогонять уйму всевозможных тестов, анализировать приложение на аномальное поведение. Проблема в том, что это долго и дорого – не все на это пойдут. Еще нужны люди, которые будут за это отвечать. Внедрение практики DevSecOps будет полезно, чтобы повысить качество кода. Будет ясно, какие библиотеки и версии [компонентов] используют разработчики, доверенные они или нет. Это позволяет максимально качественно спроектировать архитектуру, отслеживать потоки данных и лучше выстраивать процессы безопасности».

Небольшие организации, которые не могут изыскать средства на такие инструменты, должны заняться политикой безопасности OSS. Всё строится на процессах: в компании должен быть иметь CISO, нужно расставить приоритеты, в перспективе – организовать подразделение по работе с программами с открытым исходным кодом.

«Сотрудничайте с поставщиками, чтобы создавать более интеллектуальные инструменты безопасности, – призывают авторы исследования. – Расширение “умной” составляющей инструментов безопасности – это один из самых важных способов для повышения безопасности по всей цепочке поставок. Большинство компаний – конечных пользователей ограничены в ИТ-ресурсах, поэтому для них критически важной задачей становится является повышение производительности существующих разработчиков без увеличения их рабочей нагрузки. Расширение автоматизации и рост интеллектуальности инструментов – это примеры того, как это можно сделать».

Автоматизация также помогает уменьшить поверхность атаки. Эксперты рекомендуют применять подход «инфраструктура-как-код» (IaC), чтобы записывать и затем автоматизировать ручные действия. Сокращение или устранение ручных операций CI/CD сокращает возможность обойти политику безопасности, изменить правила, допустить ошибки и создать дополнительные риски.

Какова практика в вашей компании?

Александр Буравцов, директор по информационной безопасности «МойОфис»:

«Мы придерживаемся комплексного подхода: проверяем возможность использования open source компонентов по лицензионным ограничениям, оцениваем их надежность с точки зрения динамики их развития и поддержки, регулярно проводим мониторинг кода на предмет новых угроз, чтобы оперативного устранить потенциальные уязвимости».

Ангелина Разорёнова, старший аналитик «Лиги Цифровой Экономики»:

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

Анастасия Худоярова, ведущий специалист по безопасной разработке Awillix:

«Плюсом будет, если компании имеет свой пакетный менеджер и хранилище артефактов, которое проверяется на возможные уязвимости и угрозы. Такой подход позволяет использовать необходимые компоненты из доверенной среды».

Александр Азаров, генеральный директор WaveAccess:

«Для себя мы определили, что наиболее ощутимый результат дают тренинги и внутреннее обучение сотрудников по различным направлениям, в числе которых и семинары по информационной безопасности. Анализ печальных историй утечек на рынке позволяет закрепить у архитекторов, руководителей разработки и других сотрудников мысль о значимости предиктивного подхода при построении различных систем. Еще один подход – во время онбординга знакомить сотрудников с политикой безопасности и проводить входное тестирование на проверку полученных знаний».


Комментарии 0