Анализ кода банковских приложений —
от доверия к осознанности и ГОСТу

Банковские организации все чаще задаются вопросом о возможности оперативного и автоматизированного анализа уязвимостей своих приложений

Доверие по ГОСТу

ГОСТ 15408 (он же — «Критерии оценки защищенности информационных технологий», он же — «Общие Критерии» или Common Criteria) предполагает, что разработчик защищенной информационной системы (или отдельного средства защиты, так как обычно этот стандарт используется только в их разработке) заявляет, что:

1. реализовал в ней определенный набор функций безопасности;
2. эти функции действительно работают;
3. нарушитель не может их отключить или обойти.

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

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

Четвертый уровень можно считать средним, сбалансированным. И одним из свидетельств, которым разработчик подтверждает корректность своих заявлений на этом уровне, является предоставление оценщику исходного кода. Одна из мер доверия, которая проверяется на ОУД4 — анализ уязвимостей, мера доверия AVA_VAN.3, определенная в ч. 3 ГОСТ 15408.

Если перевести эти требования на общечеловеческий язык, то разработчик должен:

• описать архитектуру подсистемы безопасности своего продукта (мера доверия ADV_ARC.1). В описании должно быть продемонстрировано, что функции безопасности его продукта невозможно обойти, т.е. что в нем нет архитектурных уязвимостей;
• написать функциональную спецификацию своего продукта (мера доверия ADV_FSP.4). В ней должен быть описан весь API, связанный с реализацией функций безопасности, назначение каждой функции API, способ ее использования, ее параметры, а также описание всех (вообще всех) ошибок, сообщения о которых могут появляться в интерфейсе или в логах, причем с разблюдовкой: вот эти ошибки — результат некорректного срабатывания функций безопасности, а вот эти — не связаны с безопасностью по вот такой причине;
• описать разделение своего продукта на подсистемы, а каждой подсистемы — на отдельные модули (мера доверия ADV_TDS.3). Для каждого модуля, в котором реализуются функции безопасности, должно быть описано, какие функции API он реализует. Для каждой функции безопасности должно быть расписано что-то вроде диаграммы взаимодействия UML — через какие модули и через какие функции API этих модулей идут пути исполнения кода при выполнении функций безопасности;
• передать оценщику всю эту документацию и исходный код продукта.

При этом у оценщика тоже есть ряд обязательств, в частности:

• убедиться, что документация полна и соответствует исходному коду;
• проверить, нет ли для этого продукта уже известных уязвимостей;
• провести анализ документации на предмет потенциальных архитектурных уязвимостей;
• провести анализ исходных кодов на предмет потенциальных 0-day;
• верифицировать все найденные потенциальные уязвимости, проверив вероятность их эксплуатируемости.

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

Как видно из описания, анализ уязвимостей — это большой объем работы по анализу архитектурных уязвимостей и уязвимостей кода. Кстати, при сертификации в системе ФСТЭК проводится точно такая же работа, но она — лишь часть сертификационных испытаний: анализ уязвимостей на ОУД4 — это примерно 1/3 трудозатрат испытательной лаборатории на полноценную сертификацию продукта.

Анализ уязвимостей как обязанность

Как видно из описания, ГОСТ ничего не говорит о том, как именно должны выявляться уязвимости: например, нужно ли проводить для этого динамический анализ кода или достаточно только статики? Такая неопределенность в способах поиска потенциальных уязвимостей не устраивает ЦБ, поэтому «встроенные» требования ГОСТ 15408-3 по анализу уязвимостей расширены в проекте профиля защиты, который сейчас рассматривается в ТК122. Изменения существенны:

• анализ уязвимостей должен проводить разработчик. Оценщик проверяет, что этот анализ разработчиком действительно проводится, а также выполняет независимый анализ уязвимостей, чтобы убедиться, что разработчик не халтурит. Такой подход не избавляет разработчика от самостоятельного анализа уязвимостей;
• добавлены примечания, в которых подробно описано, какими именно способами должны выявляться уязвимости. В частности, прямо указана необходимость проведения статического и динамического анализа исходного кода;
• верификация уязвимостей (она обычно проводится в лабораторных условиях) заменена полноценным тестированием на проникновение в реальных условиях эксплуатации. Требования к тестированию на проникновение взяты из РС БР ИББС 2.6, тем самым переведя описанную там процедуру тестирования на проникновения из рекомендованной в обязательную;
• описаны требования к отчетам об анализе уязвимостей. Именно такими отчетами разработчик (или банк) будет подтверждать аудиторам факт самостоятельного проведения анализа уязвимостей.

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

ОУД 4: что есть что?

В состав мер доверия входит анализ уязвимостей, требования к нему для ОУД4 определены в компоненте доверия AVA_VAN.3. В соответствии с ним оценщик (лицо, которое проводит анализ уязвимостей) должен проделать следующую работу:

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

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

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

Задача анализа непростая и, очевидно, она будет еще сложнее, если ее выполнять без автоматизированных средств инспекции кода – анализаторов защищённости, имеющих в своем арсенале возможность выполнения вышеописанных функций. И совсем нетривиальной она становится, если мы говорим об инспекции кода на всех этапах жизненного цикла разработки ПО и о встраивании такого рода средств в системы Continuous Integration / Continuous Delivery, реализуя тем самым концепцию безопасной разработки программного обеспечения (SDL — Security Develoment Life Cycle).

Соответствие ОУД4 «на автомате»

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

PT Application Inspector (PT AI) – анализатор защищенности, предназначенный для выявления уязвимостей и ошибок в приложениях, поддерживающий процесс безопасной разработки. Он имеет в своем арсенале различные движки анализа: поиск уязвимых библиотек, динамический и статический анализы кода. То есть в продукт «зашиты» технологии, позволяющие искать как известные, так и неизвестные уязвимости (т.н. уязвимости «нулевого дня», 0-day), а по результатам своей работы анализатор выдает отчет в удобном формате, который и будет для аудитора являться свидетельством того, что анализ уязвимостей проводился.

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

И еще одна важная особенность PT AI в контексте анализа по требованиям ОУД4: он позволяет генерить эксплойты (тестовые запросы) для проверки и верификации найденных уязвимостей. Выражаясь языком требований ОУД4, эксплойты позволяют убедиться, что найденными уязвимостями можно воспользоваться.

Таким образом, PT AI решает задачу автоматизации процесса анализа по требованиям ОУД4, а в зависимости от частоты сканирования и объема кода, можно выбрать PT AI в Desktop’ном исполнении или в исполнении Enterprise. Первый решает классическую задачу приемки кода (то есть удобен для разовых проверок). Второй незаменим, когда кода много (поток) и сканировать его приходится почти постоянно. Последний, кстати, идеален для встраивания в среду разработки (CI/CD) и построения процесса безопасной разработки (SDL).

Вывод

При оценке и анализе приложения на соответствие требованиям ОУД4 значительно облегчает задачу использование специализированных средств, автоматизирующих процесс анализа. Одним из них является PT Application Inspector, который позволяет выполнить большинство проверок на соответствие требованиям ОУД4, провести всеобъемлющий анализ уязвимостей банковского приложения. И, что немаловажно, сформировать отчет, подтверждающий, что анализ на наличие уязвимостей проводился (уязвимости при первичном сканировании найдены, даны рекомендации по их устранению, а при повторном сканировании уязвимости устранены). Отчеты по результатам первичного и повторного сканирования снимают многие вопросы, возникающие у аудитора, и сокращают время самих проверок.

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

Смотрите также