16 августа 2022

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

Специалисты 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:

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

Источник: Security Media

iTrend: освоить маркировку интернет-рекламы можно только на собственном опыте

25 марта 2024

В феврале 2024 года в Москве прошла Конференция «Digital-коммуникации России». Организатор мероприятия – Ассоциация директоров по коммуникациям и корпоративным медиа России (АКМР). Эксперты конференции обсудили острые вопросы рынка digital, в том числе маркировку интернет-рекламы. Об опыте коммуникационного агентства в рамках перехода на работу по новым правилам рассказала Екатерина Саранцева, директор по развитию iTrend.

 

Медиалогия: iTrend – в ТОП-4 коммуникационных агентств по медиаиндексу за январь 2024 года

20 марта 2024

Коммуникационное агентство iTrend вошло в пятерку агентств, получивших наиболее высокий медиаиндекс по данным рейтинга «Медиалогии» за январь 2024 года. Компания заняла четвёртую строчку ранкинга, набрав 433,2 пункта МИ. Медиаактивность участников рынка оценивалась на основе анализа базы российских СМИ, включающей в себя более 88 тыс. источников — ТВ, радио, газеты, журналы, информационные агентства и Интернет-СМИ.

 

iTrend: интерес деловых СМИ к ИТ вырос в 6 раз за последние пять лет

20 марта 2024

Эксперты коммуникационного агентства iTrend провели исследование, в рамках которого проанализировали, как менялся медиаландшафт в ИТ-индустрии в последние пять лет. В компании сравнили количество упоминаний крупнейших российских разработчиков и системных интеграторов в деловых СМИ и пришли к выводу, что об ИТ-компаниях стали писать в 6 раз чаще.

 

Как строить личный бренд в 2024 году? Запись вебинара iTrend и РБК Компании

12 марта 2024

27 февраля 2024 года коммуникационное агентство iTrend и сервис РБК Компании провели вебинар «Новая искренность 2.0. Почему личный бренд — это тренд 2024?».

 

Проект «Облакотеки» и iTrend номинирован на премию «ЦОДы.РФ» в номинации «Креатив года»

12 марта 2024

Telegram-канал КучевыеАйТи, проект разработчика облачных сервисов «Облакотека» и коммуникационного агентства iTrend, номинирован на национальную премию «ЦОДы.РФ».

 
Все новости iTrend