SIEM: ответы на часто задаваемые вопросы

    Вместо предисловия


    Я приветствую всех, кто читает этот пост!
    В последнее время мне стали часто задавать вопросы, связанные с SIEM. Окончательно добило общение с товарищем, с которым мы собрались вечером попить пивка и как-то незаметно перешли на тему, связанную с безопасностью. Он сказал, что они собираются внедрять SIEM — потому что «она помогает защитить инфраструктуру». И даже нашли людей, которые им соглашаются сделать это «за недорого и быстро». Вот тут-то я и насторожился… Как выяснилось, они думали, что внедрение SIEM разом избавит их от неприятностей вроде утечки данных, и к тому же будет недорогим и быстрым — мол, нашли систему, которая не требует настройки. Ну и дела, подумал Штирлиц, и решил накропать свои соображения по этому поводу, дабы отправлять вопрошающих к печатному источнику. Постараюсь быть кратким и охватить наиболее часто задаваемые вопросы.

    Немного теории


    Я не хочу подробно расписывать теоретические аспекты работы современных SIEM и их классификацию, т.к. тема хорошо описана. Вкратце, что такое SIEM? SIEM — это Security Information and Event Management. Как видно из названия — она «сама по себе» не способна что-то предотвращать или защищать. Данная система предназначена для анализа информации, поступающей от различных других систем, таких как DLP, IDS, антивирусов, различных железок (Fortinet, маршрутизаторы и т.д.) и дальнейшего выявления отклонения от норм по каким-то критериям. Как только мы выявили отклонение — генерируем инцидент. В основе работы SIEM лежит, как ни странно, почти голая математика и статистика. Каких-либо защитных функций «голая» SIEM в себе не несет.

    По техническим аспектам работы систем такого класса рекомендую ознакомиться через статьи на www.securitylab.ru либо на Хабре в блоге Positive Technologies. Также немного информации можно найти в моем посте: habrahabr.ru/post/159929.

    Собственно вопросы


    Здесь я попробую дать ответы на наиболее часто задаваемые вопросы.

    Вы говорите — SIEM сама по себе не защищает. Зачем она тогда?

    SIEM нужна именно для сбора и анализа информации. Информация поступает с различных источников — таких, как DLP-системы, IDS, маршрутизаторы, межсетевые экраны, АРМ пользователей, серверов…
    Согласитесь — достаточно муторно вручную просматривать логи с большого количества источников. К тому же, бывают ситуации, когда внешне безобидные события, полученные с различных источников, в совокупности несут в себе угрозу. Предположим, когда происходит отправка письма с чувствительными для компании данными человеком, имеющим на это право, но на адрес, находящийся вне его обычного круга адресов, на которые он отправляет. DLP система этого может не отловить, но SIEM, используя накопленную статистику, на основании этого уже сгенерирует инцидент.
    ОК, инцидент произошел — но сотрудник, допустивший утечку, всячески открещивается. Как доказать? SIEM способна предоставить всю необходимую доказательную базу, пригодную как для внутренних расследований, так и для суда. Собственно говоря, это одно из ее главных предназначений. В момент создания инцидента также будут оповещены все заинтересованные лица.
    И дополним штрих — периодически вам надо проводить аудиты на соответствие каким-либо стандартам. Это SIEM тоже умеет. Из дополнительных особенностей — SIEM после внедрения может косвенно вам помочь выбить деньги на дозакупку какого-то еще средства ИБ: например, вы в качестве обоснования прикладываете отчет, из которого видно, что большая часть полученных инцидентов закрывается запрашиваемым вами средством. Ниже иллюстрации, в каких случаях SIEM может быть полезна.
    Предположим, у вас нет SIEM. Тогда вы имеете:


    А вот теперь мы поставили SIEM:

    Картинки, конечно же, не претендуют на истину в последней инстанции, а просто дают примерно представление, зачем вам вообще может потребоваться SIEM.

    Давайте подытожим, что может делать SIEM система:
    1. Анализировать события и создавать алерты при каких-то аномалиях: сетевого трафика, неожиданных действий пользователя, неопознанных устройствах и т.д.
    2. Проверить на соответствие стандартам (PCI DSS, COBIT и др). Не без подводных камней, правда.
    3. Создать красивый отчет. В том числе настроенный непосредственно для ваших нужд. Например, ежедневный отчет об инцидентах, еженедельный отчет ТОР-10 нарушителей, отчет по работоспособности устройств и т.д. Отчеты настраиваются гибко, как и их получатели.
    4. Мониторить события от устройств/серверов/критически важных систем, создавать соответствующие оповещения для заинтересованных лиц.
    5. Собрать доказательную базу по инцидентам.
    6. Помогать выбивать средства на системы ИБ из адекватных руководителей.
    7. При наличии сканера уязвимостей, SIEM частично избавит вас от головной боли в плане рисков.


    Кто основной потребитель SIEM?

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

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

    Третья категория — крупные предприятия, кто уже познал всю прелесть неожиданно обнаруженного инцидента ИБ.

    Соответственно, можно примерно очертить круг тех, кому, возможно, внедрение SIEM актуально:
    • Должна быть большая/географически разветвленная инфраструктура. Насколько большая? Ну, наверное, это не 100 машин :) Как минимум, 1000-1300.
    • Должны быть системы ИБ — начиная от антивирусов и кончая DLP, IDS, IDM и т.д. Чем больше таких систем — тем лучше. На мой взгляд, в организации, которая собирается внедрять SIEM, DLP должна уже быть.
    • Наличие устройств, которые требуют мониторинга. Многие SIEM системы «из коробки» поддерживают достаточно большое количество вендоров, в т.ч. какие-то специфические сообщения, и поэтому способны заблаговременно спрогнозировать какие-то критические ситуации. Скажем, контроллер беспроводной сети генерирует сообщение о том, что кол-во пользователей близко к критическому — на основе этого SIEM способна сгенерировать алерт, оповещение о котором будет направлено заинтересованному лицу.
    • Должны быть деньги!!! И понимание того, что SIEM не окупится за полгода.


    Сколько времени займет внедрение? Какие работы надо закладывать?

    Приведу примерный список работ:
    • Обследование инфраструктуры и принятие решения о способе внедрения. Т.е. — будем ли все события обрабатывать в одном месте или нужно распараллеливание.
    • Формирование и утверждение ТЗ.
    • Разработка руководства администратора и руководства пользователя.
    • Установка и базовая настройка SIEM. Это означает настройку собственно сервера SIEM / интеграции железки, прописывание ее в сети, выполнение каких-то специфических настроек.
    • Настройка источников событий. Настройка собственно DLP, серверов и АРМ (возможно, с установкой агентов), железок в сети на отправку событий на сборщик SIEM.
    • Написание дополнительных правил реагирования. Из коробки ничего работать должным образом не будет, требуется дописывать правила для конкретной организации. Также на этом этапе вылезают первые косяки в плане криво настроенных источников / базовой настройки компонентов SIEM.
    • Тестовая эксплуатация и накопление статистики. Важный этап. Кладите от месяца до четырех, в зависимости от размера организации. Приготовьтесь к тому, что на вас обрушится шквал инцидентов, 95% которых — т.н. False-Positive, т.е. ложных.
    • Корректировка и дополнение правил корреляции. Выполняется параллельно с предыдущим этапом, фактически это обучение SIEM, тонкая донастройка под конкретные нужды.
    • Завершение тестовой эксплуатации. Тут лучше поставить несколько дней на финальную шлифовку системы. Какие-то крупные изменения проводить тут уже нецелесообразно, иначе goto на п.5 или п.6
    • Проведение приемо-сдаточных испытаний. Написание кейсов и прогонка их. Думаю, тут все понятно.


    В среднем, если делать все «по уму», то минимальный срок, на который надо рассчитывать, — от полугода. Какие-то плюсы от внедрения SIEM вы почувствуете через 5-6 месяцев после работы системы в «боевом» режиме. Цена на работы будет соответствующей, к ней припишите еще стоимость лицензий, и, возможно, обучения администраторов безопасности работе с SIEM.

    Что так много работ? Что так дорого? Вот XXX обещал все сделать за неделю за сто тыщ рублей!

    Есть замечательная картинка, дающая ответ на такой вопрос:

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

    Останутся ли False-positive события после начала эксплуатации?

    Останутся. Если вам говорят, что их не будет — плюньте в лицо тому менеджеру, что уверяет вас в этом. В этом случае либо у вас будут пропуски действительно требующих внимания инцидентов (кривая настройка), либо вам предлагают не SIEM. На итоговое количество ложно-позитивных событий повлияет количество источников, с которых SIEM гребет данные и тщательность написания правил корреляции, а также размер накопленной статистики в базе. И все равно, при подключении нового компьютера или неожиданном (но согласованном) «выверте» пользователя инцидент создастся. Тут работает принцип «лучше перебдеть, чем недобдеть». И все равно, число таких ложных событий будет мало, а точность определения инцидентов — выше, чем если бы вы анализировали вручную.
    Следует также понимать, что SIEM — это часть технических мер по обеспечению ИБ организации. И она не спасет от того, что сотрудник спьяну что-то где-то разболтает в баре, или забудет в том же баре прототип вашей разработки.

    SIEM способна предотвратить инциденты...

    НЕТ! SIEM сама по себе не способна ничего предотвращать. Если инцидент в ней зарегистрирован, то он уже произошел. Другой разговор — что могло не быть продолжения инцидента, т.к. DLP заблокировало передачу, антивирус убил трояна, пользователь передумал сливать информацию после предупреждения и т.д.
    Зато SIEM обеспечит вас доказательствами, которые можно будет использовать при внутренних разборках, в суде или продемонстрировать нарушителю и сказать «Вася! не делай так! Большой брат все видит».

    Какого вендора выбрать?

    Заранее не ответишь, нормальный интегратор обычно изучает инфраструктуру клиента, его потребности, выясняет, с какой суммой денег он готов расстаться. После чего предлагает вендора, т.к. они с одной стороны и похожи, а с другой — McAfee, например, хуже масштабируется, чем IBM QRadar, и они оба могут не поддерживать какую-то специфическую программу, под которую уже есть готовый коннектор для ArcSight.

    Какой объем жесткого диска требуется для хранения данных?

    Тоже неоднозначный вопрос. Это рассчитывается в зависимости от количества источников, интенсивности генерации событий (которая завязано на количество пользователей) и прожорливости конкретного вендора. Естественно, «чем больше, тем лучше». Обычно у каждого вендора есть «железячные» варианты, и «виртуальные», железячные варианты, как правило, в плане напичканной техники ничего из себя интересного не представляют и какими-либо особыми свойствами, кроме дизайна и размеров, не обладают. Зато стоят зачастую неоправданно дорого. Но по размерам установленных в них жестких дисков можно примерно прикинуть, насколько комфортно будет чувствовать себя система на вашей конфигурации. Размеры жесткого диска, как и интенсивность потока событий, на которые рассчитаны сервера, обычно указываются в даташите.
    Имейте ввиду, что решающее значение имеет скорость и надежность дисковой подсистемы, поэтому RAID тут жизненно необходим, также надо обращать внимание на производительность каждого ЖД, входящего в состав массива. SSD, хотя и быстры, на данный момент ввиду высокой стоимости хранения информации и меньшего ресурса, по сравнению с обычными HDD, наверное, использовать нежелательно.
    UPD из комментариев Подсказали статью по этой теме. Спасибо lless.

    А сложно с ней работать?

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

    Могу ли я сам написать правило корреляции?

    Да, это возможно, сложностей никаких нет — создание правил в большинстве SIEM максимально визуализировано, единственно где могут быть затруднения — правила могут использовать регулярные выражения «в чистом виде». Синтаксис регулярных выражений в большинстве случаев стандартный — если человек знаком с perl, скажем, то сможет написать синтаксически грамотное регулярное выражение. Основная сложность здесь — нужно представлять логику работы в целом, т.к. добавление правил может повлечь за собой изменение в логике работы других правил по формированию инцидента.
    UPD из комментариев Хотелось бы добавить, что в составе SIEM иногда имеются графические утилиты для тестирования разрабатываемых регулярных выражений. В частности, у ArcSight ESM эта утилита так и называется — regex. Спасибо eafanasov за дополнение.

    А можно ли сделать поддержку для источника событий YYY?

    Для начала, надо посмотреть, может ли источник (программа или железка) отправлять события как SYSLOG. Если да, то проблема решена — все SIEM ведущих вендоров с сислогом работают.
    Если программа какая-то специфическая, то в большинстве случаев можно написать обработчик событий или коннектор, но это означает дополнительные трудо- и денежные затраты.
    В тоже время современные SIEM «из коробки» поддерживают значительное число источников + производители их добавляют в своих обновлениях.
    UPD из комментариев Как верно подсказали, разные источники могут называть одно и тоже событие по-разному. Например, фаервол одного вендора скажет в логе «deny», другой «discard», третий «drop», а SIEM должна категорировать все эти события в единый формат, например «Firewall/Access/Failure», т.е. может потребоваться дополнительный обработчик. Спасибо bondbig за замечание.

    Нужна ли какая-то поддержка SIEM?

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

    Резюмируем


    Здесь я постарался осветить общие вопросы, которые возникают у людей; к сожалению, специфика SIEM такова, что конкретные цифры для абстрактной организации привести сложно — надо знать конкретную специфику. Для предварительного уяснения ситуации можно использовать примерно такой список вопросов, на которые желательно ответить перед тем, как принимать решение о поиске интегратора, который вам все сделает (тем более, что он у вас примерно тоже спросит):
    1. Что я в ожидаю в конечном итоге от внедрения SIEM? (можно перефразировать как: какие повседневные задачи планируется выполнять с помощью SIEM?)
    2. Общее число пользователей?
    3. Есть ли какие-то филиалы, географически удаленные, события с которых тоже надо учитывать?
    4. Какие системы ИБ у нас уже есть?
    5. Планируется ли анализ сетевых потоков (sFlow, netFlow...)?
    6. Планируется ли снимать события с серверов, АРМ пользователей?
    7. Есть ли в инфраструктуре какие-то специфические устройства, события с которых тоже нужно учитывать?
    8. Как часто происходят инциденты, требующие вмешательства/расследования? (<10 инцидентов/день, 10...50 инцидентов/день, 50...100 инцидентов/день, >100 инцидентов/день)
    9. Необходимость проверки на соответствие каким-либо стандартам есть? Если да, то каким?
    10. Кто будет ответственным за обработку инцидентов?
    11. Через какое время я ожидаю получение какого-то ощутимого результата?
    12. Сколько мы готовы потратить на внедрение и закупку SIEM?
    13. Кто будет поддерживать SIEM и сколько мы готовы платить за поддержку?

    Пара комментариев… Если вы не можете ответить на 1й вопрос — то советую почитать литературу и погуглить — не стоит надеяться на то, что в интеграторе вам все сразу расскажут. Потому что по телефону вам расскажут маркетинговый материал. При первой встрече вы узнаете, что у интегратора, естественно, есть опыт работы в этой области. Но! Зачем вам понадобилась SIEM — инженеры будут понимать именно с ваших слов, потому что нужды конкретной организации и особенности ее функционирования вы должны знать лучше них. Поэтому, при отсутствии завершенного образа — что вы хотите получить в конечном итоге — вы получите то, что, как подумал интегратор, вам подойдет лучше всего. При наличии образа — что вы хотите увидеть в конечном итоге — неизбежно скорректируются какие-то частности, но конечный результат, как правило, вас удовлетворит. Если у вас при ответе на 2-й вопрос — число пользователей — меньше 1000, то, скорее всего, SIEM вам не нужна. Если у вас из средств ИБ стоит только антивирус и фаервол — то тем более. SIEM достаточно специфичный продукт, который нужен, на самом деле, далеко не всем.

    На этом, пожалуй, закончу; если вы считаете, что какие-то общие вопросы не осветил — напишите, пожалуйста, в каментах.

    Всем спасибо за внимание!
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

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

      0
      Подскажите где можно почитать о примерах правил корреляции? О методике внедрения SIEM систем или это все КТ каждого интегратора? :)
        +1
        Хорошая книга есть, правда, на английском, в ней еще и ведущие игроки SIEM описываются вкратце.
        David R. Miller, Shon Harris, Stephen Vandyke, «Security Information and Event Management (SIEM) implementation», McGrawHill, 2011

        На русском не подскажу…

        + можно почитать блог Чувакина chuvakin.blogspot.ru/

        Если вас интересует конкретная реализация правил в конкретной системе — то это в админгайды лезть надо.
          0
          Недавно делал обработчик событий для HP 5500 HI Switch Series. Очень проблемно писать что-то самому — когда нету документов о форматах логов, о типах событий в них, о всевозможных комбинациях данных. Это я к тому, что в админгайдах ничего нет и правила пишутся в основном на основе опыта, чаще — своего(такими данными редко кто делится). А когда доходит дело до правил, то иногда встаешь в ступор:
          -какие правила могут быть для свича? роутера?
          -какие правила могут быть для DLP? Check Point IPS?
          Можно создать уведомления на какие-либо события, но это не есть правила корреляции.
          DLP и IPS это уже готовые системы, которые на основе своих алгоритмов и сигнатур выявляют угрозы. Как можно коррелировать уже выявленные угрозы?

          Идеальной считаю систему, ни где много правил корреляции, а где правила могут устанавливать взаимосвязи с несколькими источниками событий. Vpn-сервер +network access control +антивирус +фаервол + терминальный сервер + SAP = и чтобы по одному клику можно было увидеть с какого внешнего IP и под какой учетной записью подключился пользователь к VPN, который отправил на печать отчет ХХХХХ.
            0
            Следует различать микро-корреляцию и макро-корреляцию. Первая сопоставляет несколько событий от одного источника, например ips регистрирует срабатывания нескольких различных сигнатур с одного и того же ip-адреса в течение, скажем, получаса. Можно написать правило, которое занесет этот ip в watchlist (например suspicious_hosts), потом всем остальным событиям с этим адресом в source или destination немного повышать уровень «тревожности», далее можно нафантазировать продолжение.
            Макро-корреляция — как раз таки сопоставлени событий от разных источников, тут вообще полет фантазии ничем не ограничен. Например, представим, что у нас такой крутой футуристичный офис и в полах встроены датчики давления. Можно написать правило, которое сгенерирует письмо юзеру с темой «а ну-ка встань и проветрись, а то совсем заработался, %username%!», если он не встает с места более 6 часов подряд и постоянно фисируется активность работы разрешенных программ на компьютере.
        0
        Мониторить состояние устройств/серверов/критически важных систем
        Под это описание больше подходит Nagios\Zabbix и др. SIEM собирает и обрабатывает события из журналов системы. Думаю тут корректней будет использовать «Мониторинг событий»
        Какой объем жесткого диска требуется для хранения данных?
        Мне в свое время понравилась статья, правда там тоже есть нюансы.
        правило корреляции… они выглядят как регулярные выражения
        Ни разу не встречал правило корреляции в виде регулярного выражения. Можете назвать пример SIEM в которой правило корреляции выглядит как регулярное выражение? В моем понимание правило — это взаимосвязь нескольких событий, например: 10 попыток неудачно аутентификации за короткий промежуток времени, множественные события с одного IP адреса.
        поддержку для источника… отправлять события как SYSLOG
        Ну тут не все так просто. Часто, события передаваемые по SYSLOG сильно отличаются по структуре. Для примера: сервер ESXi, rhel, умный switch. Они все могут передавать события на сервер журналов, но для их обработки придется попотеть. Если для ArcSight это еще можно сделать без больших затрат, то для таких систем как TSIEM, SSIM разработка может занять значительные сроки.
        Нужна ли какая-то поддержка SIEM… ИБ обновляться и добавляться
        Правила, это такая вещь которую ни один интегратор не доведет до ума(мое мнение) и все равно придется на протяжение всей эксплуатации системы создавать новые правила\новые шаблоны отчетов.
          0
          У OSSIM, например, обработка сислога сделана достаточно неплохо. Понимает и линуксовые, и свитчи, и много чего еще.
            0
            Сислог — в первую очередь транспорт и формат заголовка (timestamp+hostname отправителя). Но не формат самих данных. Расположение полей, их назначение и содержимое сильно отличается в зависимости от того, кто шлет этот сислог, например лог событий FW сильно будет отличаться от лога Samba, Radius или почтового релея, при этом все они будут слать свои собития по сислогу. Поэтому в рамках темы SIEM нельзя просто сказать «поддерживается syslog!» Потому что первостепенная задача SIEM — структурирование данных, категорирование событий, приведение их к единому виду. Т.е. например фаервол одного вендора скажет в логе «deny», другой «discard», третий «drop», а SIEM должен категорировать все эти события в единый формат, например «Firewall/Access/Failure».
              +1
              А вот по этой теме интересная статья есть! От Олеси Шелестовой — habrahabr.ru/company/pt/blog/171083/ Как раз данная проблема и затрагивается.
              Но, под поддержкой SYSLOG подразумевалось именно
              транспорт и формат заголовка (timestamp+hostname отправителя)
              , т.е.поддержка сислога как протокола. Сислог, в первую очередь, все же протокол, и описан в RFC 5424, tools.ietf.org/html/rfc5424 — и у него есть общие поля.
              А разгребать все дальше — задача обработчика, встроенного в систему — все эти discard / drop
            0
            Думаю тут корректней будет использовать «Мониторинг событий»

            Вы правы, так корректней будет. Поправил.

            Можете назвать пример SIEM в которой правило корреляции выглядит как регулярное выражение? В моем понимание правило — это взаимосвязь нескольких событий, например: 10 попыток неудачно аутентификации за короткий промежуток времени, множественные события с одного IP адреса.

            IBM Q1 Labs QRadar, например, может использовать в правилах регекспы. Правило может быть как собственно включать один регексп (выборку по чему-либо), так и как вы описали. Хотя, я согласен — не очень удачно у меня написано, поправлю. В любом случае, с использованием визуальных конструкторов правил (я имею ввиду, когда у вас происходит некий диалог с системой) использование регулярок сведено до минимума.

            Если для ArcSight это еще можно сделать без больших затрат, то для таких систем как TSIEM, SSIM разработка может занять значительные сроки.

            Вы правы, но всегда можно найти найти вендора, SIEM которого будет поддерживать нужное оборудование. Например, крупные организации используют, в общем-то, одно и то же оборудование, поддержка событий которых уже встроена в систему «из коробки». Пример — тот же QRadar. На крайний случай, можно принять сырой поток (RAW) и обработать его, причем сделать это самостоятельно — с тем же QRadar`ом идет неплохая дока, по которой написать обработчик сможет даже человек, далекий от программирования. Да собственно, там и программированием это сложно назвать.

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

            Согласен с вами на все сто. Я это самое и имел ввиду, когда писал кусок про поддержку. Только тут вопрос в том — кто ее будет осуществлять. Интегратор — по запросу от заказчика либо сам заказчик.
              0
              Имел горе работать с TSIEM, QRadar боюсь даже пробовать(оба SIEM принадлежат IBM). Хотя я и понимаю, что они его целиком выкупили.
                0
                QRadar не стоит бояться, отличный продукт, довольно легок в освоении (для системы класса SIEM, конечно). Порог вхождения в тот же ArcSight гораздо выше, например.
                  0
                  McAfee еще можно попробовать, он в плане работы легче ArcSight / QRadar, но у него есть ряд недостатков в плане внедрения, на мой взгляд, у IBM тут более продумано все.
                    0
                    Расскажи про недостатки McAfee SIEM, мне интересно, не приходилось пока с ним работать.
                      0
                      Ну это не совсем недостатки, скорее, особенности, несколько усложняющие жизнь при определении нужных компонентов и последующую их инсталляцию. Это могут быть как железные, так и VirtualAppliаnce — центральный модуль, «приемники» и прочие системы, все это добро выпускается в куче комбинаций (например, т.н. отдельно стоящие компоненты / Combo — когда в одной оболочке несколько компонентов), отсюда несколько запутанная система лицензирования. Ко всему этому надо прибавить иной раз достаточно значительные вмешательства в сетевую инфраструктуру. Плюс — очень гибкая система, позволяющая, по идее, не платить за ненужные модули (зато вы заплатите за работу по интеграции этих модулей, так что неизвестно, будет ли выгода...). Минус, как ни странно, вытекает из этой гибкости сборки — довольно сложно масштабировать с сохранением единого «головного» модуля, где будет информация о всех значимых инцидентах (например, QRadar я могу развернуть таким образом, что на центральный модуль нагрузка по обработке будет минимальной, но в то же время, я, находясь в центральном офисе, смогу просмотреть все инциденты из одной консоли — для географически распределенных филиалов).
                      Но вот после внедрения, McAfee, наверное, одна из самых простых и эффективных в работе SIEM (за счет того, что он достаточно глубоко может внедряться в инфраструктуру). Но это уже мое мнение.
                      Так, чтобы подробно рассказать о McAfee — это, скорее, тема отдельной статьи.
                        0
                        Понятно. У QRadar'а, кстати, тоже много вариантов appliance'ов, с первой попытки не разберешься.
                        А в чем выражается «глубоко может внедряться в инфраструктуру»? В чем глубина-то?
                          0
                          У QRadar`a да, но там, в общем, все проще в плане того, что модулей меньше — нет обязательного раскидывания по функциональным особенностям. У McAfee же там несколько вариантов центрального модуля, несколько вариантов приемников, приемники обязательно должны стоять отдельно в тех местах, где планируется обработка информации, но и тут есть исключения + все усугубляется некой разобщенностью документации, трудно найти нужную информацию. Приемник — это может быть блейд способный работать на L2, т.е. мы в критических местах внедряем эти приемники, возможно, с другими продуктами макафи — такие как Email Gateway, DLP и т.д., за счет чего получаем что-то большее и выходящее за рамки понятия SIEM — т.е. мы уже можем влиять на трафик, блочить и пропускать email и т.д. В общем, если разобраться досконально, то наверное, выяснится, что там ничего особенного сложного то и нет, но у меня еще возможности не было очень глубоко изучить. Основная прелесть — в том, что всем этим добром можно управлять из еРО.
                          Я McAfee SIEM в данный момент занимаюсь, так что, возможно, что-то излишне субъективно написано, либо не совсем точно ввиду того, что не совсем до конца все возможности изучил.
                            0
                            Да мне тоже предстоит протестировать их SIEM в ближайшее время, понять, стоит ли с ним работать, предлагать заказчикам.
                            Твоя информация мне очень пригодится, спасибо.
                              0
                              пару слов добавлю:
                              McAfee ESM — название их SIEM — очень круто, если есть другие продукты МакАфи:)
                              Без них это довольно обычный SIEM, у которого есть доп. навороты — анализатор трафика и мониторинг СУБД.
                              Анализатор трафика — это железка, которая по SPAN мониторит трафик и разбирает его на составляющие — тут письмо, тут картинку в фейсбук запостили, тут по RDP приконнектились. СУБД — отслеживаются транзакции, доступы и т.д.
                              Лично мне не показалось, что есть какие то сложности, модули довольно стандартные — менеджер, ресивер для событий и лог-менеджер для сырых логов. Также есть их комбинации — менеджер+ресивер, ресивер+лог-менеджер и все в одном.
                              Расчет не такой уж и сложный, главное определиться, сколько событий ловим и где территориально ловим.
                              Также знаком с QRadar, не скажу, что сильно отличается по функционалу.
                              Очень ИМХО — МакАфи быстрее, и интерфейс, и отчеты. Также МакАфи заявляют о дикой производительности топовых железок, но чего не видел, того не видел…

                              Кстати, есть еще такая штука как Splunk — вот это где рай для линуксоида :) Мне нравилось когда-то им заниматься :) Очень много возможностей по кастомизации, но это одновременно и минус, так что…
                                0
                                Splunk довольно трудно назвать SIEM'ом, это в первую очередь лог-менеджмент, причем с приоритетом на неструктурированные данные. SIEM же работает исключительно со структурированными. Скажем, если сравнивать с ArcSight, то не с ArcSight ESM, а с ArcSight Logger. Ну или QRadar Log Manager.
                                  0
                                  Согласен) Но упомянуть стоило, он же бесплатный есть и ставится на раз-два, для чего-то небольшого подойдет.
                                    0
                                    Бесплатный тогда уж лучше OSSIM, потому что модули, хоть как-то реализующие функционал SIEM, у спланка бесплатно недоступны.
                                  0
                                  По функционалу да, не сильно отличается, я бы даже сказал — полностью собранная версия McAfee вообще ничем, по большему счету, не отличается — кроме масштабируемости, поправьте, если не прав.
                                  Основной плюс McAfee — это все же более понятный интерфейс + большие возможности при, как вы раньше упомянули, наличии прочих продуктов макафи.
                                  Но интерфейс, все же, понятие очень субъективное. Хотя, насчет скорости — это не субъективно, макафи быстрее QRadar`а. Что, впрочем, неудивительно, если учесть, что последний написан на Java.
                            0
                            Спасибо автору за статью.
                            Хотелось бы задать следующий вопрос: с какими еще системами SIEM, помимо вышеупомянутых, удалось познакомиться? Какие понравились, какие можете выделить?
                            И с какой стороны происходит знакомство с системами SIEM: со стороны Заказчика, администратора SIEM, Исполнителя, другое..?
                              0
                              В основном QRadar (проходил обучение), OSSIM, McAfee SIEM сейчас активно изучаю, ArcSight поверхностно. Знакомство происходит со стороны интегратора, то есть, получается, исполнителя — есть вендоры, с которыми мы работаем, соответственно, есть возможность получить продукт, ознакомиться с актуальной документацией, иногда удается сходить на какие-то курсы.
                              На данный момент QRadar понравился в плане относительной простоты развертывания, хотя для полноценной работы там приходится вникать, McAfee — удобство работы, но это уже, скорее, для конечного заказчика более актуально.
                                0
                                У меня есть некоторый опыт общения с SIEM других вендоров. Так вот этого небольшого опыта достаточно, чтобы сделать вывод о сложности и индивидуальности каждой системы. В общем и целом, они решают одну задачу, но в реализации, в деталях, очень разные. Соответственно, периодически посещает мысль создания общего сравнения всех решений в одном месте. Как уже говорил ранее, сложность каждого решения не позволит это сделать быстро и качественно. Не возникало подобных желаний?
                                  0
                                  Тут хотя бы с критериями сравнения определиться… У каждого вендора найдется документик с перечнем того, где они крутые, а остальные — нет.
                                    0
                                    Все правильно: определить критерии, заполнить их для разных решений.
                                      0
                                      С определением критериев как раз большая беда. Слишком общие критерии (eps, количество поддерживаемых источников, количество отчетов, предустановленных правил и т.п.) практически не дают никакого понятия о том, чем же они отличаются в процессе интеграции и повседневной работе с ними. А по миллиону других параметров системы не пересекаются. Дьявол — в деталях.

                                      Есть вот такой вот отчет гартнера, например, можно составить некое впечатление:
                                      www.peeep.us/1e0b522d
                                        0
                                        Сравнение — это гиблое дело, на мой взгляд, все надо от окружения смотреть. Если у заказчика кругом продукты макафи — зачем я ему буду предлагать арксайт? Это все очень синтетически будет, в реальных условиях я соберу информацию об инфраструктуре и потребностях, и предложу то, что встанет с наименьшими трудозатратами. SIEM — это не антивирус, у которого хотя бы общие критерии можно выделить.
                                          0
                                          дык о том и речь.
                                          Но таких ситуаций («у заказчика кругом макафи») не так уж и много, поэтому всегда требуется некое сравнение. Лучше всего, по моему мнению, это делается в рамках небольших пилотных проектов на кусочке реальной инфраструктуры. Поставили, подключили пять-шесть источников, поигрались с системой, реализовали три-четыре интересных use-case'а. Проделав это на двух-трех решениях сразу становиться понятно, какое имено решение лучше ложится на конкретную инфраструктуру.
                                          0
                                          В отчет Гартнера пока не вникал, почитаю в ближайшее время.

                                          Можно начать с общих критериев, указать кол-во eps, указать кол-во отчетов, как хранятся события, где хранятся инциденты, потом описать, как лицензируется продукт, как масштабируется… и т.д.

                                          Начать можно с малого, а потом развить тему.

                                            0
                                            Такие «сравнения» не стоят и выеденного яйца. Сделать можно за 10 минут на основании маркетинговых материалов, но практической ценности нет никакой.
                    0
                    del продублировалось
                    0
                    Спасибо за статью, коллега. Плюс поставить не могу, отмечаю благодарность словами.
                    Правда присоединяюсь к недоумению по поводу
                    правило корреляции… они выглядят как регулярные выражения
                    если уж и подыскивать аналогии, то это скорее SQL-запрос, но уж никак не регулярка :) Да и то, скорее триггер, чем просто запрос.
                      0
                      Спасибо. Да, с правилами не очень ясно написал, видать, мысль опередила пальцы, поправлю. Имелось ввиду, что в правиле может быть регулярное выражение.
                        0
                        может, но этого следует всячески избегать.
                          0
                          О да… При потоке событий под 15к EPS проверять каждое сообщение на регексп типа (.+?)failed(.+?) будет очень весело.
                        0
                        А можно пример такого «SQL» запроса с описанием, что делает в данном конкретном случае?
                          0
                          Пример одного из встроенных правил ArcSight:
                          Protocol_Deny: ( ( Category Behavior = /Access OR Category Behavior = /Access/Start ) AND NotInActiveList(«Trusted List») AND ( NotInActiveList(«Reconnaissance List») OR NotInActiveList(«Scanned List») ) AND Category Device Group = /Firewall AND Category Outcome = /Failure )
                          image

                          Описание:
                          This rule looks for application protocol scans. The rule monitors failure access detected by a firewall. The rule fires when 3 events occur in 3 minutes with the same attacker/target pair with different application protocols each time. On first threshold, the attacker address is added to the /Reconnaissance active list and the target address is added to the /Scanned active list.
                        0
                        Спасибо за статью, все понятно описано и разложено по полочкам.
                          +1
                          Хотелось бы добавить, что в составе SIEM иногда имеются графические утилиты для тестирования разрабатываемых регулярных выражений.
                          В частности, у ArcSight ESM эта утилита так и называется — regex.

                            0
                            Более того, без этой утилиты делать флекс для арксайта довольно-таки непросто, потому что синтаксис регулярок особый.
                              0
                              Это вы про "\\" вместо "\"?
                                0
                                В том числе.
                              0
                              Вы действительно ей пользуетесь при разработке flex?
                              Я пытался начать с ней работать, но как то не сложилось.
                                0
                                Ну не в голом же блокноте. Я с ее помощью пишу флекс от получаса до трех-четырех часов, в зависимости от того, насколько сильно «заморочен» лог (насколько отличаются между собой разные строки, сколько токенов надо выделить, нужны ли submessage и т.п.).
                                Тулза хороша тем, что можно загонять в нее большой кусок лога (тысячи строк) для теста готовой регулярки и разбивки на токены. Также она сама генерит конфиг, при тестировании на куске лога сразу показывает в отдельном окошке значения токенов и все в таком духе. Не вижу смысла отказывать себе в таком удобном инструменте. Это не «магическая штука», которая сама все сделает (такая есть у RSA, кстати), это просто удобная микро-ide для флексов.

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

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