Экономика Shift Left Security

Я работал с десятками SecOps и Обнаружение и ответ команды за последние несколько лет, и мне стало совершенно ясно, насколько важно исправить как можно больше проблем с безопасностью. вверх по течению. Или, как это более известно, «Сдвиг влево безопасности». В целом я вижу три лагеря на «Сдвиг влево безопасности» — 1) не понимаю, 2) получаю, не исполняя, 3) получаю, исполняя. Возможно, вы принадлежите к третьему лагерю и считаете, что смещение влево является очевидным и общеизвестным фактом. Позвольте мне скромно напомнить вам, что это большой мир, и обычная организация крайне незрела в вопросах безопасности. Иными словами, первый и второй лагеря вместе взятые намного превосходят третий лагерь.

Почему это? Что ж «Сдвиг влево безопасности» новый, но, что более важно, он жесткий. Это все равно, что постоянно есть овощи перед лицом других сладких искушений. Все поставщики систем безопасности говорят, что смещение влево позволяет ускорить доставку и снизить затраты, но, по моему мнению, никогда не оценивают это значимо количественно. В этом анализе я попытаюсь вооружить практиков данными о «Shift Left Security», понятными каждому руководителю и контролеру бюджета — экономике бизнеса. Это вписывается в важную более широкую тему необходимости обеспечения безопасности для достижения бизнес-результатов — роста вашего TAM, ускорения циклов продаж, более быстрой доставки продукта — а не только в качестве упражнения по снижению рисков.

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

Теперь по анализу. На мой взгляд, эта тема слишком сложна, чтобы проводить какой-то высокоуровневый анализ и утверждать что-то вроде «Сдвиг влево делает вас на 10% быстрее и экономит 30%», слишком много переменных. Мой подход будет заключаться в моделировании очень конкретных микропримеров гипотетической организации, смещающейся влево, и посмотреть, что можно извлечь из этого.

По параметрам в приведенных ниже моделях — есть несколько очень грубых оценок (а местами даже полных предположений), которые я пытаюсь собрать воедино, когда доступных данных недостаточно. Прочитайте источники для моего комментария и дайте мне знать, если вы знаете более надежные исследования! Кроме того, «утечка данных» — не единственная форма киберсобытий, о которой стоит беспокоиться, я остановился на них, потому что есть серьезные исследования затрат по сравнению с более туманными эффектами бренда, доверия и т. д.

Модель 1 — MFA, реализованная во всей организации

Начиная с простого. Если вы думаете «в каждой организации везде включена функция MFA», вам нужна проверка на реальность. Тем не менее MFA как единый элемент управления, развернутый в организации, является отличным наглядным примером. MFA считается сдвигом влево, потому что он вообще предотвращает многие рискованные действия с учетными данными. В этой модели сравнивается гипотетическая организация, в которой MFA развернута везде должным образом, и организация, в которой используется только 1FA.

Стоимость модели:

• SOC Затраты на персонал = (Уведомления о входе в систему для каждого пользователя в день, связанные только с однофакторной аутентификацией) * (Размер организации) * (Средний годовой доход) SOC (Стоимость услуг аналитика) / (Количество обработанных оповещений на одного аналитика в день)
• SOC Затраты на программное обеспечение = (Оповещения о входе в систему на пользователя в день, относящиеся только к 1FA) * (Размер организации) * (Стоимость программного обеспечения для оповещения для помощи в расследовании) * (365 дней)
• Потеря производительности в долларах = (Среднее количество MFA в день на пользователя) * (Размер организации) * (Время до MFA в секундах) / (1 минута / 60 секунд) / (1 час / 60 минут) / (1 день / 24 часа) * ( Среднегодовые затраты на сотрудников)
• Ожидаемое значение стоимости нарушения = (Средняя стоимость утечки данных) * (Вероятность утечки данных)

Параметры модели:

• Размер организации: 10000 сотрудников (пользователей)
• Время до MFA (Google Auth или эквивалент): 10 секунд [1]
• Среднее количество MFA в день на пользователя: 1 [2]
• Среднегодовые затраты на сотрудников: $100,000
• Предупреждения о входе в систему на пользователя в день, относящиеся только к 1FA (аномальный доступ, совместное использование пароля и т. д.): 0.01 [3]
• Предупреждений, отсортированных по аналитикам в день: 100 [4]
• Среднегодовой SOC Стоимость услуг аналитика: $100,000
• Стоимость программного обеспечения для оповещения, помогающего в расследовании: 0.10 5 доллара [XNUMX]
• Процент утечек данных в результате кражи или компрометации учетных данных: 19% [6]
• Средняя стоимость утечки данных: 4.35 миллиона долларов [7]
• Базовая вероятность утечки данных: 1.13% [8]
• Вероятность утечки данных с помощью MFA: 0.92% [9]

Честно говоря, я был немного удивлен, насколько в этом анализе сложились трения традиционных МФА в долларовом выражении. Еще одна причина для внедрения невидимых решений MFA.

Модель 2 — правильное выполнение DevSecOps

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

Стоимость модели:

• Затраты разработчиков = (Отдельные производственные приложения, разработанные организацией) * (Среднее количество уязвимостей на одно производственное приложение) * (Среднее количество часов разработки для устранения уязвимости в часах) * (1 год / 52 недели) * (1 неделя / 40 рабочих часов) * (Среднегодовое значение Стоимость разработчика)
• Стоимость аналитика безопасности = (Отдельные производственные приложения, разработанные организацией) * (Среднее количество уязвимостей на одно производственное приложение) * (Среднее количество часов, потраченных командой безопасности на устранение уязвимости, обнаруженной в производственной среде, в часах) * (1 год / 52 недели) * (1 неделя / 40 рабочих часов) * (Средняя годовая стоимость аналитика безопасности)
• Ожидаемое значение стоимости нарушения = (Средняя стоимость утечки данных) * (Вероятность утечки данных)

Параметры модели:

• Отдельные производственные приложения, разработанные организацией: 17 [10]
• Среднее количество уязвимостей на рабочее приложение: 30.59 [11]
• Среднее количество часов разработки для устранения каждой уязвимости, обнаруженной в процессе разработки: 3.61 часа [12]
• Среднее количество часов разработки для устранения каждой уязвимости, обнаруженной в рабочей среде: 10.71 часа [13]
• Средняя годовая стоимость разработки: $150,000
• Среднее количество часов, затраченных командой безопасности на устранение каждой уязвимости, обнаруженной в рабочей среде: 3.10 [14]
• Средняя годовая стоимость аналитика безопасности: $100,000
• Среднее среднее время устранения уязвимостей — низкая частота сканирования — 1–12 сканирований в день (безопасность со сдвигом вправо): 217 дней [15]
• Среднее среднее время устранения уязвимостей — высокая частота сканирования — более 260 сканирований в день (Shift Left Security): 62 дней [15]
• Предполагаемое снижение уязвимостей за счет высокой частоты сканирования: 71% [16]
• Процент утечек данных в результате уязвимостей приложений: 43% [17]
• Средняя стоимость утечки данных: 4.35 миллиона долларов [6]
• Базовая вероятность утечки данных: 1.13% [7]
• Вероятность утечки данных при высокой частоте сканирования: 0.79% [18]

DevSecOps имеет большое вспомогательное исследование, касающееся стоимости исправления недостатков безопасности на разных этапах разработки (модульное тестирование, интеграционное тестирование, системное тестирование, подготовка, производство и т. д.), поэтому неудивительно видеть существенные различия при смещении влево и вправо. в этой модели. В 2022 году действительно нет оправдания тому, чтобы не стать чемпионом мира. DevSecOps — это касается всех размеров организаций по разработке программного обеспечения (эти организации могут быть подразделениями более широких организаций).

Модель 3 — адаптация и увольнение надежных сотрудников и активов

Прием и увольнение сотрудников и активов — чрезвычайно недооцененные рабочие процессы безопасности. Если все сделано правильно, это дает возможность создавать чистые данные и гарантировать строгий контроль (EPDR, VPN, безопасность электронной почты, шифрование диска, браузер, контролируемый организацией и т. д.) и состояния доступа во время подключения и отключения. Плохо сделанный, он создает дополнительную работу и оставляет все на волю случая или ручного труда человека. Существует множество систем, которые помогают поставить рельсы на рельсы этих процессов. В этой модели сравнивается организация с идеальной системой безопасности при подключении и отключении от организации с ручными, подверженными ошибкам рабочими процессами.

Стоимость модели:

• Затраты времени на настройку инструмента адаптации сотрудников = (Размер организации) * (Оборот организации) * (Время на ручную адаптацию ИТ в минутах) * (1 час / 60 минут) * (1 неделя / 40 рабочих часов) * (1 год / 52 недели) * (Среднегодовая численность сотрудников Расходы)
• Оплачиваемый SOC Стоимость = (Организация) SOC Размер) * (Среднегодовой SOC Затраты на аналитика) * (Применимые преимущества)
• Ожидаемое значение стоимости нарушения = (Средняя стоимость утечки данных) * (Вероятность утечки данных)

Параметры модели:

• Размер организации (постоянный в течение года): 10000 сотрудников (пользователей)
• Годовой оборот организации: 47.2% [19]
• Среднегодовые затраты на сотрудников: $100,000
• Время вручную установить и настроить EPDR и VPN на новых ноутбуках: 20 минут [20]
• организация SOC Размер: 3 FTE
• Среднегодовой SOC Стоимость услуг аналитика: $100,000
• SOC Повышение эффективности за счет четкого определения «кто чем владеет» в результате адаптации сотрудников и управления активами: 10% [21]
• Процент утечек данных в результате фишинга: 16% [22]
• Процент утечек данных в результате неправомерного увольнения сотрудников: 10% [23]
• Средняя стоимость утечки данных: 4.35 миллиона долларов [6]
• Базовая вероятность утечки данных: 1.13% [7]
• Вероятность утечки данных с гарантированным правильным контролем на каждом ноутбуке сотрудника и автоматизированным удалением: 0.85% [24]

Люди делают ошибки; держите повторяющиеся задачи на машинах. Даже если предположить, что в такой задаче, как прием на работу и увольнение, люди совершают ошибки только в 5% случаев, то есть 472 ошибки в этой модели учитывают всех этих сотрудников, принимавших на работу и увольняемых. Это много низко висящих фруктов, которые рискуют снять со стола. Инвестируйте в надежный инструмент, который управляет этим для вашей организации, он окупит себя.

Выводы

Безопасность — это сложная сеть компромиссов, и смещение безопасности влево ничем не отличается. Я в основном исследовал это аналитическое упражнение, потому что я не могу поверить, что я все еще вижу оповещения в дикой природе только когда-либо возможным, потому что организация не внедряет MFA. Я понимаю, однако, основы могут быть сложными, между борьбой с унаследованным ИТ-долгом или бюрократией. Какой бы ни была ваша роль, мы надеемся, что это дало вам новые знания о том, как «Shift Left Security» может привести к бизнес-результатам и окупить любые новые инструменты, требуемые только с экономической точки зрения.

А теперь иди и ешь овощи.