7 сценариев, когда в организации используются 2 разных SIEM

В чатике про SOCи зашла тут дискуссия на тему, может ли, и если да, то зачем, использовать SOC два разных SIEM (именно SIEM, а не SIEM и LM или SIEM и UEBA). Вынесу я эту тему в блог, чтобы не забылась она и не затерялась. Я сталкивался с такими ситуациями не раз и поэтому не могу назвать это изначально неправильной идеей. Есть несколько сценариев, когда такая схема возможна:

1. SIEMы для работы и в рамках импортозамещения. На Западе этот сценарий встретить невозможно (разве, что в Китае, но это уже Восток), а вот в России он не редкость. Компания долгое время жила на зарубежном SIEM, но ввиду либо ухода Splunk из России, либо требований по импортозамещению (для госорганов и госкомпаний) вынуждена переходить на отечественные продукты. Да, тут речь идет о переходе, но для таких проектов он обычно длится не один год и поэтому в организации сосуществуют два SIEM. Иногда, правда, переход даже не планируется, так как отечественный SIEM работает, мягко говоря, неидеально.  Например, крупная холдинговая структура строит SOC на все часовые пояса по всей России. SOC двухуровневый - региональные мини-SOCи и один главный в центре. На регионы решили поставить отечественный SIEM. Когда его пытались натянуть на центр, оказалось, что по EPS он не тянет от слова совсем и надо либо ставить кластер из SIEM, что дорого, либо ставить другой, более производительный SIEM.
2. SIEM для работы и для compliance. Это частный случай предыдущего кейса, но у него немного иная мотивация. Один SIEM, как правило, зарубежный, используется для реальной работы, а второй, как правило, отечественный, для демонстрации регуляторам при проверках или для сопряжения с ГосСОПКОЙ. В последнем случае до сих пор нет ясности, должны ли средства ГосСОПКИ быть только российского происхождения или нет. С одной стороны, нормативные акты ФСБ говорят, что да. С другой стороны, практика утверждает обратное. Возможно, это явление временное, так как ни ФСБ еще не разработала регламента оценки соответствия средств ГосСОПКИ, ни российские вендоры пока еще не подсуетились с выпуском продуктов под них. В любом случае, видел проекты, где используется Arcsight или QRadar для основного мониторинга, а решение от Positive Technologies использовалось для передачи данных в ГосСОПКУ. 
3. SIEMы от мамы и от поглощенной компании. Ну тут очевидная история.  Купленная компания использует один SIEM, а купившая - второй. У первой достаточно большая автономия и менять шило на мыло она не готова (инвестиции сделаны, люди обучены, плейбуки написаны). Вторая может только в свой план развития включить переход на единый SIEM. Но будет это через несколько лет. А пока надо сосуществовать вместе. При этом речь не идет о том, что эти SIEM независимы - головная компания требует передачи данных из подчиненного SIEM в головной, что можно сделать как на уровне отправки данных об инцидентах, так и в виде отправки определенных или всех событий.
4. SIEMы для себя и для предоставления услуг. У нас в рамках оказания услуг по проектированию SOC, один из задаваемых заказчику вопросов звучит так: "Вы планируете использовать SOC для себя или будете предоставлять на нем услугу внешним заказчикам?" От ответа на него зависит многое - не в части процессов или компетенций специалистов (хотя и они немного отличаются), а в части именно технологического стека. "Для себя" можно сделать "на коленке", не очень красиво, но так чтобы работало. Для внешней аудитории или для демонстрации руководству "на коленке" уже не работает и могут понадобиться немного иные решения. Да и совмещать внутренние и внешние источники и события безопасности в одном решении не совсем разумно. Поэтому снова возникает тема с 2 SIEM, хотя в данном случае она и вырожденная, - управляют ими разные подразделения, обменивающииеся, разве что, общими данными Threat Intelligence.
5. SIEM для корпоративной сети и для АСУ ТП. Нередко АСУ ТП делают изолированными от внешнего мира и даже от корпоративных сетей. Да и за безопасность АСУ ТП может отвечать подразделение, отличное от корпоративной ИБ. Поэтому и SIEM могут быть изначально разные, которые со временем могут начать обмениваться данными между собой для выявления сложных атак, подразумевающих проникновение через корпоративную сеть (как первый этап kill chain).
6. SIEM для корпоративной сети и для облачных сред. Кейс, схожий с предыдущим, но отличающийся тем, что для мониторинга облачных сред Azure, GCP или AWS используются встроенные в облачные платформы SIEM, а корпоративная сеть мониторится "по старинке". Я про эту историю писал большой обзор на Хабре (часть 1 и часть 2).
7. SIEM для базовой аналитики и а-ля SIEM для глубокого анализа (Big Data Security Analytics). Наверное, это не совсем история про два классических SIEM, так как второй компонент больше относится к инструменту анализа, чем к инструменту визуализации событий безопасности. Но все-таки, учитывая, что SIEM используется для сбора данных и их анализа, могу отнести его к ситуации, когда в организации используется два разных решения. Второй SIEM нередко даже пишут сами на базе open source компонентов, закладывая в него богатый инструментарий для глубокой аналитики событий ИБ на базе машинного обучения. Например, в Cisco именно так родился OpenSOC, про который я писал 3 года назад на Хабре.
8. SIEM подороже и подешевле. Учитывая, что SIEM часто лицензируются по EPS и при большом потоке событий цена решения может быть достаточно велика. Поэтому возникает соблазн, когда вы вместо дорогого SIEM берете тот, у которого цена лицензии на EPS обходится дешевле, или тот, у которого вообще схема лицензирования, отличная от EPS.
9. SIEM побыстрее и помедленнее. В зависимости от архитектуры SIEM, использования реляционной или нереляционной базы данных, скорость индексации и поиска событий ИБ может стать ключевым фактором при выборе SIEM. Мы в Cisco в свое время, среди прочего, по этой причине отказались от одного из SIEM и стали писать свой OpenSOC. При этом у нас продолжает использоваться Splunk для работы с краткосрочной аналитикой и для визуализации. А OpenSOC работает с долгосрочными данными, ретроспективой и неструктурированной информацией.

Да, у вас будут сложности при объединении двух разных SIEM в единый комплекс, когда одно из решений выступает в качестве источника событий для другого. Особенно учитывая, что они могут иметь разные форматы данных, разные их схемы. Но при желании такой вариант все-таки возможен. В ряде случаев поток событий будет распараллеливаться между двумя SIEMами. В ряде случаев у вас IRP/SOAR может работать с двумя SIEMами. Все эти варианты непросты в реализации, что повышает вероятность ошибки. Но и отбросить этот вариант тоже не совсем правильно - иногда применение двух SIEM вполне оправдано. В любом случае описанные выше сценарии вполне рабочие, чтобы разговор о двух разных средствах мониторинга событий ИБ можно было рассматривать как глупую шутку или вырожденный кейс.

Но при этом, если уж вы идете по пути двух и более (и такое тоже бывает) SIEM, убедитесь, что они обладают продвинутым API, который позволяет не только делать им запросы друг к другу, но и который поддерживается вашей IRP/SOAR. Тогда интеграция SIEM станет возможной.

В 2017-м году для SOC Forum я сваял много демотиваторов и мемасиков, одним из которых был такой:

И ведь как в воду глядел. Спустя год с лишним предсказание сбылось, правда для другого вендора. Поэтому вопрос про 2 SIEM вполне себе насущный :-)

Подробнее…

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

Почти  двадцать лет спустя я написал свою первую книжку по обнаружению атак, которая, до сих пор используется в учебном процессе ряда ВУЗов. При этом ее часто даже сейчас воспринимают как догму, забывая, что за двадцать лет технологии обнаружения атак сильно поменялись, а возможности решений по обнаружению атак не ограничены только классическими 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 и посмотреть, что из этого вы мониторите, после чего уже принимать взвешенное решение о том, какие источники данных у вас не охвачены и какие технологии нужны для их охвата.

Подробнее…

Как НЕ надо выбирать SIEM?

На сочинском "Коде ИБ. Профи" (кстати, на прошлой неделе стали доступны все презентации и записи с него) у Льва Палея был мастер-класс о том, как выбирать средства защиты, где среди рассматриваемых в качестве примера решений были системы управления событиями ИБ (SIEM). И у меня в загашнике давно был черновик заметки на схожую тему. Но я не стану отнимать хлеб у Льва (тем более, что у него мастер-класс был практический - с заданиями и их разбором) и напишу о том, как НЕ надо выбирать SIEM :-) Тем более, что за последнее время, в ряде проектов по SOC, в которых я участвую в России и странах СНГ, накопились определенные наблюдения, которые и станут основой этой заметки.

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

Не выбирайте SIEM, потому что это модно

Ну это вроде и так понятно. Выбирайте не то, что модно, а то, что нужно. Это простая истина применима не только к SIEM, но и вообще к любому хайпу - от SOCа до блокчейна, от WAF до CASB. Для этого вам, правда, нужно знать, что нужно :-) А поняв это, вы поймете, как этого достичь и, только потом, сможете определиться с инструментарием для этого.

Не выбирайте SIEM под требования регуляторов

Регуляторы, и ФСТЭК, и ФСБ, и ЦБ, сегодня много говорят про необходимость непрерывного мониторинга ИБ и устанавливают требования к решениям этого класса. Особенно важно это при интеграции вашей инфраструктуры мониторинга с той же ГосСОПКА или ФинЦЕРТом. Но... обратите внимание, что иногда гораздо проще и лучше - строить систему мониторинга такой, какой ее хотите видеть вы (исходя из ваших условий), а на стыке с ГосСОПКОЙ или ФинЦЕРТом поставить какой-нибудь шлюз, который будет посредником между вами и регулятором и просто передавать нужные данные туда и обратно. Не ведитесь на рекламу ряда отечественных вендоров, которые говорят, что у них встроенная поддержка взаимодействия с ГосСОПКОЙ "из коробки". Зато другой функционал, который вам и нужен в первую очередь, там может быть не очень. В конце концов, если выбранный вами SIEM из-за "печати" "Approved by GosSOPKA" не сможет видеть инцидентов, то и отдавать вам будет нечего. А вот функция "генерация отчетов о соответствии требованиям регуляторов" очень неплоха; главное, чтобы эти отчеты были по регуляторике, которая применима к вам. В любом случае помните, решение по безопасности нужно для обеспечения вашей безопасности, а не требований регуляторов.

Не выбирайте SIEM, потому что вы строите SOC

Все умные люди, говоря о SOCах, обычно делают знак равенства между двумя фразами "имею SOC" и "имею SIEM", но это не совсем так. Достаточно просто вспомнить, что вы можете аутсорсить свой SOC у внешнего поставщика услуг, к которому вы предъявляете требования по скорости реакции, гарантиям, охвату вашей инфраструктуры, но точно не по тому инструментарию, который он должен использовать. Это его прерогатива, раз уж вы выбрали его из множества аутсорсинговых SOCов; доверьте ему и выбор SIEM. Вы вообще можете не знать, какой SIEM у вашего SOC-as-a-Service; вы же платите за услугу с понятными входными и выходными данными и вам не так уж и важно, что у нее внутри.

Не выбирайте SIEM, потому что он в правом верхнем углу магического квадранта

Обратите внимание, я не говорю, не выбирайте SIEM из этого угла квадранта. Я говорю, не выбирайте, потому что он там. Чувствуете разницу? Если SIEM попал в этот угол, значит он достаточно хорош (а вы же хотите все самое лучшее, не так ли?). Но вам нужна не медаль на грудь и не "мировой рекорд",  а решение стоящих перед вами задач. Возможно вас устроит что-то более простое и не столь дорогое? Возможно 50% функционала самого крутого SIEM в мире вам просто не нужны? Так зачем за нее платить (а также за специалистов, которые знают как работать с самым крутым SIEM в мире)?

Не выбирайте SIEM, потому что вас зачморили коллеги и говорят вам "Ты что, с Урала?"

Помните советский фильм "Самая обязательная и привлекательная"? Там был эпизод, где главную героиню привели к, как сейчас модно говорить, байеру, который предлагал то одну модную штуку, то другую, то третью. А на изумленный вопрос героини "А зачем это?", ее сравнили с деревенщиной, припечатав, ставшим классикой, "Ты что, с Урала?" Не выбирайте конкретный SIEM и вообще SIEM, потому что это модно и у всех ваших коллег это есть.

Не выбирайте SIEM, потому что вам надо выстроить сбор логов

Для сбора логов выбирайте решение соответствующего класса -  SIEM тут будет избыточен. Если, конечно, у вас нет четкого плана продержаться на вашем текущем месте еще лет пять, на которые у вас уже есть стратегия развернуть полноценный мониторинг ИБ, с долговременным хранением, корелляцией, оркестрацией, контролем поведения, анализом сетевого трафика и т.п. Если вы не имеете персонала, который будет пялиться в монитор SIEM круглые сутки или хотя бы в режиме 5х8 или если у вас нет задачи оперативного реагирования на инциденты (а ее может и не быть), то зачем вам SIEM? Ограничьтесь обычным LM-решением.

Не выбирайте SIEM по фичам и обещаниям вендора

Часто, смотря материалы вендоров, мы попадаем в ловушку "kill feature", которая означает, что у продукта есть какая-то классная фишка и вокруг нее выстроен процесс продаж. Помните анекдот про студента, сдающего экзамен по зоологии, который успел выучить только билет про блох? Вот так и тут. Например, у SIEM классная фишка - он по умолчанию интегрируется с ГосСОПКА, а вы, как субъект КИИ обязаны это сделать. И вот вокруг этого начинаются танцы продаванов с бубном, уводя вас в сторону от такой, например, проблемы как низкое количество событий в секунду (EPS), которое может обработать одна нода SIEM. И чтобы работать в вашей организации вам нужно поставить 4 ноды, в то время как у другого SIEM, у которого нет встроенной "килфичи" работы с ГосСОПКОЙ, достаточно всего одной ноды, да еще и с запасом.

Или другой пример. Продавец SIEM вам говорит, что вы сэкономите, купив его решение, так как у него SIEM и SOAR и IRP - все в одном флаконе. А вы же понимаете, что хотя бы IRP, но вам нужна (а может и SOAR вместо IRP). Вы берете этот SIEM, но потом оказывается, что он не работает в multi-tenant архитектуре, а у вас холдинг и каждому предприятию нужен свой "кусок". Или multi-tenant поддерживается, но нет иерархии SIEM "главный-подчиненный", которая вам нужна для охвата 9 часовых поясов и размещения нескольких центров мониторинга по России и странам СНГ, в которых у вас размещены точки присутствия. Смотрите сначала на архитектуру, а потом на конкретные функции, тем более обещаемые.

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

Не выбирайте SIEM, потому что он поддерживает искусственный интеллект

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

От ответов на них зависит, понимает ли вендор, что такое ИИ и машинное обучение в частности или нет? И стоит ли вестись на всю эту хайповую тему с магической заменой кучи конструкций "IF THEN" в коде или корреляционном правиле на словосочетания "искусственный интеллект", "нейросеть" или "глубокое обучение". Для того, чтобы назвать атакой 3+ попыток неудачного входа в систему с одной учетки за короткий интервал времени, много ума не надо. В отличие от идентификации кражи учетной записи по определению нетипичного места входа в систему, опираясь на результаты кластеризации таких попыток за большой интервал предыдущего времени, опираясь именно на ваши данные. ИИ в SIEM есть и он может решать свои задачи - вопрос в том, знаете ли, как выжать максимум из него, и знает ли это локальный поставщик?

Не выбирайте SIEM, потому что у него отличная корреляция

Это древняя песня, которую я помню еще с конца 90-х годов, когда внедрял свой первый SIEM в одном из национальных банков на постсоветском пространстве. Заказчик тогда тоже купился на рассказ про корреляцию и вот это вот все, но реальность была совсем другой. Несмотря на наличие правил корреляции "из коробки", которыми так кичился вендор, пришлось писать много своей логики, отличавшейся от задумки производителя. И это при том, что число источников, подключаемых к SIEM, было на порядки меньше, чем у современных решений по мониторингу. По рынку ходит цифра, что сколько бы правил корреляции в вашем SIEM не было, только 20% их них можно применять безболезненно. Поэтому надо четко осознавать, что писать правила корреляции под ваши use case придется вам (или внешнему интегратору за дополнительные деньги) и все слова о "уникальной системе корреляции" превратятся в реальности в тыкву.

Не выбирайте SIEM, потому что он имеет универсальный коннектор ко всему

А подключать к этому коннектору ваши решения будет кто? Бывает так, что с универсальным коннектором может работать только сам вендор и больше никто. И вы сразу стали заложником конкретного вендора. И если вам, например, нужно написать коннектор к системе защиты вашего промышленного сегмента, а она куплена в единственном экземпляре и есть в России только у вас, то как вендор напишет тогда коннектор к тому, что он у себя даже развернуть не может и специалистов по чему у него нет?

Не выбирайте SIEM, у которого нет плана развития

Я уже писал выше, что надо проверять все заявленные и нужные вам фичи в рамках пилота. Не менее важно, чтобы у SIEMа был четкий план развития (с соответствующими подтверждениями), который учитывает тенденции рынка и вашу стратегию развития. Возможности масштабирования, рост производительности, новые коннекторы для интеграция с различными решениями (не забывайте учитывать все скрытые затраты такой интеграции, которые лягут тяжким бременем на ваши плечи), поддержка каких-либо стандартов (от STIX/TAXII и MITRE ATT&CK до ГосСОПКИ и ФинЦЕРТа), новые функциональные модули, новые корреляционные возможности, обнаружение новых атак и т.п. Вроде бы очевидные вещи, но часто бывает так, что продукт берется ради сиюминутных задач, а потом оказывается, что вендор и не развивает свой продукт, делая только косметические правки, оставаясь на позади конкурентов. Такое было в свое время с netForensics - лидером рынка SIEMов, который сдулся и прекратил свое существование. Кстати, план развития тоже не гарантия, что продукт будет развиваться согласно ему. Но это уже ситуация, которая не предсказуема и с которой приходится просто мириться, на ходу меняя решение на другое.

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

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

Не выбирайте SIEM, потому что у него харизматичный лидер с горящими глазами

Проверьте, что за этим лидером есть команда, которая готова развивать и поддерживать продукт. Извините, никто не вечен и все может произойти в жизни - от рождения детей до попадания в ДТП на "джихад-такси" Яндекс.Такси. Горящие глаза и делающие руки - это классно, но любая разработка - это процесс, который не должен зависеть от одного винтика, вынув который, все ломается. К иностранным вендорам этот совет малоприменим, а вот в России такие случаи бывают. 

Не выбирайте SIEM, потому что он поддерживает ваши средства защиты периметра

Первые SIEM появились в конце 90-х годов, чтобы сократить число ложных срабатываний у систем обнаружения вторжений и межсетевых экранов. С тех пор число источников событий безопасности и объем этих событий возросли многократно. Насколько выбираемый вами SIEM способен работать с такими источниками? DLP? CASB? AWS CloudTrail? Azure Monitor? UEBA? EDR? HRM? СКУД? SCM? ERP? СУБД? Иные бизнес-системы?

Не выбирайте SIEM, у которого нет реагирования

Вам для чего нужен мониторинг ИБ? Чтобы видеть атаки или чтобы их отражать или купировать последствия? Вот так и SIEM нужен не только для того, чтобы видеть как можно больше, но и для того, чтобы оперативно реагировать на обнаруженное. Поэтому неплохо бы, чтобы выбираемый вами SIEM знал как реагировать и, желательно, применительно к вашим же средствами защиты (напрямую, через скрипты или через какой-либо SOAR). 

Не выбирайте SIEM, если не знаете, где взять людей для работы с ним

Очевидно.

Не выбирайте SIEM, если у вас нет процесса мониторинга ИБ

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

• Что вы хотите собирать?
• Где это находится?
• Кто отвечает за эти источники?
• Как и в каком формате хранятся эти данные?
• Как отдаются эти данные?
• Что надо предпринять, чтобы забрать эти данные?
• Как обеспечивается целостность и непротиворечивость этих данных?
• Что вы будете делать с этими данными?
• Сколько надо хранить эти данные?
• Какие виды анализа вы будете проводить над этими данными? 
• Как вы управляете временными метками в вашей инфраструктуре?
• Кто имеет доступ к этим данным?
• Насколько структурированы эти данные?

Вот только небольшой список вопросов, на которые надо получить ответы до начала выбора SIEM.

Не выбирайте SIEM с непонятным TCO

По результатам общения с вендором вам все понравилось и вы готовы заплатить кругленькую сумму за систему мониторинга событий ИБ. Но... посчитайте TCO для него. На тестах оказалось, что вам нужна иная конфигурация, чем вы изначально рассчитывали? Вам нужна лицензия на большее число EPS, чем думали изначально? Выбранное или рекомендованное вендором железо "не тянет" и требуется более мощное? Ваша архитектура потребовала новых коллекторов? Курсы обучения по SIEM в России не проводятся и надо ехать в Европу (а вас по приезду развернули, потому что вы под санкциями, несмотря на полную предоплату, - реальный случай)? Вы не учли размер хранилища под собираемые события ИБ (кстати, вы в курсе, что будет, если на ваш SIEM подадут больше EPS, чем надо, или база переполнится?)? Вы не заложили стоимость написания коннекторов под ваши специфические источники? Есть вендора, которые предлагают к своим решениям полную калькуляцию всех статей расходов, которые могут понадобиться для развертывания и эксплуатации SIEM с расчетом на 12, 24 или даже 36 месяцев. Ваш вендор вам такое может сделать с учетом вертикального (число EPS) и горизонтального масштабирования (число и типы источников)?

 Не выбирайте SIEM-вендора - выбирайте SIEM-партнера

В отличие от МСЭ, EDR, NGIPS или SIG, решение по мониторингу событий ИБ требует гораздо более тесного взаимодействия с его производителем (тоже можно сказать и про DLP, и про другие прикладные ИБ-игрушки). Это не коробка, которая работает по принципу "поставил и забыл". Работы с новыми источниками, понимание методов анализа, разработка правил корреляции, масштабирование, расчет TCO, обучение модели ML... Да мало ли еще тем, по которым вы будете постоянно общаться с производителем вашего SIEM. Готов ли вендор к этому? Готовы ли вы к этому?

 Не выбирайте SIEM как самодостаточную систему

Как вы будете использовать SIEM? Это важный вопрос. Не для чего, а именно как. Вы планируете ее использовать как самодостаточное решение или интегрировать с IRP/SOAR, TIP, NTA, UEBA, EDR, CASB, CMDB и другими решениями, которые вместе позволят выстроить вам цикл управления инцидентами в вашей инфраструктуре? Если второе, то смотрите на то, с чем и как может интегрироваться выбираемый вами SIEM.

Вот таким получился список из почти двадцати "как не надо" выбирать SIEM. Допускаю, что их гораздо больше. Главное, чтобы этот список был прочитан, критически обдуман и воспринят. Тогда быть может у нас будет гораздо меньше неудачных внедрений SIEM, а нам в проектах по аудиту SOCов придется реже ставить самый низкий уровень зрелости SOC из-за того, что заказчик не потратил чуть больше времени на правильный выбор правильного SIEM, который, что ни говори, но пока для многих является ядром центра мониторинга ИБ.

Подробнее…

Можете работать руками или на счетах? Значит у вас нет значимых объектов КИИ

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

Секция по цифровой экономике меня и порадовала и огорчила одновременно. Порадовала она тем, что на ней выступали представители регионов, которые задавали закономерные вопросы о том, почему им приходится тратить на непонятные требования по безопасности сотни миллионов рублей и стоимость защиты информационных систем выходит выше, чем стоимость самих информационных систем. И почему, например, муниципалы только-только установили у себя VipNet'ы 3-й версии, а тут приходит указание заменить все на 4-ую. Министры региональной информатизации задаются закономерным вопросом - что такого изменилось в мире, что надо срочно и в обязательном порядке переходить на новую версию? Угрозы стали серьезнее? Алгоритмы стали быстрее и эффективнее? Не было ответа, так как, и это меня удручало, чиновники не пришли на секцию. Что касается секции по импортозамещению, то она была похожа как две капли воды на все остальные секции - импортозаместители говорили каждый за себя и ничего конкретного :-(

Но перейдем к секции по кибербезопасности - я заранее подготовил вопросы к участникам, которые представляли собой субъектов КИИ, вендоров по ИБ и регуляторов. Правда, с последними вышла промашка, - обещанный НКЦКИ так и не посетил мероприятие и заготовленные ему вопросы остались без ответа. А по остальным вопросам были вполне конкретные ответы от участников.

Первый вопрос касался ошибок, которые субъекты КИИ делают при формировании перечня объектов КИИ. Согласно решению коллегии ФСТЭК многие субъекты должны были составить такие перечни и отправить во ФСТЭК к 1-му августу, а согласно решению СовБеза - к 1-му сентября. Я заранее подготовился к модерируемой секции и взял перечень ошибок из презентации Алексея Кубарева, которая читалась за день до ИТ-Диалога в Москве (остальные материалы тут). Однако по сравнению с этим списком, на секции представитель ФСТЭК по СЗФО озвучил еще одну ошибку - когда присылаются все ИС, АСУ ТП и ИТС, а не только те, которые обслуживают критические процессы. Это странная позиция на мой взгляд, так как такое определение объекта КИИ уже установленного законом. Понятно, что ФСТЭК лишнюю работу делать не хочется, но блин... Наступаем на те же грабли, что и с сертификацией средств защиты ПДн, когда при наличии фразы про оценку соответствия регулятор раньше считал, что это написано только про сертификацию.

Из субъектов КИИ на секции присутствовали ИВЦ питерского РЖД, питерский метрополитен и ДИТ Москвы. У ИВЦ прозвучало сначала очень революционная идея, что у них после оценки оказалось, что объектов КИИ нет вообще. В процессе дискуссии выяснилось, что позиция ИВЦ базируется на простом факте - если нарушение работы информационной системы не сказывается на выполняемых ИВЦ задачах и они могут быть выполнены "вручную", то данная информационная система не является объектом КИИ (думаю, что все-таки речь идет о значимом объекте, а не просто об объекте). Очень интересная, но и понятная позиция. У метро подход оказался схожий. А вот у ДИТ Москвы (выступал Валерий Комаров) иная проблема - они не являются обладателями/владельцами/заказчиками информационных систем, используемых в Москве, - они всего лишь их оператор и на них требование по категорированию не распространяется.

Из зала была поднята тема лицензирования деятельности по защите для субъекта КИИ. Я заранее, на основе своей заметки, подготовил табличку и хотел ее обсудить с двумя регуляторами, но увы, НКЦКИ не пришел и поэтому их позиция (особенно по последнему пункту) осталась неозвученной. А ФСТЭК подтвердил правильность таблицы по их направлению. Кстати, представитель ФСТЭК также упомянул, что сейчас оперативно готовится (все-таки) единая методика моделирования угроз, которая будет применяться для ГИС, АСУ ТП, КИИ и других типов защищаемых по требованиям ФСТЭК объектов. Ждемс...

Вопросы к НКЦКИ остались без ответа, но тут может помочь презентация их представителя, прозвучавшая днем ранее в Москве.

На заданный в самом конце вопрос о гостайне, ФСТЭК ожидаемо ответила, что к ГТ будут относиться только совокупные сведения по КИИ и каждому субъекту не придется создавать у себя первые отделы.

Что еще прозвучало интересного на мероприятии? Тезисно я бы отметил следующее:

• питерское метро ориентируется в первую очередь на встроенные механизмы защиты и планирует выполнять 239-й приказ именно ими - в наложенных средствах защиты они не нуждаются
• ДИТ и Конфидент считают, что рынок отечественных решений ИБ вполне себе развит и можно выполнить требования 239-го приказа целиком на отечественных решениях (ну не знаю, я скептично отношусь к такой позиции).
• РТК-Solar рассказал, что НКЦКИ не требует, чтобы SIEM на стороне центров ГосСОПКИ были только отечественного производства. Интересно, в проекте приказа НКЦКИ было написано немного другое. Может и правда поменяют? Хотя РТК-Solar, использующий в своем SOCе три разных SIEM (Arcsight, QRadar и MaxPatrol), для субъектов КИИ применяет отечественное решение (может все-таки готовятся к негативному развитию событий?).
• Также РТК-Solar рассказал, что НКЦКИ рекомендует не арендовать SIEMы (например, в рамках аутсорсингового SOC), а покупать свой и ставить его себе на баланс, и хранить логи у себя локально.

Вот такие новости. Может кому-то будет что-то внове.

Подробнее…

AT&T покупает AlienVault

10 июля американский провайдер AT&T объявил о планах по приобретению компании AlienVault, известного разработчика SIEM (коммерческого USM и бесплатного OSSIM) и поставщика Threat Intelligence. Размер сделки не разглашается.

Подробнее…

SIGMA - новый язык описания индикаторов компрометации для SIEM

Пока все ждут от ФСБ документов по ГосСОПКЕ и, в частности, по правилам и форматам передачи данных об инцидентах, я бы хотел поговорить об одном из недавно появившихся стандартов описания индикаторов компрометации. Но сначала вопрос. Какие языки для описания индикаторов компрометации / сигнатур / шаблонов для файловых атак вы знаете? Первое, что приходит на ум, - это YARA. А для сетевых атак? Правильно, Snort. А что для системных событий? И вот тут мы пасуем. Наши SIEM просто берут данные в форматах syslog или Event Log и анализируют по сути сырые данные. Существует ли язык, который мог бы помогать SIEM анализировать события?

Оказывается да. Это SIGMA, язык появившийся год назад, который позволяет легко описывать события для анализа в SIEM и делиться ими между различными организациями в рамках информационного обмена. По мере получения популярности SIGMA для логов должен стать тем же, что YARA для файлов и Snort для сетевого трафика.

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

title: Очистка EventLog
description: один из логов Windows очищается
author: Florian Roth
logsource:
  product: windows
detection:
  selection:
    EventLog: System
    EventID: 104
  condition: selection
falsepositives:
    - Unknown
level: medium

А вот так выглядит описание сценария, когда офисный документ запускает интерпретатор командной строки cmd.exe:

title: Макрос в офисном документе запускает cmd.exe
status: экспериментальный
description: правило для Windows
references: - https://www.hybrid-analysis.com
author: Florian Roth
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 1
    ParentImage:
      - '*\WINDOWRD.EXE'
      - '*\EXCEL.EXE'
    Image: '*\cmd.exe'
  condition: selection
fields:
    - CommandLine
    - ParentCommandLine

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

Наконец, вот так описывается один из тригеров DragonFly:

action: global
title: CrackMapExecWin
description: Обнаружение активности CrackMapExecWin как описывает NCSC
status: экспериментальный
references: - https://www.ncsc.gov.uk/alerts/hostile-state-actors-compromising-uk-organisations-focus-engineering-and-industrial-control
author: Markus Neis
detection:
  condition: 1 of them
falsepositives: - None
level: critical
--- # Сначала анализируем Windows Audit Log 
logsource:
  product: windows
  service: security
  description: 'Requirements: Audit Policy : Detailed Tracking > Audit Process creation, Group Policy : Administrative Templates\System\Audit Process Creation'
detection:
  selection1:
  # Does not require group policy 'Audit Process Creation' > Include command line in process creation events
     EventID: 4688 
     NewProcessName: - '*\crackmapexec.exe' 
--- 
# Затем анализируем Sysmon 
logsource:
  product: windows 
  service: sysmon 
detection: 
  selection1: 
  # Does not require group policy 'Audit Process Creation' > Include command line in process creation events 
   EventID: 1 
   Image: 
     - '*\crackmapexec.exe'

Достаточно несложно и эффективно. Однако есть один нюанс - нужны средства автоматизации для работы со сценариями SIGMA. Пока это делает только MISP (для обмена индикаторами компрометации) и Splunk через соответствующий App - TA-Sigma-Searches. Также SIGMA поддерживает Elastic и kibana. У автора SIGMA были планы по интеграции своего языка в различные SIEM (например, ArcSight и QRadar), но пока они не реализованы. Может отечественные производители будут первыми?

ЗЫ. Кстати. Вы слышали что-нибудь про JA3, метод описания цифровых отпечатков для SSL/TLS-клиентов, который может использоваться в рамках Threat Intelligence? Вот так выглядит отпечаток JA3 для Dridex - 74927e242d6c3febf8cb9cab10a7f889.

Подробнее…

Thoma Bravo покупает контрольный пакет LogRhythm

31 мая инвестиционный фонд Thoma Bravo, известный своими поглощениями на ниве ИБ, объявил о подписании соглашения о покупке контрольного пакета акций SIEM-производителя LogRhythm. Остальные детали сделки не разглашаются.

Подробнее…

Splunk покупает Phantom Cyber

Splunk 27-го февраля объявил о подписании соглашения о покупке Phantom Cyber, компании, которая работает в сегменте SOAR по версии Gartner, и занимается оркестрацией и автоматизацией вопросов ИБ. Размер сделаки составл 350 миллионов долларов США.

Подробнее…

Дашборды по ИБ для руководства: КТО, ЧТО и КАКОЕ

Достаточно часто сталкиваюсь с вопросом, который звучит "Как должен выглядеть отчет/дашбоард по ИБ для руководства?" Это немного другая сторона медали, связанной с выходом ИБ на уровень бизнеса, о которой я достаточно часто говорю в последние годы (хотя и не так часто как хотелось бы). Многие вопрошающие считают, что существует некий магический пример отчета или дашборда (разница между этими понятиями не столь большая), который можно скопировать и наступит счастье в общении с руководством, которое сразу должно понять, что безопасность не зря ест свой хлеб и не зря на нее тратят десятки и сотни миллионов рублей. Нередко заданный в начале вопрос сопровождается дополнением - "У нас уже есть SIEM/SOC и нам осталось только правильно расположить виджеты, чтобы получить нужный результат. У вас же в Cisco это сделано. Покажите как?"

Вот об этой проблеме мы сегодня поговорим, но как это часто бывает - никакой серебряной пули не существует и никакого магического отчета нет. Все ситуации уникальны, а потому уникальны будут и дашборды/отчеты, которые могут показать эффективность (или неэффективность) работы службы ИБ или отдельных ее подразделений. Но это не значит, что нет общих рецептов, которым надо следовать, чтобы добиться нужного результата. Для начала стоит понять, в чем корень проблем с визуализацией бизнес-представления ИБ? В разном восприятии. Человек, готовящий отчет (предположим, что он понимает, чем он занимается), слишком погружен в детали. Он считает все данные в отчете или на дашборде важными. Еще бы - он ведь их сам собирал по крупицам и поэтому не может отказаться от чего-то, на что он, возможно, потратил не одну неделю. Руководителю (и не важно какого уровня), в отличие от аналитика, нужны не детали, а общая картина, наглядность. Аналитика волнуют ответы на вопросы классической игры "Что? Где? Когда?", а руководителю нужны ответы на вопросы "Что будет? Что делать?" Отсюда и все проблемы, для устранения которых надо ответить на ряд простых на первый взгляд вопросов, а точнее просто произвести декомпозицию исходной задачи.

Первое с чего стоит начать, с ответа на вопрос "КТО?", который разбивается на две составные части - кто вы и кто ваша целевая аудитория? Первая часть не столь актуальна в небольших организациях, в которых вся ИБ - это 2-5 человек без жесткой иерархии подчинения. В такой ситуации совсем не важно, кто вы; главное, что вы занимаетесь ИБ и вам поручили подготовить отчет или сделать дашборд для руководства. В крупных организациях, в которых служба ИБ насчитывает сотни или даже тысячи человек эта часть вопросам становится уже гораздо важнее. Врядли руководитель отдела СКЗИ или антифрода сможет адекватно подготовить дашборд по деятельности всей службы ИБ - у него своей фронт работ, по которому он и может говорить предметно. Поэтому если вам поручили задачу сделать отчет/дашборд "обо всем" лучше сразу расставить все точки над i. В противном случае вы точно окажетесь виноватым.

Вот вторая часть вопроса "КТО" гораздо важнее. Кто ваш заказчик? Кто будет смотреть на ваш отчет или дашборд? CISO? CSO? CEO? COO? CFO? Иной CxO? С CISO ситуация не так просто как кажется на первый взгляд. Это в небольших организациях руководитель ИБ обычно в курсе всего, что творится у его подчиненных. В крупных, уровня Газпрома или РЖД или Сбербанка, сложно ожидать, что CISO знает все, что находится на 2-3-4 уровня иерархии ниже. Это физически невозможно. Поэтому, получая задачу подготовки дашборда или отчета от своего руководителя ИБ все-таки уточните задачу и получите как можно больше деталей. Мне доводилось слышать такую постановку задачу "Сделайте мне красиво, понятно и чтобы я мог перед предправления отчитаться". Или вот такую: "Вы сами должны знать, что мне надо, я же не зря вам плачу зарплату". Увы, в последних двух случаях вероятность сделать что-то устраивающее вашего "рукамиводителя" невысока. При столь нечеткой постановке задачи это равносильно "пойди туда, не знаю куда, принеси то, не знаю что".

Второй важнейший вопрос - ЧТО. Что нужно вашей целевой аудитории? Какие ключевые показатели ей необходимо показать? Ответ на этот вопрос зависит от ответов на предыдущий вопрос. Понятно, что финансовому директору не интересно число уязвимостей в Web-сайте компании (да и никому не интересно). И среднее время реагирования на инциденты (кстати, среднее арифметическое или медианное?) тоже неинтересно. И эффективность источников Threat Intelligence тоже. Все это внутренняя кухня ИБ, которая в лучшем случае интересна CISO.

Для ответа на вопрос ЧТО, вы должны ответить на третий вопрос - КАКОЕ решение должна принять ваша целевая аудитория? Запустить проект по повышению осведомленности сотрудников? Увеличить инвестиции в проект по приведению себя в соответствие с PCI DSS или 382-П? Инвестировать в защиту Web-сайта от прикладных атак? Обратиться к аутсорсингу ИБ вместо содержания собственной службы ИБ? Увы. Все эти решения не имеют никакого отношения к бизнесу. Это в лучшем случае уровень CISO. Бизнес волнуют совершенно иные вещи и вопросы. Какой канал лучше позволяет привлекать клиентов? Какие регионы/города России наиболее перспективны для географической экспансии? Как снизить издержки и повысить доходность? Как поднять лояльность сотрудников/клиентов/партнеров? Как снизить регулятивные риски? Могут ли ваши дашборды/отчеты помочь ответить на эти вопросы? Скорее всего нет. Но это не значит, что вам не надо общаться с бизнесом и пытаться понять его чаяния. Именно о том, что нужно бизнесу в контексте ИБ и как ИБ влиться в общие бизнес-процессы, будет посвящено два мастер-класса на Магнитогорском форуме по банковской ИБ, которые буду вести я и Дмитрий Мананников уже в следующий вторник. Это важнейшая часть работы ИБ (общение с бизнесом), но выходящая за рамки сегодняшней заметки. В любом случае, независимо от уровня вашей целевой аудитории (CEO или CISO) вы должны понимать, какое решение она должна принять. Отсюда вы поймете, что ей нужно для принятия решения и какие данные вам помогут облегчить принятие решения.

Например, перед вашим CISO стоит задача - искать ли новые источники Threat Intelligence или оставить используемые сейчас? Чтобы принять решение ему нужно ответить на ряд вопросов:

• Какое соотношение получаемых извне IoC с теми, которые применялись в компании за отчетный период? Ответ на этот вопрос помогает понять, насколько вообще внешние источники помогают вашей организации в обнаружении атак и инцидентов?
• Какие источники TI наиболее релевантны для организации? Это предыдущий показатель применительно к каждому внешнему источнику.
• Число индикаторов, полученных от внешнего источника TI с учетом их полезности для организации (полезно при принятии финансовых решений о продлении контракта на TI). 
• Соотношение количества угроз, пришедших по каналам TI, и не обнаруженных за счет внутренних возможностей (фишинговые сайты, украденные логины/пароли, сайты-клоны и т.п.).
• Какое количество получаемых извне IoC применялось в компании? Может оказаться вообще, что индикаторы компрометации вы получаете, но не используете, потому что руки не доходят или не знаете, как автоматизировать процесс интеграции внешних источников с вашими средствами защиты/анализа.

Кстати, при оценке деятельности подразделения Threat Intelligence с точки зрения руководителя ИБ, было бы неплохо задать следующие вопросы:

• Сколько IoC, сформированных службой TI, помогло отразить инциденты в организации (например, на МСЭ, IPS, рутерах и т.п.)?
• Сколько playbook было создано/обновлено и использовано группой по реагированию на инциденты на основе IoC, сформированных службой TI? 
• Распределение полученных IoC по типам и соотношение их с типами угроз внутри организации.
• Динамика снижения числа ложных срабатываний средств защиты после обогащения сигналов тревоги данными от службы TI.
• Снижение времени (ускорение) на расследование инцидента и реагирование на него за счет обогащения данных об инцидентах данными от службы TI.
• Соотношение количества обнаруженных угроз средствами защиты организации с данными от службы TI и без них (например, голый IDS в сравнении с IDS + TI или IDS + TI + SIEM).
• Количество самостоятельно обнаруженных и отреверсенных вредоносов по сравнению с традиционными антивирусными программами (если это функция TI).
• Количество подготовленных бюллетеней по акторам/угрозам/кампаниям, которые имели отношение к предприятию; особенно тех бюллетеней, которые описывают угрозы, направленные именно на само предприятие, а не веерные угрозы.
• Количество подготовленных бюллетеней, направленных в ФинЦЕРТ/ГосСОПКУ/иным внешним лицам (если стоит задача awareness и обучения отрасли/индустрии).
• Участие в стандартизации вопросов обмена информацией об угрозах (если такая тема актуальна для организации).

Ответив на эти три вопроса - КТО ваша целевая аудитория, ЧТО им нужно и КАКОЕ решение они должны принять - вы решите, нет, не 50%, а 80% задачи по созданию правильного дашборда/отчета по ИБ. Про остальные 20% мы поговорим уже завтра.

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

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

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

ЗЫ. Когда писал заметку, думал нашпиговать ее красивыми примерами дашбордов, но уже в процесс написания отказался от этой идеи. Правильные примеры явяются таковыми только в конкретной ситуации, в конкретной организации, после ответа на поставленные вопросы. Они могут не копироваться в других компаниях при других условиях ункционирования службы ИБ. Да и, положа руку на сердце, таких примеров-то и немного. А вот дурацких примеров в Интернете полно - достаточно ввести в Гугле поиск картинка по ключевым словам report|dashboard security|cybersecurity и вы получили красивые, но абсолютно бесполезные в реальной жизни диаграммы, графики, светофоры, индикаторы и т.п. 

Подробнее…

Обзор конференции ЦБИ по мониторингу ИБ

Неделя с 16 ноября прошла под знаком мониторинга ИБ. Сначала пошло камерное мероприятие Гартнера, на котором Антон Чувакин рассказывал про системы поведенческой аналитики (UEBA), которые по версии этой аналитической компании относятся к набору обязательных для SOCов технологий. Спустя несколько дней прошел уже четвертый (третий в России) SOC Forum, который собрал какое-то неимоверное количество народа и поднял несколько очень важных тем, которым я еще посвящу несколько заметок. Но сейчас я бы хотел коснуться другого мероприятия, которое прошло накануне SOC Forum и которое было организовано ЦБИ.

Когда меня на него звали, я был достаточно скептичен. Абсолютно новое мероприятие, проводимое вендором, который запускал новый продукт (Neurodat SIEM), да еще за день до более известного SOC Forum... Но я ошибался. Во-первых, представители ЦБИ практически ни разу не прорекламировали свое решение по мониторингу ИБ. Другие выступающие иногда не стеснялись рекламировать свою компанию и свои продукты (несмотря на запрет от организаторов), а ЦБИ держал марку. Очень достойно это выглядело! Во-вторых, вместо предполагаемых ста участников зарегистрировалось 500, а пришло более 300! 300 человек, которым была интересна тема SIEM и мониторинга ИБ настолько, что они отдали ей предпочтение вместо SOC Forum, который должен был пройти на следующий день. И это лишний раз подтверждает мой давно высказанный тезис, что нам не хватает фокусных мероприятий, а не конференций "обо всем и ни о чем". В итоге мероприятие получилось очень насыщенным и интересным.

Хотя надо признать, что местами некоторые доклады выглядели немного по-детски что ли. Я уже как-то писал, что свою первую SIEM я внедрял в 99-м году, в одном из киевских банков. Тогда, почти 20 лет назад, уже активно обсуждались вопросы по источникам данных, корреляции событий, log management и другим базовым вопросам при создании, внедрении и эксплуатации систем мониторинга ИБ. И, что местами выглядело странно, сейчас вновь обсуждаются эти же вопросы, а ответы на них преподносятся как открытия, достойные Нобелевской премии. Но многие из этих проблем и задач известны давно и на них уже даны ответы. Почему надо изобретать велосипед?

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

• Почему сейчас все заговорили про мониторинг? Я этим вопросом задавался на прошлогоднем круглом столе по SIEM и продолжаю задаваться сейчас. Вроде требования по мониторингу у ФСТЭК появились еще в 2013-м году (блок требований РСБ). У ЦБ в СТО БР они тоже были давно. Что послужило причиной такого хайпа вокруг мониторинга? ФЗ-187 о безопасности критической инфраструктуры? Тема SOCов, которая тоже высосана из пальца? Возможно. В любом случае такое внимание к этой теме вызывает вопросы, особенно на фоне отсутствия сколь-нибудь серьезно выстроенной инфраструктуры ИБ у многих заказчиков, которые фокусируются преимущественно на периметре и установке антивирусов на ПК. Про это, кстати, говорил и Виталий Лютиков из ФСТЭК, повторяя тезисы, которые он озвучивал еще 2 года назад на первом SOC Forum. Зачем нужна SIEM или SOC, если в организации нет достаточного количества средств защиты информации? Почему все так ринулись в мониторинг, не имея того, что мониторить? Риторический вопрос, который, однако, заставляет задуматься, а реально ли нужно начинать строить систему защиты с SIEM? Решит ли она все проблемы?

• Тема SOCов очень модная и про нее говорят многие, активно выбирая или предлагая услуги по мониторингу ИБ в контексте ФЗ-187 (почему это глупость, я напишу в заметках про SOC Forum). Но многие забывают, что SIEM - это одна из основ SOCа. Первый SOC Forum был очень сильно ориентирован на SIEM-тематику, но потом как-то эту тему замылили, решив, что все настолько продвинуты, что можно говорить уже только о центрах и реагировании на инциденты. Увы. Часть обсуждаемых на конференции ЦБИ тем, показала, что многие просто не готовы к SIEM. Кто-то не имеет выстроенного процесса log management. Кто-то внедрив SIEM, забывает про внедрение системы единого времени (даже на базе NTP, не говоря уже о GPS или более патриотичном ГЛОНАСС). Кто-то забывает учесть разные часовые пояса, в которых находится система мониторинга и системы, которые мониторятся. Кто-то, говоря об источниках данных для SIEM, говорит только о логах, напрочь забывая про потоки (NetFlow) и поведение пользователей. Кто-то, заявляя о захвате/сборе всех данных в свои SIEMы, не может ответить на вопрос о последующей доступности контролируемых устройств в такой ситуации (нагрузка может быть настолько большой, что контролируемый узел просто уйдет в даун). Кто-то внедряет вторую SIEM только для целей ИБ, не умея или не имея возможности договориться с ИТ, которые уже внедрили другую систему мониторинга для своих целей. Вообще таких вопросов, показывающих уровень зрелости заказчиков применительно к SIEM, было много.

• На вопрос некоторым заказчикам, что их не устраивает в отечественных средствах защиты для целей интеграции с SIEM или SOC, услышал ответ, что "закрытость". Отсутствие сколь-нибудь развитых API, позволяющих интегрировать отечественные средства ИБ с системами мониторинга ИБ. А ведь по версии Gartner, которая опросила большое количество заказчиков по всему мира, именно открытый API и доступ к логам являются сегодня одним из обязательных признаков современного ИБ-вендора. 
• Очень забавной выглядела неразбериха с термином "мониторинг". Тут и докладчики, и заказчики были кто во что горазд, что показывает совершенно разный взгляд и уровень зрелости на данный вопрос. Например, Владимир Голованов из "Кристалла" рассматривал мониторинг не с точки зрения только сбора событий от средств защиты, как это делало большинство. Поэтому упоминание стандартов уровня ISO/IEC 27004 или ISO/IEC 15939 в его выступлении выглядело вполне логичным и понятным, хотя в соцсетях такая трактовка "мониторинга" и вызвала у некоторых экспертов вопросы.

         

• Кто-то опускался на уровень отдельных программ и говорил, что применение SysMon или RegMon или ProcMon от Sysinternal - это тоже мониторинг ИБ (и с этим сложно спорить). Кто-то приравнивал мониторинг к SOCу, а кто-то к SIEM. Разработчики DLP рассматривали мониторинг в контексте обнаружения утечек, что, наверное, тоже верно, но скорее всего расходилось с первоначальной идеей организаторов мероприятия. Разброс точек зрения был колоссальный, что в очередной раз подняло вопрос о необходимости унификации понятий перед началом конференции, чтобы иметь некую единую точку отсчета. Это позволит задать некую общую границу, ниже которой опускаться участники не будут и будут оперировать схожими точками зрения при обсуждении и выстраивании своих докладов.

• Немного островатой оказалась дискуссия на тему поддержки русского языка в системах мониторинга. Я задал аудитории вопрос, кому является критически необходимой поддержка русского языка не столько в интерфейсе, сколько в генерируемых отчетах и описаниях атак. Поднялась всего одна (!) рука. Участник, ее поднявший, ответил, что его заказчики - это оборонка и там не все (мягко говоря) знают английский, чтобы работать с зарубежными SIEM-системами. Выступавший в модерируемой мной секции представитель Ростеха (а у них тоже полно оборонки) высказал противоположную точку зрения, сказав, что без знания английского языка специалист по ИБ не может считаться таковым (немного утрирую) и в Ростехе не является препятствием, что средства защиты и мониторинга "говорят" на языке супостатов. Дальше один из представителей заказчиков высказал "ожидаемую" мысль, что вообще-то в России есть ГОСТы 34-й и 19-й серии и они обязывают создавать программные продукты (и документацию к ним) на государственном языке, то есть на русском. На этом дискуссия и закончилась, так как она грозила перерости в склоку :-)
• Поговорили о правилах корреляции, что бывает нечасто на таких мероприятиях, больше "продающих" коробки, чем рассказывающих о том, как самостоятельно настраивать систему сопоставления различных событий безопасности из разных источников.

• Представителю Инфовотча задал вопрос, который парой дней ранее обсуждася в Фейсбуке - зачем интегрировать DLP и SIEM? Четкого ответа так и не получил. Единственное, что было озвучено, так это вырожденный кейс от одного из заказчиков, который требовал блокировать в СКУД пропуск сотрудника, замеченного в утечке информации (чтобы не успел убежать от карающей длани службы безопасности).
• В очередной раз подняли разговор, что регулятор должен более активно участвовать в установлении требований к мониторингу ИБ. Тут вам и стандарты по формату событий ИБ, и требования к SIEM, и требования к управлению инцидентами. И все, чтобы обязательно было :-) Регулятор в лице ФСТЭК в очередной раз высказал скепсис в отношении таких желаний. Я лично тоже не понимаю этого стремления вендоров получить от регулятора "скрижали", соответствие которым позволит улучшить продажи своих продуктов. Попытки разработать стандарты обмена событиями ИБ в мире предпринимались не раз, но успехом они так и не увенчались. Всегда (и часто быстрее выхода стандартов) появляется новый класс продуктов, который имеет поля, отсутствующие стандарты. И что теперь, переписывать стандарты при появлении каждого нового средства защиты? Отсюда и небольшое стремление к стандартизации, которая не успевает за динамичным рынком ИБ. Да, есть некоторые стандарты де-факто - syslog (хотя и он существует в куче разных модификаций), STIX/TAXII, NetFlow и т.п. Но они все "зарубежные" и я иногда слышу заявления, что нельзя использовать стандарты потенциального врага (!). Тогда получается что, разработка своего, чтобы затем писать за дополнительные деньги коннекторы к нему, а потом еще и шлюзы-трансляторы из отечественного стандарта в зарубежные? В целом, я достаточно скептично отношусь к идее переложить на регулятора этот вопрос там, где это не нужно (в ГосСОПКЕ нужно, а в требованиях к SIEM или SOC нет).

• Когда я в первый раз писал о конференции, я упоминал, что она является не только практической, но и научной, что выделяет ее на фоне того же SOC Forum или мероприятий Gartner. И наука действительно была представлена на конференции ЦБИ в лице представителей питерского СПИИРАН, которые делали доклады про перспективы корреляции событий ИБ и прогностические модели, которые могли бы быть применены при мониторинге ИБ. Первый доклад делал Игорь Котенко, который поделился своим взглядом на SIEMы нового поколения (и как я понимаю, разработанные подходы могут быть использованы в отечественных разработках), на подходы к проактивному мониторингу, основанному на ретроспективной ИБ, на анализе графов атак и на автоматизации выработки контрмер для систем мониторинга (что само по себе является проблемой). Что характерно, вместо чисто научных формул, которые часто бывает сложно понять на ходу, СПИИРАН даже создал программный комплекс, реализующий разработанную методику.

• При этом данный комплекс является достаточно прогрессивным, использующим различные технологии анализа и корреляции данных, в том числе построенные и на Больших данных. Кстати, на следующий день, на модерируемой мной секции “Future SOC”, выступал Сергей Рублев из ГК “Инфосекьюритисервис”, который рассказывал о практическом опыте построения собственного SOC на базе как раз тех технологий, которые были упомянуты Игорем Котенко в своем докладе (Spark, Scala и др.)

• Во втором докладе СПИИРАН речь шла о более высоких материях - о применении методов анализа рисков на базе стозастических моделей к системам мониторинга ИБ в реальном времени, что позволяет даже в ряде прогнозировать какие-то новые события безопасности, оценивать вероятность тех или иных угроз и т.п.

•  Но этот доклад от СПИИРАН оказалось достаточно тяжело слушать и воспринимать. Чего только стоит такая фраза “Семантическая связь между событиями безопасности на физическом уровне и конечными показателями безопасности, в которых может быть она выражена содержательно, не достаточно определена“. Что имелось ввиду, фиг разберешь…

• Наконец, в заключение был интересный доклад от Андрея Дугина из МТС, который поделился опытом снижение нагрузки на операторов SOC, которые были разбиты на 3 части - технические, процессные и организационные.

В заключение хочу еще раз повторить, что мероприятие ЦБИ мне понравилось - свежая для России тема, большой интерес, интересные доклады. Кроме того, ЦБИ выделился и еще одной темой - они открыли программу технологического сотрудничества и объявили о выделении грантов на разработки в области мониторинга ИБ. Вообще, это интересная тема, которая показывает, что компания не варится в своем соку и готова развиваться. Выделено три гранта - совместно с Microsoft Rus и SolidLab на разработку алгоритмов идентификации действий пользователей. Что же мне это напоминает? А, точно, UEBA :-) И хотя про поведенческую аналитику на конференции почти никто не говорил, данные гранты ЦБИ говорят, что они решили пойти по пути многих вендоров SIEM, которые оснащают свои системы сбора и анализа логов и иных источников информации новым модным инструментарием по контролю действий пользователей. Сейчас в этом же направлении идут еще разработчики как минимум трех отечественных и псевдо-отечественных DLP. Ждем в следующем году UEBA Forum? 

Год назад, на PHDays, где я модерировал круглый стол по SIEM, я готовил список вопросов к вендорам. Надо признать, что эти вопросы до сих пор остаются актуальными для любого производителя - отечественного или зарубежного. Стоит их задать либо поставщику, либо самому себе, чтобы понять, так ли нужна вам SIEM и нужна ли вам именно эта SIEM, которую вам предлагают. Разброс мнений, точек зрения и подходов, прозвучавших на конференции ЦБИ, показывает, что тема до сих пор актуальна и еще долго будет мучить специалистов по ИБ, которые будут пытаться найти ответы на интересующие их вопросы (тут, главное, не замыкаться на себе, а смотреть шире, в том числе и на зарубежный опыт). И это, кстати, говорит, что тема поднятая ЦБИ "на флаг" своей конференции, достаточно благодарна для того, чтобы в следующем году провести второй "SIEM Forum", а потом и третий :-) Тем более, что у Neurodat SIEM вполне интересные планы развития:

ЗЫ. На самом деле осенью в Москве было еще два мероприятия по мониторингу - традиционные VB-Trend от VolgaBlob и конференция Splunk, но я на них не смог присутствовать, поэтому и писать про них не буду.

Подробнее…

Управление логами - фундамент любой SIEM, в котором часто зияют прорехи

Уже совсем скоро пройдет конференция ЦБИ "Мониторинг ИБ: проблемы построения и эксплуатации", на которой я буду вести секцию про полноту и "доступность" источников информации, которые подключаются к SIEM, а потом на их основе работает SOC и принимаются решения о наличии или отсутствии угроз. По сути именно от того, насколько выстроена работа с источниками зависит эффективность всей системы кибербезопасности.

Давайте вспомним вот эту иллюстрацию двухнедельной давности:

В ней атомарным элементом считаются логи. Все логи сразу. Многие компании, да и производители SIEM, могут сказать, что уже они то выстроили достаточно зрелый, может быть даже на пятом уровне, процесс управления логами. И в принципе, не сильно задумываясь, мы можем с ними согласиться, так как о том, как работать с логами, как одним из источников информации ИБ, говорят уже много лет и даже десятилетий. Первые хостовые IDS, появившиеся в начале 80-х годов, как раз опирались в своей работе на данные из журналов регистрации. Можно предположить, что уж с логами-то за почти 40 лет у нас научились работать. Но история умеет преподносить сюрпризы. Вот так выглядит слайд из вчерашней презентации Антона Чувакина из Gartner, который рассказывал про технологию пользовательской поведенческой аналитики (UEBA):

Обратите внимания на первый пункт в списке основных проблем при внедрении и использовании UEBA - сбор данных, их доступность и качество. И это спустя 40 лет после появления первых хостовых IDS и 20 лет после появления первых SIEM. А ведь SIEM, которые в принципе должны уметь работать с источниками данных, потом отдают информацию в UEBA, а также иные системы аналитики ИБ.

Но если источники данных плохие, то и все принятые на их основе решения тоже можно поставить под сомнение. В "лучшем" случае мы просто будем пропускать атаки и инциденты, а в худшем - пойдем по неверному пути, принимая неверные решения, тратя ресурсы не на то.

Какие проблемы можно выделить при работе с источниками информации? Их немало:

• Множество источников. Это примерно как с DLP, которые вроде и борются с утечками, но когда начинаешь копать, то оказывается, что 2/3 коммуникационных каналов в вашей компании они вообще не отслеживают.
• Противоречивость данных. Например, в одном источнике у вас указан IP-адрес, но нет, допустим, имени пользователя, а в другом наоборот - имя пользователя есть, а IP-адреса нет. И как связать такие данные между собой? А вот еще простой пример. В одном логе у вас время события записано в формате DD-MMM-YYYY, а в другом - MMDDYYYY. Хорошо, если система управления логами, приводит все к единому формату, а если нет?
• Противоречивость временных меток. Ну тут все понятно и дело даже не в разных часовых поясах, в которых могли происходить события, а в отсутствии системы синхронизации, что может привести, например, к ситуации, когда в SIEM числится, что события А произошло после события Б через 66 секунд, а на самом деле оно произошло до - на 15 секунд.
• Множество разных форматов. XML, JSON, syslog, CSV (с разделениями табуляцией или запятыми), SNMP, REST, базы данных и др.
• Незащищенность логов. Кто мешает злоумышленнику удалить какие-то записи из источника информации или, что еще хуже, подменить их, создавая и поддерживая ложное чувство защищенности? А что с доступностью источников информации?
• Способы доступа к источникам информации. Часто в описании SIEM/LM написано, что они поддерживают потоковые данные из syslog (а Netflow как, кстати?) и удаленный доступ к логам через API и удаленный доступ. А что с агентами? Некоторые данные без агентов не вытащить и не проанализировать.
• Неструктурированные данные. Правда, это не совсем задача SIEM или LM, но без них сегодня сложно проводить серьезную аналитику и принимать решения и поэтому стоит задуматься об этой теме заранее.
• Отсутствие стандартов или отказ от поддержки вендорами уже существующих стандартов. RDEP, CEE, SDEE, IODEF, RID, SecDEF... Их поддерживают средства защиты или системы анализа?

Разумеется, все эти проблемы могут быть решены, но об этом все-таки лучше поинтересоваться у производителя SIEM/UEBA/NTA/IDS и других ИБ-решений. Ну а если вы пишете систему защиты/аналитики сами, то просто подумайте, как вы будете решать эти проблемы? Вот именно этим вопросам и будет посвящена секция на конференции ЦБИ, которую я модерирую. Выступать в ней будут представители:

• ЦБИ, которые недавно выпустили свою SIEM Neurodat,
• НТЦ Вулкан, которые активно развивают направление SIEM в своих проектах,
• Infowatch
• Код безопасности
• РТ-Информ
• R-Vision

и их ждут непростые вопросы от меня :-)

Подробнее…