CC BY
125
Барабанов Александр Владимирович
старший преподаватель МГТУ им. Н.Э.Баумана
Нормативные вопросы безопасного производства программ
Аннотация: рассмотрены вопросы стандартизации процесса разработки безопасных программных средств. Проанализированы основные положения проекта ГОСТ «Защита информации. Разработка безопасных программных средств. Требования». Показана возможность гармонизации указанного стандарта с стандартами серии.
Ключевые слова: безопасное программное средство, уязвимости программных средств, дефекты безопасности программных средства.
На протяжении последних лет наблюдается устойчивый рост количества нарушений ИБ, приводящих к снижению уровня целостности, доступности и конфиденциальности информационных ресурсов автоматизированных систем [1, 8]. Опыт работы аккредитованной испытательной лаборатории [2, 6], проводящей сертификационные испытаний ПО в различных системах сертификации, показывает, что даже в продуктах, представляемых разработчиками на сертификацию, содержатся уязвимости и дефекты безопасности. Наиболее распространенными типами уязвимостей, выявляемых в ПО, подаваемом сертификацию, являются: аутентификаци-онные данные в исходном коде ПО, межсайто-вый скрптинг, внедрение SQL-кода [1].
Проведенные исследования позволили определить три основных причины наличия уяз-вимостей в ПО [2].
1. Недостаток мотивации разработчиков. Потребители в первую очередь приобретают ПО, которое является первым на рынке или обладает уникальными функциональными возможностями. В связи с этим разработчики ПО заинтересованы в скорейшем выпуске ПО или его обновлений на рынок, что влечет за собой отсутствие должного внимания к вопросам обеспечения безопасности.
2. Отсутствие у разработчиков необходимых знаний. Методы построении безопасного ПО еще находиться в стадии изучения и формирования. В связи с этим современный разработчик ПО не всегда полностью понимает, как правильно проектировать и разрабатывать программу именно с точки зрения безопасности, что ведет к наличию большого
числа уязвимостей в ПО, выпускаемом на рынок.
3. Отсутствие у разработчиков необходимых технологий. Современные инструментальные средства обеспечения безопасности разработки (статические анализаторы, сканеры уязвимостей и т.д.) еще не вышли на необходимый уровень развития и не еще могут в полной мере помочь разработчикам решить вопросы безопасности их ПО.
Угрозы безопасности ПО могут быть классифицированы по стадии жизненного цикла разработки ПО (стадии разработки, поставки, установки и эксплуатации), для которой они характерны [5, 9, 10].
Источником угроз безопасности ПО на стадии разработки ПО являются внутренние нарушители, в первую очередь недобросовестные разработчики, которые пытаются повлиять на штатный режим функционирования ПО путем внесения несанкционированных изменений в следующие объекты:
> требования к ПО, проектная документация ПО;
> исходные тексты ПО или исполняемые модули;
> тестовая документация или результаты тестирования ПО [3];
> эксплуатационная документация;
> инструментальные средства, используемые при разработки ПО.
Недобросовестные разработчики могут как входить в штат компании-разработчика ПО или привлекаться временно, так и являться разработчиком ПО с открытым исходным текстом, которое используется при реализации ПО.
Источником угроз безопасности ПО на стадии поставки ПО могут являться организа-
ции, осуществляющие поставку ПО конечному пользователю. В ходе этой процедуры в ПО могут быть несанкционированно внедрены вредоносные модули или выполнена замена стандартных модулей ПО на модули с недеклари-рованными возможностями [4]. Если поставка ПО осуществляется с использованием сетевых протоколов передачи данных (например, путем получения дистрибутива ПО с сервера организации-разработчика), то источником угрозы может выступать внешний нарушитель, который может заменить файлы дистрибутива ПО в
Таким образом, на сегодняшний день важным направлением развития, нацеленным на повышение качества ПО и уменьшение числа уязвимостей и дефектов безопасности, является внедрение цикла разработки безопасного ПО. Опыт компании Microsoft показал, что внедрение цикла разработки безопасного ПО позволяет сократить число уязвимостей в ПО компании в среднем на 80%. В настоящее время известны методологии проектирования безопасного ПО, которые успешно используются предприятиями-разработчиками. В таблице 2 представлены результаты сравнитель-
процессе их передачи или перенаправить пользователя на вредоносный сайт для скачивания дистрибутива ПО с использованием атак типа «межсайтовый скриптинг».
Источником угроз безопасности ПО на стадии эксплуатации ПО являются внутренние или внешние нарушители, которые могут выполнять локальные или удаленные (с использованием сетевых протоколов) атаки на ПО с целью эксплуатации уязвимостей.
Основные категории угроз безопасности ПО и их описания приведены в таблице 1.
ного анализа следующих методологий проектирования безопасного ПО:
> «Общие критерии» (ГОСТ Р ИСО/МЭК 15408 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий»);
> методология OWASP CLASP (Complex Lightweight Application Security Process);
> методология Microsoft Security Development Life Cycle;
> методология Cisco SDL;
> методология OpenSAMM.
Таблица 1.
Основные категории угроз безопасности ПО
Категория угроз безопасности ПО Краткое описание Нарушаемое свойство информационной безопасности Последствия от реализации угрозы
Саботаж Нарушение штатного режима функционирования ПО, удаление исполняемых модулей ПО. Доступность Реализация атаки типа «отказ в обслуживании»
Внедрение программных закладок Несанкционированная модификация исполняемых модулей ПО, внедрение в ПО вредоносных модулей или программных закладок Целостность Нарушение штатного режима функционирования ПО, выполнение ПО команд атакующего
Получение несанкционированного доступа Несанкционированный доступ к функциональным возможностям ПО Нарушение политик разграничения доступа Несанкционированное выполнение команд или копирование/кража исполняемых файлов
Раскрытие архитектуры ПО Раскрытие архитектуры и принципов работы ПО с использованием механизмов декомпиляции или дизас-семблирования Конфиденциальность Получение предварительной информации об атакуемом ПО, получение информации об архитектуре и принципах работы ПО, что является интеллектуальной собственностью разработчика
Таблица 2.
Результаты сравнительного анализа методологий проектирования безопасного ПО
Характеристика Методология
«Общие критерии» Microsoft SDL Open SAMM Cisco SDL OWASP CLASP
Обучение специалистов - + + + -
Обеспечение физической и логической безопасности при разработке ПО + - - - -
Управление конфигурацией + - - - -
Моделирование угроз + + + + +
Определение требований безопасности к разрабатываемому ПО + + + + +
Использование принципов безопасного проектирования + + + + +
Анализ исходных кодов ПО - + + + +
Анализ уязвимостей + + + + +
Использование методов проектирования безопасного ПО - + + + +
Обеспечение безопасности поставки + - + + -
В настоящее время ФСТЭК России ведется работа над государственным стандартом «Защита информации. Требования по обеспечению безопасности разработки программного обеспечения». Кроме этого, в соответствии с нормативным правовым актом ФСТЭК России «Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных», использование в информационной системе системного и (или) прикладного ПО, разработанного с использованием методов защищенного программирования, является дополнительной мерой по обеспечению безопасности информации в случае определения в качестве актуальных угроз безопасности персональных данных 1-го и 2-го типов. В тоже время документ, определяющий содержание и порядок выполнения работ по созданию ПО с использованием методов защищенного программирования, отсутствует. Эти положения и определяют актуальность разработки ГОСТ.
При разработке первой редакции проекта ГОСТ учитывались следующие особенности: 1. Поскольку известно, что стоимость устранения уязвимостей и дефектов безопасности
ПО выше на поздних стадиях проектирования, ГОСТ должен обеспечить внедрение необходимых процедур на самых ранних стадиях проектирования ПО.
2. ГОСТ должен учитывать современные тенденции разработки безопасных ПО, учитывать положения «лучших практик» (например, Microsoft SDL, Cisco SDL) [12-14].
3. ГОСТ должен быть полностью совместим с ме-
тодологией разработки и сертификации ПО, используемой в настоящее время ФСТЭК России («Общие критерии») [9].
4. Разрабатываемый ГОСТ должен обеспечить возможность интеграции процедур разработки безопасного ПО с существующей на предприятии системой управления ИБ (например, построенной в соответствии с ГОСТ Р ИСО/ МЭК 27001 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования») [11].
Анализ современных методологий проектирования безопасного ПО позволил сформулировать следующий перечень процедур, которые должны быть реализованы разработчиком для успешного противостояния угрозам безопасности ПО: > процедуры управления конфигурацией;
> процедуры определения модели жизненного > цикла; >
> процедуры проектирования и реализации безопасных ПО;
> процедуры использования инструменталь- р ных средств и методов разработки; с
> процедуры обеспечения безопасности разра- I ботки;
Таблица 3. Соответствие требованиям ИСО 15408
> процедуры поставки;
> процедуры обновления и устранения уязвимостей и дефектов безопасности ПО.
Следует отметить, что требования к реализации большинства процедур согласованы с требованиями доверия, предъявляемыми ГОСТ Р ИСО/МЭК 15408-3 (табл. 3) [1].
Требование разрабатываемого стандарта Требование ГОСТ Р ИСО/МЭК 15408-3
Требования к функциональным возможностям системы управления конфигурацией ACM CAP.1, ACM CAP.2, ACM CAP.3, ACM CAP.4, ACM_CAP.5
Требования к области действия системы управления конфигурации ACM_SCP.1, ACM_SCP.2, ACM_SCP.3
Требования к средствам автоматизации процесса управления конфигурацией ACM_AUT.1, ACM_AUT.2
Требования к процедурам определения модели жизненного цикла ALC_LCD.1, ALC_LCD.2, ALC_LCD.3
Требования к процедурам проектирования и реализации безопасных ПО ATE FUN.1, ATE FUN.2, AVA VLA, ADV FSP, ADV HLD, ADV_LLD, ADV_RCR
Требования к процедурам использования инструментальных средств и методов разработки ALC_TAT.1, ALC_TAT.2, ALC_TAT.3
Требования к обеспечению безопасности разработки ALC_DVS.1, ALC_DVS.2
Требования к процедуре поставки ADO DEL.1, ADO DEL.2, ADO DEL.3, ADO ISG, AGD_ADM, AGD_USR
Требования к реализации процедур обновления и устранения недостатков ALC_FLR.1, ALC_FLR.2, ALC_FLR.3
Отдельно рассмотрим перечень основных требований к процедурам проектирования и реализации безопасных ПО, сформулированные по результатам анализа «лучших практик» и обобщения опыта работы аккредитованных испытательных лабораторий систем сертификации средств защиты информации.
1. Должно проводиться периодическое обучение разработчиков ПО с целью повышения их осведомленности в области разработки безопасного ПО. Выполнение данного требования позволяет обеспечить повышение осведомленности в области безопасной разработки ПО сотрудников, связанных с разработкой ПО и, как следствие, повышение уровня безопасности разрабатываемого ПО. В программу обучения сотрудников могут входит курсы безопасного программирования, инспекции кода, тестирования на проникновение, статического анализа, динамического анализа, функционального тестирования и другие [7].
2. Разработчиком ПО должны быть определены и документированы требования безопас-
ности к разрабатываемому ПО. Например, могут быть определены следующие классы требований: требования к обеспечению конфиденциальности, требования к обеспечению идентификации и аутентификации, требования к реализации разграничения доступа, требования к обработке ошибок и исключений ПО.
3. Проектирование ПО должно выполняется с использованием принципов проектирования безопасных ПО. При выполнении проектирования разработчиком могут, например, использоваться следующие принципы: принцип эшелонированной защиты, принцип минимальных привилегий, принцип модульного проектирования, принцип разделения обязанностей.
4. При проектировании ПО разработчиком должно выполняться моделирование угроз с целью выявления уязвимостей ПО этапа проектирования, результаты моделирования угроз должны документироваться.
5. Разработка ПО должна выполняться с использованием методов защищенного про-
граммирования. Например, в ходе разработки ПО разработчик должен избегать использования скомпрометированных (небезопасных) функций в исходных кодах ПО. В качестве источника небезопасных функций могут использоваться, например, списки «Security Development Lifecycle Banned Function Calls» компании Microsoft.
6. Должен проводиться периодический статический анализ исходных кодов ПО с целью выявления уязвимостей и дефектов кода, результаты анализа должны документироваться.
7. Должна проводиться периодическая инспекция кода с целью выявления уязвимостей и дефектов кода, результаты инспекции должны документироваться.
8. Должно проводиться и документироваться тестирование (функциональное, нагрузочное) ПО.
9. Должен проводиться динамический анализ исходных кодов ПО с целью выявления уяз-вимостей и дефектов кода, результаты анализа должны документироваться.
10. Должно проводиться тестирование на проникновение с целью выявления уязвимостей ПО, результаты тестирования должны документироваться.
11. Должны быть разработаны функциональная спецификация ПО, проектная документация (проект верхнего уровня, проект нижнего уровня) и документация, демонстрирующая соответствие между всеми смежными парами имеющихся представлений ПО.
Планируется, что будет введена некоторая градация, которая позволит предъявлять требования к организациям-разработчикам в зависимости от критичности создаваемого ПО.
Внедрение подобных процедур в российские организации-разработчики ПО, на наш взгляд, повысить уровень защищенности создаваемого ПО и, как следствие, значительно уменьшить число инцидентов ИБ.
Литература
1. Барабанов А.В. Стандартизация процесса разработки безопасных программных средств // Вопросы кибербезопасности. 2013. № 1(1). С.37-41.
2. Костогрызов А.И., Липаев В.В. Сертификация функционирования автоматизированных информационных систем. М.: Изд. «Вооружение. Политика. Конверсия», 1996. 280 с.
3. Марков А.С. Модели оценки и планирования испытаний программных средств по требованиям безопасности информации // Вестник Московского государственного технического университета им. Н.Э. Баумана. Серия: Приборостроение. 2011. № SPEC. С. 90-103.
4. Марков А.С., Фадин А.А. Организационно-технические проблемы защиты от целевых вредоносных программ типа Stuxnet // Вопросы кибербезопасности. 2013. № 1(1). С.28-36.
5. Марков А.С., Фадин А.А. Систематика уяз-вимостей и дефектов безопасности программных ресурсов // Защита информации. Инсайд. 2013. №3. С. 56-61.
6. Марков А.С., Цирлов В.Л. Сертификация программ: мифы и реальность // Открытые системы. СУБД. 2011. № 6. С. 26-29.
7. Марков А.С., Цирлов В.Л., Маслов В.Г., Олексенко И.А. Тестирование и испытания программного обеспечения по требованиям безопасности информации // Известия Института инженерной физики. 2009. Т. 2. № 12. С. 2-6.
8. Матвеев В.А., Цирлов В.Л. Состояние и перспективы развития индустрии информационной безопасности Российской Федерации в 2014 г. // Вопросы кибербезопасности. 2013. № 1(1). С.61-64.
9. Методы оценки несоответствия средств защиты информации / А.С.Марков, В.Л.Цирлов, А. В. Барабанов; под ред. А.С.Маркова. - М.: Радио и связь, 2012. 192 с.
10. Правовое обеспечение информационной безопасности / Минаев В.А., Фисун А.П., Скрыль С.В. , Дворянкин С.В., Никитин М.М. - М.: Маросейка, 2008 г. 368 с.
11. Шахалов И.Ю., Дорофеев А.В. Основы управления информационной безопасностью современной организации // Правовая информатика. 2013. № 3. С. 4-14.
12. Howard M., Lipner S. The Security Development Lifecycle: A Process for Developing Demonstrably More Secure Software. Microsoft Press. 2006. 352 p.
13. Cisco Secure Development Lifecycle. Cisco White Paper. 2013. 4 p.
14. Software Assurance Maturity Model: A guide to building security into software development. Ver. 1.0. OWASP. 2013. 96 p.
