Второй блок статей из серии «Три кита РБПО» посвящен технологиям и инструментам динамического анализа программного обеспечения. На первый взгляд интуитивно понятное определение «динамический анализ» на практике оказывается одним из самых «крепких орешков» при выборе подходов и инструментов динамических исследований программного обеспечения.

Определение их применимости и достаточности, в условиях ограниченности ресурсов (и кадров), с учетом необходимости выполнения регуляторных требований, является типовой задачей, регулярно решаемой как разработчиками ПО, так и специалистами в области ИБ и РБПО, в том числе сотрудниками испытательных лабораторий. В статье приведен обобщенный взгляд на существующие технологии динамического анализа (далее – ​ДА), требования и особенности их применения. Цель статьи – ​подготовить читателя к последующему знакомству с конкретными инструментами динамического анализа, помочь в определении их полезности и применимости.

Раздумывая несколько месяцев над наполнением статьи, я в очередной раз столкнулся с обозначенной в аннотации проблемой. Казалось бы тривиальный в понимании термин «динамический анализ», или, в соответствии с ГОСТ Р 56939-2024 [1] «динамический анализ кода программы», определяемый как «вид работ по инструментальному исследованию программы, основанный на анализе кода программы в режиме непосредственного исполнения (функционирования) кода», на самом деле не дает ответа на большую часть практических вопросов, возникающих у исследователя, которому поставлена задача по проведению ДА. Пытаться ответить на них все единолично в рамках одной небольшой статьи, еще и в формате стройной, формально-выверенной картины – задача заведомо нерешаемая. Поэтому решено действовать другим – уже проверенным в предшествующих материалах [2] – способом, а именно перечислить типовые вопросы, с которыми уважаемые разработчики периодически «влетают» в эксперта испытательной лаборатории, а также некоторые апробированные временем и практикой тезисы ответов.   

Динамический анализ это же DAST?

Мой «любимый» тезис, регулярно всплывающий при общении с представителями разработчиков и исследователей безопасности кода. Сильно упрощая, для большого числа инженеров-безопасников ДА примерно тождественен «походить по API c помощью условного OWASP Zap» [3]. Действительно, являясь одним из полезных и распространенных видов ДА, комплекс подходов и инструментов анализа, в обиходе известный как DAST, сконцентрирован в первую и основную очередь на анализе API (в первую очередь в отношении web-фреймворков). Данный комплекс, как правило, ориентирован на поиск известных уязвимостей – как составляющих API компонентов, так и безопасности их конфигураций – либо, на выявление «нехороших» API (Shadow, Orphan и Zombie [4]) и их параметров. Практики и инструменты DAST в наибольшей степени применимы при работе команд пентестеров (Red Team), а также при создании и постоянном контроле защищенности микросервисных (зачастую разрабатываемых в парадигме API-First) приложений, по своей природе предполагающих частые внесения изменений. Тем не менее вышеуказанные практики составляют только подмножество существующих и требуемых в ряде случаев практик ДА. 

Что требует и что не требует ФСТЭК России, когда упоминает динамический анализ?

Дискутируя с коллегами, мы, как правило, делим РБПО-практики на «вширь» и «вглубь» [5]. «Вширь» определяется ГОСТ Р 56939-2024, в котором вводятся 25 процессов, составляющих комплексный процесс РБПО, при этом сами описания процессов достаточно верхнеуровые и зачастую оставляют на усмотрение разработчика выбор инструментов и детали (в т. ч. численные критерии) реализации процессов. «Вглубь» – а именно более конкретные требования к технологическим возможностям инструментов и численные критерии – определяется Методикой выявления уязвимостей и недекларированных возможностей в ПО ФСТЭК России [6], доступной для использования в работе лицензиатам ФСТЭК России, а также частично приказом №76 ФСТЭК России «Требования, устанавливающие уровни доверия...».

В область требуемых практик ДА с точки зрения Методики (для испытаний по 4 – самому типовому – уровню контроля) попадают как минимум:

• функциональное тестирование (иначе: «пользовательское» тестирование функций безопасности);
• модульное тестирование (основным доп. требованием которого является запуск тестов с комплектами датчиков срабатывания ошибок в тех случаях, когда это применимо);
• генетическое фаззинг-тестирование (о нем ниже);
• комплексный сбор информации об объекте в динамике оценки, совмещенный с тестированием на проникновение (на пальцах этот процесс можно охарактеризовать как совмещение практик DASTи анализа в песочнице);
• а также ряд специальных практик, таких как динамический анализ потоков распространения чувствительных данных (в т. ч. полносистемный).

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

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

Также процессы определения поверхности атаки (процесс №7) и нефункционального тестирования (процесс №19) не требуют, но подразумевают использование различных, характерных для ДА, подходов.

29 сентября в Госдуму внесли законопроект с поправками в Налоговый кодекс, предусматривающими исключение подпункта 26 ст. 149, который освобождает от НДС операции с софтом и базами данных, входящими в единый реестр российского ПО.

Комментируя это, глава Минцифры Максут Шадаев отметил, что ИТ-сектор всё же остаётся на особом положении: «Да, в условиях существующих бюджетных ограничений подтверждаю наличие согласованных планов по увеличению для ИТ-компаний тарифов на страховые взносы с 7,6% до 15% на оплату труда по году до предельной базы (2,76 млн руб.) и отмену льготы по НДС на покупку ПО из реестра <…> Сейчас общая ситуация действительно непростая — планируется общее увеличение НДС и отмена целого ряда льгот для малого бизнеса. Но даже в этих сложнейших условиях Правительство продолжает курс на поддержку ИТ‑отрасли, тарифы на страховые взносы для ИТ‑компаний будут в два раза ниже, чем для предприятий в других отраслях экономики, будут сохранены льготы по налогу на прибыль, льготная ипотека в регионах и отсрочка от военной службы».

Упомянутые поправки затрагивают страховые взносы: со следующего года их ставка составит 15% от фонда оплаты труда, а суммы, превышающие единую предельную величину базы для исчисления взносов (2,98 млн руб. на работника в год), будут облагаться по ставке 7,6%.

Изменения коснутся и налога на прибыль — для аккредитованных ИТ‑компаний он устанавливается на отметке 5%. При расчёте сохраняются льготы: повышающий коэффициент 1,5 при учёте расходов на отечественные оборудование и софт, а также включение расходов на внедрение ПО в инвестиционный вычет. Для всех остальных — ставка 25%.

Наконец, в законопроекте говорится, что с 2026-го продажа программ облагаться НДС по ставке 22% (с 2021 года действовала нулевая ставка для решений, включённых в реестр, и сохранялся зачёт входящего НДС, который для разработчиков обычно был незначителен).

Источники Reuters утверждают, что австрийская Raiffeisen Bank International вновь не смогла согласовать продажу своего российского бизнеса, потому что «смена владельца приведёт к введению санкций против банка».

«Райффайзенбанк» остаётся последним каналом для расчётов между Россией и европейскими странами, и по данных тех же собеседников журналистов, компания только в текущем году обработала «газовых» платежей за поставки по «Турецкому потоку» на сумму 3,8 млрд долларов.

RBI заявила о планах уйти из РФ ещё в 2022 году, но процесс затянулся из-за запрета на сделки с долями в уставном капитале 45 банков без разрешения правкомиссии. Годом позже, после инициированной Минфином США проверки и прямого требования ЕЦБ покинуть российский финсектор, холдинг предложил продать активы или вывести их из контура группы, а работу с частными и корпоративными клиентами в стране — ограничить.

Прошлым летом RBI допустила продажу только 60% местного бизнеса, а в этом апреле даже решила приостановить процедуру «на фоне возобновления Москвой и Вашингтоном политического взаимодействия».

Национальные агентства по кибербезопасности семи стран, включая членов альянса «Пяти глаз», выпустили новое руководство по безопасности операционных технологий (OT). Оно адресовано ИБ-специалистам, работающим в организациях, которые внедряют или эксплуатируют оборудование и системы OT.

«Системы ОТ обеспечивают электроснабжение, подачу воды, работу производственных линий и функционирование наших критически важных служб. Когда эти системы скомпрометированы или выходят из строя, реальные последствия сказываются на безопасности, операционной деятельности, экономике и даже на национальной устойчивости», — предупредил в публичном заявлении представитель Национального центра кибербезопасности Великобритании (NCSC), одного из семи подписантов.

Документ содержит подробное описание конкретных действий, которые следует предпринять для эффективного применения принципов укрепления безопасности OT. В руководстве упомянут и основанный на этих принципах подход, призванный помочь организациям создать и вести «окончательный отчёт» (definitive record) об их ОТ-среде.

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

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

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

Усам Оздемиров

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

Ведомство уточнило, что в перспективе биометрию можно будет использовать в качестве альтернативы паспорту при регистрации на рейс и непосредственно при посадке в самолёт. Каждый при этом имеет право остаться при «аналоговой» форме.

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

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

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

Также союз уверен, что необходимо закрепить ведомство, ответственное за фиксирование такого рода нарушений, — например, Роскомнадзор. Сейчас регулятор лишь штрафует компании, и эти штрафы идут в бюджет, а сами граждане ничего из затребованных сумм не получают. Более того, люди иногда даже не знают, что их данные утекли. Миссию оповещения страховщики видят справедливым взять на себя или возложить на Национальную страховую информационную систему (НСИС), «дочку» Банка России.

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

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

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