Security for all - #38 - 15 апреля 2022

Один в поле не воин - SDL

Сегодня

Процесс разработки ПО не такой простой, как может показаться. Он состоит из нескольких крупных стадий. Сначала появляется идея. Потом продумывается архитектура - из каких компонентов будет состоять продукт и как эти компоненты будут взаимодействовать между собой. Только после этого пишется код. Когда он написан, наступает фаза тестирования. Затем продукт выпускается и поддерживается. Потом придумывается новая функциональность и все начинается сначала. В ходе разработки приходится решать большое количество проблем и придумывать разные решения. Разработчики больше сосредоточены на функциональности приложения, и не всегда удается уделить достаточное время безопасности. Сегодня я расскажу, какие есть подходы к разработке более безопасного ПО.

История Security Development Lifecycle

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

Все поменялось с приходом интернета в 90-х годах. На тот момент уже существовали персональные компьютеры и доступ к ним имело относительно большое количество людей. С приходом глобальной сети, можно было получать доступ к другим системам. Появились вредоносные программы - вирусы, трояны. Многие технологии тогда были в новинку. В среде интернет стали встречаться “невозможные” вещи, например, системы бухгалтерского учета, которые по ошибке или незнанию сделали публично доступными.

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

В 1999 компания пошла еще дальше и создала программу “Secure Windows Initiative”. В рамках этой инициативы были выделены три менеджера, которые проводили анализ различных компонентов Windows. Они должны были находить проблемы безопасности и заводить задачи для их устранения на соответствующие команды разработки. После исправления этих проблем по задумке должен был получиться безопасный продукт.

В 2001 году инициатива развилась в командные тренинги и “bug bushes” - в некоторые дни утром проводилось обучения по разным темам, а после обеда разработчики проводили тестирование, ревью кода и поиск проблем безопасности.

Затратив такое количество времени и ресурсов на безопасность люди в компании Microsoft предполагали, что выпущенная во второй половине 2001 года Windows XP сделана достаточно надежно и ее безопасность “на уровне”. Однако, их ждало разочарование.

Code Red во второй половине июля заразил более 300 тысяч компьютеров. Nimda в сентябре 2001 за 22 минуты стал самым распространенным в интернете червем. В компоненте UPnP (Universal Plug and Play) были найдены несколько уязвимостей. Две из этих уязвимостей вызвали отказ в обслуживании. И проблема была не в имплементации, а в логике работы компонента и протокола UPnP. В случае с Universal Plug and Play уязвимости не эксплуатировались активно. Но даже их наличие было плохим знаком.

И сама компания это понимала, и пользователи говорили, что надо что-то делать. Это что-то вылилось в итоге в письмо Билла Гейтса к сотрудникам компании. Темой письма были “Благонадежные Вычисления” (“Trustworthy Computing” на языке оригинала - https://www.wired.com/2002/01/bill-gates-trustworthy-computing/, https://news.microsoft.com/2012/01/11/memo-from-bill-gates/). В своем сообщении Билл Гейтс задал вектор развития и приоритеты для компании - непрерывность сервисов, безопасность, приватность. Главной целью стало заслужить доверие пользователей. Доверие к производимому ПО и доверие к сервисам, которые предоставляла компания.

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

Набранный опыт не пропал даром. В 2004 году руководству компании был представлен SDL - Security Development Lifecycle - Цикл Безопасной Разработки.

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

Обучение и вовлечение

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

Требования

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

Дизайн

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

Также на этом этапе идет анализ поверхности атаки - тех входных точек, которые будут подвержены риску атаки в большей степени, и моделирование угроз. Моделирование угроз это отдельная тема. В рамках этой активности анализируются компоненты приложения, их связи, потоки данных и границы доверия между компонентами. Для упрощения этого непростого процесса была создана специальная утилита - Microsoft Threat Modeling Tool.

Имплементация

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

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

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

Реагирование

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

Адаптация к процессу разработки

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

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

Заключение

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

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

Ссылки

История создания SDL от одного из авторов - https://www.youtube.com/watch?v=rReXXg1rdkw&list=PLA388F3E903B237BD&index=1

Steve Lipner один из авторов SDL - https://www.microsoft.com/security/blog/2012/03/26/introducing-steve-lipner/

Видео и примеры кода к книге “Writing Secure Code” - https://ptgmedia.pearsoncmg.com/imprint_downloads/microsoftpress/companionfiles/9780735622142_files.zip

Celebrating 20 Years of Trustworthy Computing - https://www.microsoft.com/security/blog/2022/01/21/celebrating-20-years-of-trustworthy-computing/

До следующего выпуска.