Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Отчет.docx
Скачиваний:
11
Добавлен:
22.02.2016
Размер:
562.88 Кб
Скачать

Процесс вовлечения сотрудников в процессе разработки безопасного по.

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

Процесс поддержки разработчиков в вопросах безопасности.

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

  1. Процесс обучения

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

Определим атаки наиболее актуальные для интернет-банкинга:

  1. XSS

  2. CSRF

  3. SQL Injection

  4. XPATH Injection

  5. Buffer Overflow

  6. Integer Overflow

  7. Unvalidated Redirects And Forwards

  8. Using Components with Known Vulnerabilities

  9. Security Misconfiguration

  10. Broken Authentication and Session Managment

Данный список составлялся на основе OWASPи требований стандарта банковского ПО -PCI-DSS.

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

  1. Моделирование угроз

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

Плюсы моделирования угроз:

  • Моделирование позволяет лучше разобраться в приложении.

  • Моделирование помогает находить ошибки в программе.

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

  • Модели угроз помогают новым сотрудникам детально разобраться в приложении.

  • Модели угроз полезны и тестировщикам: проверка ПО на основе модели угроз поможет разработать новые средства тестирования. Модели угроз полезны при организации хорошо продуманного плана тестирования защиты.

Процесс моделирования угроз выглядит следующим образом:

  1. разложение приложения на составляющие;

  2. определение угроз, грозящих системе:

  3. упорядочение угроз в порядке убывания степени их серьезности:

  4. определение методов реагирования на угрозы;

  1. Разложение приложения на составляющие:

Для этого пункта будет использоваться формальная декомпозиция с помощью DFD-диаграмм

  1. Определение угроз будет проводиться по методике STRIDE:

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

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

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

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

Отказ в обслуживании (Denial of service) В атаках такого типа взломщик пытается лишить доступа к сервису правомочных пользователей, например, сделав Web-сервер временно недоступным или непригодным для работы. Необходимо защищаться от определенных видов DoS-атак — это повысит доступность и надежность системы.

Повышение привилегий (Elevation of privilege) В данном случае непривилегированный пользователь получает привилегированный доступ, позволяющий ему “взломать” или даже уничтожить систему. К повышению привилегий относятся и случаи, когда злоумышленник удачно проникает через защищенные средства системы и становится частью защищенной и доверенной подсистемы.

  1. В качестве методики оценки риска будет использована методика DREAD

  • Потенциальный ущерб (Damage potential)мера реального ущерба от успешной атаки. Наивысшая степень (10) угроз означает практически беспрепятственный взлом средств защиты и выполнение практически любых операций.

Оценки:

0 – ничего не пострадает;

5 – пострадают или будут компрометированы данные отдельных пользователей;

10 – пострадает вся система или уничтожены все данные.

  • Воспроизводимость (Reproducibility)мера возможности повторной реализации угрозы. Некоторые узявимости доступны постоянно (оценка — 10), другие —только в зависимости от ситуации, и их доступность непредсказуема, то есть нельзя наверняка знать, насколько успешной окажется атака.

Оценки:

0 – очень тяжело или невозможно даже для администратора приложения.

5 – требует одного двух шагов, возможно нужны права авторизованного пользователя.

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

  • Подверженность взлому (Exploitability) — мера усилий и квалификации, необходимых для атаки.

Оценки:

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

5 – утилиты можно найти в сети интернет, или эксплойер легко написать самому или же можно воспользоваться уже существующими хакерскими утилитами.

10 – требуется только веб-браузер или подключение к атакуемой сети.

  • Круг пользователей, попадающих под удар (Affected users) — доля пользователей, работа которых нарушается из-за успешной атаки. Оценка выполняется на основе процентной доли: 100% всех пользователей соответствует оценка 10, а 10% — 1 балл. Иногда угроза становится реальной только в системе, сконфигурированной особым образом.

Оценки:

0 – Никто или ничто.

5 – Некоторые пользователи, но не все.

10 – Все пользователи.

  • Вероятность обнаружения (Discoverability) — мера усилий злоумышленника на обнаружение возможности атаки. Самая сложная для определения оценка.

Оценки:

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

5 – Может быть обнаружена под правами пользователя или же при помощи мониторинга сети.

9 – Детали и подробности можно найти в общем доступе (интернет, специализированные сайты по взлому).

10 – Информацию можно обнаружить при помощи браузера или использования приложения.

Суммарная DREAD-оценка равна арифметическому среднему всех оценок

  1. Определение методов реагирования на угрозы:

При анализе угроз и выборе способа противостояния им возможны четыре варианта поведения:

  • ничего не предпринимать;

  • предупредить пользователей;

  • устранить причину угрозы вместе с частью приложения;

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

Для пунктов 1 и 2 также можно воспользоваться приложением разработанным Microsoft под названием SDL Modeling Tool, которое строить DFD-диаграммы, а на их основе автоматически создавать отчет по возможным угрозам.