Лабиринт малотавра: ОУД4 для банковских приложений

В последнее время заказчики из банковской сферы все чаще спрашивают, можем ли мы провести анализ уязвимостей их приложений в соответствии с требованиями ОУД4 ГОСТ 15408-3. Связано это со скорым вступлением в силу уже упоминавшихся положений Банка России. К сожалению, при этом заказчики часто слабо представляют, что от них требуется и в чем заключается такой анализ.

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

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

ОУД4 — средний, сбалансированный уровень доверия — он еще не настолько фантастичен, как ОУД7, но уже позволяет не верить разработчику на слово, в отличие от ОУД1. Одним из свидетельств, которым разработчик подтверждает корректность своих заявлений на ОУД4 — исходные коды, которые он должен предоставить оценщику.

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

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

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

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

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

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

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

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