8 марта 2020 года. Ваши коллеги празднуют женский день, а вы вынуждены разрабатывать модель угроз по недавно утвержденной методике моделирования угроз ФСТЭК, так как к концу первого квартала у вас запланировано согласование этого документа с регулятором. И вот вы составили предварительный перечень угроз, среди которых у вас есть, например, УБИ.175 (фишинг). Я оставлю в стороне, что это описание неполное, так как исходит из того, что фишинг, это угроза только для электронной почты, в то время как фишинг может быть реализован и через блоги, и соцсети, и телефон, и SMS/MMS, и мессенджеры, и т.п. Вариантов может быть очень много, но суть не в этом.
А еще и включены они в перечень вразнобой, без какой-либо понятной систематизации. Ну вот возьмем угрозу УБИ.041 (угроза межсайтового скриптинга), которая вообще-то угрозой и не является. Это всего лишь некая техника, используемая для компрометации пользовательского компьютера для последующего выполнения той или иной задачи. Но допустим, это угроза. Но как она могла попасть сразу за УБИ.040, упомянутой выше? А спустя несколько пунктов мы встречаем УБИ.058 (угроза неконтролируемого роста числа виртуальных машин). Но почему только виртуальных машин? А где контейнеры? И кстати, почему это угроза применяется только к облакам, но не к собственным ЦОДам, в которых тоже могут применяться виртуалки? А УБИ.070 (угроза непрерывной модификации облачной инфраструктуры)? Под ней понимается всего лишь внесение уязвимостей с обновляемым ПО. Но только в облаках. А в корпоративной или ведомственной сети? А на промышленной площадке? Какие-то хаотические скачки от реальных угроз, идущих со стороны хакеров, к геополитическим угрозам, а потом снова к техническим угрозам, но на аппаратном уровне, а потом к косякам администрирования... Я так и не смог понять логику в нумерации и боюсь что ее просто нет - угрозы добавляют бессистемно, по мере попадания их в голову разработчиков БДУ. Постепенное наполнение БДУ - это неплохо, но лучше бы, чтобы нумерация угроз подчинялась понятной и четко структурированной таксономии , которой нет. Будь моя воля, я бы поменял там всю нумерацию с одноуровневой на многоуровневую и подчинил ее понятной иерархии и структуре.
Вернемся к kill chain. Если я буду опираться только на БДУ, то она мне дает ответ на вопрос "ЧТО может плохого произойти?". Но для нейтрализации этих угроз этого недостаточно. Повторюсь, мне нужно получить ответ на вопрос "КАК?" В случае с угрозами злоумышленников правильно было бы провести декомпозицию и разбить их (угрозы, а не злоумышленников) на этапы, которые можно будет затем привязать к тактикам и техникам, используемым злоумышленниками.
- источники данных (сетевой трафик, прокси, почтовые шлюзы, почтовые сервера, записи DNS, результаты инспекции TLS/SSL и т.п.)
- использующие эту технику хакерские группировки (полезно для атрибуции и понимания других атак, используемых этой же группировкой)
- защитные меры (учитывая, что под фишингом MITRE также понимает только атаку на уровне e-mail, то список защитных мер очень слабенький, - я бы расширил его)
- методы обнаружения.