Википедия

Security Development Lifecycle

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]:

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

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

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

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

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

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

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

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

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

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

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

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

Реализация(Implementation) править

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

Верификация (Verification) править

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

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

Выпуск(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 не устранила уязвимости вовсе. В отчете компании Microsoft так же упоминается необходимость не только постоянного улучшения SDL и поиска новых подходов к безопасности, но и использования подобных подходов повсеместно, так как большое количество уязвимостей, найденных в приложениях, может привести к угрозе безопасности системы в целом[8].

Литература править

  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 Отчет о развитии Microsoft. Microsoft Download Center. Дата обращения: 25 декабря 2017. Архивировано 26 декабря 2017 года.
  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 года.
Источник — https://ru.wikipedia.org/w/index.php?title=Security_Development_Lifecycle&oldid=131981143