Инструментальный анализ безопасности приложений. Обзор нормативных требований.

image

Введение

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

Рассмотренные документы разработаны в соответствии с Федеральным законом РФ № 184-ФЗ «О техническом регулировании» Федеральной службой по техническому и экспортному контролю РФ и Центральным банком РФ в пределах их полномочий:

  • ГОСТ «Защита информации. Разработка безопасного программного обеспечения. Общие требования»;
  • ГОСТ Р 51624 «Защита информации. Автоматизированные системы в защищенном исполнении. Общие требования»;
  • ГОСТ Р ИСО/МЭК ТО 20004-2 «Информационная технология. Методы и средства обеспечения безопасности. Детализация анализа уязвимостей программного обеспечения в соответствии с ГОСТ Р ИСО/МЭК 15408 и ГОСТ Р ИСО/МЭК 18045. Часть 2. Тестирование проникновения»;
  • РС БР ИББС-2.6-2014 «Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем».

Помимо документов, выпущенных российскими регулирующими органами, рассмотрен стандарт безопасности платежных приложений (Payment application data security standard, PA DSS), созданный Советом по стандартам безопасности данных в индустрии платежных карт (Payment Card Industry Security Standards Council). Связано это с повсеместным распространением, в том числе и на территории Российской Федерации, сертификации по стандарту безопасности данных индустрии платежных карт (Payment Card Industry Data Security Standard, PCI DSS), который включает в себя требования PA DSS к разработке и эксплуатации приложений, осуществляющих процессинговые операции.

ГОСТ «Защита информации. Разработка безопасного программного обеспечения. Общие требования»

Данный документ принят техническим комитетом по стандартизации «Защита информации» (ТК 362) в окончательной редакции и отправлен на утверждение в Росстандарт. Планируется обязать компании выполнять требования данного стандарта при сертификации в Федеральной службе по техническому и экспортному контролю.

Рассмотрим и прокомментируем отдельные требования документа. Внимание! Комментарии являются авторскими и не имеют юридической силы.

Требование 5.3.3.3
Разработчик ПО должен создать (выбрать) и использовать при создании программы порядок оформления исходного кода программы, содержащий перечень правил и рекомендаций, направленных на устранение недостатков (потенциально уязвимых конструкций) в исходном коде программы.
Комментарий к требованию 5.3.3.3
Упомянутый перечень правил и рекомендаций (порядок оформления) должен регулировать процессы по исправлению потенциально уязвимых конструкций кода; контроль выполнения правил возможно при этом организовать с помощью инструмента анализа исходного кода.

Требование 5.3.3.4
Разработчик ПО должен обеспечить проведение статического анализа исходного кода программы с целью выявления недостатков (потенциально уязвимых конструкций) в исходном коде программы. Статический анализ исходного кода программы следует проводить в отношении компонентов, заимствованных у сторонних разработчиков ПО, для которых доступен исходный код.
Комментарий к требованию 5.3.3.4
Требование в явном виде регламентирует использование статического анализа не только собственного исходного кода, но и заимствованных компонентов. Это говорит о важности применения автоматизированного анализа исходного кода.

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

Требование 5.6.3.4
Разработчик ПО должен проводить систематический поиск уязвимостей программы. Поиск уязвимостей программы следует проводить с использованием моделирования угроз безопасности информации, статического анализа кода программы, экспертизы исходного кода программы, функционального тестирования программы, тестирования на проникновение, динамического анализа кода программы и фаззинг-тестирования программы.
Комментарий к требованию 5.6.3.4
Требование объединяет методы обеспечения безопасной разработки в систематическую процедуру, основанную на модели угроз и экспертном подходе.

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

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

ГОСТ Р 51624 «Защита информации. Автоматизированные системы в защищенном исполнении. Общие требования»

Данный документ принят техническим комитетом по стандартизации «Защита информации» (ТК 362) в окончательной редакции и отправлен на утверждение в Росстандарт. После утверждения планируется сделать требования стандарта обязательными к выполнению для государственных информационных систем.


Требование 6.3.7
При создании (модернизации) и эксплуатации автоматизированной системы в защищенном исполнении (АСЗИ) осуществляются выявление, анализ и устранение уязвимостей.
Работы по анализу уязвимостей в АСЗИ, обновлению ПО, а также выявлению инцидентов безопасности информации и реагированию на них проводятся с учетом национальных и международных стандартов в порядке, установленном в нормативных правовых актах и методических документах уполномоченных федеральных органов исполнительной власти и (или) организационно-распорядительных документах по защите информации в АСЗИ.
Данное требование фактически обязывает разработчиков ПО, чье программное обеспечение используется в государственных информационных системах, выполнять требования ГОСТ «Защита информации. Разработка безопасного программного обеспечения. Общие требования», который, в свою очередь, требует проводить комплексный анализ приложения.

ГОСТ Р ИСО/МЭК ТО 20004-2 «Информационная технология. Методы и средства обеспечения безопасности. Детализация анализа уязвимостей программного обеспечения в соответствии с ГОСТ Р ИСО/МЭК 15408 и ГОСТ Р ИСО/МЭК 18045. Часть 2. Тестирование проникновения»

Нормативный документ практически полностью повторяет стандарт ISO 20004-2 и описывает процедуры, которые должна проводить испытательная лаборатория при сертификации программного обеспечения. Данные требования рекомендуется учитывать при подготовке ПО, чтобы заранее подготовится к сертификации.

Основные аспекты документа:

  • При сертификации по ГОСТ 15408, начиная с ОУД2, испытательная лаборатория производит независимый анализ уязвимостей;
  • Основной метод анализа уязвимостей — динамический анализ с использованием инструментальных средств;
  • Если будут найдены значительные уязвимости, испытания признаются непройденными и продукт отправляется на доработку.

РС БР ИББС-2.6-2014 «Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем»

Для обеспечения должного уровня защиты информации в организациях финансового сектора Банк России разработал нормативный документ РС БР ИББС-2.6-2014, описывающий необходимые меры для обеспечения информационной безопасности автоматизированных банковских систем на всех стадиях их жизненного цикла. В частности, данный документ предъявляет требования по безопасности для программных компонентов, работающих в банковской системе.

Попробуем прокомментировать основные требования документа.

Требование 8.10
Для программных компонентов автоматизированной банковской системы (АБС), реализующих банковский платежный технологический процесс или предназначенных для обработки персональных данных или иной информации, в отношении которой законодательством Российской Федерации или решением организации БС РФ установлено требование об обеспечении безопасности, рекомендуется перед проведением предварительных испытаний осуществлять контроль исходного кода с целью выявления типовых ошибок программирования и иных дефектов, приводящих к возникновению уязвимостей.
Данное требование  рекомендует проведение для банковских приложений анализа исходного кода. При этом требование действует не только в отношении платежных приложений, но и любых других, связанных с персональными данными, банковской тайной или другой чувствительной информацией.

Требование 11.3
Модернизация АБС включает в себя в необходимом объеме стадии разработки технического задания, проектирования, создания и тестирования, приемки и ввода в действие.
Документ предполагает, что к модернизации, как продолжающейся разработке программных компонентов в автоматизированной банковской системе предъявляются те же требования, что и к вновь запускаемым системам, включая требования по анализу защищенности приложения.

Стандарт безопасности платежных приложений (Payment application data security standard, PA DSS)

Стандарт безопасности платежных приложений предназначен в первую очередь для производителей, которые разрабатывают ПО для обработки платежной информации. Стандарт указывает на процессы безопасности, необходимые при разработке ПО для компаний, обрабатывающих критически важные данные, такие как номера счетов, сведения о денежных средствах, персональные данные и т. п. Несмотря на то что документ разработан для производителей, он рекомендуется к использования и для организаций, подпадающих под действие стандарта безопасности данных индустрии платежных карт (PCI DSS): с его помощью рекомендуется проводить аудит ПО, используемого в автоматизированной банковской системе, но не прошедшего сертификацию по PA DSS. Кроме того, стандарт рекомендуется к использованию командами разработчиков, проектирующих и производящих собственное ПО АБС.

Требование 5.1.4
Payment application code is reviewed prior to release to customers after any significant change, to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:
  • Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code-review techniques and secure coding practices.
  • Code reviews ensure code is developed according to secure coding guidelines. (See PA-DSS Requirement 5.2.) ...
  • Code-review results are reviewed and approved by management prior to release.
  • Documented code-review results include management approval, code author, and code reviewer, and what corrections were implemented prior to release.
Стандарт не указывает в явном виде на необходимость инструментального статического или динамического анализа кода, но требует проводить проверку кода на предмет соответствия стандартам безопасной разработки, которые в свою очередь указывают на необходимость применения инструментальных средств анализа исходного кода.