В каком разделе профиля защиты содержится аннотация и идентификация

Начало тут…

Вернемся к тому требованию, которое через полтора месяца вступят в силу для финансовых организаций:

Кредитные организации должны обеспечить использование для осуществления банковских операций прикладного программного обеспечения автоматизированных систем и приложений, распространяемых кредитной организацией клиентам для совершения действий в целях осуществления банковских операций, а также программного обеспечения, обрабатывающего защищаемую информацию на участках, используемых для приема электронных сообщений, к исполнению в автоматизированных системах и приложениях с использованием информационно-телекоммуникационной сети “Интернет” (далее – сеть “Интернет”), сертифицированных в системе сертификации Федеральной службы по техническому и экспортному контролю на соответствие требованиям по безопасности информации, включая требования по анализу уязвимостей и контролю отсутствия недекларированных возможностей, или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия (далее – ОУД) не ниже чем ОУД 4 в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013

В формулировке этого требования есть, как минимум, два неясных момента:

1. Какие именно автоматизированные системы и приложения имеются в виду?
2. В чем именно должен заключаться анализ их уязвимостей?

В первом пункте путаницу вносит обычная беда канцелярита – причастный оборот после однородных существительных в множественном числе (“системы и приложения, распространяемые”): поди разберись, относится этот оборот ко всем существительным или только к последнему. Но в данном случае здравый смысл подсказывает, что свою автоматизированную систему банк ну никак не может “распространять” – он может только предоставлять доступ к ней. Таким образом, под это требование подпадают три вида объектов, используемых для выполнения банковских операций:

• программное обеспечение АБС;
• приложения, распространяемые клиентам;
• программное обеспечение, используемое для приема электронных сообщений от клиентов.

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

• Попадают ли в первую категорию все автоматизированные банковские системы, используемые в платежных процессах банка? Некоторые комментаторы считают, что в эту категорию попадают только фронтэнды АБС, непосредственно доступные из сети Интернет, хотя из формулировки это никак не следует.
• Относятся ли куда-нибудь скрипты веб-интерфейса ДБО, исполняемые в браузере клиента?
• Относится ли это требование к программному обеспечению банкоматов?

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

Частичную ясность вносит проект профиля защиты для прикладного программного обеспечения автоматизированных систем и приложений, который уже дважды рассматривался в техническом комитете №122 и который ЦБ намеревается принять до конца этого года. Профиль защиты – это специализированный документ, разработка которого предусматривается Общими Критериями для тех случаев, когда нужно установить какие-то единые требования для определенного вида информационных систем или средств защиты. Документ объемный (более 150 страниц), его чтение требует навыка работы с Общими Критериями, и, к сожалению, требования таких документов не всегда правильно интерпретируются неспециалистами.

Что подпадает под действие профиля защиты

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

• Объект оценки используется “на технологических участках передачи и приема первичных документов (содержащихся в электронных сообщениях) к исполнению финансовой организацией с использованием сети Интернет”
• Объект оценки или устанавливаются в изолированном сегменте сети банка, “сопряженном с сетью Интернет” (т.е. является фронтэндом информационно системы банка) или устанавливается на устройствах клиента (т.е. является клиентским приложением, которое используется для взаимодействия с информационными системами банка в ходе платежного процесса).

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

И, наверное, также стоит подчеркнуть, что определение объекта оценки, данное в профиле, не уточняет область действия положений Банка России. Если в положении Банка России говорится об АБС, используемых в платежном процессе, а в профиле защиты – о фронтэндах этих АБС, то это означает только то, что профиль применим лишь к части области действия положений ЦБ.

Что такое “функциональные требования безопасности” и почему они такие странные

Основное назначение профиля защиты – установить обязательные условия, без выполнения которых объект оценки не сможет успешную пройти оценку соовтетствия. Согласно процедуре, при такой оценке (в том числе – сертификации) по ГОСТ 15408 разработчик сам решает, какие функции безопасности своего продукта заявить и какими именно свидетельствами обосновать доверие к реализации этих функций. Для этого он разрабатывает специальный документ “задание по безопасности”, в котором функции безопасности описываются как набор стандартизованных “функциональных требований безопасности”, а свидетельства доверия и порядок их оценки – как набор стандартизованных “требований доверия к безопасности”. Функциональные требования и требования безопасности по-возможности принято брать из частей 2 и 3 ГОСТ 15408, но при необходимости стандарт разрешает придумывать из самостоятельно.

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

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

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

ФБО должны обнаруживать, когда произойдет [выбор: [назначение: положительное целое число]; устанавливаемое администратором положительное целое число в пределах [назначение: диапазон допустимых значений] ] неуспешных попыток аутентификации, относящихся к [назначение: список событий аутентификации].

В переводе на человеческий язык это функциональное требование означает: “Разработчик должен определить, какие именно события считаются неуспешными попытками аутентфикации (третья по счету операция “назначение”), и объект оценки должен реагировать на заданное количество таких событий. Это количество может задаваться, по усмотрению разработчика (операция “выбор”), или как прописанное хардкодом положительное целое число (первая операция “назначение”), или как настраиваемое администратором значение из заданного разработчиком диапазона (вторая операция “назначение”)”.

После того, как разработчик сделает выбор и назначения, требование может, например, принять вид: “ФБО должны обнаруживать, когда произойдут три неуспешные попытки аутентификации, относящиеся к некорректному вводу имени пользователя или некорректному вводу пароля пользователя”, – и уже в таком виде попасть в задание по безопасности.

Анализ уязвимостей в соовтетствии с профилем защиты

Как человека, зарекшегося заниматься сертификацией (спасибо нашей команде сертификаторов, успешно справляющимся с этой задачей), меня больше интересует, как в профиле защиты раскрывается вопрос анализа уязвимостей. Напомню, нормативные документы ЦБ ссылаются на ГОСТ 15408-3, а в этом документе ничего вразумительного по этому поводу нет. Зато есть в профиле защиты – за это отвечают три компонента доверия:

• “ADV_ARC.1 Описание архитектуры безопасности”
• “ADV_IMP.2 Полное отображение представления реализации ФБО”
• “AVA_VAN.5 Усиленный методический анализ”

Причем основная ценность профиля защиты даже не в самих этих компонентах доверия (они, как положено, просто скопированы из ГОСТ 15408-3), а в замечаниях к их применению.

Как я уже писал ранее, компонент доверия ADV_ARC.1 требует, чтобы разработчик продемонстрировал, что объект оценки защищен от вмешательства нарушителя в момент своего запуска (элемент ADV_ARC.1.3C) и в ходе своей работы (элемент ADV_ARC.1.4C), а также что нарушитель не может обойти механизмы защиты (элемент ADV_ARC.1.5C). Для этого разработчик должен самостоятельно провести анализ уязвимостей своего продукта и предоставить его результаты оценщику). В тексте ГОСТ 15408-3 прямого указания на это нет, поэтому в профиле защиты, в замечаниях к применению этого компонента доверия, дана явная ссылка на пункт 10.3.1 ГОСТ 18045, где подробно описывается, что как именно должны быть обоснованы невмешательство и невозможность обхода.

Компонент доверия ADV_IMP в исходном тексте Общих Критериев не определен (“Общее руководство отсутствует; за консультациями по выполнению данного подвида деятельности следует обращаться в конкретную систему оценки.” – ГОСТ 18045, п. 10.5.2), поэтому в профиле защиты он определен “с нуля” замечаниями по применению. Если вкратце, от разработчика (именно от разработчика, не от оценщика) требуется:

1. Провести code review
   • Убедиться, что программный код соответствует стандартам качества, установленным разработчиком.
   • Убедиться, что код полностью документирован
   • Убедиться, что отдельные программисты не пытались включать код явные недекларированные возможности и не пытались обфусцировать код там, где обфускация не была санкционирована руководством
2. Провести статический анализ кода с использованием автоматизированных средств

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

Результаты анализа должны быть переданы оценщику вместе с исходными кодами для независимой проверки.

В замечаниях к применению компоненте доверия AVA_VAN.5 авторы профиля защиты сделали то, что профильный комитет ISO так и не смог сделать за двадцать лет своей работы – расписали, в чем же именно должен заключаться анализ уязвимостей 🙂 И снова, именно разработчик должен:

• Провести анализ известных уязхвимостей, опираясь на БДУ ФСТЭК, CVE, бюллетени вендоров, уведомления ФинЦЕРТ и т.п.
• Провести анализ типовых уязвимостей веб-интерфейсов методом “черного ящика”
• Провести динамический анализ кода, ориенртируясь на выявление типовых уязвимостей, предусмотренных классификатором CWE
• Провести тестирование на проникновение (при этом определен минимально-необходимый состав проверок, включающий в себя как внешний, так и внутренний пентесты

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

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

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

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