Комментарии 17
1) может ли система в качестве реакции на событие или последовательность событий порождать новые событие?
2) позволяет ли система обогащать событие новыми значениями которых в них нет. Например есть событие логина в котором фигурирует логин пользователя и некоторый числовой ID. А во всех последующих событиях от системы фигурирует уже только этот ID без логина пользователя. Если в SIEM поступит событие, требующее реакции, то надо по ID-пользователя найти соответствующий ему логин и дообогатить событие логином. Для этого в SIEM - системах используются дополнительные пользовательские структуры (см.п3)
3)можно ли в системе создавать пользовательские таблицы, справочники с данными, динамически наполнять их данными, делать поиск данных по этой таблице в правила корреляции?
если говорить про формирование инцидентов на основании заданной последовательности событий - то само собой да. Если говорить про управление активами и реакцию в виде изменений настроек источников данных (и пр.) то нет. Но такой функционал будет добавлен в течении этого года.
В описанном виде - нет. Но в правилах кросс-корреляции для похожих целей используется указание поля объединения. Это позволяет добиться похожего результата без добавления одинакового поля в каждое событие.
нет, такого функционала нет. Но есть ряд инструментов, позволяющих решить задачи, которые обычно решаются динамическими списками в других решениях.
.
по п.1. имелось ввиду не создание активные действия на основании последовательнтси событий. Имелось ввиду, что на основании последовательности событий от сырых источников, формируется некоторое внутреннее событие в системе. Это событие само по себе обрабатывается SIEM системой так-же как и соібтия от источников. Например есть несколько разных фаерволов разных производителей, которые генерируют событие "доступ запрещен" в специфичном для каждого источника виде. Разрабатывается одно правило, которое объединяет эти типы событий от разных фаерволов и в ответ генерирует уже одно унифицированное внутреннее событие "доступ запрещен", с указанием source и destination. Другие правила, которым важен факт нарушения сетевого доступа, но не важен конкретно источник уже реагируют на это унифицированное событие.
по .п.2. ип.3 интересно, как это сделано в вашей системе, что бы понять возможности движка для решения типовых задач. Можно просто ссылки на документацию.
«СёрчИнформ SIEM» базируется на опенсорсной (а оттого независимой) MongoDB.
Так ли это? Это вопрос:
В октябре 2018 года компания-разработчик объявила о переходе к более жёсткой по сравнению с AGPL копилефтной лицензии SSPL (Server Side Public License)[9][10]. Вслед за этим было начато изучение новой лицензии представителями Open Source Initiative и Free Software Foundation на предмет соответствия определениям открытого и свободного программного обеспечения.
К сожалению проблема администрирования SIEM, "решаемая" "из коробки", - не самая большая проблема мониторинга ИБ. Это видно на основе состава специалистов в SOC - администраторы SIEM занимают в лучшем случае 10% штата.
Поэтому решение проблем доступности SIEM для SMB не может быть сведено к упрощению администрирования и внедрения (а у такого подхода есть и минусы).
Вы говорите, про импортозамещение и объекты КИИ, а серверная часть вашего продукта до сих пор работает только операционных системах MS Windows. Когда-нибудь мы наверно дождёмся решения на Linux, с нетерпением ждём.
Судя по описанию, получилась достойная замена SIEM-системам (QRadar, ArcSight, McAfee ESM) образца 2014 года.
Современная SIEM-система - это прежде всего платформа обработки данных, с надстройкой в виде правил корреляции, алертов, тригеров, дашбордов, карточек инцидента и прочими специальными инструментами.
Хорошие примеры, которые следовало бы импортозаместить:
Elastic Security (на базе ELK Stack)
Splunk Enterprise Security (на базе Splunk Platform)
По поводу систем, которые следовало бы заменить – не вижу проблем ни по одной из перечисленных. Мы работали и замещали SIEM у заказчиков, хорошо знакомых или применявших перечисленных «иностранцев».
ну, а теперь расскажите - чем это лучше, чем тот же https://wazuh.com/blog/
или
Что касается open-source SIEM. Они могут быть хорошим решением, но только в одном случае – если в компании достаточный штат квалифицированных администраторов, у которых есть время и знания, чтобы постоянно «допиливать» систему под свою компанию. Но даже если так — для компании это слишком большой риск: если спец уйдет, с ним скорее всего уйдет и вся экспертиза. Ну и последнее. В нынешних условиях доверить опен-сорс решению свою безопасность готовы все меньше компаний.
Извините, но Вы пишете бред.
В нынешних условиях доверить опен-сорс решению свою безопасность готовы все меньше компаний.
ровно наоборот. Closed source и проприетарные решения означают неприемлемые риски для компаний. Во-первых, попробуй найди специалистов на местечковые решения. Тот же Splunk. Съедешь на ArcSite - это либо переучивать спецов, либо нанимать новых. С другой стороны, уже есть сформировавшийся рынок. И спецов найти можно. Хоть как-то. А для noname SIEM - какие специалисты? Или Вы предлагаете полный цикл поддержки? А сколько это будет стоить? Время реакции какое будет? Тогда уж проще отдать SOC вообще на аутсорс - есть прекрасные ребята из https://www.angarasecurity.ru/ которые готовы это реализовать и вообще голова не болит, только успевай счета оплачивать.
О наших преимуществах мы много писали в статье – система простая и понятная, это для многих заказчиков то, что доктор прописал.
не верю (с) Мы прекрасно понимаем, что это маркетинг и только маркетинг. И еще - система должна быть не только простой и понятной, а там еще пачка критериев - оптимальной по цена/качество, надежной, быстрой, не очень ресурсоемкой (кому нужна система, железо под которую стоит как крыло от боинга) и пр. пр. пр. В том числе - и от надежного партнера, а не noname ООО с уставным капиталом 10000 рублей, которое завтра закроется (это не к вам претензия, а к другим ребятам, которые знают, о чем речь).
у нас есть опыт успешного замещения системы
анекдот про дельфинов помните?
Типа: вы же знаете, что дельфины "всегда" спасают людей и вытаскивают их на берег... но что случается с теми, кого дельфины уносят в море? Эти же люди ничего не скажут никому!?
Они могут быть хорошим решением, но только в одном случае – если в компании достаточный штат квалифицированных администраторов, у которых есть время и знания, чтобы постоянно «допиливать» систему под свою компанию. Но даже если так — для компании это слишком большой риск: если спец уйдет, с ним скорее всего уйдет и вся экспертиза.
любая SIEM требует настройки. Как минимум - интеграция в текущий ИТ ландшафт. Как максимум - fine tuning алертов и корелляция событий. Иначе она превращается попросту.... в дорогостоящую игрушку.... и способ заткнуть аудититоров (то что я презрительно называю "бумажной безопасность" и что особо любят в РФ в госах)
Ладно, прошу прощения за резковатый тон. Но я реально видел просто эпичнейшие факапы в дорогущих (и якобы лидерах индустрии) продуктах.
Например, можете ли Вы работать в режиме, когда у Вас есть пересекающиеся сети в различных отделениях какого-нибудь всероссийского банка (ну, вот так сеть исторически сложилась). Это не на реальном примере из моего опыта, из опыта коллег.
Или - если особо умные надмозги заиспользовали для внутренних адресов публичные сети из диапазонов, схожих с используемымыми в RFC1918 (бывает, в частности, во всяких этих ваших кубернетисах)... а система говорит, что это ВНЕШНИЙ адрес из U.S.A. (ага-ага, интеграция с IPAM нам не нужна)....
и всякое такое... по мелочи... рассказать могу много corner case'ов, только кому они нужны
Понимаете в чем дело... заявлениями о "простой и интуитивной системе" Вы создаете ложное ожидание у потенциального потребителя... со всеми вытекающими последствиями... Типа SIEM будет работать из коробки... и ловить злоумышленников... прямо на месте преступления... ага-ага... верю как себе
SIEM-терапия: защититься, импортозаместиться, сэкономить