Часть 1. Как писать свой код без ошибок
На сегодняшний день трудно представить себе какую-либо отрасль бизнеса, в которой не использовались бы информационные технологии. Не только в банковской сфере, но и в промышленности, транспорте, сельском хозяйстве – везде ИТ играют огромную роль. У каждой отрасли своя специфика и найти готовое приложение, которое бы полностью удовлетворяло потребности конкретной организации не всегда возможно.
Кроме того, нынешняя геополитическая обстановка жестко диктует свои условия – западные вендоры массово уходят с российского рынка, запрещая продажу лицензий и снимая с поддержки свои решения. Все это также требует разработки собственного программного обеспечения, причем в довольно сжатые сроки.
И если многие крупные заказчики поручают создание приложений компаниям разработчикам ПО с многолетним опытом и компетенциями, то небольшие организации с более скромными бюджетами нанимают для разработки программистов, часто студентов. При этом многие разработчики в погоне за сроками и прибылью сознательно пренебрегают требованиями безопасной разработки программного кода. В этой статье мы поговорим об основных принципах и методологиях, которые используются для безопасной разработки. А во второй части статьи рассмотрим методы и средства поиска уязвимостей в чужом программном коде.
Концепция SDLC
Начнем мы наше повествование с классической концепции Software Development Life Cycle (SDLC), состоящей из набора шагов по разработке программного продукта. Эта концепция состоит из следующих шести шагов:
1. Анализ требований.
2. Планирование.
3. Проектирование и дизайн.
4. Разработка ПО.
5. Тестирование.
6. Развёртывание.
Действия, выполняемые на каждом из этих шагов достаточно очевидны:
Анализ требований предполагает получение от заказчика информации о том, какой функционал он хотел бы видеть в разрабатываемом приложении. На основании этого формируются требования для технического задания.
Планирование - это составление плана разработки ПО, описывающего этапность разработки.
Проектирование и дизайн это, по сути, превращение сухих требований ТЗ в архитектуру программного продукта.
С разработкой ПО все понятно. Тестирование предполагает полноценную проверку корректной работы приложения.
Ну и развертывание - это завершающий этап разработки ПО.
Waterfall – когда можно последовательно и не торопясь
Последовательное выполнение всех этих шагов предполагается в методологии Waterfall. Эта более простая и управляемая методология. При этом она успешно применяется только в тех проектах, где во время разработки какие-либо требования к проекту существенно не меняются.
Однако, при разработке серьезных приложений крайне сложно придерживаться изначальных требований, так как за время выполнения одного шага многое может поменяться, как в технике (выйти новые версии или обновления для ОС и ПО), так и в бизнесе заказчика (слияние с другой компанией, выход на IPO). Также могут появиться обстоятельства непреодолимой силы, такие как санкции.
Поэтому в современной разработке большей популярностью пользуется методология Agile.
Agile – когда все меняется
Общая суть этой методологии можно описать словами: работающий продукт важнее исчерпывающей документации, сотрудничество с заказчиком важнее согласования условий контракта, готовность к изменениям важнее следования первоначальному плану».
Данная методология хорошо подходит для продуктов, у которых часто меняются бизнес-требования и отсутствуют специфические требования к надёжности.
Если до этого мы говорили об SDLC, то есть о разработке программных продуктов, то теперь перейдем непосредственно к теме безопасной разработки.
Концепция SSDLC
SSDLC — Secure Software Development Lifecycle — концепция разработки, заключающаяся в обеспечении безопасности разрабатываемого приложения, идентификации рисков и управления ими.
При этом, данная концепция предполагает выполнение ряда шагов еще до начала разработки программного продукта. Так перед началом разработки вся команда должна пройти Pre-SDL: Security Training — обучение информационной безопасности.
При этом, так как уровень подготовки членов команды в области ИБ может существенно различаться, предварительно необходимо провести исследование подготовки сотрудников по темам безопасности и защиты данных. На основании собранных данных разрабатывается система обучения и проводятся тренинги для поддержания безопасности персонала.
Во время обучения освещаются следующие темы:
1. Безопасное проектирование.
2. Моделирование угроз.
3. Безопасная разработка.
4. Тестирование ПО в части безопасности.
5. Обеспечение приватности.
Только после прохождения обучения и успешной сдачи тестов по данным темам команда может приступать непосредственно к разработке.
Этапы непосредственной разработки здесь имеют определенный акцент на вопросы информационной безопасности.
Requirements — анализ требований всех заинтересованных сторон. Здесь должны учитываться в том числе модели угроз как для корпоративной инфраструктуры, так и для разрабатываемых систем.
Design (планирование, проектирование) — преобразования требований в план для реализации их в приложении. Здесь должны учитываться требования безопасного проектирования.
Implementation (разработка ПО) — фокусирование на качестве и факте реализации ранее спроектированных требований в коде приложения. В этот этап также входит проверка зависимостей.
Verification — верификация, тестирование. При этом важно проводить тестирования в части аспектов информационной безопасности, в частности использовать проверки на наличие уязвимостей в коде.
Release — развёртывание и сопровождение, в которое входит мониторинг событий безопасности и реагирование на инциденты.
Основной проблемой такого подхода является то, что нельзя внедрить эту концепцию пошагово, как она описана в документе. Как уже упоминалось чуть выше, у каждой команды в компании уже есть уровень зрелости в ИБ, который требуется:
1. Повышать одновременно в нескольких командах.
2. Повышать комплексно.
При этом каждый следующий уровень зрелости сложнее, чем предыдущий.
Оценить уровень зрелости ИБ в компании можно с помощью фреймворка Owasp SAMM.
Owasp SAMM
Software Assurance Maturity Model — модель (фреймворк) обеспечения безопасности программного обеспечения. Этот фреймворк позволяет оценить уровень зрелости на каждой итерации развития ИБ в компании, а также предлагает набор методов по её улучшению.
Фреймворк состоит из 5 бизнес функций:
· Governance,
· Design,
· Implementation,
· Verification
· Operations.
Для оценки необходимо ответить на вопросы по каждому из доменов. Например, в разделе Policy & Compliance домена Governance, необходимо ответить, в том числе, на вопросы: “Есть ли у вас и применяете ли вы общий набор политик и стандартов во всей вашей организации?” и “Публикуете ли вы политики организации в виде тестовых сценариев или руководств для упрощения интерпретации командами разработчиков”. А в Design ответить на вопросы “Используете ли вы централизованные и количественные профили рисков приложений для оценки бизнес-рисков”.
Всего необходимо ответить почти на сто вопросов. По результатам ответов по каждому из доменов вычисляется оценка
Для автоматизации оценки существуют онлайн калькуляторы, например https://concordusa.com/SAMM/.
По результатам полученной оценки относительно максимума вы можете оценить уровень зрелости разработки в компании и понять по каким из приведенным направлениям необходимо провести дополнительное обучение разработчиков.
Заключение
В этой статье основной упор был сделан на теоретические аспекты безопасной разработки собственного программного кода. Однако, без фундаментального понимания теории сложно реализовать безопасную разработку на практике.
Но в следующей статье мы рассмотрим немного другую ситуацию, когда у вас уже имеется приложение с исходным кодом и необходимо проверить этот код на наличие уязвимостей. И в этой статье практики будет намного больше.
