K
точно сказать сложно, но минут 10 до коррелятора доходит...
Size: a a a
2019 March 29
K
то есть имеет смысл перенести операции со списками в обогащение и, например, вешать метку на событие при обогащении?
RS
как вариант
K
забавно, возникает и обратная ситуация: при удалении записи из списка, коррелятор опять же не отрабатывает. Инцидента нет, запись не создается. Думаю, минут через 10 отработает... и не раз...
MI
Так баг или фича ? 😉
K
с учетом, что в корреляции использовать далеко не всегда удобно, я бы сказал, что баг...
K
по идее, нужно было отлавливать первое событие в сутки (время жизни записи в списке ограничено сутками) и генерировать инцидент единожды... теперь придется разносить на два правила - корреляция и обогащение, это не так удобно.
Да и проверить нужно, не страдает ли обогащение подобными проблемами
Да и проверить нужно, не страдает ли обогащение подобными проблемами
RS
Так баг или фича ? 😉
не фича точно
SA
коллеги, подскажите пожалуйста, почему может некорректно отрабатывать правило корреляции? (во вложении)
Как задумано: при возникновении события "Test_event" генерируется инцидент и в табличный список "Table_test" записываются IP и имя пользователя из события. При повторном возникновении события "Test_event" с теми же данными коррелятор находит запись в списке и не генерирует инцидент.
Как работает: инциденты генерируются на каждое событие "Test_event"...
Запись в списке каждый раз обновляется.
Подскажите, в чем может быть причина? Заранее огромное спасибо!
Как задумано: при возникновении события "Test_event" генерируется инцидент и в табличный список "Table_test" записываются IP и имя пользователя из события. При повторном возникновении события "Test_event" с теми же данными коррелятор находит запись в списке и не генерирует инцидент.
Как работает: инциденты генерируются на каждое событие "Test_event"...
Запись в списке каждый раз обновляется.
Подскажите, в чем может быть причина? Заранее огромное спасибо!
Можете рассказать сколько у вас записей в таблице, и какая используется схема табличного списка?
К
не фича точно
Ром, дык мы вроде на 2556 с такой же фигней сначала пришли, разве нет?
RS
Ром, дык мы вроде на 2556 с такой же фигней сначала пришли, разве нет?
Нет, у вас на обогащении это вылезло и там оно было ожидаемо
К
Нет, у вас на обогащении это вылезло и там оно было ожидаемо
м? у нас на корреляции это вылезло. обогащением мы это обходили.
2019 March 30
IS
по идее, нужно было отлавливать первое событие в сутки (время жизни записи в списке ограничено сутками) и генерировать инцидент единожды... теперь придется разносить на два правила - корреляция и обогащение, это не так удобно.
Да и проверить нужно, не страдает ли обогащение подобными проблемами
Да и проверить нужно, не страдает ли обогащение подобными проблемами
Я писал подобное правило и оно работало корректно. Как уже писали нужно проверить регистры и добавьте key в событие, мне говори что его отсутствие может магически влиять на корреляцию)
RS
Ключ, да, нужен, но это больше про производительность
K
Можете рассказать сколько у вас записей в таблице, и какая используется схема табличного списка?
Запись в списке одна, это тестовый стенд.
Структура... 3 столбца: время изменения записи, ip и account. Все ключевые. Размер таблицы ограничен сотней записей, время жизни записи - 12 часов.
Структура... 3 столбца: время изменения записи, ip и account. Все ключевые. Размер таблицы ограничен сотней записей, время жизни записи - 12 часов.
2019 April 01
Z
драсте, c ksc события кто получает?
К
привет. а в чем вопрос?)
К
мы на них собаку съели, если позитив не врёт)
Z
сегодня баг в саппорт завел, что события сыпет с карантином. в кореляции есть директива state в нормализации её нет
К
сегодня баг в саппорт завел, что события сыпет с карантином. в кореляции есть директива state в нормализации её нет
нормализацию лучше доработать по месту напильником - там вообще много чего нет