Z
интересно что предложит pt:)
давайте сделаем свой велик потому что:
- "посмотрите люди не хотят делать сами но им очено надо"
- "посмотрите люди сами пилят этим проклятые велики каждый по своему а мы сделаем так что всем понравится!"
Size: a a a
2019 February 19
B
Попробуйте поэксплуатировать misp в продакшн soc'а в условном режиме slave
ВД
Я тоже такое слышал ещё в 2017, но процесс шел специфически, и я не уверен что без личных связей он бы закончился
Нет никакой проблемы в этом вопросе
y
> MISP не про хранение
можете подробнее описать в чем проблема с хранением данных в MISP?
> очень ограниченно про сбор
Зависит от определения слова "сбор". Вы про какой сбор? Я про синхронизацию фидов и сохранение их в локальной базе, например. Добавление своих данных тоже не проблема, это основная функциональность.
> на нормальном стеке
Переписать на go? (: Видел ваши аналайзеры в репо thehive, по соседству с нашими.
> с вменяемой архитектурой
Александре — нормальный чел. Они принимают любые запросы и довольно отзывчивы. Посоветуйте им как оно должно быть на ваш взгляд, вполне вероятно запрос будет услышан. На мой взгляд лучше улучшать существующее, чем строить новое. Потому что это не только про техническое решение, но и про подход. Основное достижение ребят это евангелизация threat sharing, самой культуры. И их продукт на этой идее стоит, в первую очередь.
можете подробнее описать в чем проблема с хранением данных в MISP?
> очень ограниченно про сбор
Зависит от определения слова "сбор". Вы про какой сбор? Я про синхронизацию фидов и сохранение их в локальной базе, например. Добавление своих данных тоже не проблема, это основная функциональность.
> на нормальном стеке
Переписать на go? (: Видел ваши аналайзеры в репо thehive, по соседству с нашими.
> с вменяемой архитектурой
Александре — нормальный чел. Они принимают любые запросы и довольно отзывчивы. Посоветуйте им как оно должно быть на ваш взгляд, вполне вероятно запрос будет услышан. На мой взгляд лучше улучшать существующее, чем строить новое. Потому что это не только про техническое решение, но и про подход. Основное достижение ребят это евангелизация threat sharing, самой культуры. И их продукт на этой идее стоит, в первую очередь.
y
Попробуйте поэксплуатировать misp в продакшн soc'а в условном режиме slave
мы используем. полет нормальный.
B
мы используем. полет нормальный.
Первые месяца три было нормально в моем кейсе, да
B
Потом стало больше данных и больше запросов к misp...
V
по моему опыту, при большой базе, misp начинает ломаться и странно себя вести
V
а поиски вылетают в time out
V
было бы не плохо, если бы они отказались от mysql
IG
> MISP не про хранение
можете подробнее описать в чем проблема с хранением данных в MISP?
> очень ограниченно про сбор
Зависит от определения слова "сбор". Вы про какой сбор? Я про синхронизацию фидов и сохранение их в локальной базе, например. Добавление своих данных тоже не проблема, это основная функциональность.
> на нормальном стеке
Переписать на go? (: Видел ваши аналайзеры в репо thehive, по соседству с нашими.
> с вменяемой архитектурой
Александре — нормальный чел. Они принимают любые запросы и довольно отзывчивы. Посоветуйте им как оно должно быть на ваш взгляд, вполне вероятно запрос будет услышан. На мой взгляд лучше улучшать существующее, чем строить новое. Потому что это не только про техническое решение, но и про подход. Основное достижение ребят это евангелизация threat sharing, самой культуры. И их продукт на этой идее стоит, в первую очередь.
можете подробнее описать в чем проблема с хранением данных в MISP?
> очень ограниченно про сбор
Зависит от определения слова "сбор". Вы про какой сбор? Я про синхронизацию фидов и сохранение их в локальной базе, например. Добавление своих данных тоже не проблема, это основная функциональность.
> на нормальном стеке
Переписать на go? (: Видел ваши аналайзеры в репо thehive, по соседству с нашими.
> с вменяемой архитектурой
Александре — нормальный чел. Они принимают любые запросы и довольно отзывчивы. Посоветуйте им как оно должно быть на ваш взгляд, вполне вероятно запрос будет услышан. На мой взгляд лучше улучшать существующее, чем строить новое. Потому что это не только про техническое решение, но и про подход. Основное достижение ребят это евангелизация threat sharing, самой культуры. И их продукт на этой идее стоит, в первую очередь.
Полностью согласен про последний пункт, и уважаю труд ребят, но к сожалению, реально проще переписать все решение.
MISP становится крайне неповоротливым при попытке хранить в нем 10М+ индикаторов и постоянно вгружать новые. У нас данных по обогащениям и категоризациям по всем индикаторам в порядке миллиарда и, разумеется, Mysql вообще непредназначен для такого.
Быстрый лукап для проверки индикатора - это тоже не про MISP.
MISP можно использовать для алертинга по новым угрозам, для шеринга инцов и эпизодического импорта/экспорта эвентов, созданных в ручном или полуручном виде - из TheHive, например.
MISP становится крайне неповоротливым при попытке хранить в нем 10М+ индикаторов и постоянно вгружать новые. У нас данных по обогащениям и категоризациям по всем индикаторам в порядке миллиарда и, разумеется, Mysql вообще непредназначен для такого.
Быстрый лукап для проверки индикатора - это тоже не про MISP.
MISP можно использовать для алертинга по новым угрозам, для шеринга инцов и эпизодического импорта/экспорта эвентов, созданных в ручном или полуручном виде - из TheHive, например.
B
Переделали скрестив с редис
B
Но это было совсем не просто
V
поделитесь форком?
B
поделитесь форком?
Уволился оттуда
Z
почитал, таким тупым себя ощутил;)
ВД
Misp это framework. Дальше нужно три-четыре разработчика и делать под себя. Большая задача, если нужно много данных и внешних источников
y
Полностью согласен про последний пункт, и уважаю труд ребят, но к сожалению, реально проще переписать все решение.
MISP становится крайне неповоротливым при попытке хранить в нем 10М+ индикаторов и постоянно вгружать новые. У нас данных по обогащениям и категоризациям по всем индикаторам в порядке миллиарда и, разумеется, Mysql вообще непредназначен для такого.
Быстрый лукап для проверки индикатора - это тоже не про MISP.
MISP можно использовать для алертинга по новым угрозам, для шеринга инцов и эпизодического импорта/экспорта эвентов, созданных в ручном или полуручном виде - из TheHive, например.
MISP становится крайне неповоротливым при попытке хранить в нем 10М+ индикаторов и постоянно вгружать новые. У нас данных по обогащениям и категоризациям по всем индикаторам в порядке миллиарда и, разумеется, Mysql вообще непредназначен для такого.
Быстрый лукап для проверки индикатора - это тоже не про MISP.
MISP можно использовать для алертинга по новым угрозам, для шеринга инцов и эпизодического импорта/экспорта эвентов, созданных в ручном или полуручном виде - из TheHive, например.
Z
yeti как вам?
AK
Подгон этомучату