Кто такие DevSecOps -инженеры и зачем они нужны?

Добрый день, уважаемые читатели!

Сегодня я расскажу о важной и достаточно новой профессии в IT — DevSecOps -инженерах. Мы разберёмся, кто эти специалисты, чем они занимаются, и почему их роль так важна в современных процессах разработки.

Немного о себе

Меня зовут Жиляев Петр, я окончил Московский институт радиоэлектроники и автоматики по специальности «Информационная безопасность” и я уже более пяти лет работаю в области информационной безопасности.

Сегодня я занимаюсь внедрением DevSecOps-методологий и процессами сертификации программного обеспечения.

Что такое DevSecOps?

DevSecOps (акроним от слов Development, Security и Operations) — простыми словами, это методология, которая интегрирует аспекты безопасности в процесс разработки и эксплуатации ПО. DevSecOps не предполагает фундаментального изменения процессов, принятых в DevOps, но предусматривает их рассмотрение сквозь призму безопасности.

Причины появления DevSecOps

Основные причины появления DevSecOps:

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

   

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

3. Растущие угрозы.
    

   

    

   

   DevSecOps позволяет избежать этих проблем, внедряя безопасность на каждом этапе жизненного цикла разработки.

Основные задачи DevSecOps-инженера

DevSecOps-инженеры сопровождают весь жизненный цикл разработки ПО (SDLC), добавляя элементы безопасности на каждом этапе. Рассмотрим, как это работает:

1. Анализ требований

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

·       обеспечение идентификации и аутентификации;

·       обеспечение защиты от несанкционированного доступа к информации;

·       налаживание процесса регистрации событий и ошибок;

·       обеспечение контроля качества данных, поступающих в систему.

2. Планирование и анализ рисков

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

3. Дизайн/Проектирование

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

4. Разработка

На этом этапе уделяется значительное внимание качеству кода с точки зрения безопасности. Для этого используют:

✦ решения для статического тестирования безопасности приложений (SAST);

✦ анализ зависимости на наличие уязвимостей (SCA) с помощью инструментов анализа состава ПО;

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

5. Тестирование

На данном этапе внедряются дополнительные виды тестирования, такие как:

✦ тестирование на проникновение (penetration testing);

✦ тестирование отказоустойчивости (fuzz-testing — тестирование путём ввода случайных или заведомо неверных данных с целью вызвать сбой системы).

6. Развёртывание

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

7. Поддержка

Даже если ответственно подходить к безопасности на предыдущих этапах, часть уязвимостей всё равно может ускользнуть от вашего внимания и попасть в релиз. Кроме того, уже после выпуска ранее неизвестные уязвимости могут обнаружиться не только в вашем коде, но и в коде зависимостей вашего ПО. Такие уязвимости называются «уязвимостями нулевого дня». Поэтому необходимо продолжать отслеживать и оперативно устранять новые уязвимости на протяжении всего периода поддержки ПО.

Примеры угроз и уязвимостей

DevSecOps помогает справляться с различными типами угроз:

✦ Уязвимости в коде. Например, различные инъекции, которые могут привести к выполнению вредоносных команд/кода. На этапе разработки специалисты ищут их с помощью различных инструментов непосредственно в самом коде продукта.

✦ Уязвимости при развёртывании. В качестве примера подобной уязвимости может быть побег из Docker-контейнера (Docker Escape), который даёт злоумышленнику доступ к хост-системе.

✦ Угрозы в инфраструктуре Использование инструментов для мониторинга безопасности и управления уязвимостями в инфраструктуре помогает защитить приложения и данные от атак, направленных на саму инфраструктуру (например, сеть, серверы).

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

В России DevSecOps-инженеры играют важную роль в сертификации продуктов по требованиям регуляторов.
Есть ФЗ № 152 от 26.01.2007 (о ПДн), который обозначает необходимость соблюдения правил работы с персональными данными (ПДн). При этом в законе никак не обозначены технические требования, не методы. Решить эти проблемы призвана сертификация ФСТЭК, которая гарантирует, что ПО, используемое оператором для обеспечения безопасности информации, соответствует заявленным требованиям к СЗИ (средства защиты информации).

ФСТЭК (федеральная служба по техническому экспорту и контролю) ранее «Государственная техническая комиссия», предназначена для контроля информации, технологий и товаров двойного назначения (используемых в военной и гражданской сфере). 

Где используется:

✦ в значимых объектах критической информационной инфраструктуры

✦ в государственных информационных системах

✦ в автоматизированных системах управления производственными и технологическими

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

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

Инструменты DevSecOps

В работе DevSecOps-инженеры используют множество инструментов. Вот некоторые из них:

• Статический анализ: SonarQube, Checkmarx.

• Динамическое тестирование: OWASP ZAP.

• Фаззинг: AFL, libFuzzer.

• Анализ Docker-образов: Trivy.

Выводы

DevSecOps — это не просто набор инструментов или процессов, а целостная методология, которая:

✦ Обнаруживает угрозы безопасности в процессе разработки приложений. Методология DevSecOps избавляет от необходимости откладывать аудит секьюрности приложения до завершения его разработки.

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

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

✦ Соответствует стандартам безопасности отрасли. В цикле безопасной разработки DevSecOps учитываются отраслевые стандарты качества и безопасности, и продукты изначально создаются с условием полного соответствия им.

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

Интеграция DevSecOps в процессы разработки помогает компаниям оставаться конкурентоспособными и защищать свои продукты от современных угроз.