12 практик безопасного жизненного цикла разработки программного обеспечения (SDLC) от Microsoft

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

Microsoft Secure Software Development Lifecycle (SSDL ) — это процесс разработки программного обеспечения, созданный и обнародованный компанией Microsoft еще в январе 2004 года. Он основан на спиральной модели SDLC. В начальный период его разработки появление данной практики в основном принесло пользу компании, снизив затраты на техническое обслуживание программного обеспечения и повысив его надежность. Версии SSDL (с 1 по 3) были обнародованы для широкого круга пользователей только в январе 2006 года. Версия 3.2 была выпущена в 2008 году.

В последующих версиях SDL Microsoft больше сосредоточились на надежности программного обеспечения, исправлении уязвимостей безопасности, моделировании угроз, соблюдении требований, отчетности, стандартов криптографии, а также реагировании на инциденты. Microsoft Secure Development Lifecycle , версия 5.2 (появившаяся на рынке в 2012 году), стала ведущей в отрасли моделью практики безопасности программного обеспечения. Она была широко признана частными и государственными компаниями по всему миру.

Нельзя не согласиться с тем фактом, что «это одна из лучших практик для обеспечения безопасности программного обеспечения (SwA ), которую следует использовать в своей работе специалистам». С 2004 года SDL имеет важное значение для создания и модернизации других ведущих практик по обеспечению безопасности ПО в мире.

Два термина «безопасность » и «конфиденциальность » для Microsoft подобны «бомбардировке электроном атома»: они не могут быть отделены от программной культуры и этапов разработки приложения. Прозрачность, о которой можно говорить, исходя из опубликованных документов, свидетельствует о том, что SSDL подходит для разработки безопасного продукта.

Введение

Настала пора ближе познакомиться с концепциями и принципами, используемыми в настоящее время Microsoft в своих продуктах и услугах. Хотя сама компания не раскрывает ни одной из своих основных проприетарных технологий и ресурсов относительно методологии создания Microsoft SDL (версия 5.2) .

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

Модель оптимизации Microsoft SDL

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

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

Следует выделить ключевые проблемы, которые могут быть решены или значительно уменьшены после внедрения Secure SDL :

• имеющиеся модели безопасности;
• конфиденциальность и защита данных;
• риск и уровень опасности уязвимостей снижаются;
• личная информация пользователей (PII) находится под постоянным контролем (предотвращение утечки данных);
• поддержка со стороны сообщества SDL;
• повышение репутации организации на рынке;
• соответствие всем имеющимся стандартам.

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

Традиционные пять возможностей в безопасном жизненном цикле разработки программного обеспечения (SSDLC)

Это упрощенные фазы жизненного цикла разработки безопасного программного обеспечения (SDLC). На самом деле, это 12-этапный процесс .

Microsoft называет это практиками , другие специалисты – этапами, шагами, фазами, процессами.

Читатели могут выбрать любое слово, которое им по душе. Это не столь важно.

Этап 1. Обучение и осведомленность (подготовка).

Этап 2. Требования к продукту (безопасность и конфиденциальность).

Этап 3. Определение и соблюдение требований к проектированию (лучшие практики, протоколы, инструменты, документы).

Этап 4. Определение уровня безопасности с помощью стандартов криптографии.

Этап 5. Метрики, критерии и соответствие стандартам.

Этап 6. Оценка рисков продукта (определение контекста, идентификация, анализ и обработка возможных рисков).

Этап 7. Управление и понимание рисков безопасности, связанных с использованием сторонних компонентов.

Этап 8. Список проверенных инструментов SDL.

Этап 9. Статический анализ кода (SAST).

Этап 10. Динамический анализ кода (DAST).

Этап 11. Тестирование на проникновение.

Этап 12. Создание стандартных процессов для реагирования на инциденты.

Традиционный процесс разработки продуктов от Microsoft

С 2002 года этот процесс начинается со сбора групп разработчиков программного обеспечения Microsoft в соответствии с директивой Trustworthy Computing (TwC) . Основная цель TwC – обеспечить безопасную, доступную и надежную защиту процесса разработки кода.

Чуть позже Microsoft придумала «SD3+C »: это дало возможность компании обеспечить безопасность проектирования, развертывания и коммуникации приложения комплексно, одновременно во всех 3 областях.

Пост-интеграция безопасного жизненного цикла разработки (SDL) + SD3+C

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

Этап 1. Обучение и осведомленность (подготовка)

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

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

Перспективы

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

Этап 2. Требования к продукту (безопасность и конфиденциальность)

На этом этапе выполнения требований к созданию продукта крайне важно рассмотреть его «безопасность и конфиденциальность (S&P) ». Это поможет самому специалисту и всей организации понять фундаментальные элементы разработки безопасных приложений. Безопасность в SDLC подобна поливу растений, требующим постоянной заботы. Изменения в практике защиты и противодействий возникающим угрозам должны регулярно осуществляться. Чем больше человек успеет исправить на ранних стадиях, тем меньше головной боли ждет его в будущем (минимизация сбоев / проблем безопасности / финансовых и временных затрат). Итак, стоит выполнить следующие требования для улучшения S&P в соответствии с нуждами бизнеса.

Требования к безопасности продукта

1. Следует провести внутренний опрос, чтобы проверить, подпадает ли ваша команда разработчиков под действие политик безопасного жизненного цикла разработки (SDL), а также рассмотреть следующие две цели при составлении вопросов и ответов:Если проект подпадает под действие политик SDI, советник по безопасности (SA) обязан выступить в качестве PoC и провести окончательную проверку безопасности (FSR).
   Если проект не подпадает под действие политик SDI, то не стоит назначать советника по безопасности (SA) ответственным по данному вопросу.
   
2. Нужно подготовить команду или человека, ответственного за координацию, отслеживание и коммуникацию, управление вопросами безопасности продукта. В компаниях S&M обычно один менеджер отвечает за вышеуказанную работу.
3. Следует убедиться, что инструменты отчетности об имеющихся багах смогут обнаружить проблемы безопасности. Необходимо подготовить базу данных, которая может быть запрошена и получена специалистом в любое время суток.
4. Надо определить и задокументировать набор критериев для панели ошибок безопасности проекта. Когда советник по безопасности ставит высокую планку для уровня безопасности приложения, проектная группа должна провести переговоры о имеющейся панели ошибок и возможной ее модернизации.
5. Когда специалист использует недавно полученный от третьей стороны лицензионный код или аппаратное обеспечение, нужно быть внимательным и убедиться, что есть подтверждение соответствиям предопределенному списку требований SDL.

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

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

Настала пора поговорить о концепции STRIDE. Итак, почему стоит использовать именно ее?

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

Примечание : Концепция STRIDE была создана с учетом уровня безопасности, она включает в себя 6 типов угроз. Практика была разработан Praerit Garg и Loren Kohnfelder из Microsoft для выявления проблем в защите.

«Security Bug Effect Cause» и «Security Bug Cause» помогут сделать так, чтобы элементы поля имели одно из значений STRIDE. Таким образом, специалист сможет убедиться в том, что он правильно настроил инструменты отчетности об имеющихся багах.

Security Bug Cause:

Анализ затрат

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

Рекомендации по безопасности

Специалист проводит оценку рисков безопасности (SRA) продуктов для выявления связанных с безопасностью аспектов, таких как угрозы, уязвимости, подверженность атакам, контрмеры.

Упрощенная или продвинутая версия СРА должна быть выполнена в соответствии с масштабами проекта.

Требования к конфиденциальности

Privacy Impact Assessment (PIA) – это быстрый способ определить уровень конфиденциальности и влияние извне на нее. Данная практика помогает пользователям оценить свою работу, назначая приложению рейтинг (P1, P2 или P3) в соответствии со степенью имеющихся рисков.

• P1 – высокий риск;
• P2 – умеренный риск;
• P3 – низкий риск.

1. Хранит личную информацию (PII) или передает ее с компьютера (P1).
2. Имеет функционал, ориентированный на детскую аудиторию (P1).
3. Производит непрерывный мониторинг активности пользователей (P1).
4. Устанавливает новое программное обеспечение или изменяет параметры домашней страницы или страницы поиска (P1).
5. Производит передачу данных анонимно (P2).
6. Ничего из вышеперечисленного (P3).

Этап 3. Определение и соблюдение требований к проектированию (лучшие практики, протоколы, инструменты, документы) + Этап 4. Определение уровня безопасности с помощью стандартов криптографии

В процессе проектирования следует создать и визуализировать план того, как проект будет реализован на протяжении всего внедрения SDL.

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

Важно рассмотреть проектные спецификации: как можно реализовать все функциональные возможности программы в рамках безопасности. Это делается очень внимательно: каждая часть данных просматривается и обрабатывается криптографически.

Требования к безопасности

Безопасность во время проектирования должна быть обговорена с консультантом по защите приложения независимо от того, какой проект реализуется. При этом компоненты с низким уровнем риска могут не требовать от специалиста детального анализа системы безопасности.

AllowPartiallyTrustedCallersAttribute (APTCA) :

Дает возможность сборке называться «надежным кодом ». Все зависит от версии фреймворка, что используется специалистом.

• Чтобы определить, включен или нет этот атрибут, обязательно следует взглянуть на аннотации в исходном коде; специалист также может использовать такой инструмент, как «FxCop ».
• В случае, если атрибут уже включен, нужно найти эксперта по безопасности проекта и потребовать проверки.

Relying Party Suite (RPS) (версия 4.0) SDK:

Данный пакет дает преимущество в плане безопасности по сравнению с текущей версией SDK Passport Manager (PPM) и помогает смягчить некоторые проблемы безопасности, связанные с ключами (такими как распространение, развертывание и администрирование).

Правила и требования к межсетевому экрану:

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

Все варианты криптографии должны соответствовать определенным криптографическим стандартам Microsoft для продуктов и услуг, относящихся к SDL.

Рекомендации по безопасности

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

1. Написать документ архитектуры безопасности.
2. Параметры по умолчанию должны быть безопасными.
3. Следует минимизировать поверхность атаки по умолчанию.
4. Рассмотреть более гибкий и продуманный подход к защите.
5. Программное обеспечение должно иметь четко прописанные необходимые компоненты.
6. Отказ от устаревших функций (оценка старых протоколов, форматов файлов и стандартов).
7. Проверка безопасности.
8. Возможность реализации нового кода с помощью его редактирования.
9. Переход любого устаревшего кода из неуправляемого в управляемый.
10. Нужно оставаться в курсе проблем безопасности во всей отрасли.
11. Следует ознакомиться с небезопасными функциями и шаблонами кодирования.
12. Убедиться, что для последующей экспертизы включены соответствующие параметры ведения журнала.
13. Необходимо выполнить проверку целостности потока страниц.
14. Обзор аппаратной безопасности приложения.
15. Обзор безопасности интегрированных компонентов.
16. «Strong log-out» и управление сеансами.

Параметры безопасности (.NET):

• отказ от ненужных разрешений;
• осуществление запроса на получение дополнительных разрешений;
• использование CodeAccessPermission Assert и LinkDemand;
• отключение трассировки и отладки перед развертыванием приложения ASP.NET.

Этап 5. Метрики, критерии и соответствие стандартам

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

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

Панель ошибок безопасности SSL и панель ошибок конфиденциальности SDL продемонстрированы ниже.

Панель ошибок безопасности SSL

Панель ошибок конфиденциальности SDL

Этап 6. Оценка рисков продукта (определение контекста, идентификация, анализ и обработка возможных рисков)

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

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

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

1. Какие персональные данные пользователей собираются?
2. Какие уведомления будет получать пользователь?
3. Какие соглашения он принимает при установке и использовании приложения?
4. Какие средства контроля предоставляются пользователям и предприятиям?
5. Как предотвращается несанкционированный доступ к личной информации?

Факторы оценки риска

Ниже представлены факторы, которые специалисты используют для определения уровня уязвимости приложения. В идеале следует проанализировать все упомянутые аспекты.

Идентификация рисков

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

На этапе проектирования команда разработчиков должна проанализировать все требования к конфиденциальности и безопасности приложения и общие ожидания, чтобы определить потенциальные риски, которые действительно несут в себе угрозу. Microsoft представила концепцию моделирования угроз в SDL. Ее основная функция заключается в использовании систематических процессов для выявления угроз и уязвимостей, присутствующих в программном обеспечении. Следует помнить, что словосочетание «structured fashion » относится ко всем продуктам, услугам и платформам.

Таким образом, команда разработчиков должна завершить этап (моделирование угроз) во время проектирования. Если она этого не сделает, то дальше специалисты не смогут создать безопасное программное обеспечение .

Моделирование угроз : часть обычного жизненного цикла разработки.

Полезный совет

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

Этап 7. Управление и понимание рисков безопасности, связанных с использованием сторонних компонентов

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

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

Необходимые компоненты находятся под контролем в современных проектах. В них может входить что угодно: начиная с программного обеспечения с открытым исходным кодом и заканчивая операционными системами.

Third-party Component Management Life Cycle (TPCM)

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

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

Риски безопасности для программ с открытым исходным кодом

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

Преимущества программ с открытым исходным кодом

• долго не появляются на рынке;
• есть большое сообщество;
• более высокое качество разработки.

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

• Нужно понять, какие инструменты с открытым исходным кодом (OST) уже используются.
• Централизовать управление OST.
• Убедиться, что OST защищены и обновлены до последней версии.
• Провести проверку уязвимостей системы безопасности.

Этап 8. Список проверенных инструментов SDL

Это один из важных этапов в Secure SDLC. Нужно определить и утвердить список инструментов, а также определиться с такими элементами, как компилятор, связанные уведомления и предупреждения. Специалисты используют проверенные версии новейших инструментов.

Этап 9. Статический анализ кода (SAST)

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

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

Нужно понимать, что тестирование конфиденциальности и безопасности затрагивает триаду «Confidentiality, integrity, and availability (CIA) », касающуюся программного обеспечения и данных, которые оно обрабатывает.

Требования к безопасности

Все проблемы должны быть исправлены в соответствии с имеющейся панелью ошибок.

Win32/64/Mac:

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

WinCE и Xbox:

Применяется шаблонная схема оптимизации, основанная на покрытии кода парсера. Недавние исследования доказали повышенную эффективность двойного фаззинга. Следует провести фаззинг не менее 250 000 итераций с момента последней найденной или исправленной ошибки.

Важно отметить, что с момента последней найденной или исправленной ошибки в среднем происходит более 100 000 итераций без ошибок, согласно статистике руководства Microsoft SDL Bug Bar .

Если программа имеет интерфейс удаленного вызова процедур (RPC), нужно быть готовым использовать любой из инструментов фаззинга RPC для поиска проблем.

Если в проекте используются «ActiveX controls », нужно применить «ActiveX fuzzer », который поможет выявить значительные риски безопасности приложения.

Верификатор приложения обнаруживает ошибки, которые являются проблемами класса исправлений MSRC в неуправляемом коде.

Онлайн-сервисы и LOB-приложения

Нужно использовать проверенный инструмент для сканирования на наличие межсайтовых сценариев и поиска уязвимостей, а также проводить синтаксический анализ XML.

Тестирование драйверов в режиме ядра

• Driver Verifier
• Device Path Exerciser
• Сайты и службы, не прошедшие проверку подлинности
• Тестирование COM-объектов
• Аутентифицированные веб-сайты
• Аутентифицированные веб-службы
• JavaScript

Интенсивное тестирование безопасности продукта

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

Подготовка к тестированию

Специалисты выбирают подходящее время и необходимые ресурсы.

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

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

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

Продолжительность тестирования

Количество времени и потраченной энергии на тестирование варьируется от одного члена команды к другому. Зависит от того, чем занимается определенный человек.

Требования к конфиденциальности

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

Этап 10. Динамический анализ кода (DAST)

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

Опять же, как и в случае с инструментами SAST, не существует универсального решения. В то время как некоторые программы, такие как инструменты сканирования веб-приложений, могут быть более легко интегрированы в конвейер CI/CD, другие процессы DAST, такие как фаззинг, требуют иного подхода. Разумно выполнить «фаззинг черного ящика», что значительно облегчит работу, поскольку не требует постоянного контроля над исходным кодом.

Этап 11. Тестирование на проникновение

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

Attack Surface Analyzer:

Microsoft разработала инструмент Attack Surface Analyzer (ASA) , он имеет открытый исходный код. Программа помогает проанализировать поверхность атаки целевой системы и сообщает о возможных уязвимостях безопасности, обнаруженных во время установки программного обеспечения или его неправильной конфигурации.

Кто может использовать данный инструмент?

• Инженеры DevOps . Просмотр изменений в поверхности атаки системы, которые происходят при установке программного обеспечения.
• Аудиторы ИТ-безопасности . Оценка рисков, возникающих при установке стороннего программного обеспечения.

Сценарии от компании Microsoft

Attack Surface Analyzer (ASA) может помочь выявить потенциальные риски безопасности, связанные с изменениями служб, учетных записей пользователей, файлов, сетевых портов, хранилища сертификатов и системного реестра. Он также поддерживает «живой» мониторинг определенных системных изменений (например, файловой системы и реестра ).

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

Основные характеристики

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

Этап 12. Создание стандартных процессов для реагирования на инциденты

Microsoft Security Response Center (MSRC), Product Security Incident Response Team (PSIRT) и Azure Security-center являются частью сообщества по реагированию на проблемы с безопасностью. Подготовка плана реагирования на инциденты (IRP) имеет решающее значение для оказания быстрой помощи при возникновении угроз.

Организациям следует создать план реагирования на инциденты (IRP) вместе со специальной группой реагирования на инциденты безопасности продуктов своей организации (PSIRT). Этот план должен включать в себя «командира инцидента» с POC. В случае чрезвычайной ситуации он сможет установить внутренний аварийный протокол для обслуживания нужд приложения. План реагирования на инциденты (IRP) должен быть протестирован и развернут до возникновения чрезвычайной ситуации.

Действия, которые следует выполнить после релиза

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

Автор переведенной статьи: Mr.Vic.

ЧИТАТЬ ВСЕ СТАТЬИ НА САЙТЕ | ПОДПИСЫВАЙТЕСЬ НА НАШ TELEGRAM КАНАЛ