Контакты
Подписка 2024

Как обеспечить безопасность разработки, сохранив время и нервы? Ответ "Ростелекома"

Ярослав Александров, 22/07/19

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

Как бизнесу и ИТ правильно интегрировать безопасность в процесс разработки, какие инструменты для этого лучше использовать, как это все ложится на реальную практику внедрения. Делимся подходами Ростелеком, М.Видео-Эльдорадо, DD Planet, AGIMA.

Ярослав Александров, руководитель отдела разработки Solar appScreener в Ростелеком

АлександровС ростом компании и увеличением числа разработчиков проверять продукт на уязвимости “вручную” становится все сложнее. Приходится использовать SAST — средства статического тестирования защищенности приложений (Static Application Security Testing). В Solar appScreener информационная безопасность строится на базе внутреннего продукта. Продукт анализирует исходные коды. На сегодня поддерживается  26 языков программирования, исходники которых могут быть проанализированы уязвимость, и поддерживает все популярные форматы и системы управления проектами. 

Как выбрать SAST?

Даже простую уязвимость невозможно отыскать при помощи примитивных алгоритмов. Сегодня на рынке представлена масса SAST-решений, как платных, так и бесплатных. Самые популярные  из них — AppScan от IBM Security, Synopsys, Veracode, Application Inspector, Micro Focus, Appercut, Checkmarks.

От выбора инструмента зависит эффективность процесса разработки. Главные преимущества платных решений:

  • Фокус на безопасность: специфические алгоритмы и большие базы правил.
  • Поддержка множества языков программирования.
  • Удобный интерфейс.
  • Наличие плагинов и API.
  • Наличие технической поддержки инструмента.

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

После того как SAST-решение выбрано, нужно интегрировать его в процесс разработки. Возможности интеграции могут быть следующими: встраивание инструмента в репозиторий, среды разработки, серверы CI/CD, системы отслеживания задач. Хороший инструмент способен успешно встраиваться во все перечисленные классы систем. 

Примечание: открытый API SAST включает JSON API и CLI и предоставляет широкие возможности по дополнительной интеграции и автоматизации.

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

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

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

Нюансы и тонкости анализа кода 

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

Скорость и ресурсы: обычно ожидается, что инструмент будет работать быстро; запускаться на каждое изменение; показывать «на лету», кто и когда внес уязвимость. На самом деле SAST анализирует код не менее 8 часов, его сложно запускать на каждое изменение; трудно определить автора уязвимости; случаются ложные срабатывания. А значит, возникает вопрос: как настроить DevSecOps.

Здесь очень важно:

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

К примеру, можно запускать тестирование с помощью SAST, когда разработчик отправляет задачу на ревью. Можно также запускать сканирование и по окончании рабочего дня.

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

Работая над интеграцией SAST в процесс разработки, важно внедрять процессы постепенно без блокирования релиза. Последовательность процесса может быть такой: 

  • Выбор инструмента.
  • Описание процесса (создание регламента).
  • Описание технических решений.
  • Проведение работ по внедрению.
  • Опытная эксплуатация.

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

В регламенте нужно обязательно обозначить :

  • Шаги проверки кода на уязвимости.
  • Ответственного за запуск сканирования.
  • Роли и результаты.
  • Как будет налажен процесс коммуникации.
  • Service Level Agreement.
  • Ответственных за контроль процесса.
  • Порядок добавления новых систем к процессу.

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

Итоговые рекомендации:

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

 

Темы:РостелекомКибербезопасностьМнения экспертовБезопасная разработка

Отечественные ИT-платформы
и ПО для объектов КИИ:
готовность к 1 января 2025
Конференция | 24 июля 2024

Жми для участия
Обзоры. Спец.проекты. Исследования
Участвуйте в обзорах / исследованиях проекта "Информационная безопасность"!
Станьте автором журнала!
Статьи по той же темеСтатьи по той же теме

  • Как соответствовать требованиям ЦБ РФ при защите мобильных приложений
    Юрий Шабалин, Ведущий архитектор Swordfish Security
    Профиль защиты прикладного программного обеспечения – это методический документ Банка России, согласно которому приложения должны проходить оценку на соответствие госстандарту в специальных лабораториях.
  • 6 мифов о безопасной разработке и сертификации ПО
    Дмитрий Пономарев, технический директор ООО НТЦ “Фобос-НТ”, сотрудник ИСП РАН
    За последние пять лет система сертификации СЗИ претерпела колоссальные изменения, практически сменив свой вектор, и продолжает активно развиваться. Если вы проходили испытания до 2019 г., или даже до 2023 г., скорее всего вы будете сильно удивлены числу произошедших перемен и их объему.
  • Управление уязвимостями при разработке ОС Astra Linux
    Владимир Тележников, директор департамента научных исследований “Группы Астра”
    Управление уязвимостями играет ключевую роль в процессе разработки и эксплуатации любой операционной системы.
  • Protestware: как защитить код?
    Владимир Исабеков, ведущий инженер по информационной безопасности Swordfish Security
    Первым и важным шагом к снижению риска от вредоносного Protestware является стандартный инструментарий безопасной разработки.
  • Как организовать процесс безопасной разработки в 5 шагов
    Константин Саматов, Член Правления Ассоциации руководителей службы информационной безопасности
    Разберем значение процесса РБПО в организации, его создание, сложности и пути их преодоления.
  • Сертификация СЗИ – курс на РБПО
    Дмитрий Пономарев, технический директор ООО НТЦ “Фобос-НТ”, сотрудник ИСП РАН
    На рубеже 2023–2024 гг. положение разительно отличается от картины пятитилетней давности. Практики РБПО требуются повсеместно, их выполнение зачастую является одним из базовых пунктов контракта.

Хотите сотрудничать?

Выберите вариант!

Печатное издание
Интернет-портал
ВЫСТУПИТЬ НА КОНФЕРЕНЦИЯХ
СТАТЬ АВТОРОМ
Кибербезопасность
30 июля. Кибербезопасность предприятия: защита от современных угроз
Участвуйте!

More...
Обзоры. Исследования. Спец.проекты
Обзоры и исследования проекта "Информационная безопасность"
Жми, чтобы участвовать

More...