Ўзбекистон республикаси ахборот технологиялари ва коммуникацияларини ривожлантириш вазирлиги муҳаммад ал-хоразмий номидаги

ОЦЕНКА БЕЗОПАСНОСТИ РАЗРАБОТКИ ПРОГРАММНОГО 
ПРИЛОЖЕНИЯ 
Д.Г. Абдуллаев, А.Д. Абдуллаев 
ТУИТ имени Мухаммада Ал-Хоразмий 
Программные приложения играют очень важную роль в сегодняшней 
враждебной компьютерной среде. Нередко можно найти программные 
приложения для работы наших транспортных систем, систем связи, 
медицинского оборудования, банковских систем, бытовой техники и других 
технологий, от которых мы зависим. Поскольку многие из этих программных 
приложений критически важны, нельзя упускать из виду необходимость 
обеспечения безопасности их данных и других ресурсов. Рост числа атак, 
направленных непосредственно на программные приложения в последние 
десятилетия, требует, чтобы программные приложения могли защищаться и 
продолжать работать. Однако, когда программные приложения разрабаты-
ваются без учета безопасности, злоумышленники используют недостатки 
безопасности в них, чтобы проводить атаки при их развертывании. Для 
решения этой проблемы в последнее десятилетие возникла новая область 
исследований, называемая безопасностью программного обеспечения, цель 
которой - встроить безопасность в приложения во время разработки. Этот 
подход рассматривает безопасность как новое свойство программного 
обеспечения. Много усилий направлено на то, чтобы встроить безопасность в 
программное обеспечение на всем протяжении SDLC (Software development 
lifecycle). Software development lifecycle (Жизненный цикл разработки 
программного обеспечения) - это серия из шести основных фаз, через 
которые проходит любая программная система. Далее рассматривают в 
общих чертах фазы жизненного цикла разработки системы, имея в виду что 

---

250 
все системы различны по уровню сложности, требуемым компонентам и 
ожидаемой функциональности.
1. Планирование системы. Фаза планирования - наиболее критичный шаг 
в создании успешной системы. Во время этой фазы, что необходимо сделать 
и какие проблемы решить при помощи: 

определения проблем, целей и ресурсов (таких, как персонал и 
издержки); 

изучения возможностей альтернативных решений путем встреч с 
клиентами, поставщиками, консультантами и сотрудниками; 

изучения, как сделать ваш продукт лучше, чем у конкурентов. 
После анализа этих данных возникают три варианта: разработать новую 
систему, улучшить существующую или оставить систему как есть. 
2. Анализ системы. Необходимо определить и задокументировать 
требованияконечного пользователя системы в чем его ожидания и как их 
осуществить Кроме того, для проекта делается технико-экономическое 
обоснование, которое выясняет, является ли проект организационно, 
экономически, социально, технологически осуществимым. Очень важно 
поддерживать хороший уровень коммуникации с заказчиками, чтобы 
убедиться, что есть ясное видение конечного продукта и его функций. 
3. Дизайн системы. Фаза дизайна наступает после того, как достигнуто 
хорошее понимание требований потребителя. Эта фаза определяет элемент 
системы, компоненты, уровень безопасности, модули, архитектуру, 
различные интерфейсы и типы данных, которыми оперирует система. Дизайн 
системы в общих чертах может быть сделан ручкой на листке бумаги - он 
определяет, как система будет выглядеть и как функционировать. Затем 
делается расширенный, детальный дизайн, с учетом всех функциональных 
и технических требований, как логически, так и физически.
4. Разработка, внедрение и развертывание. Эта фаза следует за полным 
пониманием системных требований и спецификаций. Это и есть собственно 
процесс разработки системы, когда дизайн системы уже полностью завершен 
и нагляден. В жизненном цикле разработки системы именно здесь пишется 
код, а если система включает хардверную часть, фаза внедрения будет 
включать в себя конфигурацию и настройку «железа» под определенные 
требования и функции. На этой стадии система готова к установке у 
заказчика, к запуску в боевом режиме. Возможно, конечным пользователям 
потребуется тренинг, чтобы они освоились с системой и знали, как ее 
использовать. Фаза внедрения может быть очень долгой - это зависит от 
сложности системы. 
5. Опытная эксплуатация и интеграция. Здесь происходит сборка 
различных компонентов и подсистем в одну целостную систему. Затем мы 
подаем системе различные входящие данные и анализируем выход, 
поведение и функционирование. Тестирование становится все важнее для 
удовлетворения потребителя, при этом оно не требует познаний ни в 
кодинге, ни в конфигурировании оборудования, ни в дизайне. Тестирование 

---

251 
может выполняться настоящими пользователями или специальной командой 
сотрудников, также оно может быть систематическим и автоматизиро-
ванным, с тем, чтобы удостовериться, что актуальные результаты работы 
системы совпадают с предусмотренными и желательными. 
6. Поддержка системы. На этой фазе осуществляется периодическая 
техническая поддержка системы, чтобы убедиться, что система не устарела. 
Сюда входит замена старого оборудования и постоянная оценка 
производительности. Также здесь осуществляются апдейты определенных 
компонентов с целью удостовериться, что система отвечает нужным 
стандартам и новейшим технологиям, чтобы не быть подверженной текущим 
угрозам безопасности. 
Это шесть основных стадий жизненного цикла разработки системы, и 
это повторяющийся процесс для каждого проекта. Важно отметить, что дол-
жен поддерживаться отличный уровень коммуникации с заказчиком. Для 
реализации требований очень важны и полезны прототипы. Строя систему 
короткими итерациями, можно гарантировать соответствие требованиям 
потребителя до того, как построить всю систему. Многие модели жизненного 
цикла разработки системы исходят из идеи экономии сил, денег и времени, 
минимизируя при этом риск несоответствия требованиям заказчика к концу 
проекта. Некоторые из этих моделей «итерационная модель» и «модель 
Agile». Одной из критических областей в этом подходе является область 
разработки программного обеспечения и безопасности, которая проактивно 
решает проблемы безопасности на этапе проектирования SDLC. Сообщается, 
что сегодня половина проблем безопасности в программных продуктах 
связаны с недостатками конструкции. Уязвимость проектного уровня 
описывается как наиболее сложная категория программных дефектов, с 
которыми приходится бороться. Более того, требуется большой опыт, чтобы 
определить, есть ли в программном приложении недостатки на уровне 
разработки, которые затрудняют поиск. При разработке программного 
приложении рекомендуется находить и исправлять недостатки на ранней 
стадии разработки программного обеспечения, поскольку устранение 
проблемы на поздней стадии разработки обходится дороже, а после 
развертывания программного обеспечения - гораздо дороже. Следовательно, 
учет безопасности на этапе проектирования SDLC в значительной степени 
поможет в создании защищенных программных приложений.