экспертиза исходного кода программы

Экспертиза программного обеспечения, или как мошенники наживаются на госконтрактах

Эта история произошла более 3-х лет назад, поэтому я смело могу снять гриф «коммерческая тайна» и озвучить ее подробности в инет-эфире.
В нашу компанию обратились коллеги из финансово-контрольного управления Министерства Обороны РФ с просьбой провести экспертизу программного обеспечения – «Стенд моделирования аварийных ситуаций в полете». Надо сказать, что коллеги из МО сразу заподозрили подвох в ПО и решили провести независимую экспертную оценку, дабы понять с чем имеют дело, и стоит ли это тех денег, которые были озвучены в госконтракте. А госконтракт был не шуточным, общая стоимость проекта составляла порядка 20 миллионов рублей!

Исходные данные:
Для исследования были получены файлы на flash-носителе общим объемом 2 252 414 699 байт. В корне носителя содержалось две директории: FltRec02; СМ-АС 2006.

Операционная система на исследуемом компьютере: Microsoft Windows XP Professional.
Анализ файлов в директории FltRec02
Объем файлов: 472 899 байт.

Среди всех представленных файлов, загрузочный только один – FLTREC02.exe, который запуску не поддается.

Однако, анализ кода файла показал, что авторские права принадлежат компании Microsoft Corp.

Анализ файлов в директории СМ-АС 2006
Fighter Ace II

Объем директории: 2 251 941 800 байт.

Загрузочный файл FIGHTACE.exe

После запуска файла, на экране появляется окно представленное на рис. 2

Наличие уже введенного защитного «ключа» (см. выделение на рис. 3), свидетельствует о «пиратском» происхождении программного продукта!

После инсталляции и запуска программы в режиме «play», пользователю необходимо пройти регистрацию на сервере официального производителя – Microsoft.

В режиме «training» перед пользователем открывается «тренировочный режим», см. рис. 5 и 6

Вывод: Исследуемое программное обеспечение относится к классу «Компьютерные игры — Симуляторы», разработчиком которого является компания Microsoft Corp., год выпуска 1999, название – Fighter Ace II.

Стоимость программного продукта с учетом «пиратского» происхождения составляет порядка 70 рублей.

Microsoft Flight Simulator 2002

Загрузочные файлы FLTSIM98.exe, FS2000.exe, FS2002.exe

Данные файлы запускают программу «Microsoft Flight Simulator 2002», которая скрывается под заставкой «Стенд моделирования аварийных ситуаций в полете». Компания ЗАО «ХХХХХХ» нарушила авторские права указав себя в качестве разработчика!

Информации о легальном происхождении программного продукта обнаружить не удалось!

Загрузочный файл FSUNINSTALL.exe

Загрузочный файл FSEDIT.exe

Вывод: Исследуемое программное обеспечение относится к классу «Компьютерные игры — Симуляторы», разработчиком которого является компания Microsoft Corp., год выпуска 2002, название – «Microsoft Flight Simulator 2002».

Стоимость программного продукта с учетом «пиратского» происхождения, а также затрат на дизайн заставки (рис. 7) составляет около 200 руб.

Итого, общая стоимость ПО поступившего на экспертизу составляет порядка 270 руб.

В результате проведенной экспертизы, сотрудникам МО было рекомендовано обратиться в военную прокуратуру и контрразведку для проведения расследования!

Источник

Экспертиза разработанного программного обеспечения (ПО)

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

В рамках подхода RTM Group выделяются 2 (две) большие категории экспертиз программного обеспечения:

Эксперты по экспертизе разработанного программного обеспечения

Волокитин Сергей Анатольевич

Ведущий эксперт компьютерно-технического направления

Опыт: Профессиональный опыт в сфере информационных технологий и информационной безопасности с 2008 года

Задать вопрос эксперту: Волокитин Сергей Анатольевич Задать вопрос эксперту Все эксперты

Музалевский Фёдор Александрович

Ведущий эксперт компьютерно-технического направления

Опыт: Экспертная работа с 2010 года. Педагогический стаж с 2012 года. Кандидат физико-математических наук. Доцент кафедры ВМ и ИТ ФГБОУ ВО «ВГУИТ»

Задать вопрос эксперту: Музалевский Фёдор Александрович Задать вопрос эксперту Все эксперты

Чайковский Андрей Сергеевич

Эксперт компьютерно-технического направления

Опыт: Профессиональный опыт в сфере информационных технологий и информационной безопасности с 2012 года

Задать вопрос эксперту: Чайковский Андрей Сергеевич Задать вопрос эксперту Все эксперты

Категория технических экспертиз программного кода

К данной категории экспертиз относятся следующие экспертизы (по типу исследования):

Категория нормативных и нормативно-технических экспертиз ПО

Одним из вариантов нормативно-технических исследований является экспертиза программного продукта. При проведении такого рода исследований экспертом устанавливаются следующее:

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

Образец экспертного исследования

Заказать экспертизу программного обеспечения

Для уточнения стоимости и сроков экспертизы заполните форму ниже. Срок реакции на запрос от 1 до 7 часов. Заявки принимаются круглосуточно.

Источник

Экспертиза исходного кода программы

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Information protection. Secure software development. General requirements

Дата введения 2017-06-01

Предисловие

1 РАЗРАБОТАН Закрытым акционерным обществом «Научно-производственное объединение «Эшелон» (ЗАО «НПО «Эшелон»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 «Защита информации»

5ПЕРЕИЗДАНИЕ. Октябрь 2018 г.

Введение

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

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

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

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

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

Настоящий стандарт можно применять в качестве источника для формирования мер и средств контроля и управления безопасностью программного обеспечения в соответствии с ГОСТ Р ИСО/МЭК 27034-1. Настоящий стандарт можно использовать для конкретизации или расширения компонентов доверия из ГОСТ Р ИСО/МЭК 15408-3.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ 2.001 Единая система конструкторской документации. Общие положения

ГОСТ 19.101 Единая система программной документации. Виды программ и программных документов

ГОСТ 19.201 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению

ГОСТ 19.402 Единая система программной документации. Описание программы

ГОСТ 19.404 Единая система программной документации. Пояснительная записка. Требования к содержанию и оформлению

ГОСТ Р ИСО/МЭК 15408-1- Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель

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

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

ГОСТ Р ИСО 10007 Менеджмент организации. Руководящие указания по управлению конфигурацией

ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств

ГОСТ Р ИСО/МЭК 27001 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования

ГОСТ Р ИСО/МЭК 27034-1 Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

безопасность информации: Состояние защищенности информации, при котором обеспечены ее конфиденциальность, доступность и целостность.

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

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

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

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

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

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

3.8 объект среды разработки программного обеспечения: Аппаратные средства, программы, программно-аппаратные средства и документы, используемые разработчиком для разработки программного обеспечения.

3.9 пользователь (программного обеспечения): Лицо, применяющее программное обеспечение или участвующее в деятельности, прямо или косвенно зависящей от функционирования данного программного обеспечения.

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

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

сетевая атака: Компьютерная атака с использованием протоколов межсетевого взаимодействия.

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

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

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

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

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

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

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

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

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

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

3.23 электронный документ: Документ, выполненный программно-техническим средством на электронном носителе.

Источник

Введение

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

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

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

Основные недостатки и ограничения тестирования по методу «чёрного ящика»:

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

В статье будет кратко рассмотрена процедура экспертизы исходных текстов ПП, как способа тестирования его безопасности и защищённости методом «белого ящика».

Суть метода экспертизы исходных текстов программных продуктов

Экспертиза исходных текстов ПП в общем случае состоит из нескольких этапов:

Экспертиза проходит во время разработки ПП и его тестирования. Завершается одновременно с завершением тестирования самого ПП.

Исследование проблемы информационной безопасности программных продуктов

Исходные тексты ПП являются очень объёмным источником информации, где есть смысл искать не только чисто технические ошибки, такие как неправильная работа с памятью, игнорирование кодов возврата функций и т.д. — ведущих к тем или иным видам нарушения свойств безопасности и защищённости ПП (например, «отказ в обслуживании»), но также и ряда логических ошибок — передача паролей в открытом виде, неверный выбор алгоритмов шифрования, а также ряд ошибок, которые являются архитектурным недосмотром и для исправления требуют внесения значительных изменений в структуру ПП. Поэтому экспертиза исходных текстов ПП (особенно внешняя экспертиза — с привлечением сторонней организации), как правило, начинается с разработки экспертами собственной модели безопасности ПП (подробнее о сути проблемы обеспечения безопасности и защищённости ПП можно узнать из более ранней работы [1]).

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

Работы по построению модели ИБ ПП могут быть организованы при помощи ряда различных методологий, таких как Microsoft Threat Modeling Methodology [2], при помощи популярных методик оценки риска [3] или методологии, рекомендуемой стандартами ГОСТ Р ИСО/МЭК 15408-1-3 (общеизвестными, как «Общие критерии»).

Разработка собственной модели ИБ ПП позволяет экспертам локализовать наиболее критичные области ПП, которые должны быть наиболее тщательно проанализированы в ходе инспекции кода, а также выявить потенциальные недочёты модели безопасности ПП, используемой разработчиками ПП.

Цели ревизии исходных текстов ПП:

Инспекция кода

Во время инспекции исходных текстов ПП происходит непосредственный поиск уязвимостей ПП путём анализа исходных текстов ПП.

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

Предусловие для инспекции: обеспечение общего качества кода (например, на основе рекомендаций из [4]). Экспертам, проводящим экспертизу, будет значительно легче разобраться в коде, если весь код подчиняется некоторому единому стандарту оформления, в коде обосновано выбираются названия для классов, методов, констант и переменных, что позволяет быстрее определить назначение того или иного участка кода, в коде имеются достаточные комментарии и т.д., например, в соответствии с рекомендациями 5.

Основные задачи на этом этапе:

Поиск проблемных мест

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

Оценка важности участка кода для безопасности и защищённости программных продуктов

В рамках построения модели ИБ ПП должны быть выявлены наиболее критичные участки исходных текстов ПП. Простой и достаточно эффективный способ оценки опасности того или иного участка кода можно найти в статье [11], где автор рекомендует при рассмотрении очередного участка кода ответить на следующие вопросы:

Следует оказать повышенное внимание коду, который получил более трёх-четырёх положительных ответов.

Поиск логических ошибок в реализации модели безопасности программных продуктов

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

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

Таблица 1. Краткий обзор типовых функций ПП, критичных для его безопасности и защищённости.

Функции

Комментарий

Управление учётными записями и паролями

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

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

Управление доступом пользователей

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

Анализу подлежат не только функции, доступные через пользовательский интерфейс ПП, но также функции и публичные интерфейсы, которые находятся в dll-библиотеках ПП, в его сборках ( assembly), ActiveX-компонентах, Java-классах и т.д., которые могут быть вызваны злоумышленником в злонамеренных целях ( code access security).

Передача (хранение) конфиденциальных данных

В общем случае здесь требуется проверить, чтобы неавторизованные пользователи доступа к конфиденциальным данным не имели, а авторизованным пользователям не было отказано в доступе к ним (требование относится и к тем данным, которые передаются по локальным вычислительным сетям).

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

Анализу подвергаются такие функции, как, например, работа с временными файлами (если в таких файлах содержится какая-то конфиденциальная информация, то такие файлы должны надёжно удаляться, без возможности восстановления) и т.д.

Управление пользовательскими сессиями

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

Ведение протоколов (аудит)

Анализ того, что в протоколе программы ( program log) не содержится информация, которая может способствовать организации атаки на ПП (т.е. отсутствие отладочной информации, отсутствие информации о других пользователях ПП, что делает невозможным мониторинг за действиями других пользователей ПП) и т.д.

Функции управления серийными кодами к ПП, управления программными лицензиями

Анализ надёжности реализации алгоритмов генерации (хранения, получения) серийных номеров и программных лицензий для активации ПП.

Функции защиты от незаконного копирования ПП и его данных

Анализ качества реализации и надёжности мер защиты от незаконного копирования и тиражирования

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

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

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

Функции

Комментарий

Работа с внешними ресурсами (файлы, реестр, базы данных и т.д.)

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

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

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

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

Управление исключениями, проверка возвращаемых кодов функций

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

Управление отладочной информацией

Управление конфигурационной информацией

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

Корректный ввод ( Data validation)

Подтверждение того, что разработчик проверил правильность ввода данных пользователем, что исключает проведения таких атак, как переполнение буфера ( buffer- over- run), внедрение кода (например, SQL- injection) и т.д.

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

Недекларированные функции и интерфейсы

Обнаружение функций ПП, которые не входят в требуемую спецификацию ПП (программные закладки ( programmer backdoor), различного рода «пасхальные яйца» [12] и т.д.)

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

Также для каждого языка программирования существует ряд технических особенностей, специфических именно для данного языка, которые в каждом отдельном случае необходимо изучать на основании специализированных справочников и статей. Так, например, для языка программирования Java ряд рекомендаций можно найти в [13], для PHP в [14].

Составление отчёта, выработка рекомендаций

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

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

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

Выводы

Экспертиза исходных текстов ПП позволяет:

Источник