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

Разработка безопасного программного обеспечения по ГОСТ Р 56939-2016

5 сентября, 2016

Ваш провайдер знает о вас больше, чем ваша девушка? Присоединяйтесь и узнайте, как это остановить!

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

Часть 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;

• Verificatio;

• Operations.

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

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

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

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

Заключение

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

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

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

Практические аспекты построения процесса безопасной разработки программного обеспечения

Игорь Беляков, 14/06/20

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

Игорь Беляков
CISO kupibilet.ru, к.т.н.

Реализация рисков на этапе эксплуатации может привести к серьезному финансовому и репутационному ущербу. Финансовый ущерб, как правило, включает в себя затраты на устранение уязвимости и выпуск новой версии программы, а также упущенную выгоду, которая может стать следствием снижения интереса клиентов к небезопасному приложению. Безопасная разработка программного обеспечения (Secure Software Development Lifecycle – SSDL) представляет собой подход, нацеленный на своевременное выявление и устранение уязвимостей в исходном коде. Построение SSDL силами разработчика программного обеспечения является наиболее верным решением, ведь именно разработчик заинтересован в снижении накладных расходов на поддержание продукта.

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

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

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

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

В сложившейся практике внедрение SSDL сводится к включению средства статического анализа исходного кода (Static Application Security Testing – SAST) в процесс тестирования приложения. Как правило, тестирование безопасности приложения осуществляется одновременно с функциональным тестированием (Quality Assurance – QA). То есть если приложение успешно проходит все проверки, его можно отправлять в промышленную эксплуатацию.

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

1. GIT – распределенная система управления версиями, хранения и версионирования исходного кода.
2. CI (Continuous Integration – непрерывная интеграция) – основная логика распространения новых версий программного обеспечения. Непрерывная интеграция – это практика разработки программного обеспечения, которая заключается в постоянном слиянии рабочих копий в общую основную ветвь разработки (до нескольких раз в день) и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем.
3. SAST – средство статического анализа исходного кода. Основной инструмент для поиска уязвимостей.

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

1. Нарушение синтаксиса языка. Чаще всего такие уязвимости вызывают нарушение работы приложения.
2. Использование уязвимых функций или библиотек. В последнее время достаточно часто появлялась информация о внедрении вредоносного кода в Open Source, библиотеки или иные расширения. Так как многие коммерческие продукты используют сторонние библиотеки без дополнительной проверки, уязвимость библиотеки становится уязвимостью приложения.
3. Хранение отладочных данных в исходном коде. Часто случаются ситуации, когда в исходном коде приложения записаны логины и пароли, используемые для отладки или тестирования. Получив доступ к исходному коду, злоумышленник может получить доступ и к приложению.
4. Ошибки конфигурации приложения. Чаще всего сводятся к некорректной настройке используемых протоколов, а также внешних модулей и иных систем, включая базы данных. Такие ошибки позволяют получить несанкционированный доступ к информации.
5. Обработка данных, полученных без предварительной проверки. Чаще всего источником таких данных является пользователь, который может ввести различные сомнительные сведения в приложение. Отсутствие проверки позволяет загрузить даже вредоносное программное обеспечение.
6. Неиспользуемые участки кода, которые могут содержать логические бомбы или бэкдоры. В рамках сложных атак неиспользуемые участки кода могут быть незаметно изменены злоумышленником и использованы для манипуляции приложением.

Как создать безопасное ПО?

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

1. Разработка. На данном этапе создается новый функционал, проверяется корректность его работы и сохраняется в основной проект (Сommit) в GIT. Хорошим тоном считается регулярное создание резервных копий репозитория, что позволяет снизить риск утраты важного актива.
2. Сборка. После накопления необходимого количества изменений по решению руководителя проекта в CI осуществляется сборка нового релиза проекта.
3. Контроль. На данном этапе собранный релиз отправляется на функциональное тестирование и проверку безопасности. Все испытания должны обязательно выполняться в тестовой среде и с использованием тестовых данных. По результатам испытаний формируется заключение о возможности промышленной эксплуатации новой версии программы.
4. Промышленная эксплуатация. Если проект успешно прошел все проверки, тогда он передается в промышленную эксплуатацию, т.е. выпускается новая версия программы. В свою очередь, сборка и внедрение новой версии программы обеспечивается системами CI/CD (Сontinuous Integration/Either Continuous Delivery or Continuous Deployment). Наиболее распространенные системы данного класса обладают всем необходимым функционалом для обеспечения хранения исходного кода, сборки новых версий, запуска задач тестирования и внедрения новых версий программы.

Роль SAST в создании безопасного приложения

Существует два основных варианта интеграции статического анализа кода (SAST) в процесс разработки:

1. Наиболее правильным является выполнение статического анализа сразу после сборки релиза приложения. В данном случае CI передает собранный релиз на функциональное тестирование и на проверку безопасности. Если в приложении не выявлены функциональные нарушения или уязвимости, CI осуществляет выпуск приложения в промышленную эксплуатацию.
2. Если процесс непрерывной разработки уже выстроен и функционирует исправно, то есть смысл в реализации параллельной проверки исходного кода. При таком подходе сканер исходного кода осуществляет регулярную проверку репозитория приложения (как правило, ветки Мaster) на наличие уязвимостей. Чаще всего сканирование осуществляется по рабочим дням в часы наименьшей нагрузки, как правило ночью. Отчет о результатах такого исследования направляется ответственным сотрудникам, которые могут принять решение о необходимости оперативного устранения уязвимости.

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

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

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

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

Тестирование при разработке безопасного ПО

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

1. Запрещается использовать одни и те же данные в процессах разработки, тестирования и эксплуатации. При нарушении этого требования возможны риски несанкционированного доступа к «боевому приложению» через тестовые учетные записи, а также риск разглашения конфиденциальной информации, используемой для тестирования.
2. Необходимо обеспечить техническую идентичность всех сред функционирования приложения для обеспечения релевантности результатов.
3. Необходимо обеспечить версионированность приложения для четкой идентификации результатов разработки и тестирования.

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

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

Популярные сообщения из этого блога