Что проверять во время анализа ПО по ОУД4?

Тема анализа безопасности ПО очень обширна и не нова. Специалисты по защите информации, в первую очередь, обеспечивают защиту ПО, которое ее обрабатывает, и проводят много времени за выработкой оптимальных настроек, за поиском ошибок, за написанием инструкций по администрированию и т. д. Эксперты Aktiv Consulting поговорят о том, что необходимо подготовить для проведения анализа ПО. В предыдущем материале мы рассказали, с чего начать процесс анализа программного обеспечения по ОУД4, на что обратить внимание банкам и крупным НФО. В этот раз мы поговорим о том, что необходимо подготовить для проведения анализа ПО. Тема анализа безопасности ПО очень обширна и не нова. Специалисты по защите информации, в первую очередь, обеспечивают защиту ПО, которое ее обрабатывает, и проводят много времени за выработкой оптимальных настроек, за поиском ошибок, за написанием инструкций по администрированию и т.д. Для упорядочивания такой деятельности, да и вообще деятельности по разработке ПО, были созданы различные методологические документы, принятые на международном уровне. Например, серия стандартов ISO 12207 «Процессы жизненного цикла программного обеспечения» (1995), или так называемые «Общие критерии оценки защищенности информационных технологий», ведущие историю с начала 90-х годов и вылившиеся в стандарт ISO 15408 с аналогичным названием. Из более привычных документов есть один из стандартов 27000 серии — ISO 27034 «Безопасность приложений», а для платежных приложений — стандарт PA DSS, разработанный в 2008 году в PCI SSC, и это только часть всего разнообразия подходов к безопасности ПО.

А как у нас?

В нашей стране Банк России остановился на ГОСТ Р ИСО/МЭК 15408 и закрепил это в своих нормативных документах для применения в финансовых организациях (к примеру, в положении 683-П). ГОСТ 15408 достаточно объемен: состоит из 3-х частей, которые вышли в 2013-2014 годах. Это не набор каких-либо конкретных требований для реализации, а фреймворк для оценки безопасности — описание инструментария и процессов для проведения оценки.

Фреймворк

Давайте посмотрим на этот фреймворк верхнеуровнево. Есть объект оценки — это информационная система (ИС). Для объекта в процессе его разработки составляется задание по безопасности, в котором описываются цели безопасности и способы, которыми эти цели достигаются. ГОСТ предполагает, что для составления заданий может использоваться так называемый профиль защиты, в котором уже заранее для различного типа информационных систем (например, для мобильных приложений по переводу денежных средств) подготовлены упомянутые цели безопасности и способы их достижения. Задание по безопасности для конкретной информационной системы содержит ссылку на профиль защиты для такого типа систем и включает в себя набор требований из этого профиля. После окончания разработки ИС проводится оценка соответствия объекта оценки требованиям задания по безопасности. Предполагается, что Банк России разработает и утвердит профиль защиты для типов информационных систем, упомянутых в 683-П/684-П. Таким образом, у финансовых организаций будет конкретный набор требований для применения в своих системах, но на данный момент существует только проект профиля защиты для ПО, осуществляющего дистанционное обслуживание клиентов. Данный профиль был принят на декабрьском заседании ТК122 и в данный момент находится на согласовании во ФСТЭК России. Тем не менее разработанный профиль защиты рассматривает только ПО для дистанционного обслуживания, в связи с чем у многих финансовых организаций возникают вопросы о его применимости к другим типам ПО.

Оценочный уровень доверия

А что же такое оценочный уровень доверия? Терминология ГОСТ говорит, что уровень доверия к системе — это уровень соответствия целям безопасности. ГОСТ описывает 7 таких уровней доверия (ОУД), включающих в себя определенные компоненты для оценки. Таким образом, к ОУД можно относиться как к глубине анализа безопасности ПО — чем выше ОУД, тем более тщательно проводится работа по оценке соответствия и тем больше компонентов ПО подвергается анализу. Формулировки в НПА Банка России ссылаются не целиком на ОУД4, а на анализ уязвимостей не ниже чем в ОУД4. Компоненты ОУД4 включают в себя такие классы оценочных мероприятий как «разработка», «руководства», «тестирование» и другие, в том числе класс «оценка уязвимостей». Соответственно, для выполнения требований Банка России следует смотреть требования к оценке уязвимостей, описанные в ОУД4, а это анализ уязвимостей, демонстрирующий противостояние попыткам проникновения нарушителей, обладающим усиленным базовым потенциалом. Дальнейшая детализация процесса анализа уязвимостей в ГОСТ описывает использование документации на ПО, включая полное проектное описание и исходный код ключевых компонентов. Следующие ОУД предполагают анализ уже всего исходного кода ПО, а не только его ключевых компонентов. После анализа уязвимостей проводится тест на проникновение, чтобы определить возможность эксплуатации выявленных уязвимостей. Таким образом, для проведения анализа уязвимостей по ОУД4 финансовой организации необходимо подготовить:

1. задание по безопасности (по возможности разработанное на основе профиля защиты или его проекта);
2. подробную документацию на компоненты информационной системы, описания API, форматы сообщений, руководства пользователей, администраторов;
3. исходные коды ключевых компонентов.

Ссылка на источник