Комментарии 15
Работает ли наш файерволл, можно узнать, выполнив ICMP ping: если правила в ACL (access control list) работают, то ответов, содержащих echo request, быть не должно.
Кто ж вас научил ICMP резать?
Как обычно, человек правильную вещь написал, а его минусуют. Хабр неизменнен.
Угу. Уже минус 3 в карму.
Для минусующих поясню: ICMP — это не только echo request/reply, это еще и redirect, всякие там destination * unreachable, сообщение о необходимости фрагментации (вот это вообще зло — если его зарезать, некоторые сети, например paypal, тупо отваливаются), и так далее.
ru.wikipedia.org/wiki/ICMP
Для минусующих поясню: ICMP — это не только echo request/reply, это еще и redirect, всякие там destination * unreachable, сообщение о необходимости фрагментации (вот это вообще зло — если его зарезать, некоторые сети, например paypal, тупо отваливаются), и так далее.
ru.wikipedia.org/wiki/ICMP
а какое это отношение имеет к статье?
Ребята же не дают в ней указания бестпрактис, или конфиги фаерволов как надо, статья вообще о другом
Ребята же не дают в ней указания бестпрактис, или конфиги фаерволов как надо, статья вообще о другом
Судя по слогу, фильтрация ICMP у них считается само собой разумеющейся.
Фраза «проверить файервол пингом» говорит о частичной некомпетентности автора. Ну вроде того ping www.google.com говорит о том, что файервол неправильно настроен.
В комментариях к статье по SIEM от конторы, занимающейся уязвимостями, обсуждают фильтрацию ICMP.
Хабрахабр оправдывает свой логотип -)
Хабрахабр оправдывает свой логотип -)
Спасибо за очередную статью, по этой интересной теме.
Как и в прошлый раз, могу спросить, да круто, да продвинуто, но для кого эти системы?
Разделение на средний и крупный бизнес думаю не корректно.
Скорее надо смотреть на вид деятельности бизнеса.
habrahabr.ru/post/172389/
Вот тут честно говорится, что SIEM это тема преимущественно банков.
Грубо говоря сотни серверов и все критичны. Человеку контролировать сложно, покупаем SIEM. Стоить это будет, как чугунный мост, но и потери от нарушений политик ИБ видны невооруженным взглядом, ибо выливаются, например, в конкретные украденные бабки.
Можно еще взять интернет гигантов, типа Яндекса. Потеря доступа миллионов пользователей к сервисам — убытки. Внедряем.
Для остального сектора, убытки косвенны и сложно считаемы.
Можно привести в пример не любимого многими Лукацкого
lukatsky.blogspot.ru/2013/03/blog-post.html
Верно пишет же — прежде чем что-то внедрять. Обоснуй. Покажи деньги.
Падение почтового сервера на пол часа, никак не скажется на выпуске тазиков Автоваза, станок как клепал кузовы так и будет клепать. Где убытки?
Или Автоваз мелкое предприятие?
Главное, это не слепо верить таким вот рекламным текстам.
Надо понимать, что если пользователь с доступом захочет украсть данные, он их украдет. Набивший оскомину пример, с фотографированием экрана — классика жанра. Не требует большого ума и хакерских навыков.
Если забыть упомянуть, в угаре выбивания «бюджетов», об этих и некоторых других так называемых остаточных рисках, то потом может быть очень больно. Руководство возьмет за шкирку и строго спросит, как так — потратили 100 лямов на SIEM с DLP, а данные все равно уплыли.
Как и в прошлый раз, могу спросить, да круто, да продвинуто, но для кого эти системы?
Разделение на средний и крупный бизнес думаю не корректно.
Скорее надо смотреть на вид деятельности бизнеса.
habrahabr.ru/post/172389/
Вот тут честно говорится, что SIEM это тема преимущественно банков.
Грубо говоря сотни серверов и все критичны. Человеку контролировать сложно, покупаем SIEM. Стоить это будет, как чугунный мост, но и потери от нарушений политик ИБ видны невооруженным взглядом, ибо выливаются, например, в конкретные украденные бабки.
Можно еще взять интернет гигантов, типа Яндекса. Потеря доступа миллионов пользователей к сервисам — убытки. Внедряем.
Для остального сектора, убытки косвенны и сложно считаемы.
Можно привести в пример не любимого многими Лукацкого
lukatsky.blogspot.ru/2013/03/blog-post.html
Верно пишет же — прежде чем что-то внедрять. Обоснуй. Покажи деньги.
Пока вы будете в авральном режиме анализировать случившееся — бизнес, скорее всего, будет простаивать, а начальство — нервничать и возмущаться. Финансовую оценку убытков от простоя предприятия легко произвести самостоятельно, благо это не так сложно.
Падение почтового сервера на пол часа, никак не скажется на выпуске тазиков Автоваза, станок как клепал кузовы так и будет клепать. Где убытки?
Или Автоваз мелкое предприятие?
Защищайте не только критические активы.
Злоумышленники получат пользовательский и административный аккаунт с незащищенных рабочих станций или с мобильных устройств и с абсолютно легитимными запросами к вашей суперзащищенной базе данных «вытянут» все, что только можно.
Главное, это не слепо верить таким вот рекламным текстам.
Надо понимать, что если пользователь с доступом захочет украсть данные, он их украдет. Набивший оскомину пример, с фотографированием экрана — классика жанра. Не требует большого ума и хакерских навыков.
Если забыть упомянуть, в угаре выбивания «бюджетов», об этих и некоторых других так называемых остаточных рисках, то потом может быть очень больно. Руководство возьмет за шкирку и строго спросит, как так — потратили 100 лямов на SIEM с DLP, а данные все равно уплыли.
Отнюдь. В России почему-то принято делить на Банки\Газ*\Все_прочие и говорить про третью категорию как «малые». SIEM изначально создавался не под отрасль, а под задачи. Compliance и policy management не только в банках. Compliance PCI DSS не ограничивается.
— Да, у Банков риски больше. Большой оборот и движение денежных средств и контролировать можно (в отличие от работы с золотыми приисками, где обороты вполне сравнимы).
— Да, банк должны повиноваться стандартам, в которых четко прописано что должно логироваться.
— Да, у них юридических инцидентов больше. А сислогом вы не обеспечите доказательную базу.
— ДА, основной русский авось «Нет обязаловки — зачем тратить деньги».
Отсюда не следует что SIEM «преимущественно» для Банков. Не стоит забывать о телекомах (провайдеры, операторы). Их конечно полно уже на рынке, но хаос полный в них. Сами очевидно знаете, что есть уже в Москве те, к которым подавляющее большинство не будут подключаться. А новые — уйдут через квартал. SIEMы им бы помогли (не буду расписывать КАК, это отдельные статьи).
Не стоит забывать о логистике, торговых компаниях. Вы не представляете какие внутри потери они несут. За счет несвоевременных поставок, утечек информации, сбоев. Вы не представляете, какие убытки они несут только из-за того, что каналы их загружены отнюдь не бизнес-приложениями (на регионах и на спутнике, поверьте, это значимо).
Ок, еще примеры? Не смейтесь, но ММОРПГ (Aion, Diablo, GoW )… Ботоводила, писала ботов. Знаю какой ущерб несут эти компании. Не поверите, SIEM помог бы им.
Дело не только в комплайнсе и наличии евентов для разбора возникшего инцидента.
фраза из трехлетней давности моей презентации — «когда в компании Le`vis рухнула база SAP, в которой находились заказы на отгрузку товара, компания понесла убытков на 48 млн. долл за сутки»
Простите, но Вы не умеете оценивать риски. Тем более в денежном эквиваленте.
Та же сумма описывалась в анекдоте про газпр* (не хочу обидеть компанию, просто вспомнилось) и туалетную бумагу.
Вопрос в стоимости информации и стоимости мер (возвращаемся к рискам). Не забывайте об этом ;)
— Да, у Банков риски больше. Большой оборот и движение денежных средств и контролировать можно (в отличие от работы с золотыми приисками, где обороты вполне сравнимы).
— Да, банк должны повиноваться стандартам, в которых четко прописано что должно логироваться.
— Да, у них юридических инцидентов больше. А сислогом вы не обеспечите доказательную базу.
— ДА, основной русский авось «Нет обязаловки — зачем тратить деньги».
Отсюда не следует что SIEM «преимущественно» для Банков. Не стоит забывать о телекомах (провайдеры, операторы). Их конечно полно уже на рынке, но хаос полный в них. Сами очевидно знаете, что есть уже в Москве те, к которым подавляющее большинство не будут подключаться. А новые — уйдут через квартал. SIEMы им бы помогли (не буду расписывать КАК, это отдельные статьи).
Не стоит забывать о логистике, торговых компаниях. Вы не представляете какие внутри потери они несут. За счет несвоевременных поставок, утечек информации, сбоев. Вы не представляете, какие убытки они несут только из-за того, что каналы их загружены отнюдь не бизнес-приложениями (на регионах и на спутнике, поверьте, это значимо).
Ок, еще примеры? Не смейтесь, но ММОРПГ (Aion, Diablo, GoW )… Ботоводила, писала ботов. Знаю какой ущерб несут эти компании. Не поверите, SIEM помог бы им.
Дело не только в комплайнсе и наличии евентов для разбора возникшего инцидента.
Верно пишет же — прежде чем что-то внедрять. Обоснуй. Покажи деньги.Правильно. Наймите опытного хорошего аудитора, он вам покажет. Не просто дыры, а деньги. Этому учат хорошие председатели\зампреды Банков (не потому что банки, а потому что их и так доят все кому попало ;) ). А пока нет нормального обоснования и нет желания понять свои ошибки — интеграторы будут разворачиваться на пороге бюджетного кошелька на 180 градусов.
Падение почтового сервера на пол часа, никак не скажется на выпуске тазиков Автоваза, станок как клепал кузовы так и будет клепать. Где убытки?
Или Автоваз мелкое предприятие?
фраза из трехлетней давности моей презентации — «когда в компании Le`vis рухнула база SAP, в которой находились заказы на отгрузку товара, компания понесла убытков на 48 млн. долл за сутки»
Простите, но Вы не умеете оценивать риски. Тем более в денежном эквиваленте.
потратили 100 лямов на SIEM с DLP, а данные все равно уплыли
Та же сумма описывалась в анекдоте про газпр* (не хочу обидеть компанию, просто вспомнилось) и туалетную бумагу.
Вопрос в стоимости информации и стоимости мер (возвращаемся к рискам). Не забывайте об этом ;)
Вообщем, простите. Но наша компания не интеграторы. Мы не впариваем решение SIEM :) Мы помогаем в оценке рисков. Моя миссия — это сказать в чем и как SIEM может помочь, попытаться рассказать о механизмах работы SIEM-систем общими понятными словами. Что я и пытаюсь сделать. Говорить в общих словах о рисках применительно для всех компаний, естественно, некорректно. Каждый сам должен оценить свои риски. И сделать свой вывод — что ему нужно SIEM\DLP или вообще ничего.
Давайте без холивара :)
Давайте без холивара :)
Да что вы говорите?! Интеграторы черные, а вы позитивные? Не стоит забывать, что интеграторы «впаривают» в том числе и ваши продукты, т.к. у них (продуктов) только такой канал доставки.
Интеграторы впаривают, но никто не мешает вам отказать этим интеграторам. Это рынок, такой же, как и мясной или обувной. Там вам тоже каждый пытается что-то впарить, но вы же не покупаете все и у каждого =)
А дойти до того, нужно вам это или нет можно и самостоятельно. Вот я четко понимаю, где в моей деятельности SIEM нужна, а где — нет =)
А дойти до того, нужно вам это или нет можно и самостоятельно. Вот я четко понимаю, где в моей деятельности SIEM нужна, а где — нет =)
Еще момент, возвращаясь к некритическим активам.
Не кажется ли Вам, что тут возникает некое противоречие.
и вот этим
То контролируйте все по-максимуму, даже не критичные, а то мало ли что…
То не контролируйте, ибо флуд, запаритесь реагировать.
Вы представляете какой поток событий будут генерить 1000 рабочих станций, с включенным мониторингом Всего по максимуму? Не Вы ли писали про бедолагу который накрутил, максимальный мониторинг, а потом упарился очищать свои базы от миллионов событий нападавших за сутки.
Нешто злобные хакеры постарались?:)
У меня на одной из предыдущих работ как то молния ударила в серверную (по чесноку). Одна стойка вылетела напрочь, хорошо была вторая в кластере.
Я не зря писал про почтовый сервер, который может вылететь на пол-часа в самом плохом варианте и ничего страшного.
Если у компании сервера вылетают на сутки, значит нужно искать проблемы в отсутствии грамотной кластеризации, резервного копирования, а не в наличии/отсутствии SIEM-а.
В прошлый раз уже обсуждалось. SIEM это не оракул/провидец. Сначала инцидент все таки случится, а потом уже SIEM об этом оповестит и последует оперативная реакция.
Если конечно операторы SIEM-а будут вовремя смотреть консоль управления, а не спать на рабочем месте, поскольку до этого всю ночь клубились по тусовкам. :)
Не кажется ли Вам, что тут возникает некое противоречие.
Защищайте не только критические активы…
…
Это пример типовой атаки по модели APT. Запущенные процессы, новые библиотеки в OС, новые сервисы, открытые порты и соединения, повышение привилегий — все это можно увидеть в журналах событий на рабочих станциях
и вот этим
Акценты
…
как и в случае с DLP-системами, здесь необходимо правильное внедрение, интеграция с источниками событий, индивидуальный подход к активному набору правил и алгоритмам корреляции. Гибкая система исключений и правильная настройка SIEM гарантируют вам акцент только на критически важных событиях — без флуда.
То контролируйте все по-максимуму, даже не критичные, а то мало ли что…
То не контролируйте, ибо флуд, запаритесь реагировать.
Вы представляете какой поток событий будут генерить 1000 рабочих станций, с включенным мониторингом Всего по максимуму? Не Вы ли писали про бедолагу который накрутил, максимальный мониторинг, а потом упарился очищать свои базы от миллионов событий нападавших за сутки.
«когда в компании Le`vis рухнула база SAP, в которой находились заказы на отгрузку товара, компания понесла убытков на 48 млн. долл за сутки»
Нешто злобные хакеры постарались?:)
У меня на одной из предыдущих работ как то молния ударила в серверную (по чесноку). Одна стойка вылетела напрочь, хорошо была вторая в кластере.
Я не зря писал про почтовый сервер, который может вылететь на пол-часа в самом плохом варианте и ничего страшного.
Если у компании сервера вылетают на сутки, значит нужно искать проблемы в отсутствии грамотной кластеризации, резервного копирования, а не в наличии/отсутствии SIEM-а.
IТ-отделу также хочется узнавать о возникающих инцидентах не по звонку пользователей, а заранее (тем более, что — как и инциденты ИБ — IТ-инциденты можно предотвратить).
В прошлый раз уже обсуждалось. SIEM это не оракул/провидец. Сначала инцидент все таки случится, а потом уже SIEM об этом оповестит и последует оперативная реакция.
Если конечно операторы SIEM-а будут вовремя смотреть консоль управления, а не спать на рабочем месте, поскольку до этого всю ночь клубились по тусовкам. :)
Доброго дня.
Нет, не кажется.
Я не говорила про флуд. False positives будут всегда. Другое дело в каком объеме. Если их нет вообще — то система скорее всего либо не работает (или недостаточно правил корреляции для обнаружения угроз, либо вы не дооцениваете своих специалистов, корректирующих работу SIEM.
Ой, представляю, ибо работала на гораздо больших объемах инфраструктуры ;) «Включенный мониторинг по максимуму» — это неправильный подход. Отсюда и получают потом кучу ложных инцидентов. Необходимо учитывать риски, активировать и редактировать правила корреляции согласно ваших (!) угроз.
Те же 900 рабочих станций скорее всего необходимо контролировать (для более точного утверждения — необходимы данные). Почему?! Вы защитили 100 серверов. А со взломанной рабочей станции можно легитимно имитировать работу пользователя и сливать информацию. Почему? Потому что вы не учли в оценке рисков где обрабатывается ваша мегаценная информация. По вашим рассчетам она ведь находится где то на этих 100 серверах. Поэтому я не вижу в своих словах противоречий.
Опять же вернемся к анализу рисков?) Что вы можете увидеть в SIEM из ИТ сбоев? Из практики: начинающиеся сбои в аппаратном\программном рейде, об ошибка в старте сервисов, о падении сервиса или ошибках в БД, о сбоях в средствах защиты (тот же антивирус вырубается или обнуляются правила и настройки), о конфликте ip адресов (прошу, не надо холивара, это также критическое событие для ряда информационных систем и в разветвленной инфраструктуре ищется долго ;) ) и прочее, прочее. Вовсе не бесполезны системы мониторинга ака nagios. Но эти системы мониторинга говорят по факту. Каждому инциденту присутствуют симптомы. Падению информационной системы будут предшествовать скорее всего разрозненные по журналам событий различные ошибки. Конфликту IP — возникновение нового актива в вашей инфраструктуре или входу с повышенными привилегиями. Пример из практики. Один из множества. Были у меня серверы приложений на Citrix. Симантек антивирус (SEP) падал на ферме с bsod. Оказалось по факту — что пользователь формировал большой отчет в домашней директории определенного формата. Да, я не смогла предотвратить первый инцидент. Он возник. Но не без пользы. SIEM помог мне выявить причину. Оперативно. После расследования инцидента, я создала правило корреляции.Правило содержало активный сценарий. Больше инцидентов не было, даже если появлялись пользователи-умельцы. Активный сценарий мне помогал предотвращать возникновение инцидента.
Пример 2. Securit Zserver падал с сервером в bsod, если путь до файла был больше 256 символов. Опять же — сценарий в правиле помогал мне в предотвращении многочисленных инцидентов.
Пример 3. Установлены политики блокировки учетных записей? Вот представьте что будет если под учетной записью под которой крутится сервис попытаются зайти N-раз под неправильным паролем? А вот тут вотработает в SIEM не только лог-менеджмент и классические правила корреляции присутстствующие во всех SIEM. Здесь уже работает оценка рисков и взаимосвязь с бизнес активами. Да, с точки зрения ИТ-ИБ произойдет возможная блокировка учетной записи. НО! На самом деле может произойти остановка бизнес-процесса(!). Сервис, отвечающий за работу информационной системы будет остановлен. Информационная система перестанет быть доступной. Бизнес-процесс будет остановлен. Простой. Сколько он будет стоить бизнесу- можно посчитать.
Искать эти события глазками в разрозненных или даже сконсолидированных в одну базу событиях — это утопия. Интеллектуальная логика позволяет автоматически (!) выявлять инциденты и сообщать мне о проблемах во время. С SIEM я всегда знаю что имеются проблемы в информационной системе, что происходит в инфраструктуре. И на что это влияет.
Вот опять же — не всегда. Холиварный вопрос, который нужно обсуждать не в комментариях. Я говорила о предшествующих симптомах. Они почти всегда есть. Интеграции с различными системами позволяют видеть это своевременно в SIEM. Часть поставляемых правил корреляции — это накопленная база знаний уже случившихся инцидентов. Устав, написанный кровью. Используйте его. К тому же, есть MAEC, CAPEC написанные также не зря. Они также должны транслироваться в правила корреляции с учетом игроз для вашей компании.И пополняемые.
Вот для этого необходим SIEM. SOC-а 24x7 может и не быть. Оператор будет клубиться уже с неспокойной душой, когда ему на мобильник прийдет инцидент. И SIEM эволюционирует из лог-менеджмента для того, чтобы постоянно не пялиться в консоль, выявляя инциденты, а работать с автоматически зарегистрированными инцидентами. Вы даже не представляете какой кайф от такой автоматизации. Какие ресурсы высвобождаются. Поверьте, говорю по опыту. =)
Не кажется ли Вам, что тут возникает некое противоречие.
Нет, не кажется.
Я не говорила про флуд. 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 эволюционирует из лог-менеджмента для того, чтобы постоянно не пялиться в консоль, выявляя инциденты, а работать с автоматически зарегистрированными инцидентами. Вы даже не представляете какой кайф от такой автоматизации. Какие ресурсы высвобождаются. Поверьте, говорю по опыту. =)
Вот читаю вас, Олеся, и просто бальзам на душу =)
Вообще, моя личная практика показывает, что подобные системы критикуют таким образом только люди, которые не сталкивались с проблемами, решать которые эти системы призваны. Либо сталкивались, но не с позиции человека, несущего ответственность, а с позиции стороннего наблюдателя =)
Я в свое время тоже погряз в скриптах, отчетах на почту и т.п.
От себя могу добавить вот такой опус.
Когда я начал работать с хозяйством, поддерживающим 1000 юзеров, я точно так же пилил анализаторы syslog'а на php, которые писали мне на почту о каком-то событии. НО, понять, инцидент это или нет, беглым взглядом невозможно. Допустим, в syslog'е мы видим, что такой-то IP совершил мониторящееся нами действие. Ок, копаем.
1. Для начала надо выяснить, какой доменный юзер это сделал. Ок, поднимаем логи прокси, узнаем.
2. Теперь надо увидеть, какое его действие (например, передача файла) инициировало запись в логе, разобрали, нашли.
Мы потратили примерно 15 минут (с учетом подключения по SSH, RDP и т.п.)
Теперь представим, что к утру у нас наклевывается 10 инцидентов (с 1000 пользователей не такая уж нереальная цифра), итого нам нужно потратить 150 минут = 2,5 часа на анализ.
Это мы сейчас вели разговор об ОДНОМ мониторящемся критерии на одном сервере.
А теперь представьте, что у вас 20 критичных серверов. Получается 1500 минут = 25 часов. То есть один рабочий день трех сотрудников (ну еще 20 минут обеда тоже на работу придется потратить) без перекуров, туалетов и т.п.
И это все нужно для мониторинга ПО ОДНОМУ критерию на КАЖДОМ из 20 серверов (критерии для каждого сервера могут быть свои). Исходя из своей практики скажу, что одного критерия не бывает. Минимум — 5-10.
Теперь включите туда человеческий фактор (замыленный глаз, ошибка, отвлекают).
Теперь добавьте медленные каналы связи с удаленными офисами (да, бывает необходимо подключаться к удаленным компьютерам и тратить вместо 10 минут 30 из-за медленного канала).
Картинка не очень радужная, да?
Я там был, я это знаю.
Вообще, моя личная практика показывает, что подобные системы критикуют таким образом только люди, которые не сталкивались с проблемами, решать которые эти системы призваны. Либо сталкивались, но не с позиции человека, несущего ответственность, а с позиции стороннего наблюдателя =)
Я в свое время тоже погряз в скриптах, отчетах на почту и т.п.
От себя могу добавить вот такой опус.
Когда я начал работать с хозяйством, поддерживающим 1000 юзеров, я точно так же пилил анализаторы syslog'а на php, которые писали мне на почту о каком-то событии. НО, понять, инцидент это или нет, беглым взглядом невозможно. Допустим, в syslog'е мы видим, что такой-то IP совершил мониторящееся нами действие. Ок, копаем.
1. Для начала надо выяснить, какой доменный юзер это сделал. Ок, поднимаем логи прокси, узнаем.
2. Теперь надо увидеть, какое его действие (например, передача файла) инициировало запись в логе, разобрали, нашли.
Мы потратили примерно 15 минут (с учетом подключения по SSH, RDP и т.п.)
Теперь представим, что к утру у нас наклевывается 10 инцидентов (с 1000 пользователей не такая уж нереальная цифра), итого нам нужно потратить 150 минут = 2,5 часа на анализ.
Это мы сейчас вели разговор об ОДНОМ мониторящемся критерии на одном сервере.
А теперь представьте, что у вас 20 критичных серверов. Получается 1500 минут = 25 часов. То есть один рабочий день трех сотрудников (ну еще 20 минут обеда тоже на работу придется потратить) без перекуров, туалетов и т.п.
И это все нужно для мониторинга ПО ОДНОМУ критерию на КАЖДОМ из 20 серверов (критерии для каждого сервера могут быть свои). Исходя из своей практики скажу, что одного критерия не бывает. Минимум — 5-10.
Теперь включите туда человеческий фактор (замыленный глаз, ошибка, отвлекают).
Теперь добавьте медленные каналы связи с удаленными офисами (да, бывает необходимо подключаться к удаленным компьютерам и тратить вместо 10 минут 30 из-за медленного канала).
Картинка не очень радужная, да?
Я там был, я это знаю.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SIEM для ИТ и ИБ