Подходы к обмену данными об угрозах находятся в активной фазе формирования и стандартизации. Сегодня есть пара значимых стандартов — MISP и STIX — и целая плеяда менее значимых, которые реже используются или считаются legacy/deprecated: MAEC, IODEF, OpenIOC (Cybox), CAPEC, 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!