Недавно наткнулся на репозитарий с правилами детектов для
В правилах от
А вот второй момент по детектированию аномального поведения тут реализован отлично, от того, как это сделано в Falco (в нем надо собственноручно описать нормальную модель поведения и поддерживать ее). Здесь используется отдельная категория для таких вещей как
Elastic Security Solution (развитие или дополнение ElasticSearch). Среди правил, там есть правила для AWS, Azure, GCP в соответствии с матрицей ATT&CK. Честно говоря, про Kubernetes там нет ничего. И мое внимание это привлекло лишь потому, что можно провести параллели с Falco, который также работает на основе правил (правда которые вы же и должны предварительно адаптировать под себя).В правилах от
Elastic Security Solution мне очень понравилось и позабавило поле false_positives. Понравилось тем, что авторы вообще проработали этот момент и сделали для этого хорошее описание, а позабавило что это поле есть наверно у 99% всех правил. При этом эти правила в основном для детектирования каких-то инфраструктурных вещей, что на мой взгляд определенно имеет право на существование.А вот второй момент по детектированию аномального поведения тут реализован отлично, от того, как это сделано в Falco (в нем надо собственноручно описать нормальную модель поведения и поддерживать ее). Здесь используется отдельная категория для таких вещей как
ML - machine learning. Насколько это качественно работает сказать абсолютно невозможно и единственный механизм влияния тут это численное поле anomaly_threshold. Что говорит нам о использовании нейронных сетей. При разработке своего детектора аномального поведения приложений в Kubernetes, мы также проводили эксперименты с нейронными сетями и пришли к выводу что основная их проблема это не возможность объяснить на основании чего было принято то или иное решение оператору и в случае false positive необходимость полного переобучения сети. Так что, меняя значение anomaly_threshold остается просто ждать какой-то магии и конечный результат вы вряд ли поймете.