Успешное внедрение SIEM. Часть 1

    Всем привет.

    Так получилось, что последние несколько лет провел в процессе внедрения SIEM Arcsight ESM в одном крупном телекоммуникационном провайдере. Считаю, что сделал это весьма успешно и в итоге ушел на несколько другую стезю, т.к. уперся в некоторый потолок, который есть в России в целом по направлению безопасности. Для того, чтобы не сложилось ложного понимания у читателя уточню, что я работал именно внутри компании, а не на проекте от системного интегратора и SIEM использовалась исключительно для внутренних нужд, а не для создания коммерческого Security Operation Center (далее SOC). В целом тематика внедрения и использования SIEM освещена слабо, да и в целом те инсталляции, которые я видел обычно не приносили достаточной эффективности тем кто ее внедрял. Мне с коллегами на мой взгляд удалось реализовать свой собственный SOC ядром, которого является SIEM, приносящий огромную пользу не только отделу ИБ, но и другим отделам в частности и всей компании в целом, включая руководство.

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

    Поехали.

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

    Перейдем к архитектуре SIEM. Первое, что тут нужно понимать, что неважно какую SIEM вы внедряете и сколько серверов для нее нужно и какие требования к железу, в зависимости от SIEM может требоваться разное число серверов. Так например с Arcsight мы использовали отдельные сервера, на которые ставили софт для сбора логов, а база данных и коррелятор логов были на других серверах. Основным же моментом в архитектуре SIEM является система хранения данных (СХД). Что тут сразу хочу сказать, что ни один интегратор не в силах посчитать сколько у вас будет реально логов, никому тут не верьте, считайте сами, смотрите ограничения SIEM на максимальный размер СХД и пляшите от него. Здесь чем больше места тем лучше, так же нужны быстрые диски, желательно прямое соединение СХД с SIEM. Так же обязательно подключение к системе резервного копирования (СРК). Оптимальным на мой взгляд временем хранения логов на горячую является один месяц, хранение на СРК минимум полгода. Основные проблемы, которые могут тут вас ожидать – это упирание в скорость чтения и записи, которые будут сильно отражаться на том на сколько быстро вы сможете выгрузить нужные вам логи и при работе нескольких людей с SIEM. Поэтому чем быстрее будет СХД тем лучше. Вот так вот плавно мы подошли к второму вопросу первой части статьи, а именно к управлению логами.

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

    Особенности получения логов – основной особенностью является то, что нужно планировать нагрузку на сеть, особенно при использовании SYSLOG, т.к. возможен спам и нужно совместно с сетевиками продумать наилучший вариант отправки логов.

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

    Агрегация событий – очень интересный и полезный момент (не все SIEM поддерживают эту функцию), который позволяет сократить количество мусора в логах. Агрегация представляет собой схлопование нескольких одинаковых событий в одно, к примеру мы имеем 30 обращений за 30 секунд с одного IP адреса на наш сервер, которые зафиксировал наш пограничный межсетевой экран, в базе данных это будет 30 строк, агрегация нужна, чтобы сделать из этих 30 событий всего лишь одно. Агрегация наиболее эффективна для логов межсетевых экранов, netflow, IDS/IPS, веб серверов.

    Фильтрация событий – выбрасываем то, что не нужно или оставляем только то, что нужно. Очень полезная штука особенно для логов с операционных систем, антивирусов, IDS/IPS. Что наиболее эффективно делать, чтобы определить, что событие вам неинтересно. Нужно написать правило, которое будет записывать в лист ( в терминологии Arcsight, не знаю есть ли у конкурентов такая функция) или построить отчет о всех событиях, которые были в течении недели с каждого источника и анализировать его с точки зрения информативности. Результатом этого анализа является изменение уровня логирования на источнике событий, либо настройка фильтров на сборщике логов SIEM. Забегая вперед скажу, что логи межсетевых экранов лучше не зафильтровывать, т.к. они очень полезны при расследовании инцидентов.

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

    Приоритезация – выставление приоритета события в рамках SIEM. К примеру нам пришло событие с severity CRIT, но мы знаем что для ИБ – это не критикал и ставим ему INFO.

    Перейдем немного к практике и поговорим о самых информативных источниках логов.

    Моим безусловным лидером являются сканеры уязвимостей, которые позволяют осуществить инвентаризацию, перечень открытых портов, сервисов и уязвимостей на сети. Здесь я бы рекомендовал использовать сразу несколько инструментов и собирать все в листы, либо отчеты, а затем уже привязывать все это дело к ITIL, т.е. создавать внутренние тикеты и закрывать проблемы согласно внутренним политикам ИБ. Собственно SIEM здесь является инструментом, на который все сканеры скинули информацию и аналитик уже ее анализирует просматривая все отчеты только в одном месте. Так же сюда я бы отнес самописные скрипты, которые могут собирать информацию из DNSBL, C&C серверах из интернета.

    Второе место для меня занимают межсетевые экраны, netflow, VPN шлюза и IPS/IDS/WAF, которые позволяют определить всевозможные сканирования, попытки DDoS-атак, другие нарушения сетевой безопасности в т.ч. внутренними пользователями и оптимизировать работу средств защиты.

    Третье место – операционные системы, с логов операционных систем можно понять, что нас взломали или админ шалит.

    Четвертое место – базы данных, по их запросам можно так же увидеть попытки увести от нас важную информацию.

    Пятое место – антивирусы.

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

    Подробнее
    Реклама

    Комментарии 6

      0
      Можно пару вопросов) Очень интересная тема.

      Вы все логи в сием шлете? Не делали промежуточных сборщиков на чем-нибудь бесплатном (logshash) c предварительной фильтрацией и отправкой на сием только важных (некий первый, грубый уровень фильтрации)? Очень уж дорогой каждый EPS.

      В чем инвентаризируете инфраструктуру — где описываете что за каким IP закреплено, тип сервера, что за система что за сервисы, критичность — для дальнейшей загрузки в сием и корреляции?
      Что предварительно сделали с инфраструктурой перед внедрением сиемки (инвентаризация, политики и проч) и по ходу развития?

      Вообще у вас насколько большая инфраструктура, которую мониторите, какой ее состав (больше маршрутизаторы/ком. обрудование или информсистемы), и какой поток EPS обрабатывает SIEM? И во сколько все это обошлось (хотя бы порядок цен)
        0
        Да легко:) Затем и пишу, чтобы рассказать и подсказать.
        Т.к. использовали Arcsight, то промежуточные сборщики — это коннекторы, функции у них те, которые я описал в статье (нормализация, фильтрация и т.п.), собственно все SIEM имеют либо отдельные сборщики, либо встроенные. Я считаю, что Arcsight в части сбора логов идеален, т.к. обладает очень гибкими механизмами. Если интересно будет, то могу написать отдельные статьи про арксайт и возможности его компонентов.
        Коннектор стоит на отдельном физическом или виртуальном сервере, на который приходят логи, т.е. схема такая: источник > сборщик логов -> SIEM->СУБД -> SAN. Так же арксайт не лицензируется особо по EPS, т.е. ограничение как бы есть и как бы его нет, т.е. упираемся в основном в производительность самого сервера. Железо нужно нормальное с современными процессорами и кол-м оперативки не менее 96 Гб.
        Я пришел в компанию, когда была куплена SIEM и лежала в разобранном виде, потому в подготовке инфры не участвовал, да и не было в этом смысла, т.к. она очень быстро менялась.
        Инвентаризация так же идет через SIEM, в качестве источников информации выступают логи с МСЭ, результаты сканирований с помощью сканеров уязвимостей и сетевых(nmap), самописные скрипты для Linux в части управления обновлениями, для Windows — AD, WSUS, что то велось в Sharepoint, для него писал приложение, которое выдергивало инфу о том какие есть сервера. В общем в этой части у нас был небольшой хаос в части инструментов :) Арксайт позволяет писать правила, которые будут заполнять инвентаризационные списки. Очень удобно.
        Когда пришел в компанию изначально изучил схему сети и те ИС, которые есть, категоризация серверов бумажная и т.п… Собственно SIEM в итоге стал тем продуктом, над которым крутятся сейчас многие процессы ИБ.
        Порядок цен не назову, но думаю сейчас около 500 000$ будет стоить. EPS — в пике до 10,000, средняя цифра — 3500 с учетом агрегации и фильтрации мусора. Думаю по цифрам понятно на сколько большая инфраструктура :) В основном средства защиты, сервера баз данных, вебы, сетевое оборудование (без коммутаторов, только МСЭ и маршрутизаторы), для коммутаторов слишком мало полезных сценариев можно написать, когда нет рабочих станций пользователей.
          0
          Спасибо, а когда ждать следующую статью про корреляцию? Мне например, в особенности интересно как наладить проверку реальности атак уровня веб-приложения.

          К примеру, SQL-иньекции. Допустим есть веб сервер с кучей сайтов (все на одном IP 11.22.33.44 — только вир.т. хосты разные), и один из виртуальных серверов на нем — xxx.abc.ru. IDS обнаруживает атаку и залоггирует payload (http://xxx.abc.ru/path/script.php?param=INJECTION_HERE). IDS отправляет в SIEM в CEF алерт что мол на IP 11.22.33.44 была атака типа SQL и номер алерта в IDS 123456.

          Как быть дальше? Как я предполагаю: По приходу такого алерта надо запустить скрипт, который получает из базы IDS payload атаки (лог веб-сервера не подойдет — POST не логгируется), распарсить его, вычленить поле Host, вычленить атакуемый параметр, запустить sqlmap/сканер, проверить параметр на иньекцию и ждать в сием результатов сканирования? Разумеется с использованием WAF в режиме регистрации можно первые шаги упростить.

          Еще интересно как быть с «инвентаризацией» веб-ресурсов — чтобы регулярно актуализировать списки проверки веб-сканерами (чтобы находились все сайты на всех поддоменах и во всех подпапках, все скрипты в них и все параметры — не все сканер может выявить самостоятельно). Условие — автоматизированность — систем очень много. И возможно ли сразу увязать результаты такой инвентаризации и проверки сиемкой? Чтобы уже были знания по «безопасным» параметрам?

          Можете осветить в следующей статье подобные кейсы?

          PS. Про WAF от Валларма с его самопроверкой наличия иньекций знаю, но он дороговат в редакции нужной нам…
            0
            В части SQL-инъекций наиболее эффективно как раз анализировать посты и/или логи СУБД. Описанная вами задача решается проще и быстрее в части определения актуальности атаки.
            1. Провели внутреннее сканирование веб-серверов сами и нашли уязвимости, которые есть на серверах
            2. Заполнили списки уязвимостей для хостов
            3. При срабатывании сигнатуры IDS/WAF смотрим актуален ли данный тип атаки для данного сервера.
            Это в т.ч. хороший способ избавляться от ложных срабатываний. Вторую статью думаю на следующей неделе ждать. Я в меньшей степени хочу описывать реальные примеры, мне интереснее описать концепцию как делать хорошо, а как не делать.
            Дальше исходя из правильного принципа, зная его можно лепить что угодно. Это как знать как управлять авто и самому выбирать куда и как ехать.

            По инвентаризации. Тут нужно понимать, что в Арксайт можно засунуть и проанализировать любую информацию, как это сделать в вашей ситуации виднее вам. Из описанного вами сценария я бы использовал питон или баш скрипт, который по сислогу бы отправлял в SIEM нужную мне информацию и на SIEM я бы ее уже анализировал. По сути сделать complience check на siem не проблема, если отправлять на нее события с перечнем параметров, которые должны быть. У нас был реализован подобный кейс.
        0
        Как в ARCSIGHT с пользовательским интерфейсом? Когда я последний раз проверял там был жутко неудобный «толстый» клиент и ограниченный в функционале веб-клиент.

        Как насчет ADHOC запросов?

          0
          Интерфейс не изменился :) Я не могу назвать его неудобным в сравнении с тем же IBM Qradar, да он объемный, но там есть практически все что нужно, но это вопрос вкуса и привычки. Начиная с 6 версии стало удобнее управлять дисковым пространством, которое выделено базе и в целом много очень удобных фишек появилось. Про особенности управления Арксайтом стараюсь не писать в своей статье, т.к. хочется рассказать про общие принципы, а не продукт. Про продукт пусть сейлы рассказывают:)
          По ADHOC запросами, что подразумеваете? Формирование своих SQL запросов? Если да, то там можно написать (накликать через UI) запрос практически любой сложности (не могу сейчас придумать, что нельзя написать :)) с разным способом визуализации.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое