Платная доработка на тему Метод безопасной разработки программного обеспечения

Содержание:

АННОТАЦИЯ 2

ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ И СОКРАЩЕНИЙ 6

ВВЕДЕНИЕ 7

ГЛАВА 1. РИСКИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ПРИ РАЗРАБОТКЕ ПО 9

1.1 Риски безопасности информации при выполнении анализа требований к программному обеспечению 12

1.1.1 Риск появления уязвимостей программы вследствие ошибок, допущенных при задании требований по безопасности, предъявляемых к создаваемому программному обеспечению 12

1.1.2 Риск выявления уязвимостей программы вследствие раскрытия информации о требованиях по безопасности, предъявляемых к создаваемому программному обеспечению [2] 14

1.1.3 Риски безопасности информации при выполнении проектирования архитектуры программы 15

1.1.4 Риск появления уязвимостей программы вследствие ошибок, допущенных при создании проекта архитектуры программы 16

1.1.5 Риск выявления уязвимостей программы вследствие раскрытия информации о проекте архитектуры программы 18

1.1.6 Риск безопасности информации при выполнении квалификационного тестирования программного обеспечения 19

1.1.7 Риск появления уязвимостей вследствие изменения тестовой документации с целью сокрытия уязвимостей программы 19

1.1.8 Риск безопасности информации при решении проблем в программном обеспечении в процессе эксплуатации 20

1.1.9. Риск не исправления обнаруженных уязвимостей программы 21

1.1.10 Риск выявления уязвимостей вследствие раскрытия информации об ошибках программного обеспечения и уязвимостях программы 22

1.2 Виды уязвимостей ПО 23

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

1.2.2 SQL-инъекция 26

1.2.3 PHP-инъекция 28

1.2.4 E-mail-инъекция 28

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

1.2.6 Shatter attack 29

1.3 Национальные и международные стандарты [4] 30

1.4 Кибербезопасность в Узбекистане [30] 32

ГЛАВА 2 ПРАВОВОЕ РЕГУЛИРОВАНИЕ И РЕАЛИЗАЦИЯ БЕЗОПАСНОЙ РАЗРАБОТКИ ПО 34

2.1 Анализ нормативно-правовых актов по разработке ПО на примере уязвимостей ПО автомобилей 35

2.2 Анализ технологий безопасной разработки ПО 42

2.3 Состав мероприятий по безопасной разработке ПО 47

2.4 Типовая модель безопасной разработки ПО 49

ГЛАВА 3 56

3.1 Методы безопасной разработки [24] 56

3.1.1 Waterfall (каскадная модель) 56

3.1.2 «V-Model» ( V-образная модель) [25] 58

3.1.3 Incremental Model (инкрементная модель) 59

3.1.4 «Iterative Model» (итеративная или итерационная модель) 60

3.1.5 «Spiral Model» (спиральная модель) 62

3.1.6 «RAD Model» (rapid application development model или быстрая разработка приложений) 63

3.1.7 Agile Model (гибкая методология разработки) 65

3.2 Разработка требований к программному обеспечению. Выявление и анализ требований. Спецификации требований. [22] 67

3.2.1 Схема разработки требований [22] 71

3.2.2 Управление требованиями [22] 73

3.2.3 Анализ требований разработки ПО [20] 76

3.2.4 Выявление и анализ требований 78

3.2.5 Спецификация требований 78

3.2.6 Тестирование программного обеспечения 81

3.3 Этапы безопасной разработки ПО [21] 82

3.3.1 Инструментарий технологии программирования 84

3.3.2 Средства для создания приложений 85

3.3.3 Средства для создания информационных систем (Case–технология) 87

3.4 Основы модели качества [28] 87

3.4.1 Модели качества 88

3.4.2 Модель качества при использовании 90

3.4.3 Модель качества продукта 91

3.4.4 Качество с точки зрения различных заинтересованных сторон 94

4 ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ 99

5 БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ 101

ЗАКЛЮЧЕНИЕ 106

Введение:

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

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

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

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

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

 

Для достижения поставленной цели были выделены следующие задачи:

− Выявление рисков информационной безопасности при разработке ПО;

− Ознакомление, сравнение и выявление необходимых технических условий в национальных и международных стандартах при разработке ПО;

− Разновидности моделей при разработке методик ПО.

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

 

Заключение:

В настоящей дипломной работе была создана методика безопасной разработки программного обеспечения. Для этого были выполнены следующие этапы:

 Проанализированы отечественные и зарубежные нормативные правовые актов по разработке ПО по теме технологий, применяемых при разработке и эксплуатации ПО автомобилей;

 Выявлены и проанализированы технологий безопасной разработки ПО;

 Выделен состав необходимых мероприятий по безопасной разработке ПО;

 Спроектирована типовая модель безопасной разработки ПО;

 Разработаны требования к разработке безопасного программного обеспечения. Выявлены и проанализированы требования, которые затем были специфицированы;

 Проведено тестирование программного обеспечения;

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

 

Фрагмент текста работы:

ГЛАВА 1. РИСКИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ПРИ РАЗРАБОТКЕ ПО

Под риском информационной безопасности, или киберриском, понимают потенциальную возможность использования уязвимостей активов конкретной угрозой для причинения ущерба организации. В соответствии с ГОСТ Р 58412-2019 Риски ИБ ПО можно классифицировать следующим образом как представлена на рис.1. [1]

Рис.1. Классификация рисков ИБ

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

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

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

Внутренние нарушители – это физические лица — сотрудники и руководители компании, а также юридические лица, которые имеют договорные отношения с компанией. Внутренние нарушители классифицируются по целенаправленности и злонамеренности их действий, а для осуществления целенаправленного несанкционированного доступа у злонамеренного инсайдера должны быть мотив, способ и соответствующая возможность для атаки. Поставщики услуг, оборудования или персонала также несут в себе риски информационной безопасности — известны случаи, когда причинами утечек становились поставщики IT-сервисов, производители вспомогательного оборудования и сотрудники компании-подрядчика. Провайдеры облачных сервисов также попадают в категорию потенциальных внутренних нарушителей, чему может свидетельствовать большое количество утечек данных из некорректно сконфигурированных облачных хранилищ. Следует отметить тенденцию последнего времени в виде стандартизации методов оценки и управления риском привлечения сторонних организаций: ЦБ РФ выпустил стандарт СТО БР ИББС-1.4-2018 «Управление риском информационной безопасности при аутсорсинге», а международный стандарт ISO 27036 можно использовать для управления информационной безопасностью при взаимодействии с поставщиками услуг, в том числе и с провайдерами облачных сервисов (руководствуясь ISO 27036-4:2016).

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

Российский стандарт ГОСТ Р 56546-2015 выделяет несколько возможных типов уязвимостей: уязвимости кода, конфигурации, архитектуры, организационная уязвимость, многофакторная уязвимость. Данный стандарт указывает и на потенциальные места возникновения уязвимостей: общесистемное, прикладное, специальное ПО, технические средства, сетевое оборудование, средства защиты. Уязвимость характеризуется степенью своей опасности, которая стандартом ГОСТ Р 56546-2015 определяется как сравнительная величина, характеризующая подверженность информационной системы уязвимости и влияние этой уязвимости на нарушение свойств безопасности информации (конфиденциальность, целостность, доступность).

Общепринятым способом расчета опасности уязвимости в количественном выражении является использование метрики CVSS (Common Vulnerability Scoring System) американского Национального института стандартов и технологий (NIST, National Institute of Standards and Technology). Данная метрика позволяет описать основные особенности уязвимости и количественно оценить её опасность (по шкале от 0 до 10) в зависимости от сложности эксплуатации, влияния на свойства безопасности актива, наличия готового экспорта и его доступности для злоумышленника, возможности устранить уязвимость, уровня достоверности сообщения о наличии уязвимости, а также в привязке к конкретной среде эксплуатации уязвимой системы.

Идея централизованно регистрировать и классифицировать уязвимости нашла свою реализацию в нескольких официальных реестрах уязвимостей, таких как MITRE CVE (Common Vulnerabilities and Exposures), Банк данных угроз безопасности информации (БДУ) ФСТЭК России, NIST NVD (National Vulnerability Database), CERT/CC VND (Vulnerability Notes Database).

1.1 Риски безопасности информации при выполнении анализа требований к программному обеспечению

1.1.1 Риск появления уязвимостей программы вследствие ошибок, допущенных при задании требований по безопасности, предъявляемых к создаваемому программному обеспечению

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

• преднамеренными действиями нарушителя (злоумышленника);

• с принятием разработчиком ПО осознанного решения об отказе от исправления обнаруженных в требованиях по безопасности ошибок в силу различных лично-индивидуальных причин, – например, для сокращения времени разработки программы;

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

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

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

В качестве примеров объектов разработки программного обеспечения можно привести: документы, разрабатываемые по требованиям ГОСТ Р 56939 (техническое задание, задание по безопасности), постановки задач и иные документы, в том числе электронные, создаваемые или используемые при определении требований по безопасности. При выполнении анализа угрозы безопасности информации следует учитывать, что объекты среды разработки ПО, создаваемые или используемые при определении требований по безопасности, могут не являться элементами конфигурации, контролируемыми системой управления конфигурацией ПО.

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

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

В качестве примеров ошибок в требованиях по безопасности можно привести:

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

• отсутствие требования аутентификации для выполнения критичных операций;

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