Мы решили узнать, как внедрение безопасных подходов к разработке выглядит со стороны самих разработчиков. В новом интервью исполнительный директор компании «СмартСофт» Сергей Черномашенцев рассказал порталу Cyber Media, как команды борются с угрозами от open-source, где можно ждать помощи от регулятора и сколько денег потребуется, чтобы сертифицировать свой продукт.

О компании:

Смарт-Софт — российская многопрофильная сервисная ИТ-компания. С 2003 года занимается разработкой комплексных продуктов сетевой безопасности, а также оказывает широкий спектр услуг и сервисное сопровождение проектов в области информационной безопасности. В портфеле собственных разработок Смарт-Софт — многофункциональный межсетевой экран Traffic Inspector и универсальный шлюз безопасности Traffic Inspector Next Generation.

О спикере:

Сергей Черномашенцев – исполнительный директор, партнер компании «Смарт-Софт», cпециалист в сфере стратегического планирования, руководства проектами, кризис-менеджмента.

Cyber Media:Что такое для вас DevSecOps?

Сергей Черномашенцев: DevSecOps – это прежде всего процессы. Прежде чем браться за эти подходы, нужно, чтобы у вас внутри все было налажено. Должна быть команда профессионалов, которые понимают, что делать и зачем.

Например, у нас над тестированием ядра ОС работает 7 разработчиков, один тимлид и один руководитель проекта. А бывают компании, которые могут выделить только одного человека. Этот специалист будет единственным, кто контролирует процессы, понимает, как построена дорожная карта, и так далее. Если он хорошо знает свое дело, он испытания (и главное исправление предупреждений) ядра у него займут лет пять.

Когда специалисты ФСТЭК разрабатывали требования к производству ПО, регулятор исходил именно из этого: требования предназначены для зрелых компаний. То есть сертификация предполагает не формальное исполнение требований, а осознанный подход к безопасной разработке. Для чего мы делаем те или иные шаги, для чего мы исправляем ошибки и почему именно так – все эти представления должны сформироваться внутри компании.

А если выполнять требования формально, то каждое нововведение регулятора будет для компании чем-то непонятным, восприниматься в штыки: «Были правила, которые мы усвоили, зачем их менять?!» Совсем другое дело, когда ты в эти процессы погружен. Не зря есть чаты с коллегами из ФСТЭК, НТЦ «Фобос-НТ» – все очень открытые к общению, в том числе и Минцифры. В этих каналах очень подробно обсуждается вектор деятельности регуляторов, вопросы, которыми они будут заниматься, условно, через полгода.

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

Cyber Media: Есть ли в этом коммьюнити инициативы наподобие рейтинга OWASP TOP-10, где собираются самые серьезные уязвимости веб-приложений, чтобы все разработчики могли делиться опытом и лучше защищать свои продукты?

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

Для сертификации ФСТЭК необходимо проверить свой продукт по базам всех известных уязвимостей регулятора – это отдельный раздел документации.

Cyber Media: Вернемся к теме DevSecOps. Какие первые шаги должна предпринять команда, чтобы быстрее получить практические результаты?

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

И дело в том, что с DevSecOps вы 90% таких уязвимостей, не считая уязвимостей нулевого дня, закрываете уже в процессе разработки. Тот же WAF работает на базе правил, которые и позволяют ему отлавливать необычные процессы, аномальные потоки данных и так далее.

Конечно, внедрение DevSecOps в разработку повышает ее стоимость. И с другой стороны, DevOps-инженеры могут тормозить процесс, потому что им приходится переучиваться. Они уже много лет своим делом занимаются и считают, что все делают правильно. А переучить человека гораздо сложнее, чем научить с нуля. Пусть даже после выпуска продукта безопасникам приходится долго и тонко настраивать WAF.

Исправление уязвимости на этапе разработки может быть до 1000 раз дешевле исправления после релиза. Сейчас есть множество открытых, бесплатных DevSecOps-инструментов, которые сильно все эти задачи упрощают. Повторюсь, 90% уязвимостей не появятся в коде, если команда применяет хотя бы анализаторы исходного кода.

Cyber Media: Насколько на этот процесс может повлиять уход западных компаний из России? Хватит ли разработчикам отечественных инструментов или им нужно обратиться к open-source-сообществу?

Сергей Черномашенцев: Главный нюанс при использовании open-source состоит в том, что приходится прикладывать дополнительные усилия. Чем, например, решение «Смарт-Софта» Traffic Inspector Next Generation отличается от open-source продукта OPNsense в его основе? У нас полсотни самописных плагинов, плюс удобный интерфейс, плюс поддержка, обновления, закрытие уязвимостей. И так, как правило, со всеми продуктами на российском рынке NGFW (если вам говорят обратное – лукавство).

Вендор берет открытые анализаторы кода, добавляет свои модули, пилит интерфейс. Такой продукт будет работать с большим количеством языков, а бесплатный – с одним-двумя.

И дальше возникает вопрос, приносит ли ваше приложение достаточно денег, чтобы вы могли себе позволить вендорское решение? Потому что, например, за лицензию одного из двух рекомендуемых ФСТЭК анализаторов разработчик в лице ИСП РАН просит несколько миллионов рублей в год. А без этих инструментов вы сертификацию не пройдете – регулятор указывает, какой анализатор, какой антивирус какой версии нужно использовать для отчета. То есть для внедрения безопасной разработки, как это видит регулятор, необходимо использовать сертифицированные средства.

Сейчас, когда началась СВО, многие стали идти навстречу разработчикам, предоставлять бесплатные периоды исползования. Так что можно договариваться, просить лицензию авансом, брать демо. Мы, в частности, на встрече со ФСТЭК подняли вопрос: мы так же по закону обязаны отдать свой продукт в испытательную лабораторию, которая абсолютно так же должна использовать в проверках сертифицированные инструменты. Услуги испытательной лаборатории тоже стоят несколько миллионов рублей. Мы задали регулятору вопрос, нельзя ли эти затраты с разработчиков снять, и получили ответ: да, вы можете не покупать себе лицензию на анализатор, если лаборатория вам позволяет использовать свои инструменты, но необходимы подтверждающие документы, и испытательная лаборатория должна вам доверять.

Cyber Media: Складывается впечатление, что у разработчиков нет особой свободы для маневра.

Сергей Черномашенцев: Если это какой-то большой продукт, к нему подключается множество разработчиков. Например, совместная команда Института системного программирования РАН, ФСТЭКа, других видных участников рынка проанализировала ядро Linux. Такое большое содружество разработчиков может распределить между 50 людьми (около десяти активных участников) модули, плагины, обновления и оперативно их проверить.

А дальше другие компании, которые создают системы под Linux, могут взять исправленный код и отчет из общей ветки. И, очень грубо говоря, это будет сертифицированная версия ОС. Примерно так же, как Astra Linux является сертифицированной средой обработки. И это избавляет от космического объема работы.

Исправление и анализ походят на программу bug bounty: разработчики очень часто на полном энтузиазме ищут уязвимости не ради денег, а ради славы и портфолио.

Возможность поместить свое имя в мастер-ветку – это дополнительные козыри, когда разработчик приходит устраиваться на работу. Конечно, твои шансы увеличиваются, если ты можешь показать, что исправил какую-то значительную часть ядра.

Cyber Media: Общее место в сегодняшних разговорах о разработке – безопасность open source компонентов. Команды используют сторонние библиотеки, и зачастую автор продукта не может перечислить, какие именно модули есть в системе, какой версии какие у них есть уязвимости. Насколько такие угрозы актуальны в контексте DevSecOps?

Сергей Черномашенцев: Да, наверняка даже сейчас у каких-то разработчиков продолжает идти автоматическое обновление из общего репозитория. Хочется, чтобы команды шли по более осознанному, разумному пути, отключали автоапдейты, просматривали код, который используют.

У «Смарт-Софта», кстати, получилось достаточно странно – мы отключили автоматическое обновление 17 февраля (2022 года – прим. ред.). Уже тогда мы посчитали, что количество «закладок» превысило некую пороговую величину. И перенесли все на собственный независимый репозиторий.

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

Глазами такие вещи легко пропустить, поэтому нужно автоматизировать проверки. Анализатор точечно найдет, что именно добавили предыдущие авторы кода. Это гораздо проще – достаточно посмотреть эти измененные участки. Анализатор получше даже привлечет внимание к предупреждениям в коде. Чем дороже инструмент, тем меньше ручной работы.

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

Из-за ухода западных компаний у нас практически не осталось инструментов для проверки мобильных приложений. У разработчиков есть варианты: пользоваться взломанным ПО, либо каким-то сложным образом пытаться поднять виртуальную машину в Германии, прокинуть туннели через Азию и как-то оплачивать все это с зарубежного счета.

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

Cyber Media: Последний вопрос – про процессы, которые, как мы говорили в самом начале, составляют значительную часть и DevOps, и DevSecOps. На этом горизонте сейчас какие стоят задачи перед командами?

Сергей Черномашенцев: Да, как уже говорилось, компания должна созреть. Внедрение DevSecOps проходит сложно, дорого и долго, и надо очень хорошо представлять себе результат. У ФСТЭК даже есть ограничение – с момента подачи заявки на сертификацию необходимо завершить процесс не позже, чем через полтора года. Если процесс затягивается – скорее всего вы изначально неверно подошли в внедрению DevSecOps и сейчас попытается что-то скроить в надежде на невнимательность регулятора.

И нужно понимать, что все это стоит больших денег. Если вы сейчас захотите открыть испытательную лабораторию и озаботитесь всеми необходимыми сертификатами, вам потребуется около 60 миллионов рублей и несколько лет. Это вдобавок к необходимости иметь штат достаточно высокооплачиваемых людей с профессиональным ИБ-образованием и несколько руководителей с допуском первой степени.

Все это – не для того, чтобы собрать с компанией побольше денег, а для того, чтобы определить зрелость компании. Раньше сертификат выдавался на пять лет конкретную версию продукта. Практически нельзя было исправлять, закрывать уязвимости, выпускать обновления. А софт сейчас устаревает фактически через полгода.

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

Если подходить трезво и с умом, набрать профессионалов, которые знакомы с сертификацией, вам понадобится год-полтора, чтобы разобраться с документацией (минимум). Три-четыре разработчика, один-два технических писателя, один руководитель проекта – такая команда за полтора сможет подготовиться к сертификации. После чего начнется сам процесс сертификации: закладывайте еще полтора года.

А закидать регулятора или испытательную лабораторию деньгами сейчас уже не получится. Потому что вам скажут, что вы должны сами проделать работу, чтобы после сертификации не остаться один на один с продуктом, про который вы ничего не знаете. То есть, если вы даже найдете людей, которые подготовят все необходимое для сертификации – это будет, во-первых, дорого (10-20 миллионов), так еще и вы привязываете себя к аутсорсу на весь жизненный цикл продукта. Либо после получения сертификата запускаете у себя заново подготовку к внедрению SDL (Security Development Lifecycle - жизненный цикл безопасной разработки).