Даниил Чернов: Объем российского рынка анализа защищенности приложений ежегодно удваивается

Руководитель направления Solar appScreener компании Ростелеком-Solar Даниил Чернов рассказал Anti-Malware.ru о тенденциях развития рынка анализа исходного кода в России и в мире, о применении концепции security by design в разработке программного обеспечения, о запуске процесса проверки исходного кода на уязвимости из коробки, а также о том, как в этой сфере используются искусственный интеллект и машинное обучение.

Если говорить о глобальном рынке средств анализа кода, какие тенденции вы можете выделить?

Д. Ч.: Рынок анализа защищенности приложений запустил Microsoft, поэтому технологии анализа кода получили наибольшее распространение в США, 60-70% мирового рынка находится там. Для американских компаний такие средства — коммодити, как у нас антивирус. Часто в работе используются сразу два сканера кода, выстроенных в эшелонированную защиту, чтобы минимизировать ошибки.

Как один из немногих отечественных разработчиков систем данного класса, за прошедшие годы мы всесторонне изучили зарубежный опыт развития технологий анализа защищенности приложений, тренды и направления этого развития, определили фичи, которые станут востребованными в ближайшее время. На наш взгляд, будущее этого класса продуктов лежит в сфере их интеграции в непрерывный процесс безопасной разработки, совершенствования алгоритмов анализа при поиске уязвимостей и одновременно упрощения процедуры сканирования, снижения числа ложноположительных и ложноотрицательных срабатываний как одного из основных показателей эффективной работы сканеров уязвимостей, а также бинарного анализа, позволяющего проверять приложения на уязвимости без исходного кода (исполняемые файлы). Именно эти направления мы сейчас активно развиваем и усиливаем в своем решении, в том числе в новой версии Solar appScreener 3.0, которую мы выпустили буквально на днях.

В России рынок анализа защищенности приложений начал зарождаться лет шесть назад. Какое-то время он практически не развивался, но сейчас вступил в фазу активного роста. Хотя мы все еще на 5-7 лет отстаем от уровня США, каждый год объем отечественного рынка систем анализа защищенности приложений, а вместе с ним и уровень зрелости компаний как минимум удваивается. Большинство российских клиентов имеют представление о технологиях анализа кода, многие уже хорошо ориентируются в игроках и инструментах.

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

Д. Ч.: Факторы накладываются. С одной стороны, в разных отраслях есть регуляторы, которые рекомендуют проверять приложения на наличие уязвимостей. Например, в банковской отрасли ЦБ РФ рекомендует сканировать софт на уязвимости и закладки, похожие положения есть и в сфере защиты АСУ ТП. С другой стороны, все чаще случаются инциденты, реализованные с помощью эксплуатации уязвимостей в приложениях. В целом, рынок ИБ в России зрелый, и основные элементы защиты — антивирусы, фаерволы, системы управления доступом — уже используются компаниями, поэтому атакующие стараются проникнуть через самое слабое звено. Сейчас это социальная инженерия и уязвимости в софте.

В этом году в сообществе ИБ стали активно говорить о термине security by design — возможно, потому, что пришло осознание неэффективности наложенных средств защиты. Применим ли такой подход к разработке программного обеспечения?

Д. Ч.: К разработке программного обеспечения это применимо в первую очередь, потому что софт часто является последним, а иногда единственным рубежом защиты. Например, после того как мобильные приложения выложены в магазин, никакими наложенными средствами невозможно предотвратить поиск в них уязвимостей и их эксплуатацию злоумышленниками. Security by design необходима, когда ведется разработка программного обеспечения, часть кода которого наследуется из сторонних репозиториев и библиотек. Если не заложить концепцию security by design с самого начала, то можно интегрировать в свое программное обеспечение множество сторонних компонентов, содержащих уязвимости. А когда это выяснится, извлекать эти части из готового продукта и чем-то их заменять будет тяжело, потому что они, например, могут быть ядром архитектуры. При разработке программного обеспечения встроенная безопасность необходима, чтобы на первых этапах, еще до интеграции сторонних компонентов, можно было проверить их на уязвимости и принять решение о возможности их дальнейшего использования в программном продукте.

А если проиллюстрировать этот тезис об уязвимых сторонних компонентах, то какие примеры можно привести? Мне приходит на ум OpenSSL, который до сих пор патчат.

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

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

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

Сканеры кода также до последнего времени были заточены под людей, которые имеют опыт разработки, — по этой причине безопаснику было тяжело интерпретировать слишком технические отчеты. Мы у себя эту проблему давно решили, интерфейс нашего продукта изначально был ориентирован не на разработчиков, а на специалистов по информационной безопасности. А в новой версии Solar appScreener 3.0, которая недавно вышла на рынок, мы представили обновленный интерфейс, максимально простой и удобный для использования, требующий минимального количества кликов для доступа к тем или иным функциям системы.

Если поговорить с айтишниками, то они считают, что если в их процесс влезает безопасность, то это все тормозит.  Как найти компромисс?

Д. Ч.: Мы сейчас проводим внедрения, в рамках которых заказчик приобретает не просто инструмент проверки на уязвимости, а процесс обеспечения безопасной разработки. Мы вводим промежуточную стадию разработки, дополняем ее элементами контроля — с комфортной периодичностью проводится сканирование кода на уязвимости, и его результаты анализирует ИБ-специалист. Он может просто контролировать процесс разработки, не вводя ограничений на релиз. В таком случае при обнаружении уязвимости в веб-приложении можно закрыть ее фаерволом и другими наложенными средствами защиты и одновременно поставить разработчикам задачу по исправлению этой уязвимости. В более критичных случаях безопасник, или на Западе — специалист по безопасности приложений (application security manager), накладывает вето на релиз. Если приложение не соответствует критериям безопасности, бреши надо устранять.

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

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

А формат привлечения секьюрити эдвайзера у нас в России на уровне стартапов не практикуется?

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

Можно ли автоматизировать процесс проверки исходного кода на уязвимости и запустить его из коробки? Или это всегда индивидуальный проект?

Д. Ч.: Смотря как понимать термин «из коробки». Как правило, хорошие сканеры кода поставляются вместе с набором коннекторов или плагинов. Наш сканер можно в два клика интегрировать, например, с Jira или с тем же Team City, и затем по определенным триггерам вы можете запускать сканирование. Что может быть триггером? Например, разработчик пишет код, коммитит его в репозитории, и это действие может являться триггером автоматического запуска проверки и отправки системой уведомления безопаснику, чтобы он ознакомился с результатами. То есть это почти из коробки.

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

Для какого программного обеспечения анализ кода используется прежде всего?

Д. Ч.: Если в компании есть внутренняя или внешняя разработка, то независимо от отрасли сканирование кода на уязвимости такой компании необходимо. В группу риска прежде всего входят веб- и мобильные приложения, предназначенные для внешнего использования. За ними идут приложения, которые обрабатывают ценную для компании информацию, — это могут быть, например, системы документооборота, бухгалтерского учета и т. п.

Если говорить о сегментах вашего рынка, какие отрасли для вас являются ключевыми? Понятно, что банки, но кто еще?

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

Компании, которые используют услуги заказной разработки, пока не внедряют у себя процессы, ориентированные на безопасность? У любого интегратора есть своя разработка — на каком уровне у них все находится?

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

В каком направлении развиваются технологии анализа защищенности приложений и исходного кода?

Д. Ч.: Основных технологий анализа три — динамический анализ, статический анализ и интерактивный анализ. Есть еще экзотика вроде Runtime Application Software Protection, когда в приложение внедряется некий код, и оно защищает само себя. Концепция интересная, но пока не работает.

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

Какие языки у вас поддерживаются сейчас? Я помню, что на этапе первого релиза языков было немного...

Д. Ч.: Мы очень быстро развиваемся, у нас 4 мажорных релиза в год, по сути, новая версия выходит каждый квартал. Сейчас наше решение поддерживает более 20 языков разработки, то есть все основные. Но мы добавляем и редкие языки — например, Solidity, на котором пишутся смарт-контракты в блокчейне. В новый релиз, вышедший на днях, мы добавили COBOL — это устаревший язык, который раньше часто использовался для разработки банковских приложений. Также мы поддерживаем язык ABAP, на котором пишутся SAP-приложения. Наша цель — нарастить максимальное количество языков без потери качества сканирования, совершенствовать технологии анализа бинарного кода и сделать продукт таким, чтобы он генерировал как можно меньше ложных срабатываний.

В АСУ ТП используется софт на специфичных языках. Вам пришлось в связи с этим внедрять новые языки?

Д. Ч.: Наш сканер кода поддерживает язык Delphi, часто используемый в приложениях, написанных для АСУ ТП. Вообще, у нас быстрый цикл планирования: если мы видим спрос и интерес, то можем оперативно добавить необходимый язык. Ту же поддержку legacy-языка COBOL мы добавили по запросам, пришедшим с зарубежных рынков.

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

Д. Ч.: Есть несколько вариантов. Первый — когда код утерян, но надо его проверить. Система восстановит код и покажет, где содержатся уязвимости. Второй вариант — это контроль разработчиков, ситуация zero trust policy. Всегда есть опасность, что на проверку отдан зачищенный код, а не тот, который идет в производство. Мы можем брать приложение из производства и проверять его, не беспокоясь, что код мог быть модифицирован. Но самый распространенный кейс — это когда собственная разработка компании использует сторонние программные компоненты, исходный код которых недоступен. С очень высокой вероятностью в них будут обнаружены какие-то сюрпризы с точки зрения безопасности. Бинарный анализ позволит проверить эти «вставочки».

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

Д. Ч.: Лучше знать, что внутри, чем находиться в состоянии комфорта и думать, что все защищено. Если ИБ-специалист знает, что софт содержит уязвимости, он сможет решить, как нейтрализовать этот риск. Если это веб-приложение, можно прикрыться Web Application Аirewall, если это внутреннее приложение, можно найти решение на уровне внутренних процессов, если это модуль в самописном коде, можно рассмотреть вариант замены модуля другим. Это вопрос взвешенного подхода и анализа рисков.

Искусственный интеллект и наработки в машинном обучении могут быть использованы для анализа исходного кода? Работаете ли вы в этом направлении?

Д. Ч.: Да, это очень интересная тема, и, на мой взгляд, она может быть полезна в анализе кода. Одна из самых больших проблем в нашей отрасли — это ложные срабатывания и их фильтрация. Некоторые разработчики стараются сократить количество ложноположительных срабатываний, но при этом начинает расти число пропущенных уязвимостей. Другие вендоры сознательно идут на большое количество ложных срабатываний, чтобы не загрублять фильтр по реальным уязвимостям. Мы для решения этой проблемы разработали технологию Fuzzy Logic Engine, основанную на использовании математического аппарата нечетких множеств и нечеткой логики; эта технология близка к искусственному интеллекту. Мы постоянно ее обучаем, вводим коэффициент экспертных функций, чтобы фильтрация ложных срабатываний не влияла на качество выявления реальных уязвимостей.

Если при помощи Solar appScreener или других продуктов можно обнаружить уязвимости, этим может воспользоваться и злоумышленник. Как быть с этой опасностью?

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

Есть ли у вас планы создания сервиса по модели SaaS, чтобы небольшие компании и стартапы могли осуществить разовые проверки?

Д. Ч.: У нас SaaS появился еще в 2016 году. Система поставляется в двух вариантах. Первый — это облачное решение, размещенное в нашем ЦОДе; его использование тарифицируется по количеству сканирований. При этом на стороне клиента нужен только браузер. Второй вариант — локальная версия, которая разворачивается у клиента. В этом случае параметром лицензирования выступает количество аккаунтов в системе, других ограничений — по языкам или по числу проектов — нет. Также можно выбрать комфортный вариант использования локального решения: либо купить подписку на год, либо приобрести вечную лицензию и продлевать поддержку.

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

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

Локальной версии не нужен доступ в интернет. Если вы не загружаете мобильное приложение в магазин, то интернет не нужен совсем — обновления можно приносить на флешке. Мы пошли на это, чтобы клиенты были уверены в том, что их данные в безопасности.

Благодарим за интервью и желаем успехов!