Даниил Чернов, «Ростелеком-Солар»:
Наш анализатор защищенности ПО
интересен зарубежным рынкам

Даниил Чернов: Да, программы-дизассемблеры существует достаточно давно, но рынок сегодня обсуждает немного другую категорию ИТ-продуктов – таких, которые умеют делать реверс-инжиниринг программного кода. Разница заключается в том, что в первом случае человек получает для последующего анализа код на языке Ассемблер, который очень сложно читать, таких умельцев по пальцам можно пересчитать на всей планете. А во втором случае речь идет о восстановлении высокоуровневого кода, который очень близок к той программе, которую писал разработчик. Главная задача такого продукта - обнаружить уязвимости, «закладки» (недокументированные возможности, НДВ) и указать пользователю соответствующие куски восстановленного исходного кода, в которых содержатся эти уязвимости и закладки.

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

А есть метод «белого ящика», когда мы можем посмотреть, что внутри ящика, и все детально изучить, как под микроскопом. Соответствующие технологии относятся к классу статического анализа кода. У каждого из подходов есть свои плюсы и минусы.Как DevOps-сервис помогает «разгрузить» высоконагруженные системы BPMSoft 2.1 т

Достоинство «черного ящика» заключается в том, что для работы с ним, по сути, нужен только набор инструментов - «раздражителей» и понимание, как интерпретировать реакцию системы. Минус в том, что покрытие уязвимостей – ограниченное, многие мы таким способом вообще не обнаружим. Например, если в систему управления электростанцией заложена закладка «31 декабря 2022 года выключить все», то методом черного ящика ее не найти. В этом случае надо понимать, какие действия заложены в алгоритмы.

Или SQL-injection: ее кусочки разбросаны по разным местам программы. Для их обнаружения нужно построить некоторую модель того кода, который анализируется. Она включает граф потоков данных, граф потоков управления, анализ, каким образом переменные используются в системе, и т.д. Фактически анализируется модель ПО, а не текст программы. Этим занимаются технологии «белого ящика».

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

Этот вид анализа мы назвали бинарным, потому что производится анализ исполняемых файлов – фактически ноликов и единичек. Поясню на примере. Пусть у вас есть некий исполняемый файл, например, мобильное приложение для ОС Android, но исходного кода нет. Мы закидываем файл в Solar appScreener, и он прямо на бинарном уровне сканирует его. И на этом уровне понимает, где и какие уязвимости присутствуют. Затем включается реверс-инжиниринг, чтобы восстановить эти нолики и единички исполняемого файла в читаемый человеком код. На выходе система сообщает: вот найденные уязвимости, вот так они выглядят на языке высокого уровня. Я смотрю и понимаю: ага, вот тут небезопасная рефлексия, а здесь вообще ключ шифрования задан в исходном коде. Иными словами, в нише статического анализа мы продвинулись дальше рынка: анализируем не только исходные коды, но и исполняемые программы.

Даниил Чернов: Допустим, в вашей компании департамент разработки написал очередное ПО, и внутренний заказчик принял его. Нередко бывает так, что ваш отдел ИБ по каким-то причинам не может получить доступ к исходным кодам. Яркий пример – разработка мобильных приложений, которую, например, банки частенько отдают аутсорсинговым компаниям. В такой ситуации разработчики передают заказчику исходные коды крайне неохотно, а если и делают это, то у заказчика мало реальных возможностей проверить, те ли это исходные коды, которые потом идут в производство, то есть загружаются в App Store и Google Play.

Складывается парадоксальная ситуация: банк заказал разработку, но она для него является черным ящиком. Динамический анализ в этом случае вряд ли качественно поможет. А если вы используете бинарный анализ Solar appScreener, то получаете «белую» картину, которую изучаете с помощью статического анализа. Получается, что банк может самостоятельно взять готовый код из App Store и Google Play, загрузить для анализа, и при этом «черный ящик» приложения превращается в «белый».

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

Даниил Чернов: Мы общаемся с аналитиками Gartner. В 2017 году Solar попал в Gartner Hype Cycle. В прошлом году нас пригласили на тестовые испытания, но мы не прошли по специальным требованиям. Дело в том, что помимо технической части, у Gartner есть ряд бизнес-требований к претендентам на попадание в квадрант. В частности, есть требования к распределению глобального оборота компании по странам: отдельно выделяются продажи в США, Европе, других регионах. К сожалению, даже при наличии подтвержденных референсов от международных заказчиков по параметру объема продаж в ряде регионов мы пока не прошли через бизнес-фильтр Gartner. Однако это лишь вопрос времени. Сейчас мы очень активно развиваемся на международных рынках.

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

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

К тому же разработчики чаще всего не мыслят в терминах информационной безопасности, ведь от них обычно требуют продукт с определенным функционалом, удобный интерфейс, отсутствие багов и высокую надежность работы софта. По официальной статистике авторитетного в сфере ИТ Ponemon Institute, в 2018 году небезопасный софт стал причиной компрометации данных в 75% компаний по всему миру. А по данным Министерства внутренней безопасности США, более 90% успешных кибератак реализуется с использованием различных брешей в приложениях. Да, компании многого достигли в части ИБ, но слабо защищенным остался последний рубеж – прикладное ПО.

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

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

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

У нас есть облачный сервис сканирования ПО – несколько хабов в разных частях света, где ежедневно осуществляются десятки сканирований. Мы собираем статистику и считаем средний уровень защищенности. Так вот, для мобильных приложений средний уровень защищенности по пятибалльной системе (5- максимальная защита) составляет 2,0 – 2,3, то есть на двойку с плюсом… И если приложение соответствует хотя бы этому среднему уровню, это уже считается неплохим результатом.

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

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

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

Для разработчиков дополнительный контроль кода на уязвимости - как пятое колесо для телеги: мало того, что коллеги будут копаться в твоем софте, придется еще устранять уязвимости, если таковые найдутся. А значит, сроки полетят, за ними – бонусы, да еще бизнес по голове настучит. Потому что бизнес хочет, чтобы через три дня клиенты увидели новую систему, а ИБ указывает на дырявое ПО.

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

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

Для всего этого есть особое название - процесс безопасной разработки ПО (Secure Software Development Lifecycle, SSDLC). Он подразумевает, что в традиционный процесс разработки софта (Software Development Lifecycle, SDLC) бесшовно интегрируется проверка ПО на безопасность. Это похоже на системы управления бизнес-процессами: вначале договариваемся о регламентах и параметрах (как часто, что конкретно, в каком порядке проверяется), потом настраиваем системы управления под эти параметры. Тогда компания получает на своей площадке полноценный центр контроля безопасности ПО, который включает как сам инструмент анализа ПО, так и соответствующие бизнес-процессы.

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

Даниил Чернов: Объем глобального рынка Application Security (безопасности ПО) в 2018 г. аналитики Gartner оценили на уровне 2,7 млрд долларов США. Есть экспертный прогноз, согласно которому через 4-5 лет этот рынок достигнет объема 10 млрд долларов. По нашему мнению, это очень сдержанная оценка. Скорее всего, темпы роста будут выше. Если принять во внимание все стимулирующие факторы, возможен даже экспоненциальный рост рынка систем анализа безопасности ПО.

Даниил Чернов: Хороший вопрос. Сами уязвимости есть в открытых источниках. Поставщики анализаторов меряются алгоритмами поиска. Ведь задача каждого вендора – сделать так, чтобы бреши в софте обнаруживались быстро и в условиях ограниченных ресурсов, которые может выделить клиент. Термин «хорошо находить уязвимости» подразумевает, по сути, два параметра. Во-первых, минимум ложных срабатываний на «уязвимости», которых на самом деле нет. Во-вторых, минимум пропусков уязвимостей (когда уязвимость есть, но продукт ее не находит) - это, пожалуй, самое опасное, что может случиться.

Даниил Чернов: Конечно. И это является стимулом для развития технологий вендора. Возьмите, например, ложные срабатывания. Если обрабатывать их традиционным способом – «в лоб» линейным фильтром, это требует очень много ресурсов. А мы нашли другой подход – это результат нашей научно-исследовательской деятельности - используем fuzzy logic engine, модуль нечеткой логики, который позволяет фильтровать ложные срабатывания, не снижая процента выявления уязвимостей.

Замечу, что функциональность движка fuzzy logic engine была заложена в Solar appScreener изначально, но этот модуль постоянно развивается: расширяется база правил поиска уязвимостей, корректируются и адаптируются сами правила. Например, до осени прошлого года у пользователей не было возможности прямого использования этого модуля, то есть индивидуальной настройки фильтров движка. А теперь эта функциональность доступна. По нашим оценкам, за последние два - три года «качество» срабатываний, благодаря развитию модуля fuzzy logic engine, улучшилось в 3 раза.

По большому счету, вечным для клиентов будет один барьер - объем ресурса, который заказчик готов выделить на такую систему, на компьютерное железо. Эта дилемма будет, по-видимому, всегда: алгоритм отличный, работает быстро, но для него нужна стойка с серверами. Тут всегда будет треугольник: качество – скорость – ресурсы. Этими параметрами вендоры играли, играют и будут играть.

Даниил Чернов: Облачный вариант использования продукта – это, действительно, удобно: клиенту нужен только браузер, в котором он видит интерфейс продукта, а мощности - наши. Замечу, что облака больше любит западный рынок: клиент получает учетную запись и работает в личном кабинете - загружает софт, сканирует. А российские клиенты в большинстве своем предпочитают, чтобы Solar appScreener был полностью развернут у них.

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

Даниил Чернов: Да, это важный дифференцирующий параметр. Нужен широкий список языков программирования для того, чтобы покрывать все потребности любого клиента. «Ростелеком-Солар» сегодня – мировой лидер по количеству поддерживаемых языков программирования. Сейчас их у нас 26, в июле будет 29, в октябре – 31. Мы раз в квартал выпускаем новую версию продукта, включающую поддержку новых языков. У ближайших конкурентов сейчас 25 языков, но мы различаемся по их набору. Например, у нас есть языки, которых пока вообще нет у конкурентов: тот же Solidity – язык для описания смарт-контрактов в технологии блокчейн. Кроме того, в разных странах – разный спрос на поддержку языков программирования. Например, в России в банковской сфере до сих пор достаточно часто можно встретить язык Delphi, который на Западе почти не используется, считается сильно устаревшим. А вот приложения, написанные на популярных за рубежом Groovy и Kotlin, наоборот, у нас встречаются довольно редко.

К концу года мы достигнем состояния, когда у нас будут все языки, которые поддерживают конкуренты, и еще ряд других, которых у конкурентов нет.

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

Затем сравниваем результаты, смотрим, какой продукт лучше справился с выявлением уязвимостей. И еще смотрим на параметры второго уровня, например, время, за которое сканер решил задачу, удобство чтения предоставленного отчета и т.п. Согласитесь, имеет значение, запускаем ли мы сканер в пару кликов, как Solar appScreener, или нужно сделать десяток шагов, да еще предварительно изучить том документации или курсы посетить, иначе не разберешься.

Даниил Чернов: Почему нет? Бывает, что компания по каким-то причинам просто не может позволить себе коммерческий продукт. Тогда она либо ничего не делает для безопасности ПО, либо использует опенсорсный бесплатный продукт. Он, конечно, слабенький, но все же это лучше, чем ничего. При этом, конечно, не стоит забывать, что open source ПО поддерживают энтузиасты, и чаще всего эта поддержка оказывается на недостаточно высоком уровне. Действительно, откуда у них могут взяться ресурсы на серьезный R&D? На исследования алгоритмов? На поддержку базы уязвимостей в продукте?

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

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

1. Злоумышленник проникает в локальную сеть пользователя и перенаправляет его трафик через свой сервер (например, с помощью атаки типа «отравление кэша DNS»).
2. Пользователь инициирует соединение с safeserver.example.com по протоколу SSL/TLS.
3. Вместо открытого ключа safeserver.example.com злоумышленник передаёт приложению собственный открытый ключ и действительный сертификат, выданный ему центром сертификации для домена hackedserver.example.com.
4. Приложение убеждается в том, что полученный сертификат действителен (для hackedserver.example.com), игнорируя тот факт, что полученный сертификат выдан не для того домена, соединение с которым было запрошено изначально.

Добавлю еще, что мне как пользователю важно, чтобы я мог легко настраивать отчеты. Скажем, у меня мало времени, и я хочу видеть 15% самых важных результатов анализа. И еще я хочу сразу отсеять стандартные библиотеки в тех результатах, которые получил сканер. Можно заранее установить такие настройки, которые организуют для меня наиболее удобное и информативное отображение результатов.

Даниил Чернов: Да, уязвимости могут проигрываться по-разному, в зависимости от особенностей программно-аппаратной среды, в которой исполняется ПО. Возьмем простой пример: веб-сайт и известную уязвимость SQL-injection Анализатор разглядел уязвимость, отобразил в отчете, но мы знаем, что в системном окружении у нас работает Web Application Firewall, который не позволяет эксплуатировать эту уязвимость. Тогда ИБ-специалист может попросить систему не обращать внимания на эту ситуацию или понизить уровень уязвимости.

Кстати, в отчете Solar appScreener даются подобные рекомендации: как закрыть эксплуатацию уязвимости настройкой Web Application Firewall, чтобы принять максимально оперативные меры защиты. Поддерживается список наиболее популярных моделей, фаейрволов, для каждого предусмотрен перечень настроек и рекомендаций по применению политик безопасности.

Даниил Чернов: Наш продукт – двуязычный, и мы активно расширяем наше присутствие на зарубежных рынках. У нас есть заказчики в Малайзии, Сингапуре, Южной Корее, Австралии, Латинской Америке и т.д. Недавно мы завершили проект по внедрению анализатора защищенности приложений Solar appScreener в GNP Seguros, одной из крупнейших страховых компаний Мексики.

В этой стране проблема обеспечения информационной безопасности местных компаний стоит очень остро. Согласно отчету Europol’s European Cybercrime Center IOCTA 2018, Мексика является второй страной Латинской Америки после Бразилии по количеству произошедших в 2018 г. кибератак. С помощью технологий анализа защищенности приложений «Ростелеком-Солар» заказчик смог выстроить автоматизированный процесс безопасной разработки ПО. В частности, реализована интеграция анализатора с трекерами задач и системой управления репозиториями кода, а также набор API для интеграции с системами управления уязвимостями.

Важное событие связано с Южной Кореей. ИБ-регулятор этой страны Korean Internet&Security Agency (KISA) выбрал Solar appScreener для повышения защищенности своих разработок и сервисов. В процессе конкурсного отбора KISA изучило ряд самых передовых решений, реализующих технологии анализа защищенности приложений, как локальных, так и международных разработчиков. Известно, что в Южной Корее действуют очень жесткие требования в сфере сертификации и лицензирования решений в области информационной безопасности. В этих условиях решение Solar appScreener было признано сильнейшим, как с точки зрения функциональности, так и в плане удобства и простоты использования.

Как часть «Ростелекома», мы планируем активную работу на рынке Вьетнама. В мае был подписан межправительственный меморандум о взаимопонимании, направленный на развитие сотрудничества в области инфокоммуникационных технологий. Его подписали руководители «Ростелекома» и VNPT, ведущего поставщика телекоммуникационных услуг Вьетнама, в присутствии председателя Правительства Российской Федерации и премьер-министра Вьетнама.

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