Сергей Деев, МТС RED: Мы предложили решение, которое выведет управление безопасной разработкой на новый уровень

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

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

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

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

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

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

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

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

Сергей Деев: Говоря о перспективах рынка безопасной разработки, следует выделить два направления — глобальное и российское. На глобальном направлении уже на протяжении достаточно длительного времени наблюдается активный рост рынка безопасной разработки. По экспертным прогнозам, в период с 2022 по 2030 гг. совокупный среднегодовой темп его роста (СAGR) составит 27,7%. Такой рост обусловлен тем, что несмотря на ухудшение глобальной экономической ситуации и снижение темпов роста экономик разных стран, кибербезопасность остается приоритетной задачей. К тому же повышается уровень цифровой зрелости компаний, которые уделяют больше внимания как вопросам информационной безопасности в целом, так и автоматизации практик безопасной разработки в частности.

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

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

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

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

Все эти факторы активно стимулируют развитие российского рынка безопасной разработки. По нашим прогнозам, совокупный среднегодовой темп роста сегмента решений безопасной разработки с 2022 по 2027 гг. достигнет 44%. Это почти в два раза выше, чем аналогичный показатель роста российского рынка информационной безопасности в целом.

Сергей Деев: Исторически сложилось так, что в стране сформировалась когорта компаний-разработчиков инструментов анализа защищенности ПО. У нас в достаточном количестве представлены статические анализаторы кода (SAST, Static Application Security Testing), разработаны отечественные динамические анализаторы (DAST, Dynamic Application Security Testing), в подгруппу которых также входят и фаззеры (fuzzing). Присутствуют и инструменты композиционного анализа (SCA, Software Composition Analysis), включающие в себя и модули анализа Open Source (OSA, Open Source Analysis). Важнейшими характеристиками этих решений является точность и полнота обнаружения уязвимостей и дефектов ПО. Учитывая, что в стране уже немало компаний применяют у себя практики безопасной разработки, производители инструментов могут развивать и совершенствовать свои решения, понимая свою аудиторию, и уже достигли высокого уровня зрелости.

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

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

Это становится возможным, если использовать принципиально новый класс решений — Application Security Orchestration and Correlation (ASOC). Продукт данного класса мы и предлагаем отрасли. Он получил название МТС RED ASOC.

Сергей Деев: Как следует из названия, в ASOC есть два ключевых механизма: оркестрация и корреляция. Оркестрация — это своего рода управление большим «оркестром», составленным из разных инструментов анализа защищенности ПО. Она обеспечивает высокую автоматизацию выполнения проверок и удобство управления этим процессом, минимально влияя на запуск проверяемой программы в коммерческую эксплуатацию — Time to market.

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

Однако каждый из множества этих инструментов проверки формирует набор отчетных данных в своем собственном формате. Бывает даже так, что различные инструменты находят одну и ту же уязвимость, но интерпретируют ее по-разному. Здесь помогает механизм корреляции: она дает возможность свести данные из разных источников в некоторый единый формат и предоставить аналитику информационной безопасности в едином интерфейсе. Это экономит много времени аналитиков и дает возможность формировать более качественную статистику по уровню защищенности приложений от релиза к релизу.

Сергей Деев: Подчеркну, что MTC RED ASOC не просто управляет сторонними инструментами, но и содержит в своем составе ряд анализаторов защищенности ПО. На текущий момент базовым минимумом таких инструментов считаются анализаторы SAST, DAST и SCA/OSA. При этом их внедрение в сборочную инфраструктуру организации, как правило, происходит поэтапно. По нашему опыту, в первую очередь внедряются SAST и SCA/OSA, и уже затем происходит внедрение DAST.

Таким путем мы и решили пойти, развивая нашу платформу: в наш первый релиз уже включены SAST и SCA/OSA, которые управляются с помощью нашего ASOC. А в новых релизах в виде обновления мы также добавим DAST, без увеличения стоимости решения для заказчиков.

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

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

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

Сегодня платформа МТС RED ASOC предназначена для использования в формате on-premise: заказчики могут установить ее в своей инфраструктуре и управлять ею совершенно самостоятельно, взаимодействуя с нами только по линии техподдержки. Однако на рынке есть запрос на облачное решение, которое подойдет любым компаниям, в том числе не имеющим либо необходимых ресурсов, либо достаточных компетенций для установки решения подобного класса во внутреннем контуре и его эксплуатации. Тогда компании будет достаточно подключиться к нашему облаку и получать оттуда все данные аналитики уязвимостей. Это задача для нас на ближайшие пару лет.

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

Сергей Деев: Да, вопрос выпуска на рынок уникальных продуктов теснейшим образом связан с командой, которая их разрабатывает и выстраивает бизнес. Команду МТС RED составляют, в основном, опытные высокопрофессиональные специалисты, которые имеют многолетнюю практику работы в отрасли, причем, во всех сферах, включая собственно разработку инструментов и запуск различных сервисов и услуг кибербезопасности, менеджмент и управление бизнесом, маркетинг.

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

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

Еще один важный тренд — формализация требований регуляторов в вопросах безопасной разработки. В рамках ТК 362 при ФСТЭК России активно развиваются и готовятся к утверждению ряд стандартов, призванных детализировать требования к применению инструментов анализа защищенности ПО и процессу внедрения практик безопасной разработки. По прогнозам, использование данных стандартов может стать обязательным для компаний-лицензиатов ФСТЭК России на разработку средств защиты информации и для разработчиков ПО, которое будет применяться в объектах критической инфраструктуры. В ближайшее время могут быть выпущены соответствующие поправки в нормативно-правовые акты, регулирующие вопросы информационной безопасности в данных сферах.

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

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