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