Security Development Lifecycle

Материал из Википедии — свободной энциклопедии
Это старая версия этой страницы, сохранённая Olegrok (обсуждение | вклад) в 07:57, 23 декабря 2017 (→Преамбула: уточнение). Она может серьёзно отличаться от текущей версии.
Перейти к навигации Перейти к поиску

Security Development Lifecycle (SDL, жизненный цикл безопасной разработки) — концепция разработки, заключающаяся в формировании требований к приложению, безопасном программировании, тестировании, сертификации, эксплуатации и обновлении.[1] SDL это процесс который позволяет убедиться в необходимом уровне безопасности разрабатываемой системы и поддерживать ее на протяжении срока эксплуатации. SDL фокусируется на деятельности в области безопасности, деятельности по обеспечению безопасности, организации мероприятий по обеспечению безопасности и управлению проектами, идентификации и управление рисками в области безопасности.

История

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

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

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

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

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

Реализация Microsoft SDL развивалась с момента «повышения безопасности» в начале 2002 года. SDL оказал значительное влияние на планы, ресурсы и графики программных групп, и их было гораздо труднее предпринять без активной поддержки высшего руководства Microsoft. Цели безопасности сосредоточены на моделировании угроз, обзорах кода и безопасности (в том числе на проникновении). Окончательный обзор безопасности («FSR») был выпущен в конце 2002 года и в начале 2003 года, до того, как был выпущен Windows Server 2003. На данный момент последняя версия Microsoft SDl была выпущена в 2012.[3]

В отличие от CLAPS[4] SDL легче интегрируема и применима практически на любом этапе разработки и является более гибкой в плане применения.

Аналогом SDL в России является ГОСТ Р 56939-2016 [5], который в предоставляет не просто набор практик, рекомендуемых для использования в разработке приложений, но конкретные рекомендации к роли каждого участника разработки и его обязанности в ходе разработки безопасного приложения.

Этапы SDL[6]

Для обеспечения безопасности программного обеспечения существует ряд основных руководящих принципов. Знания заинтересованных сторон и способы их применения в программном обеспечении имеют жизненно важное значение для обеспечения безопасности программного обеспечения. К ним относятся:

  1. Защита от раскрытия информации
  2. Защита от изменения
  3. Защита от разрушения
  4. Аутентификация
  5. Какие права и привилегии пользователя
  6. Управление конфигурацией, сеансами и ошибками / исключениями

Для поддержания безопасной разработки в SDL используются следующие практики.

Обучение(Training)

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

Базовый уровень тренинга должен включать в себя:

Безопасный дизайн

  • Снижение областей атаки
  • Глубокая защита
  • Принцип наименьших привилегий
  • Безопасность по умолчанию

Моделирование угроз, включая следующие темы:

  • Обзор моделей угроз
  • Влияние модели угроз на дизайн
  • Ограничения для стиля кодирования, базирующиеся на модели угроз

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

  • Переполнение буфера
  • Ошибки целочисленной арифметики
  • SQL-инъекции (для приложений взаимодействующих с БД)
  • Слабая криптография

Тестирование безопасности, включая следующие темы:

  • Различия между тестированием безопасности и функциональным тестированием
  • Аудит рисков
  • Методы тестирования безопасности

Обеспечение приватности, включая следующие темы:

  • Типы приватной информации
  • Приватность: лучшие практики дизайна
  • Аудит рисков
  • Приватность: лучшие практики разработки
  • Приватность: лучшие практики тестирования

Требования(Requirements)

Требования в концепции SDL заключаются в:

  1. определение и интеграция требований безопасности и конфиденциальности;
  2. определение минимально допустимых уровней безопасности и конфиденциальности;
  3. оценка безопасности и конфиденциальности и изучение разработки программного обеспечения на основе затрат и нормативных требований.

На этом этапе команда разработки определяет лидеров и консультантов по темам безопасности, назначается ответственный за безопасность. Ответственный проверяет план разработки продукта, рекомендует изменения или устанавливает дополнительные требования к безопасности продукта, определить приоритет, процедуру отслеживания и исправления ошибок. Также необходимо определить и задокументировать порог отбраковки продукта по ошибкам связанным с безопасностью и защитой данных. Важно установить на этапе требований все необходимые критерии, которые могут помочь в обеспечении безопасности проекта, так как включение подобных требований помогает не экономить на безопасности и влючить проверку требований в планирование времени разработки. Также возможен вариант, при котором требования устанавливает и проверяет не команда разработчиков, а сторонняя команда. Например в Microsoft для этого существует Secure Windows Initiative.[7]

Проектирование(Design)

Включает:

  1. Установка требований к дизайну(рассмотрение вопросов безопасности и конфиденциальности). На данном этапе необходимо определить общую структуру программного обеспечения с точки зрения безопасности и те компоненты, которым необходимо доверять («доверенная вычислительная база»), определить методы проектирования, такие как использование строго типизированного языка и минимизация поверхности атаки(элементов уязвимых к угрозам), которые применимы к программному обеспечению в глобальном масштабе. Особенности отдельных элементов архитектуры должны быть подробно описаны в отдельных спецификациях дизайна, но архитектура безопасности определяет общую перспективу проектирования безопасности;
  2. Анализ / сокращение поверхности атаки(Attack Surface Reduction). В этом помогает документация элементов поверхности программного обеспечения;
  3. Использование моделирования угроз(применение структурированного подхода к сценариям угроз во время проектирования). Для этого команде разработчиков необходимо проводить моделирование угроз на уровне компонентов. Используя структурированную методологию, команда определяет компоненты и ресурсы, которыми программное обеспечение должно управлять, и интерфейсы. Процесс моделирования угроз идентифицирует угрозы, которые могут нанести ущерб каждому активу и вероятность причинения вреда. Затем команда компонента определяет возможные контрмеры, которые могут смягчить или устранить риск - либо в виде таких функций безопасности, как шифрование, либо в виде требований для надлежащего функционирования программного обеспечения, которые защитят используемые ресурсы от вреда. Таким образом, моделирование угроз помогает разработчикам находить места, где функциях безопасности необходимы для надлежащей работы программного продукта. Процесс моделирования угроз должен поддерживаться инструментом, который отображает модели угроз в машиночитаемой форме для хранения и обновления;
  4. Определение дополнительных критериев проекта. Хотя базовые условия безопасности должны быть определены на уровне организации, отдельные группы продуктов или программного обеспечения могут нуждаться в специфичных требованиях к безопасности.

Реализация(Implementation)

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

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

Верификация (Verification)

Методами проверки качества и надежности кода включает:

  1. динамический анализ — выполнение проверки во время разработки;
  2. обзор поверхности атаки — проверка уровня поверхности атаки после завершения процедуры;
  3. Fuzz тестирование – файлами, вводом данных в интерфейсные элементы и код сетевой подсистемы.

Выпуск(Release)

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

Реагирование(Response)

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

Литература

  1. ↑ The Trustworthy Computing Security Development Lifecycle (англ.). msdn.microsoft.com. Дата обращения: 21 декабря 2017.
  2. ↑ Stewart, James. CISSP Certified Information Systems Security Professional Study Guide Sixth Edition. — Canada : John Wiley & Sons, Inc., 2012. — P. 275–319. — ISBN 978-1-118-31417-3.
  3. ↑ Microsoft Security Development Lifecycle (SDL) Process Guidance - Version 5.2. Microsoft Download Center. Дата обращения: 22 декабря 2017.
  4. ↑ CLASP Concepts - OWASP (англ.). www.owasp.org. Дата обращения: 22 декабря 2017.
  5. ↑ ГОСТ Р 56939-2016 | НАЦИОНАЛЬНЫЕ СТАНДАРТЫ. protect.gost.ru. Дата обращения: 22 декабря 2017.
  6. ↑ Microsoft Security Development Lifecycle (амер. англ.). www.microsoft.com. Дата обращения: 21 декабря 2017.
  7. ↑ Inside the Secure Windows Initiative (англ.). msdn.microsoft.com. Дата обращения: 21 декабря 2017.
Источник — https://ru.wikipedia.org/ruwiki/w/index.php?title=Security_Development_Lifecycle&oldid=89812605