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

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

Первая история началась в 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 лет, история вновь расставила все по своим местам:

Три эти истории ставят перед нами простой вопрос — а как защититься от повтора в будущем? Как сделать так, чтобы, не взирая ни на какие санкции и внезапные уходы компаний с рынка (в том числе и из конкретной страны — вспомним 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) тех, кто поддерживает эти языки. Но проблема в том, что обжегшись один раз (а реально больше, если посмотреть на примеры в начале), мы должны извлечь из этого уроки и начать  строить устойчивые к повторам таких событий системы, а не рассчитывать, что снаряд второй/третий/… раз в воронку не падает (на самом деле падает — все зависит от плотности огня). А иначе, какая вам разница, в зависимости от какого, российского или зарубежного вендора, вы будете в зависимости.

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