Комментарий генерального директора НТЦ ИТ РОСА Олега Карпицкого.

В январе 2022 г. редакция журнала «Системный администратор» обратилась к экспертам рынка с вопросом: 

«Популярность свободного программного обеспечения постоянно растет. Поэтому задача повышения безопасности ПО с открытым кодом остается едва ли не самой актуальной, когда речь заходит о распространении Open Source во всех экосистемах. Как повысить безопасность Open Source компонентов?»

Мнение Олега Карпицкого, генерального директора ООО «НТЦ ИТ РОСА»:

«Разработчики открытого ПО (включая программные продукты, предназначенные для конечных пользователей) зачастую используют сторонние открытые компоненты, которые их авторы изначально могли не проверять на уязвимость. Например, разработчиком популярного компонента в этом сообществе может выступать частное лицо, и такой автор может не выделить достаточное количество времени и внимания безопасности своей разработки.

Кроме того, сама концепция открытого кода подразумевает, что злоумышленник может иметь к нему доступ, и следовательно, сознательно искать и находить уязвимости в нем.

Чтобы застраховаться от случаев появления уязвимости в сторонних компонентах, подобных тому, о котором стало известно буквально на днях, создателям конечного продукта необходимо тестировать на безопасность не только свой код, но и исследовать компоненты, встраиваемые со стороны.

Вариантов избавления от «дыр» в «чужом» компоненте существует три: перейти на свежую версию используемого ПО, если таковая имеется; сделать исправление собственными силами; в самом крайнем случае, отказаться от компонента.

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

Что касается приведенного выше самого «свежего» случая, то со стороны НТЦ ИТ РОСА исправление стало доступно для установки в нашем репозитории, а также на нашем сайте в соответствующем бюллетене безопасности буквально через 2 часа после обнародования уязвимости.

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

В последнее же время в мире открытого ПО и в российском его сегменте формируются как независимые, так и регулируемые сообщества разработчиков, объединенные задачей повышения безопасности, которые определяют методики проведения исследований ПО на безопасность и, собственно, осуществляют подобные исследования наиболее часто используемых открытых компонентов. В качестве примера можно привести организацию Open Source Security Foundation (OpenSSF), основанную Microsoft, Google, Red Hat, IBM и Linux Foundation.

Объединение разработчиков в сообщества снизит их совокупные издержки на обеспечение безопасности ПО, т.к. часто используемые всеми разработчиками компоненты можно единожды тестировать, по итогам анализа присваивать им статус доверенных продуктов и затем применять их как безопасные решения во множестве конечных продуктов.

И таких сообществ даже в России не одно. Так как открытое ПО — это мейнстрим внедрения ИТ в госструктурах РФ, то здесь важна роль некоего регулятора, который создает методики анализа кода на безопасность, разрабатывает соответствующие стандарты (ГОСТы). При координации такого регулятора, как ФСТЭК, в настоящее время формируется подобное сообщество – центр по исследованию безопасности операционных систем на базе ядра Linux. Помимо ФСТЭК собственные требования к средствам защиты информации выдвигают Министерство обороны РФ и ФСБ.

Отличие ПО, сертифицированного ФСТЭК, состоит в том, что в такой продукт очень сложно внести какие-либо изменения. Это объясняется как техническими, так и экономическими причинами, ведь для изменения подобного ПО необходимо вновь подключать сертификационную лабораторию при ФСТЭК. Поэтому тут допускается только два вида модификаций: во-1), собственно закрытие уязвимостей по безопасности (причем, без привязки к сроку действия подписки на техническую поддержку); во-2), подтвержденные ФСТЭК необходимые функциональные изменения, проводимые через специальные механизмы внесения изменений в сертифицированное ПО.

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

• проведение статического анализа кода на безопасность (насколько корректно написан сам код);
• проведение динамического анализа кода (анализ исполняемого кода);
• анализ уязвимостей по открытым источникам (см. пример выше);
• получение обратной связи от пользователей о найденных уязвимостях: у многих крупных заказчиков выделены внутренние службы, ответственные за информационную безопасность как собственных ИТ-разработок, так и внешних решений;
• анализ «на проникновение», или так называемый «этический хакинг».

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

Комментарий опубликован в №№ 1-2 журнала «Системный администратор» за 2022 г.