Даниил Чернов, «РТК-Солар»: Проверить на защищенность сегодняшние объемы кода без автоматизации невозможно

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

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

Даниил Чернов: Конечно. Классическая модель атак предполагает эшелоны защиты. Образно говоря, есть замок, вокруг него – глубокий ров, высокий прочный забор, массивные железные двери. Нужно пройти всю эту эшелонированную оборону, чтобы попасть внутрь замка. Почему сегодня так опасны атаки через application security? Можно попасть внутрь, минуя все линии защиты периметра и материализоваться прямо в удаленной комнате в глубине замка. Всего лишь надо добавить к правильному коду некие сторонние компоненты, которые потом прямиком попадут в высококритичную систему, которая обрабатывает корпоративную конфиденциальную информацию.

Собственно, поэтому мы увидели в начале этого года не просто рост внедрений инструментов application security, а мощный лавинообразный всплеск таких проектов и на территории нашей страны, и за ее пределами.Российский рынок облачных ИБ-сервисов только формируется 2.3 т

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

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

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

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

К чему это привело? Приведу яркий пример. Недавно мы участвовали в выставке в Сингапуре. Один посетитель заинтересовался нашим сканером уязвимостей и решил проверить свое мобильное приложение, и там оказалось почти 4 миллиона строк кода. Четыре. Миллиона. Строк. Можете представить, что туда включили разработчики? Ядро Linux лет 10 назад было меньше по объему. И что мы имеем в результате? Гигантские объемы кода, где огромное количество фактически неиспользуемого кода, который появился там только потому, что железо это позволяет. Без автоматизации реально проверить такой код нельзя.

В реальной жизни, если компания ведет собственную разработку, то есть имеется репозиторий, где хранится код, работает какой-никакой bug-трекер, CI/CD-серверы и др., уже имеет смысл все автоматизировать. Уже нужно строить процесс разработки таким образом, чтобы стоит появиться в репозитории новому кусочку кода, система анализа на уязвимости автоматически понимала: появился код, его нужно забрать, просканировать и передать дальше на следующий этап разработки. Можно выстроить автоматизированную логику действий: если после анализа защищенности кусочка кода уровень защищенности оказался ниже определенного порога, сборка тормозится, назначенные люди об этом уведомляются и принимают решение - пускать или не пускать.

Даниил Чернов: Эта автоматизация должна развиваться в русле новой культуры безопасной разработки. Причем, это именно новая культура, а не просто некоторые практические подходы. Культура подразумевает, что все стороны находятся в общем информационном поле и в едином процессе. То есть не может быть ситуации, когда бизнес требует: в понедельник продукт должен быть выпущен. Безопасники отвечают: нет, нужно закрыть дыры. А разработчики крутят головой: да, мы в любом случае к понедельнику не успеем… Должен быть формат обсуждения таких ситуаций и выработки согласованного решения. Собственно, это и есть суть того, что сегодня называют модным термином DevSecOps: процесс DevOps пронизывает Security.

Даниил Чернов: SDLC – это Software Development Lifecycle, а Secure добавляет к разработке ПО значение «безопасная». В общем-то, этот термин обозначает примерно то же самое, что и DevSecOps, – то, что процесс разработки интегрировал в себя аспекты безопасности, и разрабатываемый софт проверяется не только на баги, но и в том числе на уязвимости.

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

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

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

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

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

Даниил Чернов: Есть одна важная для понимания происходящего вещь, реализация которой позволяет максимально упростить процесс проверки и улучшить результат. Это концепция, которая получила название Shift Left. Речь идет о том, что разработка развивается по оси времени, и в какой-то момент t1 возник код.

Так вот, как только код возник, нужно его проверить в следующей точке t2, которая расположена как можно ближе к точке возникновения кода. Потому что, чем дальше от этой точки, тем сложнее и дольше переписывать куски кода с выявленными уязвимостями. Скажем, если программный продукт с уязвимостями дойдет до стадии запуска в рабочей среде (deploy), то придется возвращаться на много-много шагов назад, фактически переписывать все заново и заново проходить все циклы тестирования. Вот такая простая истина позволяет максимально повысить эффективность и минимизировать количество ресурсов, затраченных на проверку кода.

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

Возьмем другой пример. Есть компания, в которой несколько десятков ИТ-систем, 200-300 разработчиков разной направленности и разного опыта, которые используют для разработки десяток языков программирования. Самый сложный случай, пожалуй, в банках – они предпочитают по максимуму писать код самостоятельно – интернет-банк, мобильный банк, KYC, финансовые системы и т.д., вплоть до АБС.

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

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

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

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

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

Даниил Чернов: Мы с самого начала - с 2015 года - стремились разрабатывать сканер уязвимостей в соответствии с теми требованиями, о которых я рассказал. Одним из приоритетов была высокая точность обнаружения уязвимостей при низком количестве ложных срабатываний. Поэтому в продукте Solar appScreener реализован собственный уникальный механизм, который позволяет достичь этих целей, - алгоритм Fuzzy Logic Engine. Алгоритм, как видно из названия, использует математический аппарат нечеткой логики. В чем его преимущество?

Когда вендоры соревнуются в области статического анализа кода, они конкурируют главным образом алгоритмами. Эти алгоритмы различным образом описывают правила обнаружения уязвимостей. Причем на одну уязвимость может приходиться несколько десятков правил. И вот эти правила начинают последовательно срабатывать: есть уязвимость, нет уязвимости и т.д. Получается поток противоположных результатов: true-false- true-false- true-false и т.д. Нужно принять окончательное решение, есть там все-таки уязвимость или нет. В рамках классической бинарной логики выбор невелик: да или нет, и всегда остается возможность ошибки.

Наш алгоритм на базе нечеткой логики оперирует суждениями типа «на 30% уязвимость есть, на 70% - нет». Согласитесь, такая аналитика гораздо более полезна для сотрудников, отвечающих за проверку кода.

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

Даниил Чернов: Что касается языков программирования, то наши инструменты поддерживают максимально большое количество языков, которые вообще есть у коммерческих сканеров. Сегодня их 36. Также поддерживается большое количество интеграций – из коробки умеем интегрироваться с репозиториями кода, bug-трекерами, CI/CD-серверами и т.д. А если в компании обнаруживается какая-то экзотика с точки зрения интеграции, то для этих целей есть очень гибкий API, который позволяет интегрироваться с чем угодно. Все это стало возможным благодаря солидному опыту внедрения наших инструментов как в России, так и за рубежом, в компаниях с десятками тысяч сотрудников и сотнями разработчиков.

Даниил Чернов: Поймать уязвимость – это только одна часть задачи, нужно еще минимизировать сопутствующий «мусор», а потом предложить рекомендации, что с этим обнаруженным «богатством» сделать. Сегодня все серьезные вендоры активно работают в этих направлениях, используя в том числе методы искусственного интеллекта. Я уверен, что одно из самых перспективных направлений исследований – возможность интеграции результатов различных движков: статического анализа (Static Application Security Testing, SAST), динамического анализа (Dynamic Application Security Testing, DAST), композитного анализа (Software Composition Analyses, SCA). Это самое «горячее» направление аналитики поиска уязвимостей в коде.

Сегодня после трех проверок тремя разными инструментами специалист получает три разных отчета. А если научить все эти движки работать вместе с общей аналитикой, то вполне может оказаться, что множество уязвимостей, выявленных SAST, DAST и SCA по отдельности, укладываются, например, в одну рекомендацию по замене конкретной библиотеки на новую версию. Наш R&D-центр мы ориентируем именно в этом направлении. Мы хотим, чтобы разные аналитические компоненты могли общаться между собой на одном языке, а зонтичная аналитика обобщала результаты разных модулей и предоставляла пользователю унифицированные выводы и рекомендации.

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

Даниил Чернов: Это следующая ступень эволюции инструментов анализа кода на уязвимости.