Проведение анализа уязвимостей программного обеспечения по требованиям к оценочному уровню доверия (ОУД) по требованиям ЦБ РФ

Анализ уязвимостей по требованиям ОУД 4

Программное обеспечение, для которого требуется проведение анализа уязвимостей по требованиям ОУД 4:

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

1 января 2020 год – установленный срок выполнения требований для проведения анализа уязвимостей по требованию к оценочному уровню доверия (Положения № 683-п, № 684-п).

Несмотря на то, что ЦБ в своем письме № ИН-014-56/105 от 31 декабря 2019 г. сообщает о том, что считает целесообразным применять к кредитным организациям меры за несоблюдение указанных требований только с 1 июля 2020 года, времени на реализацию данного требования с учетом намерений ЦБ крайне мало.

Почему анализ уязвимостей, а не сертификация?

Хотя Положения ЦБ позволяют финансовым организациям выбрать один из двух вариантов реализации данного требования:

1) сертификация в системе ФСТЭК;

2) проведение анализа по требованиям к оценочному уровню доверия (не ниже ОДУ-4).

Проходить сертификацию в системе ФСТЭК нецелесообразно, так как:

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

Что необходимо для проведения анализа уязвимостей по требованиям ОУД

При проведении анализа уязвимостей по требованиям ОУД нашим специалистам необходим следующий пакет документов и программных компонент:

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

1. Общий вердикт по анализу уязвимостей «положительный» тогда и только тогда, когда все составляющие вердикта положительные.

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

2. Отсутствие полного комплекта документов на программное обеспечение.

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

Хотелось бы обратить Ваше внимание на тот факт, что значительную часть сведений, необходимых для формирования финальных документов, должен представить разработчик программного обеспечения. Это связано с тем, что для выполнения требований семейства национальных стандартов ГОСТ Р 15408 при разработке документов необходимо погрузиться в архитектуру и реализацию программного продукта на достаточно глубокий уровень.

А объем сведений, которых необходимо запросить у Разработчика, достаточно значительный, что не позволяет в принципе выполнять подобные работы «под ключ». По этой причине мы не видим другого варианта взаимодействия по разработке документов для ОУД, кроме как разработки проектов данных документов.

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

3. Отсутствует документация по безопасной разработке.

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

Ответы на часто задаваемые вопросы.