Как совместить работу разработчиков и команды безопасности: четыре способа

Могут ли эти два различные точки зрения быть согласованными?

Чтобы лучше понять эту напряженность и, возможно, найти путь к разрешению, мы можем изучить конкретную тему уязвимостей. В данном случае мы говорим о недостатке в программном обеспечении, позволяющем злоумышленнику совершить несанкционированное действие с злонамеренным намерением. Если вы из области информационной безопасности, вы знаете, что существует практически бесконечное количество уязвимостей, которые нужно решить при ограниченных ресурсах, при том что кибер-противники поджидают в тени. Уязвимости существуют, потому что разработчик создал их, хотя не намеренно, и все чаще не непосредственно. Редко возникают споры относительно решения уязвимостей, которые очевидно представляют высокий риск или уже были использованы, но есть много места для разногласий относительно того, что составляет «высокий» риск и относительного приоритета решения уязвимостей, которые находятся на нижних позициях в индексе риска. Фактически, существуют компании, посвященные определению приоритета уязвимостей. Приоритизация уязвимостей — это микрокосм в большей среде кибербезопасности. Принципы легко принять, но детали трудны. В конце концов путь к разрешению заключается в том, что проблемы безопасности должны быть выделены в зависимости от их операционного воздействия. Другими словами, как безопасность, так и разработчики должны идти на уступки и соглашаться, что некоторые проблемы действительно критичны, а некоторые — нет. Это требует изменения мышления с обеих сторон и обязательства к сотрудничеству.

Технология одна просто не является ответом

Также необходим культурный сдвиг. Разработчикам необходимо осознать, насколько проблемы безопасности влияют на бизнес, и обучение лучшим практикам написания безопасного кода должно основываться на этой потребности бизнеса. Команды безопасности, в свою очередь, должны понять давление бизнеса, с которым сталкиваются разработчики, и стремиться быть помощниками, а не стражниками. Сессии кросс-функционального обучения и совместные семинары могут помочь построить это взаимопонимание и содействовать культуре, где безопасность рассматривается как общая ответственность. Более того, организации должны принять подход к приоритизации рисков по бизнесу. Не все уязвимости созданы равными образом, и приоритизация их на основе потенциального воздействия на организацию критична. Это включает в себя оценку не только технической серьезности уязвимости, но и бизнес-контекста. Например, уязвимость в бизнес-критическом API, обрабатывающем конфиденциальные данные клиентов, должна иметь более высокий приоритет по сравнению с такой же серьезной проблемой в низкорисковом внутреннем приложении. Однако решить эти проблемы нелегко. Одной из целей DevSecOps является поощрение межфункциональной коммуникации. Эффективное общение между разработчиками и командами безопасности является жизненно важным. Команды безопасности должны излагать риски и потенциальные последствия уязвимостей таким образом, чтобы это резонировало с разработчиками. Это означает выход за рамки технического жаргона и формулирование разговора в терминах бизнес-рисков и операционного воздействия, что требует от обеих команд понимания того бизнес-контекста. Напряженность между разработчиками и командами безопасности в конечном итоге коренится в их различных приоритетах: скорость против безопасности. Установление общего землянного шара для приоритизации вокруг бизнес-потребностей может помочь сократить этот разрыв. Путем принятия практик, таких как DevSecOps, использования автоматизации, поощрения сотруднической культуры и фокусировки на управлении уязвимостями на основе бизнес-рисков могут приблизить разработку и безопасность друг к другу. Обе команды должны признать, что они работают над одной целью: обеспечение безопасного и качественного программного обеспечения. Источник: TechRadar