Как перейти от эфемерных угроз к реальным техникам злоумышленников?

Угрозы
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 описание этой техники (именно техники, а не угрозы) более практично — указаны:

  • источники данных (сетевой трафик, прокси, почтовые шлюзы, почтовые сервера, записи DNS, результаты инспекции TLS/SSL и т.п.)
  • использующие эту технику хакерские группировки (полезно для атрибуции и понимания других атак, используемых этой же группировкой)
  • защитные меры (учитывая, что под фишингом MITRE также понимает только атаку на уровне e-mail, то список защитных мер очень слабенький, — я бы расширил его)
  • методы обнаружения.
Если бы в БДУ можно было бы добавить либо ссылки на MITRE ATT&CK, либо переписать матрицу своими словами, то практическая пользу от БДУ возросла бы на пару порядков (и не забыть систематизировать названия угроз). И нельзя сказать, что ФСТЭК не использует ATT&CK в своей работе и не соотносит угрозы из БДУ с ATT&CK. Вот, например, слайд из презентации авторов БДУ.
Но вот в БДУ пока таких отсылок не появилось, чего не хватает 🙁 Кстати, о систематизации в той же матрице MITRE. У нее есть вполне понятная модель, согласно которой авторы и развивают ее.
Есть и чуть более сложная таксономия этих элементов:

Схожую, но учитывающую также понятия инцидент (он в проекте методики моделирования угроз ФСТЭК есть и он отличается от определения ФСБ), уязвимость и атака, модель можно было бы разработать и для целей наших регуляторов. Тогда можно было бы, по примеру MITRE, привлекать и внешних экспертов, которые бы понимали, как развивается БДУ и смогли бы вносить свой посильный вклад, опираясь на свой практический опыт.

Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

Нажимая кнопку "Отправить", я даю свое согласие на обработку персональных данных (если вдруг они указаны в комментарии) в соответствие с политикой конфиденциальности. Также я соглашаюсь с тем, что в своем комментарии не раскрываю никаких сведений, составляющих государственную тайну, а также никакой иной информации, охраняемой законом (для этого используйте иные способы :-) ), если это не разрешено ее владельцем. Ваш комментарий может появиться не сразу, а после модерации (так бывает не всегда, но бывает).

  1. Алексей Гавриш

    Алексей, а эта статья ушла в каком то виде во ФСТЭК как комментрай к проекту новой методики?

    Ответить
  2. Андрей Титов

    А вот как это реализуется на практике https://www.recordedfuture.com/machine-learning-cybersecurity-applications/

    Ответить
  3. Валерий Сигитов

    Это все очень красиво звучит, но кто этой методикой фстэк, кроме госов и пары фанатов выпоонения требований к пдн, пользоваться будет? Правильно — никто.
    А если учесть, что 99 процентов госов имеют в роли ответственных за иб людей, которые компьютер с трудом включают, то ваши красивые идеи просто разбиваются о чугунную жопу реальности. .

    Ответить
  4. Vladimir Minakov

    Этот комментарий был удален автором.

    Ответить
  5. Vladimir Minakov

    1. Значительная часть угроз не может быть промоделирована через ATT@CK
    2. Нумерация БДУ идентична по характеру нумерациям CVE, CWE, CAPEC. Почему не начать применять свою "волю" там? Всё ж Cisco, может, попроще сделать так, чтоб в американских базах не было, как Вы пишите "включены они в перечень вразнобой, без какой-либо понятной систематизации"
    3. А так, кому надо уже делают продукты для моделирования и связывают те, базы которые нужны. И не останавливаются на CVE/NVD/БД уязвимостей
    4. По моим прикидкам, даже если ФСТЭК сделает и выложит эту связь части угроз ФСТЭК с аттаск, кто этим будет пользоваться? Из дипломированный ИБшников по моим прикидкам — не более 5 %, при том что БДУ сейчас понимают и используют подавляющее большинство. Такую связь смогут использовать только разработчики GRC продуктов для крупных компаний. Ну так они и сами всё делают.

    Ответить
  6. Алексей Лукацкий

    Алексей Гавриш: пока нет 🙂 Вот на днях выложат проект методики, можно будет предложить как идею. На первой стадии обсуждения такие детали не нужны были — там и без этих предложений было куда развиваться.

    Андрей Титов: статья RF все-таки про другое

    Валерий Сигитов: этой методикой будут обязаны пользоваться несколько тысяч организаций, что уже немало. А при хорошей методике ею бы и другие пользовались.

    Владимир Минаков: Да, не может, я про это упомянул, что в БДУ далеко не все угрозы технические и связаны с злоумышленниками. У той же CAPEC есть категории, которые и позволяют отделить одни угрозы от других. В ATT&CK тоже есть четкая иерархия. А в БДУ она идет сплошняком без какой-либо идеи. Если уж оставлять текущую нумерацию, то добавлять обязательно "срезы" или "view" как в той же CAPEC. Без связи БДУ с чем-то практическим, она превращается в очередную тыкву бумажной безопасности 🙁

    Ответить
  7. Unknown

    Алексей, а можно подробней о "недавно утвержденной методике моделирования угроз"? Где выложена или как обычно она имеет гриф ДСП и о ней никак регулятор не уведомляет обычных смертных?

    Ответить
  8. Алексей Лукацкий

    Посмотрите начало статьи. Она про будущее 🙂 Есть надежда, что в первом квартале новую методику утвердят

    Ответить
  9. Александр Германович

    Кому нужна реальная защита те уже давно имеют свою модель угроз и систему защиты информации.
    Кому нужна зашита от регулятора, напишут строго по методике и все будут довольны.

    Ответить
  10. Алексей Лукацкий

    Это большое заблуждение, что многие имеют модель угроз. Многие считают, что ее имеют, но обычно она очень фрагментарна и многих угроз вообще не учитывает.

    Ответить