Интеграция моделирования угроз с DevOps
Этот пост автор Саймон Керзи, Энтони Невико, Джонатан Дэвис, Рафаэль Пасос Родригес и Бен Хэнсон
Введение
Моделирование угроз — это важный метод безопасности, который помогает выявлять и приоритеты наиболее важных рисков для приложения или системы. В этом документе содержатся некоторые размышления о том, как можно эффективнее и эффективно внедрять моделирование угроз, интегрировать его с современными методологиями и инструментами DevOps, а также сосредоточиться на ценности, предоставленной всем различным субъектам, участвующим в жизненном цикле разработки программного обеспечения.
Это бумага для вас?
Этот документ является результатом работы небольшой группы экспертов по моделированию угроз и безопасности от Корпорации Майкрософт и включает в себя входные данные и идеи некоторых из самых известных экспертов извне Майкрософт. Он пытается решить простой, но срочный вопрос: что необходимо сделать, чтобы процесс моделирования угроз, используемый нами, обновлялся до современных требований, введенных методологиями Agile и DevOps, чтобы обеспечить необходимую стоимость при наименьшей стоимости?
Если вы являетесь владельцем продукта, членом группы безопасности или просто разработчиком, который рассматривает возможность внедрения моделирования угроз в рамках жизненного цикла разработки, этот документ предназначен для вас.
Аналогично, если вы уже приняли моделирование угроз, вы по-прежнему можете найти практические идеи для улучшения процесса.
Тем не менее, в документе представлены идеи для улучшения текущих процессов или успешного внедрения моделирования угроз в рамках процесса DevOps. Он не вводит конкретные инструменты или продукты, даже если мы надеемся увидеть эти идеи, реализованные некоторыми инструментами или продуктами в будущем. Таким образом, здесь вы не найдете объявления о новых средствах или предварительных версиях предстоящих функций.
Почему важно моделирование угроз?
Моделирование угроз является одним из основных подходов к безопасному проектированию программных решений. С помощью моделирования угроз вы анализируете системные векторы атак и разрабатываете действия по устранению рисков, вызванных этими атаками. Правильно, моделирование угроз является отличным компонентом любого процесса управления рисками. Это также может помочь сократить затраты, определив и исправив проблемы проектирования рано. Старое исследование из NIST оценило затраты на исправление проблемы проектирования в рабочем коде примерно в 40 раз выше, чем ремонт его на этапе проектирования. Кроме того, она экономит затраты из-за инцидентов безопасности для будущих проблем проектирования. Рассмотрим, что отчет о затратах на нарушение данных 2022 года из IBM Security и Ponemon Institute оценивает среднюю стоимость нарушения данных в размере $ 4,35 млн. Для так называемых Мега Брейз, с участием компрометации более 50 миллионов записей, средняя стоимость достигает $ 387M!
Моделирование угроз — это первое действие, которое можно сделать для защиты решения, так как оно работает с проектом решения. Эта характеристика делает ее наиболее эффективной практикой безопасности, которые можно применить к SDLC.
Корпорация Майкрософт уже давно работает с моделированием угроз. В 1999 году два сотрудника Майкрософт, Лорен Кохнфельдер и Пратерит Гарг, написали документ, угрозы нашим продуктам. В этом документе представлен подход STRIDE, синоним процесса моделирования угроз Майкрософт.
Моделирование угроз — это эволюционный процесс
Моделирование угроз не является статическим процессом; он развивается по мере изменения потребностей и технологий.
Атаки цепочки поставок, такие как недавний, предназначенный для SolarWinds , демонстрируют необходимость покрытия с моделированием угроз больше сценариев, чем само решение, включая разработку и развертывание.
Уязвимости с открытым исходным кодом, такие как недавний для Log4j , показали необходимость дополнения текущего подхода на основе внедрения средств анализа композиции программного обеспечения для сканирования уязвимых компонентов путем разработки решения оборонительным образом, чтобы ограничить его воздействие.
Применение новых технологий, таких как Машинное обучение, представляет новые векторы атак, которые необходимо понимать и контролировать. Рассмотрим, например, возможность играть злонамеренные звуки, неразборчивые человеческими уши, чтобы вызвать выполнение команд служб ИИ, как описано в https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carliniстатье.
В Корпорации Майкрософт различные группы продуктов практикуют различные варианты моделирования угроз на основе конкретных требований к безопасности. Каждый вариант направлен на обеспечение адекватного уровня обеспечения безопасности для сценариев, к которых он применяется, но то, что «адекватно» означает изменения в зависимости от конкретного контекста.
Например, защита Windows отличается от защиты Azure Cognitive Services, так как эти системы имеют очень разные размеры и характеристики. Ключевым аспектом моделирования угроз является балансировка затрат на риск для приложения. Хотя это может привести к решению избежать моделирования угроз в целом для некоторых сценариев, это так эффективно при правильном выполнении, что мы можем только рекомендовать его для любой ИТ-инициативы, включая проекты разработки программного обеспечения и развертывания инфраструктуры.
Важность фокусировки на roI
Последние пару лет наблюдается устойчивый рост интереса к моделированию угроз в качестве ключевого процесса разработки программного обеспечения. Этот интерес обусловлен экспоненциальным увеличением атак на инфраструктуру и решения. Такие инициативы, как NIST, рекомендуемые минимальный стандарт для поставщика или разработчика проверки кода и манифеста моделирования угроз, еще больше увеличили спрос на то, что текущие подходы показали некоторые ограничения. Например, результаты моделирования угроз сильно зависят от принятого процесса и от того, кто выполняет модель угроз. Таким образом, существует озабоченность по поводу постоянно более высокого качества из опыта.
Но что означает качество для моделирования угроз? Для нас модель угроз качества должна иметь следующие характеристики:
Он должен определить возможные меры по устранению рисков, действия, которые можно сделать, чтобы уменьшить потенциальные потери, вызванные атаками. Это означает, что эти меры должны быть четко определены, что означает, что вы получаете достаточно информации для их реализации, а затем протестируете реализацию. Это также означает, что они должны быть предоставлены, чтобы разрешить простое потребление от команды разработчиков. При использовании DevOps и Agile это означает, что существует простой путь для импорта мер по устранению рисков в невыполненную работу.
Для каждого устранения рисков он должен определить его состояние. Некоторые способы устранения рисков являются новыми, а другие уже существуют. Модель угроз должна распознавать, что уже существует и сосредоточиться на текущем риске, чтобы определить, как улучшить ситуацию.
Он должен четко определить, почему каждое устранение рисков требуется путем связывания его с соответствующими угрозами.
Кроме того, устранение рисков имеет относительную силу для каждой угрозы. Например, шифрование TLS может быть строгим устранением рисков, связанных с передачей данных, и в то же время это может быть почти полное устранение рисков, связанных с спуфингом сервера.
Угрозы должны быть надежными, четко определенными и характерными для решения.
Угрозы должны иметь связанную серьезность, которая должна учитывать как их вероятность, так и влияние. Серьезность должна быть разумной и идеально беспристрастной.
Необходимо получить комплексное представление о рисках и способах их решения. Это мнение будет способствовать вождения значимых разговоров с командой безопасности и с лицами, принимающими бизнес-решения, и это позволит нам скрыть ненужные сложности.
В этом списке уже показана важная концепция: моделирование угроз может обеспечить ценность для многих ролей, участвующих в жизненном цикле программного обеспечения, но каждая роль имеет разные потребности и требования. Например, разработчикам необходимо получить четкие сведения о том, что им нужно реализовать, и о том, как проверить, что они реализовали, как ожидалось. С другой стороны, группа безопасности обычно обеспокоена общей безопасностью экосистемы инфраструктуры и приложений, принадлежащих организации; таким образом, они должны получать информацию, позволяющую решить, является ли система в области достаточно безопасной и удовлетворяет требованиям соответствия требованиям. Наконец, владельцы продуктов и руководители бизнес-решений должны понять, что необходимо, чтобы сделать риск приемлемым для организации.
Такие различные потребности требуют предоставления различных представлений по модели угроз, каждая из них ориентирована на конкретный сценарий использования.
Типичные проблемы с моделированием угроз заключается в том, что чем более успешно, тем сложнее для немногих доступных экспертов покрыть спрос, хотя и обеспечить высокое качество, ожидаемое от этого опыта. В некоторых случаях качество может негативно повлиять на качество. Все хорошо, пока моделирование угроз не перестанет предоставлять значительную ценность по сравнению с инвестициями. Эта проблема затрагивает более нескольких организаций. Уже было несколько отчетов о лицах, принимающих бизнес-решения, начиная с вопроса о моделировании угроз, потому что это не позволит обеспечить значительную ценность для стоимости.
Со значением мы ссылаемся на значение бизнеса, которое позволяет предоставлять информацию, необходимую для понимания рисков, представленных системой в области, и двигаем значимый процесс принятия решений для выбора надлежащих мер, которые необходимо реализовать. Кроме того, значение также связано с предоставлением правильных сведений разработчикам и тестировщикам. Наконец, значение связано с обменом остаточным риском со всеми участвующими сторонами. Например, мы можем измерять значение, измеряя влияние процесса моделирования угроз. Предположим, мы измеряем общий риск для решения, назначив число серьезности, определяемой каждой угрозой. В этом случае мы ожидаем, что общий риск уменьшается с течением времени на влияние модели угроз. Если общий риск остается постоянным или увеличивается, у нас может возникнуть проблема. Чем круче снижение, тем выше влияние модели угроз. Конечно, модель угроз не будет контролировать реализованные меры по устранению рисков. Ответственность владельца продукта заключается в принятии решения о том, что необходимо реализовать. Но преимущество связывания эффективности модели угроз с фактической реализацией мер по устранению рисков заключается в том, что это повышает влияние на фактическую безопасность решения, уменьшая риск того, что модель угроз остается теоретическим упражнением.
Вместо этого стоимость связана с действиями, необходимыми для выполнения самой модели угроз, что является временем, необходимым для всех заинтересованных сторон для создания модели угроз и обсуждения этой модели.
Это повещает вопрос: можно ли определить процесс моделирования угроз, ориентированный на максимизацию бизнес-ценности и минимизацию затрат?
Важность DevOps
Мы уже подчеркнули, насколько важно убедиться, что моделирование угроз является ценной практикой, интегрированной с процессом DevOps. Это означает, что процесс должен быть доступен всем участникам команды, обычно упрощая и автоматив его. Самое главное, чтобы сосредоточиться на моделировании угроз для DevOps, необходимо убедиться, что интерфейс тесно интегрирован с существующими процессами DevOps.
Моделирование угроз не должно стать еще одним бременем, но вместо этого он должен быть активом для упрощения требований безопасности и сбора, проектирования безопасных решений, включения действий в средство отслеживания задач и ошибок, а также оценки остаточного риска, учитывающего текущее и будущее решение.
Выравнивание с devOps
Мы можем использовать различные методы для выравнивания моделирования угроз с использованием текущей практики DevOps.
Угрозы и устранение рисков
Во-первых, мы должны сосредоточиться на процессе моделирования угроз на том, что необходимо сделать. Угрозы, которые являются шаблонами атак и как они могут произойти, необходимо объяснить, почему команда должна реализовать контроль безопасности. Они также являются фактором определения того, когда следует реализовать меры по устранению рисков. Тем не менее, реальная цель состоит в том, чтобы определить, что необходимо сделать: устранение рисков. Таким образом, подход должен привести к быстрой идентификации необходимых мер и должен информировать процесс принятия решений, чтобы было проще определить, что делать и когда. Основной доставить этот процесс принятия решений заключается в наличии выбранных мер в невыполненной работы, чтобы сделать их частью стандартного процесса. В идеале средство моделирования угроз и средство отслеживания ошибок должны быть синхронизированы, чтобы отразить обновления состояния устранения рисков в модели угроз. Это позволит динамически и автоматически изменить остаточный риск, который жизненно важен для поддержки обоснованных решений в рамках обычных хореографий принятой методологии Гибкой разработки, таких как собрание по планированию спринта.
Что вы можете сделать сегодня?
В качестве эксперта по моделированию угроз необходимо обеспечить реализацию процесса моделирования угроз, который может четко определить действия и включить их в выбранный вариант отслеживания задач и ошибок. Одним из способов может быть внедрение одного из многих средств моделирования угроз, способных автоматизировать этот процесс.
В качестве разработчика следует сосредоточиться на элементах управления безопасностью, которые определены по мере необходимости. Процесс должен быть разработан для предоставления им таким же образом, как вы ожидаете получить любое другое действие.
Функции, истории пользователей и задачи
Мы уже заявили, что устранение рисков представляет собой наиболее важный артефакт, созданный моделью угроз, относящейся к интеграции DevOps. Поэтому важно четко определить тип объектов, созданных из этих мер, на выбранном средстве отслеживания задач и ошибок. Некоторые способы устранения рисков могут длиться больше, чем спринт. Поэтому их можно создать как функции. Но многие из них проще и могут быть реализованы в одном Спринте; таким образом, можно было бы представить их как истории пользователей или задачи. При создании различных типов рабочих элементов это может привести к сложному процессу, что может привести к ошибкам и путанице. По этой причине кажется более практическим придерживаться одного типа рабочего элемента. Учитывая, что устранение рисков может рассматриваться как дочерние истории пользователей, вы можете рассмотреть возможность представления их в качестве задач, что подразумевает расслабление требования к типу указанного рабочего элемента, выполняемого в одном Спринте.
Что вы можете сделать сегодня?
Убедитесь, что в невыполненной работы представлены средства устранения рисков, выявленные моделью угроз. Определите способ четкого представления их.
Пользовательские Истории
Устранение рисков не является единственной частью модели угроз, которая может быть согласована с тем, что у вас есть в средстве отслеживания задач и ошибок. Например, может потребоваться также представлять угрозы. Эта цель может быть достигнута путем расширения пользовательских историй путем добавления предложения WITHOUT к обычному "Как кто я] я хочу [что я хочу], чтобы я мог [сделать что-то]". Например: "Как пользователь, я хочу платить с моей кредитной картой, чтобы я смогу купить некоторые товары, не имея моей кредитной карты украденные данные". Предложение WITHOUT может быть сопоставлено с одной или несколькими угрозами, а иногда и разрешено выражать требования к безопасности. Убедившись, что это выравнивание между угрозами и предложениями БЕЗ явным образом осуществляется в модели угроз, мы можем гарантировать, что возможные риски отражаются и заботятся команде, так как они включены в состав пользовательских историй. Вы также можете использовать эту связь для сопоставления всех требований безопасности, определенных как часть историй пользователей, по крайней мере угрозой.
Приятно знать
Предложение WITHOUT не является исходной идеей команды, которая подготовила эту страницу. Мы не уверены, кто впервые представил его, но мы благодарны тем, кто пришел с этой идеей.
Рис. 1. Выравнивание требований
Например, на предыдущем рисунке показаны следующие ситуации:
Угроза A связана с user Story 1 с помощью предложения БЕЗ 1.
Угроза B связана с пользовательской историей 2 с помощью предложения БЕЗ 2.
Угроза B также связана с историей пользователя 3. Но пользовательская история 3 не назначена ни одному предложению БЕЗ. Почему? Он представляет потенциальную аномалию, которую следует исследовать.
Угроза B также связана с пользовательской историей 1. Пока не ясно, следует ли разрешить наличие историй пользователей, связанных с несколькими угрозами.
Угроза C связана с пользовательской историей 4, которая связана с БЕЗ 3 и 4. Пока не ясно, следует ли разрешить наличие нескольких предложений БЕЗ.
Угроза D не связана с какой-либо историей пользователя. Отсутствует ли у нас история пользователя или предложение БЕЗ?
История пользователя 5 связана с предложением WITHOUT, но не связана с угрозой. Отсутствует ли угроза или просто связь между историей пользователя и угрозой?
Мы редко определяем требования к безопасности в рамках модели угроз. Таким образом, предложение WITHOUT представляет возможность дальнейшего интеграции взаимодействия, расширяя модели угроз с требованиями безопасности и связывая их с соответствующими историями пользователей. Этот подход будет играть важную роль в развитии опыта моделирования угроз от того, как оценка повторяется с течением времени, чтобы стать средством разработки безопасности для DevOps.
Что вы можете сделать сегодня?
Начните использовать предложение WITHOUT в ваших историях пользователя.
Сопоставляйте угрозы, которые вы определяете с пользовательскими историями с предложениями БЕЗ, и наоборот.
Интегрированный интерфейс
Вы можете применить ту же идею к другим сценариям. Например, модель угроз может связать требования к безопасности с артефактами внутри самой модели угроз, например угроз и устранения рисков, и теми, которые в средстве отслеживания ошибок и отслеживания ошибок. Например, требование реализовать мониторинг для выявления атак, выполняемых в ходе выполнения, следует сопоставить со всеми этими средствами устранения рисков, связанными с мониторингом, а затем с соответствующими артефактами в средстве отслеживания задач и ошибок. В результате было бы легко определить ситуации, когда требование безопасности не реализовано: на самом деле это не будет связано с чем-либо.
Вы можете использовать те же связи между артефактами в средстве отслеживания задач и ошибок, а также угрозы и устранение рисков, определенных моделью угроз, для упрощения приоритета действий безопасности. Безопасность обычно реализуется последней, иногда для устранения уязвимостей, обнаруженных некоторыми средствами или тестом на проникновение. Напротив, наиболее эффективным будет реализация мер по устранению рисков вместе со связанными историями пользователей или функциями. Зачем ждать реализации элементов управления для защиты сведений о кредитной карте, когда их следует реализовать вместе с соответствующими функциями оплаты? Модель угроз должна выделить эти связи и предоставить простой способ определить при реализации некоторых функций во время Спринта требует реализации некоторых связанных функций безопасности. Эти сведения можно использовать, например, во время собрания по планированию спринта, чтобы иметь понятное обсуждение и обеспечить информированную приоритетность. Механизм прост. Предположим, что владелец продукта для проекта, над которым мы работаем, решает запланировать историю пользователя для следующего Спринта. Указанная история пользователя имеет предложение WITHOUT, связанное с угрозой. Модель угроз определяет несколько рисков для одной и той же угрозы. Таким образом, мы можем немедленно определить, что мы должны определить приоритеты одного или нескольких выявленных мер.
Рис. 2. Приоритет безопасности
Например, на рисунке выше мы видим, что история пользователя 1 связана с угрозой 1, которая, в свою очередь, связана с устранением рисков A и B. Поэтому мы также должны рассмотреть вопрос о реализации одного или обоих этих мер.
Что вы можете сделать сегодня?
Связывание пользовательских историй с предложениями БЕЗ рабочих элементов, соответствующих выбранным устранению рисков, с помощью модели угроз в качестве ссылки. При планировании следующего Спринта обязательно определите приоритеты связанных действий безопасности при реализации одной из этих историй пользователей с предложениями WITHOUT.
Интеграция для выделения несоответствий
Когда мы начнем думать о том, как мы можем связать артефакты, составляющие модель угроз с теми, которые в средстве отслеживания задач и ошибок, становится проще определить возможности для улучшения качества обоих. Ключ заключается в том, чтобы использовать свои отношения для выделения несоответствий и использования информации, присутствующих в одном, для дополнения, интеграции и интерпретации того, что присутствует в другом. Как описано выше, вы можете сделать это без существенного влияния на то, как команда уже работает. Это связано с тем, что подход зависит от существующей информации и создает связи между различными объектами в различных мирах. Таким образом, модель угроз станет источником истины для безопасности решения. В то же время невыполненная работа постоянно соответствует состоянию решения.
Что вы можете сделать сегодня?
Регулярно убедитесь, что нет несопоставленных угроз или пользовательских историй с предложениями WITHOUT.
Моделирование угроз и операции
Все эти идеи в основном сосредоточены на стороне разработки DevOps. Можем ли мы сделать что-то, чтобы улучшить операции, а также? Мы так думаем. Например, можно было бы использовать моделирование угроз в качестве средства для упрощения анализа первопричин, так как он предоставляет комплексное представление системы с точки зрения безопасности и, таким образом, может обеспечить лучшее понимание последствий некоторых атак. Для этого необходимо интегрировать модель угроз с существующими веб-каналами из выбранных средств мониторинга. Этот подход может представлять собой дополнение для выбранного SIEM.
Другая идея интеграции моделирования угроз с Operations заключается в том, чтобы использовать первый способ разработки того, как это может произойти. Примером этого является проектирование событий для решения. Моделирование угроз идентифицирует возможные атаки, и мы можем использовать эти знания для выявления событий, которые решение в области может вызывать при сбое этих атак. Если вы выполняете строгую проверку входных данных, злоумышленнику потребуется несколько попыток, прежде чем выполнить успешное выполнение. Первоначально попытки завершаются ошибкой, и одна из них в конечном итоге завершается успешно. Создавая события для каждого сбоя и запуска оповещений при достижении определенного порогового значения, вы можете обнаруживать атаки и принимать меры для их устранения. Эти ситуации редко обнаруживаются, если вы ограничиваете себя мониторингом инфраструктуры. Поэтому необходимо включить пользовательские события, которые команда должна разработать и реализовать, прежде чем SOC может использовать их.
Кроме того, последний может не знать много о решении. Поэтому SOC может не иметь возможности определить, как реагировать при сбое проверки входных данных. К сожалению, когда возникает нарушение данных, необходимо быстро реагировать на снижение прямого ущерба и вероятности и сущности в конечном счете штрафов.
Поэтому мы должны заранее спланировать, что необходимо отслеживать, в каких условиях у нас может возникнуть проблема, и что делать, когда это произойдет. Лучший способ идентификации этих событий — полагаться на модель угроз. Поэтому было бы полезно использовать его для создания стандартных артефактов для руководства и ускорения реализации необходимых конфигураций для управления мониторингом и аудитом и упрощения реагирования на инциденты.
Что вы можете сделать сегодня?
Активно используйте модель угроз для выявления событий, которые можно вызвать для каждой угрозы. Эти события могут быть предоставлены инфраструктурой или что-то, что приложение должно вызывать. Включите рабочие элементы в невыполненную работу, чтобы убедиться, что эти события реализованы.
Активно сотрудничайте с командами по операциям и безопасности, в том числе командой SOC, чтобы обеспечить использование событий для создания оповещений и выявления инцидентов безопасности.
Влияние на roI
Вы можете задаться вопросом, почему эти методы могут положительно повлиять на рентабельность моделирования угроз. С нашей точки зрения, они важны для повышения ценности моделирования угроз для команд DevOps. Проблема, которую мы неоднократно видели, заключается в том, что эти команды воспринимают безопасность как стоимость, которая обеспечивает ограниченную ценность и требует много непредвиденных работ. Иногда неясно, почему они должны инвестировать столько времени, чтобы исправить безопасность. В результате безопасность становится проблемой, а не возможностью. Моделирование угроз может преодолеть эти проблемы, так как это дает основания для реализации безопасности. Кроме того, его можно начать в начале процесса разработки и избежать ошибок разработки, которые могут стоить дорого, если не обнаружено в ближайшее время. Описанные выше методы направлены на более эффективное интеграцию моделирования угроз с DevOps. Это гарантирует, что разработчики бизнес-решений и разработчики воспринимают моделирование угроз как естественное дополнение к процессу разработки и эксплуатации. Таким образом, значение, полученное путем внедрения моделирования угроз, увеличивается, и его затраты снижаются из-за интеграции с различными инструментами, уже используемыми.
Упрощение работы для моделей угроз
Еще один важный аспект, необходимый для улучшения roI моделирования угроз, связан с сокращением ее затрат и увеличением числа людей, способных доставить его, сохраняя более однородные уровни качества.
Существует много попыток решить нехватку компетентных людей. Некоторые из них основаны на активном участии всей команды DevOps в упражнении моделирования угроз. Идея заключается в том, чтобы определить лидера инициативы, то есть кто-то с промежуточными знаниями о процессе, но не обязательно эксперт, и привести ее к обсуждению среди других членов группы. Этот подход активно поддерживается подписавшими манифест моделирования угроз.
Мы согласны с тем, что этот подход позволяет получить хорошую ценность и представляет собой улучшение текущей ситуации. Он также предоставляет хорошие аналитические сведения и позволяет команде развивать свою культуру безопасности. Тем не менее, это не без недостатков, потому что он охватывает всего несколько вопросов, оставляя много. Это создает проблему согласованности, потому что было бы слишком легко идти вниз кролика отверстие и тратить драгоценное время на вторичные вопросы, отсутствующие важные. Опыт лидера будет играть важную роль в предотвращении этих ситуаций. Кроме того, этот подход требует много времени от всех членов команды для обсуждения каждой проблемы.
По этой причине даже тратить пару часов на Спринт для этого упражнения может представлять собой значительные инвестиции. Все знают, что большинство команд, как правило, тратить время на большие собрания с участием всех, и эти сеансы моделирования угроз не будут делать исключения. Тем не менее, этот подход отлично подходит для небольших продуктов, где команда состоит из горстки старших членов.
Другой подход
Учитывая ограничения предыдущего подхода, мы предпочитаем ограничить количество собраний, их продолжительность и количество участников. Таким образом, ответственность моделирователя угроз будет более значительной: не только вести интервью, но и создавать и поддерживать саму модель угроз. Этот подход требует более значительных компетенций и знаний. Моделиторы угроз могут быть представлены чемпионами безопасности или членами внутренней группы безопасности. Большинство организаций будут идти в первую очередь, так как команда безопасности обычно полностью забронирована.
Чемпионы безопасности являются членами команд DevOps с определенным интересом к безопасности. Они не эксперты ни в коем случае, но у них есть базовые знания и готовность улучшить безопасность своей команды. Идея состоит в том, чтобы создать привилегированное соединение между чемпионами безопасности и внутренней командой безопасности, чтобы первое было разрешено помочь своим командам в правильном выполнении, в то время как команда безопасности может снизить свою рабочую нагрузку. С моделированием угроз чемпионы безопасности будут выступать в качестве моделей угроз, и внутренняя группа безопасности будет отвечать за руководство и просмотр их работы.
Что вы можете сделать сегодня?
Изучите возможность внедрения программы "Чемпионы безопасности" и ее использования для дальнейшего укрепления жизненного цикла разработки программного обеспечения.
Роль база знаний
Важная проблема с моделированием угроз заключается в том, что качество опыта и ценность команды DevOps высока независимо от того, кто выполняет модель угроз. С чемпионами безопасности эта проблема становится еще более срочной. Идея решения этой проблемы заключается в предоставлении база знаний для создания модели угроз. Базы знаний для моделирования угроз — это пакеты сведений о определенном контексте: они содержат определение сущностей, связанных с этим контекстом, возможные шаблоны атак по этим сущностям и стандартные способы устранения рисков, которые можно применить. Базы знаний позволяют организации получать более согласованные результаты, так как они представляют справочные материалы, направляющие моделиров угроз в предписательном виде. Базы знаний должны иметь правила, позволяющие автоматически применять угрозы и устранение рисков к системе. Эта автоматизация позволит нам преодолеть тот факт, что некоторые моделиторы угроз могут не иметь опыта, необходимого для определения того, следует ли применять угрозу или если некоторые способы устранения рисков эффективны.
Базы знаний не являются новой идеей: многие текущие средства моделирования угроз уже поддерживают их в некоторой форме. Но многие текущие реализации имеют значительные недостатки. Например, вы можете легко поддерживать база знаний. Их удобство обслуживания — это проблема, которая по-прежнему не решена. Например, не легко определить лучшие источники информации, которые следует использовать для их создания. Кроме того, обслуживание обычно выполняется вручную. Создание и обслуживание база знаний должны быть ответственностью внутренней группы безопасности организации. Мы надеемся, что компании начнут предоставлять база знаний для наиболее распространенных средств моделирования угроз, чтобы поднять некоторые нагрузки от своих клиентов в будущем. Эти база знаний должны быть гибкими для поддержки и облегчения их внедрения даже самыми зрелыми организациями, которые должны адаптировать указанные база знаний к их практике, политике и нормативным требованиям.
Что вы можете сделать сегодня?
Рассмотрим возможность посвятить часть усилий централизованной группы безопасности для разработки база знаний, которые могут использоваться различными командами разработчиков для ускорения моделирования угроз.
Использование база знаний
Другая проблема с база знаний заключается в том, что иногда они слишком сложны для использования. Многие из них пытаются быть всеобъемлющими, включая основные и менее важные проблемы. К сожалению, не все они требуются всеми системами. При анализе системы требуется более простой подход, который не обрабатывает конфиденциальные данные. Напротив, вы хотите получить более подробную информацию, если система сложна и обрабатывает личные данные и высокопроизводительные данные. Таким образом, необходимо применить различные версии знаний в зависимости от контекста или пометить некоторые шаблоны атак и связанные с ними способы устранения рисков как TOP. В результате моделиторы угроз смогут решить, хотят ли они комплексного опыта или легко и свести к минимуму необходимую работу.
Говоря о эффективности, необходимо обеспечить упрощение и автоматизацию деятельности как можно больше, чтобы сократить объем необходимой работы. Мы считаем, что сладкое место для выполнения модели угроз среднего размера решения должно быть 1 день работы для модели угроз. Такие результаты возможны только в том случае, если средство выбора предоставляет акселераторы, чтобы позволить сократить необходимое время. Например, если средство применяет 20 разных типов устранения рисков в 100 разных местах, и вам предлагается указать для каждого из них их состояние, вы будете более 5 раз эффективнее, сосредоточив внимание на первом, а не на последнем. Выбор средства должен обеспечить эту возможность, предоставляя возможность выполнять более тщательную работу при необходимости.
Что вы можете сделать сегодня?
Если база знаний, которые вы используете сегодня, не поддерживают концепцию "TOP" угроз и устранения рисков, рассмотрите возможность удалить то, что редко необходимо или полезно, чтобы разрешить сосредоточиться только на том, что действительно важно.
Иногда проблема заключается в том, что принятые база знаний пытаются быть универсальными и охватывать несколько сценариев. Вы можете улучшить ситуацию, специализируясь на них.
Задавать правильные вопросы
Во время нашего анализа мы рассмотрели возможность использования средства для поддержки платформы вопросов для выполнения первых этапов анализа. Мы заметили, что большинство неопытных моделей угроз не могут задавать правильные вопросы, чтобы получить информацию, необходимую для их анализа. Некоторые из наших экспертов показали, что можно определить некоторые важные вопросы на основе системной схемы в области. Эти вопросы могут применяться даже автоматически, с некоторыми правилами создания. Проблема заключается в том, что этот подход может не предоставить значение, которое, кажется, обещает. Это было бы потому, что вам нужно понять обоснование каждого вопроса. В противном случае вы не сможете оценить ответ и определить, является ли оно удовлетворительно. Тем не менее, автоматическое создание вопросов может обеспечить значительную ценность для менее экспертных моделей угроз, повышая их понимание систем в области.
Что вы можете сделать сегодня?
Внедрение структурированного подхода к вопросу. Например, наша команда получила хорошие результаты, приняв Microsoft STRIDE в качестве ссылки. Это можно сделать, задав каждому компоненту таких вопросов решения, как:
Спуфинг: как компонент проходит проверку подлинности в отношении служб и ресурсов, которые он использует?
Изменение: проверяет ли компонент получаемые сообщения? Является ли проверка слабой или строгой?
Отказ: является ли компонент ведение журнала взаимодействия в журнале аудита?
Раскрытие информации: является ли трафик входящий и исходящий компонент зашифрованным? Какие протоколы и алгоритмы разрешены?
Отказ в обслуживании: настроен ли компонент в высокой доступности? Защищается ли она от атак DDoS?
Повышение привилегий: являются ли пользователи, которым назначены минимальные привилегии? Предназначен ли код решения для обычных пользователей с высоким уровнем привилегий?
Такие методы можно научить и улучшить с опытом. Поэтому важно реализовать подход непрерывного обучения, предназначенный для сбора обучения и распространения их в организации.
Влияние на roI
В нижней строке можно определить множество идей для повышения эффективности опыта моделирования угроз, его качества и в конечном итоге увеличить рентабельность инвестиций. Эти усилия следует рассматривать как непрерывный процесс, который следует направить на непрерывное улучшение практики.
Заключения
Моделирование угроз — это отличная методология для улучшения безопасности организации. Если это сделано правильно, оно может предоставить значение для очень разумной стоимости. Мы уже определили различные методы, которые могут оказаться важными для улучшения ценности моделирования угроз для защиты современных решений, в том числе:
Выравнивание модели угроз с помощью практики DevOps
Фокус на устранении рисков
Связывание рисков с историями пользователей
Выделение несоответствий между моделью угроз и невыполненной работой
Использование модели угроз для более полного мониторинга и аудита для обеспечения безопасности
Упрощение создания моделей угроз и повышение согласованности результатов
Опирайтесь на чемпионов безопасности
Внедрение база знаний для автоматизации идентификации угроз и устранения рисков
Создание лучших база знаний
Предоставление платформы вопросов, поддерживаемой автоматизацией
Надеюсь, некоторые из них уже можно найти в выбранном средстве моделирования угроз. Другие будут включены в будущее. Мы знаем, что максимизация roI для моделирования угроз является долгосрочным усилием, который требует ответов, которые у нас еще нет. Мы также знаем, что некоторые вопросы по-прежнему неизвестны. Эта статья должна предоставить некоторые продукты питания для мысли и, надеюсь, поможет вам улучшить способ моделирования угроз. Мы надеемся, что это может быть маяк для вас и нас, и что будет полезно направить наши усилия на эти годы.