Security Development Lifecycle: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
[непроверенная версия][непроверенная версия]
← Предыдущая правка
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
м →Преамбула: уточнение
 
(не показано 47 промежуточных версий 21 участника)
Строка 1: Строка 1:
{{стиль статьи|дата=2023-07-27}}
'''Security Development Lifecycle''' (SDL, жизненный цикл безопасной разработки) — концепция разработки, заключающаяся в формировании требований к приложению, [[безопасное программирование|безопасном программировании]], [[тестирование программного обеспечения|тестировании]], [[сертификация|сертификации]], [[эксплуатация (техника)|эксплуатации]] и [[обновление программного обеспечения|обновлении]].<ref>{{Cite web|url=https://msdn.microsoft.com/en-us/library/ms995349.aspx|title=The Trustworthy Computing Security Development Lifecycle|publisher=msdn.microsoft.com|lang=en|accessdate=2017-12-21}}</ref> SDL это процесс который позволяет убедиться в необходимом уровне безопасности разрабатываемой системы и поддерживать ее на протяжении срока эксплуатации. SDL фокусируется на деятельности в области безопасности, деятельности по обеспечению безопасности, организации мероприятий по обеспечению безопасности и управлению проектами, идентификации и управление рисками в области безопасности.
{{много внутренних ссылок|дата=2023-07-27}}
'''Security Development Lifecycle''' (SDL, жизненный цикл безопасной разработки) — концепция разработки, заключающаяся в формировании требований к приложению, [[безопасное программирование|безопасном программировании]], [[тестирование программного обеспечения|тестировании]], [[сертификация|сертификации]], [[эксплуатация (техника)|эксплуатации]] и обновлении<ref name=":0">{{Cite web|url=https://msdn.microsoft.com/en-us/library/ms995349.aspx|title=The Trustworthy Computing Security Development Lifecycle|publisher=msdn.microsoft.com|lang=en|accessdate=2017-12-21|archive-date=2017-12-05|archive-url=https://web.archive.org/web/20171205094503/https://msdn.microsoft.com/en-us/library/ms995349.aspx|deadlink=no}}</ref>. SDL — это процесс, который позволяет поддерживать необходимый уровень безопасности системы на этапе разработки, а затем на протяжении всего срока эксплуатации. Эта концепция фокусируется на обеспечении безопасности разрабатываемого приложения, идентификации рисков и управлении ими.


== Причины создания ==
== История ==
По мере развития технологий среда приложений становится более сложной, и безопасность разработки приложений становится более сложной задачей. Приложения, системы и сети постоянно подвергаются различным атакам безопасности, таким как вредоносный код или отказ в обслуживании. Вирусы, троянские программы, логические бомбы, черви, агенты.<ref>{{Cite book|title=CISSP Certified Information Systems Security Professional Study Guide Sixth Edition|last=Stewart|first=James|publisher=John Wiley & Sons, Inc.|year=2012|isbn=978-1-118-31417-3|location=Canada|pages=275–319|via=}}</ref>
По мере развития технологий [[среда окружения]] становится более сложной, поэтому все труднее разрабатывать приложения, обеспечивающие высокий уровень безопасности системы. Приложения, системы и сети постоянно подвергаются различным атакам и угрозам, таким как вирусы, троянские программы, логические бомбы, черви, агенты и т. д.<ref name="CISSP">{{книга |заглавие=CISSP Certified Information Systems Security Professional Study Guide Sixth Edition |ссылка=https://archive.org/details/cisspcertifiedin0000stew |издательство=[[John Wiley & Sons|John Wiley & Sons, Inc.]] |год=2012 |isbn=978-1-118-31417-3 |место=Canada |страницы=[https://archive.org/details/cisspcertifiedin0000stew/page/275 275]—319 |ref=Stewart |язык=en |автор=Stewart, James}}</ref>.


Приложения обычно разрабатываются с использованием [[Язык программирования|языков программирования]] высокого уровня, которые включают в себя методы обеспечения безопасности. Основа разработки приложения должна включать в себя функциональные требования, спецификация управления, обзор дизайна, обзор кода и сквозной обзор, проверка системных тестов, а также обслуживание и управление изменениями.
Как правило, приложения разрабатываются с использованием [[Язык программирования|языков программирования]] высокого уровня, которые включают в себя методы обеспечения безопасности. Разработка приложения состоит из создания функциональных требований, спецификации управления, обзора дизайна, обзора кода и сквозного обзора, проверки системных тестов, а также из процесса обслуживания приложения и управления изменениями<ref name="CISSP" />.


Построение программного обеспечения для обеспечения безопасности не входит в компетенцию управленческой команды, но включает в себя: руководство, руководителей проектов, бизнес-аналитиков, менеджеров по обеспечению качества, технических архитекторов, специалистов по безопасности, владельцев приложений и разработчиков.
Процесс построения ПО для обеспечения безопасности не входит в компетенцию управленческой команды, но в нем также задействованы руководство, руководители проектов, бизнес-аналитики, менеджеры по обеспечению качества, технические архитекторы, специалисты по безопасности, владельцы приложений и разработчики<ref name="CISSP" />.


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


Разработка и внедрение жизненного цикла разработки безопасности представляет собой крупную инвестицию для компаний и значительное изменение в том, как разрабатывается, разрабатывается и тестируется программное обеспечение. Возрастающее значение программного обеспечения для общества подчеркивает необходимость SDL для отрасли.
Разработка и внедрение SDL на всех этапах жизненного цикла разработки представляет собой значительный вклад в обеспечение безопасности создаваемых приложений, который влечёт за собой значительное изменение в том, как разрабатывается и тестируется программное обеспечение<ref name=":0" />. Возрастающее значение ПО для общества подчеркивает необходимость SDL для отрасли<ref name="CISSP" />.


В отличие от CLAPS<ref>{{Cite web|url=https://www.owasp.org/index.php/CLASP_Concepts|title=CLASP Concepts - OWASP|publisher=www.owasp.org|lang=en|accessdate=2017-12-22|archive-date=2017-12-23|archive-url=https://web.archive.org/web/20171223042716/https://www.owasp.org/index.php/CLASP_Concepts|deadlink=no}}</ref>, SDL легче интегрируема и применима практически на любом этапе разработки, а также является более гибкой в плане применения<ref name="CISSP" />.
Реализация Microsoft SDL развивалась с момента «повышения безопасности» в начале 2002 года. SDL оказал значительное влияние на планы, ресурсы и графики программных групп, и их было гораздо труднее предпринять без активной поддержки высшего руководства Microsoft. Цели безопасности сосредоточены на моделировании угроз, обзорах кода и безопасности (в том числе на проникновении). Окончательный обзор безопасности («FSR») был выпущен в конце 2002 года и в начале 2003 года, до того, как был выпущен Windows Server 2003. На данный момент последняя версия Microsoft SDl была выпущена в 2012.<ref>{{Cite web|url=https://www.microsoft.com/en-us/download/details.aspx?id=29884|title=Microsoft Security Development Lifecycle (SDL) Process Guidance - Version 5.2|publisher=Microsoft Download Center|accessdate=2017-12-22}}</ref>


Аналогом SDL в России является ГОСТ Р 56939-2016, который предоставляет не только набор практик, рекомендуемых для использования в разработке приложений, но и конкретные рекомендации к роли каждого участника разработки и его обязанности<ref name="ГОСТ">{{Cite web|url=http://protect.gost.ru/v.aspx?control=8&baseC=-1&page=0&month=-1&year=-1&search=&RegNum=1&DocOnPageCount=15&id=195653|title=Защита информации. Разработка безопасного программного обеспечения. Общие требования|publisher=protect.gost.ru|access-date=2017-12-23|archive-date=2017-06-13|archive-url=https://web.archive.org/web/20170613005256/http://protect.gost.ru/v.aspx?control=8&baseC=-1&page=0&month=-1&year=-1&search=&RegNum=1&DocOnPageCount=15&id=195653|deadlink=no}}</ref>.
В отличие от CLAPS<ref>{{Cite web|url=https://www.owasp.org/index.php/CLASP_Concepts|title=CLASP Concepts - OWASP|publisher=www.owasp.org|lang=en|accessdate=2017-12-22}}</ref> SDL легче интегрируема и применима практически на любом этапе разработки и является более гибкой в плане применения.


== Этапы SDL ==
Аналогом SDL в России является ГОСТ Р 56939-2016 <ref>{{Cite web|url=http://protect.gost.ru/document.aspx?control=7&id=203548|title=ГОСТ Р 56939-2016 {{!}} НАЦИОНАЛЬНЫЕ СТАНДАРТЫ|publisher=protect.gost.ru|accessdate=2017-12-22}}</ref>, который в предоставляет не просто набор практик, рекомендуемых для использования в разработке приложений, но конкретные рекомендации к роли каждого участника разработки и его обязанности в ходе разработки безопасного приложения.
Для обеспечения [[Информационная безопасность|безопасности программного обеспечения]] существует ряд основных руководящих принципов. Знания заинтересованных сторон и способы их применения во всех этапах разработки ПО имеют жизненно важное значение для обеспечения безопасности ПО. К ним относятся<ref name="SDL">{{cite web|url=https://www.microsoft.com/en-us/sdl|title=Microsoft Security Development Lifecycle|publisher=www.microsoft.com|lang=en|accessdate=2017-12-21|archive-date=2017-12-20|archive-url=https://web.archive.org/web/20171220084800/https://www.microsoft.com/en-us/sdl/|deadlink=no}}</ref>:
* защита от раскрытия информации;
* защита от изменения;
* защита от разрушения;
* [[аутентификация]];
* какие права и привилегии пользователя;
* управление конфигурацией, сеансами и ошибками/исключениями.


=== Планирование(Training) ===
== Этапы SDL<ref>{{Cite web|url=https://www.microsoft.com/en-us/sdl|title=Microsoft Security Development Lifecycle|publisher=www.microsoft.com|lang=en-us|accessdate=2017-12-21}}</ref> ==
Обучение подразумевает исследование подготовленности сотрудников организации по темам безопасности и защиты данных. При необходимости рекомендуется создать курсы, разработать подходящие критерии качества обучения, определить частоту тренингов и обеспечить их посещение минимально необходимому для поддержания безопасности количеству персонала<ref name="SDL" />.
Для обеспечения [[Информационная безопасность|безопасности программного обеспечения]] существует ряд основных руководящих принципов. Знания заинтересованных сторон и способы их применения в программном обеспечении имеют жизненно важное значение для обеспечения безопасности программного обеспечения. К ним относятся:
# Защита от раскрытия информации
# Защита от изменения
# Защита от разрушения
# [[Аутентификация]]
# Какие права и привилегии пользователя
# Управление конфигурацией, сеансами и ошибками / исключениями
Для поддержания безопасной разработки в SDL используются следующие практики.


Базовый уровень тренинга должен включать в себя<ref name="ГОСТ" />:
=== Обучение(Training) ===
Обучение подразумевает исследование подготовленности сотрудников организации по темам безопасности и защиты данных. При необходимости рекомендуется создать курсы, разработать подходящие критерии качества обучения, определить частоту тренингов и обеспечить их посещение минимально необходимому для поддержания безопасности количеству персонала. Основополагающие [[концепции]] построения лучшего программного обеспечения включают безопасный дизайн, моделирование угроз, безопасное кодирование, тестирование безопасности и лучшие практики, связанные с конфиденциальностью.


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


=== [[Требования к программному обеспечению|Требования (Requirements)]] ===
Безопасный дизайн
Требования в концепции SDL заключаются в<ref name="ГОСТ" /><ref name="SDL" />:
* Снижение областей атаки
* определении и интеграции требований безопасности и конфиденциальности;
* Глубокая защита
* определении минимально допустимых уровней безопасности и конфиденциальности;
* Принцип наименьших привилегий
* оценке безопасности и конфиденциальности, изучении разработки программного обеспечения на основе затрат и нормативных требований.
* Безопасность по умолчанию
На этом этапе команда разработки определяет лидеров и консультантов по темам безопасности, назначает ответственного за безопасность. Ответственный проверяет план разработки продукта, рекомендует изменения или устанавливает дополнительные требования к безопасности продукта, определяет приоритет, процедуру отслеживания и исправления ошибок. Также необходимо определить и задокументировать порог отбраковки продукта по ошибкам, связанным с безопасностью и защитой данных. Важно установить на этапе требований все необходимые критерии, которые могут помочь в обеспечении безопасности проекта, так как включение подобных требований помогает не экономить на безопасности и включать проверку требований в планирование времени разработки. Также возможен вариант, при котором требования устанавливает и проверяет не команда разработчиков, а сторонняя команда. Например в Microsoft для этого существует [[Secure Windows Initiative]]<ref>{{Cite web|url=https://msdn.microsoft.com/en-us/library/cc723542.aspx|title=Inside the Secure Windows Initiative|publisher=msdn.microsoft.com|lang=en|accessdate=2017-12-21|archive-date=2017-12-22|archive-url=https://web.archive.org/web/20171222051842/https://msdn.microsoft.com/en-us/library/cc723542.aspx|deadlink=no}}</ref>.
Моделирование угроз, включая следующие темы:
* Обзор моделей угроз
* Влияние модели угроз на дизайн
* Ограничения для стиля кодирования, базирующиеся на модели угроз
Безопасное кодирование, включая следующие темы:
* Переполнение буфера
* Ошибки целочисленной арифметики
* SQL-инъекции (для приложений взаимодействующих с БД)
* Слабая криптография
Тестирование безопасности, включая следующие темы:
* Различия между тестированием безопасности и функциональным тестированием
* Аудит рисков
* Методы тестирования безопасности
Обеспечение приватности, включая следующие темы:
* Типы приватной информации
* Приватность: лучшие практики дизайна
* Аудит рисков
* Приватность: лучшие практики разработки
* Приватность: лучшие практики тестирования


=== [[Проектирование|Проектирование (Design)]] ===
=== [[Требования к программному обеспечению|Требования]](Requirements) ===
Включает<ref name="ГОСТ" /><ref name="SDL" />:
Требования в концепции SDL заключаются в:
# Установку требований к дизайну (рассмотрение вопросов безопасности и конфиденциальности). На данном этапе необходимо определить общую структуру программного обеспечения с точки зрения безопасности и те компоненты, которым необходимо доверять («доверенная вычислительная база»), определить методы проектирования, такие как использование строго типизированного языка и минимизация поверхности атаки (элементов уязвимых для угроз). Особенности отдельных элементов архитектуры должны быть подробно описаны в отдельных спецификациях дизайна;
# определение и интеграция требований безопасности и конфиденциальности;
# Анализ/сокращение поверхности атаки ([[Attack Surface Reduction]]). В этом помогает документация элементов поверхности программного обеспечения;
# определение минимально допустимых уровней безопасности и конфиденциальности;
# Использование моделирования угроз (применение структурированного подхода к сценариям угроз во время проектирования). Для этого команде разработчиков необходимо проводить моделирование угроз на уровне компонентов. Моделирование угроз помогает разработчикам находить места, где функции безопасности необходимы для надлежащей работы программного продукта. Процесс моделирования угроз должен поддерживаться инструментом, который отображает модели угроз в машиночитаемой форме для хранения и обновления;
# оценка безопасности и конфиденциальности и изучение разработки программного обеспечения на основе затрат и нормативных требований.
На этом этапе команда разработки определяет лидеров и консультантов по темам безопасности, назначается ответственный за безопасность. Ответственный проверяет план разработки продукта, рекомендует изменения или устанавливает дополнительные требования к безопасности продукта, определить приоритет, процедуру отслеживания и исправления ошибок. Также необходимо определить и задокументировать порог отбраковки продукта по ошибкам связанным с безопасностью и защитой данных. Важно установить на этапе требований все необходимые критерии, которые могут помочь в обеспечении безопасности проекта, так как включение подобных требований помогает не экономить на безопасности и влючить проверку требований в планирование времени разработки. Также возможен вариант, при котором требования устанавливает и проверяет не команда разработчиков, а сторонняя команда. Например в Microsoft для этого существует [[Secure Windows Initiative]].<ref>{{Cite web|url=https://msdn.microsoft.com/en-us/library/cc723542.aspx|title=Inside the Secure Windows Initiative|publisher=msdn.microsoft.com|lang=en|accessdate=2017-12-21}}</ref>

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


=== Реализация(Implementation) ===
=== Реализация (Implementation) ===
Разработка в SDL заключается в спецификации и использовании задокументированных средств разработки, поиска и устранения устаревшего программного обеспечения, при этом происходит анализ всех функций проекта и их запрещение в случае несоответствия требованиям. Также рекомендуется использовать статический анализ кода для обеспечения политики безопасности программы<ref name="ГОСТ" />.
Разработка кода и ревью процессов, документации и инструментов необходимых для безопасного развертывания и эксплуатации разрабатываемого продукта.

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


=== [[Верификация|Верификация (Verification)]] ===
=== [[Верификация|Верификация (Verification)]] ===
Методами проверки качества и надежности кода включает:
Методы проверки качества и надежности кода включают в себя<ref name="ГОСТ" /><ref name="SDL" />:
# динамический анализ — выполнение проверки во время разработки;
* динамический анализ — выполнение проверки во время разработки;
# обзор поверхности атаки — проверка уровня поверхности атаки после завершения процедуры;
* проверку уровня поверхности атаки;
# Fuzz тестирование – файлами, вводом данных в интерфейсные элементы и код сетевой подсистемы.
* [[Фаззинг |фаззинг-тестирование]] (файлами, вводом данных в интерфейсные элементы) и код сетевой подсистемы.

=== Выпуск (Release) ===
Перед непосредственным выпуском программного продукта рекомендуется создать план реагирования на инциденты и провести окончательный обзор безопасности. Подготовка плана реагирования на инциденты имеет решающее значение для помощи в устранении новых угроз, которые могут возникать с течением времени. Данный план включает в себя предоставление соответствующих аварийных контактов по вопросам безопасности и создание планов обслуживания для кода, унаследованного от других групп внутри организации, и для лицензированного стороннего кода. В свою очередь, заключительный обзор безопасности (FSR - final security review) обычно включает в себя проверку моделей угроз, выводов инструментов и производительности<ref name="ГОСТ" />.

=== Реагирование (Response) ===
После выпуска программного обеспечения необходимо обеспечить своевременное реагирование на возникающие проблемы. Несмотря на использование SDL, программный продукт все еще может содержать уязвимости и проблемы в работе, которые могут приводить к нарушению [[Криптографическая стойкость|криптографической стойкости]]. Больша́я часть ошибок обнаруживается на этапе эксплуатации. Таким образом, процесс реагирования помогает в обеспечении безопасности программного продукта уже после выпуска<ref name="ГОСТ" />.

== Обзор ==
Microsoft официально использует SDL, начиная с 2004 года, и, согласно статистике использования, компании удалось добиться повышения качества продукции<ref name=":0" /><ref>{{Cite web|url=https://www.anti-malware.ru/interviews/2015-12-03/4067|title=SDL как новый подход к безопасности|publisher=Anti-Malware.ru|lang=ru|accessdate=2017-12-23|archive-date=2017-12-24|archive-url=https://web.archive.org/web/20171224213743/https://www.anti-malware.ru/interviews/2015-12-03/4067|deadlink=no}}</ref>.

Согласно словам Стива Липнера (Steve Lipner), старшего директора по направлению стратегического планирования и разработки технологий обеспечения безопасности корпорации Microsoft, руководящего разработкой SDL:


{{начало цитаты}} «…при введении этой системы удалось уменьшить общее количество ошибок и, тем самым, повысить конкурентоспособность продукции компании с точки зрения безопасности. Мы также уверены, что нам удалось значительно сократить количество выпускаемых обновлений. Однако достаточно сложно оценить количество уязвимостей, которые не были исправлены.» {{конец цитаты|источник=https://www.anti-malware.ru/interviews/2015-12-03/4067}}Согласно отчёту о развитии SDL в 2004–2010 годах количество уязвимостей в продуктах корпорации Microsoft уменьшилось почти на три порядка по сравнению с остальными компаниями<ref name=":0" /><ref name=":1" />. Вместе с тем, по данным [[Secunia Research Community]], бюллетени независимой фирмы [[Secunia]], специализирующейся на безопасности программных продуктов, количество [[Secunia advisories]] в IIS 5 (до SDL) — 12, в IIS 6 (первый выпуск с SDL) — 5 и в IIS 7 (с SDL) — 1<ref>{{Cite web|url=https://secuniaresearch.flexerasoftware.com/community/|title=Security Community - Secunia|publisher=secuniaresearch.flexerasoftware.com|accessdate=2017-12-25|archive-date=2017-12-22|archive-url=https://web.archive.org/web/20171222190043/https://secuniaresearch.flexerasoftware.com/community/|deadlink=no}}</ref><ref>{{Cite web|url=https://secuniaresearch.flexerasoftware.com/community/research/|title=Computer Security Research - Secunia|publisher=secuniaresearch.flexerasoftware.com|accessdate=2017-12-25|archive-date=2017-12-31|archive-url=https://web.archive.org/web/20171231212800/https://secuniaresearch.flexerasoftware.com/community/research/|deadlink=no}}</ref>. Так же результативность использования SDL подтверждена опытом компаний [[VMware]]<ref>{{cite web|url=https://www.vmware.com/security/sdl.html|title=VMware Security Development Lifecycle (vSDL)|publisher=VMWare|lang=en|accessdate=2017-12-25|archive-date=2018-03-11|archive-url=https://web.archive.org/web/20180311111026/https://www.vmware.com/security/sdl.html|deadlink=no}}</ref> и [[SAP]]<ref>{{Cite web|url=https://www.sap.com/documents/2016/03/a248a699-627c-0010-82c7-eda71af511fa.html#|title=The Secure Software Development Lifecycle at SAP|publisher=SAP|lang=en|accessdate=2017-12-25|archive-date=2017-01-19|archive-url=https://web.archive.org/web/20170119200131/http://www.sap.com/documents/2016/03/a248a699-627c-0010-82c7-eda71af511fa.html|deadlink=no}}</ref>.
=== Выпуск(Release) ===
Перед непосредственным выпуском программного продукта рекомендуется создание плана реагирования на инциденты и проведение окончательного обзора безопасности. Подготовка плана реагирования на инциденты имеет решающее значение для помощи в устранении новых угроз, которые могут возникать с течением времени. Он включает предоставление соответствующих аварийных контактов по вопросам безопасности и создание планов обслуживания безопасности для кода, унаследованного от других групп внутри организации, и для лицензированного стороннего кода.  в области безопасности. В свою очередь, заключительный обзор безопасности ([[FSR]]) обычно включает в себя проверку моделей угроз, выводов инструментов и производительности по сравнению с качественными воротами и барами, определенными на этапе требований.


Однако, несмотря на то, что SDL эффективно снижает риски и уменьшает частоту обновлений, это также подчеркивает постоянно меняющийся характер кибербезопасности, так как ни одна система не может полностью устранить уязвимости.<ref name=":1">{{Cite web|url=https://www.solix.com/products/application-retirement-solution/|title=Application Retirement|publisher=Application Retirement|accessdate=2019-12-25|archive-date=2019-12-26|archive-url=https://web.archive.org/web/20240715205445/solix.com/products/application-retirement-solution/|deadlink=no}}</ref>. Однако концепция SDL не устранила уязвимости вовсе. В отчете компании Microsoft так же упоминается необходимость не только постоянного улучшения SDL и поиска новых подходов к безопасности, но и использования подобных подходов повсеместно, так как большое количество уязвимостей, найденных в приложениях, может привести к угрозе безопасности системы в целом<ref name=":2">{{Cite web|url=https://www.microsoft.com/ru-ru/download/details.aspx?id=14107|title=Отчет о развитии Microsoft|publisher=Microsoft Download Center|accessdate=2017-12-25|archive-date=2017-12-26|archive-url=https://web.archive.org/web/20171226130258/https://www.microsoft.com/ru-ru/download/details.aspx?id=14107|deadlink=no}}</ref>.
=== Реагирование(Response) ===
После выпуска программного обеспечения необходимо обеспечить своевременное реагирование на возникающие проблемы. Не смотря на использование SDL программный продукт все еще может содержать уязвимости и проблемы в работе, которые могут приводить к нарушению [[Криптографическая стойкость|криптографической стойкости]]. Большáя часть ошибок обнаруживается на этапе эксплуатации. Таким образом процесс реагирования помогает в обеспечении безопасности программного продукта уже после выпуска


== Литература ==
== Литература ==
{{примечания}}
<references />


[[Категория:Технологии организации программирования]]
{{нет категорий}}
[[Категория:Microsoft]]
{{изолированная статья}}

Текущая версия от 15:32, 20 декабря 2024

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

Причины создания

[править | править код]

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

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

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

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

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

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

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

Этапы SDL

[править | править код]

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

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

Планирование(Training)

[править | править код]

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

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

  • безопасный дизайн;
  • моделирование угроз;
  • безопасное кодирование;
  • тестирование безопасности;
  • обеспечение приватности.

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

[править | править код]

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

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

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

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

[править | править код]

Включает[4][5]:

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

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

[править | править код]

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

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

[править | править код]

Методы проверки качества и надежности кода включают в себя[4][5]:

  • динамический анализ — выполнение проверки во время разработки;
  • проверку уровня поверхности атаки;
  • фаззинг-тестирование (файлами, вводом данных в интерфейсные элементы) и код сетевой подсистемы.

Выпуск (Release)

[править | править код]

Перед непосредственным выпуском программного продукта рекомендуется создать план реагирования на инциденты и провести окончательный обзор безопасности. Подготовка плана реагирования на инциденты имеет решающее значение для помощи в устранении новых угроз, которые могут возникать с течением времени. Данный план включает в себя предоставление соответствующих аварийных контактов по вопросам безопасности и создание планов обслуживания для кода, унаследованного от других групп внутри организации, и для лицензированного стороннего кода. В свою очередь, заключительный обзор безопасности (FSR - final security review) обычно включает в себя проверку моделей угроз, выводов инструментов и производительности[4].

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

[править | править код]

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

Обзор

[править | править код]

Microsoft официально использует SDL, начиная с 2004 года, и, согласно статистике использования, компании удалось добиться повышения качества продукции[1][7].

Согласно словам Стива Липнера (Steve Lipner), старшего директора по направлению стратегического планирования и разработки технологий обеспечения безопасности корпорации Microsoft, руководящего разработкой SDL:

«…при введении этой системы удалось уменьшить общее количество ошибок и, тем самым, повысить конкурентоспособность продукции компании с точки зрения безопасности. Мы также уверены, что нам удалось значительно сократить количество выпускаемых обновлений. Однако достаточно сложно оценить количество уязвимостей, которые не были исправлены.»

— https://www.anti-malware.ru/interviews/2015-12-03/4067

Согласно отчёту о развитии SDL в 2004–2010 годах количество уязвимостей в продуктах корпорации Microsoft уменьшилось почти на три порядка по сравнению с остальными компаниями[1][8]. Вместе с тем, по данным Secunia Research Community, бюллетени независимой фирмы Secunia, специализирующейся на безопасности программных продуктов, количество Secunia advisories в IIS 5 (до SDL) — 12, в IIS 6 (первый выпуск с SDL) — 5 и в IIS 7 (с SDL) — 1[9][10]. Так же результативность использования SDL подтверждена опытом компаний VMware[11] и SAP[12].

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

Литература

[править | править код]
  1. ↑ 1 2 3 4 The Trustworthy Computing Security Development Lifecycle (англ.). msdn.microsoft.com. Дата обращения: 21 декабря 2017. Архивировано 5 декабря 2017 года.
  2. ↑ 1 2 3 4 5 6 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. ↑ CLASP Concepts - OWASP (англ.). www.owasp.org. Дата обращения: 22 декабря 2017. Архивировано 23 декабря 2017 года.
  4. ↑ 1 2 3 4 5 6 7 8 Защита информации. Разработка безопасного программного обеспечения. Общие требования. protect.gost.ru. Дата обращения: 23 декабря 2017. Архивировано 13 июня 2017 года.
  5. ↑ 1 2 3 4 5 Microsoft Security Development Lifecycle (англ.). www.microsoft.com. Дата обращения: 21 декабря 2017. Архивировано 20 декабря 2017 года.
  6. ↑ Inside the Secure Windows Initiative (англ.). msdn.microsoft.com. Дата обращения: 21 декабря 2017. Архивировано 22 декабря 2017 года.
  7. ↑ SDL как новый подход к безопасности. Anti-Malware.ru. Дата обращения: 23 декабря 2017. Архивировано 24 декабря 2017 года.
  8. ↑ 1 2 Application Retirement. Application Retirement. Дата обращения: 25 декабря 2019. Архивировано 26 декабря 2019 года.
  9. ↑ Security Community - Secunia. secuniaresearch.flexerasoftware.com. Дата обращения: 25 декабря 2017. Архивировано 22 декабря 2017 года.
  10. ↑ Computer Security Research - Secunia. secuniaresearch.flexerasoftware.com. Дата обращения: 25 декабря 2017. Архивировано 31 декабря 2017 года.
  11. ↑ VMware Security Development Lifecycle (vSDL) (англ.). VMWare. Дата обращения: 25 декабря 2017. Архивировано 11 марта 2018 года.
  12. ↑ The Secure Software Development Lifecycle at SAP (англ.). SAP. Дата обращения: 25 декабря 2017. Архивировано 19 января 2017 года.
  13. ↑ Отчет о развитии Microsoft. Microsoft Download Center. Дата обращения: 25 декабря 2017. Архивировано 26 декабря 2017 года.
Источник — https://ru.wikipedia.org/ruwiki/w/index.php?title=Security_Development_Lifecycle&oldid=142179372