SIEM для ИТ и ИБ

    С появлением первых средств защиты информации возникли первые насущные вопросы: как узнать, что возведенные баррикады работают и защищают? как быстрее реагировать на оповещения? как понять, какие угрозы удалось предотвратить? Работает ли наш файерволл, можно узнать, выполнив ICMP ping: если правила в ACL (access control list) работают, то ответов, содержащих echo reply, быть не должно. Можно через консоль устройства просмотреть журнал событий, разбирая сотни или тысячи строк вручную и пытаясь увидеть отраженную или выявленную угрозу.

    Время — деньги


    Журналов событий, получаемых от одних только активных средств защиты, — много, не говоря уже о критических серверах, базах данных, приложениях. При помощи этих журналов можно выявить несанкционированные попытки доступа, сетевые атаки, аномалии, ведущие к нарушению непрерывности бизнеса или политик безопасности. Чтобы открыть журнал событий, нужно выполнить последовательность действий, которые требуют времени: запустить приложение, подключиться к консоли, вывести список событий и изучить его. Даже если допустить, что один сотрудник отвечает только за контроль антивирусного ПО (предположим, что имеется централизованная консоль управления), установку обновлений и IPS (предположим, что их не более 2—4), — на просмотр событий от этих источников и разбор проблем за последние сутки у него уйдет около часа. Отметим человеческий фактор: офицер может быть загружен другими делами, может болеть или быть в отпуске, отвлечься от работы или выполнить ее для проформы. Теперь посчитайте, сколько человеко-часов нужно, чтобы анализировать журналы событий на критических активах хотя бы раз в сутки? Учтите в расчетах заработную плату квалифицированного сотрудника, способного выявить угрозы в этих журналах событий, учтите время, необходимое для подключения к СЗИ в вашем филиале по медленным каналам связи. Дорого? Да, выходит круглая сумма, назвав которую руководству, вы, скорее всего, будете выставлены из кабинета.

    Итак, вы установили средства защиты, настроили их, они работают, — что вам еще нужно? SIEM заменяет не один десяток человек, работает оперативно и не будет просить о повышении зарплаты.

    Защита бизнеса


    Главная задача ИБ — обеспечить защиту бизнеса и непрерывность бизнес-процессов. Что для этого нужно? Описываются бизнес-процессы, определяются активы, проводится их аудит (включая сканирования и пентесты), составляется модель нарушителя, изучаются риски, составляется план их минимизации. Какие меры принимаются для минимизации риска? Создаются политики, проводится обучение пользователей, устанавливаются средства защиты информации, изменяются конфигурации, устанавливаются обновления… Мы все это сделали — и оставили как есть? до следующего цикла PDCA?

    Держать руку на пульсе


    Принцип «поставить и забыть» в ИБ неприменим. Абcолютной защиты не существует, и самые маловероятные риски могут аукнуться остановкой бизнеса и огромными финансовыми потерями. Любое программное и аппаратное обеспечение может перестать работать или быть неверно настроено — и пропустить угрозу. Видели панель управления в современных самолетах? Все важные индикаторы собраны воедино с соблюдением эргономики и приоритета. Пилот и его помощник не могут не увидеть нарушение критически важного показателя. Так и в SIEM: в случае любого отклонения от baseline или политик (курс самолета) или нарушения работоспособности актива в результате сбоев или угроз (неполадки в оборудовании) — операторы-пилоты будут незамедлительно уведомлены.

    Почему незамедлительно и что будет через час? Вирусы распространяются в считанные секунды, у злоумышленников имеются автоматизированные комплексы для анализа и эксплуатации уязвимостей. Событие о посыпавшемся RAID-массиве в системе, находящейся в промышленной эксплуатации, завтра вам будет уже не интересно, ибо часть данных (или даже все) будут утеряны. Чем оперативнее вы будете информированы, чем быстрее предпримете меры, — тем меньше финансовых потерь понесет ваш бизнес. Хорошо, если случившийся инцидент не будет иметь последствий (возвращаясь к самолетам: «Вася, прикинь! Мы вчера с Парижа в Москву на одном движке долетели!»).

    Превентивной защиты не существует


    Если мы устанавливаем централизованное антивирусное ПО — необходимо убедиться, что оно установлено везде, правильно сконфигурировано, работает с актуальными базами. Как? С помощью журналов событий.

    Зачем? Представьте, что вы автоматизировали установку корпоративного антивирусного ПО и обновление баз. Аудит журнала событий вы осуществляете раз в два-три дня, но произошел сбой, в ОС на рабочей станции, стоящей на складе, не запускается сервис и она заражена вирусом, который распространяется по сети. Абсолютно не факт, что на всех серверах запрещен, к примеру, автозапуск, установлены все заплатки: в реальной жизни такого практически не бывает. Автоматически размещенный использующий уязвимость троян с автозапуском и распространением по сети или подделанным ярлыком на общем сетевом ресурсе приводит к коллапсу всей компании. Пока вы будете в авральном режиме анализировать случившееся — бизнес, скорее всего, будет простаивать, а начальство — нервничать и возмущаться. Финансовую оценку убытков от простоя предприятия легко произвести самостоятельно, благо это не так сложно. Кроме того, подобные сбои имеют свойство негативно влиять на премии и зарплату.

    Контролируемая угроза, принятый риск


    На практике встречаются случаи, когда безопасность идет вразрез с бизнесом. Случаются ситуации, когда нельзя поставить обновление, чтобы закрыть уязвимость (причин масса: сертификация, нестабильность работы, «не протестировано», конфликт с другим ПО), или, например, невозможно запретить RPC, поскольку бизнес-приложение перестанет работать. Затраты на устранение угрозы могут превышать возможные потери, поэтому риск «принимается». Однако мы можем контролировать подобные риски с помощью SIEM, реагировать на возникающие инциденты, возвращая по окончании года средства, выделенные на покрытие операционных рисков, обратно в бюджет. Естественно, что в данном случае не может быть и речи о просмотре оператором журналов межсетевого экрана без автоматического анализа и регистрации инцидентов как способа контроля рисков.

    Нет причины — все виноваты


    Вы наверняка сталкивались со случаями, когда для решения инцидента нет данных: отсутствует информация о точном времени и месте возникновения (не считаем звонки от пользователей), о том, что предшествовало инциденту; и мы не можем ответить на главные вопросы — почему произошел инцидент и кто в этом виноват. Нет, это нужно не для того, чтобы наказать виновных (хотя это тоже иногда необходимо). Главное, что необходимо выяснить по итогам инцидента, — что делать, чтобы инцидент не повторился. Причем одного только встроенного в OС журнала (Windows event log или syslog) может оказаться недостаточно.

    Я не бог, я всего лишь системный администратор


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

    Кто знает, что это за скрипт?..


    Безусловно, можно построить управление журналами и какое-никакое управление событиями на «самописных» сценариях. Журналы собирать через syslog или открытое ПО. Можно все оформить на PowerShell, «батники», sh-сценарии, а об инцидентах сообщать на электронную почту. Как удобно и дешево!

    Да, это приемлемо для малого бизнеса. Вернемся к нашему примеру с самолетом. Уберем мысленно все индикаторы с приборной панели (или сотрем их названия), а сообщения о неполадках будем направлять пилоту по СМС и на электронную почту… Как быстро пилоту надоест лазать в карман за телефоном и разбирать входящие письма?

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

    Защищайте не только критические активы


    Представим, что вы защитили критические (по вашему мнению) активы, к примеру бизнес-приложение или базу данных. Все прекрасно, денег потрачено в меру, сэкономили на отсутствии СЗИ для рабочих станций и двухфакторной авторизации для мобильных пользователей. Пользователей «зажали» групповыми политиками. Вот только не учли, что дверь с замком, стоящая посреди поля, — абсолютно неэффективна. Злоумышленники получат пользовательский и административный аккаунт с незащищенных рабочих станций или с мобильных устройств и с абсолютно легитимными запросами к вашей суперзащищенной базе данных «вытянут» все, что только можно. Деструктивные действия давно не в моде. Вы узнаете об утечке информации из новостей — и удивитесь: ведь все ваши серверы были надежно защищены! Это пример типовой атаки по модели APT. Запущенные процессы, новые библиотеки в OС, новые сервисы, открытые порты и соединения, повышение привилегий — все это можно увидеть в журналах событий на рабочих станциях, которые не являлись, по вашему мнению, критическими активами…

    Защита должна быть комплексной. Доказательство тому — инциденты с Bit9 и RSA, которые почему-то не поставили разрабатываемую ими защиту на свои же рабочие станции.

    Представления


    Средства защиты, как правило, являются сигнатурными, то есть создаются на основе анализа уже известных угроз (вирусы, сетевые атаки, даже словарики в DLP). Новые угрозы вы можете выявить только с применением сложных алгоритмов корреляции (об RBR-корреляции — см. статью в нашем блоге — здесь не может быть и речи) на основе миллионов событий и показателей, а также анализа baseline. Человеческий мозг не всегда способен комплексно проанализировать такой объем данных. Однако абстракция представлений в SIEM-системах способствует своевременному обнаружению угроз операторами. Система делает все предварительные расчеты и выводит показатели. Как минимум, к примеру, на основе анализа baseline система сообщает о новом DynDNS-трафике, о том, что зафиксировано по 10 безуспешных попыток входа с различных активов от имени доменного администратора. Как правило, система способна сообщить о трояне или брутфорсе (в зависимости от состава правил корреляции и возможностей конкретной системы). Применение более сложных алгоритмов корреляции позволит узнать причину инцидента (например, выявить подключение пользователем модема, в результате которого произошло заражение трояном и брутфорс). Человеку не под силу самостоятельно осуществлять такой анализ на основании миллионов текстовых событий. Возможность настройки панелей визуализации полезна как отдельным сотрудникам, так и для работы SOC (security operation center), а также подразделений ИТ и техподдержки.

    Соответствие (compliance)


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

    Акценты


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

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

    Поделитесь событиями


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

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

    При успешном внедрении вы получите:

    • корреляцию и оценку влияния IТ- и ИБ-событий и процессов на бизнес;
    • SOC с анализом ситуации в инфраструктуре в режиме реального времени;
    • автоматизацию процессов обнаружения угроз и аномалий;
    • автоматизацию процессов регистрации и контроля инцидентов;
    • аудит политик и стандартов соответствия, контроль и отчетность;
    • задокументированное корректное реагирование на возникающие угрозы ИБ и ИТ в режиме реального времени с приоритизацией в зависимости от влияния угроз на бизнес-процессы;
    • возможность расследования инцидентов и аномалий, в том числе произошедших давно;
    • доказательную базу для судебных разбирательств;
    • отчетность и показатели (KPI, ROI, управление событиями, управление уязвимостями).

    Я привела лишь немногие примеры того, как SIEM поможет вашему бизнесу в обеспечении непрерывности, повышении оперативности, в решении проблем и инцидентов. Можно еще много писать об автоматизации, реакции (сценариях), предотвращении инцидентов и их расследовании. Об этом я постараюсь рассказать в следующих публикациях. Отдельно рассмотрим крайне важный момент, волнующий многих: как с помощью SIEM проследить влияние IТ- и ИБ-событий на бизнес.

    До встречи! Жду ваших вопросов и комментариев.

    Автор: Олеся Шелестова (oshelestova), исследовательский центр Positive Research.
    Метки:
    Positive Technologies 167,98
    Компания
    Поделиться публикацией
    Комментарии 15
    • +1
      Работает ли наш файерволл, можно узнать, выполнив ICMP ping: если правила в ACL (access control list) работают, то ответов, содержащих echo request, быть не должно.

      Кто ж вас научил ICMP резать?
      • +1
        Как обычно, человек правильную вещь написал, а его минусуют. Хабр неизменнен.
        • 0
          Угу. Уже минус 3 в карму.

          Для минусующих поясню: ICMP — это не только echo request/reply, это еще и redirect, всякие там destination * unreachable, сообщение о необходимости фрагментации (вот это вообще зло — если его зарезать, некоторые сети, например paypal, тупо отваливаются), и так далее.

          ru.wikipedia.org/wiki/ICMP
          • +1
            а какое это отношение имеет к статье?
            Ребята же не дают в ней указания бестпрактис, или конфиги фаерволов как надо, статья вообще о другом
            • 0
              Судя по слогу, фильтрация ICMP у них считается само собой разумеющейся.
            • 0
              Фраза «проверить файервол пингом» говорит о частичной некомпетентности автора. Ну вроде того ping www.google.com говорит о том, что файервол неправильно настроен.
    • 0
      В комментариях к статье по SIEM от конторы, занимающейся уязвимостями, обсуждают фильтрацию ICMP.
      Хабрахабр оправдывает свой логотип -)
    • +2
      Спасибо за очередную статью, по этой интересной теме.

      Как и в прошлый раз, могу спросить, да круто, да продвинуто, но для кого эти системы?

      Разделение на средний и крупный бизнес думаю не корректно.
      Скорее надо смотреть на вид деятельности бизнеса.

      habrahabr.ru/post/172389/

      Вот тут честно говорится, что SIEM это тема преимущественно банков.
      Грубо говоря сотни серверов и все критичны. Человеку контролировать сложно, покупаем SIEM. Стоить это будет, как чугунный мост, но и потери от нарушений политик ИБ видны невооруженным взглядом, ибо выливаются, например, в конкретные украденные бабки.
      Можно еще взять интернет гигантов, типа Яндекса. Потеря доступа миллионов пользователей к сервисам — убытки. Внедряем.

      Для остального сектора, убытки косвенны и сложно считаемы.
      Можно привести в пример не любимого многими Лукацкого
      lukatsky.blogspot.ru/2013/03/blog-post.html

      Верно пишет же — прежде чем что-то внедрять. Обоснуй. Покажи деньги.

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


      Падение почтового сервера на пол часа, никак не скажется на выпуске тазиков Автоваза, станок как клепал кузовы так и будет клепать. Где убытки?
      Или Автоваз мелкое предприятие?

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


      Главное, это не слепо верить таким вот рекламным текстам.
      Надо понимать, что если пользователь с доступом захочет украсть данные, он их украдет. Набивший оскомину пример, с фотографированием экрана — классика жанра. Не требует большого ума и хакерских навыков.
      Если забыть упомянуть, в угаре выбивания «бюджетов», об этих и некоторых других так называемых остаточных рисках, то потом может быть очень больно. Руководство возьмет за шкирку и строго спросит, как так — потратили 100 лямов на SIEM с DLP, а данные все равно уплыли.
    • +1
      Отнюдь. В России почему-то принято делить на Банки\Газ*\Все_прочие и говорить про третью категорию как «малые». SIEM изначально создавался не под отрасль, а под задачи. Compliance и policy management не только в банках. Compliance PCI DSS не ограничивается.
      — Да, у Банков риски больше. Большой оборот и движение денежных средств и контролировать можно (в отличие от работы с золотыми приисками, где обороты вполне сравнимы).
      — Да, банк должны повиноваться стандартам, в которых четко прописано что должно логироваться.
      — Да, у них юридических инцидентов больше. А сислогом вы не обеспечите доказательную базу.
      — ДА, основной русский авось «Нет обязаловки — зачем тратить деньги».
      Отсюда не следует что SIEM «преимущественно» для Банков. Не стоит забывать о телекомах (провайдеры, операторы). Их конечно полно уже на рынке, но хаос полный в них. Сами очевидно знаете, что есть уже в Москве те, к которым подавляющее большинство не будут подключаться. А новые — уйдут через квартал. SIEMы им бы помогли (не буду расписывать КАК, это отдельные статьи).
      Не стоит забывать о логистике, торговых компаниях. Вы не представляете какие внутри потери они несут. За счет несвоевременных поставок, утечек информации, сбоев. Вы не представляете, какие убытки они несут только из-за того, что каналы их загружены отнюдь не бизнес-приложениями (на регионах и на спутнике, поверьте, это значимо).
      Ок, еще примеры? Не смейтесь, но ММОРПГ (Aion, Diablo, GoW )… Ботоводила, писала ботов. Знаю какой ущерб несут эти компании. Не поверите, SIEM помог бы им.
      Дело не только в комплайнсе и наличии евентов для разбора возникшего инцидента.

      Верно пишет же — прежде чем что-то внедрять. Обоснуй. Покажи деньги.
      Правильно. Наймите опытного хорошего аудитора, он вам покажет. Не просто дыры, а деньги. Этому учат хорошие председатели\зампреды Банков (не потому что банки, а потому что их и так доят все кому попало ;) ). А пока нет нормального обоснования и нет желания понять свои ошибки — интеграторы будут разворачиваться на пороге бюджетного кошелька на 180 градусов.
      Падение почтового сервера на пол часа, никак не скажется на выпуске тазиков Автоваза, станок как клепал кузовы так и будет клепать. Где убытки?
      Или Автоваз мелкое предприятие?

      фраза из трехлетней давности моей презентации — «когда в компании Le`vis рухнула база SAP, в которой находились заказы на отгрузку товара, компания понесла убытков на 48 млн. долл за сутки»
      Простите, но Вы не умеете оценивать риски. Тем более в денежном эквиваленте.

      потратили 100 лямов на SIEM с DLP, а данные все равно уплыли

      Та же сумма описывалась в анекдоте про газпр* (не хочу обидеть компанию, просто вспомнилось) и туалетную бумагу.
      Вопрос в стоимости информации и стоимости мер (возвращаемся к рискам). Не забывайте об этом ;)
    • +1
      Вообщем, простите. Но наша компания не интеграторы. Мы не впариваем решение SIEM :) Мы помогаем в оценке рисков. Моя миссия — это сказать в чем и как SIEM может помочь, попытаться рассказать о механизмах работы SIEM-систем общими понятными словами. Что я и пытаюсь сделать. Говорить в общих словах о рисках применительно для всех компаний, естественно, некорректно. Каждый сам должен оценить свои риски. И сделать свой вывод — что ему нужно SIEM\DLP или вообще ничего.
      Давайте без холивара :)
      • –3
        Да что вы говорите?! Интеграторы черные, а вы позитивные? Не стоит забывать, что интеграторы «впаривают» в том числе и ваши продукты, т.к. у них (продуктов) только такой канал доставки.
        • +2
          Интеграторы впаривают, но никто не мешает вам отказать этим интеграторам. Это рынок, такой же, как и мясной или обувной. Там вам тоже каждый пытается что-то впарить, но вы же не покупаете все и у каждого =)

          А дойти до того, нужно вам это или нет можно и самостоятельно. Вот я четко понимаю, где в моей деятельности SIEM нужна, а где — нет =)
    • 0
      Еще момент, возвращаясь к некритическим активам.

      Не кажется ли Вам, что тут возникает некое противоречие.

      Защищайте не только критические активы…

      Это пример типовой атаки по модели APT. Запущенные процессы, новые библиотеки в OС, новые сервисы, открытые порты и соединения, повышение привилегий — все это можно увидеть в журналах событий на рабочих станциях


      и вот этим

      Акценты

      как и в случае с DLP-системами, здесь необходимо правильное внедрение, интеграция с источниками событий, индивидуальный подход к активному набору правил и алгоритмам корреляции. Гибкая система исключений и правильная настройка SIEM гарантируют вам акцент только на критически важных событиях — без флуда.


      То контролируйте все по-максимуму, даже не критичные, а то мало ли что…
      То не контролируйте, ибо флуд, запаритесь реагировать.

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

      «когда в компании Le`vis рухнула база SAP, в которой находились заказы на отгрузку товара, компания понесла убытков на 48 млн. долл за сутки»


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

      IТ-отделу также хочется узнавать о возникающих инцидентах не по звонку пользователей, а заранее (тем более, что — как и инциденты ИБ — IТ-инциденты можно предотвратить).


      В прошлый раз уже обсуждалось. SIEM это не оракул/провидец. Сначала инцидент все таки случится, а потом уже SIEM об этом оповестит и последует оперативная реакция.
      Если конечно операторы SIEM-а будут вовремя смотреть консоль управления, а не спать на рабочем месте, поскольку до этого всю ночь клубились по тусовкам. :)
    • +1
      Доброго дня.
      Не кажется ли Вам, что тут возникает некое противоречие.

      Нет, не кажется.
      Я не говорила про флуд. False positives будут всегда. Другое дело в каком объеме. Если их нет вообще — то система скорее всего либо не работает (или недостаточно правил корреляции для обнаружения угроз, либо вы не дооцениваете своих специалистов, корректирующих работу SIEM.

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

      Ой, представляю, ибо работала на гораздо больших объемах инфраструктуры ;) «Включенный мониторинг по максимуму» — это неправильный подход. Отсюда и получают потом кучу ложных инцидентов. Необходимо учитывать риски, активировать и редактировать правила корреляции согласно ваших (!) угроз.
      Те же 900 рабочих станций скорее всего необходимо контролировать (для более точного утверждения — необходимы данные). Почему?! Вы защитили 100 серверов. А со взломанной рабочей станции можно легитимно имитировать работу пользователя и сливать информацию. Почему? Потому что вы не учли в оценке рисков где обрабатывается ваша мегаценная информация. По вашим рассчетам она ведь находится где то на этих 100 серверах. Поэтому я не вижу в своих словах противоречий.

      Если у компании сервера вылетают на сутки, значит нужно искать проблемы в отсутствии грамотной кластеризации, резервного копирования, а не в наличии/отсутствии SIEM-а

      Опять же вернемся к анализу рисков?) Что вы можете увидеть в SIEM из ИТ сбоев? Из практики: начинающиеся сбои в аппаратном\программном рейде, об ошибка в старте сервисов, о падении сервиса или ошибках в БД, о сбоях в средствах защиты (тот же антивирус вырубается или обнуляются правила и настройки), о конфликте ip адресов (прошу, не надо холивара, это также критическое событие для ряда информационных систем и в разветвленной инфраструктуре ищется долго ;) ) и прочее, прочее. Вовсе не бесполезны системы мониторинга ака nagios. Но эти системы мониторинга говорят по факту. Каждому инциденту присутствуют симптомы. Падению информационной системы будут предшествовать скорее всего разрозненные по журналам событий различные ошибки. Конфликту IP — возникновение нового актива в вашей инфраструктуре или входу с повышенными привилегиями. Пример из практики. Один из множества. Были у меня серверы приложений на Citrix. Симантек антивирус (SEP) падал на ферме с bsod. Оказалось по факту — что пользователь формировал большой отчет в домашней директории определенного формата. Да, я не смогла предотвратить первый инцидент. Он возник. Но не без пользы. SIEM помог мне выявить причину. Оперативно. После расследования инцидента, я создала правило корреляции.Правило содержало активный сценарий. Больше инцидентов не было, даже если появлялись пользователи-умельцы. Активный сценарий мне помогал предотвращать возникновение инцидента.
      Пример 2. Securit Zserver падал с сервером в bsod, если путь до файла был больше 256 символов. Опять же — сценарий в правиле помогал мне в предотвращении многочисленных инцидентов.
      Пример 3. Установлены политики блокировки учетных записей? Вот представьте что будет если под учетной записью под которой крутится сервис попытаются зайти N-раз под неправильным паролем? А вот тут вотработает в SIEM не только лог-менеджмент и классические правила корреляции присутстствующие во всех SIEM. Здесь уже работает оценка рисков и взаимосвязь с бизнес активами. Да, с точки зрения ИТ-ИБ произойдет возможная блокировка учетной записи. НО! На самом деле может произойти остановка бизнес-процесса(!). Сервис, отвечающий за работу информационной системы будет остановлен. Информационная система перестанет быть доступной. Бизнес-процесс будет остановлен. Простой. Сколько он будет стоить бизнесу- можно посчитать.
      Искать эти события глазками в разрозненных или даже сконсолидированных в одну базу событиях — это утопия. Интеллектуальная логика позволяет автоматически (!) выявлять инциденты и сообщать мне о проблемах во время. С SIEM я всегда знаю что имеются проблемы в информационной системе, что происходит в инфраструктуре. И на что это влияет.

      В прошлый раз уже обсуждалось. SIEM это не оракул/провидец. Сначала инцидент все таки случится, а потом уже SIEM об этом оповестит и последует оперативная реакция.

      Вот опять же — не всегда. Холиварный вопрос, который нужно обсуждать не в комментариях. Я говорила о предшествующих симптомах. Они почти всегда есть. Интеграции с различными системами позволяют видеть это своевременно в SIEM. Часть поставляемых правил корреляции — это накопленная база знаний уже случившихся инцидентов. Устав, написанный кровью. Используйте его. К тому же, есть MAEC, CAPEC написанные также не зря. Они также должны транслироваться в правила корреляции с учетом игроз для вашей компании.И пополняемые.

      Если конечно операторы SIEM-а будут вовремя смотреть консоль управления, а не спать на рабочем месте, поскольку до этого всю ночь клубились по тусовкам. :)

      Вот для этого необходим SIEM. SOC-а 24x7 может и не быть. Оператор будет клубиться уже с неспокойной душой, когда ему на мобильник прийдет инцидент. И SIEM эволюционирует из лог-менеджмента для того, чтобы постоянно не пялиться в консоль, выявляя инциденты, а работать с автоматически зарегистрированными инцидентами. Вы даже не представляете какой кайф от такой автоматизации. Какие ресурсы высвобождаются. Поверьте, говорю по опыту. =)

      • +1
        Вот читаю вас, Олеся, и просто бальзам на душу =)

        Вообще, моя личная практика показывает, что подобные системы критикуют таким образом только люди, которые не сталкивались с проблемами, решать которые эти системы призваны. Либо сталкивались, но не с позиции человека, несущего ответственность, а с позиции стороннего наблюдателя =)

        Я в свое время тоже погряз в скриптах, отчетах на почту и т.п.

        От себя могу добавить вот такой опус.

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

        1. Для начала надо выяснить, какой доменный юзер это сделал. Ок, поднимаем логи прокси, узнаем.
        2. Теперь надо увидеть, какое его действие (например, передача файла) инициировало запись в логе, разобрали, нашли.

        Мы потратили примерно 15 минут (с учетом подключения по SSH, RDP и т.п.)
        Теперь представим, что к утру у нас наклевывается 10 инцидентов (с 1000 пользователей не такая уж нереальная цифра), итого нам нужно потратить 150 минут = 2,5 часа на анализ.

        Это мы сейчас вели разговор об ОДНОМ мониторящемся критерии на одном сервере.
        А теперь представьте, что у вас 20 критичных серверов. Получается 1500 минут = 25 часов. То есть один рабочий день трех сотрудников (ну еще 20 минут обеда тоже на работу придется потратить) без перекуров, туалетов и т.п.
        И это все нужно для мониторинга ПО ОДНОМУ критерию на КАЖДОМ из 20 серверов (критерии для каждого сервера могут быть свои). Исходя из своей практики скажу, что одного критерия не бывает. Минимум — 5-10.

        Теперь включите туда человеческий фактор (замыленный глаз, ошибка, отвлекают).
        Теперь добавьте медленные каналы связи с удаленными офисами (да, бывает необходимо подключаться к удаленным компьютерам и тратить вместо 10 минут 30 из-за медленного канала).

        Картинка не очень радужная, да?

        Я там был, я это знаю.

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

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