Обнаружение атак двадцать лет спустя

Почти  двадцать лет спустя я написал свою первую книжку по обнаружению атак, которая, до сих пор используется в учебном процессе ряда ВУЗов. При этом ее часто даже сейчас воспринимают как догму, забывая, что за двадцать лет технологии обнаружения атак сильно поменялись, а возможности решений по обнаружению атак не ограничены только классическими IDSами (хотя регуляторы, присвоив аббревиатуры СОВ и СОА вполне конкретным типам решений, сильно подпортили картину).

В одном из недавних проектов по аудиту SOC я столкнулся с этой проблемой. Заказчик в ТЗ на построение системы защиты указал, что необходимо, среди прочего, построить систему обнаружения атак, а проектировщик не долго думая, просто прописал в проекте кучу сенсоров сетевой системы обнаружения атак и все. В рамках аудита, мы выясняли, причину такого решения, и почему проектант даже имеющийся у заказчика Stealthwatch (решение класса Network Traffic Analytics, NTA) не включил в список технологий обнаружения. Разумеется, все остальные варианты обнаружения вредоносной активности также не были рассмотрены проектироващиком, который почему-то посчитал, что обнаружение атак - это только классические сетевые СОВы (СОА), которые появились в то время, когда основным источником при обнаружении атак был сетевой трафик и, иногда, системные логи.

С тех пор ситуация сильно поменялась и к источникам, по которым можно обнаруживать проявления вредоносной активности, добавилось куча всего другого - файлы, Web-трафик, Netflow (и вообще flow-протоколы), URL, домены, активность пользователя и активность приложений. И это еще не полный перечень.

Другая проблема в обнаружении атак в том, что эти решения обычно ставят на периметра корпоративной или ведомственной сети, в то время как они сегодня давно не ограничены одной площадкой или одним выходом в Интернет. У вас есть внутренняя сеть и куча способов проникновения в нее, минуя периметр. У вас есть Wi-Fi, у вас есть АСУ ТП, у вас есть облака, у вас есть 4G и еще куча точек и отрезков контроля. Обратите внимание, что я специально упомянул не только точки, которые можно контролировать на предмет вредоносной активности, но и отрезки, на которых это можно сделать.

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

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

Да ну, фигня это все, можете сказать вы. У меня есть МСЭ, СОВ и антивирус, да еще и сертифицированный VPN; зачем мне еще что-то? Они прекрасно справляются со своими задачами. Ну еще WAF куплю в 2020-м. Как вообще вышеприведенную матрицу транслировать в приоритезированный список технологий обнаружения атак, которые надо внедрять в организации? Я бы начал с матрицы MITRE ATT@CK, которая описывает самые распространенные тактики, техники и процедуры киберпреступников. Существует маппинг TTP из нее с источниками данных, позволяющих выявлять плохих парней. Обратите внимание, что на первом месте у нас мониторинг процессов, файлов, параметров командной строки, API, реестра и сетевого трафика. Сетевой трафик вообще на последнем месте в Топ7 источников.

Для упрощения можно посмотреть Топ10 источников данных для мониторинга от Red Canary и посмотреть, что из этого вы мониторите, после чего уже принимать взвешенное решение о том, какие источники данных у вас не охвачены и какие технологии нужны для их охвата.

Подробнее…

Как готовить UEBA: рецепты от Гартнер

Я написал в прошлой заметке, что Гартнер 16-го ноября, пригласив Антона Чувакина, провел в Москве мини-семинар, посвятив его двум темам - поведенческой аналитике и внедрению и эксплуатации DLP-решений. Про вторую часть я писать сегодня не буду, сконцетрируюсь на первой презентации, которая очень хорошо ложится в серию заметок, посвященных мониторингу ИБ.

UEBA или User-Entity Behavior Analytics - это модная тема, к которой стали обращаться организации, не получившие удовлетворения от внедрения SIEM и иных инструментов анализа данных в контексте информационной безопасности. Немного повангую, предположив, что в России скоро может появиться мероприятие типа UEBA Forum, которое будет продвигать какой-нибудь отечественный вендор по ИБ. И ярким кандидатом на эту роль я бы назвал СерчИнформ, который сейчас “пилит” свою UEBA, называя ее системой профалинга пользователей. На самом деле об активности в этой сфере уже заявляли 4 компании - Инфовотч, Солар, СерчИнформ и ЦБИ, но:

• у Инфовотча уже есть DLP Russia (то есть BIS Summit)  “про DLP”
• у Солара есть SOC Forum “про SOCи”
• у ЦБИ есть конференция по мониторингу “про SIEM”.

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

В каких случаях компании обращаются к UEBA. Их по сути три:

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

Отсюда сразу вытекает вывод, что UEBA - это искусственно созданная сущность, возникшая на фоне проблем у существующих на рынке решений по ИБ, и когда эти задачи будут решены, то и само понятие “рынок UEBA” исчезнет (по возможным прогнозам - к 2020-му году), слившись с другими технологическими нишами, коих по-крупному выделить можно две:

• SIEM. Очень часто производители UEBA используют системы управления событиями ИБ как точку входа для своих аналитических возможностей. Оно и понятно - зачем самим собирать данные из источников, когда можно взять их уже готовые из SIEM. Но тут напрашивается вывод, что SIEM-вендоры могли бы расширить функционал своих продуктов, добавив в них UEBA. Так и поступают, например, Splunk, IBM, LogRhytm. Из отечественных игроков SIEM по этому пути пошел, как минимум, ЦБИ. Тут, правда, стоит оговориться, что UEBA отличается от классического SIEM тем, что не опирается на жесткие правила корреляции, пороговые и “средние” значения, которыми оперируют системы управления событиями ИБ. Все-таки в аббревиатуре UEBA последняя буква означает “advanced analytics”, то есть нечто более продвинутое, зачастую базирующееся на машинном обучении и иных интересных фишках, которые позволяют системе самообучаться, а не жить за счет правил, созданных аналитиком SIEM. Еще одним отличием от SIEM является работа с не “чистыми” ИТ-данными. Нередко UEBA берут информацию от HR-решений, бизнес-приложений, систем экономической безопасности и т.п., существенно расширяя оперируемый ими контекст.
• DLP. Учитывая, что DLP в последнее время все чаще трансформируются из средств защиты от утечек информации в средства мониторинга поведения пользователей (даже рабочее время контролируют), то логично предположить, что DLP будут расширяться функциями UEBA. По этому пути пошел СерчИнформ, Инфовотч, Солар. На мой взгляд это тупиковый путь (вот тут более подробно написано, почему), так как сама идея DLP обречена на неудачу в современной ИТ-среде, но, видимо, DLP-вендоров это мало останавливает и они хотят придать новый толчок своим продуктам с помощью хайповой UEBA.

Понятно, что помимо SIEM и DLP, технология UEBA может развиваться и самостоятельно. По такому пути пошли лидеры этого рынка - Securonix и Exabeam (у нас “чистых” отечественных UEBA-вендоров не наблюдается). Учитывая вышесказанное, не исключаю, что указанные компании будут куплены более крупными игроками и слиты с существующими продуктами. Гартнер считает, что UEBA-функциональность будет появляться и в других нишах ИБ - CASB, EDR, NTA, что еще острее поставит вопрос о необходимости UEBA как самостоятельного решения или выбору UEBA, как технологии в каком-либо из существующих на рынке продуктов.

Гартнер видит два бизнес-кейса для покупки UEBA:

• Улучшение обнаружения угроз, пропускаемых другими средствами защиты. Но есть ли у вас такие средства? Вы используете что-то помимо IDS/IPS и антивирусов? Вы применяете NTA, CASB? У вас уже есть SIEM и вы, имея многолетний опыт работы с ним, понимаете, что его возможностей вам реально не хватает? Это важный момент. UEBA нужна тогда, когда вы реально перепробовали все и вас это не устраивает. Вот тогда вы действительно готовы потратить кругленькую сумму денег на поведенческую аналитику. Если же для вас это очередной хайп и вы с трудом понимаете, что такое UEBA и зачем она нужна, то стоит повременить с выбором.
• Повышение эффективности повседневных операций по ИБ, позволяющих более оперативно детектировать компрометацию пользовательских учетных записей, утечки данных, нарушения привилегированных пользователей и т.п. Но тут вновь нас подстерегает засада. Вы вообще оцениваете эффективность своих операций по ИБ? Вы реально оценивали временные и финансовые затраты на их реализацию? Вы попробовали снизить их более простыми и, возможно, бесплатными методами? Может начать с этого? Вот если вы готовы с цифрами в руках показать, что текущее положение дел вас действительно не устраивает, вам стоит посмотреть в сторону UEBA. Но только в этом случае. В противном случае вы потратите много денег и так и не поймете, стало ли у вас лучше и “эффективнее”.

Среди некоторых ключевых проблем, с которыми сталкиваются заказчики, внедряющие или внедрившие UEBA, Гартнер называет следующие:

• Доступность и качество исходных данных. Да-да, спустя 20 лет с момента появления SIEM на рынке, это до сих пор основная проблема в мониторинге ИБ. Именно ей была посвящена конференция ЦБИ, о которой я писал в предыдущей заметке.
• Квалификация аналитиков. В прошлый раз, на семинаре Gartner в Москве, рассказывая про продвинутую аналитику, Антон Чувакин также касался этой проблемы. У вас есть на примете те, кого на Западе называют data scientist? Они должны хорошо разбираться в ИБ и математике одновременно, чтобы строить и проверять корректность используемых моделей поведения, закладываемых в решения UEBA. Зачастую найти таких специалистов почти нереально, а их годовой фонд оплаты труда может быть выше стоимости UEBA-решения. Без грамотных аналитиков приоретенное решение превратится в тыкву и станет очередной бесполезной игрушкой в руках службы ИБ.
• Оценка эффективности технологии. Ну я бы назвал это общей проблемой в ИБ, а не только в UEBA.
• Приватность. Да, работа с Большими данными - вообще представляет большую проблему для приватности, так по анализу разрозненных данных можно делать очень интересные, и часто нелицеприятные, выводы о поведении пользователей, что вступает в конфликт с конституционными правами граждан на невмешательство в частную жизнь. Антон рассказывал, что одного из американских UEBA-вендоров европейские заказчики даже попросили переименовать продукт, чтобы из его названия исчезли слова “user behavior analysis”, которые являются табу в Европе, так борющейся за права граждан. У нас, кстати, это тоже может скоро стать проблемой, так как Роскомнадзор готовит законопроект по так называемым большим пользовательским данным и регулированию деятельности по работе с ними. Он может коснуться и UEBA-решений (да и вообще анализа Big Data в контексте ИБ).

В заключении Антон Чувакин сделал достаточно важное замечание про будущее всех решений на базе продвинутой аналитики (advanced analytics). Безопасность - это всегда про умного нарушителя и какой бы супер-умной не была технология, она всегда будет сталкиваться с иррациональным поведением человека, которое сложно предсказывать. У автоматизированных систем принятия решений в ИБ (читай, ИБ-роботов) есть будущее, но нельзя полагаться на них целиком - роль человека в принятии решений остается очень важной. Поэтому, внедряя  UEBA, SIEM, SOC, EDR, NTA и т.п. не забывайте уделять должное внимание квалификации своего персонала, который внедряет, настраивает и эксплуатирует все современные “умные” ИБ-технологии.

ЗЫ. Кстати, мы внутри службы ИБ Cisco тоже используем UEBA-решение. Но, как это уже было с системой продвинутого анализа событий безопасности OpenSOC, мы не нашли устраивающего нас на рынке решения по ИБ (хотя и инвестировали 30 миллионов долларов в Exabeam) и в итоге написали собственную систему контроля поведения пользователей. Как нибудь я расскажу об этом решении, также как я уже описывал систему OpenSOC.

Подробнее…