Вложения в безопасную разработку – это вложения в совершенствование бизнес-процессов разработки ПО. Безопасная разработка позволяет снижать издержки на выпуск продуктов, в том числе сертифицированных, удовлетворить требования к сертифицированным продуктам, обеспечивать стабильный финансовый результат, который напрямую зависит от качества продукта, снижать репутационные риски компании, которые неизбежно перерастают в финансовые, повысить конкурентность компании на рынке.
Лучше идти от того, что будет максимально понятно бизнесу – от бизнес-рисков. Оцените, сколько будет стоить сбой в простой системе, компрометация данных компании или клиентов. Покажите, что вы решаете проблемы и тем самым уменьшаете определенные риски. Можно провести аналогию с обычным тестированием. Только, в отличие от типичных ошибок, уязвимости еще могут навредить конфиденциальности, целостности и доступности.
Главный тезис: безопасность – домен качественной разработки. Каждая ошибка, обнаруженная на раннем этапе разработки, позволяет сократить затраты на ее исправление. Внедрение и автоматизация процедур тестирования и безопасной разработки позволяют сократить релизный цикл основных продуктов. Достигаемое высокое качество за счет внедрения практик безопасной разработки выпускаемого программного обеспечения значительно влияет на формирование репутации компании и позволяет занять прочные позиции, в частности, на конкурентном рынке СЗИ.
Самое простое решение – это наглядно продемонстрировать потенциальные убытки в случае успешной реализации атак на инфраструктуру компании. Например, можно провести пентест, успех которого убедит руководство в необходимости выделения бюджета на построение комплексной системы безопасности. По опыту могу отметить, что сейчас финансовые директора очень быстро оцифровывают репутационные потери.
Уговорить финансового директора на самом деле очень просто. Необходимо донести информацию, что в случае отсутствия вложений во внедрение безопасного жизненного цикла разработки усиливаются риски потери репутации компанией-разработчиком. Тот факт, что злоумышленники воспользовались уязвимостью в исходном коде основного ценного актива разработчика – его продукта, ставит крест на привлекательности решения для заказчиков, а значит, продажи прекратятся в один момент. Кроме того, отсутствие вложений в SDL приводит к появлению и функциональных ошибок, что, в свою очередь, приводит к нестабильной работе приложения, сбою бизнес-процессов – и вновь потеря времени, денег, упущенная бизнесом выгода. Когда речь идет о десятках, сотнях и тысячах клиентов, потери могут быть очень масштабными. К счастью, усиливается осознание того, что безопасность нужна и важна.
Сравните затраты на устранение наступивших угроз с эксплуатационными затратами на противодействие угрозам. Эти данные довольно просто получить и осмыслить, особенно в терминах затрат, потерь и экономии бюджета. Замечу, что если в начале 2000-х гг. вкладывать деньги в развитие стендовой базы заказчикам казалось непроизводительными расходами, то в настоящее время у подавляющего большинства корпоративных заказчиков необходимость стендовой базы, сопоставимой с производственными мощностями, стала совершенно понятными расходами на эксплуатацию системы.
Виднее всего генеральному директору! Я на 100% уверена, что только под его руководством, при акценте на качестве своего продукта и при соответствующих задачах для линейных руководителей, уговаривать никого не придется.
Обоснование затрат на SDL – это очень веселая история. Кажется, что самый простой способ – просто запугать, пользуясь своим техническим превосходством в понимании темы. Мне думается, что многие айтишники отчасти живут по принципу "лучше день потерять, потом за пять минут долететь". Что делать с финансовым директором, искушенным в ИТ, я не знаю. Но я с такими и не встречался.
А как вы уговариваете финансового директора на то, чтобы выделить средства на создание качественного кода? Важно продемонстрировать коммерческую выгоду от безопасности программных решений – риски утечек, потери данных и вместе с ними репутации. Если качество важно для вас, то и безопасность тоже будет важна.
Аргументами могут быть формальные требования к сертификации продукта как действующие, так и ожидаемые в скором будущем, а также возможные риски, связанные с обнаружением уязвимостей в процессе эксплуатации. В нашем случае никого уговаривать не пришлось: финансовый директор оказался грамотным специалистом и все понимал сам.
Для начала рекомендую проанализировать, что компании даст безопасная разработка с точки зрения ценности для бизнеса, а дальше уже донести эту ценность до руководителя. Например, для многих вендоров внедрение безопасной разработки является критически важным фактором развития компании, поскольку заказчики предъявляют повышенные требования к безопасности ПО, проверяют продукты на наличие уязвимостей, организовывают пентесты. Если у разработчика отсутствуют практики SDL, это может усилить как финансовые, так и репутационные риски, ведь компания может просто потерять клиента. Кроме этого, применение практик безопасной разработки создает для компаний дополнительное конкурентное преимущество на рынке: еще на этапе создания продукта за счет оптимизации процесса тестирования разработчик получает существенное снижение затрат для всего жизненного цикла ПО.
Определение бюджета и убеждение руководства в необходимости его принятий – это первый шаг к безопасной разработке. Хорошим аргументом может стать ощутимый размер убытков в случае обнаружения уязвимостей после выпуска изделия в промышленную эксплуатацию. Например, эксперты из LLVM Project приводят следующую оценку: если стоимость исправления бага на этапе разработки составляет около $25, то после релиза она может быть порядка $16 тыс., то есть в 640 раз выше. Важно также учитывать зависимость продукта компании от других систем и заранее проверить наличие их сертифицированных версий, что позволит сэкономить время и деньги.
Для общения с финансовым директором и любым топ-менеджером рецепт успеха простой: показать реальную пользу от внедрения на примере в деньгах. Сколько стоит исправление найденной критичной уязвимости после релиза продукта (затраты на разработку, тестирование, сдвиг запланированных сроков релиза)? Насколько репутационные риски приемлемы для компании?
Следует показать возможные денежные и репутационные риски в случае, если в продукте найдутся серьезные уязвимости. Можно также сравнить объем затрат и потенциальную выгоду от сертификации продукта. В нашем случае внедрение SDL не стоило очень дорого, потому что многие этапы уже и так присутствовали.
На мой взгляд, с финансовым директором верным подходом будет разговор на языке цифр. Нужно сделать расчет стоимости внедрения решения по безопасной разработке и сопоставить его с затратами на ликвидацию последствий инцидента, вызванного эксплуатацией уязвимости в ПО. Можно также посчитать недополученную компанией прибыль и финансовые потери в связи со снижением качества разработанного компанией ПО, а значит, предоставляемых компанией услуг.
Для директора важен рост доходов и репутации на конкурентном рынке, поэтому рекомендую показать, какие перспективы с внедрением SDL открываются перед компанией.
Важно объяснить, что любое ПО содержит уязвимости. Впоследствии это может привести к финансовым и репутационным потерям, например из-за взлома компании через имеющуюся уязвимость в коде. Таким образом, чем раньше организация начнет внедрять безопасную разработку, тем меньше денежных затрат она понесет в будущем.
Раскрою наш секрет: умело манипулируйте тройкой "неизбежность –необходимость – польза", добейтесь личной вовлеченности генерального директора – и результат будет обеспечен. У нас ведется разработка более десяти собственных ИБ-продуктов. Без унификации подхода к SDL нам было бы очень сложно, так что уговаривать никого и не пришлось.
Способов не очень много. Основной – это, конечно, описание рисков. Возможен вариант описания и подсчета вероятности рисков при потере ценной информации или ее утечки, простоя производства, а также указания в качестве рисков административной, а иногда и уголовной ответственности. Не стоит забывать и о репутационном ущербе. Мне кажется, при грамотном подходе любой финансовый директор прислушается к мнению специалистов.
Наши вложения в SDL опираются на необходимость обеспечения возможности отработки студентами полученных практических навыков по безопасной разработке в соответствии с "русским методом" подготовки инженеров, что является вполне достаточным обоснованием для руководства университета.
Полная версия круглого стола в журнале "Информационная безопасность": https://cs.groteck.com/IB_3_2023/40/