:::::: ЧОУ ДПО «Центр предпринимательских рисков» :::::

Эффективное распределение SOC'ами информации об угрозах

Член подкомитета (ПК 1 ТК 122 Федерального агентства

по техническому регулированию и метрологии (Росстандарта))

Обмен информацией об угрозах: типовые ошибки и способы их избегать

В России сейчас намечается не то чтобы бум, но явная тенденция к активному использованию и построению центров мониторинга инцидентов информационной безопасности. Такие центры не совсем верно называют CERTами; правильнее называть их CSIRTами, так как сама аббревиатура CERT является торговой маркой и на её использование надо получать соответствующее разрешение. Хотелось бы поговорить об одной из составляющих эффективного CERT, — об управлении, а точнее, о распределении информации об угрозах.

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

В каком виде может распространяться такая информация? Очевидно, что данные сведения не должны быть хаотическими, распространяемыми нерегулярно, в непонятной и неудобной для работы с ними форме, по незащищенным каналам. Например, совершенно бессмысленно передавать pdf-файлы, содержащие неструктурированный текст, общими словами описывающий ту или иную угрозу. Такая информация ничем не поможет её получателям, так как и вредоносный код, и эксплойт, и атака могут уже завтра измениться. А pdf сложно «прикрутить» к каким-либо системам защиты для автоматического обнаружения и блокирования.

ИНДИКАТОРЫ КОМПРОМЕТАЦИИ

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

Для идентификации более сложных образцов вредоносных воздействий нужна дополнительная аналитика, которая может быть получена в виде так называемых индикаторов или признаков компрометации (Indicators of Compromise, IoC), которые принято делить на три основных типа:

Атомарные. К ним относятся IP-адреса, e-mail-адреса, DNS-адреса, полные URL и даже статические фрагменты в управляющих (Command & Control, C2) каналах вредоносного кода или ботнетов. Такая информация является первичной информацией, позволяющей идентифицировать что-то нехорошее, происходящее в сети или на отдельных компьютерах. Да, IP– или DNS-адреса, с которых может распространяться вредоносный код, могут меняться и меняться часто (до нескольких раз в день). Но и индикаторы компрометации, содержащие эту информацию, могут также распространяться по мере появления новой информации.

Вычисляемые. К такому типу индикаторов относятся хэши (контрольные суммы) вредоносных файлов по стандартам MD5 или SHA1, ключи реестра, списки процессов или информация для декодирования протоколов, по которым работает вредоносный код.

Поведенческие. Это уже не отдельные индикаторы, а их наборы, описывающие профиль поведения чего-либо или кого-либо — злоумышленника, узла, подсети и т. п. Например, таким индикатором может служить формализованное описание следующего профиля — «неизвестный часто использует IP-адреса в диапазоне <таком-то> для попытки подключиться к Web-сайту <такому-то> в <такое-то> время» или «неизвестный отправил вложение в формате MS Word в сообщение e-mail с почтового сервера, созданного 10 минут назад в Украине» .

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

Динамичность присуща не только вредоносным файлам, но и адресам — IP, DNS, e-mail. Например, тот же MultiPlug за 3 месяца сменил 500 доменов, с которыми он взаимодействовал; по 5–6 доменов (!) в день. Набор экслойтов Angler менял ежедневно IP-адреса и использовал сайты-однодневки для своего распространения. В рамках спамерской кампании Dridex злоумышленники обновляли текст рассылаемых по электронной почте писем каждые 4–6 часов.

За первое полугодие 2015-го года было обнаружено 850 уникальных образцов рассылок, т. е. 5–6 новых рассылок каждые сутки. Очевидно, что традиционные средства защиты, обновляемые даже несколько раз в день, не способны бороться с такими угрозами. К тому моменту, как они научатся распознавать их, злоумышленники уже сменят название файла, текст спамерской рассылки, используемый для скачивания дополнительных модулей домен или IP-адрес для сервера управления.

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

КАК ОПИСАТЬ ИНДИКАТОР КОМПРОМЕТАЦИИ?

С оперативной рассылкой индикаторов (до нескольких раз в час!) вроде бы все понятно. А вот как описывать эти индикаторы? Тут возможно два варианта развития событий.

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

Вариант № 2 — использовать общепринятые стандарты описания индикаторов компрометации, которые понятны многим распространенным средствами защиты информации.

Можно, конечно, распространять и неформализованный бюллетень в формате Word или PDF. Но при их получении у меня возникает закономерный вопрос: «И что мне с этим PDF/Word делать?». IP/DNS/E-mail-адресов в нем нет. Хэшей вредоносных файлов тоже нет. Отдать эту информацию на вход своей системе защиты я не могу. Понятно, что в виде PDF такую информацию, да еще и регулярно, рассылать бессмысленно. Всё-таки нужен открытый и стандартизованный формат, который позволяет легко и без особых затрат загружать индикаторы компрометации в средства защиты.

Какие это общепризнанные стандарты могут быть? Их на самом деле разработано уже немало:

TLP (Traffic Light Protocol) — простой протокол, предложенный американским центром реагирования на инциденты US CERT, и позволяющий «раскрасить информацию в 4 «цвета». От цвета зависит, кому можно передавать информацию об угрозах — всем, внутри отрасли или сообщества, внутри организации, нельзя передавать никому. Протокол очень прост в реализации, и его можно применить даже к обычной электронной почте.
Протоколы и стандарты рабочей группы MILE (Managed Incident Lightweight Exchange), включающие:
- Стандарт Incident Object Description and Exchange Format (IODEF) , описанный в RFC5070, и содержащий в формате XML свыше 30 классов и подклассов инцидентов, включая такую информацию как контакт, финансовый ущерб, время, пострадавшие операционные системы и приложения и т. д. IODEF — стандарт достаточно проработанный и уже немало где используется. Из организаций его использует Anti-Phishing Working Group, а также многие CERT/CSIRTы. Да и с вендорской поддержкой не так все плохо — SIEM постепенно интегрируют его внутрь себя.
- Стандарт IODEF for Structured Cyber Security Information (IODEF-SCI) , который является расширением для IODEF, позволяя добавлять к IODEF дополнительные данные — шаблоны атак, информация о платформах, уязвимостях, инструкциях по нейтрализации, уровень опасности и т. п. Также предлагается включить в состав IODEF-SCI часть стандартов американской корпорации MITRE, предназначенных для описания тех или иных нюансов, связанных с ИБ, — уязвимостей, атак, конфигураций, ошибок и т. п. (это стандарты CAPEC, CEE, CPE, CVE, CVRF, CVSS, CWE, CWSS, OCIL, OVAL, XCCDF, XDAS).
- Протокол Real-time Inter-network Defense (RID) , который позволяет взаимодействовать различным системам ИБ-аналитики. Построенный на базе HTTP/HTTPS, он, хотя и описан в RFC6545, не является очень уж популярным.
OpenIOC — это открытый стандарт описания индикаторов компрометации (Indicator of Compromise, IOC), который первоначально был закрытой разработкой американской компании Mandiant, но потом был открыт для публичного использования. Также как и IODEF построен на базе XML и содержит свыше 500 различных индикаторов, преимущественно узловых (хостовых) — файл, драйвер, диск, процесс, реестр, система, хэш и т. п. Пока OpenIOC — это преимущественно епархия продуктов Mandiant, но постепенно начинает проникать и в решения других компаний-разработчиков средств защиты информации.
VERIS (Vocabulary for Event Recording and Incident Sharing) — стандарт американской компании Verizon, ориентированный стратегически, в отличие от тактического OpenIOC, на информацию об угрозах и инцидентах. По сути это некий единый язык для описания и обмена информацией об инцидентах. Схема VERIS состоит из пяти частей — отслеживание инцидента, описание инцидента, демография жертвы, оценка ущерба и реагирование, каждая из которых в свою очередь делится на различные типы данных и переменные. Большой популярности данный стандарт пока не снискал.
Стандарт CybOX (Cyber Observable Expression) , разработанный американской корпорацией MITRE, предназначенный для описания индикаторов наблюдаемых событий безопасности. Сегодня уже представлено свыше 70 различных описываемых объектов — файл, сетевое соединение, HTTP-сессия, сетевой поток (Netflow), сертификат X.509 и т. п.
Стандарт STIX (Structured Threat Information Expression) , также разработанный MITRE и позволяет унифицировать описание различных угроз. Несмотря на его активное продвижение в США, он достаточно сложен в реализации и поэтому уступает по популярности OpenIOC и IODEF.

СТАНДАРТЫ ОБМЕНА ИНФОРМАЦИЕЙ ОБ УГРОЗАХ

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

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

Стандарт TAXII (Trusted Automated eXchange of Indicator Information) , разработанный в пару к STIX, и позволяющий унифицировать обмен данными об угрозах. В частности данный стандарт уже используется в центре обмена информацией об угрозах в финансовой отрасли США (FS-ISAC), некотором аналоге FinCERT, заработавшем при Банке России.
Европейский стандарт VEDEF (Vulnerability and Exploit Description and Exchange Format) для обмена информацией об уязвимостях и эксплойтах, разработанный рабочей группой при TERENA.
Также европейский стандарт SecDEF (Security Description and Exchange Format) обмена различной информацией в области безопасности. Инициирован ENISA, но пока широко не применяется и его описание не опубликовано. После опубликования есть надежда, что именно этот стандарт станет наиболее популярным на территории европейских стран.
Стандарт CAIF (Common Announcement Interchange Format) , предложенный немецким RUS-CERTом для обмена формализованными бюллетенями по безопасности.
Стандарт DAF (Deutsches Advisory Format / German Advisory Scheme) , также предложенный для обмена информацией другим CERTом из Германии.

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

CIF (Collective Intelligence Framework) , разработанная REN-ISAC(Центром обмена информацией об угрозах для американских вузов и исследовательских организаций), поддерживаемая рядом организаций. Она позволяет собирать и объединять информацию об угрозах из различных источников и использовать её для идентификации инцидентов, обнаружения и нейтрализации угроз. Нейтрализация заключается в генерации правил для Snort (на базе Snort построены почти все отечественные и сертифицированные в ФСТЭК России и ФСБ России системы обнаружения кибервторжений, которые могут стать частью государственной системы обнаружения, предотвращения и ликвидации последствий компьютерных атак ГосСОПКА), iptables и других средств защиты. CIF преимущественно работает с IP-адресами, доменными именами и URL, связанными с вредоносной активностью. В качестве формата хранения информации использует IODEF.
The MANTIS (Model-based Analysis of Threat Intelligence Sources) Framework — это новая инициатива, которая объединяет вместе вышеперечисленные стандарты OpenIOC, IODEF, CybOX, STIX, TAXII. Пока сказать что-то конкретное про эту систему рано — она появилась относительно недавно, и опыта её применения практически нет.
Combine — решение open-source для сбора и обработки данных об угрозах. Используя в качестве источника данных множество ресурсов с информацией об угрозах, на выходе эта система выдает нормализованные сведения в формате, понимаемом многими SIEM.

ГДЕ БРАТЬ ИСХОДНЫЕ ДАННЫЕ?

Ну хорошо, есть стандарты описания индикаторов компрометации. Есть и стандарты для обмена ими. Есть даже система, которая позволяет всё это автоматизировать. Но где брать данные для индикаторов компрометации? Как обычно, вариантов существует несколько.

Во-первых, можно брать данные от средств защиты информации. Для корпоративного центра мониторинга инцидентов — это первый и самый важный источник данных. SIEM — идеальный инструмент для сбора сведений из внутренних источников — МСЭ, IDS, антивирусов, сканеров безопасности и др.

Какие данные можно получить из внутренней сети? Это:

сетевой трафик (Netflow / jFlow / sFlow);
активность с необычных IP-адресов;
DNS-запросы;
URL;
заголовки SMTP;
адреса e-mail;
сэмплы вредоносного кода;
активность пользователей;
неудачные попытки входа;
административный доступ;
операции с СУБД;
соединения на нетипичных портах;
появление нетипичных протоколов;
несоответствие размеров пакетов для служебных протоколов стандартам;
адреса анонимайзеров;
User Agent в HTTP;
входные узлы Tor;
вредоносные IP (C&C, спамеры, боты…);
репутация пользователей, узлов и файлов и т. д.

Но этот вариант нельзя задействовать в отраслевом или государственном центре, только если не загонять на него все информационные потоки для последующего анализа. В России такое возможно будет сделать в рамках недавно объявленной централизации всех государственных информационных ресурсов в рамках федеральных ЦОДов и единого сегмента сети Интернет для государственных органов, контролируемого Федеральной службой охраны (ФСО).

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

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

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

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

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

Abuse.ch
Anubis.Iseclab
Blocklist.de
Camas
CleanMX
Cuckoo Sandbox
Critical Stack
Hail a Taxii STIX IoC
IOCbucket.com
IOCmap
Malwr.com
Malwaredomains.com
MalwareIOC
Microsoft APP
Mirror-ma.com
OpenDNS
PassiveTotal
Pastebin
SANS ICS Data Feed and Threat Diaries
SenderBase.org
SpamHaus
ThreatGrid
Threat Exhange
VirusTotal
VirusShare
WhoisXMLAPI
Zero Wine
ZeusTracker
Zone-h.org.

Есть и еще один проект, который позволяет собирать и обмениваться информацией об угрозах — это Open Threat Exchange. Он построен на OSSIM (open source SIEM) и через него обменивались информацией свыше 18 000 внедрений OSSIM по всему миру. Также он может обмениваться информацией с описанной ранее системой CIF.

Сходу трудно припомнить открытые источники таких данных в России. Что-то есть у Positive Technologies, что-то у Лаборатории Касперского, что-то у Dr.Web, что-то у Group-IB, что-то у «Перспективного мониторинга», но не всё публично и не всё формализовано. Хотя постепенно ситуация меняется и отдельные отечественные игроки начинают понимать, что имеющаяся у них информация может быть коммерчески использована.

Какой бы вариант, платный или бесплатный, ни был избран, приходится доверять источнику или источникам. Его отсутствие — проблема, и серьёзная. Есть такие ресурсы как, например, www.malwaredomains.com. Есть и платные сервисы, распространяющие такие сведения, например, ETPro, IQRisk или ThreatStream. Но насколько они полны и релевантны? Какое влияние на них имеют иностранные спецслужбы? Насколько они учитывают региональную специфику? Насколько оперативно они обновляются?..

ЗАКЛЮЧЕНИЕ

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

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