Как привлечь руководство к обеспечению безопасности?

Работа в компании, где никто не относится к безопасности серьезно, может стать крайне неприятным испытанием. Человеку очень сложно быть удовлетворенным своей работой, если 50 % времени он тратит на переговоры и просьбы, от которых зависит выполнение его задач.

Есть несколько способов привлечь руководство и другие команды к обучению безопасности приложений, если отсутствие взаимопонимания представляет серьезную проблему.

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

Далее следует объяснить риск так, чтобы мог понять каждый. Не надо восклицать: «Это входит в CVE (CVE – Распространенные уязвимости и риски (англ. Common Vulnerabilities and Exposures)) наивысшей степени риска!» Лучше сказать: «Данная уязвимость в платформе Java Struts позволит злоумышленникам взять контроль над зараженными веб-серверами с помощью всего одной строки кода. Таким образом они окажутся внутри нашей сети, минуя межсетевой экран, и смогут атаковать наши ресурсы напрямую. Мы уязвимы, я проверил(-а). Мне нужно разрешение на создание виртуального патча с использованием инструмента RASP для блокировки подобных атак, а также ваша помощь в его тестировании, чтобы я был(-а) уверен(-а), что все делаю правильно. Вы со мной?» Кто сможет отказать в такой аргументированной просьбе? Когда кажется, что мир рушится, но поддержки нет, часто причиной ее отсутствия является именно проблема коммуникации.

Другой вариант получения поддержки – провести проверку концепции (PoC) беспокоящей проблемы. «Не используете заголовки безопасности? Позвольте мне показать наш веб-сайт во фрейме, из которого злоумышленник легко может украсть учетные данные пользователей». Проверка концепции эксплойта для уязвимости, которую никто не хочет исправлять, – отличный способ вернуть эту проблему в топ списка в системе отслеживания ошибок. Тем не менее данный подход довольно трудоемок, поэтому, прежде чем приступать к его применению, следует убедиться в том, что он будет принят положительно. Проверку концепции надо проводить только в особых случаях.

Последней идеей, которую можно представить по этой теме, является использование документа «Подписанный список рисков», который я придумала в ответ на игнорирование моих отчетов по пентестированию. В нем подробно описываются все оставшиеся уязвимости, выявленные в ходе тестирования безопасности, а также связанные с ними бизнес-риски. Документ подается на подпись высшему руководителю службы безопасности организации (обычно это главный специалист по информационной безопасности (CISO) или главный специалист по безопасности (CSO)), который тем самым «принимает изложенные в нем риски». Цель такого документа – указать на то, что руководство было проинформировано об имеющихся проблемах и дальнейшее бездействие будет означать принятие соответствующих рисков. Если произойдет взлом системы через указанную в списке уязвимость, ответственность за него будет нести подписавший его человек. Возможно и такое, что, ознакомившись с этим документом, руководство даст его составителю полномочия на устранение проблем силами других команд.

Насколько я знаю, никто никогда не подписывал такой документ. Всем моим знакомым, кто использовал эту тактику, всегда предоставлялись полномочия для проведения необходимых изменений.

СОВЕТ. Используйте последний метод только в случае крайней необходимости. Данный трюк работает лишь один раз.

Как привлечь разработчиков к обеспечению безопасности?

Разработчики программного обеспечения – это строители, которые ежедневно буквально из ничего создают что-то. Большинство из них гордится результатами своей работы и хочет, чтобы их приложения были безопасными. Разработчики пишут небезопасный код не специально: либо они не знают, как улучшить защиту, либо им не хватает времени и ресурсов.

Поскольку программисты стремятся к созданию качественного ПО, а это невозможно без обеспечения высокого уровня безопасности, то привлечь их к делу – не такая уж сложная задача. Есть три области, на которые необходимо обратить внимание: знания, понимание и ресурсы.

Знания: как уже говорилось ранее, большинство курсов и тренингов по программированию не учат тому, как обеспечить безопасность создаваемого ПО. Вот здесь-то можно вступить в игру и научить их! Дайте разработчикам знания, необходимые для выполнения их работы. Отправляйте их на тренинги. Покупайте им книги (например, эту… да, купите им эту). Сделайте все возможное, чтобы они получили информацию, необходимую для создания максимально безопасного программного обеспечения.

Понимание: всем IТ-специалистам нужно знать приоритеты, потребности и мандаты в области обеспечения безопасности. Если разработчик понимает важность вашей просьбы, он с гораздо большей вероятностью включит ее в свой список приоритетов. Вместо того чтобы указывать ему, что конкретно нужно делать, лучше показать значимость поставленной задачи и способ ее выполнения.

Ресурсы: ошибки не исправляются в вакууме. Разработчикам требуется время, отведенное в проектных графиках, чтобы выполнить действия по обеспечению безопасности, в противном случае они будут проигнорированы. Также необходимы инструменты, справочные материалы, а иногда и дополнительная пара рук. Ваша задача – предоставить разработчикам возможность создавать безопасное программное обеспечение, и иногда под этим подразумевается, что нужно самому засучить рукава и потратить несколько дней на исправление ошибок, связанных с безопасностью, чтобы помочь им закончить работу в срок. Обеспечьте разработчиков всеми необходимыми ресурсами, затем сядьте и наблюдайте за их трансформацией.