Обмен информацией об угрозах информационной безопасности
Использование в Security Operations Centers (SOC) информации об угрозах из внешних источников – это само по себе уже качественный переход от реагирования на заранее известные сценарии угроз к практике раннего выявления новых типов атак. А обмен данными об инцидентах ИБ с другими центрами мониторинга и реагирования говорит о выходе на новый уровень зрелости SOC.
Solar JSOC уже несколько лет применяет базы данных угроз от производителей систем ИБ, подписки на специализированные ресурсы и ведет двусторонний обмен информацией c несколькими CERT’ами. Для понимания, как это может быть устроено и чего ждать от такого обмена, рассмотрим пример взаимодействия Solar JSOC и FinCERT.
КОГДА SOC НАЧИНАЕТ ИСПОЛЬЗОВАТЬ ИНФОРМАЦИЮ ОБ УГРОЗАХ ИЗВНЕ
Первоочередной задачей SOC в плане выявления инцидентов является понимание ключевых сервисов компании, важных с точки зрения операционной деятельности бизнеса, способов обращения с ними пользователей и администраторов, коммуникаций с внешним миром за пределами контролируемой зоны. Именно в отношении таких сервисов и обслуживающих их объектов инфраструктуры, таких как прикладные серверы СУБД и web-интерфейсы, аналитиками SOC строятся модели угроз, прогнозируются векторы атак. На первых этапах становления SOC создаются собственные каталоги сценариев атак, релевантные целям SOC: это может быть написанный с нуля перечень инцидентов или выбранные из каталогов SIEM-решений актуальные события ИБ и корреляционные цепочки на их основе. Естественно, что создаваемый и даже регулярно пополняемый перечень таких сценариев угроз никогда не сможет претендовать на полноту из-за активно развивающейся индустрии инструментария кибератак, обнаружения неизвестных ранее уязвимостей или разработки новых способов проникновения.
В таких условиях неизбежны инциденты, которые могут быть не замечены службой мониторинга SOC. А вот разбор этих инцидентов рано или поздно потребуется, например, после эскалации бизнес-подразделения вследствие причиненного ущерба. Приведенный пример часто является причиной привлечения специальных компаний для расследования инцидентов, а в случае наличия собственных экспертов – к обращению во внешние базы знаний о новых инцидентах для сопоставления выявленных Indicators of Compromise (IoC) и поиску рекомендаций по сдерживанию и устранению инцидента и его последствий. Подход не проактивный, но всё-таки имеет свой плюс: если применить на практике полученный опыт разбора нового инцидента и внести его в базу знаний SOC, настроить новые правила в SIEM (или в ряде случаев дооснастить систему ИБ новыми функциями), то повторное причинение ущерба можно свести к минимуму.
Но представьте, если о появляющихся новых инцидентах будет известно заранее. Если будет создан центр информирования, регулярно оповещающий о зарегистрированных векторах атак и предлагающий способы их раннего детектирования. И такие источники информирования давно создаются на базе аналитических центров производителей зарубежных систем ИБ, на западном рынке уже есть агрегаторы подписок на новости об угрозах от нескольких поставщиков, предлагающие систематизированный доступ к информации по отраслям, по способам проникновения, по вендорам и т.д.
В 2015 году примером российского центра информирования компаний банковского сектора стал Центр мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере (FinCERT). Менее чем за полгода команда FinCERT организовала сбор информации об угрозах, ее анализ и рассылку данных в виде структурированного документа среди более чем 200 участников. Основная их часть – банки, работающие на прием информации. Анализируют и применяют такие отчеты не более трети участников, а вот дают обратную связь и делятся своей информацией об угрозах – единицы. С одной стороны, некоторых участников не устраивает скорость обмена информацией или отсутствие чётких инструкций по настройке систем ИБ для отражения угрозы. С другой стороны, объяснить это можно тем, что созданные внутри SOC процессы, способные принимать на вход информационный поток для раннего детектирования новых атак – это показатель высокой операционной зрелости службы мониторинга и реагирования. К сожалению, работающих в таком режиме SOC’ов по всей России не более десятка, и лишь пара из них – представители банковской сферы.
КОГДА SOC НАЧИНАЕТ ПРЕДОСТАВЛЯТЬ ИНФОРМАЦИЮ ОБ ИНЦИДЕНТАХ НАРУЖУ
На нескольких тематических дискуссиях конференций и форумов, прошедших в 2015 году, поднимался вопрос обмена информацией об угрозах между организациями или с отраслевыми регуляторами. Опрос аудиторий показал, что многие участники рынка ИБ хотели бы получать информацию о способах реализации кибератак и рекомендации по внедрению превентивных мер. Но практически никто не готов делиться информацией о пропущенных ударах со стороны злоумышленников. С чем это связано: юридические нестыковки, отсутствие доверия к участникам обмена, боязнь признать свои ошибки или потеря репутации? На этот вопрос у каждого будет свой ответ, но вот случаи, когда организация начинает отправку оповещений о реализованных инцидентах, обусловлены следующими факторами:
- Нормативное требование. Конечно, в первую очередь стоит упомянуть ЦБ России и его Указания отправлять по 203-й и 258-й формам отчетности сведения, касающиеся инцидентов ИБ в ДБО, при работе с платежными системами, по электронным денежным средствам и поддельным банковским картам. Во-вторых, всё больший оборот набирает тема ГосСОПКА, а создаваемая в её рамках система как раз и определит порядок и формат обмена информацией о кибератаках.
- Функция средства защиты. Первопроходцами в получении данных об инцидентах с внедренных систем стали антивирусное ПО и системы обнаружения вторжений. Автоматический сбор и отправка по решению администратора ИБ обезличенной информации в центр обработки (лабораторию) сейчас доступна во многих средствах защиты.
- Осознанное решение по партнёрству. Наиболее зрелым подходом к информационному обмену видится установление партнерских, доверительных отношений. В этом случае обе стороны понимают цель и общую выгоду от сотрудничества, готовы активно содействовать друг другу в преодолении технических и организационных проблем.
Именно осознанное решение по партнерству с целью противодействия кибератакам, повышения информированности и готовности к раннему детектированию возникающих угроз стало поводом для сотрудничества коммерческого центра мониторинга и реагирования на инциденты ИБ Solar JSOC и FinCERT.
КАКОЙ ИНФОРМАЦИЕЙ ИНТЕРЕСНО ОБМЕНИВАТЬСЯ
Если посмотреть на поставщиков информации относительного нового направления ИБ Threat Intelligence, то многие из них предлагают перечни фишинговых сайтов, IP-адресов центров управления ботнетами, зараженные сайты и фальшивые DNS-сервера. В редких случаях можно найти IoC конкретных вирусов и троянов, используемых при организации целенаправленных атак. Но практически всегда это база знаний, состоящая из миллионов записей, которую невозможно использовать без средств интеграции с SIEM, web-proxy или IDS/IPS. К тому же среди этих записей нередко оказываются ложные или нерелевантные конкретной стране (например, России) данные. В таких условиях применение в SOC баз данных Threat Intelligence без опытных аналитиков, умеющих в SIEM автоматически отфильтровывать лишние срабатывания, приведет к снижению эффективности работы всего SOC и даже серьезным превышениям метрик SLA.
Одним из ключевых преимуществ использования Solar JSOC всегда являлась возможность раннего предупреждения собственных клиентов о возникновении определенных инцидентов в других обслуживаемых инфраструктурах и бизнес-приложениях. Этот процесс организован как накопление базы данных IoC и пополнение каталога корреляционных правил, которое происходит многократно быстрее, чем у любой организации, занимающейся развитием SOC самостоятельно. Данных, накопленных таким образом, в тысячи раз меньше, чем в любой подписке Threat Intelligence, но они многократно ценнее с прикладной точки зрения.
К обмену такой информацией было решено прийти, и с начала ноября 2015 года была организована двусторонняя отправка отчетов об обнаруженных векторах атак между Solar JSOC и FinCERT. Сведениями организации обмениваются в виде формализованных таблиц. Интересны они в первую очередь экспертам и аналитикам двух Центров. В Solar JSOC полученный отчет сверяется с имеющейся базой знаний и, если данные новые, информация заносится в SIEM-платформу как в виде новых корреляционных правил, так и путем пополнения специальных перечней индикаторов инцидентов.
Обязательными сведениями о заражении или инциденте являются:
- Общее описание угрозы: одно или два предложения, кратко раскрывающие суть угрозы;
- Способ реализации угрозы: через какой канал (email-рассылка с вложением или со ссылкой на сайт, запросы извне к публичным IP и т.п.) и с использованием каких уязвимостей;
- Реакция антивирусного ПО: какие антивирусы и с какими версиями обновлений баз способны детектировать угрозу, если это применимо;
- Маркеры угрозы: внешние IP-адреса, появление определенных файлов на атакованном хосте, изменения системных файлов и веток реестра и т.п.
- Рекомендации по противодействию: меры по сдерживанию атаки и восстановлению хоста в прежнее состояние, если это применимо.
ЧТО МОЖНО УЛУЧШИТЬ И КАКИХ РЕЗУЛЬТАТОВ ДОБИТЬСЯ
Между Solar JSOC и FinCERT сделан лишь первый шаг навстречу отточенному технологическому сотрудничеству. Вскоре могут возникнуть первые проблемы, которые необходимо решать уже сейчас, например, повышение количества текстовых отчетов без соответствующих машиночитаемых типизированных XML-файлов приведет к невозможности оперативного пополнения базы знаний. А от времени реакции на внешние изменения в Solar JSOC зависит величина потенциального ущерба обслуживаемых компаний: ведь счет иногда идет не на дни, а на часы. Как в Solar JSOC, так и в FinCERT обсуждаются удобные форматы предоставления информации об угрозах, а также порядок ее передачи кому-либо.
В конечном счете будет создан процесс обмена (framework) с использованием программной платформы, политики и регламентов передачи информации. Наиболее интересным кажется решение, создаваемое на базе Collective Intelligence Framework (CIF), с применением зарекомендовавших себя стандартов и протоколов: от простейших Traffic Light Protocol (TLP) для ограничения распространения информации вовне до OpenIOC на базе XML с предопределёнными классами индикаторов атак для унифицированного описания инцидентов. Но это еще только варианты, а конечный выбор платформы и реализация остается за техническими экспертами.
Двум Центрам мониторинга и реагирования на инциденты ИБ еще предстоит многое сделать для реализации полноценного технического взаимодействия, но одно уже ясно: сотрудничество, объединение знаний и повышение скорости реакции на угрозы – это единственный верный путь к достижению общей цели в борьбе с киберпреступностью.
.jpg)