Что делать, когда вас кинули производители контента обнаружения?

SecOps

В 2001-м году в своей книге “Обнаружение атак” я привел следующую статистику — 86,5% пользователей систем обнаружения атак никогда не создают собственных сигнатур атак (контента обнаружения), даже если у используемых ими решений есть такая возможность. Прошедшие 20 лет показали, что такая беспечность (хотя она и понятна — мы покупаем коммерческие продукты во многом именно для того, чтобы за нас все делал производитель) может дать сбой. Вот три примера, когда фокус на внешних поставщиков данных об угрозах может привести к печальным последствиям.

А откуда вы берете контент обнаружения угроз?
От производителя средства защиты
56.73%
Скачиваю также из открытых источников TI
19.23%
Также покупаю контент обнаружения у специализированных компаний
8.65%
Пишу сам (наряду с любым из вариантов выше)
15.38%
Проголосовало: 104

Первая история началась в 2014-м году, когда DTCC и FS-ISAC (аналог нашего ФинЦЕРТа) объявили о создании совместного предприятия по разработке решения Soltra, которое позволяло автоматически обмениваться данными об угрозах (threat intelligence). До этого момента консолидация фидов из множества источников, и их анализ с последующим распространением, осуществлялись преимущественно вручную. Фокусировка на финансовом секторе и грамотная архитектура привели к тому, что спустя год Soltra Edge использовали 2900 компаний из 77 стран мира (считается, что благодаря именно Soltra стали популярными протоколы STIX и TAXII, превратившиеся по сути в стандарты де-факто). В 2015-м году DTCC и FS-ISAC решили уйти от P2P-архитектуры в сторону централизованной и лучше масштабируемой схемы, а также выйти за пределы только финансового сектора, и запустили Soltra Network, которую, по мнению основателей было проще монетизировать. Однако, что-то пошло не так и 15 ноября 2016 года DTCC и FS-ISAC объявили о немедленном (!) прекращении поддержки и обновлении Soltra. Руководство двух организаций признало, что это создает трудности для всех пользователей, но так и не объяснили причину столь стремительного, без какого-либо переходного периода, завершения поддержки своей TIP-платформы. Да, на тот момент на рынке уже существовало несколько десятков коммерческих и open source решений, поддерживающих STIX/TAXII, но сама история оказалась очень неприятной.

В том же году внезапно прекратила свое существование другая компания, занимавшаяся Threat Intelligence, — Norse Corp. (хотя некоторые эксперты обвиняли Norse, что они часто распространяли совсем не intelligence, а просто сырые, а иногда и вовсе непроверенные данные об угрозах), известная своим расследованием взлома Sony в 2014-м году и своей интерактивной картой кибератак. История до сих пор умалчивает все детали произошедшего, но факт есть факт — сайт компания практически внезапно ушел в оффлайн в январе 2016-года, а e-mail’ы компании не отвечали. Заказчики перестали получать фиды от Norse. Сейчас про эту компанию уже никто и не вспоминает, но эта история вновь подсвечивает проблему зависимости от поставщика данных об угрозах.

Третью историю мы наблюдаем сейчас — многие зарубежные компании либо приостановили свою деятельность, либо ушли из России, оставив десятки или сотни тысячи инсталлированных средств ИБ без обновления, в том числе и без обновления сигнатур вирусов, атак, правил SIEM и т.п. Я про риски получения данных об угрозах из одного источника говорил еще в 2017-м году в своей презентациивидео) про «Окно Джохари», но сейчас, спустя 5 лет, история вновь расставила все по своим местам:

Риски получения данных об угрозах из одного источника
Риски получения данных об угрозах из одного источника (моя презентация 2017-го года)

Три эти истории ставят перед нами простой вопрос — а как защититься от повтора в будущем? Как сделать так, чтобы, не взирая ни на какие санкции и внезапные уходы компаний с рынка (в том числе и из конкретной страны — вспомним Splunk), мы могли и дальше продолжать обнаруживать текущие и новые угрозы? Да, можно обратиться к услугам аутсорсинговых SOCов, которые с радостью возьмут на себя вашу головную боль и будут писать контент обнаружения за вас и для вас. Но есть ли гарантия, что и они не кинут вас под влиянием непредвиденных (или нежелаемых быть предвиденными) событий? Ее нет. Отсюда возникает вполне очевидный вывод:

Надо учиться самим писать контент обнаружения!

Это не так сложно, как может показаться, хотя и сложнее, чем включить функцию автоматического обновления сигнатур в своей IDS или подгрузки правил и use case из маркетплейса SIEM. На мой взгляд фокусироваться инженеру/аналитику по обнаружению угроз сегодня нужно всего на 3-4 инструментах/языках описания угроз (помимо понимания Regex):

  • Для сетевого трафика — Snort. Snort был и остается одной из самых популярных сетевых систем обнаружения атак, которая легла в основу и многих коммерческих, в том числе и российских, продуктов. Язык описания шаблонов различных нарушений в сетевом трафике, реализованный в Snort, стал стандартом де-факто. Он же совместим и с описанием обнаруживаемых нарушений ИБ в Suricata.
  • Для файлов — YARA. Этот, базирующийся на правилах, инструмент позволяет проводить расследования в области ИБ на узлах, находя на них следы вредоносной активности. 
  • Для логов — SIGMA. Одна из уникальных возможностей Sigma — совместимость со многими средствами мониторинга и расследования инцидентов ИБ. Какое бы решение вы не использовали, коммерческое или open source, можно быть уверенным, что ваши правила Sigma подойдут ко многим из них либо без какой-либо переделки, либо с незначительными доработками или с помощью конвертера Sigma. 
  • Для приложений — Lua. Этот язык немного выбивается по сравнению с предыдущей тройкой, так как разрабатывался не специально под задачи ИБ. Однако именно с помощью Lua в Snort можно описать трафик приложений для реализации функциональности NGFW. И Lua же помогает писать более сложные правила в Suricata, чем позволяет язык Snort, разработанный более 20 лет назад, когда сетевые инфраструктуры не были такими сложными, как сейчас. Также на Lua пишутся скрипты для NMAP, превращая его в сканер уязвимостей. И т.д.  

Сегодня многие производители средств ИБ (правда, не всегда отечественные) поддерживают эти языки в своих решениях. Их знание также обычно указывается в вакансиях на роли аналитиков вредоносной активности в различные компании. Иногда, получается достаточно забавно, — одна и та же компания выпускает SIEM, не поддерживающий Sigma, но она же ищет аналитиков, умеющих на нем писать правила. Отсюда и второй вывод:

Надо выбирать те средства защиты/мониторинга/расследования, которые поддерживают эти языки.

Хотя с российскими решениям это сейчас непросто, но хотя бы спросить у вендора можно — набрав критическую массу, возможно, это сподвигнет его на доработки своего продукта (а если в требования регуляторов включить поддержку этих языков, то вообще было бы неплохо). Да, сегодня достаточно сложно будет найти на российском рынке (если не брать open source) тех, кто поддерживает эти языки. Но проблема в том, что обжегшись один раз (а реально больше, если посмотреть на примеры в начале), мы должны извлечь из этого уроки и начать  строить устойчивые к повторам таких событий системы, а не рассчитывать, что снаряд второй/третий/… раз в воронку не падает (на самом деле падает — все зависит от плотности огня). А иначе, какая вам разница, в зависимости от какого, российского или зарубежного вендора, вы будете в зависимости.

Есть надежда, что уж к языкам описания угроз России не заблокируют доступ.

Дополнительные источники информации (может потребоваться VPN для доступа к ним):
  • Сайт Snort
  • Сайт Suricata
  • Репозиторий Sigma на GitHub
  • Репозиторий pySigma на Github
  • Онлайн-конвертер правил Sigma
  • Раздел по Sigma на сайте SOC Prime
  • Репозиторий Yara на GitHub
  • Полезные ресурсы по Yara
  • Сайт Lua

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

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

  1. Павел

    Самим все делать это прекрасно. «Если хочешь сделать хорошо, — сделай сам», и вот это вот всё. Но это противоречит логике разделения труда. Давайте отключимся от центральной электросети, поставим свой генератор, пробурим свою скважину для воды, и т.д. В отдельных случаях — да. Но в целом, должна быть какая-то инфраструктура, доступная всем. Вместо того, чтобы топить за «сделай сам», лучше предложите такой себе «МосБез» (или «Гос») для всяких сервисов по ИБ. Было б круто.

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

      А МосГосБезДляВсех у нас есть — это НКЦКИ или ФинЦЕРТ. Только они ни за что ответственности не несут. Ответственность только на вас — вам и решить. Можно и дальше продолжать полагаться на других, а можно попробовать компенсировать этот риск, тем более, что он уже не раз осуществился

      Ответить
      1. Павел

        Ну если вы условная Роснефть, ну или Циско 🙂 , тогда может быть. А если детский садик, какие вам спецы, пишущие правила корреляции? А таких компаний количественно подавляющее большинство.

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

          Если я условный детский садик, то там вообще вопрос с тем, могут ли они хоть антивирус закупить?

          Ответить
  2. Сергей

    Садики кстати антивирусы покупать обязует городская администрация, т.к. они делают обработку ПДн и их городская администрация проверяет периодично на наличие оного.

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

      Да, есть такая проблема. С одной стороны вроде и обрабатывают, а с другой — нет возможности выполнить все требования

      Ответить
    2. пофиг

      Садики проверяет? да ладно? эт чо за богатый регион который не только за собой но и за другими следит? москва чтоль? и Аттестации делают и иб выполняют? Администрации сами как в проруби не то что по другим

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

        Ну проверять тех, кто «слабее» — это обычная практика

        Ответить