Как создать успешную программу безопасности приложения?
modern security, security, защита ит-инфраструктуры
Комьюнити специалистов в сфере безопасности постоянно меняется и расширяется, а участники – непрерывно обмениваются опытом, чтобы защищать мир от киберугроз еще лучше. В последней публикации из серии блогов «Голос сообщества» приведена беседа менеджера по продуктовому маркетингу Microsoft Натальи Годылы с Таней Янка, основателем We Hack Purple Academy и автором бестселлера «Алиса и Боб изучают безопасность приложений». Ранее Таня поделилась своим видением, какова роль безопасности приложений (AppSec), и проблемами, с которыми сталкиваются профессионалы AppSec. В этом блоге Таня рассказывает, как создать программу AppSec, найти чемпионов по безопасности и оценить ее успех.
Наталья: Когда вы создаете программу AppSec, каковы ее цели и требования?
Таня: Это вопрос с подвохом, поскольку создание программы основано на том, что уже есть и чего требуется достичь. Что касается Канады, я занималась антитеррористической деятельностью, и, поверьте, это была самая строгая программа безопасности из когда-либо созданных человечеством. Однако если же работаю с компанией, которая, к примеру, продает ароматическое мыло в интернете – требуемый уровень безопасности будет существенно отличаться. У такого небольшого бизнеса другой бюджет и другая степень важности того, что нужно защищать. Я пытаюсь разобраться, каковы риски компании и насколько они терпимы к изменениям. Например, меня приглашали во многие банки, где хотели обеспечить жесткие меры безопасности, но, при этом, не любят перемен. Я сначала изучаю, что для них важно, а затем стараюсь привлечь их внимание к тому, что для них действительно имеет значение.
Я также обычно прошу предоставить все результаты сканирования. Даже если у организации практически нет программ AppSec, обычно люди сканируют или проходят тест на проникновение. Я смотрю на все это, обращаю внимание на три главных момента и предлагаю: «Хорошо, давайте просто отбросим эти три главные момента», поскольку довольно часто две или три топовые позиции составляют угрозу от 40 до 60 процентов в списке всех уязвимостей. Сначала я «останавливаю кровотечение», а затем создаю процессы и работаю над осведомленностью разработчиков в вопросах безопасности. Мы проводим день безопасного программирования и углубляемся в каждый из этих моментов. Я провожу время с людьми: они просматривают все pull-запросы, чтобы определить тройку лучших и начать устанавливать конкретные измеримые цели.
Очень важно привлечь к полезному вам сотрудничеству разработчиков. После прохождения обучения безопасному программированию, одна группа программистов идентифицирует себя как разработчики безопасности. Обязательно находится один человек, который задает кучу вопросов. Мы просим email этого человека. Такие люди – наши друзья. Мы покупаем для этого человека несколько книг и поощряем открытое общение, потому что эта личность получает роль нашего защитника. В конце концов, многие из моих клиентов запускают программы чемпионов по безопасности – и это даже лучше. В таком случае у вас будет целая группа особых разработчиков (надеюсь, как минимум по одному на команду) – которые помогают привлечь внимание к нужным вопросам безопасности участников своих команд.
Наталья: Какие ключевые показатели эффективности (KPI) используются для оценки состояния безопасности?
Таня: Как профессионалы в области безопасности приложений, мы хотим свести к минимуму риск появления «пугающих» приложений, а затем попытаться довести все до наивысшего уровня безопасности. Каждая организация устанавливает собственную планку. Для программы безопасности приложений я бы измеряла, достаточно ли внимания уделяется внимание безопасности каждого отдельного приложения на разных этапах жизненного цикла разработки программного обеспечения. Для внедрения программы я провожу инвентаризацию всех приложений и API. Инвентаризация – сложная задача с точки зрения безопасности приложений; это самая сложная проблема, с которой мы сталкиваемся в своей сфере.
После того, как вы завершите инвентаризацию, вам захочется выяснить, можно ли провести быстрое сканирование динамического тестирования безопасности приложений (DAST) для всех приложений. Вы заметите, что для некоторых сканирование покажет предупредительных сигналов, как на рождественской елке, а для других – обнаружит лишь несколько пробелов. Это не идеальная стратегия, но это то, что можно выполнить всего за 30 дней. Вы можете быстро отсканировать много чего и убедиться, что все не так ужасно и выглядят нормально. А теперь давайте все же сконцентрируемся на ужасных моментах и сделаем их не столь пугающими.
Наталья: Есть ли у вас примеры лучших практик моделирования угроз облачной безопасности?
Таня: Что касается моделирования угроз в целом, я представляю это как видеовстречу с сотрудником службы безопасности и стараюсь не быть слишком формальной при первом общении, поскольку разработчики обычно думают: «Что она здесь делает? Опасность, Уилл Робинсон, опасность. К нам приставили охрану. Что с нами не так?» Я объясняю: «Я хочу поговорить о вашем приложении и посмотреть, могу ли я дать какие-нибудь полезные рекомендации». Затем я начинаю задавать программистам вопросы из серии: «Если бы вы собирались взломать свое приложение, как бы вы это сделали?»
Мне нравится методология STRIDE, где каждая буква обозначает разные моменты, о которых нужно беспокоиться, если это произойдет с вашими приложениями. В частности, спуфинг, подделка, отказ от авторства, раскрытие информации, отказ в обслуживании (DOS) и повышение привилегий. Может ли кто-то притвориться кем-то другим? Может ли кто-нибудь притвориться вами? Я перечисляю все это медленно, в разговорной манере, потому что это приложение – их детище, и я не хочу, чтобы они чувствовали, будто нападаю на их творение. В конце концов, я обучаю их методологии STRIDE, чтобы они могли думать об этих вещах. Затем мы придумываем план, и я говорю: «ОК, я все это зафиксирую письменно и отправлю вам по электронной почте». Письменное изложение означает, что теперь вы можете поставить людям какие-то задачи.
При моделировании угроз в облаке вы должны задавать больше вопросов, особенно если в вашей организации уже были проблемы. Нужно спросить об этом, поскольку вы столкнетесь с шаблонами. Самая большая проблема, связанная с использованием облака – недостаточный уровень знаний у пользователей. Переводя сотрудников в облако, нужно пояснить им, чего мы от них ожидаем, и тогда мы это получим. Если мы этого не сделаем, велика вероятность, что этого не будет.
Наталья: Как специалисты по безопасности могут убедить лицо, принимающее решения, инвестировать в AppSec?
Таня: Для этого у меня есть масса приемов. Первый – проводить презентации про AppSec. Я совмещаю обеденный перерыв и обучение. Например, однажды я разослала разработчикам электронные письма с предложением: «Я собираюсь взломать банк в обеденный перерыв. Кто хочет это увидеть? » а затем я показал им демо взлома фейкового банка. Я объяснила, что такое SQL-инъекция, как я обнаружила эту уязвимость в одном из наших приложений и что может произойти, если мы ее не устраним. И мне ответили: «Ничего себе!» Или я могу предложить: «Кто хочет научиться взламывать приложения?» а затем продемонстрировать инструмент DAST. Я продолжала показывать им такие примеры, а они начинали проявлять все больше интереса.
Затем мне пришлось заинтересовать менеджеров разработчиков и их высшее руководство. Некоторые все еще не задействовались, поскольку это была первая программа AppSec как ля них, так и для меня. Никто не стал бы делать то, что я сказала. У меня на руках были все эти результаты тестов на проникновение от третьей стороны, и мы наняли дополнительно четырех разных специалистов по оценке безопасности, которые сообщили о серьезных проблемах, требующих решения.
Итак, я придумала документ, который называется лист подтверждения рисков. В нем перечислены все риски безопасности и что именно может случиться с бизнесом. Я была очень конкретна в вопросах, которые меня беспокоили. У мня был распечатанный вариант для подписи от директора службы безопасности всего здания и от директора по информационным технологиям всей организации. Я подошла к ним и сказала: «Мне нужна ваша подпись, что вы принимаете эти риски от имени своей организации». Я сделал небольшую пометку на листе подтверждения рисков: «На подпись».
Начальник службы безопасности позвонил мне и спросил «Что это, Таня?» и я ответила: «Никто не будет исправлять эти проблемы, и у меня нет полномочий принимать на себя эти риски от имени организации. Только вы можете быть ответственным. У меня нет полномочий заставлять этих людей исправлять эти моменты. Только вы можете повлиять на них. Мне нужно, чтобы вы поставили свою роспись, которая будет свидетельствовать, что вы знали о рисках. Когда мы столкнемся с плохими новостями, мне нужно знать, кто виноват ». И ИТ-директор, и директор по безопасности отказались подписать документ, а я сказала: «Тогда вы должны предоставить мне полномочия. Я не могу нести ответственность и не иметь полномочий», и это сработало. Я использовала этот лист на работе дважды – и это всегда действовало.
Также важно объяснять им все на понятном языке. словами. Глава службы безопасности, который отвечает за физическую и ИТ-безопасность, был блестящим специалистом, но не знал AppSec. Когда я объяснила, что можно сделать с приложением из-за этой уязвимости, и как это отразится на их пользователях, он ответил: «О, давайте что-то предпримем». Мне пришлось научиться лучше общаться, чтобы внедрять AppSec, потому что как разработчик я просто общалась с другими разработчиками.