Какие проблемы или root причин вы пытаетесь выявить с помощью графика трафика Zeek восток-запад c?
Похоже, что более подходящий вариант использования, такой как определенный тип аутентификации c, или даже более крупный набор проблем, такой как расширение доступа к конечной точке, может лучше использовать хранилище, вычисления, память и другие ваши драгоценные время и ресурсы, нет?
Даже если вы действительно хотите коррелировать или группировать данные Zeek, попробуйте нормализовать их до OSSEM , и не будет никаких причин, скажем, собирать кортеж, когда вы можете собрать идентификатор сообщества вместо. Вы можете соотнести Zeek в большом с Suricata в маленьком. Возможно, лучшая архитектура данных будет VAST .
Kibana в своих последних итерациях имеет Graph , и даже более старая версия может поддерживать сторонний плагин kbn_network . Я мог видеть, как вы попали в стену с 200k активных IP-адресов и агрегацией Elasticsearch или даже сводными индексами.
Многие организации будут создавать архитектуры данных за пределами простого обслуживающего уровня, предоставляемого Elasticsearch. То, о чем я слышал, - это архитектура Kappa, напрямую передаваемая в базу данных графов, такая как dgraph , и, возможно, только те края графа, которые доступны со слоя обслуживания.
Существуют и другие способы задавать вопросы из данных IP-адресов, например параметры ML в AWS SageMaker IP Insights или Apache Spot .
Кроме того, я большой поклонник получения правильных данных только при возникновении ситуации, хотя и в автоматическом режиме, так что кусочки головоломки всплывают для меня, и я могу просто зафиксировать их на месте. Если бы я особенно работал с данными Zeek, я мог бы задействовать платформу, такую как SecurityOnion и ее оркестрованный движок Playbook , чтобы запускать для меня другие задачи, такие как запросы с одним из Velocidex инструменты или даже кросс-корреляции с использованием встроенных Sigma источников.