Блог компании r-vision

Подходы к обмену данными об угрозах находятся в активной фазе формирования и стандартизации. Сегодня есть пара значимых стандартов 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 определяет следующие сущности:

1. Схема атаки (Attack pattern) описывает подход (TTP), который использовал злоумышленник для взлома своей цели. Эта сущность используется для классификации атак, обобщения конкретных атак в соответствии со схемами, которым они следуют, и предоставления подробной информации о том, как атаки выполняются.

2. Вредоносная кампания (Campaign) описывает последовательность вредоносных поведенческих признаков, которые возникают на протяжении определенных промежутков времени.

3. План действий (Course of action) описывает меры, которые нужно принять, чтобы избежать или противостоять атаке.

4. Личность (Identity) описывает персоны, организации либо их группы.

5. Индикатор (Indicator) описывает технические вредоносные артефакты, которые могут быть использованы для обнаружения вредоносной активности (например, IP-адреса, домены, хеши, ключи реестра).

6. Intrusion set описывает набор поведенческих признаков и ресурсов с общими свойствами, которые, вероятней всего, подконтрольны одной организации. Ключевое отличие от Campaign в том, что последняя обычно представляет собой вредоносную активность, направленную на конкретную цель и длится в течение ограниченного промежутка времени, тогда как Intrusion set длится продолжительное время, может участвовать в нескольких Campaigns и иметь несколько целей.

7. Вредоносное ПО (Malware) описывает экземпляры вредоносного ПО.

8. Объект наблюдения (Observed data) описывает не вредоносные технические артефакты.

9. Отчет (Report) описывает в понятном виде какую-либо угрозу, вредоносную группировку, их TTP, жертв. Своего рода аналитическая сводка, позволяющая понять суть угрозы, ее опасность, вредоносное ПО, используемые техники, тактики и процедуры, применяемые атакующей стороной.

10. Злоумышленник (Threat actor) описывает персон, группы или организации, которые действуют со злым умыслом. Если коротко, злоумышленники и хакеры. Именно злой умысел в мотивации этой сущности отличает ее от Identity.

11. Инструмент (Tool) описывает легитимное ПО, которое может быть использовано для осуществления атак. Отличие этой сущности от Malware именно в том, что это легитимный софт, например, nmap или RDP, VNC.

12. Уязвимость (Vulnerability) описывает недостатки/дырки в требованиях, логике, дизайне, реализации ПО или железа, которые могут быть проэксплуатированы и негативно повлиять на конфиденциальность, целостность или доступность системы.

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

Пример 1

Здесь описывается индикатор компрометации http://x4z9arb.cn/4712/ типа URL и его связь (атрибуция) с вредоносным ПО x4z9arb backdoor. При этом явно видно, что индикатор это сайт, на котором располагается вредоносный загрузчик (downloader), в данном случае вредонос x4z9arb backdoor.

Что это значит для аналитика? Все довольно просто: если мы обнаружим следы присутствия (индикатор компрометации http://x4z9arb.cn/4712/) в инфраструктуре компании, то можем сделать вывод, что имеем дело с вредоносным ПО x4z9arb backdoor. Дальнейшие шаги обычно зависят от вредоносности ПО, попавшего внутрь инфраструктуры. Для его анализа существует множество баз, например, Malpedia.

{"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 такая структура фида с взаимосвязями поможет понять, что подобным вредоносным ПО пользуется злоумышленник.

{"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 свою модель данных не делит на большое количество детерминированных объектов разных типов, тут их сравнительно немного:

1. Событие (Event) какое-либо событие, инцидент, аналитический отчет, который повествует о чем-либо. По сути, Event это контейнер.

2. Атрибуты события (Event attributes) чаще всего это индикаторы компрометации, разные технические артефакты. То есть Events, как в контейнерах, собирают внутри себя разные индикаторы компрометации, которые рассказывают о какой-либо одной угрозе или вредоносной кампании (либо нескольких, но семантически близких).

3. Объект (Object) нужен для обобщения атрибутов по какому-либо признаку общности. Например, чтобы связать несколько хешей (md5, sha1. sha256) с именем файла, с которого они были сняты. Объекты можно связывать друг с другом с помощью прокси-объекта Object References.

4. Тег (Tag) метки для классификации, могут быть как представлены в виде пользовательских строк, так и взяты из справочника MISP Taxonomies.

5. Обнаружения (Sighting) факты о том, где, когда, при каких условиях и кем встречался конкретный атрибут.

6. Галактика (Galaxy) связь объектов или атрибутов с контекстом, который дает более детальное описание объектов/атрибутов. По сути, это расширение функциональности тегов. Galaxies декомпозируются на Clusters (Кластеры) и Elements (Элементы). На примере это может выглядеть так: атрибут привязывается к Threat Actor (Galaxy), MuddyWater (Element) из этой связи наглядно понятна атрибуция.

Пример

Из этого примера видно, что фид рассказывает нам о двух индикаторах компрометации adfs.senate.group и adfs-senate.email, которые связаны с вредоносной кампанией Pawn Storm, есть ссылка на первоисточник исследования пост в блоге Trend Micro.

"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.

Все это явно свидетельствует, что в этой области еще не сформирован единый стандарт индустрии. Тем, кому этих доводов мало, также можно почитать несколько исследований из первоисточников:

• https://arxiv.org/abs/2103.03530

• https://res.mdpi.com/d_attachment/electronics/electronics-09-00824/article_deploy/electronics-09-00824-v3.pdf

Само по себе отсутствие стандарта отрасли это не хорошо и не плохо, просто факт. Порой он приносит определенные неудобства производителям продуктов, поставщикам и потребителям TI. Я вижу это лишь следствием того, что threat intelligence все еще сравнительно молодая область, которая представляет собой большой плавильный котел. Здесь множество требований с различных сторон еще на нашли 100% устраивающих всех реализаций, поэтому преобладает некий хаос, постепенно кристаллизующийся в лучшие практики. Полагаю, стандартизация это вопрос времени.

С точки зрения платформы TI, такая гетерогенность форматов настоящий челлендж, так как нужно собрать из многообразия источников все данные, переложить их в собственную модель, не потерять смысл и по возможности потерять минимум данных тех, что семантически не получается разместить в полях модели данных платформы. Как раз в следующей статье вместе с Колей Арефьевым из RST Cloud мы рассмотрим более подробно конкретные фиды, расскажем, какие сложности поджидают на пути их сбора, обработки и интерпретации. Stay tuned!

Другие статьи по теме

• Погружение в Threat Intelligence: кому и зачем нужны данные киберразведки

Согласно отчету 2021 SANS Cyber Threat Intelligence (CTI) Survey, 66,3% компаний используют открытые источники для сбора индикаторов компрометации и стараются работать одновременно с несколькими источниками. Казалось бы, сбор индикаторов из открытых источников достаточно простая задача: надо просто скачать с какого-то сайта файлик txt или csv, и всё. В действительности на этом пути можно столкнуться с большим количеством проблем. В статье мы расскажем, что это могут быть за сложности, от чего зависят структура и формат фида, какие метрики помогают оценить полезность фидов, а также покажем на реальном примере, что можно узнать из фида. Для большей объективности эту статью мы подготовили вместе с Колей Арефьевым из компании RST Cloud, занимающейся агрегацией, обогащением, очисткой и ранжированием индикаторов, публикуемых независимыми ИБ-исследователями.

Какие подводные камни таят в себе открытые источники TI

Сразу оговоримся: обойти проблемы при работе с индикаторами из открытых источников не выйдет. При первой же загрузке таких индикаторов в средства защиты вы получите тысячи срабатываний за сутки. Не разобрав и первые 100 сработок, вероятнее всего, плюнете на это дело и просто отключите фид.

Попробуем описать основные проблемы, которые необходимо будет разрешить при сборе индикаторов из открытых источников:

1. Подбор источников.

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

2. Понимание структуры фида.

Важно понимать, что за индикаторы компрометации приносит источник. Но зачастую еще важнее собирать не только сами индикаторы, но и связанный с ними контекст, если он есть: временные метки, атрибуцию (кто, кого, когда, зачем, почему и какими инструментами атакует?). Например, контекстом может быть информация о том, почему определенный IP, домен, url или hash попал в фид. Если это С2C, то от какого вредоносного ПО, если фишинговый url, то под какую компанию он сделан.

3. Агрегация и дедупликация.

А что, если несколько источников данных предоставляют одну и ту же информацию об индикаторе компрометации? Дубль? А что, если противоречивую? Кому верить?

4. Понимание изменений в источнике и актуальность данных.

Перед подключением источника необходимо понять, что означает пропадание индикатора из источника, как происходит обновление индикатора. Представьте, что сегодня индикатор был в фиде, а завтра пропал. О чем это говорит? Означает ли это, что индикатор перестал быть вредоносным, или же просто источник приносит только новые индикаторы и не включает в выгрузку старые?

5. Понимание расписания обновления источников.

При сборе индикаторов из открытых источников важно знать не только, как происходят изменения в фиде, но и когда и с какой частотой они публикуются. Если источник публикует только новые индикаторы каждые 4 часа, то стоит разобраться, в какие именно часы это происходит. В противном случае вы рискуете пропустить сеанс связи и попросту не получить часть индикаторов, ведь повторно публиковать их уже никто не будет.

6. Очистка индикаторов.

Встретить в открытых индикаторах 127.0.0.1, microsoft.com или SHA256 обычного calc.exe вполне нормальная ситуация. Чтобы избежать ложных срабатываний, необходимо очищать индикаторы с помощью разнообразных списков исключений.

7. Обогащение индикаторов.

Многие открытые источники индикаторов не снабжают их какой-либо дополнительной информацией. К таким сведениям, например, относятся ASN, Whois, Geo-привязка, данные об открытых портах, запущенных сервисах и т.д. Подумайте, что вам может быть полезно при расследовании инцидентов, в которых могут участвовать индикаторы, и откуда вы сможете получить эту информацию.

8. Хранение индикаторов в средствах защиты.

Было бы просто чудесно, если бы можно было загрузить все собранные за год индикаторы в средства защиты и использовать их для проверки на потоке. К сожалению, чудеса в IT и ИБ случаются очень редко, и хранить в средствах защиты придется лишь столько индикаторов, сколько они способны обеспечить без существенной деградации производительности. Для наглядности приведем статистику RST Cloud по уникальным сетевым IoC, собранным за 365 дней.

От чего зависят структура и формат фида: ищем ответ в Пирамиде боли

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

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

Давайте вспомним Пирамиду боли, предложенную впервые в 2013 году David J Bianco.

В нижней части пирамиды лежат атомарные сетевые и хостовые индикаторы. Как правило, для их описания в фиде можно использовать плоские структуры данных, сформировав txt- или csv-фид. Для таких структур характерно отсутствие каких-либо вложенностей.

Например, фид такой структуры может выглядеть вот так:

812 | ROGERS-COMMUNICATIONS | 99.250.237.110 | 2021-04-05 04:46:22

852 | ASN852 | 66.183.170.4 | 2021-04-05 02:50:15

1101 | IP-EEND-AS Surfnet B.V. | 192.42.116.13 | 2021-03-31 19:52:48

1101 | IP-EEND-AS Surfnet B.V. | 192.42.116.14 | 2021-04-03 14:50:55

1101 | IP-EEND-AS Surfnet B.V. | 192.42.116.16 | 2021-04-05 09:45:03

1101 | IP-EEND-AS Surfnet B.V. | 192.42.116.17 | 2021-04-04 18:13:59

Или даже вот так:

Family,URL,IP,FirstSeen

Pony,http[:]//officeman[.]tk/admin.php,207[.]180.230.128,01-06-2020

Pony,http[:]//learn[.]cloudience[.]com/admin.php,192[.]145.234.108,01-06-2020

Pony,http://vman23[.]com/admin.php,95.213.204.53,01-06-2020

По мере продвижения вверх по пирамиде необходимо описывать всё более и более сложные модели данных. Такое усложнение обусловлено тем, что на более высоких уровнях недостаточно просто описать атомарный индикатор и его атрибуты. В фиде необходимо уже отражать как связки индикаторов, так и целые поведенческие паттерны вредоносных программ, техники и тактики (TTP) хакерских группировок или этапы APT.

Для описания подобных моделей становится недостаточно обычных плоских структур, и здесь уже задействуются такие форматы, как json, yaml, xml или что-то более экзотическое, построенное на их основе. Пример фида, описывающего несколько взаимосвязанных объектов в формате STIX 2, можно посмотреть в этой статье.

Помимо крайних точек в виде плоских структур с одной стороны и сложных структур с высокой степенью вложенности с другой, есть и промежуточные варианты. Как правило, такие фиды формируются в формате json и обладают небольшой глубиной вложенности от 1 до 3 уровней. Фиды с такой структурой появляются тогда, когда атомарные индикаторы снабжают дополнительным контекстом, позволяющим иметь более полную информацию при расследовании инцидента, где встречаются эти индикаторы. Пример подобного фида приведем ниже.

Пример: о чем можно узнать из фида

Разберем подробнее, что полезного можно найти в фидах с индикаторами, снабженными дополнительным контекстом, на примере структуры доменного индикатора от RST Cloud.

Сам фид состоит из json следующего вида:

{

"id": "572f891c-dd92-31d3-a2e7-c448a4b72b22",

"title": "RST Threat feed. IOC: defender5.coachwithak.com",

"description": "IOC with tags: c2. Related threats: silverfish_group",

"threat": ["silverfish_group"],

"domain": "defender5.coachwithak.com",

"fseen": 1616630400,

"lseen": 1617408000,

"collect": 1617494400,

"tags": ["c2"],

"resolved": {

"ip": {

"a": ["37.48.84.156"],

"cname": []

},

"whois": {

"created": "2019-07-31 20:36:52",

"updated": "2020-08-01 10:58:42",

"expires": "2021-07-31 20:36:52",

"age": 608,

"registrar": "GoDaddycom LLC",

"registrant": "unknown",

"havedata": "true"

}

},

"score": {

"total": 55,

"src": 73.75,

"tags": 0.89,

"frequency": 0.85

},

"fp": {

"alarm": "false",

"descr": ""

}

}

Выделим ключевую информацию об индикаторе, которую можно узнать из этого фида:

1. GUID индикатора.

2. Краткое описание индикатора помогает TI-аналитику быстро понять, чем опасен этот индикатор.

3. Время первого и последнего появления индикатора.

4. Информация об угрозе, которую несет индикатор. В данном случае домен атрибутирован с APT-группировкой SilverFish (подробнее можно ознакомиться в публичном отчете исследователей).

5. Теги дают дополнительный контекст. В данном случае вредоносный домен используется как командный управляющий сервер (C2C).

6. IP-адреса, в которые резолвится домен, полезны при анализе логов с сетевых устройств, где присутствуют только IP и нет информации о DNS-резолве.

7. Whois-информация помогает TI-аналитику лучше понять, кто и когда зарегистрировал домен. Зачастую для атак регистрируют домены-однодневки, поэтому важно обращать внимание на то, когда домен зарегистрирован. В нашем примере APT-группировка подошла к вопросу выбора домена для C2C-сервера более основательно и использовала домен с более чем двухгодичным временем жизни.

8. Вес индикатора позволяет количественно оценить опасность индикатора. К примеру, индикатор с весом 70 опаснее индикатора с весом 50, и реагировать на появление первого необходимо в первую очередь.

9. Как правило, вес индикатора рассчитывается по заданной создателем фида формуле. TI-аналитику в общих чертах важно понимать, из чего складывается итоговый вес. В приведенном примере вес индикатора складывается из следующих параметров: доверие к источникам индикатора, его контекст и частота появления.

10. При работе с индикаторами важно понимать, насколько тот или иной индикатор может быть ложноположительной сработкой (False-Positive), поэтому в его структуре присутствует соответствующий флаг. В данном случае флаг выставлен в false, а это значит, что нахождение такого индикатора в инфраструктуре с высокой долей вероятности говорит о ее компрометации.

На какие метрики смотреть?

Оценка данных threat intelligence нетривиальная задача, потому что в идеале нужно не только ориентироваться на объективные метрики, но и оценивать релевантность источников данных для специфики деятельности компании или индустрии, учитывать уникальную модель угроз организации, количество ложноположительных обнаружений угроз. Для этого нужен качественный контекст в источниках данных, а также накопленная статистика. Как показывают наши наблюдения, как с первым, так и со вторым, есть проблемки.

Так а что делать-то? Если ничего непонятно, то лучший вариант обычно начинать с малого и понятного, другими словами, есть слона по кускам. Существует немалое количество метрик, по которым можно сделать вывод о потенциальной пользе фида. На что же стоит смотреть в первую очередь и почему?

Давайте посмотрим, какие метрики можно собрать даже по голым опенсорсным фидам, где контекст либо отсутствует, либо он есть, но в минимальном количестве.

Например, можно оценить фид по динамике поступления новых данных, то есть тех индикаторов компрометации, которые фид не присылал ранее:

По таким графикам (или таблицам) хорошо видно, насколько часто фид присылает новые данные:

Как можно интерпретировать такую метрику? Факт постоянного получения новых данных позитивный, однако изолированная метрика достаточно неоднозначна, и следует рассматривать ее вкупе с иными метриками, чтобы увидеть картину более широко.

Давайте снова взглянем на опенсорсный фид от CIRCL.lu. Как видно из предыдущего графика, фид достаточно регулярно обновляется. Что же он собой представляет, если посмотреть более обобщенно?

За период в 3 месяца в фиде 157 852 индикатора. Видно, что фид предоставляет разные типы индикаторов компрометации.

Если посмотреть на фид CIRCL в сравнении с несколькими другими фидами, можно также оценить распределение типов индикаторов компрометации по фидам. Что может дать эта информация пользователю? Например, понимание того, как можно будет использовать такой фид. Ведь обилие хешей обычно требует интеграции с EDR-решениями, хеши довольно бессмысленно искать в потоке трафика или netflow с сетевых устройств:

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

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

Похожей метрикой может быть среднее время обновления время от последнего обновления индикаторов компрометации до настоящего момента, усредненное для всей выборки. Эта метрика отвечает на вопрос, насколько оперативно источник данных TI предоставляет данные об изменениях индикаторов компрометации. Вот как это может выглядеть:

Дополнить картину можно метрикой возраста индикаторов компрометации в фиде. Она представляет собой распределение количества индикаторов компрометации в фиде по времени. Иными словами, это позволяет понять, что за фид перед нами: динамично обновляющийся с равномерным поступлением данных либо хранилище археологии.

Интересная метрика, которую стоит брать во внимание, уникальность данных в различных источниках. Подсчет следующий: для каждого источника данных в выборке (совокупности источников) нужно посчитать вхождения значений индикаторов компрометации из одного источника в другой. В результате можно получить таблицу:

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

Ниже приведем пару примеров. В первом примере хорошо видно, что фид CIRCL пересекается всего на 1% и 2% c digitalside и botvrj соответственно, а botvrj на 30% и 1% c CIRCL и digitalside соответственно (тут все верно, разный процент пересечения между botvrj и CIRCL получился из-за их разных размеров по количеству объектов внутри относительно друг друга).

Во втором примере справедливо видно тотальное пересечение между фидами OTX - Project TajMahal и IBM X-Force Project TajMahal. Это объясняется тем, что фиды рассказывают об одной и той же угрозе.

Вместо выводов

Хотелось бы подвести тут умное заключение, но некоторая недосказанность прямо-таки просится сюда по той причине, что нет единого способа оценить полезность фидов с помощью универсального набора метрик. Пока нужно оценивать источники данных, исходя из специфики индустрии, деятельности организации и ее модели угроз, а это довольно кропотливая ручная работа. В этой статье мы рассмотрели ряд наиболее используемых метрик, с которых стоит начинать погружение в мир TI. Кажется, что высказывание одного популярного Youtube-канала На нашем канале зрители все выводы делают сами как нельзя кстати подходит под заключение этой статьи.

Авторы: Антон Соловей, менеджер продукта R-Vision Threat Intelligence Platform,

Николай Арефьев, сооснователь RST Cloud

Другие статьи по теме

• Погружение в Threat Intelligence: кому и зачем нужны данные киберразведки

• Threat Intelligence по полочкам: разбираемся в стандартах обмена данными

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

Конечно, внутри компаний есть (или должны быть) специально обученные люди, занимающиеся поиском уязвимостей. Но объем таких работ огромен, и увеличивается он ежедневно. Что можно предпринять? Найти нужные рабочие руки всех желающих, кто хочет и может этим заняться, причем за вознаграждение. Так возникла идея Bug Bounty открытой краудсорсинговой альтернативы внутренней ИБ-службе, реализованной как своего рода мегаконкурс по поиску уязвимостей в программах компаний (разумеется, все это не за бесплатно, хотя есть исключения).

Увы, джентльменам не верят на слово в современном мире, а потому, если вы решили попробовать заработать на bug hunting, придется соблюдать правила игры. В статье я попытаюсь очертить круг возможностей охотников за ошибками и расскажу о вариантах участия в программах вознаграждения за найденные ошибки: сторонних платформах Bug Bounty (marketplaces) и программах, спонсируемых компаниями.

Платформы Bug Bounty

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

К наиболее известным площадкам Bug Bounty относятся Bugcrowd, HackerOne, Vulnerability Lab, BountyFactory, Synack.

HackerOne и Bugcrowd

HackerOne и Bugcrowd имеют схожий охват различных компаний с разными продуктами, бизнес-моделями и требованиями безопасности. Основное направление площадок поиск уязвимостей в веб-приложениях, но есть также предложения о поиске уязвимостей в мобильных приложениях и нестандартные альтернативные варианты. У HackerOne есть несколько известных компаний, которые являются эксклюзивными для этой платформы (в том числе и Twitter), но в целом предложения очень похожи.

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

Bugcrowd поддерживает систему классификации уязвимостей, называемую таксономией рейтинга уязвимостей (Vulnerability Rating Taxonomy, VRT). Как утверждают представители площадки, эта система помогает определиться, на какие типы уязвимостей лучше обратить внимание с учетом опыта исследователя и его веры в свои силы, измеряемой в величине вознаграждения за найденную уязвимость. Естественно, что чем больше вы верите в свои силы, тем на более дорогостоящие уязвимости вы решите замахнуться.

VRT это весьма полезная услуга, предоставляемая площадкой. Можно, во-первых, потренироваться или повысить свои навыки на обнаружении несложных уязвимостей, а во-вторых, определить оптимальный режим приложения сил для получения вознаграждения и оценить реальный уровень этого вознаграждения с учетом существующих навыков и опыта.

В то время, как вы изучаете площадки, площадки изучают вас. Как в Bugcrowd, так и у HackerOne есть политика вознаграждения за нахождение багов. Исследуются, например, показатели количества и качества активности пользователя, полученные за последние 90 дней. По результатам таких исследований вас могут пригласить в частные программы вознаграждений. Они отличаются более узким кругом претендентов на награду, что повышает шансы найти денежный баг, но в то же время претенденты в них более опытны, и лишь ваше дело решить, что лучше ввязаться в драку или посмотреть на нее со стороны.

Помимо этого, HackerOne предлагает вознаграждение за аудит безопасности собственных ресурсов и сайтов площадки. В этом случае выплату можно получить, даже если обнаружить уязвимости не удастся, главное продемонстрировать серьезный исследовательский подход с полным описанием опробованных вариантов. Отсутствие результата тоже результат, к тому же зачем упускать возможность лишний раз проверить безопасность, не так ли?

Vulnerability Lab

Представьте, что вы нашли критическую уязвимость в безопасности очень крупной компании, разглашение информации о которой может обойтись вам очень дорого. В этом случае на помощь может прийти Vulnerability Lab. Эта платформа может быть использована как точка контакта и сторонний посредник между исследователем и рассматриваемой им компанией. При этом одна из функций сайта Vulnerability Lab включает получение отчетов о критических уязвимостях, которые исследователь может не захотеть предоставлять напрямую. Vulnerability Lab использует команду внутренних экспертов для проверки уязвимостей высокого уровня, но также принимает сообщения и о менее критических уязвимостях. Публикация отчетов об ошибках по истечении определенного промежутка времени (как в HackerOne) делает эту площадку полезным справочным пособием для новичков, стремящихся лучше понять как форму отчетов об ошибках, так и методы обнаружения этих ошибок.

BountyFactory

BountyFactory позиционирует себя как первая европейская Bug Bounty платформа, основанная на европейских правилах и законодательстве. BountyFactory управляется группой YesWeH4ck рекрутинговой компанией Infosec, основанной в 2013 году. Помимо платформы Bug Bounty, под управлением YesWeH4ck находятся доска объявлений о работе YesWeH4ck Jobs, скоординированная платформа раскрытия уязвимостей ZeroDisclo и совокупность всех общедоступных программ по защите от уязвимостей FireBounty. Как и Bugcrowd и HackerOne, BountyFactory имеет свою систему оценки, таблицу лидеров, а также публичные и частные программы, на которые распространяется ограниченное количество приглашений. Являясь европейским оператором, BountyFactory отлично подходит для компаний, которые не пользуются популярными американскими bug bounty-платформами.

Synack

Платформа Synack позиционирует себя как своего рода эксклюзивный клуб охотников за ошибками. Желающим попасть в него необходимо пройти весьма жесткий отбор. Synack потребует вашу личную информацию, проведет видеоинтервью, инициирует проверку биографических данных и идентификацию, а также оценит ваши навыки, чтобы убедиться, что вы не только обладаете опытом подобных работ и способны на многое, но и достаточно ответственны для аудита программ, предполагающих работу с конфиденциальными данными (одна из специализаций Synack). В Red Team этой платформы принимаются менее 10% претендентов. В отличие от других платформ Bug Bounty, Synack не публикует список лидеров или каких-либо других исследователей публично (хотя у нее есть внутренние рейтинги, которые используются как основа для вознаграждений и приглашений для выбора компаний). Synack хранит личность своих исследователей в секрете, и это дает охотникам за ошибками некоторую защиту от судебных исков со стороны компаний, пытающихся препятствовать агрессивному аудиту, или от тех, кто считает, что исследователь нарушил Правила взаимодействия (Rules of engagement, ROE).

Программы, спонсируемые компаниями

Деньги против барахла

На требования и условия получения вознаграждения за поиск уязвимостей в рамках программ, спонсируемых компаниями, влияет множество факторов. В основном в качестве вознаграждения компании предлагают деньги, при этом широко распространены и так называемые swag-only программы, когда исследователи получают подарки: различный мерч, бутылки с водой и так далее. Тем не менее, именно swag-only программы являются базой, основой для новичков. Они дают отличную практику по поиску уязвимостей на действующих сайтах компаний, при этом многие из них поддерживаются на сторонних маркетплейсах. Таким нехитрым образом компании одновременно обеспечивают себе более широкий круг исследователей уязвимостей и избегают излишних трат денег. Помимо этого, особо отличившихся охотников за уязвимостями компании могут пригласить в собственные программы bug bounty hunting.

Крупные компании платят высокие гонорары за найденные уязвимости, но шанс найти такую уязвимость не слишком велик: основной спектр уязвимостей уже найден до вас. У стартапов будут более уязвимые приложения, но область атаки намного уже, чем у крупных компаний, то есть уязвимости могут быть малоизвестными, и помимо определенной удачи, нужны опыт и навыки. Взлом Google, Facebook или Amazon гарантирует вам большие выплаты в случае успеха, но у них уже есть крупные команды безопасности и так много сообщений об ошибках от независимых исследователей, что начинающему охотнику за ошибками будет сложно найти что-либо с первой попытки.

Как говорилось в одном известном советском фильме, в джинсы сейчас облачились даже самые отсталые слои населения. Собственные программы bug bounty hunting сегодня имеют не только крупные компании, но и средний (и даже малый) бизнес. На удивление большое количество компаний предлагает вознаграждение за вклад в обеспечение безопасности. Поскольку уместить всю информацию об этом в одной статье попросту немыслимо, часть информации о программах, спонсируемых компаниями, останется за бортом моего поста.

Google

У Google обширная программа Bug Bounty, с подробными структурами выплат и специальными инструкциями для классификации различных типов ошибок. Большую часть информации об этом можно найти в разделе Награды на странице Безопасность приложений, но Google также разрабатывает набор учебных пособий по тестированию (небольшой). Особое внимание в нем уделяется формализации результатов: как правильно оформить конкретно для Google то, что вы искали и как вы это делали. В качестве примера можно привести университет Bughunter, Google Gruyere и другие учебные приложения. В них содержатся не только предпочтения и требования Google, но и лучшие практики и знания, которые можно применить к программам и заданиям других компаний.

Facebook

У Facebook есть программа вознаграждения за выявление ошибок с минимальной выплатой в размере 500 долларов. В политике ответственного раскрытия информации компании говорится, что Facebook не будет мириться со злоупотреблениями с данными. Это значит, что против вас не будут инициировать судебный процесс или расследование с привлечением правоохранительных органов в ответ на сообщение о найденной проблеме безопасности, но при одном условии соблюдении вышеупомянутых правил Facebook (политики ответственного раскрытия). Количество информации, доступной для программы Facebook, минимально. Помимо этого, Facebook очень резко реагирует на попытки несанкционированного поиска уязвимостей на своей платформе, что неудивительно, особенно с учетом недавнего усиленного контроля за деятельностью компании как за рубежом, так и в России.

Amazon

У Amazon есть программы bug bounty hunting как для подразделений электронной коммерции, так и для облачных сервисов. Их ключевая особенность применение разрешительной модели участия вместо открытой. Другими словами, пока вы соблюдаете правила взаимодействия, можете ожидать иммунитета. Amazon потребует от вас регистрации и запроса на разрешение участия в пентестинге. Таким образом компания отсекает излишнее количество тестировщиков, а также старается различить активность белых и черных хакеров (White and Black-Hat).

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

GitHub

GitHub предлагает программу вознаграждений, которая охватывает широкий спектр его свойств, включая API, корпоративные приложения и основной сайт. Выплаты в большинстве случаев варьируются от 555 до 20 000 долларов США.

Одна из замечательных особенностей программы GitHub заключается в том, что каждый участник, успешно нашедший ошибки, получает страницу профиля, на которой отображаются не только набранные им баллы, место в рейтинге исследователей и заработанные значки, но и обнаруженные уязвимости с кратким техническим описанием. Такие страницы профиля могут стать впоследствии отличным пунктом в резюме для карьеры в области ИБ.

Microsoft

У Microsoft есть программа вознаграждений, охватывающая как ее потребительские продукты для ПК, так и продукты для веб-приложений, например, Azure. На сайте программы Microsoft Bounty подробно рассказывается о форматировании отчетов и их представлении, показаны примеры хороших и плохих образцов, приведены подробные, конкретные рекомендации по тестированию для каждого свойства Microsoft, но нет большого запаса учебного материала с точки зрения общего пентестинга. У Microsoft, как и у многих других компаний, есть своя публичная таблица лидеров и система рейтинга.

Internet Bug Bounty Program (IBBP)

IBBP представляет собой нечто среднее между сторонними маркетплейсами и спонсируемыми компанией программами. IBBP некоммерческая организация, которую финансируют крупные технологические партнеры, включая Microsoft, Adobe, Facebook и GitHub, для защиты целостности основных интернет-сервисов. Технологии, охватываемые программой Bug Bounty IBBP, разнообразны: языки (Perl, Ruby, PHP), фреймворки (Django, Ruby on Rails), серверы (NGINX, Apache HTTP) и криптографические инструменты (Open SSL).

Именно IBBP выплачивала вознаграждения за некоторые из самых известных и высокооцененных найденных уязвимостей за последнее десятилетие: Heartbleed 15 тыс. долларов, ShellShock 20 тыс. долларов и ImageTragick 7,5 тыс. долларов. Таким образом, IBBP является отличным ресурсом для развития навыков пентестинга, особенно веб-приложений.

Как найти программы Bug Bounty сторонних компаний

У многих компаний есть программы вознаграждения за ошибки. Выяснить, поддерживается ли для сайта или приложения программа Bug Bounty, легко за пару запросов. Например, можно использовать запросы с синтаксисом поиска Google, например, inurl: / security /, intext: bug bounty и intext: reward или их объединение. Можно также настроить оповещение Google, используя эти и другие поисковые термины, чтобы получить простой, автоматизированный способ поиска новых программ для участия в пентестинге.

Bugcrowd курирует список, заполняемый компаниями-участниками платформы. Из него можно узнать, какие программы Bug Bounty доступны в компаниях, в какой форме по ним предоставляется вознаграждение, и есть ли у этих организаций Зал славы для успешных исследователей.

Firebounty, упомянутый ранее как продукт YesWeH4ck, представляет собой гибрид, который показывает программы Bug Bounty с других платформ, а также свои собственные уникальные предложения.

Автор: Дмитрий Мельник, ведущий инженер по информационной безопасности R-Vision

Минувшей зимой мы впервые опробовали формат хакатона. Из-за ограничений на массовые мероприятия он проходил в формате онлайн, но это никак не сказалось на наших ожиданиях. Нам давно хотелось повысить узнаваемость бренда работодателя за пределами ИБ-рынка среди разработчиков и других айтишников, которые зачастую не имеют о нас никакого представления. Кроме того, мы хотели понять, можно ли на хакатоне познакомиться с перспективными специалистами, а еще нам было очень интересно узнать внутреннюю кухню профессиональных организаторов таких мероприятий, чтобы научиться проводить их самим.

Если вам давно не дает покоя идея провести хакатон, но трясутся поджилки, и вы не знаете, с чего начать, добро пожаловать под кат. Мы расскажем, как это происходило у нас, как миновать наши грабли, и как ожидания могут разойтись с реальностью, а также можно ли воссоздать атмосферу офлайнового хакатона в режиме онлайн.

Как нам пришла в голову идея провести первый онлайн-хакатон?

Помимо всего, что мы перечислили выше, перед нами стояла основная задача решить практическую проблему, к которой одна из наших команд долго не могла подступиться. У нас был корпус текстов, и на его основе нужно было создать алгоритм, который бы выбирал из этого корпуса именованные сущности, относящиеся к предметной области threat intelligence: злоумышленников (threat actors), вредоносное ПО (malwares), индикаторы компрометации (indicators of compromise) и прочие. Нюанс заключался в том, что корпус текстов был на английском языке. Задача была нетривиальная, интересная, но у нас до нее очень долго не доходили руки.

Почему именно хакатон, когда есть много других инструментов?

В целом для решения основной задачи можно было нанять аутсорсеров, а для поиска кандидатов активнее задействовать HR и сконцентрироваться на подборе персонала. Но внезапно с нами на связь вышел представитель компании Pystech.Genesis, специализирующейся на проведении хакатонов для айтишников. Мы начали обсуждать организационный процесс и в итоге решили протестировать проведение совместного онлайн-хакатона с поддержкой профессионального организатора таких мероприятий. Поскольку у нас самих были планы проводить хакатоны в будущем, нам хотелось посмотреть вживую, как это делают специалисты с богатым опытом за плечами.

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

Как выбирали задание?

Процесс выбора задания сам по себе был увлекательным. В нем участвовали сотрудники сразу двух подразделений: Центра экспертизы и Департамента разработки. Первый помогает клиентам и партнерам выстраивать ИБ-процессы на базе наших решений, а второй разбит на команды по создаваемым продуктам. По сути департаменты и отдельные команды конкурировали друг с другом, и все они были заинтересованы в том, чтобы выбрали именно их задачу.

Мы проводили отдельную встречу, на которой желающие питчили каждый свою задачу и объясняли присутствующим, почему именно их задача должна быть выполнена на хакатоне. Например, Центр экспертизы предлагал в качестве задачи разработку нового генератора лицензий для компании. Было много интересных задач, но победила в итоге задача от команды продукта R-Vision Threat Intelligence Platform (TIP), представляющего собой платформу для управления данными киберразведки.

Суть задачи

Изначально задача в постановке команды TIP была конкретная и слишком специфичная для ИБ-сферы. Это было не очень удачно, поскольку на хакатоне предполагается определенная свобода действий для команды. Поэтому мы решили разбить задачу на две части.

1. Основная задача была достаточно широка: построить интерфейс сбора, описания и аналитики угроз, индикаторов компрометации по реальным документам.

2. Далее командам давалась полная свобода по созданию продукта. Результатом могла стать программа, ML-модель, иная реализация, которая позволила бы решать прикладные задачи сбора и анализа неструктурированных данных об ИБ-угрозах. Предпочтение планировали отдавать наиболее законченным решениям, которые закрывали бы целостную (end-to-end) задачу.

Неожиданности, с которыми мы столкнулись

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

Изначально мы рассчитывали примерно на 60 участников, то есть не более чем на 10 команд. Но из-за того, что это был первый в этом году онлайн-хакатон в России, количество претендентов превысило 200 человек. В итоге мы вынуждены были проводить отсев, потому что с точки зрения организации просто не выдержали бы такое количество команд. В конце концов мы отобрали 13 команд, из которых до фактической реализации прототипа решения дошли 9, остальные выбыли на промежуточных этапах.

С чего начали подготовку к хакатону

У нашего задания была определенная ИБ-специфика, мы поняли, что нужно доступно объяснить задачу участникам, которые вообще не знают, что такое ИБ и индикаторы компрометации. Для этого Антон Соловей aka @likeafreedom, менеджер продукта R-Vision TIP и по совместительству тамада нашего хакатона, отвечал за взаимодействие с участниками: готовил задания, презентацию, проводил питчинги с командами вместе с другими экспертами нашей компании, делал все необходимое, чтобы хакатон состоялся. Чтобы ввести в курс дела далеких от области ИБ разработчиков и дизайнеров, мы решили отойти от позиционирования наших продуктов и не объяснять, что такое IRP, SGRC, TIP, SENSE и Deception, поэтому в презентации о компании визуализировали наши решения в виде маскотов.

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

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

Хакатон в цифрах

• Длительность 45 часов.

• Более 220 заявок на участие, конкурс 4,5 человека на место.

• 13 команд, 9 из них дошли до готового решения, 6 прошли в финал, из них осталось 3 победителя.

Этапы хакатона

1. Пятница, вечер. Знакомство. Рассказ о задании, презентация компании R-Vision.

2. Пятница, ночь. Разработка прототипа.

3. Суббота, утро. Питч решения: то, что успели сделать за ночь. 5 минут на питч.

4. Суббота, весь день и ночь. Второй питч: относительно готовый вариант.

5. Воскресенье, утро. Готовое решение на оценку экспертам.

Решения, которые выполнили команды

Команды-участники прорабатывали презентации своих решений и дизайн инструмента. Из интересных можно выделить решение команды Digital Rover, которая придумала что-то вроде Алисы для инфобеза виртуальный помощник на основе искусственного интеллекта для описания угроз по реальным документам. Решение на основе языковой модели ruGPT3 представляет собой бот для Telegram, который позволяет написать что-то на нативном языке текстом либо отправить голосовой запрос. У инструмента есть весь наш корпус текстов, который он переводит на английский язык. Затем он переводит на английский полученное текстовое или аудиосообщение, анализирует соответствие запроса содержимому корпуса документа и выдает пользователю релевантную информацию. Например, можно написать или сказать: Расскажи мне про такую-то уязвимость или Напиши больше информации про такой-то индикатор компрометации, и бот будет отвечать выжимками из корпуса текстов.

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

1. ARES. Разработка продукта для аналитиков в сфере ИБ базы знаний, агрегирующей источники данных с анализом угроз компьютерной безопасности, справочники с терминами, взаимосвязи между сущностями предметной области. Задачи, которые воплотили в продукте:

   • Создание системы фильтрации источников аналитики по ключевым словам

   • Аннотация новых отчетов для выделения терминов, имеющих отношение к ИБ-аналитике, и добавления документа в базу знаний

   • Подключение справочных систем (MITRE и MISP)

   • Визуализация взаимосвязей между сущностями предметной области ИБ

2. Stellar. Проект R-Vision Assistant cервис для сбора, визуализации и аналитики данных по угрозам кибербезопасности. Особенности сервиса удобный и понятный UX/UI-интерфейс, возможность работы с различными источниками данных о киберугрозах и добавления новых. Решение содержит много вариантов визуализации, аналитики.

3. DEV Labs. Интерфейс для полуавтоматизированного парсинга основных сущностей из неструктурированных источников данных, в рамках которых ИБ-специалист анализирует уязвимости. Программа нацелена на повышение качества данных, сохраняемых в базу знаний.

Находчивость приветствуется

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

Выводы

Что нам в итоге удалось

Мы смогли использовать хакатон как возможность рассказать о нас как о компании и в результате отобрали 15 человек для дальнейшего общения по поводу трудоустройства. Однако специалисты, показавшиеся нам интересными, не были заинтересованы в смене работодателя, а были готовы только к работе на отдельных проектах.

Что можно было бы сделать лучше

Мы выделили слишком много экспертов от нашей компании, это отнимало много рабочего времени наших сотрудников. В следующий раз сократим количество экспертов как минимум вдвое.

Также очень много времени у нас уходило на развертывание продуктов на наших стендах: на каждую команду тратили по 1015 минут. На будущее решили давать командам заранее сформированный стенд, чтобы у них была возможность разворачивать готовое решение самим.

Планы на будущее

Мы получили полезный практический опыт и обязательно будем его использовать в дальнейшем. Теперь планируем раз в квартал проводить свои внутренние хакатоны и периодически организовывать внешние с привлечением подрядчиков. Это реально сделать и своими силами, но поддержка со стороны профессионального организатора хакатонов позволяет сократить количество экспертов от компании до 2-3 человек, а значит, сэкономить рабочее время сотрудников.