Про разные модели угроз: именно для этого есть пункт про определение зоны действия правил
Про монструозность модели: решая задачи Asset и Vulnerability Management в компании (не для галочки) создаётся модель АС, только в другом решении. Функции импорта отчетов сканеров безопасности в SIEM — не что иное, как попытка получить кусочек этой модели. Делая правила корреляции по профилированию действий пользователей или их сетевой активности также создаётся модель на базе Active list/Ref. set/табличных списков и они просто огромны :) Т.ч. созданием модели и так занимаются неявно,
я тут ничего не придумал. Только это делают в разных продуктах и бессистемно.
В модель должна смотреть (дополнять, актуализировать) машина, а не человек.
В методологии есть моменты (их всего пара) которые требуют определенных функций от самого SIEM. Эти функции позволяют строить внутри SIEM модель АС. На эту модель правила и могут опираться. В ArcSight модель достаточно примитивна и нетемпоральна, чуть развесистее в Qradar, но ей почти нельзя оперировать в правилах корр. Отсутствие таких вещей выбивают фундаментальные вещи, позволяющие строить адаптивные правила. Об этом я подробно писал в прошлой статье.
И, да, что мешает совмещать правила и бестпрактисы сразу :)
Если реально смотреть на вещи, то простые правила, действительно, заработают «из коробки», т.к. будут адаптироваться под инфраструктуру. Более сложные, все же придется подтюнить и тут важно добиться того, чтобы такого тюнинга было минимум.
Я негативно отношусь к этой новости. Снижение конкуренции на рынке ИБ России ни к чему хорошему не приведет.
Судя по тому как развивалась ситуация, а я за ней следил с самого начала, тут много политики, неже ли денег. То как поспешно было принято решение, как обошлись с официальными партнерами в России… Очень мутная и спорная ситуация.
Это система категоризации атак, исходя из используемых злоумышленниками техник и тактик.
Какие техники и тактики чаще всего используют разные группировки можно посмотреть здесь mitre caret.
На хабре есть подробный разбор https://habr.com/ru/post/423405/ от bassmack
Я этой темы не касаюсь, т.к. техниками и тактиками помечаются инциденты, вылетающие из коррелятора. Здесь же я рассматриваю события, которые попадают на вход в коррелятор.
В этих словах есть правда… Следующая статья будет про использование данных об активах. Эта задача схожу с обогащением. Там постараюсь тему восполнения недостающих данных затронуть.
Спасибо за фидбек, момент с обогащением от меня ускользнул :(
В данном подходе категория отражает суть исходного события. Суть может быть определена на этапе нормализации (даже с пропущенными данными)
Категория определяет правила заполнения нужных полей. Но что делать с пропущенными данными (src.ip — действительно такой случай)? Восполнить такие пропуски можно обогащением (когда это возможно, но это далеко не всегда так). Т.о. зачем дотягивать категоризацию до обогащения?
Да, верно, в этом тоже есть большая проблема. К сожалению я ее не затронул в этой статье.
Видится, что для ее решения надо выработать какой-то отраслевой стандарт. Этот цикл статей — робкая попытка начать наводить порядок хотя бы в рамках одной компании/вендоре. Если выработанные практики можно будет масштабировать, будет успех. На отраслевой стандарт, я пока не замахиваюсь. Здесь ключевое слово "пока" :)
Да, такое можно сделать. Только это займет целую статью. Сначала хочется описать к какой схеме, на мой взгляд, стоит прийти и потом уже, через эту призму, посмотреть на наборы полей, которые есть в наиболее распространенных в России SIEM-ах.
Да, вы абсолютно правы. SIEM выедает очень много трудозатрат как при внедрении, так и при эксплуатации. Лично мое мнение заключается в том, что вендоры изначально позиционируют свои решения как «конструкторы», из блоков которых надо собирать себе «работающий» SIEM. Мало кто пытается переломить этот тренд и сделать продукт, которое будет решать конечные задачи пользователя, а не давать кубики для сборки.
Мне кажется, для того чтобы непосредственно решать проблемы ИБ средствами SIEM, надо, как минимум, постараться систематизировать входные данные, а не тратить на это время и мыслетопливо на этапе написания правил корреляции (они ведь и отвечают за конечную пользу).
В общем-то весь цикл статей, по большей части, именно про то, чтобы избавиться от garbage-in. И со следующей статьи это будет более четко видно.
С UEBA тоже тема не простая. Я долго искал в России инсталляции любого продукта класса UEBA, где бы заказчик честно признался, что она приносит ему пользу. Пока не нашел, но не оставляю попыток. Сам немого увлекаюсь ML и чуток понимаю как все работает, т.ч. пока у меня сложилось такое мнение, что для того чтобы UEBA реально заработала в штате нужен безопасник + data scientist. Любые поведенческие модели надо подкручивать под особенности своей инфраструктуры и бороться за precision и recall.
Да, Вы правы, пока таких нет.
Создавая данную методологию хотелось изменить ситуацию и стараться двигаться в правильном направлении.
я тут ничего не придумал. Только это делают в разных продуктах и бессистемно.
В модель должна смотреть (дополнять, актуализировать) машина, а не человек.
И, да, что мешает совмещать правила и бестпрактисы сразу :)
Судя по тому как развивалась ситуация, а я за ней следил с самого начала, тут много политики, неже ли денег. То как поспешно было принято решение, как обошлись с официальными партнерами в России… Очень мутная и спорная ситуация.
Какие техники и тактики чаще всего используют разные группировки можно посмотреть здесь mitre caret.
На хабре есть подробный разбор https://habr.com/ru/post/423405/ от bassmack
Я этой темы не касаюсь, т.к. техниками и тактиками помечаются инциденты, вылетающие из коррелятора. Здесь же я рассматриваю события, которые попадают на вход в коррелятор.
Спасибо за фидбек, момент с обогащением от меня ускользнул :(
Как и писал выше в методологии, действительно есть дырка: она ничего не говорит о том как и где достать недостающие в событии данные.
Вроде как именно об этом шаг 3 методологии.
В данном подходе категория отражает суть исходного события. Суть может быть определена на этапе нормализации (даже с пропущенными данными)
Категория определяет правила заполнения нужных полей. Но что делать с пропущенными данными (src.ip — действительно такой случай)? Восполнить такие пропуски можно обогащением (когда это возможно, но это далеко не всегда так). Т.о. зачем дотягивать категоризацию до обогащения?
Да, верно, в этом тоже есть большая проблема. К сожалению я ее не затронул в этой статье.
Видится, что для ее решения надо выработать какой-то отраслевой стандарт. Этот цикл статей — робкая попытка начать наводить порядок хотя бы в рамках одной компании/вендоре. Если выработанные практики можно будет масштабировать, будет успех. На отраслевой стандарт, я пока не замахиваюсь. Здесь ключевое слово "пока" :)
Мне кажется, для того чтобы непосредственно решать проблемы ИБ средствами SIEM, надо, как минимум, постараться систематизировать входные данные, а не тратить на это время и мыслетопливо на этапе написания правил корреляции (они ведь и отвечают за конечную пользу).
В общем-то весь цикл статей, по большей части, именно про то, чтобы избавиться от garbage-in. И со следующей статьи это будет более четко видно.
С UEBA тоже тема не простая. Я долго искал в России инсталляции любого продукта класса UEBA, где бы заказчик честно признался, что она приносит ему пользу. Пока не нашел, но не оставляю попыток. Сам немого увлекаюсь ML и чуток понимаю как все работает, т.ч. пока у меня сложилось такое мнение, что для того чтобы UEBA реально заработала в штате нужен безопасник + data scientist. Любые поведенческие модели надо подкручивать под особенности своей инфраструктуры и бороться за precision и recall.