• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

View
 

Static Analysis Technologies Evaluation Criteria - Russian

Page history last edited by Sherif Koussa 5 years, 11 months ago

Translation By:

 

  • Alec Shcherbakov (Astech Consulting)
  • Alexey Markov (NPO Echelon)

 

 

Введение: 

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

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

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

Цель документа не состоит в составлении списка требований, которые должны выполнять все поставщики анализаторов, чтобы их продукт считался «полным» решением. Более того, оценка конкретных продуктов и предоставление результатов такой оценки в рамках проекта SATEC не рассматривается. Проект нацелен на разработку критериев и документации, которые позволят любому пользователю оценить средства статического анализа кода и соответствующие услуги и выбрать продукт, оптимально отвечающий его конкретным требованиям. Специальное издание 500-283, «Анализатор безопасности исходного кода: функциональное описание, версия 1.1», выпущенное институтом NIST, содержит минимальные функциональные требования, предъявляемые к средствам статического анализа кода. Этот документ можно скачать со страницыhttp://samate.nist.gov/index.php/Source_Code_Security_Analysis.html.

 

Целевая группа: 

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

 

Область применения:

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

 

Участники:

Aaron Weaver (Pearson Education)

Abraham Kang (HP Fortify)

Alec Shcherbakov (AsTech Consulting)

Alen Zukich  (Klocwork)

Arthur Hicken (Parasoft)

Amit Finegold (Checkmarx)

Benoit Guerette (NorthSec)

Chris Eng (Veracode)

Chris Wysopal (Veracode)

Dan Cornell (Denim Group)

Daniel Medianero (Buguroo Offensive Security)

Dinis Cruz (SecurityInnovation)

Gamze Yurttutan

Herman Stevens

Janos Drencsan

James McGovern (HP)

Jean-Marc Atchison (Centauri Technologies))

Jim Manico (WhiteHat Security)

Joe Hemler (Gotham Digital Science)

Jojo Maalouf (Hydro Ottawa)

Laurent Levi  (Checkmarx)

Mushtaq Ahmed (Emirates Airlines)

Ory Segal (Akamai)

Philippe Arteau

Sherif Koussa (Software Secured) [Project Leader]

Srikanth Ramu (University of British Columbia)

Romain Gaucher  (Coverity)

Sneha  Phadke (eBay)

Wagner Elias (Conviso)

 

Контакты:

Участиев проекте Static Analysis Technologies Evaluation Criteria открытодлявсехжелающих. По всем вопросамотносительно критериев оценки просьба обращаться к руководителю проекта Sherif Koussa ( sherif dot koussa at gmail dot com).


Критерии:
 

1. Развертывание:

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

 

1.1. Модель развертывания:

Поставщики предоставляют технологии статического анализа кода в соответствии с одной или обеими моделями, описанными ниже:

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

Технологии SaaS («Программное обеспечение в виде услуги») : Пользователи предоставляют исходный или бинарный код своих приложений поставщику, который проводит сканирование и возвращает пользователям окончательные результаты.

В настоящем документе настольные технологии статического анализа кода будут называться «инструментами», а SaaS-технологии –  «услугами». В документе термин «технология» может быть использован для обозначения как настольных инструментов, так и SaaS-услуг.

 

1.2. Поддержка установки инструмента:

Инструмент статического анализа кода должен предоставлять следующее:

• Руководство по установке: конкретные инструкции по установке инструмента и его подсистем, если таковые имеются (например, плагины IDE), в т.ч. минимальные требования по аппаратным средствам и программному обеспечению.

• Руководство по применению: конкретные четкие инструкции по настройке и работе с инструментом и его подсистемами.

• SaaS-услуги: поскольку SaaS-услуги не требуют загрузки или установки, поставщик должен предоставить следующее:

            ◦ Четкие инструкции по подготовке к работе.

            ◦ Ожидаемое время обработки с момента представления кода до момента получения результатов.

            ◦ Меры обеспечения конфиденциальности в отношении представленного исходного или бинарного кода, а также отчетов.

 

1.3. Архитектура развертывания:

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

• Тип развертывания: серверное или клиентское, поскольку это может потребовать изменения уровня доступа или покупки дополнительных аппаратных средств.

• Возможность одновременного проведения нескольких сеансов сканирования.

• Возможности инструмента по ускорению сканирования (например, возможность объединять несколько машин, возможность использовать многопоточную/ многоядерную среду и т.д.)

• Возможности инструмента по масштабированию, позволяющие при необходимости сканировать несколько приложений.

 

1.4. Зависимости установки и времени выполнения:

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

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

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

• Динамический анализ: ситуация, когда инструмент или услуга используются для анализа данных, собранных в процессе выполнения кода или приложенияв реальном времени (или в моделируемых условиях).

 

2. Поддержка технологии:

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

 

2.1 Поддержка стандартных языков:

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

 

2.2. Поддержка среды программирования:

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

Способность инструмента или услуги понимать как функционируют структуры ПО (такие как Struts, Spring, Rail и т.д.), проводить анализ данных на основании фактического потока данных, и отслеживать «загрязненные» (tainted) данные, передаваемые между приложением и структурой.

Способность инструмента или услуги соединять клиентские трассировки (например, скрытое поле, и т.п.) с серверными трассировками (например, параметры).

Способность инструмента или услуги определять, использует ли приложение структуру опасным способом.

Способность инструмента или услуги идентифицироватьизвестные уязвимости, указанные в CVE (Список распространенных уязвимостей и незащищенностей).

 

2.3. Поддержка настройки конфигурации технологии:

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

• Переопределение файлов конфигурации: позволяет инструменту более эффективно просматривать файлы с нестандартными расширениями (например, *.ini, *.properties, *.xml, и т.п.) в качестве файлов конфигурации.

• Расширение карты языков: способность расширять область применения инструмента за счет включения нестандартных расширений файла исходного кода. Например, JSPF-файлы являются файлами фрагментов JSP-файлов, и могут быть обработаны аналогично JSP-файлам. Аналогично, HTC-файлы являются файлами фрагментов HTM-файлов, и могут быть обработаны аналогично HTML-файлам. PCK-файлы являются пакетными файлами Oracle, содержащими скрипт PL/SQL. Несмотря на то, что инструмент не обязательно должен распознавать все нестандартные расширения, он должен содержать функцию, позволяющую добиться распознавания этих расширений путем сопоставления нестандартных расширений со стандартными.

 

3. Поддержка сканирования, команд и управления:

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

 

3.1. Поддержка командной строки:

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

 

3.2. Поддержка интеграции с интегрированными средами разработки (IDE):

Пользователь должен предоставить список IDE (и версий), поддерживаемых оцениваемой технологией, с указанием способа сканирования с помощью IDE (например, какие именно объекты будут сканироваться). Например, выполняет ли плагин Eclipse сканирование файлов JavaScript и файлов конфигурации, или только сканирование файлов Java и JSP.

 

3.3. Поддержка системы сборки:

Как правило, различные организации используют технологии статического анализа различным образом. Некоторые организации проводят сканирование кода в рамках ежедневной системы сборки. Поставщик должен предоставить список поддерживаемых систем сборки и их версий (Ant, Make, Maven, и т.д.). Кроме того, поставщик должен указать, какие именно объекты будут сканироваться.

 

3.4. Пользовательская настройка по заказу:

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

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

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

• Пакетирование правил: Способность пакетировать правила и запускать выбранные пакеты правил.

• Выборочное сканирование: Способность запускать (повторно запускать) сканирование для определенного типа уязвимости.

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

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

 

3.5. Возможности конфигурации сканирования:

Возможности конфигурации сканирования указаны ниже:

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

Возможность просматривать статус сканирования в реальном времени: поскольку иногда сканирование занимает несколько часов, для пользователя удобно и желательно иметь возможность просматривать статус сканирования и слабые места, выявленные на текущий момент. Для SaaS-услуг поставщик должен обеспечить точный расчетный срок предоставления результатов.

Возможность сохранять конфигурации для повторного использования в качестве шаблонов: Часто значительное количество времени и усилий затрачивается на оптимальную настройку конфигурации инструмента статического анализа кода для конкретного приложения. Поэтому инструмент должен предоставлять возможность сохранять конфигурацию сканирования для повторного использования в качестве шаблона.

Возможность проводить несколько сканирований одновременно: Для организаций, которым требуется сканировать большое количество приложений, возможность одновременного проведения нескольких сканирований является желательной.

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

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

Возможность перенастраивать местоположение исходного кода: Возможность перенастраивать местоположение исходного кода после сканирования актуальна для ситуаций, при которых сканирование выполняется на одной машине, а результаты просматриваются на другой машине.

 

3.6. Возможности тестирования:

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

• Некорректное использование API

• Неверная конфигурация приложения

• Опция Auto-complete не устновлена для поля содержащего пароль

• Переполнение буфера

Внедрение команд

Прогнозирование пароля/ сеанса

• Межсайтовый скриптинг

Отказ в обслуживании

Повышение уровня привилегий

• Ненадежность криптографических средств

• Форматирующая строка

• Жестко закодированные пароли

Разбиение HTTP-ответа

• Некорректная обработка входных данных

• Некорректное кодирование выходных данных

• Утечка информации

• Ненадежное кэширование данных

• Незащищенная загрузка файла

• Недостаточная блокировка учетной записи

• Недостаточная аутентификация

• Недостаточная авторизация

• Недостаточная / ненадежная схема входа в учетную запись

• Недостаточные требования, предъявляемые к сложности пароля

• Недостаточные требования, предъявляемые к истории паролей

• Недостаточная схема выхода из сеанса

• Переполнение целых чисел

Внедрение LDAP

Внедрение команд отправки почты

Внедрение нулевого байта

• Атаки открытой переадресации

Внедрение OS-команд

• Обход пути

• Состояние гонки

• Дистанционное включение файла

Внедрение второго порядка

• Фиксация сеанса

Внедрение SQL

• Некорректное использование URL-переадресации

Внедрение XPATH

• Внешние объекты XML

• Расширение объектов XML

Атаки по внедрению XML

Внедрение XPATH

 

3.7. Анализ на основании отраслевых стандартов:

Сканирование, проводимое на основании отраслевых стандартов, является желательной функцией по многим причинам. Например, списки наиболее распространенных угроз OWASP Top 10, CWE/SANS Top 25, классификация угроз WASC, DISA/STIG и т.п., предоставляют организациям отправные точки для анализа «прорех» в защите программного обеспечения, а в других случаях эти классификации используются в целях измерения минимального соответствия стандартам безопасности.

 

4. Обновление подписей продукта:

Наборы подписей (также известных как правилаи контролеры)в инструментах статического анализа кода используются для выявления слабых мест с точки зрения безопасности. При выборе инструмента статического анализа необходимо учитывать следующие факторы:

 

4.1. Частота обновления подписи:

Возможность частого обновления подписи в инструменте статического анализа кода обеспечивает актуальность инструмента в условиях постоянного появления новых типов угроз. Следовательно, важно получить сведения о следующих аспектах обновления подписи:

• Частота обновления подписи: обновление осуществляется периодически, по требованию, или по специальной подписке, и т.п.

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

 

4.2. Обратная связь с пользователем по вопросам обновления подписей:

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

 

5. Поддержка сортировки по приоритетам и устранения уязвимостей:

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

 

5.1. Результаты в виде метаданных: 

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

Степень серьезности: Степень серьезности выявленного слабого места с указанием способа ee изменения при необходимости.

• Резюме: описание слабого места и соответствующей степени риска для приложения.

• Местоположение: местоположение файла исходного кода и номер строки выявленного слабого места.

• Поток данных: способность отслеживать «загрязненные» данные от источника до конечной точки и обратно.

 

5.2. Управление метаданными:

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

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

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

Инструмент или услуга должны обеспечивать слияние/ дифференцирование результатов сканирования. Эта функция полезна при проведении повторного сканирования приложения: инструмент или услуга должны уметь добавлять результаты второго сканирования к первому.

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

 

5.3. Поддержка рекомендаций по устранению уязвимостей

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

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

 

6. Возможности составления отчетов:

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

 

6.1. Поддержка отчетов, основанных на ролях: 

Инструмент или услуга должны предоставлять следующие типы отчетов с возможностью смешения и сравнения:

Резюме для руководителя: заключительное резюме по результатам сканирования.

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

        ◦ Резюме по проблеме, с указанием категории слабого места.

        ◦ Местоположение проблемы, с указаниемимени файла и номера строки кода.

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

           примерами кода на соответствующем языке.

        ◦ Подробности потока данных, с указаниемпути загрязненных данных от источника до конечной точки

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

OWASP Top 10

Классификация угроз WASC

СписокCWE/SANS Top 25

СтандартSarbanes-Oxley (SOX)

Отраслевой стандарт безопасности данных на платежных карточках (PCI DSS)

Закон об ответственности и переносе данных о страховании здоровья граждан (HIPAA)

Закон Грэма-Лича-Блили (GLBA)

Стандарт NIST 800-53

Федеральный закон об управлении информационной безопасностью (FISMA)

Закон о защите персональной информации и электронных документах (PIPEDA)

Стандарт Basel II

6.2. Пользовательская настройка отчетов:

Инструмент или услуга должны поддерживать пользовательскую настройку отчетотв. Инструмент или услуга должны обеспечивать следующие возможности:

• Возможность включать в отчеткомментарии аудитора о результатах.

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

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

 

6.3. Форматы отчетов:

Поставщик должен представить список поддерживаемых форматов отчета (PDF, XML, HTML и т.д.)

 

7. Поддержка на уровне предприятия: 

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

 

7.1. Интегрирование технологии в системы отслеживания ошибок:

Поставщик должен предоставить список поддерживаемых систем отслеживания ошибок, в частности, поставщик должен определить следующие критерии:

• Способ, с помощью которого инструмент или услуга интегрируется в системы отслеживания ошибок, например, прямые запросы API, экспорт CSV, и т.д.

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

 

7.2.  Интегрирование технологии в системы управления рисками на уровне предприятия:

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

• Технология, используемая для интегрирования.

• Наличие возможности определения критериев для осуществления интегрирования в системы управления рисками на уровне предприятия.

 

7.3. Возможность объединения проектов:

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

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

 

7.4. Схема лицензирования:

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

Факторы схемы лицензирования:

       ◦ Лицензия на определенный объем сканирования (оплата за строку): стоимость лицензии зависит от количества сканируемых строк кода.

       ◦ Лицензия на отдельное приложение: лицензия выдается для конкретного приложения, и она не может быть использована для других                         приложений.

       ◦ Подписки на определенный срок: одно или несколько приложений можно сканировать неограниченное количество раз до истечения срока               действия лицензии.

       ◦ Лицензия на отдельного пользователя: лицензия выдается для отдельного пользователя, обычно данный тип лицензии используется в                       сочетании с одной или несколькими другими схемами.

       ◦ Неограниченные/бессрочные лицензии: лицензия выдается для сканирования неограниченного количества приложений неограниченным                 количеством пользователей.

       ◦ Затраты на сервер: для моделей клиент-сервер.

• Способы контроля схемы лицензирования:

       ◦ Сервер с лицензиями: специально выделенный сервер, на котором хранятся лицензии и к которому могут получить доступ пользователи                   сети.

       ◦ Местная блокировка: Лицензия привязана к конкретному типу ОС, конкретной машине или именованному пользователю.

       ◦ Блокировка по имени пользователя: Лицензия привязана к конкретному имени пользователя.

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

       ◦ Трастовая или договорная лицензия: предполагается, что схема лицензирования,упомянутая в договоре, соблюдается пользователем без                   дополнительных мер контроля.

 

Приложение A: Памятка для подготовки информации о статическом анализе кода:

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

• Список языков программирования, используемых в организации.

Список структур и библиотек, используемых в организации.

Список лиц, которым будет поручено проведение сканирования

• Способ интегрирования инструмента или услуги в жизненный цикл программного обеспечения

• Способ просмотра результатов сканирования разработчиками ПО

• Средства, выделенные на приобретение технологии, включая аппаратное обеспечение (при необходимости)

Решение о допустимости сканированияисходного или бинарного кода вне организации.

 

Приложение B: Ссылки

• Классификация угроз WASC (http://projects.webappsec.org/w/page/13246978/Threat%20Classification)

• Критерии оценки сканеров безопасности Web-приложений (http://projects.webappsec.org/w/page/13246986/Web%20Application%20Security%20Scanner%20Evaluation%20Criteria)

• Анализатор безопасности исходного кода: функциональное описание, версия 1.1, NIST (http://samate.nist.gov/docs/source_code_security_analysis_spec_SP500-268_v1.1.pdf)

• Статический анализ программного кода (http://en.wikipedia.org/wiki/Static_program_analysis)

• Список инструментов статического анализа программного кода (http://en.wikipedia.org/wiki/List_of_analyzers_for_static_code_analysis)

 

 

Comments (0)

You don't have permission to comment on this page.