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

Kate · 31 Мар 2022

Часть 1. Как писать свой код без ошибок

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

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

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

Концепция SDLC

Начнем мы наше повествование с классической концепции Software Development Life Cycle (SDLC), состоящей из набора шагов по разработке программного продукта. Эта концепция состоит из следующих шести шагов:

Анализ требований.
Планирование.
Проектирование и дизайн.
Разработка ПО.
Тестирование.
Развёртывание.

Действия, выполняемые на каждом из этих шагов достаточно очевидны:

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

Планирование - это составление плана разработки ПО, описывающего этапность разработки.

Проектирование и дизайн это, по сути, превращение сухих требований ТЗ в архитектуру программного продукта.

С разработкой ПО все понятно. Тестирование предполагает полноценную проверку корректной работы приложения.

Ну и развертывание - это завершающий этап разработки ПО.

Waterfall – когда можно последовательно и не торопясь

Последовательное выполнение всех этих шагов предполагается в методологии Waterfall. Эта более простая и управляемая методология. При этом она успешно применяется только в тех проектах, где во время разработки какие-либо требования к проекту существенно не меняются.

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

Поэтому в современной разработке большей популярностью пользуется методология Agile.

Agile – когда все меняется

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

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

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

Концепция SSDLC

SSDLC — Secure Software Development Lifecycle — концепция разработки, заключающаяся в обеспечении безопасности разрабатываемого приложения, идентификации рисков и управления ими.

При этом, данная концепция предполагает выполнение ряда шагов еще до начала разработки программного продукта. Так перед началом разработки вся команда должна пройти Pre-SDL: Security Training — обучение информационной безопасности.

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

Во время обучения освещаются следующие темы:

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

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

Этапы непосредственной разработки здесь имеют определенный акцент на вопросы информационной безопасности.

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

Design (планирование, проектирование) — преобразования требований в план для реализации их в приложении. Здесь должны учитываться требования безопасного проектирования.

Implementation (разработка ПО) — фокусирование на качестве и факте реализации ранее спроектированных требований в коде приложения. В этот этап также входит проверка зависимостей.

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

Release — развёртывание и сопровождение, в которое входит мониторинг событий безопасности и реагирование на инциденты.

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

Повышать одновременно в нескольких командах.
Повышать комплексно.

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

Оценить уровень зрелости ИБ в компании можно с помощью фреймворка Owasp SAMM.

Owasp SAMM

Software Assurance Maturity Model — модель (фреймворк) обеспечения безопасности программного обеспечения. Этот фреймворк позволяет оценить уровень зрелости на каждой итерации развития ИБ в компании, а также предлагает набор методов по её улучшению.

Фреймворк состоит из 5 бизнес функций:

Governance;
Design;
Implementation;
Verificatio;
Operations.

Для оценки необходимо ответить на вопросы по каждому из доменов. Например, в разделе Policy & Compliance домена Governance, необходимо ответить, в том числе, на вопросы: “Есть ли у вас и применяете ли вы общий набор политик и стандартов во всей вашей организации?” и “Публикуете ли вы политики организации в виде тестовых сценариев или руководств для упрощения интерпретации командами разработчиков”. А в Design ответить на вопросы “Используете ли вы централизованные и количественные профили рисков приложений для оценки бизнес-рисков”.

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

Для автоматизации оценки существуют онлайн калькуляторы, например https://concordusa.com/SAMM/.

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

Заключение

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

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

Также хочу пригласить всех желающих на бесплатный вебинар, который 13 апреля проведут мои коллеги из Otus. На вебинаре поговорим о том, что такое ИБ (от уровня «не открывайте письма от неизвестных отправителей» до уровня «товарищ майор, мы не специально») и на что опираться (стандарты, законы), как COVID-19 пришёл и почему вечер у специалистов по ИБ перестал быть томным, коротко обсудим почему в технологии DevOps нужен Sec.