Ключом к улаживанию такого противоборства является повышение уровня доверия между аудиторами, разработчиками и создаваемой SDL-командой. Это достигается за счет проведения встреч с командами разработки, на которых демонстрируются примеры применения лучших практик, их польза для процесса разработки в части качества исходного кода и для компании в части безопасности итогового продукта, что в целом повышает репутацию компании на рынке.
Противоборство с командой решается поддержкой руководства организации. Если принято волевое решение, деваться некуда. Естественно, у команд всегда присутствует большая доля скепсиса: трудозатраты повышаются, времени, чтобы пилить фичи, становится меньше. Но если показать реальную пользу от процесса SDL, продемонстрировать, как ошибка в коде может привести к полной компрометации в системе, подсказать разработчику, как искать проблемы и как их избегать, негатив уходит и начинается конструктивное взаимодействие.
У нас в команде таких вопросов не возникает, поскольку наш продукт сам является SDL-инструментом и все конструктивно воспринимают безопасность. Но в полях мы действительно видим большое количество встречных отговорок от безопасности. Самая популярная – "нужно исправлять баги от заказчика, нет времени настраивать SDL". Важно объяснить, что функциональные ошибки и ошибки безопасности – одного поля ягоды. К тому же исправление багов безопасности зачастую более увлекательная инженерная задача, чем исправление функциональности.
Дам сначала совет начинающим. Первым делом необходимо провести аудит актуального процесса разработки в команде, оценить его с разных сторон: уровень взаимодействия и коммуникации внутри и между командами, достаточно ли знаний и опыта для внедрения концепции безопасной разработки.
Если говорить конкретнее, нужно детально понять, насколько сложными инструментами обеспечения безопасной разработки команда владела ранее, способна овладеть сейчас и в перспективе (это относится как к разработчикам, так и к тестировщикам). При плохом уровне взаимодействия ошибки не будут исправляться.
Исходя из моего опыта могу сказать, что весь процесс организации безопасного процесса разработки занимает от А до Я около шести месяцев. Сейчас для автоматизации разработки софта и написания кода мы используем хорошо известные и проверенные временем инструменты: систему непрерывной интеграции Jenkins, собственные скрипты на Python, а также разнообразные средства тестирования безопасности, такие как Svace, AFL++, Crusher, Блесна.
Главный залог успеха в процессе "разруливания" – командоформирующие мероприятия, объединение команды, налаживание коммуникации.
Противоборство было, есть и будет всегда! Я стараюсь подключать грамотных аудиторов, проводить встречи с регулятором для того, чтобы разработчики могли задать волнующие их вопросы и по-другому взглянули на ситуацию, увидев пользу от новых практик и инструментов. Только показав, что их труд не напрасен, можно добиться результата.
Могу вспомнить свой опыт разработки продукта в Intel примерно пять лет назад. Компания в директивном порядке навязывала практики SDL, и команда разработчиков изначально восприняла это в штыки: еще одна палка в колесо, как будто их без этого их мало. Но поскольку это было требованием компании, пришлось подчиниться. В результате SDL был внедрен только на уровне практик процессов и инструментов на уровне валидации. Сейчас мне кажется, что начинать надо был по-другому. Безопасность разработки сама по себе очень интересная инженерная задачка, и людей надо было попробовать этим заинтересовать. А коль скоро все они инженеры, это должно быть не так сложно.
Внедрение SDL-процесса виделось естественной заменой авральной подготовки к очередной сертификации. Противоборства не было, зато были вопросы типа "С кем все это делать?", много обсуждений, поездок на конференции, совещаний с лабораторией. В результате мы выделили команду AppSec, определились с приоритетами и внесли изменения в общий процесс разработки. Конечно, сложности были тогда и есть сейчас. Но главное, мы решили, что "без SDL дальше не получится", – и начали действовать.
Пример из жизни: в процессе внедрения SSDLC у ИБ не получалось реализовать контроль над безопасностью разрабатываемого ПО. ИТ не хотели вмешательства в свою зону ответственности и никак не помогали. Пришлось мне выступать буфером, и к концу второго этапа удалось убедить ИТ, что функции ИБ не в контроле, а в помощи при работе над общей целью.
К сожалению, противостояние ИТ и ИБ все еще встречается, и важно уже на начальном этапе учитывать этот риск. Нивелировать проблему поможет создание комфортных условий для объединения команд в решении общих задач, и тогда все будут победителями.
Важный аспект для успешного внедрения SDL в компании – это поддерживание диалога с командами разработки. Каждая команда стремится сделать свой продукт более качественным, а безопасность является одним из показателей качества. Поэтому, выстраивая процессы SDL, не рекомендуется взаимодействовать с командами в формате указов, иначе большинство практик будет ими игнорироваться. Внедряемые инструменты и практики также должны быть удобными для работы, а результаты деятельности команд необходимо отображать в привычных для разработчиков инструментах (репозиториях, IDE, таск-трекерах и т.д).
Наша команда разработчиков никогда не сопротивлялась внедрению процессов безопасной разработки. Мы с самого начала органично включили SDL в процессы разработки операционных систем, проводили проверки средствами свободных программ. Правила игры по обеспечению безопасности программных продуктов меняются постепенно, эволюционно. И поскольку процесс проверки налажен, мы расширяем его постепенно и без потрясений: проводим тюнинг задач для команды разработчиков.
Основной совет: делайте SDL не ради самого SDL. Четко понимайте цели и последствия ваших действий, а также то, какие конкретно проблемы вы решаете. Это позволит наиболее быстро увидеть результаты и правильно расставить приоритеты с учетом вашей специфики, а не на основании маркетинговых листовок.
Обычный скепсис инженеров трудно преодолеть, тем более что формальная верификация кода дает много ложных срабатываний и заставляет трудиться вхолостую. Но при появлении реальных результатов мнение разработчиков постепенно меняется.
В действительности на первых этапах особого сопротивления не было, кроме, возможно, "да зачем оно вообще нужно, лишняя нагрузка". Но после обнаружения первых серьезных проблем в аспекте безопасности вопросы сами собой исчезли. Первое время было совершенно непонятно, как делать фаззинг. Но после погружения в тему стало понятно, что это не так уж и сложно, не так уж непонятно и не так уж невозможно.
У нас такой проблемы не было, потому что инициатива внедрения SDL c момента создания программного продукта исходила от руководителей компании, и все инженеры стремятся поддерживать высокое качество и безопасность продукта – такой подход у нас в ДНК. Чтобы внедрение SDL было успешным, оно не должно рушить выстроенные процессы и становиться сверхурочной задачей для загруженной команды разработчиков. SDL необходимо преподносить как параллельный процесс, плавно интегрируемый в уже устоявшиеся процессы разработки.
Очень важна фаза обучения и стремление к автоматизации процессов. На фазе обучения команда продуктовой безопасности работает с менеджерами, разработчиками и тестировщиками. Цель этой работы – описать всем участникам процесса базовые модели угроз для продукта и научить команду бороться с причинами их реализации – уязвимостями. Это один из самых важных этапов, так как код пишут люди и безопасность напрямую зависит от его качества. Для разработчиков в настоящий момент мы создаем отдельное адаптированное руководство. В нем описаны базовые принципы безопасной разработки, перечень возможных уязвимостей для разного типа приложений, показаны типичные примеры уязвимого кода и исправлений. Есть также информация о том, как использовать различные техники и технологии снижения вероятности эксплуатации уязвимости, так называемые Mitigations.
Внедрение любого процесса начинается с аудита. Важно проанализировать, как устроены процессы безопасной разработки, и выработать рекомендации по их улучшению, опираясь на лучшие практики. Затем нужно получить от руководства компании полномочия на внесение изменений в процессы разработки, после чего переходить к внедрению: определить ответственных лиц и сформировать принципы взаимодействия между ними. При этом нужно учитывать ограничения разработки по ресурсам, требования бизнеса к срокам выпуска релизов и т.д. Внедрение практик безопасной разработки реализуется поэтапно, от общего к частному, учитывая интересы всех сторон. При таком подходе сопротивление разработчиков будет минимальным.
Естественно, что при внедрении новых процессов, в том числе SDL, растет нагрузка на команду разработки и появляются дополнительные издержки для компании. Это встречает сопротивление. Но в ходе внедрения SDL мы помогаем улучшать качество разработки кода, что в перспективе снимает определенную нагрузку с разработчиков и увеличивает монетизацию продукта. Начинающим компаниям рекомендую выделять внутри продуктовой команды роль Security Champion для транслирования команде разработки практик SDL.
Противоборства в нашей практике не было. Есть задача постоянного совершенствования процессов разработки, причем не только в части SDL: автоматизация и улучшение процессов работы с архитектурой, документацией, прослеживаемостью требований до кода и обратно. И это у многих встречает понимание.
Полная версия круглого стола в журнале "Информационная безопасность": https://cs.groteck.com/IB_3_2023/40/