Подходы к обмену данными об угрозах находятся в активной фазе формирования и стандартизации. Сегодня есть пара значимых стандартов MISP и STIX и целая плеяда менее значимых, которые реже используются или считаются legacy/deprecated: MAEC, IODEF, OpenIOC (Cybox), CAPEC, IODEF, VERIS и множество иных. При этом порядочное количество community-фидов до сих пор распространяется в виде txt или csv, а также в виде человекочитаемых аналитических сводок, бюллетеней и отчетов.
В статье я разберу более-менее общепринятые практики обмена данными о киберугрозах: специализированные стандарты и форматы общего назначения, предназначенные не только для обмена TI. Какие-то сугубо проприетарные, редкие и собственные велосипеды форматов рассматривать не буду. Также пока за бортом оставлю тематические блоги, новостные порталы, сообщества в мессенджерах и иные источники TI в человекочитаемых форматах. Сегодня фокус на машиночитаемых форматах.
Формат STIX
Начну со стандарта STIX, лично у меня к нему душа больше лежит. Стандарт довольно зрелый, так как прошел путь в девять лет от версии 1 до 2.1. Он имеет хорошие описательные характеристики: с его помощью можно очень детально описать угрозу, все ее взаимосвязи, технические артефакты, при этом результат будет пригоден как для анализа человеком, так и машиной. В стандарт заложены хорошие руководящие принципы, которые соблюдаются на протяжении всего развития STIX:
-
Выразительность
-
Гибкость
-
Расширяемость
-
Автоматизируемость
-
Читаемость
Над STIX идет активная работа, регулярно выпускаются новые редакции. Стандарт поддерживает организация OASIS, её комитет по cyber threat intelligence объединяет более 50 компаний, собаку съевших на работе с TI. Поэтому развитие стандарта это путь обобщения лучших практик, ошибок и выводов, которые были сделаны опытными специалистами в этой области.
STIX является языком описания для обмена данными TI и вводит набор сущностей, а также определяет возможные типы взаимосвязей между ними. Стандарт довольно объемный, поэтому в этой статье я не буду погружаться во все его детали.
Согласно спецификации, STIX заявлен как serialize-agnostic, однако на практике чаще всего используется формат JSON, схемы находятся в публичном репозитории на GitHub. Транспорт для STIX тоже может быть любым, но OASIS позаботился и об этом: параллельно со STIX развивается стандарт для транспорта TAXII, который использует HTTPS как фундамент.
STIX описывает данные об угрозах как связный граф, где узлами являются SDO (STIX Domain Objects), а ребрами SRO (STIX Relationship objects).
В качестве SDO STIX определяет следующие сущности:
-
Схема атаки (Attack pattern) описывает подход (TTP), который использовал злоумышленник для взлома своей цели. Эта сущность используется для классификации атак, обобщения конкретных атак в соответствии со схемами, которым они следуют, и предоставления подробной информации о том, как атаки выполняются.
-
Вредоносная кампания (Campaign) описывает последовательность вредоносных поведенческих признаков, которые возникают на протяжении определенных промежутков времени.
-
План действий (Course of action) описывает меры, которые нужно принять, чтобы избежать или противостоять атаке.
-
Личность (Identity) описывает персоны, организации либо их группы.
-
Индикатор (Indicator) описывает технические вредоносные артефакты, которые могут быть использованы для обнаружения вредоносной активности (например, IP-адреса, домены, хеши, ключи реестра).
-
Intrusion set описывает набор поведенческих признаков и ресурсов с общими свойствами, которые, вероятней всего, подконтрольны одной организации. Ключевое отличие от Campaign в том, что последняя обычно представляет собой вредоносную активность, направленную на конкретную цель и длится в течение ограниченного промежутка времени, тогда как Intrusion set длится продолжительное время, может участвовать в нескольких Campaigns и иметь несколько целей.
-
Вредоносное ПО (Malware) описывает экземпляры вредоносного ПО.
-
Объект наблюдения (Observed data) описывает не вредоносные технические артефакты.
-
Отчет (Report) описывает в понятном виде какую-либо угрозу, вредоносную группировку, их TTP, жертв. Своего рода аналитическая сводка, позволяющая понять суть угрозы, ее опасность, вредоносное ПО, используемые техники, тактики и процедуры, применяемые атакующей стороной.
-
Злоумышленник (Threat actor) описывает персон, группы или организации, которые действуют со злым умыслом. Если коротко, злоумышленники и хакеры. Именно злой умысел в мотивации этой сущности отличает ее от Identity.
-
Инструмент (Tool) описывает легитимное ПО, которое может быть использовано для осуществления атак. Отличие этой сущности от Malware именно в том, что это легитимный софт, например, nmap или RDP, VNC.
-
Уязвимость (Vulnerability) описывает недостатки/дырки в требованиях, логике, дизайне, реализации ПО или железа, которые могут быть проэксплуатированы и негативно повлиять на конфиденциальность, целостность или доступность системы.
Приведенные выше наборы сущностей и взаимосвязей позволяют описывать в понятном виде данные, которые могут использоваться машиной. Давайте посмотрим на паре примеров.
Пример 1
Здесь описывается индикатор компрометации http://x4z9arb.cn/4712/ типа URL и его связь (атрибуция) с вредоносным ПО x4z9arb backdoor. При этом явно видно, что индикатор это сайт, на котором располагается вредоносный загрузчик (downloader), в данном случае вредонос x4z9arb backdoor.
Что это значит для аналитика? Все довольно просто: если мы обнаружим следы присутствия (индикатор компрометации http://x4z9arb.cn/4712/) в инфраструктуре компании, то можем сделать вывод, что имеем дело с вредоносным ПО x4z9arb backdoor. Дальнейшие шаги обычно зависят от вредоносности ПО, попавшего внутрь инфраструктуры. Для его анализа существует множество баз, например, Malpedia.
Пример STIX 2.1
{"type": "bundle","id": "bundle--56be2a3b-1534-4bef-8fe9-602926274089","objects": [{"type": "indicator","spec_version": "2.1","id": "indicator--d81f86b9-975b-4c0b-875e-810c5ad45a4f","created": "2014-06-29T13:49:37.079Z","modified": "2014-06-29T13:49:37.079Z","name": "Malicious site hosting downloader","description": "This organized threat actor group operates to create profit from all types of crime.","indicator_types": ["malicious-activity"],"pattern": "[url:value = 'http://x4z9arb.cn/4712/']","pattern_type": "stix","valid_from": "2014-06-29T13:49:37.079Z"},{"type": "malware","spec_version": "2.1","id": "malware--162d917e-766f-4611-b5d6-652791454fca","created": "2014-06-30T09:15:17.182Z","modified": "2014-06-30T09:15:17.182Z","name": "x4z9arb backdoor","description": "This malware attempts to download remote files after establishing a foothold as a backdoor.","malware_types": ["backdoor","remote-access-trojan"],"is_family": false,"kill_chain_phases": [{"kill_chain_name": "mandiant-attack-lifecycle-model","phase_name": "establish-foothold"}]},{"type": "relationship","spec_version": "2.1","id": "relationship--864af2ea-46f9-4d23-b3a2-1c2adf81c265","created": "2020-02-29T18:03:58.029Z","modified": "2020-02-29T18:03:58.029Z","relationship_type": "indicates","source_ref": "indicator--d81f86b9-975b-4c0b-875e-810c5ad45a4f","target_ref": "malware--162d917e-766f-4611-b5d6-652791454fca"}]}
Пример 2
Тут явно описаны связи между злоумышленником Adversary Bravo, используемой им техникой атаки фишингом и вредоносным ПО Poison Ivy Variant d1c6.
В этом случае при обнаружении в инфраструктуре вредоносного ПО PoisonIvy вариант d1с6 такая структура фида с взаимосвязями поможет понять, что подобным вредоносным ПО пользуется злоумышленник.
Пример STIX 2.1
{"type": "bundle","id": "bundle--0ecd8123-90d5-46e0-9cd4-65d4999b3a2e","objects": [{"type": "threat-actor","spec_version": "2.1","id": "threat-actor--9a8a0d25-7636-429b-a99e-b2a73cd0f11f","created": "2015-05-07T14:22:14.760Z","modified": "2015-05-07T14:22:14.760Z","name": "Adversary Bravo","description": "Adversary Bravo is known to use phishing attacks to deliver remote access malware to the targets.","threat_actor_types": ["spy","criminal"]},{"type": "malware","spec_version": "2.1","id": "malware--d1c612bc-146f-4b65-b7b0-9a54a14150a4","created": "2015-04-23T11:12:34.760Z","modified": "2015-04-23T11:12:34.760Z","name": "Poison Ivy Variant d1c6","malware_types": ["remote-access-trojan"],"is_family": false,"kill_chain_phases": [{"kill_chain_name": "mandiant-attack-lifecycle-model","phase_name": "initial-compromise"}]},{"type": "attack-pattern","spec_version": "2.1","id": "attack-pattern--8ac90ff3-ecf8-4835-95b8-6aea6a623df5","created": "2015-05-07T14:22:14.760Z","modified": "2015-05-07T14:22:14.760Z","name": "Phishing","description": "Spear phishing used as a delivery mechanism for malware.","kill_chain_phases": [{"kill_chain_name": "mandiant-attack-lifecycle-model","phase_name": "initial-compromise"}],"external_references": [{"source_name": "capec","description": "phishing","url": "https://capec.mitre.org/data/definitions/98.html","external_id": "CAPEC-98"}]},{"type": "identity","spec_version": "2.1","id": "identity--1621d4d4-b67d-41e3-9670-f01faf20d111","created": "2015-05-10T16:27:17.760Z","modified": "2015-05-10T16:27:17.760Z","name": "Adversary Bravo","description": "Adversary Bravo is a threat actor that utilizes phishing attacks.","identity_class": "unknown"},{"type": "relationship","spec_version": "2.1","id": "relationship--d44019b6-b8f7-4cb3-837e-7fd3c5724b87","created": "2020-02-29T18:18:08.661Z","modified": "2020-02-29T18:18:08.661Z","relationship_type": "uses","source_ref": "threat-actor--9a8a0d25-7636-429b-a99e-b2a73cd0f11f","target_ref": "malware--d1c612bc-146f-4b65-b7b0-9a54a14150a4"},{"type": "relationship","spec_version": "2.1","id": "relationship--3cd2d6f9-0ded-486b-8dca-606283a8997f","created": "2020-02-29T18:18:08.661Z","modified": "2020-02-29T18:18:08.661Z","relationship_type": "uses","source_ref": "threat-actor--9a8a0d25-7636-429b-a99e-b2a73cd0f11f","target_ref": "attack-pattern--8ac90ff3-ecf8-4835-95b8-6aea6a623df5"},{"type": "relationship","spec_version": "2.1","id": "relationship--56e5f1c8-08f3-4e24-9e8e-f87d844672ec","created": "2020-02-29T18:18:08.661Z","modified": "2020-02-29T18:18:08.661Z","relationship_type": "attributed-to","source_ref": "threat-actor--9a8a0d25-7636-429b-a99e-b2a73cd0f11f","target_ref": "identity--1621d4d4-b67d-41e3-9670-f01faf20d111"}]}
Приведенные примеры довольно тривиальны, но просты для понимания. Разбор сложных примеров может стать темой отдельной статьи. Однако для наглядности покажу, как можно упаковать в STIX результаты объемного исследования отчета о деятельности вредоносной группировки APT1 (ссылка на json):
Если подытожить, STIX достаточно мощный и гибкий формат для описания самых различных угроз и обмена ими между различными потребителями. Плюсов у него много: выразительность, то есть хорошая описательная способность, гибкость, автоматизируемость. Из ощутимых минусов можно отметить разве что следствие перечисленных плюсов сравнительно высокий порог входа, из-за этого STIX пока не получил статуса стандарта отрасли.
Формат MISP
MISP популярная open-source платформа Threat Intelligence, она обросла довольно большим и активным сообществом за годы существования. Формат обмена данными с 2016 внесен в IETF в статусе internet draft, то есть метит в RFC, но пока им не стал.
Концепция платформы MISP сосредоточена в первую очередь на создании и p2p-обмене данными threat intelligence, то есть основная цель это создание и распространение знаний между различными участниками сообществ. Глубину и ширину такого распространения можно довольно гибко регулировать настройками.
Формат обмена данными MISP пошел несколько иным путем, нежели STIX. В отличие от последнего, MISP свою модель данных не делит на большое количество детерминированных объектов разных типов, тут их сравнительно немного:
-
Событие (Event) какое-либо событие, инцидент, аналитический отчет, который повествует о чем-либо. По сути, Event это контейнер.
-
Атрибуты события (Event attributes) чаще всего это индикаторы компрометации, разные технические артефакты. То есть Events, как в контейнерах, собирают внутри себя разные индикаторы компрометации, которые рассказывают о какой-либо одной угрозе или вредоносной кампании (либо нескольких, но семантически близких).
-
Объект (Object) нужен для обобщения атрибутов по какому-либо признаку общности. Например, чтобы связать несколько хешей (md5, sha1. sha256) с именем файла, с которого они были сняты. Объекты можно связывать друг с другом с помощью прокси-объекта Object References.
-
Тег (Tag) метки для классификации, могут быть как представлены в виде пользовательских строк, так и взяты из справочника MISP Taxonomies.
-
Обнаружения (Sighting) факты о том, где, когда, при каких условиях и кем встречался конкретный атрибут.
-
Галактика (Galaxy) связь объектов или атрибутов с контекстом, который дает более детальное описание объектов/атрибутов. По сути, это расширение функциональности тегов. Galaxies декомпозируются на Clusters (Кластеры) и Elements (Элементы). На примере это может выглядеть так: атрибут привязывается к Threat Actor (Galaxy), MuddyWater (Element) из этой связи наглядно понятна атрибуция.
Пример
Из этого примера видно, что фид рассказывает нам о двух индикаторах компрометации adfs.senate.group и adfs-senate.email, которые связаны с вредоносной кампанией Pawn Storm, есть ссылка на первоисточник исследования пост в блоге Trend Micro.
MISP Event
"Event": {"info": "Update on Pawn Storm: New Targets and Politically Motivated Campaigns","publish_timestamp": "1515851051","timestamp": "1515850537","analysis": "2","Attribute": [{"comment": "","category": "Network activity","uuid": "5a5a0b04-198c-4190-9f1a-8d1cc0a8ab16","timestamp": "1515850500","to_ids": true,"value": "adfs.senate.group","object_relation": null,"type": "hostname"},{"comment": "","category": "Network activity","uuid": "5a5a0b04-4d44-463f-81a9-8d1cc0a8ab16","timestamp": "1515850500","to_ids": true,"value": "adfs-senate.email","object_relation": null,"type": "domain"},{"comment": "","category": "External analysis","uuid": "5a5a0b22-86a4-4d66-90e4-9282c0a8ab16","timestamp": "1515850530","to_ids": false,"value": "http://blog.trendmicro.com/trendlabs-security-intelligence/update-pawn-storm-new-targets-politically-motivated-campaigns/","object_relation": null,"type": "link"}],"Tag": [{"colour": "#00d622","exportable": true,"name": "tlp:white"}],"published": true,"date": "2018-01-12","Orgc": {"uuid": "56c42374-fdb8-4544-a218-41ffc0a8ab16","name": "CUDESO"},"threat_level_id": "3","uuid": "5a5a0acb-a374-415e-b88f-8d1ec0a8ab16"}}
MISP довольно обширный формат, позволяющий описать угрозы достаточно детально. В нем есть для этого все инструменты: обилие атрибутов, таксономии для категоризации, галактики для кластеризации угроз. Однако, как во многих community-driven вещах, на мой взгляд, в нем нет той стройности, детерминированности, типизированных взаимосвязей и правил их использования, которые есть в STIX. Это не значит, что STIX выглядит однозначно более выигрышным таково мое личное мнение. Время и здоровая конкуренция покажут, чей подход будет более эффективным.
Иные форматы
Помимо STIX и MISP, больших китов в мире стандартизации обмена данными threat intelligence, есть немало иных форматов. И надо сказать, что наибольшее количество опенсорных фидов в форматах txt и csv. Редко, когда можно найти их в STIX или MISP, которые я бы назвал, скорее, уделом коммерческих, отмодерированных, обогащенных, хорошо структурированных фидов. Иные форматы (MAEC, IODEF, CAPEC, IODEF, VERIS) редкость.
Почему же стали настолько популярны txt и csv? Ответ один из-за простоты. Большинство опенсорсных фидов это либо фиды с минимальным контекстом (временные метки, именования вредоносного ПО, теги), либо просто голые индикаторы компрометации без какого-либо контекста (только значения индикаторов). Наиболее простой способ упаковки таких индикаторов plain text или csv, так как любые иные форматы имеют более высокий порог входа.
Минус фидов в plain-text отсутствие контекста, то есть обычно такие фиды это листы IP-адресов, хешей, доменов, URL, реже чего-то иного. Проблема в том, что таким фидам без контекста, голым по-сути, сложно доверять и интерпретировать, так как не понятно, что за угрозы представляют содержащиеся в них индикаторы компрометации, и насколько эти угрозы актуальны и вредоносны.
Фиды в csv часто содержат несколько колонок, описывающих значения, тип индикатора, временные метки. Иногда встречаются описания вредоносного ПО или эксплуатируемых уязвимостей, которые связаны с этим индикатором. В общем случае фиды в csv, где есть хоть какой-то контекст, могут быть полезнее. Однако это зависит от различных ситуаций, ведь может случиться так, что plain-text фид с индикаторами по очень актуальной угрозе для конкретной отрасли или компании может оказаться полезнее любого другого фида с контекстом.
Основные проблемы при работе с фидами в таких свободных форматах, как txt и csv, это сбор и приведение к единой нормальной форме, а также связывание данных. Txt может содержать комментарии, в одном файле могут находиться разные фиды и использоваться различные способы разделения индикаторов компрометации такие фиды достаточно сложно парсить. В csv-фидах порядочную сложность также порой представляет извлечение данных: разделители в одном файле могут не быть консистентными. Это актуально для фидов, где правки делаются вручную, да и вообще наша практика показала, что нежданчик может случиться в любой момент. Отдельная тема это неявность связи атрибутов в csv. Иногда довольно сложно понять, какие атрибуты к чему относятся.
Примеры
В этом примере явно видно, что есть одна колонка с индикатором компрометации, одна колонка с семейством вредоносного ПО, которая связана с хешем, есть колонка со страной (хотя не вполне понятно, страна это источник атаки или цель), есть колонка со ссылкой на исследование/отчет по угрозе. Такой csv-фид более-менее понятен.
Вот другой пример фида с однозначным и хорошим описанием понятно, какие есть атрибуты и какие между ними имеются взаимосвязи:
А вот в этом примере не понятно, к чему относится дата: к третьей колонке (URL) или к пятой (хеш)?
Еще один пример: есть две колонки с индикатором компрометации (url, ip), есть колонка с датой и непонятно, к какому из индикаторов компрометации эта дата относится, а также, что она означает. Время первого обнаружения индикатора? Время последнего обнаружения индикатора? Что-то иное?
Как видно из примеров, форматы общего назначения вполне подходят для публикации фидов TI, но проблема обычно кроется в последующей интерпретации этих форматов. Это может вносить существенную путаницу при использовании данных в процессе применения TI, например, при реагировании на инциденты. В этом отношении специализированные STIX/MISP решают проблему интерпретации гораздо лучше из-за детерминированности схем данных.
За бортом обсуждения также остаются немногочисленные практики публикации фидов в устаревших форматах, например, STIX 1.*, OpenIOC и иных они действительно либо безнадежно устарели и более не используются, либо слились с другими стандартами, либо эволюционировали в более новые версии, отвечающие нынешним запросам.
Выводы
В мире threat intelligence не все так однозначно, как видится на первый взгляд. С одной стороны, сформировалось достаточно активное сообщество, которое развивает открытые стандарты, решающие вполне понятные проблемы и задачи большинства пользователей (потребителей и производителей) TI. В то же время различные производители средств защиты информации зачастую разрабатывают и используют собственные форматы, наиболее выгодные в их конкретных сценариях использования. Помимо этого, есть практика использования форматов общего назначения вроде txt, csv, rss, pdf.
Все это явно свидетельствует, что в этой области еще не сформирован единый стандарт индустрии. Тем, кому этих доводов мало, также можно почитать несколько исследований из первоисточников:
Само по себе отсутствие стандарта отрасли это не хорошо и не плохо, просто факт. Порой он приносит определенные неудобства производителям продуктов, поставщикам и потребителям TI. Я вижу это лишь следствием того, что threat intelligence все еще сравнительно молодая область, которая представляет собой большой плавильный котел. Здесь множество требований с различных сторон еще на нашли 100% устраивающих всех реализаций, поэтому преобладает некий хаос, постепенно кристаллизующийся в лучшие практики. Полагаю, стандартизация это вопрос времени.
С точки зрения платформы TI, такая гетерогенность форматов настоящий челлендж, так как нужно собрать из многообразия источников все данные, переложить их в собственную модель, не потерять смысл и по возможности потерять минимум данных тех, что семантически не получается разместить в полях модели данных платформы. Как раз в следующей статье вместе с Колей Арефьевым из RST Cloud мы рассмотрим более подробно конкретные фиды, расскажем, какие сложности поджидают на пути их сбора, обработки и интерпретации. Stay tuned!
