Роль директора по информационной безопасности (CISO) полна противоречий. Обеспечивать безопасность корпоративной инфраструктуры, но не тормозить бизнес. Работать с разработчиками над созданием более безопасного кода, но не задерживать разработку. Часто испытывая нехватку ресурсов, CISO с трудом справляются с ежедневными требованиями, когда речь идет об общих проблемах безопасности, угрожающих бизнесу. Рост непрерывной интеграции и непрерывного развертывания (CI/CD) и ориентированных на разработчиков процессов разработки, таких как DevOps, только добавляет им хлопот, пишет на портале TechBeacon Мартин Кноблох, глобальный стратег Micro Focus по AppSec.

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

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

Неведение и неправильные представления

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

Поэтому им легко упустить из виду сложность современной разработки ПО. Переход к практике DevOps, более ориентированной на разработку, часто воспринимается неправильно — как своего рода Дикий Запад без ограничений и рамок для разработчиков. Между тем, нежелание разработчиков добавлять трудоемкое тестирование безопасности в автоматизацию CI/CD ошибочно воспринимается как сопротивление безопасности в целом, а рецидивы отдельных проблем — как отсутствие заботы о безопасности.

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

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

Сходство и взаимное уважение

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

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

Создание альянсов

Служба безопасности должна сотрудничать с командой разработчиков при выборе инструментов, поскольку инструменты должны соответствовать их целям и среде. Интеграция CI/CD с непрерывным тестированием безопасности требует, чтобы эксперты по безопасности стали спонсорами инструментов и наставниками по части решений. Никогда не будет 100%-но безопасного развертывания, мы должны постоянно отслеживать и реагировать на постоянно меняющуюся реальность. Отзывчивость — это ключевое качество DevOps, которое службы безопасности могут максимально использовать для поддержания оптимального уровня безопасности или возвращения к нему.

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

Будьте проводником безопасности в вашей организации

В конце концов, поговорка «Неизвестное хуже худой вести» определенно справедлива для лагерей разработчиков и безопасников. Наведение мостов и междисциплинарные коммуникации — два игнорируемых требования успешной практики безопасности. Специалисты по ИТ-безопасности должны понимать, что они не сторожат артефакты или ценности. Скорее, они направляют тех, кто будет отвечать за обеспечение безопасности цифрового бизнеса. Они могут добиться этого, только создавая четкие политики, формулируя понятные рекомендации и, самое главное, создавая альянсы.