 |
|
|
|
Как повысить безопасность Open Source-компонентов?
Как повысить безопасность Open Source-компонентов?
Популярность свободного программного обеспечения постоянно растет. Поэтому задача повышения безопасности ПО с открытым кодом остается едва ли не самой актуальной, когда речь заходит о распространении Open Source во всех экосистемах. Есть ли решение у этой задачи ? Вопросы для экспертов:
Вопрос 1. Основные проблемы безопасности компонентов с открытым исходным кодом? – Сам по себе открытый исходный код не более и не менее безопасен, чем проприетарный, ведь оба они написаны человеком, которому свойственно делать ошибки. Основная проблема в том, отсутствует механизм контроля за использованием Open Source-компонента и большое количество зависимостей. Проекты с открытым исходным кодом используют другие решения внутри себя, содержащие сотни и тысячи известных уязвимостей, которые, в свою очередь, можно эксплуатировать. Наличие исходных кодов в открытом доступе повышает риски атаки злоумышленников на среду функционирования. Это приводит к возникновению риска использования недокументированных возможностей на прикладном или системном уровне, ведь хакер может, например, внести в дистрибутив Open Source вредоносный код. Конечно, не стоит забывать и про нехватку поддержки Open Source (патчи, консультации и т. д.), а также наличие проблем с определением лицензионной чистоты используемого открытого кода.
– При обеспечении безопасности компонентов с открытым исходным кодом можно выделить следующие значимые моменты, требующие внимания: Отсутствие контроля за жизненным циклом разработки компонента, что приводит к невозможности обеспечить выполнение всех требований безопасности. Отсутствие гарантий по срокам устранения уязвимостей, из-за чего системы, использующие компонент, могут длительное время подвергаться рискам. Открытость кода позволяет злоумышленникам использовать статические анализаторы, что значительно упрощает поиск уязвимостей. Система больше не является для них черным ящиком, понимание принципов ее работы значительно повышает риски обнаружения незащищенных мест.
– Крупные Open Source-проекты обладают преимуществом, так как большое количество людей может исследовать код и уязвимости в таких проектах обнаруживаются быстрее. Возможно, проблемы могут возникнуть в небольших проектах или проектах с небольшим сообществом. Тогда даже найденные уязвимости могут устраняться долго либо же не устраняться вовсе. Также к проблемам можно отнести зависимость компонентов с открытым исходным кодом от других Open Source-библиотек. Поэтому разработчики должны регулярно проверять зависимости, а также использовать различные средства автоматизации и оповещения о выпущенных патчах и обновлениях в используемых библиотеках.
– Проблемы у ПО с открытым кодом такие же, как и с закрытым. На практике количество ошибок на единицу объема нового кода есть величина практически постоянная. Открытый код дает злоумышленникам возможность проще находить эти ошибки, тогда как ИТ-специалисты занимаются ровно тем же с целью закрытия уязвимостей. В среднем аспект безопасности можно считать уравновешенным. Еще одной значимой и глобальной проблемой является малая доля специалистов Linux. Отчасти это обусловлено применением продуктов Microsoft в быту, будущий ИТ-специалист использует экосистему западного партнера повсеместно – игры, образование, школьная программа, Интернет.
– Как наглядно продемонстрировала обнаруженная недавно уязвимость Log4Shell, основная проблема безопасности состоит в использовании кода, не прошедшего аудит. Существует огромное количество проектов с открытым исходным кодом. Большие, как правило, находятся под контролем и, возможно, аудитом специальных фондов, например, Linux Foundation. Одновременно с ними на рынке представлены молодые компании, с минимальным контролем, менее координированным аудитом и не совсем прозрачными лицензиями. Наличие подобных лицензий или их отсутствие отталкивают разработчиков от активного участия в разработке и возможном поиске и исправлении уязвимостей, включая проблемы безопасности компонентов. Также в некоторых Open Source-проектах непростая система менеджмента и условия для вовлеченности в решения, что не позволяет участникам сообщества вносить вклад и экспертизу в создаваемый код. Здесь хочется добавить, что при использовании кода, не прошедшего аудит, разработчик несет за него ответственность, том числе, в части безопасности; и должен это делать в соответствии с полным циклом разработки, включая поиск уязвимостей и их устранение. Процессы эти трудоемкие и именно поэтому мы видим ряд инициатив как в России, так и в мире, по совместной проверке скрытых сторонних компонент силами участников рынка. В России это делается под эгидой ИСП РАН, например, создан Технологический центр изучения ядра Linux.
– При чтении открытого исходного кода компонента любому разработчику гораздо проще понять структуру его работы. Одновременно с этим гораздо проще понять какие изъяны безопасности скрыты в коде. Например, запуск статического анализатора на коде компонента может показать ряд узких мест, сделать то же для исполняемого файла сложнее. Сообщество Open Source разрабатывает ПО для решения технически значимых для себя задач. В код свободного ПО включается большой объем функционала, для экономии усилий и ресурсов используется много свободно распространяемых разделяемых библиотек. Безопасность при такой разработке не является приоритетом: ведь чем больше функционала – тем больше кода и потенциальных уязвимостей. Чем больше разделяемых библиотек – тем больше число библиотек, нуждающихся в контроле работы.
– С точки зрения разработки и безопасности, открытый исходный код является одновременно преимуществом и недостатком. С одной стороны, в безопасности открытого исходного кода может убедиться кто угодно: скачать исходники, найти или не найти в них уязвимости и принять решение использовать их или нет. Но в реальности большинство подобной проверкой не занимается. Если говорить не о разработчиках, а о конечных заказчиках, которые принимают решение, то они берут уже скомпилированные продукты, а в их безопасности убедиться сложнее. Сейчас нет качественного механизма, который помогает разобраться, действительно ли это те исходные коды, которые приводятся разработчиком и используются для компиляции конкретного продукта с конкретной цифровой подписью. К примеру, если взять один и тот же исходный код и скомпилировать его сегодня и через день, то не будет двух одинаковых цифровых подписей, а значит, и убедиться в безопасности нельзя. Еще одна проблема безопасности компонентов с открытым исходным кодом в том, что заказчики и злоумышленники находятся в равных условиях. И злоумышленники могут найти уязвимость, которую, к примеру, пропустил заказчик.
– В отличие от проприетарного ПО, развитием и поддержкой Open Source-решений занимаются команды энтузиастов, для большинства из которых эта деятельность не является основной. Как следствие, уровень их защищенности сильно уступает коммерческим продуктам с закрытым кодом, огражденным от вмешательства извне и отвечающим всем современным требованиям безопасности. Безусловно, Open Source-продукты также совершенствуются, но «дыры» в их защите устраняются по факту выявления, нередко – после инцидентов, приведших к утрате или повреждению критически важных данных и приостановки бизнес-процессов. К сожалению, уровень организации и качество этой работы сильно уступает таковым у разработчиков коммерческих продуктов.
– Прежде всего хочется отметить, что свободный доступ к исходному коду дает массу преимуществ, в том числе и с точки зрения безопасности. Но нельзя назвать открытый исходный код абсолютным благом. И ни в коем случае нельзя считать открытый исходный код гарантией безопасности. Вместе с исходным кодом публичной зачастую становится и информация об уязвимостях (они доступны, например, в NVD NIST или ФСТЭК БДУ) и эксплоиты. Это существенно понижает требования к нарушителю и накладывает серьезные требования на разработчиков по скорости обновления компонентов с открытым кодом. Если вы не успеваете сделать это достаточно оперативно, безопасность вашего продукта окажется под угрозой. Большинство компонентов с открытым исходным кодом поставляются под «свободными лицензиями». Хорошо известны формулировки из свободных лицензий, например, «данное программное обеспечение предоставляется «как есть» без каких-либо гарантий». Это касается в том числе и безопасности, и поддержки программного обеспечения. Некоторые компании, разрабатывающие компоненты с открытым кодом, конечно, уделяют внимание безопасности своего кода, поддерживают программы Bug Bounty и выплачивают вознаграждение тем, кто найдет уязвимости в их коде. Но это характерно далеко не для всех компонентов с открытым исходным кодом. Даже если такой анализ проводится, достигаемый при этом уровень безопасности может оказаться недостаточным и не отвечать вашим требованиям. Отсутствие гарантий по поддержке также создает операционные риски для потребителей компонентов: нет гарантий по срокам исправления известных уязвимостей, а развитие и поддержку компонента могут прекратить в любой момент даже без уведомления.
– Мы как предприятие не располагаем ресурсами для аудита безопасности, собственно, это и не наш профиль. Нам очень было бы полезно иметь источник получения доверенного программного обеспечения, тех же версий ядра Linux.
– Основная проблема компонентов с открытым исходным кодом в том, что это компонент с открытым исходным кодом. Вместе со всеми плюсами вы получаете большую неизвестность – вы не знаете, кто писал код приложения и есть ли в нем недекларированные возможности, программные закладки или, например, тайм-бомбы и логические бомбы. Вы не можете контролировать процесс разработки и, как следствие, не можете гарантировать безопасность использования компонентов с открытым исходным кодом.
– Компоненты с открытым исходным кодом имеют те же самые проблемы, что проприетарные решения. Однако если в случае платных продуктов ответственность за безопасность несет поставщик ПО, то в случае Open Source за этим нужно следить самостоятельно и вовремя реагировать на выход патчей и обновлений компонентов. Кроме того, продукты Open Source чаще кастомизируют и порой это приводит к появлению новых брешей в безопасности.
– Проблемы исходят из самой природы Open Source: зачастую разработка «на свой страх и риск» и открытость кода. Первое приводит к слабому качеству продукта (библиотеки, фреймворка), так как принцип снятия ответственности ускоряет выпуск релиза в ущерб времени/ресурсу на тестирование и багфикс. Второе приводит к отсутствию преград к поиску и использованию уязвимостей заинтересованными, включая злоумышленников. А в отсутствие замотивированного стейкхолдера/продакта исправление уязвимостей и повышение качества продукта может длиться месяцами, а может и вообще не выполняться. К тому же возможны случаи умышленного регресса – недавно был громкий случай, когда создатель Open Source-библиотеки выпустил заведомо испорченный релиз с целью нанесения вреда использующим эту библиотеку коммерческим компаниям.
– Основные проблемы безопасности – значительное количество новых компонентов, которые выкладываются в общее пользование на многочисленных платформах, низкий уровень автоматизации безопасности процессов у некоторых небольших разработчиков, многоуровневые разветвленные взаимозависимости между компонентами и значительный поток информации о вновь обнаруженных уязвимостях (небольшим разработчикам его сложно отследить и отреагировать своевременно). Также проблемой является появление новых областей с уязвимостями – контейнерами и программным обеспечением для их оркестрации, подходом «инфраструктура как код» и методами автоматизированного конфигурирования инфраструктуры, платформами «программное обеспечение как сервис» (SaaS) и бессерверными вычислениями. Дополнительно на масштаб проблемы влияет тот факт, что внедрение любого автоматизированного процесса контроля конвейера разработки требует определенных ресурсов со стороны разработчиков, но они предпочитают тратить время на собственно написание кода, чем на безопасность, а нанять в штат специалиста по DevSecOps или приобрести специализированное ПО (например, для анализа исходного кода) не все могут себе позволить. Также разработчики не спешат устранять уязвимости, даже если были своевременно оповещены о них, и в результате у злоумышленников остается достаточно времени на создание и распространение средств для эксплуатации уязвимостей, что повышает ущерб.
– Основные проблемы безопасности компонентов с открытым исходным кодом – это:
– Я бы выделил две основные проблемы безопасности компонентов с открытым исходным кодом: Первая проблема – это зачастую переоценённый уровень качества кода. Это касается не только компонентов с отрытым исходным кодом, но и всех программных компонентов. Принято считать, что если компонент открытый, то это автоматически делает его более безопасным. Это не всегда так. Конечно, в открытом коде во много раз сложнее сделать умышленные уязвимости с учётом доступности для всеобщего аудита. Однако оценка любого изменения в проекте, с точки зрения уровня безопасности, требует специальных компетенций, которыми владеют далеко не все разработчики и мейнтейнеры. Часто внимание уделяется более общим аспектам, таким как архитектура проекта, кодинг стайл. Поэтому я считаю, что вовлечённость комьюнити и качество ревью кода часто переоценена. Есть ключевые компоненты, которых примерно несколько сотен (прим, openssl, libc), в них уделяют качеству кода дополнительное внимание, но бывает, что даже в них находят ошибки, влияющие на безопасность и которые не обнаруживали годами. Вторая проблема – огромное количество кода, использованного в консервативных отраслях цифровой промышленности. Это и ICS-системы, и медицинские системы, любые устройства непотребительского сектора. ПО в этих областях часто очень сложно обновлять до последних версий компонентов, они устаревают, количество известных уязвимостей и ошибок в них возрастает. В связи с невысокой востребованностью устаревших версий со стороны сообщества их поддержка ложится во многом на ограниченное количество заинтересованных производителей. Для них это очень трудоёмко и дорого.
– Существующее мнение о том, что открытость кода сама по себе является гарантией безопасности, неверно. Оно основывается на том, что тысячи глаз читает код и их обладатели готовы заметить и исправить ошибку. Но может оказаться также, что десятки тысяч или сотня, но гораздо более профессиональных и очень мотивированных глаз тоже ищут ошибку и жаждут воспользоваться ею в своих неблагородных целях. А самые изощренные, под видом исправления ошибки, могут внести в код опасную, но неочевидную уязвимость. Разобраться в десятках миллионов строк – сложная, иногда и нерешаемая задача, особенно с учетом того, что продукт продолжает развиваться и код меняется. Поэтому найти намеренно внесенную уязвимость или случайную ошибку гораздо труднее, чем внести ее. Защищенность и работоспособность компонентов с открытым кодом, скорее, зависит от культуры разработки и принятия изменений у разработчиков, использования автоматизации контроля качества и, конечно, наличия мощной системы круглосуточной технической поддержки, напрямую связанной с профессиональными разработчиками.
Александр Белокрылов – Конечно, проблему проверки кода перед его размещением в открытый доступ. Система работы проектов с открытым исходным кодом под координацией, например, автономной некоммерческой организации (АНО) с системой коллегиального принятия решений в вопросах выпуска релизов, позволит уменьшить число уязвимостей, попадающих в релиз, в том числе и в области безопасности. Ситуации, подобные недавней с Log4J, – повод пересмотреть подходы к использованию Open Source в сложных комплексных системах и критических информационных инфраструктурах. Не так давно также была публикация расследования Positive Technologies об уязвимости в сервере приложений с открытым исходным кодом JBoss Application Server. Пример Log4J осложняется тем, что даже если в коде, написанном в организации, ее нет, библиотека может наследоваться. Внедрение цикла безопасной разработки (SDL) в совокупности с технической поддержкой от вендоров, разрабатывающих Open Source, как раз являются требованиями ФСТЭК к подобным решениям.
– Заказчикам нужно перестать верить в то, что продукты на базе Open Source безопаснее решений на базе проприетарного кода. О безопасности продукта говорит только его проверка, и эту задачу нужно решать в первую очередь. Нет никакой разницы между повышением уровня защищенности Open Source-компонентов или проприетарного исходного кода. Всё, что актуально для безопасности закрытого исходного кода, применимо и для Open Source-компонентов. Поэтому необходимо выполнять обязательный набор проверок на безопасность.
– Современные технологии информационной безопасности позволяют решить все проблемы компонентов с открытым исходным кодом, используя инструменты сканирования исходного кода. Эти программные комплексы могут содержать в себе необходимый модуль – Open Source Analysis (он же OSA), который позволяет гарантировать отсутствие в исходном коде недекларированных возможностей, проверяя на наличие заданного пользователем набора уязвимостей.
– Здесь важно отметить, что уровень защищенности открытого ПО сейчас более чем достаточен для применения на серверах и рабочих станциях общего назначения. Периодически появляющиеся в СМИ сообщения о нахождении в открытом коде «ужасных» уязвимостей, которые вот-вот обрушат хрупкий мир информационных технологий, на самом деле говорят только о том, что работа по повышению уровня безопасности открытого кода ведется планомерно и постоянно приносит результаты. Радикальное повышение уровня безопасности открытого кода имеет смысл только в одном случае – там, где к программно-техническим изделиям предъявляются повышенные требования в части безопасности. А это практически всегда означает, что речь идет о сертифицированных программных продуктах. И в этом случае придется решать все перечисленные выше проблемы, потому что решение каждой из них в отдельности не позволит повлиять на ситуацию существенным образом.
– В первую очередь нужно решать проблему низкой мотивации разработчиков, а также руководителей среднего и высшего звена для внедрения безопасности во всей цепочке разработки. Безопасность создаваемого продукта должна быть в высоком приоритете для руководителей компаний-разработчиков, в этом случае всегда можно найти ресурсы и средства для автоматизации контроля.
– Перед компаниями, которые используют в своих продуктах компоненты с открытым исходным кодом глобально, стоит задача убедиться, что в используемых компонентах нет недекларированных возможностей. Такими возможностями могут быть как банальные «зашитые» в код логин и пароль, при знании которых можно получить права администратора, так и уязвимости, например, переполнение внутреннего массива или выход за его границы. В качестве примера компонента с открытым исходным кодом, в котором была найдена недекларированная возможность, которая повлияла, без преувеличения, на весь мир, можно привести OpenSSL с уязвимостью "Heartbleed". При эксплуатации этой уязвимости можно было получить закрытый ключ любого сайта, который впоследствии можно было использовать для расшифрования любой сессии любого пользователя, который работал с данным сайтом по зашифрованному каналу. В ходе разработки компонентов с открытым исходным кодом фокус разработчиков смещен в сторону добавления и реализации нового функционала, а вопросы обеспечения безопасности функционирования, безопасной сборки и безопасного распространения уходят на второй план. Такая фундаментальная проблема обусловлена их спецификой, ведь основной задачей разработчиков является именно разработка функционала для демонстрации того факта, что данная технология работает и как ее воплотить в код. Таким образом, основной проблемой, которую надо решить, является смещение фокуса при разработке в сторону обеспечения всестороннего исследования безопасности данных компонентов, что можно сделать только совместными усилиями всех заинтересованных лиц.
– Прежде всего, на мой взгляд, командам развития Open Source-решений следует обратить внимание на решение проблем контроля доступа, постоянный мониторинг новых уязвимостей и оперативность их устранения. Комплекс этих мер повысит безопасность и надежность таких продуктов.
– В первую очередь стоит обратить внимание на механизмы контроля за использованием Open Source-компонентов, ведь разработчики зачастую забывают о безопасности, когда речь идет о сокращении time-to-market. Это ведет к тому, что сами разработчики оставляют в своих продуктах лазейки для злоумышленников.
– Прежде всего, нужно принять тот факт, что использование компонентов с открытым исходным требует доработки внутренних процессов для включения дополнительных мер обеспечения безопасности: оценка рисков для конкретных компонентов, валидация качества их реализации и регулярный мониторинг на появление уязвимостей. Выбор того, как и в каком порядке реализовывать эти меры, сильно зависит от модели угроз и критичности для бизнеса.
– Самое важное – это обеспечить как можно более быстрое исправление выявленных уязвимостей. Open Source, с одной стороны, позволяет самостоятельно прочитать исходный код и убедиться в отсутствии уязвимостей. Но, с другой стороны, этот же плюс становится огромным минусом, когда этот код читает хакер и находит в нем дыры. Возможность осуществить анализ кода может дать ложное чувство безопасности. Большое число исследователей и пользователей ПО не гарантирует, что все дыры безопасности будут обнаружены и исправлены.
– Упрощение функционала до минимально необходимого – сильно сужает поле для формирования уязвимостей. Работа со сторонними библиотеками будет более безопасной при гарантии отсутствия известных уязвимостей в их коде. Портал проверенных безопасных решений способен уменьшить время поиска и адаптации готовых продуктов. Среда запуска может позволять перекрывать функции компилируемого в машинный код приложения функциями из сторонних библиотек при динамической сборке. Статическая сборка увеличивает объем кода приложения, но лишает его такой уязвимости.
– Конечно, самая приоритетная задача – «тушение пожаров», т. е. оперативное исправление найденных уязвимостей. Но для этого их надо сначала найти, а затем оповестить использующие проекты о наличии и исправлении бага/дыры. Для этого существуют специальные инструменты: SonarQube, Dependency-Track и т. д. Пытаться исправлять остальные проблемы, на мой взгляд, быстро не получится – они противоречат самой природе Open Source. Это культура в команде разработки – ее быстро не поменять.
– В первую очередь, нужно решать проблему именно грамотного применения ПО. К сожалению, всё еще распространен подход – «поставил, настроил, забыл», в результате в Интернете светятся устройства и серверы с давно не обновляемым кодом и незакрытыми известными уязвимостями.
– Для того чтобы обеспечить безопасное использование ПО с открытым кодом, требуется наличие людей, способных исправлять в нем ошибки и отвечающих за это. Нужный уровень квалификации эти люди могут получить, только занимаясь разработкой этого продукта. Поэтому в первую очередь важно развивать разработку свободного ПО и ПО с открытым кодом, создавая собственные проекты и участвуя в деятельности международных сообществ, сформировавшихся вокруг используемых Open Source-решений. Это является задачей национального значения. Сообщества продуктивны, но безответственны. Но из них возникают компании, способные всерьез обеспечивать надежное и безопасное функционирование компонентов Open Source.
– К вопросам безопасности нужно подходить комплексно и решать их в совокупности.
– Вопрос безопасности кода – вопрос комплексный. Часто для обеспечения высокого качества кода у разработчиков не хватает квалификации в этой области. Поэтому, в первую очередь, я бы обратил внимание на профильное образование. Нужно вводить в профильных учебных заведениях дисциплины, посвящённые безопасному программированию, рассказывать про Secure Development Lifecycle, уделять внимание безопасному кодированию на курсах по различным языкам программирования, организовывать тренинги в компаниях. И если начать сегодня, то мы сможем получить результат через несколько лет.
– Если у компонента отсутствует коммерческая поддержка, компании необходимо брать ответственность за гарантии безопасности на себя или делегировать их надежным подрядчикам. Вот некоторые универсальные меры, имеющие смысл в большинстве случаев. Создание политик безопасности с учетом рисков использования компонента:
Метрики можно варьировать в зависимости от критичности компонента для бизнеса. По результатам анализа необходимо составлять белые и черные списки и, что важно, периодически их актуализировать.
– Предложение, с точки зрения обеспечения информационной безопасности, может и должно быть только одно – обеспечение полноценного процесса DevSecOps, в том числе для компонентов с открытым исходным кодом, т. е. использование систем статического и динамического анализа исходного кода с использованием модуля OSA.
– Повысить уровень защищенности (качество кода) большинства Open Source-компонентов не так сложно, как может показаться. Сегодня существует довольно много инструментов для автоматизированного сканирования на недекларированные возможности. Например, средства статического анализа в автоматизированном режиме могут исследовать проект при его сборке и подсвечивать для программиста те места, в которых, возможно, допущена ошибка, что довольно эффективно, если до этого такой вид анализа совсем не производился. Далее можно внедрить несколько различных статических анализаторов, провести сборку проекта, используя санитайзеры, организовать фаззинг тестирование, мутационное тестирование, тестирования с использованием пользовательских данных и т. д. Все эти инструменты не сложны в освоении для программиста, но они отнимают примерно столько же времени, сколько занимает и разработка всего проекта.
– Компаниям-разработчикам сертифицированного ПО нужно участвовать в отечественных сообществах по безопасной разработке. Повышение уровня безопасности программного кода – это, в первую очередь, повышение его качества. Так как основное преимущество открытого программного кода – синергетический эффект от совместной работы, то именно повышение эффективности совместной работы поможет повысить качество открытого кода. Поэтому разработчикам сертифицированного ПО имеет смысл объединять усилия. Для этого и созданы, например, сообщество по безопасной разработке и Центр компетенции по ядру Linux, которые объединяют опыт участия в открытых проектах, разработку сертифицированного ПО, отечественную систему стандартизации и сертификации.
– Как человеку, который обеими руками «за» проприетарное ПО с его всесторонней поддержкой и своевременными обновлениями от разработчиков, мне трудно дать какой-то совет Open Source-командам. Единственное, в чем точно можно быть уверенным, – если вы выбираете такие решения, закладывайте в бюджет средства на совершенствование системы информационной безопасности. Они гарантированно понадобятся.
– Мое мнение – не хватает нормативной базы.
– Первым шагом необходимо разработать политику использования Open Source, включая поиск, оценку и категоризацию Open Source-компонента (в том числе ведение черных и белых списков), внедрить политику загрузки из доверенных источников. Также необходимо отслеживать версии и обеспечивать их исправление и актуальность. Нужно правильно конфигурировать ПО: отключать ненужные сервисы и не забывать менять пароли, заданные по умолчанию. Анализ защищенности должен проводиться перед и/или после каждого обновления. И не забывать периодически проводить аудит ПО.
– Уменьшить объем открытого исходного кода компонента и анализировать его в контексте безопасного исполнения на стадии разработки. Со здать платный реестр проверенных на безопасность библиотек. Минимизировать объем использования сторонних библиотек. Создать портал безопасных программ и сервисов для уменьшения времени их адаптации.
– Поможет повышение внимания к оценке качества создаваемого программного обеспечения на обоих фронтах: и при создании Open Source-компонента, и при его использовании. Для этого есть ряд инструментов и практик. Практики – это, конечно, различные виды тестирования: smoke, ручное, автоматическое, регресс, нагрузочное и проч. Сегодня из-за гонки за сроками часто забываются прописные истины обеспечения качества создаваемого программного обеспечения: тестирование не может занимать менее +/- 30 % трудоемкости разработки. Конечно, это ведет к увеличению команды, сроков, бюджетов. Быстрее провести минимальное неквалифицированное тестирование с помощью аналитиков или вообще разработчиков, однако при этом страдает качество.
– Распространение информации о способах и инструментах для обеспечения безопасности разработки и о важности их систематизированного применения. Улучшение доступности качественных средств и методик для проверки безопасности своего и чужого кода, повышение количества и доступности обучающих материалов и литературы по данному вопросу.
– Не раз доводилось читать и слышать о том, что основная проблема безопасности ПО с открытым кодом – это именно открытость кода. Вроде бы это дает возможность хакерам изучать код и его уязвимости, а потом внедрять вредоносные программы. Выглядит логично, но в реальности дело обстоит ровно наоборот. Чем большее количество человек видит код, работает с ним, тем больше шансов, что найдут и ошибки, и намеренные закладки. Ведь с кодом работают люди разной квалификации, обладающие разнообразным опытом, и компании, выпускающие частное ПО с закрытым кодом, никогда не смогут привлечь такое же количество специалистов к работе. А свежий взгляд порой очень важен. Так что на стороне Open Source работает и популярность тоже. Миф о том, что хакеры используют доступность кода Open Source-продуктов, развенчивают и разнообразные исследования безопасности ПО. ПО с закрытым кодом не только не выигрывает в рейтингах по безопасности с огромным отрывом, но часто даже уступает Open Source ПО. Да, конечно, как и в любом ПО, в программах с открытом кодом тоже есть уязвимости, мир не стоит на месте, но, по последним данным Githab, после выявления разработчики закрывают их в среднем в течение месяца, а пользователи вносят изменения в продукт за неделю. Впечатляющая скорость. Корпорации часто работают медленнее, исправляя бреши в продукте. Есть сообщества, например, тот же Apache Software Foundation, где жестко следят за безопасностью ПО и постоянно проверяют его на уязвимости, поэтому, используя код, сделанный под крылом подобных сообществ, вы существенно снижаете риски. Но главное, что должна иметь любая компания, работающая с Open Source ПО, – экспертизу. Внутренняя предпочтительнее, но можно и привлекать специалистов со стороны. Наличие экспертизы – это один из способов снизить риски работы с кодом. При наличии экспертизы можно воспользоваться главным преимуществом Open Source – кодом: бери и изучай его, оценивай сам перед использованием. Когда у тебя закрытый код, ни о какой безопасности глобально ты говорить не можешь: ты полностью полагаешься на компетентность разработчика, скорость его реакции на обнаружение проблемы, его оценку степени риска, т.е. на выход обновления повлиять невозможно. С открытым кодом ты можешь всё проверить сам и принимать решение самостоятельно, взвешенно, обладая всеми данными, но нужны ресурсы и время. Еще одним инструментом решения проблемы безопасности открытого ПО, помимо экспертизы, являются программы проверки и анализа кода, которые ищут распространенные ошибки в коде, а иногда и выявленные уязвимости. И, конечно, открытый код дает возможность его самостоятельной доработки в том месте, которое внушает опасение. А это дает уверенность в решении проблемы и качестве продукта.
– Конкретную меру можно предложить для проблемы зависимости компонентов с открытым исходным кодом от других Open Source-библиотек. Решить ее может помочь использование Спецификации программного обеспечения (Software Bills of Materials). В Спецификации программного обеспечения перечислено, какие компоненты использованы при создании продукта. Она позволяет разработчику убедиться, что эти компоненты обновлены, и быстро реагировать на новые уязвимости.
– Есть несколько рекомендаций для повышения защищенности Open Source-компонентов:
– Государство в последнее время обратило существенное внимание на Open Source, так как его использование дает определенные преимущества. Но тут фактор безопасности является очень важным, и требуются специальные подходы, связанные с открытостью и общедоступностью кода. Должны быть сформулированы правила, касающиеся ответственного использования Open Source. В целом они должны сводиться к наличию профессиональной техподдержки силами разработчиков, которые могут не только настраивать и внедрять продукты, но и исправлять в них ошибки, и системы контроля качества и безопасности кода. В качестве примера такой системы можно привести центр изучения безопасности Linux, недавно созданный ИСПРАН и ФСТЭК. Простое использование Open Source как бесплатной альтернативы коммерческим продуктам заманчиво, но небезопасно, особенно в масштабах государственных и крупных промышленных информационных систем. Использование Open Source не нуждается в господдержке – оно и так достаточно привлекательно. Но разработка Open Source, которая необходима для его безопасного использования, – в поддержке нуждается. Но, чтобы поддержка была эффективной, надо помнить пословицу – «Человек, которому дали рыбу, – сыт. Человек, которого научили ловить рыбу, – сыт всегда». Господдержка не должна сводиться к прямой раздаче денег разработчикам. Она должна быть устроена так, чтобы способствовать развитию коммерциализации Open Source – т.е. становлению отрасли, зарабатывающей на разработке ПО с открытым кодом. Опасным является такая ветвь развития, в которой каждое ведомство или госкорпорация начинает создавать свои клоны широко распространенных продуктов для внутреннего использования. Это неэффективно и приводит к распылению драгоценного человеческого ресурса. Разработкой должны заниматься специализированные компании, которые способны сконцентрировать силы на основных направлениях разработки. Задачей государственной важности является создание условий для возникновения в стране компаний, способных взять на себя ответственность за функционирование открытого ПО в государстве. Без этого вместо зависимости от иностранных корпораций мы получим зависимость от международных сообществ, продуктивных, но безответственных.
– В последнее время Open Source Software уделяется много внимания, в том числе недавно объявили об учреждении АНО «Открытый код». Это важно, так как культура использования OSS, в том числе, подразумевает ответственность за тот код, который заимствуется у сообщества. Как минимум – это ИТ-гигиена (своевременная установка обновлений безопасности). В идеале же нужно иметь внутреннюю экспертизу разработчиков, которые умеют интегрировать в основной проект с открытым кодом и перерабатывать патчи, для того, чтобы сделать их применимыми для младшей версии. А если такой экспертизы нет, то необходимым условием для допуска в промышленную эксплуатацию является использование ПО от разработчиков, предоставляющих гарантийную поддержку на свою продукцию, в соответствии с необходимым SLA. Как один из мировых лидеров OpenJDK, формирующий стандарты разработки Java, мы знаем, что безопасность технологий и регламентация процессов создания открытого ПО являются определяющим фактором. Хотелось бы, чтобы АНО «Открытый код» смогло сформулировать базовые рекомендации по использованию открытого кода. Наша рекомендация для пользователей – использовать код только от официальных поставщиков. Выбирая код от такого провайдера, вы также получаете техническую поддержку, что еще более снижает риски безопасности, ведь вы сможете моментально получить необходимую помощь от самого разработчика кода. Для решения проблемы в целом можно предложить перевести под управление сообщества или АНО наиболее популярные сегодня проекты с открытым исходным кодом. В такой системе координат сообщество либо ассоциация сможет регулировать вопрос релизов, аудита и одобрения участников сообщества для внесения правок. Система лицензирования и соглашений участников должны быть понятны и демонстрировать правильные принципы вклада сторонних разработчиков и целых компаний. Через большую вовлеченность экспертных участников можно решить и вопрос с безопасностью.
– OpenSource имеет механизмы саморегуляции. Если мы хотим уделять вопросу безопасности больше внимания, всегда есть выбор. Можно либо добавить своих разработчиков в мейнтенеры, в действительно открытые проекты и тем самым полноценно участвовать в жизни проекта и повышать его безопасность, либо сделать форк и взять вопрос полностью в свои руки. А в случае достижении критической массы запроса такой форк даже может перетянуть на себя других разработчиков. И так как использование Open Source стало частью почти любого цифрового продукта, то повышение уровня доверенности происходит как благодаря совместным усилиям разработчиков, так и сотрудничеству компаний в отношении отдельных компонентов, благодаря разделению зон ответственности, нагрузки по ревью, оперативному исправлению уязвимостей. Но как бы там ни было, базой для повышения качества изменений, вносимых в Open Source, является процесс безопасной разработки, используемый в каждой конкретной компании. А также невозможность обхода этого процесса. В компании «Открытая мобильная платформа» такой процесс мы дополняем обширной автоматизацией, как в части проверки кода, так и в части тестирования продукта, а также вовлекаем разработчиков в активный мейтененс проектов.
– Прежде всего, это наличие компетентных сотрудников из Open Source-тусовки, которые в постоянной связи с сообществом будут формировать и развивать общую базу знаний. А она, в свою очередь, будет способствовать повышению безопасности решений с открытым кодом.
– Для нашей специфики очень не хватает средств динамического анализа для встроенных систем.
– В первую очередь, чтобы повысить уровень защищенности Open Source-компонентов необходимо создать закрытую среду разработки и вести учет всех действий разработчиков. Имеется в виду административный учет: кто и что сделал и кто какую строчку дописал. Также необходим статический, динамический и ручной анализ кода. Желательно, чтобы под эту задачу был выделен человек, который просмотрит исходники и найдет в них проблемы, а без его одобрения ничего не выйдет в релиз. Причина в том, что статистические и динамические анализы и вся автоматизация имеют вероятностный характер. То есть можно только с определенной долей вероятности сказать, есть в коде проблемы или нет. Если есть какие-то уязвимости, то автоматизированный анализ может их не увидеть в отличие от человека, который проведет ручной анализ.
– Важна грамотная организация процессов разработки и контроля безопасности кода, внедрение современных практик, внимательный подбор включаемых в проект компонентов. Среди инструментов могу выделить статические анализаторы кода вроде PVS-studio. Такие инструменты позволяют не только обнаружить слабые места, но и оперативно отслеживать изменения в коде.
– Самым эффективным инструментом по-прежнему будет выстраивание более организованного сообщества, фонда, АНО с четким формированием общих требований к аудиту и тестированию безопасности проектов.
– Как говорилось выше, это системы защиты классов SAST и DAST с модулями OSA.
– Существует довольно много инструментов с широким набором функций на выбор. Особо можно выделить два близких класса решений: Software Composition Analysis (SCA) и Open Source Analysis (OSA), применяемых для тестирования компонентов/библиотек сторонних производителей, используемых в ваших приложениях. Преимущество сканеров SCA/OSA в скорости работы и возможности держать разработчиков в курсе последних уязвимостей для используемых библиотек. Более того, некоторые инструменты даже помогут перейти на версию библиотеки с меньшим количеством уязвимостей без необходимости переделывать код. Еще одним преимуществом этой технологии можно назвать возможность проверки лицензий, прикрепленных к каждой библиотеке. Это позволит разработчикам избежать неприятностей при использовании библиотеки с лицензией, которая может оказать негативное влияние.
– Инструменты статического анализа проблем с безопасностью зависят от используемого стека. Хорошим помощником при выборе инструмента может стать список утилит на сайте OWASP – широко известной некоммерческой организации, занимающейся обеспечением безопасности веб-приложений: https://owasp.org/www-community/Source_Code_Analysis_Tools. Этот список регулярно обновляется сообществом. Из этого списка хочется выделить инструмент SonarQube, который мы используем у себя как обязательный минимум для конвейера разработки любого продукта. Он позволяет не только контролировать качество кода, но и находить типовые ошибки и уязвимости, а также сделать их устранение обязательным этапом жизненного цикла разработки ПО.
– Инструменты не работают без мотивации людей сделать использование свободно распространяемого ПО более безопасным. Поэтому я выскажусь за средства, создающие мотивацию:
– Помимо традиционных инструментов различного вида тестирования (Unit, Selenium/WebDriver, JMeter и т. д.) на помощь приходят продукты SAST/DAST/IAST/RASP (Dependency-Track, Clair, SonarQube). Крайне желательно встраивать эти проверки в обязательные шаги создания программного обеспечения. Например, мы всё чаще встречаем в крупных inhouse командах и компаниях-разработчиках появление конвейеров, в которых шаги анализа зависимостей на уязвимости являются обязательными и препятствуют, например, выкатке релиза на TEST/UAT.
– На рынке есть множество онлайн- и оффлайн-инструментов российских и зарубежных производителей. Например:
Современные средства могут автоматически выполнять ежедневное обновление базы уязвимостей, оповещать при выявлении небезопасного стороннего компонента или собственного исходного кода, обновлять версии используемого стороннего небезопасного компонента (если в новой версии уязвимость устранена), блокировать конвейер разработки и развертывания при невозможности автоматического решения проблемы, давать методические рекомендации по избеганию небезопасных программных конструкций в своем исходном коде, а также в коде сторонних компонентов, если разработчик не спешит устранять уязвимость, а удалить компонент нет возможности и приходится «патчить» сторонние уязвимости самостоятельно.
– Для повышения безопасности уже используемых компонентов с открытым исходным кодом необходимо использовать сторонние средства защиты, например, сетевые экраны и WAF, IDS или IPS.
– Если говорить о программных инструментах, то это статические и динамические анализаторы программного кода, средства автоматизации тестирования и анализа поверхности атаки. Плюс, конечно, средства коллективной работы над программным кодом.
– В первую очередь необходимо уделять больше внимания подготовке нового поколения профессионалов в сфере Open Source. Для этого нужно модернизировать ИТ-образование, внедрив практико-ориентированный подход к обучению, настроив взаимодействие вузов и технологических компаний, развивающих свои образовательные проекты. Это, в свою очередь, невозможно и без глубоких изменений в образовании вообще. Общее физико-математическое образование является базовым для ИТ-специальностей. Соответствующее внимание должно уделяться и ему. Необходим также приток активных профессионалов в образование. Преподавать должны те, кто сделал что-то своими руками и жаждет отдать свои достижения в руки молодежи. Государство занимается активной поддержкой развития ИТ-отрасли. В 2021 году вышел уже второй пакет мер поддержки, анонсировано начало работы над третьим. Меры эти существенны и заметно влияют на эволюцию отрасли. Надеюсь, что в третьем пакете будут учтены упомянутые выше особенности безопасности Open Source.
– Важны не только сами инструменты, но и их общая доступность разработчикам, их соответствие индустриальным стандартам. Любые инструменты должны пройти проверку временем, чтобы стоимость обеспечения процесса разработки безопасного кода стала ниже, а использовать эти инструменты было выгодно, и они автоматически стали востребованными. В этом смысле работа, проводимая Технологическим центром исследования безопасности ядра Linux в ИСП РАН по консолидации усилий разработчиков Linux- ядер и апробации таких вспомогательных инструментов - одна из первых таких полезных инициатив. Цели поставлены амбициозные, а сама форма как инструментов, так и взаимодействия между Центром и разработчиками будет еще оформляться и видоизменяться.
– ИТ-сообщество обменивается не конечными продуктами, которые использует заказчик, а наработками, кусками кода, модулями, библиотеками и т. д. Глупо применять единые требования ко всему ИТ-сообществу, т. к. суть Open Source в добровольности и открытости.
– Встречи, конференции, создание и развитие библиотек, содержащих совместно выработанные идеи, кейсы, разработки, видеоуроки и т. д.
– Считаю, что основным способом для взаимодействия ИТ-сообщества в области повышения безопасности (доверия) компонентов с открытым исходным кодом, является создание и продвижение сообществ по исследованию безопасности этих компонентов. Это позволит, если не полностью сместить фокус в сторону безопасной разработки, то сделать заметный вклад в обеспечение и становление этих процессов для компонентов с открытым исходным кодом.
– Возможно, в дополнение к OSday нужна профильная конференция по вопросам безопасности.
– Самым эффективным в длительной перспективе считаю интенсивный обмен опытом на конференциях, посвященных безопасности открытого ПО. Прочие методы не будут ориентированы на создание инженерной среды, культуры и новых кадров, способных решать эту и многие другие задачи.
– Помимо стандартных багтрекеров, считаю эффективным открытый диалог: конференции, митапы, круглые столы. На них разработчики Open Source-компонентов знакомятся ближе с требованиями бизнеса и получают прямую обратную связь. Обе стороны обмениваются болями, проблемами и их решениями. Это позволяет сблизить позиции и лучше понимать планы и потребности друг друга, в том числе по вопросам уязвимостей.
– Один из возможных вариантов – конференции и форумы, где представители ИТ-сообщества могли бы обсудить наиболее важные проблемы безопасности ПО с открытым кодом и найти решения. В результате, возможно разработать правила безопасности или какие-либо документы.
– Нужно понимать, что обеспечение безопасности – это непростой и недешевый процесс. Поэтому я считаю, что участники ИТ-сообщества должны объединять усилия для достижения общей цели. Например, потребители крупного компонента со свободным кодом могут формировать коалиции по совместному анализу безопасности используемого компонента. Такой подход позволит общими усилиями протестировать и обеспечить требуемый уровень безопасности даже более крупных компонентов.
– Ни один формат взаимодействия ИТ-сообщества в данном случае не может считаться достаточно эффективным, так как нет веских причин считать информацию, получаемую по таким каналам, как профильные форумы, сайты обмена информацией и иные формы сообществ, достоверными. Иными словами, возможны ситуации, когда злоумышленники намеренно направляют специалистов на определенные ресурсы, где содержится ложная информация о безопасности того или иного компонента, который на самом деле содержит недекларированные возможности или вообще является вирусным или нежелательным ПО.
– Истории успеха и неудач на различных конференциях помогают посмотреть свежим взглядом на внутренние процессы. Важно не только слушать, но и рассказывать о своем опыте, получать обратную связь.
– Существует ряд проектов, занимающихся регулярным исследованием уровня защищенности открытого ПО. Также многие большие корпорации, которые используют в своих продуктах Open Source-компоненты, участвуют в устранении проблем безопасности и закрытии дыр. Всё это в совокупности позволяет поддерживать открытые компоненты на высоком уровне безопасности.
– Отраслевые онлайн- и офлайн-форумы, телеграм-каналы, подписки на сообщения о новых уязвимостях и о методах и инструментах борьбы с уязвимостями.
– Создание дорожной карты на реализацию комплексных инфраструктурных систем с участием государственных грантов и программ для отечественных инвесторов. Помимо этого, будет целесообразно разработать и внедрить модель финансирования проектов на основе открытого исходного кода для обеспечения реализации стандартов цикла разработки ПО.
– Open Source уже давно является неотъемлемой частью многих ИТ-решений, представленных как на отечественном, так и на международных рынках. Это приводит к тому, что производители продукции начинают активно использовать один и тот же код для решения необходимых функциональных задач. Но перед ними равнозначно также встают вопросы обеспечения безопасности своей продукции, успешное внедрение и применение мер к разработке безопасного программного обеспечения. Для однотипного кода каждый вендор должен будет пройти этот путь целиком и самостоятельно. В свою очередь, если ИТ-сообщество будет сообща решать данную задачу, если будет делиться опытом и практиками, работая на результат коллективно, то очевидна будет не только конечная экономическая эффективность, но, что самое главное, реальное повышение уровня защищенности своей конечной продукции. Вектор такого развития в нашей стране уже задан. Форматы взаимодействия ИТ-сообщества сейчас вырабатываются в недавно сформировавшихся вокруг ИСП РАН сообществах по безопасной разработке и Центре компетенции по ядру Linux. Важно отметить, что во взаимодействии ИТ-сообщества активное участие принимают представители со стороны регулятора – ФСТЭК России, что позволяет сообществу принимать активное участие еще и в вопросах совершенствования руководящих требований в области разработки безопасного программного обеспечения с последующей их практической апробацией, в том числе в рамках соответствующих сертификационных испытаний.
– Тут я могу привести в пример международную экосистему разработчиков, аналитиков и пользователей, сложившуюся вокруг СУБД PostgreSQL за всё время ее существования. Благодаря объединению их усилий есть возможность расширять функциональность СУБД в соответствии с требованиями рынка и времени, повышать ее качество, надежность и защищенность. В это сообщество входят и индивидуальные разработчики, и мелкие и крупные компании, вносящие в наше время основной вклад в развитие продукта. Вообще, сообщества Open Source, их жизнь и деятельность, являются интересным и сравнительно новым социальным феноменом. Я надеюсь, что наши гуманитарии возьмутся за их изучение с точки зрения социальных наук и помогут разработчикам сотрудничать эффективно.
– В мировой практике существует много примеров успешной организационной структуры различных сообществ или фондов. Для создания такого формата работы в России, в первую очередь, необходимо определиться, какие именно проекты с открытым исходным кодом представляют наибольшую важность и интерес для внутреннего рынка, и затем создать организацию, которая возьмет на себя функции координации вопросов безопасности с этими проектами. Поскольку проекты с открытым исходным кодом могут быть самыми разнообразными, то, возможно, модель Linaro наилучшим образом подойдет для российской специфики.
– Эта проблематика всегда обсуждается на отраслевых мероприятиях. Но часто на этом всё и заканчивается, без дальнейших практических шагов. Чтобы взаимодействие было эффективным, необходимо выделять реальные человеческие ресурсы: на мейтененс компонентов, на обучение студентов, на постоянное взаимодействие с сообществом и др. Большинство компаний не готовы инвестировать в это, так как это не даёт результата в краткосрочной перспективе. Компаниям нужно осознать, что для того, чтобы через несколько лет существенно сократить затраты, им придется предпринимать конкретные шаги уже сейчас. Ключевые слова: Open Source, безопасность, ИТ-сообщество, экосистема, ИТ-решение, ядро Linux, ИСП РАН, ФСТЭК России Подпишитесь на журнал |
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
