Контакты
Подписка 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.
  • Внедряйте постепенно, начиная без влияния на релизы.

 

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

Инструменты и решения для защиты информации и предотвращения кибератак
Конференция | 2 апреля 2024

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

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

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

Печатное издание
Интернет-портал
ВЫСТУПИТЬ НА КОНФЕРЕНЦИЯХ
СТАТЬ АВТОРОМ
Персональные данные
4 апреля. Персональные данные в 2024 году: регулирование, практика, тенденции
Участвуйте!

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