Не кажется ли Вам, что тут возникает некое противоречие.
Нет, не кажется.
Я не говорила про флуд. 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 эволюционирует из лог-менеджмента для того, чтобы постоянно не пялиться в консоль, выявляя инциденты, а работать с автоматически зарегистрированными инцидентами. Вы даже не представляете какой кайф от такой автоматизации. Какие ресурсы высвобождаются. Поверьте, говорю по опыту. =)
Вообщем, простите. Но наша компания не интеграторы. Мы не впариваем решение SIEM :) Мы помогаем в оценке рисков. Моя миссия — это сказать в чем и как SIEM может помочь, попытаться рассказать о механизмах работы SIEM-систем общими понятными словами. Что я и пытаюсь сделать. Говорить в общих словах о рисках применительно для всех компаний, естественно, некорректно. Каждый сам должен оценить свои риски. И сделать свой вывод — что ему нужно SIEM\DLP или вообще ничего.
Давайте без холивара :)
Отнюдь. В России почему-то принято делить на Банки\Газ*\Все_прочие и говорить про третью категорию как «малые». SIEM изначально создавался не под отрасль, а под задачи. Compliance и policy management не только в банках. Compliance PCI DSS не ограничивается.
— Да, у Банков риски больше. Большой оборот и движение денежных средств и контролировать можно (в отличие от работы с золотыми приисками, где обороты вполне сравнимы).
— Да, банк должны повиноваться стандартам, в которых четко прописано что должно логироваться.
— Да, у них юридических инцидентов больше. А сислогом вы не обеспечите доказательную базу.
— ДА, основной русский авось «Нет обязаловки — зачем тратить деньги».
Отсюда не следует что SIEM «преимущественно» для Банков. Не стоит забывать о телекомах (провайдеры, операторы). Их конечно полно уже на рынке, но хаос полный в них. Сами очевидно знаете, что есть уже в Москве те, к которым подавляющее большинство не будут подключаться. А новые — уйдут через квартал. SIEMы им бы помогли (не буду расписывать КАК, это отдельные статьи).
Не стоит забывать о логистике, торговых компаниях. Вы не представляете какие внутри потери они несут. За счет несвоевременных поставок, утечек информации, сбоев. Вы не представляете, какие убытки они несут только из-за того, что каналы их загружены отнюдь не бизнес-приложениями (на регионах и на спутнике, поверьте, это значимо).
Ок, еще примеры? Не смейтесь, но ММОРПГ (Aion, Diablo, GoW )… Ботоводила, писала ботов. Знаю какой ущерб несут эти компании. Не поверите, SIEM помог бы им.
Дело не только в комплайнсе и наличии евентов для разбора возникшего инцидента.
Верно пишет же — прежде чем что-то внедрять. Обоснуй. Покажи деньги.
Правильно. Наймите опытного хорошего аудитора, он вам покажет. Не просто дыры, а деньги. Этому учат хорошие председатели\зампреды Банков (не потому что банки, а потому что их и так доят все кому попало ;) ). А пока нет нормального обоснования и нет желания понять свои ошибки — интеграторы будут разворачиваться на пороге бюджетного кошелька на 180 градусов.
Падение почтового сервера на пол часа, никак не скажется на выпуске тазиков Автоваза, станок как клепал кузовы так и будет клепать. Где убытки?
Или Автоваз мелкое предприятие?
фраза из трехлетней давности моей презентации — «когда в компании Le`vis рухнула база SAP, в которой находились заказы на отгрузку товара, компания понесла убытков на 48 млн. долл за сутки»
Простите, но Вы не умеете оценивать риски. Тем более в денежном эквиваленте.
потратили 100 лямов на SIEM с DLP, а данные все равно уплыли
Та же сумма описывалась в анекдоте про газпр* (не хочу обидеть компанию, просто вспомнилось) и туалетную бумагу.
Вопрос в стоимости информации и стоимости мер (возвращаемся к рискам). Не забывайте об этом ;)
SIEM не равно продукт из коробки. Есть предзаданные правила корреляции. Правила корреляции пишутся дополнительно при интеграции. Правила дополняются при пентестах, аудитах и т.п. (PDCA).
Простому оператору не стоит доверять писать правила корреляции. Вообще, чем больше правил корреляции — тем больше нагрузка на сервер (см. мои статьи в цикле по SIEM. Счетчики и триггеры висят в памяти)
Маской описывается кейс запуска процессов или сетевых коннектах при отсутствии сотрудника (интеграция агента и скуда — уже в практике давно применяется, но реализация возможна не на всех сиемах).
Статистика дашбордов репрезентативно показывает всплески от baseline.
Не только банковский сектор. Почти в каждой организации есть банк-клиенты. Представьте что с компьютера бухгалтера переводят максимальную сумму со счета в оффшор. И не важно кто это сделал — троян, сам главный бухгалтер или новая сотрудница с нулевыми знаниями в хакинге.
Представьте, что кто то заимел халявную ноду и поднял VPS. Или сливает по 10-20 литров бензина за смену когда температура в хранилище нагревается до определенного значения. Или когда запускаются процессы на компьютере генерального директора в его отсутствие и отсутствии VPN к его компьютеру.
Когда события собраны в единое хранилище со всех источников (либо таких хранилищ несколько) по ним можно делать корреляцию и определять взаимосвязи, отслеживать тенденции. Открываем дашбоард, и видим всплески трафика на порт, видим кучу неуспешных попыток входа, а затем успешную. Без SIEM эти факты еще предстоит выяснить, после того как мы узнаем об утечке или удалении, к примеру, всей корпоративной информации на файловом хранилище. Или нанимать кучу людей которые будут мониторить логи. Как часто можно смотреть те же журналы событий на VPN? а если Катя, которая все время коннектилась с акадо-москва вдруг залезла на vpn с тайваня? SIEM это увидит, сгенерирует инцидент. причем это должно быть не просто письмо в электронную почту (ибо через неделю никто не будет читать их, или сотрудник заболеет, или сработает человеческий фактор и он попросту пропустит событие при просмотре, потому что клубился всю ночь.
Логи DLP и антивирусного ПО тоже надо смотреть. И конфигурации с логов читать.В противном случае — насколько будет уверено руководство компании что месяц назад админ-ИБ-смотрящий-DLP не взял шоколадку и пропустил за это событие ака «Ваня отослал на какой-то ящик список ваших сотрудников». Антивирусное ПО — да, можно в ПО смотреть ситуацию. Но очень сложно организовать работу, при которой во всей инфраструктуре установлено ПО, обновлено до актуальных баз и с правильными настройками согласно ваших политик и инструкций.
Для ИТ будет лучше поскорее узнать о том что отказал диск в рейде или сервис застопорился. Не по звонку от рассерженных пользователей, которые потеряли часть данных. Да, можно и скриптами. Их не один десяток придется написать. И не одну сотню. Уверены что ИТ специалист среагирует на этот алерт? Или все же лучше зарегистрировать инцидент с опеределенным приоритетом, фиксированными сроками решения и эскалацией в случае его просрочки?
Это все ИТ-Ибшные части. Сейчас все SIEM стремятся приоритезировать инциденты по результатам корреляций и с учетом рисков, исходя из ценности актива, его участия в бизнес-процессах и т.д. В итоге, вы сможете увидеть на какие бизнес-процессы влияют те или иные события.И что будет если остановить сервис\удалить пользователя\не закрыть уязвимость.
Источников много. Угроз и векторов атак еще больше. Нельзя полагаться на «поставил и забыл».
Данная статья не позиционировалась как «купите SIEM, без него нельзя». Можно. Но только когда инфраструктура небольших размеров. С ростом, появляется множество задач по контролю и соблюдению. Политики мало написать, «закрутить гайки» и спокойно пить кофе. Необходимо контролировать их соблюдение. Оправдание «Средний навык рядового пользователя по хакингу систем колышется около 0 уровня» нужно держать в себе и в одном из пунктов модели нарушителя.
Логи бекапятся, ок. Но с какой переодичностью? Достаточной для расследования инцидента? А можно быть уверенной что все необходимые события там будут? Может кто то случайно назначит GPO и там будет лишь пустота. Гарантируется ли юридическая значимость этих забекапленных логов? А если будет многомиллионная транзакция?! Вы сможете привести в суде доказательства, что это действительно те самы логи с того самого сервера, а не фальсифицированные доказательства?!.. Можно их перенаправлять и на Syslog. Но опять же — где кдц. Да и не все источники могут поддерживать tcp syslog — в противном случае, часть событий при потоке выше 5-7к eps syslog udp скорее всего будут потеряны (по результатам тестирования).
SIEM не панацея от 0-day и всех-всех угроз. SIEM — средство автоматизации.
SIEM автоматизирует монотонную работу с журналами событий, выстраивает процессы инцидент-менеджмента, приоритезируя инциденты и фокусируя внимание подразделений ИТ и ИБ на важных для бизнеса. Дополняет процессы управления политиками и комплайнса, управления конфигурациями…
Приходите на рускрипто-2013, у меня как раз будет выступление и пообщаемся в колуарах. Переубеждать я не намеряна, просто расскажу :)
То есть, вы с помощью политик домена контролируете «все и вся» и при этом:
— пользователь не может загрузиться с livecd\usb и нарушить работу вашей инфраструктуры
— пользователь не может повысить привилегии
— нельзя получить административный аккаунт доменного админа или к какой либо информационной системе
— пользователь не может несанкционированно запустить софт (в т.ч. portable)
— о появлении вируса\атаки\угрозы\утечки вы в режиме реального времени узнаете и отреагируете (!) и все будет документировано?!
— вы сможете предоставить юрилически значимые журналы событий когда к вам придут и скажут что ваша компания ддосит кремлинру?
— вы сможете сказать кто и когда изменил настройки на сервере\рабочей станции\базе данных\роутере\файерволле?
Если все «да» и вы это сделали с помощью домена — честь и благодать Вам.
Добрый день!
Общая цель — защищенность. Аудиторские проверки на соответствие стандартам не у всех проводятся. Если нет требований отраслевых или компания не прошла сертификацию по ISO, то зачем аудиторские проверки? Так считаю многие, отодвигая все стандарты в сторону и начиная изобретать велосипед в виде внутренних бумажных политик без контроля их соблюдения. Максимум что делают в подобном лучшем случае — заказывают сторонний аудит ИБ. А можно взять за основу политик контроли, указанные в стандартах, расширить их и контролировать их соблюдение. Согласитесь, что часть требований стандартов — это азы информационной безопасности, которые необходимо соблюдать и контролировать. Если они не учтены — то о какой безопасности может идти речь?
Давайте забудем про минусомет и объективно рассудим.
Говоря фразу «Вы в корне неправы.» я имела ввиду ваш коммент в котором я это написала а не статью. Не следует воспринимать комментарии не содержащие «о, спасибо, клево» как атаку на вас.
Цель статьи какая? Рассказать про CEF? Ну подготовьтесь, изучите его сначала сами, посмотрите — а какие есть проблемы у siem\sim систем в рамках типизации событий. Приведите примеры плюсов и минусов использования CEF. Посмотрите кто использует CEF и как. В данном случае вы объективно этого не понимаете. Пример — продукт компании в которой я работаю в данное время интегрирован с ArcSight. Но это не означает, что мы используем CEF.
Примеры? «Подключение нового источника событий превращается в «plug and play»» Вот ведь не так на практике, да?! Да, с типизацией на стороне источника, с которым интегрируемся или агента (когда в siem приходят уже нормализованные типизированные события) все намного проще становится. Можно и фильтрацию делать, и ресурсы сервера на типизацию не тратятся. И правилами корреляции по ним можно работать и методами пройтись…
" Его уже применяют и в других решениях, связанных с обработкой логов." Можно примеры? Просто примеры классов решений. Или вендоров. Для саморазвития. Может, я просто фразу не поняла.
«Вы мне лучше приведите ссылку, по которой я смогу пройти и убедиться, что формат CEE поддерживает большее (чем формат CEF) количество вендоров»
CEE: Tripware, Sensage
CEF: ArcSight
Это siem-ы. То что указали вы, еще раз, при всем уважении, это «CEF Connectors and Action Connectors», но не использование CEF партнерами для своих продуктов.
У CEF, равно как и у остальных, есть свои плюсы и минусы. Насколько я знаю из блогов, CEF хотели модифицировать, развить, так как не совсем устраивал.
Про udp доставку, я надеюсь, вы знаете. 100 км от мкад и там такие каналы связи «замечательные»… Про спутник — тоже. Встает сразу проблема целостности передачи. Ну а про защищенность udp я промолчу.
«CEF Connectors and Action Connectors are the foundation for interoperability between ArcSight and partner technologies which can be certified to benefit our joint-customers»
Это не склоняются именно к CEF", они используют его для интеграции. Это разные вещи. Приведу простой пример. Вам нужно (именно вам, потребность) позвонить в Штаты. Вы им предлагаете заговорить с вами на русском, или все же будете на инглише разговаривать?
illuzii, вы правы. Но у подавляющего большинства пользователей, как показывает практика, открыт профиль. И это по умолчанию. Названная вами функция скрыта. Почему не дать возможность пользователю самому закрыть предоставив настройку?
illuzii, простите за использование вас в комментарии, но! site:ebay.com intext:«illuzii» и получаем:
Я при поиске товара вывожу только топ-селлеров. Потом смотрю его feedback. Недобросовестные «топы» частенько с разных аккаунтов переводят суммы $0.1-1 чтобы поставить повысить рейтинг.
Активно пользуюсь ebay только последние года два. Не помню чтобы использовались звездочки.
Сейчас часть итемов пишется как item #… Но он легко находится по этому номеру на самом ebay или в google.
Агрессии никакой нет. Опишите произошедшие случае термином не-APT. Атаки были раньше. APT замечать стали с 2006 года. Nortel — самый давний случай, известный на данный момент времени. Уверена, еще вспылывет что то впоследствии. Про APT на РусКрипто слышали. Никто не поднял руку на мой вопрос об APT в России. Потому что не знали, не слышали, «о! APT! а что это? А, понял, ну ладно, это все нацелено не в России, это все на *gov*».
Dsec я упомянула лишь потому что вижу пессимистичность к защите. Она бросается в глаза мне лично, как аналитику. Если человек показывает пессимизм к мерам защиты — значит на уровне корпоративной защиты тоже есть изъяны («осведомленность»). Значит — можно использовать. Обидеть не преследовала цель. Хотя, в день рождения настроение с минусами мне вы попортили.
Какую «репрезентативную» статистику вы хотели бы увидеть? Она есть в аналитике McAfee, Symantec. Копипастить их отчеты не преследовала целью. Подробные наименования компаний вы вряд ли найдете — не принято в России. Равно, как не принято сообщать об инцидентах.
Угрозы были и будут.
Парадигма их, состав и последовательность будут меняться.
Красиво или нет — вы решаете индивидуально для себя. Термин придумали не вы, не я. И не зря.
Комплекс мер по защите для различных угроз разный. Статистика компаний, подвергшихся атаке, позволяет судить что меры не принимаются, или принимаются некорректно.
Можно сложить ручки и пессиместично чего то ждать — угрозы то по вашим словам есть и будут… А можно попытаться донести до аудитории, разъяснить, чтобы не было им потом печально. Из аудитории на РусКрипто никто не знал об APT в России. Не из за пессимистичности ли? Ведь «термин был моден в 2009-2010». Про 2011 и 2012 d00kie наверное вы не успели прочитать.
Задумалась — может стоит взять на следующую статью в качестве примера dsec?
В статье написано, что угрозы были. Социальная инженерия использовалась. 0-day были. Шпионаж тоже. Но APT это все же новая парадигма. Согласно неё — злоумышленник не старается обнаружить себя или выкинуть информацию в паблик (скажем, обналичить по украденным из банка данным), или опубликовать, как это делают Anonymous (хоть факт передачи им информации из APT был). Обнаружение APT сложнее в разы за счет многих факторов — индивидуального подхода к жертве, тщательного скрытия, мониторинга контрмер и т.д… APT — это новая школа для ИБ. Построенная на ошибках, заблуждении, беспечности нашей с вам защиты, професиональном комплексном подходе атакующих. APT нельзя сравнивать с ранее проводившимися атаками.
Нет, не кажется.
Я не говорила про флуд. 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 эволюционирует из лог-менеджмента для того, чтобы постоянно не пялиться в консоль, выявляя инциденты, а работать с автоматически зарегистрированными инцидентами. Вы даже не представляете какой кайф от такой автоматизации. Какие ресурсы высвобождаются. Поверьте, говорю по опыту. =)
Давайте без холивара :)
— Да, у Банков риски больше. Большой оборот и движение денежных средств и контролировать можно (в отличие от работы с золотыми приисками, где обороты вполне сравнимы).
— Да, банк должны повиноваться стандартам, в которых четко прописано что должно логироваться.
— Да, у них юридических инцидентов больше. А сислогом вы не обеспечите доказательную базу.
— ДА, основной русский авось «Нет обязаловки — зачем тратить деньги».
Отсюда не следует что SIEM «преимущественно» для Банков. Не стоит забывать о телекомах (провайдеры, операторы). Их конечно полно уже на рынке, но хаос полный в них. Сами очевидно знаете, что есть уже в Москве те, к которым подавляющее большинство не будут подключаться. А новые — уйдут через квартал. SIEMы им бы помогли (не буду расписывать КАК, это отдельные статьи).
Не стоит забывать о логистике, торговых компаниях. Вы не представляете какие внутри потери они несут. За счет несвоевременных поставок, утечек информации, сбоев. Вы не представляете, какие убытки они несут только из-за того, что каналы их загружены отнюдь не бизнес-приложениями (на регионах и на спутнике, поверьте, это значимо).
Ок, еще примеры? Не смейтесь, но ММОРПГ (Aion, Diablo, GoW )… Ботоводила, писала ботов. Знаю какой ущерб несут эти компании. Не поверите, SIEM помог бы им.
Дело не только в комплайнсе и наличии евентов для разбора возникшего инцидента.
Правильно. Наймите опытного хорошего аудитора, он вам покажет. Не просто дыры, а деньги. Этому учат хорошие председатели\зампреды Банков (не потому что банки, а потому что их и так доят все кому попало ;) ). А пока нет нормального обоснования и нет желания понять свои ошибки — интеграторы будут разворачиваться на пороге бюджетного кошелька на 180 градусов.
фраза из трехлетней давности моей презентации — «когда в компании Le`vis рухнула база SAP, в которой находились заказы на отгрузку товара, компания понесла убытков на 48 млн. долл за сутки»
Простите, но Вы не умеете оценивать риски. Тем более в денежном эквиваленте.
Та же сумма описывалась в анекдоте про газпр* (не хочу обидеть компанию, просто вспомнилось) и туалетную бумагу.
Вопрос в стоимости информации и стоимости мер (возвращаемся к рискам). Не забывайте об этом ;)
Простому оператору не стоит доверять писать правила корреляции. Вообще, чем больше правил корреляции — тем больше нагрузка на сервер (см. мои статьи в цикле по SIEM. Счетчики и триггеры висят в памяти)
Маской описывается кейс запуска процессов или сетевых коннектах при отсутствии сотрудника (интеграция агента и скуда — уже в практике давно применяется, но реализация возможна не на всех сиемах).
Статистика дашбордов репрезентативно показывает всплески от baseline.
Представьте, что кто то заимел халявную ноду и поднял VPS. Или сливает по 10-20 литров бензина за смену когда температура в хранилище нагревается до определенного значения. Или когда запускаются процессы на компьютере генерального директора в его отсутствие и отсутствии VPN к его компьютеру.
Когда события собраны в единое хранилище со всех источников (либо таких хранилищ несколько) по ним можно делать корреляцию и определять взаимосвязи, отслеживать тенденции. Открываем дашбоард, и видим всплески трафика на порт, видим кучу неуспешных попыток входа, а затем успешную. Без SIEM эти факты еще предстоит выяснить, после того как мы узнаем об утечке или удалении, к примеру, всей корпоративной информации на файловом хранилище. Или нанимать кучу людей которые будут мониторить логи. Как часто можно смотреть те же журналы событий на VPN? а если Катя, которая все время коннектилась с акадо-москва вдруг залезла на vpn с тайваня? SIEM это увидит, сгенерирует инцидент. причем это должно быть не просто письмо в электронную почту (ибо через неделю никто не будет читать их, или сотрудник заболеет, или сработает человеческий фактор и он попросту пропустит событие при просмотре, потому что клубился всю ночь.
Логи DLP и антивирусного ПО тоже надо смотреть. И конфигурации с логов читать.В противном случае — насколько будет уверено руководство компании что месяц назад админ-ИБ-смотрящий-DLP не взял шоколадку и пропустил за это событие ака «Ваня отослал на какой-то ящик список ваших сотрудников». Антивирусное ПО — да, можно в ПО смотреть ситуацию. Но очень сложно организовать работу, при которой во всей инфраструктуре установлено ПО, обновлено до актуальных баз и с правильными настройками согласно ваших политик и инструкций.
Для ИТ будет лучше поскорее узнать о том что отказал диск в рейде или сервис застопорился. Не по звонку от рассерженных пользователей, которые потеряли часть данных. Да, можно и скриптами. Их не один десяток придется написать. И не одну сотню. Уверены что ИТ специалист среагирует на этот алерт? Или все же лучше зарегистрировать инцидент с опеределенным приоритетом, фиксированными сроками решения и эскалацией в случае его просрочки?
Это все ИТ-Ибшные части. Сейчас все SIEM стремятся приоритезировать инциденты по результатам корреляций и с учетом рисков, исходя из ценности актива, его участия в бизнес-процессах и т.д. В итоге, вы сможете увидеть на какие бизнес-процессы влияют те или иные события.И что будет если остановить сервис\удалить пользователя\не закрыть уязвимость.
Источников много. Угроз и векторов атак еще больше. Нельзя полагаться на «поставил и забыл».
Логи бекапятся, ок. Но с какой переодичностью? Достаточной для расследования инцидента? А можно быть уверенной что все необходимые события там будут? Может кто то случайно назначит GPO и там будет лишь пустота. Гарантируется ли юридическая значимость этих забекапленных логов? А если будет многомиллионная транзакция?! Вы сможете привести в суде доказательства, что это действительно те самы логи с того самого сервера, а не фальсифицированные доказательства?!.. Можно их перенаправлять и на Syslog. Но опять же — где кдц. Да и не все источники могут поддерживать tcp syslog — в противном случае, часть событий при потоке выше 5-7к eps syslog udp скорее всего будут потеряны (по результатам тестирования).
SIEM не панацея от 0-day и всех-всех угроз. SIEM — средство автоматизации.
SIEM автоматизирует монотонную работу с журналами событий, выстраивает процессы инцидент-менеджмента, приоритезируя инциденты и фокусируя внимание подразделений ИТ и ИБ на важных для бизнеса. Дополняет процессы управления политиками и комплайнса, управления конфигурациями…
Приходите на рускрипто-2013, у меня как раз будет выступление и пообщаемся в колуарах. Переубеждать я не намеряна, просто расскажу :)
— пользователь не может загрузиться с livecd\usb и нарушить работу вашей инфраструктуры
— пользователь не может повысить привилегии
— нельзя получить административный аккаунт доменного админа или к какой либо информационной системе
— пользователь не может несанкционированно запустить софт (в т.ч. portable)
— о появлении вируса\атаки\угрозы\утечки вы в режиме реального времени узнаете и отреагируете (!) и все будет документировано?!
— вы сможете предоставить юрилически значимые журналы событий когда к вам придут и скажут что ваша компания ддосит кремлинру?
— вы сможете сказать кто и когда изменил настройки на сервере\рабочей станции\базе данных\роутере\файерволле?
Если все «да» и вы это сделали с помощью домена — честь и благодать Вам.
Общая цель — защищенность. Аудиторские проверки на соответствие стандартам не у всех проводятся. Если нет требований отраслевых или компания не прошла сертификацию по ISO, то зачем аудиторские проверки? Так считаю многие, отодвигая все стандарты в сторону и начиная изобретать велосипед в виде внутренних бумажных политик без контроля их соблюдения. Максимум что делают в подобном лучшем случае — заказывают сторонний аудит ИБ. А можно взять за основу политик контроли, указанные в стандартах, расширить их и контролировать их соблюдение. Согласитесь, что часть требований стандартов — это азы информационной безопасности, которые необходимо соблюдать и контролировать. Если они не учтены — то о какой безопасности может идти речь?
Говоря фразу «Вы в корне неправы.» я имела ввиду ваш коммент в котором я это написала а не статью. Не следует воспринимать комментарии не содержащие «о, спасибо, клево» как атаку на вас.
Цель статьи какая? Рассказать про CEF? Ну подготовьтесь, изучите его сначала сами, посмотрите — а какие есть проблемы у siem\sim систем в рамках типизации событий. Приведите примеры плюсов и минусов использования CEF. Посмотрите кто использует CEF и как. В данном случае вы объективно этого не понимаете. Пример — продукт компании в которой я работаю в данное время интегрирован с ArcSight. Но это не означает, что мы используем CEF.
Примеры? «Подключение нового источника событий превращается в «plug and play»» Вот ведь не так на практике, да?! Да, с типизацией на стороне источника, с которым интегрируемся или агента (когда в siem приходят уже нормализованные типизированные события) все намного проще становится. Можно и фильтрацию делать, и ресурсы сервера на типизацию не тратятся. И правилами корреляции по ним можно работать и методами пройтись…
" Его уже применяют и в других решениях, связанных с обработкой логов." Можно примеры? Просто примеры классов решений. Или вендоров. Для саморазвития. Может, я просто фразу не поняла.
«Вы мне лучше приведите ссылку, по которой я смогу пройти и убедиться, что формат CEE поддерживает большее (чем формат CEF) количество вендоров»
CEE: Tripware, Sensage
CEF: ArcSight
Это siem-ы. То что указали вы, еще раз, при всем уважении, это «CEF Connectors and Action Connectors», но не использование CEF партнерами для своих продуктов.
У CEF, равно как и у остальных, есть свои плюсы и минусы. Насколько я знаю из блогов, CEF хотели модифицировать, развить, так как не совсем устраивал.
Про udp доставку, я надеюсь, вы знаете. 100 км от мкад и там такие каналы связи «замечательные»… Про спутник — тоже. Встает сразу проблема целостности передачи. Ну а про защищенность udp я промолчу.
Это не склоняются именно к CEF", они используют его для интеграции. Это разные вещи. Приведу простой пример. Вам нужно (именно вам, потребность) позвонить в Штаты. Вы им предлагаете заговорить с вами на русском, или все же будете на инглише разговаривать?
Можно примеры склонности к CEF?
Почитайте презентацию Чувакина. Там азы заложены ;)
illuzii, простите за использование вас в комментарии, но! site:ebay.com intext:«illuzii» и получаем:
Сейчас часть итемов пишется как item #… Но он легко находится по этому номеру на самом ebay или в google.
Dsec я упомянула лишь потому что вижу пессимистичность к защите. Она бросается в глаза мне лично, как аналитику. Если человек показывает пессимизм к мерам защиты — значит на уровне корпоративной защиты тоже есть изъяны («осведомленность»). Значит — можно использовать. Обидеть не преследовала цель. Хотя, в день рождения настроение с минусами мне вы попортили.
Какую «репрезентативную» статистику вы хотели бы увидеть? Она есть в аналитике McAfee, Symantec. Копипастить их отчеты не преследовала целью. Подробные наименования компаний вы вряд ли найдете — не принято в России. Равно, как не принято сообщать об инцидентах.
Парадигма их, состав и последовательность будут меняться.
Красиво или нет — вы решаете индивидуально для себя. Термин придумали не вы, не я. И не зря.
Комплекс мер по защите для различных угроз разный. Статистика компаний, подвергшихся атаке, позволяет судить что меры не принимаются, или принимаются некорректно.
Можно сложить ручки и пессиместично чего то ждать — угрозы то по вашим словам есть и будут… А можно попытаться донести до аудитории, разъяснить, чтобы не было им потом печально. Из аудитории на РусКрипто никто не знал об APT в России. Не из за пессимистичности ли? Ведь «термин был моден в 2009-2010». Про 2011 и 2012 d00kie наверное вы не успели прочитать.
Задумалась — может стоит взять на следующую статью в качестве примера dsec?