Безопасность конфиденциальность по умолчанию
Жизненный цикл разработки защищенных приложений (Майкрософт) делает акцент на важности безопасности и конфиденциальности. Функции безопасности и конфиденциальности не должны быть надстройками, а должны быть центральными компонентами продуктов и служб. Мы встраиваем безопасность в наши продукты, определяя требования безопасности на ранних этапах жизненного цикла функции, поддерживая актуальные модели угроз для всех основных компонентов и функций службы и требуя ручной проверки кода для всего исходного кода.
Требования к безопасности и конфиденциальности
Требования к безопасности и конфиденциальности должны лежать в основе разработки всех приложений и систем с высокой степенью защиты. В корпорации Майкрософт все продукты, службы и функции, которые мы разрабатываем, начинаются с четко определенных требований к безопасности и конфиденциальности. Так как разработка программного обеспечения является непрерывным процессом, мы постоянно обновляем эти требования на протяжении всего жизненного цикла продукта, чтобы отражать изменения как в требуемой функциональности, так и в ландшафте угроз. Факторы, которые влияют на требования к безопасности и конфиденциальности, включают характер разрабатываемого программного обеспечения, известные угрозы безопасности, уроки, извлеченные из инцидентов безопасности, юридические и отраслевые требования, а также внутренние стандарты и методы кодирования.
Оптимальное время для определения требований к безопасности и конфиденциальности — это этапы первоначального проектирования и планирования продукта или функции. Это позволяет группам разработчиков интегрировать функции безопасности в основные функции продукта. Например, один вопрос, который мы задаем о каждом продукте на этапе проектирования, заключается в том, будет ли продукт обрабатывать конфиденциальную информацию, такую как данные клиентов. Жизненный цикл разработки защищенных приложений (Майкрософт) включает требования к безопасности и конфиденциальности, чтобы помочь разработчикам реализовать лучшие методики обработки конфиденциальных данных и обеспечить безопасное сбор, обработку и хранение конфиденциальных данных программным обеспечением в соответствии с соответствующими требованиями. Требования SDL для обработки конфиденциальных данных включают шифрование, ведение журнала и готовность к реагированию на инциденты, чтобы защитить конфиденциальные данные и предоставить группам реагирования на безопасность Майкрософт возможности аудита, необходимые для расследования потенциальных инцидентов безопасности и реагирования на них.
Модели угроз и схемы потока данных (DFD)
После того, как разработка продукта включает четко определенные требования к безопасности и конфиденциальности, группы разработчиков создают модели угроз для визуализации угроз безопасности и конфиденциальности, которые с наибольшей вероятностью могут повлиять на продукт. Моделирование угроз помогает выявлять, классифицировать и оценивать потенциальные угрозы в соответствии с риском, чтобы разработчики могли предлагать и реализовывать соответствующие меры по их устранению. SDL требует, чтобы группы разработчиков корпорации Майкрософт поддерживали актуальные модели угроз и схемы потоков данных (DFD) для всех основных компонентов и функций служб.
Моделирование угроз начинается с определения компонентов продукта или функции и построения схем их связей друг с другом для ключевых функциональных сценариев, таких как проверка подлинности или обработка конфиденциальных данных. Схемы моделирования угроз включают соответствующие потоки данных, функции и процессы, которые помогают визуализировать угрозы для службы. В рамках процесса моделирования угроз группы обслуживания создают и поддерживают DFD, которые документируют все потоки данных, порты и протоколы, используемые компонентом или функцией службы.
Завершенные схемы используются для выявления угроз для системы и определения приоритетов угроз для устранения рисков. Группы разработчиков предлагают и реализуют меры по устранению рисков, связанных с их моделями угроз. Новые меры по устранению рисков добавляются к требованиям безопасности продукта, проверяются в коде во время проверки кода вручную и автоматического тестирования, а также проверяются в процессе утверждения перед выпуском.
Так как разработка современного программного обеспечения с помощью гибкой методики делает акцент на быстрой доставке функций клиентам, моделирование угроз является непрерывным процессом. Чтобы обеспечить согласованность между командами разработчиков и поддерживать модели угроз в актуальном состоянии, корпорация Майкрософт требует от своих разработчиков использовать инструмент Microsoft Threat Modeling Tool для всех моделей угроз. Threat Modeling Tool позволяет любому разработчику или архитектору программного обеспечения корпорации Майкрософт:
- Обмениваться информацией о проектировании системы безопасности.
- Анализировать схемы безопасности на предмет потенциальных проблем безопасности с использованием проверенной методологии.
- Предлагать меры по устранению проблем безопасности и управлять ими.
Во время проверки безопасности перед выпуском все модели угроз проверяются на точность и полноту, включая меры по устранению недопустимых рисков. Эти проверки по-прежнему поддерживают отчетность и поощряют проектирование, ориентированное на безопасность.
Проверка кода вручную
Наши группы разработчиков используют Git Azure DevOps для управления версиями во всех новых репозиториях кода. Чтобы убедиться, что весь код, разработанный в Корпорации Майкрософт, соответствует требованиям к SDL и проекту, SDL требует проверки кода вручную отдельным рецензентом, прежде чем изменения кода можно будет проверить в ветви выпуска. Проверяющие кода проверяют наличие ошибок кодирования и проверяют, соответствуют ли изменения кода требованиям к SDL и проекту, проходят функциональные тесты и тесты безопасности и работают надежно. Они также проверяют связанную документацию, конфигурации и зависимости, чтобы убедиться, что изменения кода задокументированы должным образом и не вызовут непредвиденных побочных эффектов.
Если проверяющий обнаруживает проблемы во время проверки кода, он может попросить отправителя повторно отправить код с предложенными изменениями и дополнительным тестированием. Проверяющие кода также могут принять решение полностью заблокировать регистрацию кода, который не соответствует требованиям. Все изменения кода, представленные для выпуска, должны явно относиться к одному разработчику и проверяться отдельным рецензентом для обеспечения отчетности. Кроме того, все изменения в коде выпуска должны быть зарегистрированы и храниться не менее 18 месяцев, чтобы предоставить проверяемую запись всех изменений кода, а также их автора, обоснование для бизнеса, результаты тестирования и проверяющего, утвердившего изменение.