The post has been translated automatically. Original language: Russian
Part 18: Checking the security of the Falco runtime environment in the DevSecOps pipeline
In part 18 of my DevSecOps project, I focused on one issue.:
Do the Falco rules correctly detect suspicious activity while the application is running?
The project unites:
→ Trivy / KICS for static security analysis→ Kubernetes / k3d for the runtime→ Falco for detecting suspicious activity during execution→ MITRE ATT&CK for method classification→ Python for correlating security events→ Artificial Intelligence for analyzing detected events→ Telegram + Prometheus/Grafana for reports and observability
During the check, I discovered two important gaps in the Falco detection mechanism.
1. Network activity detection
The rule designed to detect outgoing network activity did not work because the python container:3.11-slim did not contain the necessary components that the rule monitored.
I have adjusted the container configuration and detection logic.
The next run recorded 3 outgoing TLS connections, which were classified as T1048 according to MITRE ATT&CK.
2. Detecting file access events
The initial configuration of the runtime environment was focused primarily on successful operations.
As a result, the event related to accessing the /etc/shadow file was not recorded.
I added the handling of system events with an access error, after which the test correctly fixed:
file=/etc/shadowresult=EACCEScommand=cat /etc/shadow
The event was classified as a confirmed discovery, not as a proven exploit of the vulnerability.
I've also added 29 unit tests covering verdict logic, recurring events, priorities, and various detection scenarios.
The main lesson:
The presence of the Falco rule in YAML does not in itself mean that the detection mechanism is working correctly.
It is necessary to run the rules in a real environment, verify actual events, test various scenarios, and protect the detection logic from regressions.
Part 18 of my DevSecOps hands-on project is dedicated to this.
Часть 18: Проверка безопасности среды выполнения Falco в конвейере DevSecOps
В части 18 моего проекта DevSecOps я сосредоточился на одном вопросе:
Действительно ли правила Falco корректно обнаруживают подозрительную активность во время работы приложения?
Проект объединяет:
→ Trivy / KICS для статического анализа безопасности→ Kubernetes / k3d для среды выполнения→ Falco для обнаружения подозрительной активности во время выполнения→ MITRE ATT&CK для классификации методов→ Python для корреляции событий безопасности→ Искусственный интеллект для анализа выявленных событий→ Telegram + Prometheus/Grafana для отчетов и наблюдаемости
Во время проверки я обнаружил два важных пробела в механизме обнаружения Falco.
1. Обнаружение сетевой активности
Правило, разработанное для обнаружения исходящей сетевой активности, не срабатывало, поскольку контейнер python:3.11-slim не содержал необходимых компонентов, которые отслеживало правило.
Я скорректировал конфигурацию контейнера и логику обнаружения.
Следующий запуск зафиксировал 3 исходящих TLS-соединения, которые были классифицированы как T1048 в соответствии с MITRE ATT&CK.
2. Обнаружение событий доступа к файлам
Изначальная конфигурация среды выполнения была ориентирована преимущественно на успешные операции.
В результате событие, связанное с обращением к файлу /etc/shadow, не фиксировалось.
Я добавил обработку системных событий с ошибкой доступа, после чего тест корректно зафиксировал:
file=/etc/shadowresult=EACCEScommand=cat /etc/shadow
Событие было классифицировано как подтвержденное обнаружение, а не как доказанное использование уязвимости.
Также я добавил 29 модульных тестов, охватывающих логику вынесения вердикта, повторяющиеся события, приоритеты и различные сценарии обнаружения.
Главный урок:
Наличие правила Falco в YAML само по себе не означает, что механизм обнаружения работает корректно.
Необходимо запускать правила в реальной среде, проверять фактические события, тестировать различные сценарии и защищать логику обнаружения от регрессий.
Этому посвящена часть 18 моего практического проекта DevSecOps.
Share
