
DevSecOps: как обеспечить безопасность IT-проекта
Российские компании на почве вынужденного импортозамещения столкнулись с трудностями. Бизнес не обновлял критические компоненты IT-инфраструктуры, потому что боялся финансовых потерь из-за простоя. Не получал обновлений ПО из-за ухода иностранных поставщиков. Как следствие – число кибератак на территории России выросло в 10 раз за последние полгода.
Ситуация вынуждает серьезнее относиться к проблемам безопасности. Теперь бизнес нуждается в комплексной киберустойчивости, ведь атаки становятся точечнее и опаснее. Потому растет запрос на DevSecOps.
DevSecOps и безопасность
DevSecOps (c англ. development, security, and operations) — комплексный подход к созданию продуктов. Внедряется в процесс CI/CD для обеспечения безопасности как самого кода, так и конечной инфраструктуры.
Разница понятий SecDevOps, DevSecOps, DevOpsSec лежит на поверхности. Положение Sec намекает об этапе включения безопасности в процесс создания продукта.
- На стадии проектирования разработчики вместе с командой ИБ моделируют угрозы, выбирая решения согласно принятым методикам.
- На остальных стадиях проверяют качество разработки и соответствие стандартам организации.
Как было раньше: DevOps-инженеры раз в год делали пентесты, раз в полгода использовали автоматические инструменты тестирования. Но они не проверяли уязвимости со старта.
Сегодня DevSecOps-инженеры подключаются к разработке с самого начала: регулярно проверяют уязвимости в продукте, автоматизируют процедуру обеспечения безопасности вплоть до развертывания и доставки.
Именно так у нас в Umbrella IT строится разработка приложений на заказ для наших клиентов.
Зачем бизнесу DevSecOps
Не каждому бизнесу подходит эта методология. Когда соцсети приносят компании львиную долю прибыли, интеграция security-практик отнимет время и не принесет пользы. Хоть есть опасность взлома страниц социальных сетей, но специальное подразделение экспертов для мониторинга не требуется.
В иных ситуациях компания расширяется за счет ускорения time-to-market с сохранением качества продукта. Тогда DevSecOps-методики актуальны:
- в IT-отделе от 50 человек;
- к бизнес-процессам подключены практики CI/CD;
- IT-инфраструктура проекта базируется на микросервисном подходе.
Преимущества DevSecOps
Сокращение time-to-market
Разработчики с DevSecOps-мышлением всеми силами стремятся исключить проблемы безопасности, чтобы избежать временных потерь. Интеграция с CI/CD конвейерами (Jenkins, TeamCity) помогает молниеносно находить уязвимости и создавать тикеты об устранении ошибок. Автоматизация экономит часы работы и ускоряет time-to-market: не приходится перепроверять, а потом в последний момент исправлять уязвимости.
Обеспечение безопасности приложения
Во всех фазах цикла производства предусмотрены анализ исходного кода, поиск и ликвидация уязвимостей. Внутренние департаменты непрерывно взаимодействуют, поэтому быстрее реагируют на инциденты.
Экономия ресурсов
Контроль версий, аудит, автоматизация тестирования сохраняют деньги бизнеса при безопасной разработке приложений или сайтов. Чем оперативнее удастся отыскать уязвимость, тем дешевле обойдется ее устранение.
Если критические ошибки обнаружат прямо перед запуском, публикацию придется отложить, что повлечет за собой упущенную прибыль или прямые убытки. Поиск и устранение уязвимостей в постпродакшене стоит в 100 раз дороже, потому что занимает дополнительное время.
Лучшие практики DevSecOps
DevSecOps-методологию интегрируют, чтобы масштабироваться, управлять выпуском ПО, усиливать независимость от кибератак.
Программисты, эксперты по контролю и эксплуатации на всех стадиях жизненного цикла продукта (SDLC) должны следовать правилам.
- На первом месте стоят знания основ защиты IT-инфраструктуры продукта, уязвимостей OWASP, моделей угроз, способов тестировать его.
- Разработчики определяют, инструменты ИБ для использования и точку цикла для проведения тестов. Например, проверить билд проекта с изменениями удастся перед коммитом с помощью интеграции инструмента анализа исходного кода, например SonarQube, в IDE. Это поможет исключить критические ошибки еще в рабочей станции.
- При первичном внедрении сканеров исходного кода лучше ограничиться анализом базовых уязвимостей. Глубокое исследование в конвейере обнажит массу проблем. Их не получится устранить быстро из-за включения новых правил и конфигураций безопасности.
- Внеплановые проверки служат для получения данных об уязвимостях, чтобы корректировать работу сканеров.
- Команда поставляет обратную связь при подключении новых инструментов для эффективной настройки модели.
Типы тестирования
Компания реинжинирует IT-процессы, анализирует угрозы на каждой ступени SDLC, чтобы позаботиться о надежности проекта. Подключает ИБ-экспертов к разработчикам с фазы проектирования, и они вместе продумывают компоненты, снижающие риск возникновения уязвимостей.
Тестирование Open Source
В продукты внедряют до 80% сторонних открытых библиотек — критически важно убедиться в их надежности.
Дыры в безопасности могут обнаружиться в открытых библиотеках и компонентах сборки в промсреде. Если не фиксировать системами мониторинга, их не заметить. Инструменты ИБ предупреждают, когда в открытом ПО есть угрозы, и предлагают другие версии.
Тестирование белого ящика: SAST
SAST-инструменты анализируют все, что касается программного кода и изменений в нем. Статическое тестирование запускается на ранних стадиях работы конвейера для определения нарушения правил кодирования без выполнения программы.
Разработчики могут использовать системы непрерывной интеграции ПО – Jenkins, TeamCity, Gitlab – в IDE, чтобы видеть угрозы в привычном интерфейсе. Ревью проводится через SonarQube или вручную.
Тестирование черного ящика: DAST
Динамический анализ — проверка уязвимостей готового приложения сканерами Netsparker, Acunetix и другими.
DAST-средства подходят для выявления SQL-инъекций, межсайтовых сценариев, проблем аутентификации, ответа сервера, переполнения буфера. Действуют, как злонамеренные пользователи — атакуют проект извне, фиксируя полученные на выходе данные. Минус метода — не дает отсылок к конкретным строкам кода.
Запускается в тестовом окружении. Без изолированной тестовой среды появляется риск сломать приложение.
Пентест
Цель — взломать ПО: найти уязвимости. «Белые» хакеры вручную тестируют продукт на проникновение:
- Ищут слабые узлы, погрешности настройки протоколов и иные способы доступа посторонних в сеть.
- Мешают работе сеансов, подделывают запросы, пытаются получить доступ к базе данных.
- Добывают пароли через брутфорс, определяют слабые аппаратные места.
- Взламывают дата-центры и другие помещения, где расположено оборудование.
В конце проверок пентестеры генерируют рекомендации для защиты IT-инфраструктуры от взлома.
Препятствия реализации принципов DevSecOps
Внедрение DevSecOps занимает минимум год — не всякий бизнес готов к такой трудоемкой процедуре.
Недостаточная квалификация
Только подготовленные инженеры справятся с настройкой правил и методов сканирования уязвимостей комплексной IT-инфраструктуры. Не в каждой компании есть такие эксперты.
Трудности интеграции инструментов
Организации подключают популярные бесплатные программы, такие как Jenkins. Опасность в том, что из-за них возникают множественные ошибки, недопустимые для сложного проекта. Ряд альтернативных вариантов не поддерживается в России в условиях санкций. Программистам приходится тратить массу времени на поиск обходных путей.
Нет единого инструмента CI
Компания использует конкретные инструменты ИБ под определенные задачи, что усложняет деятельность команды. Разработчики приспосабливаются к условиям, как получается. Отключают внедренные средства или игнорируют ступени обеспечения безопасности приложения или сайта. Отдел ИБ узнает о ситуации, когда она станет критической.
Мало экспертов ИБ
Или один на шесть команд программистов: он не успевает решать поставленные задачи.
Устаревший legacy-код
У ряда компаний главная проблема — поддержка и анализ информационной безопасности старого приложения. В подобный проект либо не получается внести изменения, либо никто не хочет этого делать.
Нет фокуса на безопасности
Внедрение инструментов безопасности DevSecOps требует внесения изменений в готовые скрипты. Если у команды иные приоритеты, это невозможно.
Проверка непосредственно перед релизом
Инженер запускает пентест. После проверки составляет список выявленных уязвимостей. Команда негодует, потому что требуется вносить правки, когда цикл разработки пройден. Компания теряет ресурсы из-за отсрочки релиза по причине несогласованности действий департаментов.
Заключение
Если при оценке бизнес-процессов выяснилось, что IT-инфраструктура не отвечает требованиям к киберустойчивости, помогут лучшие практики DevSecOps. Они обеспечат безопасность кода, контейнеров, пакетов при сборке — ускорят запуск проекта благодаря комплексным мерам по автоматизации разработки и тестирования.





