Обычно программисты стараются работать отдельно от специалистов по кибербезопасности, оставляя время на сотрудничество только при проведении плановых аудитов. В результате между ними нередко возникают разногласия и конфликты, которых можно было бы избежать.
Введение
В процессе построения корпоративных ИТ-систем или адаптации уже внедрённых программных продуктов под новые требования всегда возникают дополнительные задачи, связанные с контролем безопасной разработки, устранением рисков в кибербезопасности, решением других вопросов, которые традиционно рассматриваются во время проведения аудита новых продуктов.
Задачи безопасного внедрения ИТ-систем охватываются методологией DevSecOps (Development Secure Operations). Она призвана усовершенствовать традиционный процесс разработки приложений, подразумевающий, что программисты пишут код, а специалисты по кибербезопасности контролируют его защищённость. Часто между этими смежными командами возникают не просто разногласия, а настоящие споры и конфликты. Они непременно требуют решения, и в процессе подготовки новых продуктов к эксплуатации внутри компании обойти их невозможно.
Разработчики часто считают, что безопасники существуют «только для того, чтобы мешать им делать свою работу». Они расценивают их требования как чрезмерно консервативные, направленные на устранение «крайне редких, практически несуществующих рисков».
Безопасники в свою очередь рассматривают программистов как «нарушителей порядка», которые, «не заботясь ни о чём, торопятся запустить свои разработки в эксплуатацию, минуя этап, когда необходимо убедиться, что управление в компании, безопасность и нормативно-правовой контроль (комплаенс) полностью соблюдены и не несут риска».
Такой «клубок интересов» порождает в итоге множество заблуждений о том, как всё происходит на самом деле и как сделать так, чтобы добиться эффективного результата.
Пракаш Сетураман, CISO компании CloudBees, поделился своим видением этих вопросов. Они были опубликованы на сайте HelpNetSecurity, и теперь с ними можно познакомиться в нашем материале.
Рисунок 1. Пракаш Сетураман, CISO компании CloudBees
Заблуждения в DevSecOps
Пракаш Сетураман систематизировал главные причины, которые, на его взгляд, вызывают недопонимание реальных процессов в операциях DevSecOps. Они представлены далее.
1. Заблуждение: проверки на комплаенс и соблюдение требований по безопасности можно выделить в особый этап процесса подготовки корпоративного ПО к эксплуатации.
Реальность: как показывает практика, наиболее эффективный контроль за соблюдением требований по безопасности удаётся реализовать тогда, когда они отслеживаются на протяжении всего процесса разработки и внедрения ПО.
Если же в компаниях относятся к проверке соблюдения требований по безопасности как к разовым мероприятиям, то в этом случае придётся многократно отвлекаться на проведение аудитов, привлекать для этого разработчиков, мешая им выполнять свои основные задачи.
«Потери» получаются весьма ощутимыми, считает Пракаш Сетураман. Это объясняется тем, что когда вопросы безопасности не прорабатываются с момента запуска проекта, безопасникам приходится тратить значительно больше времени и усилий на выявление и устранение проблем. При этом их работа не добавляет ощутимой «продуктовой» ценности создаваемому ПО.
2. Заблуждение: для решения задач по обеспечению безопасности и комплаенса достаточно оснастить разработчиков дополнительными инструментами для проведения контроля.
Реальность: хотя использование вспомогательных инструментов для контроля безопасности и комплаенса, безусловно, помогает в решении соответствующих задач, сами по себе эти программные средства, как правило, не позволяют решить саму проблему целиком. Применение этих инструментов требует соответствующей квалификации, полученные результаты необходимо подвергать анализу.
После этого формируются рекомендации, которые передаются менеджерам по развитию продукта. Те должны потратить время, чтобы оценить их значимость и выработать приоритеты для осуществления дальнейших операций в процессе внедрения ПО. Поставленные задачи потребуется выполнить разработчикам.
На всё требуются время и затраты. Более того, перенасыщение экосистемы вспомогательными инструментами ведёт к росту её сложности. Более эффективный подход — найти комплексное решение, которое обеспечит сокращение угроз и избавит от потенциальных отказов.
3. Заблуждение: для соблюдения комплаенса достаточно ограничиться обучением разработчиков.
Реальность: в действительности, многое при внедрении ПО происходит совершенно иначе, чем это видится тренерам. Разработчики, которых они обучают, нацелены в первую очередь на изучение новых технологий и их внедрение в свои продукты. Они готовы с интересом изучать и внедрять инновационные решения, а не заниматься проведением тестов для контроля безопасности и чтением нормативных актов. Такие операции они считают скучными и малопродуктивными.
В то же время к реализации требований по безопасности необходимо подходить с особым вниманием. Это должно стать нормой для разработчиков.
Но ожидать, что они будут с большим усердием заниматься задачами обеспечения безопасности помимо своих прямых обязанностей, — это заблуждение. Выдвигаемые ИБ-специалистами требования они чаще всего воспринимают в штыки. Те вызывают у них недовольство. Программисты обвиняют безопасников в сдерживании инноваций в угоду своим «маниакальным требованиям».
4. Заблуждение: для устранения разногласий достаточно ввести в команду DevSecOps отдельного участника из команды безопасников.
Реальность: без сомнения, участие эксперта по безопасности в работе отдела по разработке корпоративного ПО способно оказать помощь разработчикам, чтобы те могли лучше понимать проблемы связанные с безопасностью. Появление такого специалиста в команде DevSecOps может обеспечить более эффективное внедрение инноваций.
В то же время многое будет зависеть от личных взаимоотношений, которые установятся внутри коллектива DevSecOps. В случае появления разногласий раскол между командами может, наоборот, усилиться.
5. Заблуждение: небольшие компании, не занимающиеся бренд-продвижением, не сталкиваются с кибератаками.
Реальность: в действительности, угрозы кибербезопасности растут в первую очередь не от масштабов компании и её известности на рынке, а из-за увеличения того материального ущерба, который способны нанести современные кибератаки, например, за счёт кражи конфиденциальной информации, персональных данных. В последнее время добавились ещё и политические риски, которые подталкивают киберпреступников к активным действиям.
В нынешней ситуации ни одна компания не может чувствовать себя в полной безопасности. Бизнес всегда связан с коммерцией, потери прибыли из-за киберпреступлений могут быть весьма ощутимыми даже для малых компаний.
6. Заблуждение: при внедрении средств автоматизации повышается уровень безопасности ПО и обеспечивается более высокий уровень комплаенса.
Реальность: для повышения безопасности корпоративного ПО и обеспечения его соответствия требованиям законодательства и нормативных актов несомненно полезно внедрять автоматизацию. Она становится ключевым фактором для реализации этих целей.
В то же время многие инструменты автоматизации представляют собой всего лишь точечные решения для выполнения локальных задач. Они не обеспечивают сквозной автоматизации.
Конечно, части процесса вывода ПО в производство, затронутые автоматизацией, после развёртывания таких инструментов становятся более безопасными. Однако изъяны на других этапах не исчезают. Снижение внимания к ним может понизить уровень безопасности в целом.
Соответственно, необходимо стремиться к тому, чтобы внедрять автоматизацию сразу на всех этапах вывода ПО. Только в этом случае можно говорить о качественном росте безопасности в целом.
7. Заблуждение: команде DevSecOps достаточно поставить соответствующие задачи.
Реальность: увы, действительность далека от такой идеализированной картинки. Для решения задач DevSecOps недостаточно просто нанять сотрудников и сформировать из них команду, которая знает о существующих требованиях. Между командами прикладных разработчиков и безопасников нередко возникают противоречия, разрешение которых требует участия руководителя. Иначе разногласия могут переходить в серьёзные конфликты.
Для устранения разногласий недостаточно просто переставлять этапы подготовки ПО к производству. Необходимо выстраивать особую культуру внутри компании, чтобы все участники понимали важность соблюдения требований по безопасности. В то же время и безопасникам необходимо осознавать, что внедрение инноваций и повышение производительности ПО должны являться главным приоритетом для всех участников процесса.
Выводы
Компания CloudBees, которую представляет автор данной подборки мифов о DevSecOps, специализируется на внедрении ИТ-решений в крупных компаниях. Среди её клиентов — Matrix Partners, Lightspeed Venture Partners, HSBC, Verizon Ventures, Golub Capital, Goldman Sachs, Morgan Stanley и Bridgepoint Group. Автор делает однозначный вывод, что для эффективного решения проблемы необходимо опираться на комплексную, сквозную автоматизацию операций DevSecOps, связанных с внедрением.
Этот вывод может не быть оптимальным для компаний другого уровня. В то же время предложенный набор «заблуждений» представляет интерес и для небольших организаций. Это поможет им лучше понимать свои процессы и эффективнее справляться с задачами обеспечения безопасности и комплаенса при внедрениях.
